ECS Gatewayとは?ALBを25サービスで共有【2026年10月】
ECS でサービスを増やすたびに、ロードバランサー・証明書・セキュリティグループを用意する——その手間を AWS 側で引き受ける機能が出ました。
2026年10月20日(米国時間)、AWS は Amazon ECS の新機能「Amazon ECS Gateway」を発表しました。追加料金はなく、東京を含むすべての商用リージョンで使えます。
ポイントは、ECS サービスの「入口」になる Application Load Balancer(ALB)と関連リソースを、ECS が自動で作って管理することと、1つの ALB を最大25サービスで共有できることです。Kubernetes でいう Ingress(外からの通信の入口の設定)に近い役割を、ECS 自体が持つようになった——という位置づけの発表です。
この記事はこんな人向けです
- Amazon ECS(Fargate など)で Web アプリや API を動かしていて、新しい「ECS Gateway」が何なのか知りたい
- サービスごとに ALB・証明書・セキュリティグループを用意する手間や、ALB の費用を減らしたい
- 東京リージョンでの料金の目安や、使う前に知っておきたい制限を確認したい
ECS Gatewayとは?一言でまとめると
ECS Gateway は、ECS サービスへの HTTPS の入口をまとめて用意・管理する仕組みです。インフラ担当が「ゲートウェイ」を一度作れば、各サービスは設定を1つ足すだけで HTTPS の URL を持てます。
| 項目 | 内容 |
|---|---|
| 発表日 | 2026年10月20日(米国時間。日本時間では10月21日朝) |
| 何をする | ALB・リスナー・ターゲットグループ・セキュリティグループ・証明書・DNS ホスト名を自動で作成・管理 |
| ALB の共有 | 1つの ALB を最大25サービスで共有。足りなければ自動で追加 |
| サービスの URL | https://<ランダムな ID>.ecs.<リージョン>.on.aws |
| 料金 | ECS Gateway 自体は無料。ALB などの実費のみ |
| 対象 | awsvpc ネットワークモードのサービス(Fargate・EC2・ECS Managed Instances) |
| 提供リージョン | すべての商用リージョン(東京・大阪を含む) |

作られたリソースはすべて自分の AWS アカウントの中にあり、ELB や EC2 のコンソールから中身を確認できます。AWS が見えないところで管理する仕組みではありません。
これまでの構成と何が違う?
AWS News Blog は、これまでの課題を「新しいサービスごとに ALB・ACM 証明書・WAF の Web ACL・セキュリティグループを用意し、設定をそろえ続ける必要があった」と説明しています。手作業が増えるほど、デプロイが遅くなり、設定のずれも起きやすくなります。
| 項目 | これまで(自分で ALB を管理) | ECS Gateway |
|---|---|---|
| ALB の用意 | 自分で作成。共有するならリスナールールも自分で管理 | ECS が自動で作成・追加・削除 |
| 証明書・URL | ACM 証明書と DNS を自分で設定 | サービスごとに自動で発行 |
| WAF・アクセスログ | ALB ごとに設定 | ゲートウェイに一度設定すれば全サービスに適用 |
| アプリ側の作業 | ターゲットグループやヘルスチェックの設定 | サービスにコネクタを1つ足すだけ |

