AWS Solutions Architect · レッスン

リスナールールとパスベースルーティング

ALB にリスナールールを記述し、ホストヘッダー、パスパターン、クエリ文字列に基づいてリクエストを異なるターゲットグループへルーティングします。

「リスナールールとパスベースルーティング」はCoddyKit上の無料AWS Solutions Architectレッスンです。これはレッスン3/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。

ALB リスナーの概要

ALB のリスナーは、指定したプロトコルとポート（例: ポート 80 の HTTP、またはポート 443 の HTTPS）を使用して接続リクエストをチェックする仕組みです。各リスナーには 1 つ以上のルールがあり、リクエストの内容に基づいて転送先を決定します。

リスナーには、他のルールに一致しなかった場合の包括的なアクションであるデフォルトルールが必ず必要です。また、追加のルールを最大 100 個まで設定できます。ルールは優先度の順（番号が小さいほど優先度が高い）に評価されます。リクエストがルールの条件に一致すると、対応するアクションが適用され、それ以降のルールは評価されません。

# Create an HTTP listener on port 80
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789:loadbalancer/app/my-alb/abc123 \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/default-tg/def456

ルールの条件

リスナールールは、条件に基づいてリクエストに一致させます。1 つのルールに複数の条件を組み合わせることができ、ルールを適用するにはすべての条件に一致する必要があります。使用できる条件タイプは次のとおりです。

