🐷

AWS環境でASTERIA WarpフローをAPIとして公開する際のCORS設定 ― ALBで解決する方法

に公開
AWS
API
ALB
CORS
asteriawarp
tech

1. はじめに

WebアプリケーションからAPIを呼び出す際、異なるドメイン間通信ではCORS（Cross-Origin Resource Sharing）エラーが発生することがあります。今回は、AWS上でASTERIA WarpをEC2に構築し、ALB経由で外部公開する構成において、CORS問題をどのように解決したかを紹介します。

2. 背景と構成

  • ASTERIA Warpサーバ：EC2上に構築
  • 公開方法：ASTERIA WarpのフローをURLトリガーで設定し、HTTP公開プロトコルのみ外部公開
  • AWS構成：
    • WAF + ALB（パブリックサブネット）
    • ALBはHTTPSエンドポイント
    • ALBからASTERIA Warpサーバへプロキシ転送
  • 外部システム：Webアプリ（ブラウザからAPIコール）
  • 問題点：外部システムのドメインとAPIのドメインが異なるため、CORSエラーが発生

3. CORSの基本動作

  • ブラウザは異なるオリジンに対してAPIコールを行う際、最初にプリフライトリクエスト（OPTIONS）を送信
  • サーバが適切なCORSレスポンスヘッダをブラウザへ返すことで、ブラウザから通常のリクエストが許可される
  • 代表的なレスポンスヘッダ：
    • Access-Control-Allow-Origin
    • Access-Control-Allow-Methods
    • Access-Control-Allow-Headers

4. 課題

  • ASTERIA WarpにはCORS設定機能がない
  • TomcatなどのWebサーバが存在しないため、サーバ側でCORS対応が困難

5. 解決策

ALBでCORSレスポンスを返す

  • ALBのリスナールールで、OPTIONSメソッドに対して固定レスポンスを設定
  • レスポンスヘッダにCORS関連ヘッダを追加
  • これにより、ブラウザのプリフライトリクエストに正しく応答し、CORSエラーを回避

6. 実装ポイント

  • ALBリスナールール＞属性の設定例：
    • 条件：HTTPメソッドがOPTIONS
    • アクション：固定レスポンス（200 OK）
    • ヘッダ設定：
      Access-Control-Allow-Origin: *
      Access-Control-Allow-Headers: Content-Type, Authorization, Custom-Header1, Custom-Header2, Custom-Header3
      Access-Control-Allow-Methods: GET, POST, OPTIONS
  • 注意点：
    • ALBは動的なレスポンス生成ができないため、固定値で許可するオリジンを指定
    • セキュリティ上、Access-Control-Allow-Originは*ではなく必要なドメインのみ許可すべき（https://example.com）

7. まとめ

ASTERIA Warp単体ではCORS対応が難しい場合、AWS ALBを活用することでシンプルに解決できます。公式ドキュメントに記載がないため、同様の構成を検討している方にとって有用な情報になるはずです。

Discussion