ECS Express Mode で ALB が作成される条件を調べてみた

ECS タスク定義や ECS サービスなどの多くの設定を意識することなく、簡単にコンテナアプリケーションをデプロイ可能な ECS Express Mode が登場しました。

https://dev.classmethod.jp/articles/ecs-express-mode/

ECS Express Mode の特徴として、ホストベースルーティングを活用して ALB を複数サービスで共有することでコストを低減可能なことが挙げられます。
この際、最大 25 の ECS サービスが ALB を共有するようです。

Application Load Balancer の共有 – 作成された ALB は、ホストヘッダーベースのリスナールールを使用して最大 25 の ECS サービス間で自動的に共有されます。これにより、ALB のコストを大幅に分散できます。
https://aws.amazon.com/jp/blogs/news/build-production-ready-applications-without-infrastructure-complexity-using-amazon-ecs-express-mode/

この ALB 共有は ECS Express Mode が自動で行い、ユーザー側で ECS サービス作成時に利用する ALB を選択する必要はありません。
ユーザー側があまり深く考えなくてもホストゾーンルーティングで上手く ALB を共有できるというのはとても便利ですね。
とはいえ、ユーザー側で ALB が作成される条件を知りたい方もいると思います。
今回は ECS Express Mode はどういう条件で ALB を新規作成して、どのような場合は ALB の共有を試みようとするのかを調べてみました。

最初に結果まとめ

最初に結果をまとめておきます。

• ECS Express Mode は可能な限り、ALB を共有させようとする
  • 例外は下記
    • パブリックサブネットを選択した場合とプライベートサブネットを選択した場合
    • VPC が違う場合
    • 条件を満たした ALB を既に 25 個の ECS サービスが共有している場合

試してみる

ネットワーク設定を指定せずに ECS Express Mode で ECS サービスを作成して、そこに条件を変えた ECS サービスを追加します。

※ 東京リージョンで ECS Express Mode ネットワーク設定を指定しない場合、デフォルト VPC に存在する 3 つのサブネットが指定されます。

ECS サービスを追加した際、ALB が新規作成されるか共有されるかを確かめてみます。

ALB が新規作成されずに共有されたパターン

最初に ALB が新規されずに既存の物が共有されたケースを列挙します。

最初に作成した ECS サービスとは別の ECS クラスターを明示的に指定して作成

ALB は新規作成されず、共有されました。

クラスター構成はもちろん ALB とは関係ありません。

最初に作成した ECS サービスとは別のセキュリティグループを明示的に指定して作成

ALB は新規作成されず、共有されました。

ここで指定するセキュリティグループはあくまで ECS サービスのセキュリティグループなので、ALB には関係無いということでしょう。

デフォルト VPC に存在する 3 サブネットの内、2 つを明示的に指定して作成

ALB は新規作成されず、共有されました。

ちなみに、最初に 2AZ に跨る 2 つのサブネットを指定した場合、ALB はそれらのサブネットに作成されます。

ALB が利用するパブリック IP 料金を少しでも節約したい場合は最初に作成する ECS サービスで明示的に 2 AZ 分を指定しておく必要がありますね。
AZ 障害の時に 1 AZ を切り離せなくはなりますが、大規模障害の際は諦めても良いならコストメリットを重視して 2AZ にしてしまうのも良いと思います。

最初に作成した ECS サービスとは別のサブネットを 3 つ指定して作成

予めサブネットを 3 つ追加して指定してみましたが、ALB は共有されました。

あくまで、最初に ECS Express Mode で ECS サービスを作成する際に選択するサブネットが ALB の配置先ということですね。

ALB が新規作成されたパターン

続いて、ALB が共有されずに新規作成されたパターンです。

最初に作成した VPC と別の VPC を指定

最初に作成した ECS サービスとは全く別の VPC に存在するサブネットを指定してみました。

もちろん ALB は新規作成されました。

VPC ごとに最初に Express Mode で ECS サービスを作成すると ALB が作成されます。

パブリックサブネットを利用した ECS サービスしか存在しない場合に、プライベートサブネットを利用した ECS サービスを追加した場合

これもさすがに作成されますね。
ALB は Internet-facing か Internal のどちらかにしかなり得ないので当然と言えるでしょう。

ちなみに、ECS Express Mode で作成された ECS サービス が Internet-facing の ALB に関連付けられているか、Internal な ALB に関連付けられているかは、下記コマンドで取得可能です。

aws ecs describe-express-gateway-service \
  --service-arn $ECS_SERVICE_ARN \
  --query 'service.activeConfigurations[0].ingressPaths[0].accessType'