host-header: Host HTTP ヘッダーに一致（例: api.example.com）
path-pattern: URL パスに一致（例: /api/*、/images/*.jpg）
http-header: 任意の HTTP ヘッダー名と値のパターンに一致
http-request-method: HTTP メソッド（GET、POST、DELETE など）に一致
query-string: クエリ文字列のキーと値の組み合わせに一致
source-ip: クライアント IP の CIDR 範囲に一致

パスベースルーティング

パスベースルーティングは、URL パスに基づいてリクエストを異なるターゲットグループへ振り分けます。これは、1 つの ALB の背後でマイクロサービスを運用する際に最も一般的なルーティングパターンです。1 つの ALB に設定するルールの例を示します。

パスが /api/* → ターゲットグループ: api-service
パスが /images/* → ターゲットグループ: image-processor
パスが /admin/* → ターゲットグループ: admin-app
デフォルト → ターゲットグループ: frontend-app

これにより、複数のロードバランサーを用意しなくても、1 つの ALB で複数の異なるサービスを公開できます。コストと DNS の複雑さを抑えられます。

# Create a path-based routing rule
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/api-service/xyz789

ホストベースルーティング

ホストベースルーティングは HTTP の Host ヘッダーに基づいてリクエストをルーティングし、1 つの ALB から複数のドメイン名（バーチャルホスト）を提供できるようにします。例を示します。

ホストが api.example.com → api-service ターゲットグループ
ホストが admin.example.com → admin-app ターゲットグループ
ホストが www.example.com → frontend ターゲットグループ

各ドメイン名の CNAME または ALIAS レコードは同じ ALB の DNS 名を指しますが、ALB はホストヘッダーに基づいて、それぞれを適切なバックエンドにルーティングします。ホストベースルーティングは、マルチテナント SaaS や、モノリシックアプリケーションをマイクロサービスに分割する場合に適しています。

# Create a host-based routing rule
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 5 \
  --conditions '[{"Field":"host-header","HostHeaderConfig":{"Values":["api.example.com"]}}]' \
  --actions '[{"Type":"forward","TargetGroupArn":"arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/api-service/xyz789"}]'

ルールのアクション

ルールの条件に一致すると、ALB は次のいずれかのアクションを実行します。

forward: リクエストを 1 つ以上のターゲットグループに転送（重み付けも可能）
redirect: HTTP リダイレクト（301 または 302）を返し、新しい URL に移動。HTTP から HTTPS へのリダイレクトに便利
fixed-response: 指定したステータスコード、コンテンツタイプ、本文による静的な HTTP レスポンスを返す。メンテナンスページや単純なヘルスチェック応答に便利
authenticate-cognito: 転送前に Cognito User Pool を介してユーザーを認証
authenticate-oidc: OIDC 互換の任意のアイデンティティプロバイダーを介してユーザーを認証

# Create a redirect rule: HTTP to HTTPS
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/http80 \
  --priority 1 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/*"]}}]' \
  --actions '[{"Type":"redirect","RedirectConfig":{"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

HTTP から HTTPS へのリダイレクトパターン

最も一般的なリスナールールのパターンは、HTTP から HTTPS へのリダイレクトです。

ポート 80 の HTTP リスナーを作成し、1 つのルールで、すべてのトラフィック（/*）をステータスコード 301 で HTTPS にリダイレクトします
ポート 443 の HTTPS リスナーを作成し、ターゲットグループを指す実際のルーティングルールを設定します

これにより、ユーザーが http:// で入力した場合や古い HTTP リンクをたどった場合でも、アプリケーション側を変更せずに透過的に HTTPS へリダイレクトできます。リダイレクトはロードバランサー層だけで処理されます。

固定レスポンスアクション

固定レスポンスアクションは、リクエストをどのターゲットにも転送せず、ALB から静的な HTTP レスポンスを返します。次の用途に使用できます。

メンテナンス中に特定のパスへ 503 のメンテナンスページを返す
ALB から直接軽量なヘルスチェックエンドポイントを提供する（バックエンドの負荷なしで即座に 200 OK を返す）
403 Forbidden レスポンスで特定のパスをブロックする

固定レスポンスを使用すると、アプリケーションコードを変更したり再デプロイしたりせず、リスナールールを動的に調整してパスを一時的にサービス対象外にできます。

# Return 503 maintenance page for a specific path
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 20 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/checkout/*"]}}]' \
  --actions '[{"Type":"fixed-response","FixedResponseConfig":{"StatusCode":"503","ContentType":"text/html","MessageBody":"<h1>Maintenance</h1>"}}]'

Cognito による ALB 認証

ALB のauthenticate-cognito アクションは、Amazon Cognito User Pools と統合し、アプリケーションにリクエストを転送する前のユーザー認証を処理します。認証されていないユーザーが保護されたリスナールールに到達すると、ALB はログインのために Cognito がホストする UI へリダイレクトします。認証に成功すると、ALB は暗号化された Cookie を設定し、ユーザーの ID ヘッダーを付けてリクエストを転送します。

これにより、認証ロジックをアプリケーションから完全に切り離せます。バックエンドは、認証されたユーザーのクレームを含む X-Amzn-Oidc-Identity、X-Amzn-Oidc-Data、X-Amzn-Oidc-Access-Token ヘッダーを受け取ります。

クエリ文字列とヘッダーベースのルーティング

ALBのリスナールールでは、クエリ文字列のパラメータやHTTPヘッダーに基づいてルーティングできるため、きめ細かなリクエストルーティングが可能です。

User-Agent: *Mobile*ヘッダーを検出してモバイル向けに最適化されたバックエンドへルーティングする
カスタムX-API-Tier: premiumヘッダーを確認して、プレミアムAPIリクエストをより高速なターゲットグループへルーティングする
クエリ文字列パラメータ?variant=betaを読み取り、A/Bテストのバリアントを振り分ける

ヘッダーベースのルーティングを使用すると、アプリケーションコードを変更せずに、インフラストラクチャ層でフィーチャーフラグやトラフィック分割を実装できます。

ルールの優先度と評価順序

ルールは優先度の昇順で評価されます。優先度の数値が小さいルールから先に評価されます。最初に一致したルールのアクションが適用され、それ以降のルールは評価されません。デフォルトルールには優先度番号がなく、すべてに一致するルールとして常に最後に評価されます。

ベストプラクティスは、優先度番号を連続した整数ではなく10刻み（10、20、30...）で割り当てることです。こうすると、番号を振り直さずに既存のルールの間へ新しいルールを挿入できます。より具体的なルール（パスとホストヘッダーの組み合わせなど）には、汎用的なルールより小さい番号（高い優先度）を設定します。

# List rules for a listener (shows priorities)
aws elbv2 describe-rules \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --query 'Rules[*].{Priority:Priority,Conditions:Conditions[0].Field,Actions:Actions[0].Type}' \
  --output table

マイクロサービス向けのリスナールール

1つのALBで、リスナールールを使用してマイクロサービスプラットフォーム全体を前段から受けられます。3種類すべての条件タイプを組み合わせた実際の構成例を示します。

優先度10：Host=api.example.com + Path=/v2/* → api-v2ターゲットグループ
優先度20：Host=api.example.com + Path=/v1/* → api-v1ターゲットグループ
優先度30：Host=auth.example.com → auth-serviceターゲットグループ
優先度40：Host=www.example.com + Path=/static/* → CloudFrontリダイレクト
デフォルト：Host=www.example.com → フロントエンドターゲットグループ

この設計により、サービスごとに個別のロードバランサーを用意する必要がなくなり、コストを削減できます。

クイックチェック

このレッスンで扱ったAWS Solutions Architect（SAA-C03）の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、リスナールールがホスト、パス、ヘッダー、メソッド、クエリ文字列に基づいてリクエストをルーティングすること、ルールは優先度順に評価され、最初に一致したルールが適用されること、そしてアクションには転送、リダイレクト、固定レスポンス、Cognito認証があることを学びました。パスベースおよびホストベースのルーティングにより、1つのALBで複数のマイクロサービスを前段から受けられます。次はSSL終端とスティッキーセッションについて学びます。

よくある質問

「リスナールールとパスベースルーティング」レッスンは無料ですか？

はい。「リスナールールとパスベースルーティング」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。

「リスナールールとパスベースルーティング」で何を学びますか？

ALB にリスナールールを記述し、ホストヘッダー、パスパターン、クエリ文字列に基づいてリクエストを異なるターゲットグループへルーティングします。ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

AWS Solutions Architectを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン3/4です。

「リスナールールとパスベースルーティング」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAWS Solutions Architectレッスンでコードを書いて実行できますか？

はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← AWS Solutions Architectに戻る