Terraform で ALB のリスナールールを更新したら “Condition Values per Rule 5” に詰まった話

弊社では、一部サービスの URL ルーティングに AWS ALB (Application Load Balancer) を、
インフラ管理には Terraform を使っています。

先日、ALB のリスナールールをちょっと拡張しようとしただけなのに、Terraform の apply が失敗する事態に遭遇しました。

resource "aws_alb_listener_rule" "this" {
  listener_arn = var.alb_listener_arn

  condition {
    host_header {
      values = var.host_headers
    }
  }

  condition {
    path_pattern {
      values = [
        "${var.base_path}/path1",
        "${var.base_path}/path2",
        "${var.base_path}/path3",
        "${var.base_path}/path4",
        "${var.base_path}/path5",    # この行を追加
      ]
    }
  }
    
  action {
    type = "forward"
    # 以下略    
  }

しかし terraform で apply してみたところエラーとなってしまったのです。

Error: modifying LB Listener Rule: operation error Elastic Load Balancing v2: ModifyRule, https response error StatusCode: 400, RequestID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx, api error ValidationError: A rule can only have '5' condition values

え、5つまで？
ルールの “条件値” が 5 個しか置けないとは…初耳でした。

調べてみたところ、これは ALB のクォータ制限によるものでした。
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html#rules-quotas

Condition Values per Rule 5

しかもこのクオータ制限には更なる注意点があるのです。

---

注意点1:　条件のカウント方法がクセ強い

UI 上で確認してみると、ALB のリスナールールで “条件値” をどう数えるかはこうなります。

特に パス条件 (path_pattern) が厄介で、少しパスが増えるだけですぐ上限に達します。

さらに、パスなどで利用できるワイルドカード * にも制限があり、こちらも最大 6 個まで。

Condition Wildcards per Rule 6

なぜこうなったのか…と思わざるを得ない制限です。

注意点2:　plan で検出できない

Terraform 利用者にとってもっと困るのがこれ。
plan の時点では一切エラーが出ず、apply して初めてエラーになります。

$terraform  plan

～中略～

Plan: 0 to add, 1 to change, 0 to destroy.

------------------------------------------------------------------------

Cost Estimation:

Resources: 0 of 7 estimated
           $0.0/mo +$0.0

実質、apply しないと AWS の制限に引っかかるか分からないため、非常に扱いづらいポイントです。

---

まとめ

• ALB の Listener Rule には Condition Values per Rule = 5 という強めの制限がある

• path_pattern は特に上限に達しやすい

• ワイルドカード * の使用も 6 個まで

• Terraform plan では検出されず、apply 時に初めてエラーになる

ALB で複雑なパス振り分けをしようとすると、今回のように制限にぶつかる可能性があります。
早めに構造を見直すか、必要に応じてリスナールールの分割・Route53 側の工夫などを検討した方が良さそうです。