---
title: "Amazon ECS Gatewayとは：共有ALBでECSサービスを公開する手順とCLI例【2026年10月】"
url: "https://www.issoh.co.jp/tech/details/19025/"
published: 2026-10-28
updated: 2026-10-28
categories: ["AWS"]
publisher: "株式会社一創"
---

# Amazon ECS Gatewayとは：共有ALBでECSサービスを公開する手順とCLI例【2026年10月】

Amazon ECS Gatewayは、ECSサービスを外部や社内ネットワークへ公開するためのALB・リスナールール・ターゲットグループ・証明書・ホスト名を、ECSが自動で作って管理する機能です。2026年10月20日に発表され、ECSが使えるすべての商用リージョンが提供対象です。サービス側はタスク定義のポート名を1つ指定するだけで、`https://<一意のID>.ecs.<リージョン>.on.aws`形式のHTTPSのURLを受け取ります。本記事では、仕組みと上限値、CLIの手順、運用の注意点、Express Modeとの違いと東京リージョンの料金の目安を、2026年10月28日時点の公式ドキュメントをもとに整理します。

## まとめ：サービスごとのALB作業をゲートウェイ1つに寄せるマネージドingress

ECS Gatewayの中身は、ECSが利用者のアカウント内に作って管理するALBです。プラットフォームチームがゲートウェイを1つ作ってクラスターに関連付けておけば、アプリケーションチームはサービスの作成時か更新時に`--gateway-connectors`を足すだけでHTTPSのURLを得られます。1台のALBを最大25サービスがホスト名で共有するため、サービスごとにALBを立てる構成よりロードバランサーの固定費が下がります。

ゲートウェイ自体は無料で、作られたALBやCloudWatch、データ転送の料金だけがかかります。制約は、HTTPS（443番ポート）しか扱えないこと、`awsvpc`ネットワークモードのサービスに限られること、Express Modeのサービスは接続できないことの3点です。

ECSのサービスをすでに5本以上動かしていて、サービスを足すたびにALBのルールや証明書を手で作っている組織なら、採用する価値があります。逆に、パス単位の振り分けやTCPの公開が必要な構成、ALBの設定を細かく手で調整している構成には向きません。

## Amazon ECS Gatewayの仕組み：ゲートウェイ・コネクタ・ルートの役割

