Amazon ECS Gateway 入門 - 25サービスで ALB を共有するマネージドなイングレスと、設定の落とし穴

2026年10月20日、AWS は Amazon ECS の新機能「ECS Gateway」を発表しました。ECS のサービスへ外からの通信を届ける入口（イングレス）を、ECS が管理してくれる仕組みです。1台の Application Load Balancer（ALB）を最大25のサービスで共有でき、サービスごとに HTTPS の URL が自動で払い出されます。

ECS で小さなサービスを増やしていくと、サービスごとに ALB を立てて料金がかさむか、1台の ALB にリスナールールを手で足していくかの二択になりがちでした。ECS Gateway はその後者を ECS に任せる機能です。この記事では、ECS 開発者ガイドの ECS Gateway のページと API の定義をもとに、仕組みと使い方、注意点を整理します。

まず要点

これまでのやり方と何が変わるか

ECS のサービスを外部に公開するには、これまで次のようなリソースを自分で用意する必要がありました。

• ALB と HTTPS のリスナー
• ACM の証明書と、Route 53 などの DNS レコード
• サービスごとのターゲットグループとリスナールール
• ALB からの通信だけを通すセキュリティグループ

サービスが1つなら大した手間ではありませんが、10、20と増えると、ALB をサービスごとに立てれば台数分の時間料金がかかり、1台を共有すればリスナールールの優先順位や証明書の管理が煩雑になります。

ECS Gateway では、この作業を2つの役割に分けています。AWS のブログの説明では、プラットフォームチームがサブネットやセキュリティグループ、WAF などを決めたゲートウェイを一度作ってクラスターに関連付け、アプリのチームはサービスに「コネクター」という設定を1つ足すだけです。足すと、ECS が証明書、DNS のホスト名、リスナールール、ターゲットグループ、セキュリティグループを用意します。

4つの要素

公式ドキュメントは、ECS Gateway を次の4つの要素で説明しています。

ECS が作るリソースは、ゲートウェイ単位で共有するものと、サービスごとに作るものに分かれます。

作られたリソースはすべて自分のアカウントの中にあり、AmazonECSManaged=true などのタグが付きます。ALB のメトリクスは通常どおり CloudWatch で見られます。ゲートウェイは ALB の作成やルールの変更をするために、IAM のロール（インフラストラクチャロール）を引き受けて動きます。

使い方

公式ドキュメントの手順に沿って、CLI での流れを示します。CLI の例は gateway-managing.html と gateway-connect-service.html に載っているものです。ゲートウェイの操作には新しいサブコマンドが必要なので、AWS CLI は新しい版に更新しておきます（手元にあった aws-cli 2.33.12 には create-gateway がありませんでした）。

1. ゲートウェイを作る

aws ecs create-gateway \
  --name my-gateway \
  --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRoleForGateways \
  --configuration '{"hostSharedAlb": {"scheme": "internet-facing"}}'

--configuration '{"hostSharedAlb": {}}' のように中身を空にすると、すべて既定値になります。CreateGateway は同期的に処理され、ACTIVE の状態で返ってきます。この時点ではまだ ALB は作られず、最初のサービスが接続したときに作られます。サブネットを指定しない場合は、そのリージョンの既定の VPC が使われます（既定の VPC が無い場合は、作成時にサブネットを指定します）。

なお、AWS のブログの CLI の例では HostSharedAlb（先頭が大文字）と書かれていますが、ドキュメントと API の定義では hostSharedAlb です。コピーするときは小文字の方を使ってください。

インフラストラクチャロールには、ecs.amazonaws.com を信頼するロールを用意します。クラスメソッドの検証記事では、AmazonECSInfrastructureRoleForGatewayHostSharedALB という AWS 管理ポリシーを付けたロールで動作を確認しています。

2. クラスターに関連付ける

aws ecs associate-gateway-with-cluster --gateway my-gateway --cluster my-cluster

1つのクラスターに関連付けられるゲートウェイは最大5つです。公開用と内部用の2つを関連付けておく、といった使い方ができます。

3. タスク定義のポートに名前を付ける

コネクターは、タスク定義の portMappings に付けた名前でポートを指定します。

"portMappings": [
  { "name": "web", "containerPort": 80, "protocol": "tcp", "appProtocol": "http" }
]

4. サービスにコネクターを付ける

