Application Load Balancer(ALB)のリスナールールを使うと、リクエストのさまざまな条件でルーティング先を変更できます。条件に使えるリクエスト要素が豊富に用意されているため、「これだけあればALBだけで柔軟な制御ができそうだ」と思われるかもしれません。
しかし、実際に調べてみると、意外と多くの制限があることがわかりました。本記事では、ALBリスナールール条件の制限事項について詳しく解説します。
なお、本記事は執筆時点(2025年12月)のAWSドキュメントに基づいています。最新の情報については、必ずAWSの公式ドキュメントをご確認ください。
ALBリスナールールにおける「条件」とは
ALBのリスナールールは、受信したリクエストを「どのターゲットへ、どう処理するか」を決める仕組みです。リスナーがリクエストを受けると、優先度(Priority) の順にルールを評価し、 条件(Conditions) に一致したルールの アクション(Actions) を実行します。
ALBのリスナールールで使える条件タイプは次の6つです。
- host-header:Hostヘッダー(ホスト名)で振り分け
- path-pattern:URLパスで振り分け
- http-request-method:HTTPメソッドで振り分け
- http-header:任意のHTTPヘッダー値で振り分け
- query-string:クエリ文字列(key/valueまたはvalue)で振り分け
- source-ip:送信元IPアドレスで振り分け
これらの条件タイプを組み合わせて、柔軟なルーティング制御を実現できます。
条件の基本(Condition basics)を解読する
AWSドキュメントの「リスナールールの条件の種類」ページには、条件の基本的な制約が「条件の基本」という項目に箇条書きで記載されています。
しかし、一読しただけでは理解しづらい内容ですので、「条件の基本」に記載されている制約事項を、実際の動作検証を交えながら1つずつ解説していきます。
ルールに複数記述できる条件タイプ
ルールは複数の条件タイプを組み合わせて記述することで、複合条件を表現できます。
条件タイプには、ルールの中に複数記述できるものと、そうでないものがあります。
1つまでしか設定できない条件タイプ(0 または 1)
host-header(ホストヘッダー)http-request-method(HTTPメソッド)path-pattern(パスパターン)source-ip(送信元IP)
これらはリクエストの基本的要素であり、1つのリクエストに複数の値が存在しないからだと思われます。
同じ条件タイプを複数設定できないというだけなので、異なる条件タイプであれば、複数条件設定することが可能です。
複数の条件タイプを設定した場合、すべて満たす場合に条件一致となります(AND条件)。
複数設定できる条件タイプ(0 以上)
http-header(HTTPヘッダー)query-string(クエリ文字列)
ヘッダーやクエリパラメータは、1つのリクエストに複数の異なる値が含まれるので、条件タイプも複数設定できるようになっています。
こちらも複数設定した場合、すべて満たす場合に条件一致となります(AND条件)。
条件タイプごとの値の制限と評価方法
それぞれの条件タイプで、値の制限と評価方法が異なります。
条件タイプ別:値の評価方法まとめ
| 条件タイプ | 評価対象 | マッチングパターン | 大文字小文字 | ワイルドカード * ? |
|---|---|---|---|---|
| host-header | Hostヘッダー(ホスト名) | 値・正規表現 | 区別しない | 使える |
| http-header | 指定ヘッダーの値 | ヘッダー名:値 / ヘッダー値:値・正規表現 | ヘッダー名:区別しない / ヘッダー値:区別しない | ヘッダー名:使えない / ヘッダー値:使える |
| http-request-method | HTTPメソッド | 値 | 区別する | 使えない |
| path-pattern | URLパス | 値・正規表現 | 区別する | 使える |
| query-string | クエリのkey/valueまたはvalue | 値 | 区別しない | 使える |
| source-ip | 送信元 IP(CIDR) | CIDR 範囲値 | ― | 使えない |
条件値を複数設定してOR条件にできる
1つの条件の中に複数の値を設定することができ、いずれか1つでも満たせば、条件一致となります(OR条件)。
複数のヘッダやクエリ文字列がすべて一致する条件にしたい場合は、それぞれの条件値ごとに条件を作成してください。
ORになる例
[ { "Field": "query-string", "QueryStringConfig": { "Values": [ { "Key": "version", "Value": "v1" }, { "Key": "debug", "Value": "true" } ] } } ]
version=v1 または debug=trueのリクエストが条件一致します。
ANDになる例
[ { "Field": "query-string", "QueryStringConfig": { "Values": [{ "Key": "version", "Value": "v1" }] } }, { "Field": "query-string", "QueryStringConfig": { "Values": [{ "Key": "debug", "Value": "true" }] } } ]
version=v1 かつ debug=trueのリクエストが条件一致します。
ルールあたりの条件値数の上限
1つのルールに複数の条件を設定できますが、それぞれの条件で設定した条件値の数が、合計5つまでに制限されています。
たとえば以下のような条件のルールだと、合計が5になり、これ以上条件の値を追加することはできません。
[ { "Field": "path-pattern", "PathPatternConfig": { "Values": ["/private/*"] } }, { "Field": "source-ip", "SourceIpConfig": { "Values": [ "192.0.2.1/32", "192.0.2.2/32" ] } }, { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": ["*Chrome*", "*Safari*"] } } ]
条件タイプsource-ipを使って接続元制限をしたい場合には、この制限に影響される可能性が高いです。
登録するIPアドレスが多い場合は、ルールを分けることで回避できますが、ルールの管理が大変になります。
L7の条件と組み合わせてIPアドレス制限をしたい場合は、リスナールールではなく、Webサーバー側の設定か、AWS WAFルールでアクセス制限することをおすすめします。
一致評価(Match Evaluations)の謎
「条件の基本」の記述には、条件につき3まで、ルールあたり5つまで 一致評価(Match Evaluations) が設定できるとあります。
一致評価(Match Evaluations) とは何かについては、ここに書かれていること以上の情報がみつからなかったのですが、記述内容から、条件値を評価することなのだと解釈しました。

しかし、実際にルールを作成して条件の設定を試してみると、1つの条件に3つを超えて、値を登録できてしまいました。
AWSコンソールのUIでも「ルールあたり5つまで」のほうだけが有効な制限となっています。

AWS CLIを使って、1つの条件に6つ以上の値をもつ条件を設定しようとすると、A rule can only have '5' condition values and regex valuesというエラーメッセージがでます。
ルールあたりの制限に抵触している旨のメッセージですので、ドキュメントに記述してあるような、1つの条件あたりの制限はされていないようです。
条件
[ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": [ "A", "B", "C", "D", "E", "F" ] } } ]
エラーメッセージ
An error occurred (ValidationError) when calling the ModifyRule operation: A rule can only have '5' condition values and regex values
ルールのサービスクォータには、「ルールあたりの条件値」と「ルールあたりの一致の評価数」があり、いずれも5となっています。
このことから、 一致評価(Match Evaluations) と 条件値(Condition Values) は別の概念として存在していることがわかります。
しかし、AWS CLIを使ってALBのサービスクォータ情報を確認しても、一致評価(Match Evaluations) に該当しそうなものは見つかりませんでした。
~ $ aws elbv2 describe-account-limits \ > --region ap-northeast-1 \ > --query "Limits[?ends_with(Name, '-per-alb-rule')].{Name:Name, Max:Max}" \ > --output table --------------------------------------------- | DescribeAccountLimits | +-----+-------------------------------------+ | Max | Name | +-----+-------------------------------------+ | 5 | condition-values-per-alb-rule | | 6 | condition-wildcards-per-alb-rule | +-----+-------------------------------------+ ~ $ aws elbv2 describe-account-limits \ > --region ap-northeast-1 \ > --query "Limits[?Max=='5'].{Name:Name,Max:Max}" \ > --output table ------------------------------------------------------------------ | DescribeAccountLimits | +-----+----------------------------------------------------------+ | Max | Name | +-----+----------------------------------------------------------+ | 5 | condition-values-per-alb-rule | | 5 | target-groups-per-action-on-application-load-balancer | | 5 | target-groups-per-action-on-network-load-balancer | +-----+----------------------------------------------------------+ ~ $
実際の制限は『ルールあたり5つまで』のみが有効であり、「条件につき3まで」という制限は現時点では機能していないようです。
また、一致評価(Match Evaluations)という概念はドキュメントに記載されているものの、実装上は条件値(Condition Values)の制限のみが適用されている可能性があります。
ワイルドカード文字数制限
ワイルドカード文字の利用数に制限があります。
1 ルールあたり の制限なので、複数の条件を設定している場合は合計のワイルドカード文字で判定されます。
以下の条件例の場合、ワイルドカード文字数は5です。
[ { "Field": "path-pattern", "PathPatternConfig": { "Values": ["/img/*"] } }, { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": ["*Chrome*", "*Safari*"] } } ]
条件タイプの説明ドキュメント(条件の基本)では最大5と記載されていますが、サービスクォータのドキュメントでは6と記載されており、記述に矛盾があります。実際の検証では6が正しいことが確認できました。
ワイルドカード数6のルール登録成功

ワイルドカード数7のルール登録失敗

なお、マッチングパターンが値マッチングを利用している条件がカウント対象です。正規表現パターンは影響しない制約です。
まとめ
本記事では、ALBリスナールールの条件タイプと、その制限事項について解説しました。
ALBリスナールールには6つの条件タイプが用意されており、これらを組み合わせることで柔軟なルーティング制御が可能です。しかし、条件値には厳しめの個数制限があり、どんな条件でも表現できるわけではないことがわかりました。
要件に合わせて、ALBリスナールールで対応するのか、AWS WAFやWebサーバー側の設定で対応するのかを適切に判断することが重要となります。
また、本記事では「条件の基本」を中心に解説しましたが、個別の条件タイプには文字数制限など、さらに細かい制約も設定されています。実際に利用する際は、AWSの公式ドキュメントも合わせてご確認ください。
付録:制限による登録エラーメッセージ集
条件タイプの制限を調査したときに収集したエラーメッセージを紹介します。
1つまでしか設定できない条件タイプを複数設定する
条件
[ { "Field": "host-header", "HostHeaderConfig": { "Values": ["*.example.com"] } }, { "Field": "host-header", "HostHeaderConfig": { "Values": ["example.com"] } } ]
エラーメッセージ
An error occurred (ValidationError) when calling the ModifyRule operation: A rule can only have one 'host-header' condition
評価値に許可されていない文字を使う
条件
[ { "Field": "http-request-method", "HttpRequestMethodConfig": { "Values": ["*CUSTOM-METHOD*"] } } ]
エラーメッセージ
An error occurred (ValidationError) when calling the ModifyRule operation: Condition value '*CUSTOM-METHOD*' contains a character that is not valid
ワイルドカード文字数制限を超える
条件
[ { "Field": "path-pattern", "PathPatternConfig": { "Values": ["/1*/2*/3*"] } }, { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": ["*Chrome*", "*Safari*"] } } ]
エラーメッセージ
An error occurred (ValidationError) when calling the ModifyRule operation: A rule can only have '6' condition wildcards