役割の分け方もはっきりしています。ゲートウェイを作るのはプラットフォーム(インフラ)チーム、サービスを接続するのはアプリチームです。アプリチームはロードバランサーを作る権限を持たなくても、自分のサービスに HTTPS の入口を付けられます。
何ができる?4つの特徴
① ALB を最大25サービスで共有し、自動で増減
ゲートウェイを作っただけでは、まだ何も作られません。最初のサービスが接続したときに、ECS が ALB を1台作ります。
1台に25サービスが載ると、次のサービスのために2台目の ALB を自動で追加します。サービスがいなくなった ALB は自動で削除されます。1つのゲートウェイが持てる ALB の数は既定で10台(設定で変更可能)なので、既定のままなら最大250サービスです。
② サービスごとに HTTPS の URL と証明書
接続したサービスには、ランダムな ID を含む HTTPS のホスト名が1つずつ付きます。共有の ALB は、このホスト名を見てリクエストを振り分けます(ホストベースのルーティング)。
証明書(ACM)とリスナールール、ターゲットグループもサービスごとに作られるため、あるサービスの設定が他のサービスに混ざることはありません。
③ セキュリティ設定を一か所で管理
ゲートウェイには次の設定をまとめて持たせられ、接続しているすべてのサービスに適用されます。
- AWS WAF の Web ACL(不正なリクエストの遮断)
- アクセスログの保存先(自分の S3 バケット)
- インバウンドのセキュリティグループ(既定では 443 番ポートを全 IP に開放)
- HTTP desync 対策のモード(既定は defensive)
サービス側のセキュリティグループは、ALB からの通信だけを受け付けるように自動で作られます。
④ テスト用ヘッダーで新しいリビジョンを確認
ゲートウェイに「テスト用ヘッダー」(例: x-test-traffic: canary)を設定しておくと、段階的なデプロイ中にそのヘッダー付きのリクエストだけを新しいリビジョンに流せます。本番の利用者には影響を出さずに、新しいバージョンを確認できる仕組みです。
ただし、振り分けはヘッダーの一致だけで、「10%だけ新バージョンに流す」といった割合での指定はできません。
料金:ECS Gateway自体は無料、ALB代は?
ECS Gateway の利用料はかかりません。払うのは、ゲートウェイが作った ALB、CloudWatch のログ・メトリクス、データ転送などの実費です。
AWS の ELB 料金ページの例はバージニア北部の単価なので、東京リージョンの単価は AWS 公式の価格表(Price List API)で確認しました。
| 項目 | 東京(ap-northeast-1) |
|---|---|
| ALB 1台あたり | $0.0243/時 |
| LCU(処理量の単位)あたり | $0.008/時 |
| パブリック IPv4 アドレス1個あたり | $0.005/時 |
| ACM の証明書(エクスポートしないもの) | 無料 |
※ 2026年10月21日時点(AWS Price List API、Amazon VPC 料金、AWS Certificate Manager 料金)。1時間未満は1時間として課金。
ALB の固定費だけで比べると、共有の効果が分かりやすくなります。1か月を730時間として計算すると次のとおりです。
| 構成(東京) | ALB の固定費(月額) |
|---|---|
| 25サービスに ALB を1台ずつ | 約$443.48($17.739 × 25台) |
| ECS Gateway で ALB 1台を共有 | 約$17.74 |
※ IT Picks 編集部の試算。LCU(通信量・接続数に応じた料金)、パブリック IPv4 アドレス、データ転送、CloudWatch は含まない。
LCU は処理したトラフィック(新しい接続数・処理したデータ量など)に応じてかかるため、共有しても LCU の料金が同じように減るとは限りません。効果が大きいのは、アクセスの少ないサービスをたくさん抱えている場合です。
なお、もともと ALB のリスナールールを自分で書いて複数サービスで共有していた場合は、固定費の差は小さく、主なメリットは管理の手間が減ることになります。クラウドの費用が想定を超えないようにする仕組みは、Google Cloud の利用額の上限設定の記事でも取り上げています。
いつから使える?提供リージョンと主な制限
2026年10月20日(米国時間)から利用できます。開発者ガイドに書かれている主な仕様と制限をまとめます。
| 項目 | 内容 |
|---|---|
| 提供リージョン | すべての商用リージョン(東京・大阪を含む) |
| 対応するサービス | awsvpc ネットワークモードのみ(bridge・host は不可) |
| プロトコル | HTTPS(443番ポート)のみ。TCP や UDP の入口には使えない |
| アカウント | ゲートウェイとクラスターは同じアカウントにあること |
| Express Mode | Express Mode のサービスには使えない |
| 主なクォータ | 1クラスターに関連付けられるゲートウェイ 5個、1サービスのコネクタ 1個、1つの ALB に 25サービス、1ゲートウェイの ALB 200台 |
※ 2026年10月21日時点(Amazon ECS 開発者ガイド)。
使う前に知っておきたい注意点もあります。
- サービスはゲートウェイを名前で選べない:クラスターに関連付けられたゲートウェイのうち、条件(公開/非公開・同じ VPC・全 AZ をカバー)に合うすべてに接続されます
- 非公開にしたいサービスは
PRIVATEで絞る:絞っていないと、後からインターネット向けのゲートウェイがクラスターに追加されたとき、次のデプロイで公開されてしまうと開発者ガイドが注意しています - 作成後に変えられない設定がある:名前・公開/非公開・サブネット・IP アドレスタイプなどは変更不可。変えるには新しいゲートウェイを作って移ります
- URL はランダム:サービスを削除して同じ名前で作り直すと、URL が変わります
- ALB を自動で統合しない:サービスが減っても、空きのある ALB が複数台残ることがあります
- ECS が作ったリソースを手で変えない:手動で変更・削除しても ECS は元に戻さず、通信が止まる原因になります
使い方:3ステップで始める
開発者ガイドの手順を要約すると、次の流れです。コンソールのほか、AWS CLI・SDK・CloudFormation でも操作できます。
- IAM ロールを用意する:ECS が ALB などを作るためのロールを作り、AWS 管理ポリシー
AmazonECSInfrastructureRoleForGatewayHostSharedALBを付ける - ゲートウェイを作り、クラスターに関連付ける:
aws ecs create-gatewayでゲートウェイを作り、aws ecs associate-gateway-with-clusterでクラスターにつなぐ - サービスにコネクタを足す:
aws ecs update-serviceに--gateway-connectors '[{"portName": "web"}]'を付ける(portNameはタスク定義で名前を付けたコンテナのポート)
デプロイが終わったら、aws ecs describe-service-revisions の結果にある serviceUrl が、そのサービスの URL です。status が ACTIVE になってから使います。
ヘルスチェックは、既定で / に30秒ごとにリクエストを送り、5秒以内に 200 が返ることを確認します。トップページの表示が重いアプリは、/health のような軽いパスを指定しておくのが無難です。
すでに自分の ALB を使っているサービスも、そのまま移行を試せます。コネクタを足しても既存のロードバランサーは変更されないため、新しい URL で動作を確かめてから古い ALB を外す、という順番で進められます。
Express Modeとの違いは?
ECS には、少ない設定でアプリを公開できる 「Express Mode」 もあります。どちらも ALB を共有し、追加料金はかかりませんが、狙いが違います。
| 項目 | Express Mode | ECS Gateway |
|---|---|---|
| 何をまとめるか | サービス・ALB・オートスケーリング・監視など一式 | 入口(ALB・証明書・URL)だけ |
| 起動タイプ | Fargate ベース | Fargate・EC2・ECS Managed Instances |
| 向いている人 | インフラを意識せず、まずアプリを公開したい | 既存の ECS サービスの入口を、チームのルールに沿ってまとめたい |
開発者ガイドは、ECS Gateway は Express Mode のサービスには使えないとしています。すでに通常の ECS サービスを多数運用しているなら ECS Gateway、新しく小さく始めるなら Express Mode、という使い分けになりそうです。
開発者の反応
発表から1日ほどのため、公開されている検証やコメントはまだほとんどありません。
- Hacker News:AWS News Blog の記事が2026年10月20日に投稿されていますが、10月21日18時ごろの時点でコメントは付いていません(出典)
- 国内の技術ブログ:10月21日夕方の時点で、ECS Gateway を試した日本語の記事は見つかりませんでした。検証記事が出てきたら、ALB の共有によって実際にどのくらい費用が変わったかが注目点になりそうです
IT Picks的な所感
「ECS でサービスが増えるほど ALB まわりの作業と費用が増える」という悩みに、正面から答えた発表だと思います。特に、社内向けの小さな API や管理画面を何十個も ECS で動かしている組織では、ALB の固定費と設定の手間がまとめて減る可能性があります。
もう1つの価値は、インフラ担当とアプリ担当の役割分担を、そのまま仕組みにしたことです。WAF やアクセスログをゲートウェイに一度設定すれば、アプリ側が設定を忘れる心配がなくなります。
一方で、独自ドメインを設定する手順は、今回の発表と開発者ガイドの ECS Gateway の各ページには見当たりません。トラブルシューティングのページは、作り直しでホスト名が変わったら「古いホスト名を指しているクライアントや DNS レコードを更新する」よう案内しています。生成される URL はランダムで変わりうるため、そのまま利用者向けの URL として使うのは難しそうです。社内向けのサービスから試し、独自ドメインまわりの情報を待つのが現実的だと考えています。
今月の AWS では、Web アプリを公開する入口まわりの発表が続いています。サーバーレスで HTTP サーバーをそのまま動かせる Lambda Web Functions の記事もあわせてどうぞ。

なお、サービスが1〜2個の小さなサイトなら、ECS と ALB を組み合わせるより、月額固定の VPS やレンタルサーバーの方が費用も構成も分かりやすい場面が多いはずです。使い分けはこちらの記事で整理しています。

まとめ
Amazon ECS Gateway のポイントをまとめます。
- 発表日:2026年10月20日(米国時間)
- 何が新しい:ECS サービスの入口(ALB・証明書・URL・セキュリティグループ)を ECS が自動で作成・管理
- ALB の共有:1台に最大25サービス、足りなければ自動で追加
- 料金:ECS Gateway 自体は無料。ALB は東京で $0.0243/時+LCU $0.008/時
- 対象:awsvpc ネットワークモードのサービス(Fargate・EC2・ECS Managed Instances)
- 提供リージョン:すべての商用リージョン(東京・大阪を含む)
- 主な制限:HTTPS(443番)のみ、ゲートウェイを名前で選べない、URL はランダム
ECS でサービスを複数動かしているなら、まずは検証用のクラスターにゲートウェイを1つ作り、既存の ALB を残したままコネクタを足して、新しい URL での動作と費用の変化を確かめてみるのがおすすめです。