aws ecs update-service \
  --cluster my-cluster \
  --service my-service \
  --gateway-connectors '[{"portName": "web", "filters": {"accessTypes": ["PRIVATE"]}, "healthCheck": {"healthCheckPath": "/health"}}]'

新しく作るサービスなら create-service に同じ --gateway-connectors を付けます。portName は必須で、タスク定義に無い名前を指定するとリクエストが失敗します。既に自前の ALB に繋いでいるサービスにも、update-service でコネクターを足せます。

5. 払い出された URL を確かめる

aws ecs describe-service-revisions \
  --service-revision-arns <サービスリビジョンの ARN> \
  --query 'serviceRevisions[0].ecsManagedResources.gatewayConnections'

接続ごとに accessType、status（CREATE_IN_PROGRESS / ACTIVE / CREATE_FAILED）、serviceUrl が返ります。クラスメソッドの検証では、URL は https://sv-<32桁の16進数>.ecs.ap-northeast-1.on.aws の形で、ALB が作られるまで12秒ほどでした。

ゲートウェイの設定項目

hostSharedAlb に書ける主な設定です。作成後に変えられない項目があるので、最初に決めておく必要があります。

このほか、ゲートウェイの名前、リスナーのポートとプロトコルも作成後に変更できません。リスナーは HTTPS の443番だけです。

上限値

公式ドキュメントに載っている上限です。

maxAlbCount が既定の10のままだと、1つのゲートウェイで扱えるのは 25 × 10 = 250 サービスまでです。それを超える場合は maxAlbCount を上げます。

注意点

ここからは、ドキュメントを読んでいて気をつけたいと思った点です。

accessTypes を省略すると、内部向けのサービスが公開されることがある

いちばん大事な点です。コネクターの filters.accessTypes は、どのゲートウェイに接続するかを絞る設定です。省略すると、PUBLIC と PRIVATE のどちらのゲートウェイにも接続できる扱いになります。

公式ドキュメントにも「Important」として、インターネットから到達できてはいけないサービスは必ず PRIVATE で絞るように書かれています。絞っていないと、後から誰かがインターネット向けのゲートウェイをクラスターに関連付けたとき、そのサービスは次のデプロイで公開されてしまいます。社内向けの管理画面や API には、最初から "accessTypes": ["PRIVATE"] を書いておくのが安全です。

なお、この絞り込みは接続先を選ぶためのもので、通信のルールやセキュリティグループを設定するものではありません。サービスが接続するゲートウェイは、アクセスの種類に加えて、同じ VPC にあること、サービスが使うすべてのアベイラビリティゾーンにサブネットを持っていることの3つで決まります。

update-gateway は設定を丸ごと置き換える

update-gateway は、渡した設定で既存の設定を置き換えます。変えたい項目だけを渡すと、渡さなかった項目は既定値に戻ります。ドキュメントによると、たとえば次のようになります。

• webACLArn を書かないと WAF が外れる
• accessLogs を書かないとアクセスログが止まる
• maxAlbCount を書かないと10に戻る
• deletionProtection を指定しないと true に、propagateTags は GATEWAY に戻る

また、--infrastructure-role-arn と --configuration は、何を変える場合でも毎回必須です。

設定を変えるときは、describe-gateway で今の設定を取り出し、全項目を書いたうえで変更するのが安全です。Terraform や CloudFormation のように宣言的に管理しているなら問題になりにくいのですが、CLI で手作業で変えるときは要注意です。

ヘルスチェックを変えるとターゲットグループが作り直される

ヘルスチェックの既定は、portName のポートの / に30秒ごとに HTTP でリクエストを送り、5秒以内に 200 が返れば正常、というものです。/ がデータベースを読むような重い処理なら、/health のような軽いパスに変えるようドキュメントは勧めています。

ただし、ヘルスチェックの設定を変えるとターゲットグループが作り直されます。デプロイの方式が ROLLING のサービスでは「Target group properties cannot be changed with ROLLING deployment strategy.」というエラーになるので、ヘルスチェックはサービスを作るときに決めておくのが無難です。

独自ドメインの設定方法が書かれていない

払い出される URL は on.aws のドメインで、ID はランダムです。クラスメソッドの検証では、同じ名前でサービスを作り直すと ID が変わると報告されています。

