ALBリスナールール詳細設計 — 条件・アクション・優先度・認証統合

ALBリスナールールの基本構造

ALBリスナールールは「条件」と「アクション」のペアで構成される。優先度順に評価され、最初に一致したルールのアクションが実行される。

リスナー（443/HTTPS）
  ├── ルール1 (優先度10): パス /api/* → ターゲットグループ api-tg
  ├── ルール2 (優先度20): ホスト admin.example.com → ターゲットグループ admin-tg
  ├── ルール3 (優先度30): ヘッダー X-Version: v2 → ターゲットグループ v2-tg
  └── デフォルトルール: → ターゲットグループ default-tg
  
評価: 優先度の低い数値（10 < 20 < 30）から先に評価
デフォルトルールには優先度なし（最後の手段）

条件タイプ

# パスベースのルール
aws elbv2 create-rule \
  --listener-arn arn:... \
  --conditions '[{"Field": "path-pattern", "Values": ["/api/*", "/v1/*"]}]' \
  --actions '[{"Type": "forward", "TargetGroupArn": "arn:..."}]' \
  --priority 10

# ホストベースのルール
aws elbv2 create-rule \
  --listener-arn arn:... \
  --conditions '[{"Field": "host-header", "Values": ["api.example.com"]}]' \
  --actions '[{"Type": "forward", "TargetGroupArn": "arn:..."}]' \
  --priority 20

使用可能な条件フィールド:
  path-pattern: URLパス（例: /api/*, /images/??.jpg）
  host-header:  ホスト名（例: api.example.com, *.example.com）
  http-header:  HTTPヘッダーの値（例: X-API-Version: 2.0）
  http-request-method: HTTPメソッド（GET/POST/PUT等）
  query-string: クエリパラメータ（例: version=2）
  source-ip:    送信元IPアドレス（CIDRブロック）
  
複数条件のAND結合:
  → 複数のField指定で全条件一致時のみルール適用

アクションタイプ

# 転送（複数ターゲットグループへの加重転送）
aws elbv2 create-rule \
  --listener-arn arn:... \
  --conditions '[{"Field": "path-pattern", "Values": ["/new-feature/*"]}]' \
  --actions '[{
    "Type": "forward",
    "ForwardConfig": {
      "TargetGroups": [
        {"TargetGroupArn": "arn:...:v1-tg", "Weight": 80},
        {"TargetGroupArn": "arn:...:v2-tg", "Weight": 20}
      ],
      "StickinessConfig": {"Enabled": true, "DurationSeconds": 3600}
    }
  }]' \
  --priority 30

# リダイレクト（HTTP → HTTPS）
aws elbv2 create-rule \
  --listener-arn arn:...:listener/app/my-alb/xxx/http-listener \
  --conditions '[{"Field": "path-pattern", "Values": ["/*"]}]' \
  --actions '[{
    "Type": "redirect",
    "RedirectConfig": {
      "Protocol": "HTTPS",
      "Port": "443",
      "StatusCode": "HTTP_301"
    }
  }]' \
  --priority 10

# 固定応答（メンテナンス時等）
aws elbv2 create-rule \
  --listener-arn arn:... \
  --conditions '[{"Field": "path-pattern", "Values": ["/maintenance"]}]' \
  --actions '[{
    "Type": "fixed-response",
    "FixedResponseConfig": {
      "StatusCode": "503",
      "ContentType": "application/json",
      "MessageBody": "{\"error\": \"Service under maintenance\"}"
    }
  }]' \
  --priority 5

Cognito認証統合

ALBはCognitoユーザープールと直接統合でき、認証なしのリクエストをCognitoにリダイレクトする。

# Cognito認証ルールの設定
aws elbv2 create-rule \
  --listener-arn arn:... \
  --conditions '[{"Field": "path-pattern", "Values": ["/secure/*"]}]' \
  --actions '[
    {
      "Type": "authenticate-cognito",
      "Order": 1,
      "AuthenticateCognitoConfig": {
        "UserPoolArn": "arn:aws:cognito-idp:ap-northeast-1:123456789012:userpool/ap-northeast-1_xxx",
        "UserPoolClientId": "client-id-xxx",
        "UserPoolDomain": "my-app.auth.ap-northeast-1.amazoncognito.com",
        "SessionTimeout": 3600,
        "OnUnauthenticatedRequest": "authenticate"
      }
    },
    {
      "Type": "forward",
      "Order": 2,
      "TargetGroupArn": "arn:...:secure-tg"
    }
  ]' \
  --priority 10

OnUnauthenticatedRequest の選択肢:
  authenticate: Cognitoログインページへリダイレクト（デフォルト）
  deny: 401を返す
  allow: 未認証でも通す（ルール評価のみ）

OIDC認証統合

Cognito以外のIdP（Okta、Azure AD等）のOIDCを使う場合。

aws elbv2 create-rule \
  --listener-arn arn:... \
  --conditions '[{"Field": "path-pattern", "Values": ["/admin/*"]}]' \
  --actions '[
    {
      "Type": "authenticate-oidc",
      "Order": 1,
      "AuthenticateOidcConfig": {
        "Issuer": "https://login.microsoftonline.com/tenant-id/v2.0",
        "AuthorizationEndpoint": "https://login.microsoftonline.com/tenant-id/oauth2/v2.0/authorize",
        "TokenEndpoint": "https://login.microsoftonline.com/tenant-id/oauth2/v2.0/token",
        "UserInfoEndpoint": "https://graph.microsoft.com/oidc/userinfo",
        "ClientId": "app-client-id",
        "ClientSecret": "app-client-secret",
        "Scope": "openid profile email"
      }
    },
    {"Type": "forward", "Order": 2, "TargetGroupArn": "arn:...:admin-tg"}
  ]' \
  --priority 10

試験頻出ポイント

シナリオ	回答
URLパスで異なるマイクロサービスにルーティング	path-patternルール
複数バックエンドへのカナリアデプロイ	加重転送（ForwardConfig + Weight）
HTTP → HTTPSの強制リダイレクト	redirectアクション（HTTP_301）
未認証ユーザーをCognitoにリダイレクト	authenticate-cognitoアクション
優先度の評価順	数値が小さいルールから評価（デフォルトは最後）

まとめ

ALBリスナールールの条件はパス・ホスト・ヘッダー・クエリ文字列等を組み合わせて柔軟なルーティングが可能だ。加重転送でカナリアデプロイ、Cognito/OIDC統合で認証オフロードを実現できる。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感