Application Load Balancer (ALB) の1つのリスナールールのルール条件タイプごとの条件数を確認してみた

結局何個条件を付けられるんだ

こんにちは、のんピ(@non____97)です。

皆さんはALBの1つのリスナールールのルール条件タイプごとの条件数の上限が気になったことはありますか? 私はあります。

AWS公式ドキュメントには以下のような記載がありました。

抜粋 : Application Load Balancer のクォータ - Elastic Load Balancing

「ルールあたりの条件値」がルール条件タイプそれぞれ5つずつなのかどうなのか、それとも全てのルール条件タイプで5つまでなのか確信が持てませんでした。

おそらく前者なような気はしますが、普段リスナールールで大量ので条件式を扱う場面がない and 大量の条件式がある大量のルールを見たくなってみたので検証してみます。

いきなりまとめ

• 1つのリスナールールの条件は全てのルール条件タイプで5つまで
  • 例) IPアドレスの条件が4つある場合、ホストヘッダーの条件は1つまで
• ルール条件が5つで足りない場合は複数のリスナールールで対応も可能
  • ただし、複数の条件タイプを組み合わせる場合、条件式5つを超えない範囲で条件タイプの組み合わせを大量に作成する必要があるため大変
• ルール数に応じて課金が発生するため大量のリスナールールを作成するのは注意が必要

検証環境

検証環境は以下の通りです。

検証環境はAWS CDKでデプロイします。使用したコードは以下リポジトリに保存しています。

とりあえず1つのリスナールールに送信元IPアドレスを5個ほど設定してみます。

./lib/constructs/alb.ts

   const ipAddresses = [];
    for (let i = 0; i <= 4; i++) {
      ipAddresses.push(`10.0.1.${i}/32`);
    }

    listener.addTargets("Targets", {
      priority: 1,
      conditions: [
        cdk.aws_elasticloadbalancingv2.ListenerCondition.sourceIps(ipAddresses),
      ],
      targets: [target],
      port: 80,
    });

ALBのリスナールールの確認

作成されたALBのリスナールールを確認します。

優先度1のリスナールールが作成されていますね。

リスナールールの編集をしようとしてみます。

条件の追加がグレーアウトしちゃっていますね。

送信元 IPを選択した状態で編集をクリックします。

このルールの 5 条件値の制限に達しました。と表示されています。

ということで、「ルールあたりの条件値」は全てのルール条件タイプで5つまでで、ルール条件タイプそれぞれ5つではないことが分かりました。

ALBのリスナールール数を増やして確認してみる

リスナールールに設定できる条件が5つだと足りない場面もあると思います。

その場合は、複数のリスナールールを用意することで対応できる場面もあるかと予想します。特に今回の例に挙げた単純にIPアドレスによってターゲットグループを振り分ける場合は、リスナールール毎に最大5つIPアドレス(CIDR形式)を設定して、必要な分のリスナールールを用意することで対応できそうです。

ただし、「大量のIPアドレスと大量のパスのAND条件の場合は、このターゲットグループに転送する」というような複数の条件タイプを組み合わせる場合は大量リスナー作戦は骨が折れます。条件式5つを超えない範囲で、条件タイプの組み合わせを大量に作成する必要があるためです。

また、大量のリスナールールを作成すると、ALBの料金に響いてくる可能性もあります。

ALBの料金はALBの稼働時間とLCU時間の合算です。

このLCUは以下ディメンションの最も高いもので請求されます。

• 1秒あたり新規接続数
• アクティブな接続数
• ALBで処理されたHTTP(S)リクエストとレスポンスのバイト数(GB)
• ALBで処理されたルールの数とリクエストレートの積 ※ 最初に処理される10個のルールは無料

普段はマッチしない条件が大量にあり、都度デフォルトルールにマッチする場合はそれなりのルール評価数になるのではないかと想像します。

実際に大量のリスナールールを見たい気分なので、リスナールールを20個作ってみます。

./lib/constructs/alb.ts

    for (let i = 0; i < 20; i++) {
      listener.addTargets(`Targets${i}`, {
        priority: i + 2,
        conditions: [
          cdk.aws_elasticloadbalancingv2.ListenerCondition.sourceIps(
            ipAddresses
          ),
        ],
        targets: [target],
        port: 80,
      });
    }

デプロイ後のリスナールールは一覧は以下の通りです。

なかなか良い眺めですね。

この調子でリスナールールを100個作ってみます。

すると、デプロイ途中にInvalid request provided: AWS::ElasticLoadBalancingV2::ListenerRule Validation exceptionとエラーになってしまいました。

CloudTrailを確認するとCreateRuleがThrottlingExceptionでエラーになってしまいました。一度に大量のリソースを作成する場合は注意が必要ですね。

クォーターに気をつけながらリスナールールを使いこなそう

ALBの1つのリスナールールのルール条件タイプごとの条件数を確認してみました。

1つのリスナールールだと対応しきれない場合は複数のリスナールールを使いこなせば良さそうですね。クォーターに気をつけながら使いこなしましょう。特に1つのALBに大量のテナントをぶら下げていると、その分リスナールール数も多くなり、どれがどれだか分からなくなりそうです。

また、リスナールールは非常に便利です。IPアドレス以外にもホストヘッダーやHTTPヘッダーなどでも条件の定義が可能です。

ただし、あまりにも複雑なことをリスナールールのみで実現しようとすると運用負荷が高まることも考えられます。そのような場合はリスナールールの想定された使い方ではないと思います。代替案がないか検討をしましょう。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!