ECS Gatewayは、ゲートウェイ、ゲートウェイコネクタ、ゲートウェイルートの3つの部品でできています。ECSのサービスやタスク定義そのものの基礎は[AWS ECSとは？Dockerコンテナを動かす手順と起動タイプ・料金・EKSとの違い](https://www.issoh.co.jp/tech/details/3870/)で解説しているので、ここではingressの部分に絞ります。

### プラットフォームチームのゲートウェイとアプリ側のコネクタの分担

[公式ドキュメントの概要ページ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/gateway-overview.html)は、利用者を2つの立場に分けています。

| 部品          | 持ち主         | 決めること               |
| ----------- | ----------- | ------------------- |
| ゲートウェイ      | プラットフォームチーム | 公開範囲・サブネット・WAF・ログ   |
| クラスターとの関連付け | プラットフォームチーム | どのクラスターのサービスが使えるか   |
| ゲートウェイコネクタ  | アプリケーションチーム | 受信ポート名・公開範囲・ヘルスチェック |
| ゲートウェイルート   | ECSが自動で作成   | 1本の接続（URLと状態を持つ）    |

ゲートウェイはアカウント単位のリソースで、名前はアカウントとリージョンの中で一意です。アプリケーションチームには`iam:PassRole`もロードバランサーの作成権限も要りません。ALBを作る権限はゲートウェイに渡したインフラロールの側にあるためです。

### 最初の接続で作られる共有ALBとサービスごとの証明書・ホスト名

ゲートウェイを作った時点や、クラスターに関連付けた時点では、何も作られません。最初のサービスが接続したときに、ECSがALB・リスナー・ALB用のセキュリティグループを作り、続けてそのサービス専用のリソースを作ります。

- 共有されるリソース：ALB、ALBのリスナー、ALBのセキュリティグループ
- サービスごとのリソース：ACMの証明書、DNSホスト名、リスナールール、ターゲットグループ、サービス用セキュリティグループ

振り分けはホストベースのルーティングです。作られたリソースには`AmazonECSManaged=true`と、ゲートウェイのARNを値に持つ`aws:ecs:gateway-arn`のタグが付くので、ELBやACMのコンソールでこのタグを検索すれば見つかります。

### 1台のALBに25サービス、既定の上限で250サービスになる計算

上限値は概要ページのクォータ表と、[ゲートウェイの作成と管理のページ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/gateway-managing.html)に載っています。

| 項目                    | 値          |
| --------------------- | ---------- |
| 1台のALBを共有できるサービス数     | 25（変更不可）   |
| ゲートウェイ当たりのALB数        | 既定10・最大200 |
| 1クラスターに関連付けられるゲートウェイ数 | 5          |
| 1ゲートウェイに関連付けられるクラスター数 | 10,000     |
| 1サービスが持てるゲートウェイコネクタ数  | 1          |

1つのゲートウェイが受け持てるサービス数は、25と`maxAlbCount`の掛け算で、既定値なら250です。上限に達した状態で新しいサービスが接続しようとすると、そのサービスのデプロイが失敗します。上限を後から上げても失敗したデプロイは再試行されないため、サービス数が200に近づいた時点で`maxAlbCount`を引き上げておく手順が必要です。ALB側のルール数などのクォータは[ALBのクォータのページ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html)が別に効きます。

## ECS Gatewayを試すCLI手順：IAMロール作成からサービスURL取得まで

手順はAWS CLI v2で書いています。コンソール・SDK・CloudFormationでも同じ操作ができます。例のアカウントID・サブネットID・クラスター名は置き換えてください。

### ECSが引き受けるIAMのインフラロールを管理ポリシー付きで作る手順

ECSがALBや証明書を作るために引き受けるインフラロールを先に用意します。信頼ポリシーで`ecs.amazonaws.com`を許可し、AWS管理ポリシーの[AmazonECSInfrastructureRoleForGatewayHostSharedALB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRoleForGatewayHostSharedALB.html)を付けます。

```
# ECS が引き受けるインフラロールを作る
aws iam create-role \
  --role-name ecsInfrastructureRoleForGateways \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": { "Service": "ecs.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }]
  }'

# ALB・証明書・セキュリティグループを作る権限を付ける
aws iam attach-role-policy \
  --role-name ecsInfrastructureRoleForGateways \
  --policy-arn arn:aws:iam::aws:policy/AmazonECSInfrastructureRoleForGatewayHostSharedALB
```

作った直後は、IAMの反映待ちで次の`create-gateway`が「The infrastructureRoleArn could not be assumed」で失敗することがあります。ドキュメントは1分ほど待って再実行するよう案内しています。ゲートウェイを作る人には、このロールに限定した`iam:PassRole`の許可も必要です。

### create-gatewayでゲートウェイを作りクラスターに関連付ける手順

設定は`configuration`の中の`hostSharedAlb`に書きます。発表ブログのCLI例は`HostSharedAlb`と大文字始まりですが、[CreateGatewayのAPIリファレンス](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API%5FCreateGateway.html)と開発者ガイドは小文字始まりの`hostSharedAlb`です。

```
# インターネット向けのゲートウェイを作る（作った時点ではALBは作られない）
aws ecs create-gateway \
  --name my-gateway \
  --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRoleForGateways \
  --configuration '{
    "hostSharedAlb": {
      "scheme": "internet-facing",
      "networkConfiguration": {
        "subnets": ["subnet-aaa111", "subnet-bbb222", "subnet-ccc333"],
        "ipAddressType": "ipv4"
      }
    }
  }'

# クラスターに関連付ける（既存サービスは次のデプロイまで影響を受けない）
aws ecs associate-gateway-with-cluster \
  --gateway my-gateway \
  --cluster my-cluster

# 関連付けが ACTIVE になったかを見る
aws ecs list-gateway-cluster-associations --gateway my-gateway
```

`scheme`は`internet-facing`（アクセス種別は`PUBLIC`）か`internal`（`PRIVATE`）で、既定はインターネット向けです。サブネットを省くと既定VPCのサブネットが使われるので、サービスを既定VPC以外で動かしている場合は必ず指定します。`ipAddressType`の既定は`dualstack`です。

### タスク定義のポートに名前を付けてgateway-connectorsで接続する

コネクタは、タスク定義の`portMappings`に付けた名前でポートを指します。名前が無いポートは指定できないので、先にタスク定義を確かめます。

```
{
  "family": "my-api",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [{
    "name": "api",
    "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-api:1.0.0",
    "portMappings": [
      { "name": "web", "containerPort": 8080, "protocol": "tcp" }
    ]
  }]
}
```

```
# 既存サービスにコネクタを足す（デプロイが始まる）
aws ecs update-service \
  --cluster my-cluster \
  --service my-api \
  --gateway-connectors '[{
    "portName": "web",
    "healthCheck": { "healthCheckPath": "/health" }
  }]'
```

`portName`だけが必須で、ECSはそのポートの番号とプロトコルからターゲットグループを作ります。ヘルスチェックの既定は、`/`へ30秒ごとにHTTPで要求を送り、5秒以内に200が返るかを見る設定です。`/`がデータベースを読むような重い処理なら、軽い`/health`を指定します。Fargateでの起動タイプの選び方は[AWS Fargateとは？ECSのEC2起動タイプとの違い](https://www.issoh.co.jp/tech/details/3304/)を参照してください。

### サービスのURLとACTIVEの状態をリビジョンの接続情報から確かめる

URLはサービスではなく、サービスのリビジョンに記録されます。[ListServiceDeployments](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API%5FListServiceDeployments.html)の応答に含まれる`targetServiceRevisionArn`でリビジョンを特定し、その接続情報を読みます。

```
# 作成日時が最も新しいデプロイの、向かう先のリビジョンの ARN を取る
REV_ARN=$(aws ecs list-service-deployments \
  --cluster my-cluster --service my-api \
  --query 'sort_by(serviceDeployments, &createdAt)[-1].targetServiceRevisionArn' \
  --output text)

# serviceUrl・accessType・status を表示する
aws ecs describe-service-revisions \
  --service-revision-arns "$REV_ARN" \
  --query 'serviceRevisions[0].ecsManagedResources.gatewayConnections'
```

`status`が`CREATE_IN_PROGRESS`の間はまだ使えません。`ACTIVE`になってから`serviceUrl`へ要求を送ります。`CREATE_FAILED`は待っても直らない失敗なので、ゲートウェイの状態とサブネットの範囲を調べます。ホスト名のIDはランダムで、サービス名から作られるわけではありません。同じ名前でサービスを作り直すとURLが変わります。

## ECS Gatewayの運用で詰まりやすい4つの設定と避け方

ここからは、[サービスの接続のページ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/gateway-connect-service.html)と管理のページに書かれた注意点のうち、実装時に事故につながりやすいものを重い順に並べます。

### PRIVATEで絞らないサービスが後からインターネットへ出る経路

最も危ないのはこの経路です。コネクタは接続先のゲートウェイを名前で選べず、クラスターに関連付いた互換ゲートウェイすべてに接続します。互換の条件は、アクセス種別の一致、同じVPC、サービスが使うすべてのアベイラビリティゾーンをゲートウェイのサブネットが覆っていること、の3つです。

社内向けのサービスで`filters.accessTypes`を省いておくと、後日だれかがインターネット向けのゲートウェイをそのクラスターに関連付けた時点で、次のデプロイから外部に公開されます。外に出してはいけないサービスには、最初から`"filters": { "accessTypes": ["PRIVATE"] }`を書いてください。

### ゲートウェイの更新は省いたWAFやログの設定を消すため現在の値を全部渡す

`update-gateway`は差分ではなく、設定の丸ごとの置き換えです。WAFのWeb ACL（`webACLArn`）やアクセスログ（`accessLogs`）を書き忘れると、それぞれ外れます。`maxAlbCount`は10に、`httpDesync`は`defensive`に戻ります。

`maxAlbCount`だけを上げるつもりでWAFが外れると、配下の全サービスが無防備な状態になるため注意が必要です。更新の前に`aws ecs describe-gateway --gateway my-gateway`で現在の設定を取得し、変えない項目も含めて渡す手順を運用手順書に書いておきます。変更は全ALBへ順に反映され、状態が`UPDATE_COMPLETE`になるまでは新旧の設定が混在します。

### ROLLING戦略ではヘルスチェックを後から変えられない制約

ヘルスチェックを変えるとターゲットグループが作り直されるため、デプロイ戦略が`ROLLING`のサービスでは「Target group properties cannot be changed with ROLLING deployment strategy」で失敗します。最初の接続のときにヘルスチェックのパスを決めておくか、`BLUE_GREEN`か`CANARY`の戦略に切り替えてから変更します。ECSの戦略ごとの動きは[ローリングアップデートとは](https://www.issoh.co.jp/tech/details/16189/)と[ECSネイティブBlue/Greenデプロイの設定手順](https://www.issoh.co.jp/tech/details/7858/)で比較できる内容です。

段階的なデプロイで新しいリビジョンへテスト用の要求を流すヘッダーは、サービスではなくゲートウェイの`testTrafficRules`で決めます。振り分けはヘッダーの一致だけで、割合での振り分けはできません。

### 作成後に変えられないスキーム・サブネット・IPアドレス種別と作り直しの手順

名前・スキーム・サブネット・IPアドレス種別・リスナーのプロトコルとポートは、作成後に変更できません。サブネットはゲートウェイがどのVPCとどのアベイラビリティゾーンを受け持つかを決めるので、後から3つ目のゾーンを足したくなったら、新しいゲートウェイを作ってサービスを移す作業になります。最初から、サービスが使う可能性のあるゾーンをすべて含めておくのが安全です。

ゲートウェイが作ったALBやリスナールールをコンソールで手直しするのも避けます。ECSは外部からの変更を元に戻さず、以後のデプロイや削除が失敗する原因になります。

## Express Mode・自前ALBとの違いとECS Gatewayの料金の目安

ECSには、似た「ALBを自動で作る」仕組みとしてExpress Modeもあります。ここでは、使い分けと費用を整理します。

### Express Modeとの違い：Express Modeのサービスは接続できない

公式ドキュメントは「ゲートウェイはExpress Modeのサービスでは使えない」と明記しています。両者は、自動で作る範囲が違います。

| 比較項目    | ECS Gateway | Express Mode            | 自前のALB     |
| ------- | ----------- | ----------------------- | ---------- |
| 自動で作る範囲 | ingressだけ   | サービス・ALB・Auto Scaling一式 | なし         |
| 対象のサービス | 通常のECSサービス  | Express Modeのサービス       | 通常のECSサービス |
| ALBの共有  | 25サービスで共有   | 25サービスで共有               | 自分で設計      |
| 設定の持ち主  | ゲートウェイに集約   | サービスごと                  | サービスごと     |

Express Modeは、コンテナイメージとIAMロールだけで公開までを済ませる仕組みで、詳しくは[ECS Express Modeとは？使い方・料金・CloudFormation対応](https://www.issoh.co.jp/tech/details/9958/)で解説しています。ECS Gatewayは、タスク定義やデプロイ戦略を自分で書く通常のサービスのまま、ingressだけを預ける仕組みです。

### 東京リージョンでALBの固定費を25サービスで割った月額の目安

ゲートウェイ自体の料金は0円です。費用の大半は作られるALBで、[Elastic Load Balancingの料金](https://aws.amazon.com/elasticloadbalancing/pricing/)のうち、東京リージョンのALBは1時間0.0243ドル、LCUは1時間0.008ドルです（Price List APIの2026年9月11日版で確認）。

| 構成（25サービス・730時間） | ALBの台数 | ALBの固定費（月） |
| ---------------- | ------ | ---------- |
| サービスごとにALBを作る    | 25台    | 約443.5ドル   |
| ECS Gatewayで共有する | 1台     | 約17.7ドル    |

1サービスあたりの固定費は約0.71ドルになります。LCUの料金は処理量に応じてかかるので、共有しても通信量の多いサービスの分は減りません。もう1つの注意は、ECSがALBをまとめ直さないことです。26本目のサービスで2台目のALBが作られ、その後サービスが減っても、半端に埋まったALBが複数残ります。

### 既存ALBのサービスへコネクタを足して並行稼働させる移行の進め方

既存のロードバランサー設定を持つサービスにコネクタを足しても、ECSは既存の設定を消しも変えもしません。1回のデプロイで、旧ALBのURLと新しいゲートウェイのURLの両方から同じサービスへ届く状態になります。

1. ゲートウェイを作り、クラスターに関連付ける
2. `update-service`でコネクタを足し、新しいURLが`ACTIVE`になるのを待つ
3. 新しいURLで動作を確かめ、クライアントの接続先を切り替える
4. 次の`update-service`で旧ALBの`loadBalancers`設定を外し、旧ALBを削除する

API Gatewayの後ろにECSを置いている構成は、移行の対象外にしておきます。API Gatewayの認証や使用量プランをALBへ置き換える判断は[API GatewayとALBの違い](https://www.issoh.co.jp/tech/details/18499/)で別に検討します。

## Amazon ECS Gatewayを採用する構成と見送る構成の判断基準

ECS Gatewayの価値は、ALBの台数の削減よりも、ingressの決まりごとをプラットフォームチームが1か所で持てる点にあります。この観点で線を引きます。

### 採用する構成：サービスが5本以上でHTTPSのAPIを足し続ける組織

ECSで5本以上のHTTPSサービスを動かし、サービスを足すたびにALBのルール・証明書・セキュリティグループを手で作っているなら採用します。WAFとアクセスログをゲートウェイ側に1回設定すれば、以後追加するサービスにも同じ設定が付くため、付け忘れが構造的に起きません。

サービスが1〜2本の構成では、ALBの固定費も手作業もほとんど減らないので、急いで乗り換える必要はありません。

### 見送る構成：パス単位の振り分けやTCPを使う構成と手で調整したALB

次のどれかに当てはまる場合は、2026年10月時点では採用を見送ります。

- 1つのドメインの`/api`と`/admin`を別のサービスへ振り分けている（ゲートウェイはホスト名で振り分ける）
- gRPCの専用ポートやTCP・UDPを公開する（リスナーはHTTPSの443番だけ）
- `bridge`や`host`のネットワークモードのタスクがある
- 別アカウントのクラスターから同じゲートウェイを使いたい
- ALBのリスナールールや属性をサービスごとに手で調整している

今回確認した公式ドキュメントの3ページには、生成されたホスト名の代わりに独自ドメインを割り当てる手順の記載がありません。利用者に見せるURLを自社ドメインで固定したいサービスは、手順が公開されるまで自前のALBで運用を続けるのが無難です。既存のECS構成をどこまでECS Gatewayに寄せるかの設計や移行作業は、一創の[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)で相談を受けています。

## Amazon ECS Gatewayの導入前によく受ける質問と回答

検討の際に出やすい疑問を、公式の記載をもとにまとめました。

### ECS Gatewayは東京リージョンで使えますか？

東京リージョンも提供対象です。[AWS News Blogの発表](https://aws.amazon.com/blogs/aws/introducing-amazon-ecs-gateway-a-fully-managed-ingress-solution-for-ecs-services/)と公式ドキュメントは、提供範囲を「すべての商用リージョン」としており、東京リージョン（ap-northeast-1）も含まれます。起動タイプはEC2・Fargate・ECS Managed Instancesのいずれでも使えます。

### ECS Gateway自体に料金はかかりますか？

かかりません。[Amazon ECSの料金](https://aws.amazon.com/ecs/pricing/)とは別に、サービスを接続したときに作られるALB、CloudWatchのログとメトリクス、データ転送の料金を払います。ゲートウェイを作っただけでサービスを接続していない間は、ALBが作られないので費用も発生しません。

### Kubernetesの「Gateway API」と同じものですか？

別のものです。KubernetesのGateway APIは、クラスター内でingressを宣言するための標準仕様で、実体のロードバランサーはコントローラーの実装によって変わります。ECS GatewayはAWSのECS専用の機能で、実体は必ずALBです。プラットフォームチームとアプリケーションチームで設定を分ける考え方は似ています。Kubernetes側の設定は[Gateway APIとは：Kubernetesの設定手順とHTTPRoute・Ingressからの移行](https://www.issoh.co.jp/tech/details/18889/)で解説しています。

### Service ConnectやCloud Mapとはどう使い分けますか？

受け持つ通信の向きが違います。ECS Gatewayは、クラスターの外（インターネットやVPC内の別システム）からサービスへ入ってくる通信を受けるための仕組みです。Service ConnectやCloud Mapは、サービス同士がお互いを名前で見つけて呼び合うために使います。外部向けのAPIはゲートウェイで公開し、その裏のサービス間の呼び出しはService Connectで結ぶ、という併用が自然です。Cloud Mapの名前空間の考え方は[AWS Cloud Mapとは](https://www.issoh.co.jp/tech/details/15498/)で確認できます。

### サービスを削除して作り直すとURLはどうなりますか？

変わります。ホスト名のIDはランダムに振られ、サービス名から作られないためです。サービスを削除するとゲートウェイルートとそのサービス用のリソースが消え、ALB上の最後のサービスだった場合はALBも削除されます。クライアントにURLを直接書き込むと作り直しのたびに改修が要るので、URLはパラメータストアなどの設定値として持ち、デプロイ後に`serviceUrl`を読み直して更新する運用にします。

## 関連記事

- [AWS ECSとは？Dockerコンテナを動かす手順と起動タイプ・料金・EKSとの違い【2026年10月】](https://www.issoh.co.jp/tech/details/3870/)：タスク定義とサービスの作り方から確認したい場合の入口です。
- [ECS Express Modeとは？使い方・料金・CloudFormation対応とApp Runner移行先を解説【2026年版】](https://www.issoh.co.jp/tech/details/9958/)：ALBを含めてサービス一式を自動で作る、もう1つの仕組みです。
- [AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順](https://www.issoh.co.jp/tech/details/17869/)：ECSを選ぶかどうかの段階から比べられます。
- [ECSネイティブBlue/Greenデプロイの設定手順｜ライフサイクルフック・ロールバック・CodeDeploy移行【2026年版】](https://www.issoh.co.jp/tech/details/7858/)：ゲートウェイのテスト用ヘッダーと組み合わせるデプロイ戦略です。
- [API GatewayとALBの違い：Lambda・ECSの前段をタイムアウト・料金・認証で選ぶ](https://www.issoh.co.jp/tech/details/18499/)：ECSの前段をAPI Gatewayにするか判断するときに役立ちます。

---

出典: [Amazon ECS Gatewayとは：共有ALBでECSサービスを公開する手順とCLI例【2026年10月】](<https://www.issoh.co.jp/tech/details/19025/>)（株式会社一創）