ECS Express Modeとは？使い方・料金・CloudFormation対応とApp Runner移行先を解説【2026年版】

Amazon ECS Express Modeは、コンテナ画像と2つのIAMロールを渡すだけで、Fargate・Application Load Balancer（ALB）・オートスケーリング・HTTPSまで一式を自動構成するECSの新しい起動モードだ。2025年12月（re:Invent 2025で発表）に一般提供が始まり、2026年4月30日に新規受付を停止したAWS App Runnerの公式な移行先としてAWSが推奨している。本記事では必須入力と自動生成リソース、コンソール・CLI・CloudFormation/CDK/Terraformでのデプロイ方法、カナリアデプロイの既定動作、料金、標準ECSやApp Runnerとの使い分けまでを公式仕様に沿って整理する。

まとめ：ECS Express Modeの要点

• 必要な入力は3つ：コンテナ画像・タスク実行ロール・インフラロール。残りはAWSが自動構成する。
• 自動生成される主なリソース：ECS on Fargate、ALB（最大25サービスで共有）、Auto Scaling、CloudWatch Logs、AWS提供ドメインとACM証明書によるHTTPS。
• IaC対応：CloudFormation（AWS::ECS::ExpressGatewayService）・CDK（L1構築のみ）・Terraformで管理できる。
• デプロイ戦略：カナリア固定。5%へ振り分け→3分の待機（bake time）→100%。エラー増加時は自動ロールバック。
• 料金：Express Mode自体は追加料金なし。作成されたFargateやALBなど下層リソースの従量課金のみ。
• 位置づけ：App Runnerの手軽さを保ちつつECSの機能にアクセスできる。App Runnerからの移行先に適する。

以下、それぞれを実際の設定項目とコマンドに落として解説する。

ECS Express Modeとは：App Runnerの後継として登場した経緯

ECS Express Modeは、コンテナをすぐ公開したい開発者向けにAWSが用意した簡易デプロイ経路だ。従来のECSはクラスター・タスク定義・サービス・ALB・ターゲットグループ・セキュリティグループを個別に設計する必要があり、初回構築の負担が大きかった。Express Modeはこの設計判断をAWSのベストプラクティスに委ね、単一のAPI呼び出しで本番相当のスタックを立ち上げる。

背景にはAWS App Runnerの縮小がある。App Runnerは2026年4月30日に新規受付を停止してメンテナンスステータスへ移行し、AWSは代替としてECS Express Modeを名指しで推奨している。App Runnerの「画像を渡すだけ」という手軽さを引き継ぎつつ、Fargateやオートスケーリングなど広範なECS機能へそのまま接続できる点が移行先として選ばれる理由だ。App Runner側の終了スケジュールと移行判断はAWS App Runnerは終了する？2026年の新規受付停止・メンテナンスモード移行と移行先を解説で整理している。

3つの入力と自動構成されるAWSリソース

必要な入力はコンテナ画像と2つのIAMロールだけ

Express Modeがユーザーに求める入力は次の3点に絞られている。

• コンテナ画像URI：Amazon ECRに置いたアプリケーションイメージ。
• タスク実行ロール：アプリの実行時にコンテナが必要とする権限（ECRからのpullやログ出力など）。
• インフラロール：ECSがユーザーに代わってALBやAuto Scalingなどのリソースを作成するための権限。

この3つを渡すと、残りのネットワーク・ロードバランサー・スケーリング・監視はすべてAWS側が既定値で組み立てる。ポート番号やヘルスチェックパスなどは任意で上書きできるが、指定しなければ本番向けの標準構成が適用される。

自動生成されるリソース一覧

1回の作成操作で、以下のリソースがユーザー自身のアカウント内に作られる。マネージドサービスのように隠蔽されるのではなく、生成物が可視化されて自分で管理・調整できるのが特徴だ。

ALBが最大25サービスで共有される点は料金に直結する。サービスごとにALBを立てないため、小規模アプリを多数動かす構成ほどロードバランサー費用の分担効果が大きい。Fargateの課金や起動タイプの考え方はAWS Fargateとは？EC2との違い・料金をわかりやすく解説【2026年版】を参照してほしい。

使い方：コンソールとCLIでのデプロイ手順

マネジメントコンソールでの作成

コンソールからの手順は、事前にECRへ画像をpushし、実行ロールとインフラロールを用意しておけば数ステップで完結する。

• Amazon ECSコンソールで「Create」を選び、Express Modeのサービス作成に進む。
• コンテナ画像URIと2つのIAMロール（実行ロール・インフラロール）を指定する。
• ポートやヘルスチェックパスなどを変えたい場合のみ「Additional configurations」を展開して上書きする。
• 作成を実行すると、Fargateタスク・ALB・HTTPS付きの公開URLまでが自動でプロビジョニングされる。