Internet-facing の ALB に関連付けられていると "PUBLIC" が、 Internal な ALB に関連付けられているか "PRIVATE" が返却されます。

既に 25 個の ECS サービスが ALB を共有している場合

事前に ECS Express Mode で 25 個の ECS サービスを作成しておきます。

ALB は全ての ECS サービスで共有され、ホストベースルーティングが利用されます。
404 を返却するデフォルトアクションが存在するのでこの時点で 26 個のリスナールールが存在します。

証明書もデフォルト含めて 25 個分設定されています。

この状態で新しく ECS サービスを作成すると、ALB が新規作成されました。

AWS ブログに記載されていた通り、ALB を共有する ECS サービスは 25 個までのようです。

基盤となるサービス側のサービスクォータに抵触する場合は？

ECS Express Mode は単に ALB や ECS サービスを簡単に作成するためのサービスです。
ユーザーの AWS アカウントに各種リソースがデプロイされる性質から、作成されるサービス自体のサービスクォータも意識する必要があるはずです。
例えばカスタムドメイン対応で追加の証明書を ALB リスナーに取り込んでいた場合、 ALB あたりの証明書のデフォルト値である 25 を超過する可能性があります。

https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-limits.html

ALB でカスタムドメイン対応を行う場合は、下記作業を行う必要があります。

• ACM 発行
• ACM の ALB リスナーへのインポート
• ホストベースルーティングの書き換え
• Route 53 レコードの追加

使わなくなった証明書を ECS Express Mode が削除してくれるわけでは無いので、カスタムドメイン対応を行っていると ECS サービスを 25 個作成する前にリスナー証明書が 25 個に達します。

この状態で新たに ECS サービスを作成してみると、下記のようにコンソール上は作成完了扱いになりました。

ただし、上手く HTTPS 通信できません。

% curl -v https://sa-212eeb2c7d74456199edf261ed05b43d.ecs.ap-northeast-1.on.aws/
* Host sa-212eeb2c7d74456199edf261ed05b43d.ecs.ap-northeast-1.on.aws:443 was resolved.
* IPv6: (none)
* IPv4: 52.196.168.183, 52.199.70.119, 52.196.248.191
*   Trying 52.196.168.183:443...
* Connected to sa-212eeb2c7d74456199edf261ed05b43d.ecs.ap-northeast-1.on.aws (52.196.168.183) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=sa-2bd70c989b234ea18ba1fce69f65b87e.ecs.ap-northeast-1.on.aws
*  start date: Nov 29 00:00:00 2025 GMT
*  expire date: Dec 28 23:59:59 2026 GMT
*  subjectAltName does not match host name sa-212eeb2c7d74456199edf261ed05b43d.ecs.ap-northeast-1.on.aws
* SSL: no alternative certificate subject name matches target host name 'sa-212eeb2c7d74456199edf261ed05b43d.ecs.ap-northeast-1.on.aws'
* Closing connection
* TLSv1.2 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name 'sa-212eeb2c7d74456199edf261ed05b43d.ecs.ap-northeast-1.on.aws'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

リスナールールは追加されています。

しかし、証明書が追加されていません。

CloudTrail から確認すると AddListenerCertificates が失敗していることがわかります。
サービスクォータを超過しているので当然ですね。

このようなケースを防ぐためにカスタムドメインを利用する場合は事前にサービスクォータに余裕を持たせておくと良いでしょう。
不要になった証明書を都度消しても良いかなと思ったのですが、単純に面倒ですし、ドキュメントにもサービスクォータ引き上げ申請を出すように記載されていたので、こちらで良いかなと思います。

If you are adding many certificates to your Application Load Balancer or servicing many Express Mode services from your Application Load Balancer, you may want to consider raising the service limit for certificates on the Application Load Balancer.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-advanced-customization.html

最後に

ECS Express Mode はどういう条件で ALB を新規作成して、どのような場合は ALB の共有を試みようとするのかを調べてみた所、下記結果になりました。

• ECS Express Mode は可能な限り、ALB を共有させようとする
  • 例外は下記
    • パブリックサブネットを選択した場合とプライベートサブネットを選択した場合
    • VPC が違う場合
    • 条件を満たした ALB を既に 25 個の ECS サービスが共有している場合

また、基盤となるサービスのクォータは別途考慮する必要があります。
あまり深く考えなくても良い感じに作成してくれるのがメリットではありますが、ついつい細かい所が気になってしまいますね。