自分のドメイン（api.example.com など）を使う方法は、2026年11月6日時点のドキュメントには書かれていません。InfoQ の記事も、発表とドキュメントのどちらにも独自ドメインを付ける方法が無いと指摘しています。利用者に直接見せる URL が必要なサービスでは、CloudFront を前に置くなどの構成を自分で検証する必要があり、今の段階では社内向けや、別のサービスから呼ばれる API の方が向いています。

手で変更したリソースは直してくれない

ECS が作った ALB やリスナールールを、コンソールなどから手で変更しても、ECS は元に戻しません。ドキュメントには、ECS の外での変更を修復しないこと、作られたロードバランサーを後からまとめ直さないことが書かれています。作られたリソースには触らず、変更はゲートウェイとコネクターの設定から行います。

削除には順番がある

削除保護が既定で有効なので、ゲートウェイはそのままでは消せません。クラスメソッドの検証では、次の順で削除しています。

1. コネクターを付けたサービスを削除し、ルートと ALB が消えるのを待つ
2. disassociate-gateway-from-cluster でクラスターとの関連付けを外す
3. update-gateway で削除保護を外し、UPDATE_COMPLETE になるのを待つ
4. delete-gateway で削除する

3では、削除保護だけを外したい場合でも --infrastructure-role-arn と --configuration が必要です（ドキュメントの削除手順の例では省略されていますが、更新の節では必須と書かれており、クラスメソッドの検証でも必要でした）。前述のとおり update-gateway は設定を置き換えるので、ここでも今の設定を渡すようにします。

料金の考え方

ECS Gateway 自体に追加料金はかかりません。払うのは、作られた ALB、CloudWatch のログとメトリクス、データ転送など、通常のリソースの料金です（AWS のブログでは ACM の証明書も課金対象の一覧に入っていますが、ドキュメントの料金の節には書かれていません）。

ALB は台数ごとの時間料金と、処理量に応じた LCU の料金がかかります。サービスごとに ALB を立てていた構成なら、時間料金の部分は最大25分の1にまとめられます。一方、LCU は処理量で決まるので、通信量が多いサービスでは共有しても大きくは変わりません。小さなサービスがたくさんある構成ほど効果が大きい、と考えるのがよさそうです。

向いている構成、向いていない構成

ALB を共有すること自体は以前からできましたし、EKS では AWS Load Balancer Controller の IngressGroup で同じようなことができます。ECS Gateway の価値は、リスナールールや証明書、セキュリティグループといった細かい作業をサービスの追加と一緒に自動化してくれる点にあります。負荷分散の方式そのものについては「ロードバランシングのアルゴリズム入門」、HTTPS の仕組みは「TLS 1.3 のハンドシェイク」で解説しています。

まとめ

• ECS Gateway は、ECS のサービスへの入口（ALB、リスナールール、証明書、DNS、セキュリティグループ）を ECS が管理する機能。2026年10月20日に登場し、追加料金は無い
• 1台の ALB を最大25サービスで共有し、サービスごとに on.aws の HTTPS の URL が付く
• 使い方は、ゲートウェイを作ってクラスターに関連付け、サービスに portName を指定したコネクターを付けるだけ
• 内部向けのサービスは必ず accessTypes を PRIVATE にする。省略すると、後から関連付けたインターネット向けのゲートウェイで公開される
• update-gateway は設定を丸ごと置き換える。ヘルスチェックの変更はターゲットグループを作り直す
• 独自ドメインの設定方法は今のところドキュメントに無い

まずは社内向けのサービスや、サービス同士で呼び合う API から試して、独自ドメインへの対応を待つのが現実的だと思います。

参考リンク

• Announcing Amazon ECS Gateway（AWS What's New, 2026-10-20）
• Introducing Amazon ECS Gateway（AWS News Blog）
• Amazon ECS ゲートウェイの紹介（AWS ブログ日本語版）
• Amazon ECS Gateway の概要（ECS 開発者ガイド）
• ゲートウェイの管理（ECS 開発者ガイド）
• サービスをゲートウェイに接続する（ECS 開発者ガイド）
• Elastic Load Balancing の料金（AWS）
• Amazon ECS Gateway Arrives with Generated Hostnames and No Custom Domain Support（InfoQ）
• I Tried Out ECS Gateway, a New Feature of Amazon ECS（DevelopersIO）