公開URLは作成完了時に払い出され、そのままHTTPSでアクセスできる。動作確認後は独自ドメインへ差し替える運用が一般的だ。

AWS CLIでの作成と更新

スクリプト化や再現性を重視するならCLIが向く。作成はcreate-express-gateway-serviceで行い、更新はupdate-express-gateway-serviceで新しい画像URIを渡す。作成時は--infrastructure-role-arnだけが必須で、更新時は作成で払い出された--service-arnで対象を指定する。

# サービスの新規作成（--infrastructure-role-arn が必須）
aws ecs create-express-gateway-service \
  --service-name my-app \
  --primary-container image=123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest \
  --execution-role-arn arn:aws:iam::123456789012:role/my-task-execution-role \
  --infrastructure-role-arn arn:aws:iam::123456789012:role/my-express-infra-role

# 画像更新（作成時に返された serviceArn を指定。カナリアで段階反映される）
aws ecs update-express-gateway-service \
  --service-arn "$SERVICE_ARN" \
  --primary-container image=123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v2

更新コマンドを実行すると、後述のカナリアデプロイが自動で走り、問題があれば自動でロールバックされる。手動でトラフィック切り替えを管理する必要はない。なお作成時にサービス名を省くとECSが一意な名前を自動生成し、サービス名は作成後に変更できない。

CloudFormation・CDK・TerraformでのIaC対応

Express Modeはコンソール専用ではなく、Infrastructure as Code（IaC）にも対応している。CloudFormation・CDK・Terraformのいずれからでも定義でき、既存のパイプラインに組み込める。「ecs express mode cloudformation」「ecs express mode cdk」で調べる場合は、まず土台となるCloudFormationリソースを押さえるとよい。

CloudFormationリソース AWS::ECS::ExpressGatewayService

CloudFormationではAWS::ECS::ExpressGatewayServiceという専用リソースタイプを使う。プロパティ名はPascalCase（大文字始まり）で、リソースとして必須なのはInfrastructureRoleArnとコンテナ画像（PrimaryContainerのImage）だけ。クラスターやスケーリング範囲は任意で指定できる。

Resources:
  MyExpressService:
    Type: AWS::ECS::ExpressGatewayService
    Properties:
      ServiceName: my-app
      PrimaryContainer:
        Image: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest
        ContainerPort: 8080
      ExecutionRoleArn: arn:aws:iam::123456789012:role/my-task-execution-role
      InfrastructureRoleArn: arn:aws:iam::123456789012:role/my-express-infra-role
      HealthCheckPath: /health
      ScalingTarget:
        MinTaskCount: 1
        MaxTaskCount: 5

ContainerPortは省略すると80が既定になる。ScalingTargetを指定しない場合、スケーリングはCPU使用率60%（AutoScalingMetricの既定はCPUUtilization、目標値の既定は60）を基準に自動調整される。Clusterは公式仕様上クラスター名でもフルARNでも指定できるが、ARN指定で識別子エラーになる報告があり、名前で指定するのが無難だ。作成後は戻り値として公開エンドポイントEndpointと、ALBのARNにあたるECSManagedResourceArns.IngressPath.LoadBalancerArnが取得でき、他リソースからの参照やDNS設定に使える。Cpu・Memoryもプロパティで上書きできる。

AWS CDKはL1構築のみ（L2は未提供）

CDKでは、CloudFormationリソースに1対1で対応するL1構築CfnExpressGatewayServiceがv2.230.0以降で利用できる。ただし高レベルの抽象化を提供するL2構築は2026年時点で未提供で、GitHubのaws-cdkリポジトリでIssue #36234として要望が挙がっている段階だ。そのためCDKでもプロパティ名はCloudFormationと同じ低レベル表記で書く必要があり、他のECS構築のような簡便なメソッドはまだ使えない。L2が来るまでは、L1構築で明示的にプロパティを指定する運用になる。

Terraformでの管理

ExpressGatewayServiceはTerraformからも管理でき、Console・SDK・CLI・CloudFormation・CDK・Terraformが選択肢としてそろっている。既存のインフラをTerraformで統一している組織なら、App Runnerからの移行時もExpress Modeを同じワークフローに載せられる。IaCで管理する場合はカナリアやヘルスチェックの既定挙動を理解したうえで、必要なパラメータだけを上書きするのが扱いやすい。

カスタムドメインの設定（Route 53とACM）

作成直後はAWS提供のドメインでHTTPS公開されるが、本番では独自ドメインへ差し替えることが多い。Route 53で管理するドメインとACM証明書があれば、共有ALBのリスナー設定を足すだけで対応できる。

