AWSは2026年10月20日、ECSサービスの入口となるApplication Load Balancer（ALB）などを作成・管理するAmazon ECS Gatewayを発表しました（AWS公式発表）[20]。

サービスを公開する際は、ロードバランサーの転送設定、証明書、セキュリティグループなどを構成し、サービスの更新後も関連リソースの設定の整合性を保つ必要があります。AWSが課題として挙げるのは、この作業によるデプロイの遅れと、サービスごとの設定が組織の標準からずれる設定ドリフトです[1]。

従来のALBにも、ホスト名やパスの条件で異なるターゲットグループへ振り分ける機能があります。ALBを複数サービスで共有する構成は既に可能でした（ALBの公式概要）。ECS Gatewayでは、Gatewayとサービスの設定をもとに、ECSがALBや接続用リソースの作成・接続・追加・撤去を管理します[2]。

ECSが引き受ける作成・接続・撤去

Gatewayは、ネットワークの共通設定を持つアカウントレベルのリソースです。作成しただけではALBなどは作られず、サービスがgateway connectorを通じて接続した時点で基盤の作成が始まります。ECSは、あらかじめ指定されたIAMインフラロールを引き受けて、利用者のAWSアカウント内のリソースを管理します[2]。

担当設定・管理する主な内容
基盤担当Gatewayのサブネット、セキュリティグループ、リスナー、WAF Web ACLなどの共通設定と、ECSクラスターへの関連付け
アプリ担当サービス作成・更新時のgateway connector、ポート名、アクセス種別のフィルター、ヘルスチェック
ECS接続に必要なALBやサービス用リソースの作成・管理

基盤担当の設定範囲と、アプリ担当がサービス側で指定する内容は、公式発表で分けて説明されています[3, 4]。

接続ごとにECSが用意するのは、ACM証明書、一意なDNSホスト名、そのホスト名からサービスのターゲットグループへ送るリスナールール、ターゲットグループ、サービス用セキュリティグループです。このセキュリティグループは、ALBのセキュリティグループからのインバウンド通信だけを許可します[5]。

GatewayはホストベースルーティングでALBを共有し、1台に最大25サービスを収容します[12]。リクエストのホスト名によって転送先を分ける構成です。ECSは最初のサービス接続時にALBを作り、収容容量に応じて追加します。サービスを削除すると、そのGateway接続・ルート・サービス用リソースを片付け、最後のルートがなくなったALBも撤去します[6]。

Service Connect・Express Modeとの役割の違い

ECS Gatewayは、インターネット向け、またはVPC内部向けのALBを通じてサービスへのトラフィックを受け付けます。一方、Service Connectは、同じnamespaceに属するECSサービス間の通信を扱います。短い名前によるサービス検出と、サービスメッシュを提供する機能です[9]。

例えば、Webサービスへの入口をALBで用意し、そのWebサービスからバックエンドを短い名前で呼び出す構成では、入口とサービス間通信を分けて設計できます。Service Connectの公式文書も、namespace外やECS外のアプリケーションから接続する場合には、別の接続方式が必要と説明しています。

新規サービスの構築も含めて簡略化したい場合は、ECS Express Modeも比較対象です。公式文書は、コンテナイメージとタスク実行ロール、インフラロールを指定すると、FargateベースのECSサービス、SSL/TLS付きロードバランサー、自動スケーリング、監視、ネットワークを構成すると説明しています。ECS Gatewayは対応する既存サービスにもconnectorを追加できるため、サービスの構築を簡略化する用途と、入口の管理をまとめる用途を分けて検討できます[14]。

接続条件と容量を確かめる

公式発表は、ECSを提供している全商用AWSリージョンでの利用を案内しています（「Now available」）。

Gatewayを使うサービスには、awsvpcネットワークモードが必要です。公式発表はEC2、Fargate、ECS Managed Instancesでの利用を案内しています。接続先となるGatewayは、サービスのconnectorに指定したアクセス種別に適合し、同じVPC内にあり、サービスの設定サブネットが使うすべてのAvailability Zone（AZ）をカバーする必要があります[10]。

サービスのAZはGatewayのAZの範囲に含まれている必要があり、AWSは両者で同じAZ構成にすることを勧めています。GatewayのALBは、自分のサブネットがあるAZのタスクだけへルーティングします（公式発表の「Networking」）。

ECSはサービスの各デプロイ時にクラスターのGateway関連付けを再評価し、互換性のあるすべてのGatewayへ接続します。関連付けが解除されていれば、そのGatewayから切断してルートを削除します[8]。そのため、基盤側で関連付けを変更する運用には、サービス側のデプロイ計画も含める必要があります。

点検する項目公式発表が示す条件
ネットワークawsvpc、アクセス種別の一致、同一VPC、サービスの全AZをGatewayがカバー
作成後に変更できない設定名前、scheme、VPC、サブネット、IPアドレスタイプ、リスナーのプロトコルとポート
ALBの共有上限1台あたり最大25サービス
ALBの最大数maxAlbCountの既定クォータはGatewayあたり10台。上限到達時に既存ALBにも空きがなければデプロイ失敗

変更できない設定は作成前に決め、既存環境のVPC・サブネット構成と照合してください[11]。容量計画では、Gateway内のALB総数に対する上限と、既存ALBの空き容量を分けて確認してください[13]。

基盤担当は、Gatewayをどのクラスターに関連付けるかで利用範囲を定めます。公式発表の関連付け上限は、Gateway 1つあたり最大10,000クラスター、1クラスターあたり最大5 Gatewayです。AWSは追加の制御として、特定クラスターへサービスをデプロイする権限をIAMポリシーで制限する方法も挙げています[7]。

既存経路を残して移行し、共有ALBを監視する

既存ALBを使うサービスは、UpdateServiceでgateway connectorを追加できます。既存の入口とGatewayの入口を並行して使えるため、Gateway側の接続を検証してから、従来のロードバランサー設定を外す手順が案内されています[14]。

移行時は、新しいホスト名での疎通、ヘルスチェック、必要なアクセス制御を確認し、既存の経路を切り離す時点を決めるとよいでしょう。これは本記事での点検案です。公式発表が説明する並行稼働をもとに、利用中のサービスに合わせて切り替えを検証します。

監視も、ALB全体と個別サービスに分けます。公式発表はCloudWatchのLoadBalancerディメンションで共有ALB全体を、TargetGroupディメンションでサービス別トラフィックを見る方法を示しています[15]。さらにdescribe-target-healthでターゲットの状態を調べ、HealthyHostCount、TargetResponseTime、HTTPCode_Target_5XX_Countなどを監視項目として挙げています。

費用を見積もる

費用はGatewayと関連リソースを分けて見積もります。Gateway自体に追加料金はありませんが[16]、ALBの稼働時間・LCU使用量は別に課金されます。データ転送には利用条件に応じた料金がかかり、ALBがパブリックIPv4アドレスを使う構成では、そのアドレス料金も発生します[17]。CloudWatchのログ・メトリクスも利用に応じた料金の対象で[18]、WAFを設定する場合はWeb ACL・ルール・リクエスト数などに基づく料金が加わります[19]。ACM証明書についても、利用する区分に応じて公式料金表を確認します。

ALBを共有できることだけで費用削減幅は決まりません。導入前には、既に使っているALBの構成、トラフィック量、監視や保護機能の利用量を合わせて比較してください。