• ACMで対象ドメインの証明書を発行しておく（前提条件）。
• Express Modeが作成した共有ALBのHTTPSリスナーに、カスタムドメイン用の証明書を追加登録する。
• 同リスナーにホストヘッダー条件のルールを追加し、独自ドメイン宛てのリクエストを対象サービスのターゲットグループへ転送する。
• Route 53でAレコード（エイリアス）を作成し、独自ドメインをALBへ紐付ける。
• 独自ドメインへアクセスしてHTTPSで到達できるか検証する。

ALBが複数サービスで共有されるため、ホストヘッダーベースのルールでドメインとサービスを対応づける点が通常のALB運用と異なる。証明書とルールはサービスごとに追加していく。

カナリアデプロイと自動ロールバックの既定動作

Express Modeの更新は、カナリアデプロイが既定かつ唯一の戦略として組み込まれている。ブルー/グリーンやローリングを選ぶ設定はなく、更新時は常に段階的な切り替えが行われる。

既定の流れは、まず新しいバージョンへ全体の5%のトラフィックを振り分け、3分間の待機（bake time）で挙動を観察し、問題がなければ100%へ切り替える、というものだ。この待機中に4xxと5xxの合計エラー割合が1%を超える状態が3分以内に2データポイント記録されると、自動でロールバックが発火して前のバージョンへ戻す。アプリの安定化に3分では足りない場合は、ECSサービス定義側でbake timeを延ばして調整できる。運用者が手動でトラフィックを切り替えたり、失敗時に切り戻したりする作業は不要になる。

App Runner・標準ECSとの違いと使い分け

App Runnerとの違いと移行判断

App RunnerとExpress Modeはどちらも「画像を渡すだけ」に近い体験を提供するが、生成物の扱いが根本的に違う。App Runnerはインフラを内部に隠すマネージドサービスで、細かいAWSリソースはユーザーから見えない。Express Modeは生成したALBやAuto Scalingをユーザーのアカウントに実体として作るため、後からECSの機能で細かく調整できる。App Runnerが2026年4月30日に新規受付を停止した以上、これから新規に採用するならExpress Modeが基本線になる。

標準ECS（Fargate直接運用）との使い分け

標準のECSは、タスク定義・サービス・ネットワーク・ロードバランサーを自分で設計する。自由度は最大だが、その分だけ初期構築と設定維持のコストがかかる。Express Modeは設計判断をAWSに委ねて速さを取る代わりに、デプロイ戦略がカナリア固定になるなど選択肢が絞られる。次の基準で選ぶとよい。

Webアプリやマイクロサービスを手早く本番へ出したいならExpress Modeが向く。逆に、ブルー/グリーンやローリングでデプロイを厳密に制御したい、VPCやサブネット・ルーティングを細かく設計する要件がある、といったケースではカナリア固定・既定寄せのExpress Modeは選ぶべきでなく、標準ECSで作り込むほうがよい。ECS全体の起動タイプや料金体系を先に理解したい場合はAWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い【2026年版】から押さえるとよい。

よくある質問

ECS Express ModeはCloudFormationで作成できますか？

できる。AWS::ECS::ExpressGatewayServiceという専用リソースタイプが用意されており、画像・実行ロール・インフラロールを必須プロパティとして指定する。作成後はEndpointやALBのARN（LoadBalancerArn）を戻り値として参照できる。

CDKでExpress Modeは使えますか？

L1構築CfnExpressGatewayServiceがv2.230.0以降で使える。ただし高レベルのL2構築は2026年時点で未提供（GitHub Issue #36234）で、当面はCloudFormationと同じプロパティ名で低レベルに記述する必要がある。

ECS Express Modeの料金はいくらですか？

Express Mode自体の追加料金はない。課金対象は自動生成されたFargateタスク・ALB・CloudWatchなど下層リソースの従量分のみで、通常のECS利用と同じ考え方だ。ALBが最大25サービスで共有されるため、小規模サービスを多数動かすほどロードバランサー費用を分担できる。

App RunnerからExpress Modeへ移行すべきですか？

App Runnerは2026年4月30日に新規受付を停止しメンテナンスステータスへ移行したため、新規採用や中長期運用ではExpress Modeへの移行が現実的だ。AWS自身が推奨移行先として案内しており、CLIやIaCでの再構築で移し替えられる。App RunnerもExpress ModeもコンテナをそのままFargateで動かすため、アプリ側の作り替えは基本的に不要だ。

デプロイ戦略はカナリア以外に変更できますか？

Express Modeではカナリアデプロイが既定かつ唯一の戦略で、ブルー/グリーンやローリングへ切り替える設定はない。ただしカナリアの待機時間（bake time）はECSサービス定義側で調整でき、安定化に時間がかかるアプリに合わせて延長できる。

関連記事

• AWS App Runnerは終了する？2026年の新規受付停止・メンテナンスモード移行と移行先を解説
• AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い【2026年版】
• AWS Fargateとは？EC2との違い・料金をわかりやすく解説【2026年版】