ECS Express Modeとは？使い方・既定値とCloudFormation・Terraform対応、App Runner移行先【2026年10月】

Amazon ECS Express Modeは、コンテナイメージとIAMロールを渡すだけで、Fargate上のECSサービス、HTTPS付きのApplication Load Balancer（ALB）、オートスケール、ログと監視を自分のAWSアカウントにまとめて作るECSの機能です。2025年11月21日に提供が始まり、2026年4月30日に新規受付を止めたAWS App Runnerの移行先としてAWSが案内しています。この記事では、CLIでの作成・更新・削除の手順、既定値と公式資料どうしで食い違う箇所、作成後に変えられない設定、CloudFormation・CDK・Terraformの対応差、2026年に追加されたARM64とカスタムタスク定義までを、2026年10月31日時点の公式ドキュメントとAPI定義で整理します。

まとめ：ECS Express Modeで決めておくことと2026年の変更点

• 必須の入力はコンテナイメージ・タスク実行ロール・インフラロールの3つです。自前のタスク定義を渡す場合は、タスク定義のARNとインフラロールだけで作れます。
• Express Mode自体は無料で、Fargate・ALB・CloudWatch・データ転送の料金だけがかかります。ALBは同じVPCの最大25サービスで共有されます。
• CPU・メモリとヘルスチェックパスの既定値は、開発者ガイドとAPIリファレンスで書かれている値が違います。本番では両方とも明示して作ります。
• サービス名・クラスター・インフラロールは作成後に変えられず、デプロイ戦略はカナリア（5％・3分）に固定です。ALBのスキームは最初に指定したサブネットで決まります。
• 2026年は、カスタムタスク定義（7月1日）とARM64の指定（グローバルの告知は9月18日）が加わりました。ただしCloudFormationにはCPUアーキテクチャのプロパティが無く、TerraformはAWSプロバイダー6.71.0（10月28日）で対応したばかりです。

初回構築ではCLIとネットワーク、既存サービスの変更では更新制約とIaCの対応差を確認してください。

ECS Express Modeの仕組み：3つの入力から作られるAWSリソース

従来のECSでコンテナをHTTPSで公開するには、クラスター・タスク定義・サービス・ALB・ターゲットグループ・セキュリティグループ・スケーリングポリシーを個別に作る必要がありました。Express Modeは、この組み合わせを既定値付きで一度に作ります。作られるのはAWS内部に隠れたリソースではなく、自分のアカウントのECSサービスやALBそのものです。

必要な入力はイメージ・タスク実行ロール・インフラロール

Express Modeの概要ページは、始めるのに必要なものをコンテナイメージ、タスク実行ロール、インフラロールの3つとしています。役割は次のとおりです。

• タスク実行ロール：ECRからのイメージ取得とCloudWatch Logsへの書き込みに使います。管理ポリシーAmazonECSTaskExecutionRolePolicyを付けます。
• インフラロール：ECSがALBやAuto Scalingを作るために引き受けるロールです。信頼ポリシーのプリンシパルはecs.amazonaws.comで、管理ポリシーAmazonECSInfrastructureRoleforExpressGatewayServicesを付けます。
• タスクロール（任意）：アプリがS3などのAWSサービスを呼ぶときに使います。

API上で必須なのはインフラロールだけです。CreateExpressGatewayServiceのリファレンスでは、イメージを渡すprimaryContainerとタスク定義を渡すtaskDefinitionArnのどちらかを選ぶ形になっており、後者を使うとタスク実行ロールやCPU・メモリはタスク定義から読まれます。

自分のアカウントに作られるリソースと共有の単位

作成されるリソースの一覧は次の10種類です。

ALBは、同じVPCで同じネットワーク構成のExpress Modeサービスなら最大25個まで1台を共有し、超えると自動で追加、サービスが減ると不要なALBを削除します。ALBの時間料金（東京で0.0243ドル毎時、720時間で約17.50ドル）はサービスの数で割られるため、小さなAPIを何本も載せるほど1本あたりの固定費が下がります。

2025年11月の提供開始から2026年10月までの機能追加

Express Modeは提供開始から1年弱で、指定できる項目が増えています。2025年12月時点の試用記事に書かれた「ARM64は指定できない」「タスク定義は自動生成のみ」は、現在は当てはまりません。

提供開始日は2025年11月21日のWhat’s New、カスタムタスク定義は2026年7月1日の告知によります。cpuArchitectureはAWS SDKのAPI定義（botocoreのECSモデル）に2026年9月11日の更新で加わり、Graviton対応の告知はその後の2026年9月18日のWhat’s Newです（中国リージョン向けサイトの同じ告知は10月20日付）。告知はx86比で最大40％の価格性能向上をうたっており、東京のFargate単価も、AWSのPrice List API（2026年10月19日公開分）でArmのvCPUが0.04045ドル毎時、x86が0.05056ドル毎時で、Armが約2割安くなっています。

ECS Express Modeの使い方：CLIで作成・更新・削除する手順

コンソールでは「Create」からExpress Modeを選び、イメージURIと2つのロールを指定すれば作れます。ロールはコンソール上で自動作成もできます。以下のAWS CLI例は、東京リージョンを設定済みで、指定するクラスター・IAMロール・サブネット・ECRイメージが存在することを前提とします。アカウントIDやリソースIDは自分の環境の値に置き換えます。nginxを公開して削除するまでの最小手順はAWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順に載せているので、ここでは本番を想定したパラメーターの付け方を中心に扱います。

create-express-gateway-serviceによるサービス作成

ロールを作った直後に実行すると、IAMの反映待ちでUnable to assume the service linked roleが返ることがあります。公式のCLIチュートリアルは、1分ほど待って再実行するよう案内しています。次の例は、既定値に頼らずCPU・メモリ・ヘルスチェック・アーキテクチャ・サブネットを明示する書き方です。

aws ecs create-express-gateway-service \
  --service-name my-api \
  --cluster my-cluster \
  --execution-role-arn arn:aws:iam::123456789012:role/ecsTaskExecutionRole \
  --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRoleForExpressServices \
  --primary-container '{"image":"123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-api:1.4.0","containerPort":8080}' \
  --cpu 1024 \
  --memory 2048 \
  --cpu-architecture ARM64 \
  --health-check-path "/healthz" \
  --network-configuration '{"subnets":["subnet-aaaa","subnet-bbbb","subnet-cccc"]}' \
  --scaling-target '{"minTaskCount":2,"maxTaskCount":10,"autoScalingMetric":"AVERAGE_CPU","autoScalingTargetValue":60}' \
  --monitor-resources

--monitor-resourcesを付けると、ALBや証明書が作られていく様子を表示しながら待ちます。完了するとhttps://<サービス名>.ecs.ap-northeast-1.on.aws/形式のURLで応答します。ARM64を指定する場合は、イメージがarm64用にビルドされている必要があります。途中で抜けても、aws ecs monitor-express-gateway-service --service-arn <ARN>で再び状態を追えます。

update-express-gateway-serviceによるイメージ・設定の更新

更新は作成時に返されたサービスARNを--service-arnで指定します。変えたい項目だけを渡せば、残りは現在の値が引き継がれます。

aws ecs update-express-gateway-service \
  --service-arn arn:aws:ecs:ap-northeast-1:123456789012:service/my-cluster/my-api \
  --primary-container '{"image":"123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-api:1.5.0","containerPort":8080}'

更新のたびにサービスリビジョンが作られ、後述のカナリアデプロイで切り替わります。コンテナはデプロイ時にイメージタグをダイジェストへ固定するversionConsistencyが既定で有効なので、同じlatestタグへ上書きpushしても、稼働中のタスクは更新前のイメージのまま動きます。どのイメージが動いているかを追えるよう、リリースごとにタグを変えて更新します。GitHub Actionsから更新する場合は、AWS公式のaws-actions/amazon-ecs-deploy-express-service（v1.2.2）が作成と更新の両方を扱えます。

削除で消えるリソースと残るリソース

aws ecs delete-express-gateway-service --service-arn <ARN>で削除すると、サービスはDRAININGを経てINACTIVEになり、元には戻せません。削除の説明によると、ALBは他のサービスが使っていなければ削除され、Express Mode以外のサービスと共有していれば残ります。IAMロールは消えません。

ロググループの扱いは資料で割れています。削除ページは削除対象に挙げる一方、ベストプラクティスは「保持期限なしで作られ、サービスを削除しても残る」と書いています。削除後はCloudWatch Logsでロググループの有無を確認し、残っていれば保持期限を設定するか消します。

ECS Express Modeの既定値一覧と、公式資料で食い違う3項目

パラメーターを省いたときの値は、開発者ガイドの既定値一覧にまとまっています。本番で変えることが多い項目を抜き出すと次のとおりです。

正常しきい値の5回は、ターゲットグループのヘルスチェック設定の定義上、異常と判定したタスクを正常へ戻すときの連続成功回数です。新しく登録されたタスクは初回のヘルスチェックを通過すると正常になります。一方、異常判定は失敗2回（間隔30秒なら約1分）で出るので、起動に時間のかかるアプリは300秒のヘルスチェック猶予の間に応答できる状態にしておきます。

CPU・メモリ、ヘルスチェックパス、スケーリング指標の表記の違い

次の3項目は、資料によって書かれている値が違います。

CPU・メモリは、CLIチュートリアルが「最小パラメーターで1vCPU・2GBのサービスができる」と書いており、開発者ガイドとTerraformのリソース説明も1024・2048です。一方、APIリファレンスとGitHub Actionの入力説明は256・512としています。ヘルスチェックパスも同じ組み合わせで/と/pingに分かれます。/pingを実装していないアプリで既定値に頼ると、どちらが正しいかによってはタスクが異常と判定され続けるので、--cpu・--memory・--health-check-pathは必ず明示します。

スケーリング指標は、説明文が既定を「CPUUtilization」と書くのに対し、APIとCloudFormationで指定できる値はAVERAGE_CPU・AVERAGE_MEMORY・REQUEST_COUNT_PER_TARGETの3つだけです。テンプレートに説明文のCPUUtilizationを書くと許可値の検証で失敗するので、AVERAGE_CPUと書きます。リクエスト数で増減させる場合は、ALBのターゲットあたりリクエスト数が指標になります。開発者ガイドは目標値の上限を「ターゲットあたり毎秒65,536」と書いていますが、ALBのこの指標は1分ごとの集計値なので、設定後に作られたスケーリングポリシーの目標値と負荷試験の結果を突き合わせます。

作成後に変えられない設定と、Express Modeの外で直す設定

Express Modeは「既定値で作り、必要ならECSやELBのAPIで直接直す」設計です。どこまでをExpress Modeの更新で変えられ、どこからを外で直すのかを先に知っておくと、作り直しを避けられます。

Express Modeの更新制約とCloudFormationで置換される設定

• サービス名とクラスター：作成時のみ指定でき、更新では変えられません。CloudFormationでは変更すると置換（Replacement）になります。
• インフラロール：作成後は変えられず、変えるにはサービスを作り直します。
• タグ：CloudFormationのTags変更は置換になりますが、サービスのタグはECSのTagResource・UntagResourceで作成後も変更できます。
• デプロイ戦略：カナリアに固定で、ローリングやブルー/グリーンへは変えられません。
• ロードバランサーの構成：Express Modeの更新ではALBとの関連付けを変えられません。

CloudFormationの「置換」は、新しいサービスを作ってから古いサービスを消す動きです。サービス名を固定していると名前が重複して失敗し、名前を変えれば新しいURLが払い出されます。サービス名とクラスターは、最初に本番用の命名で決めておきます。

Express Mode外での変更の保持条件と上書きリスク

Express Mode外での更新の説明によると、ECSやELBのAPIで直接加えた変更は残り、Express Modeは更新で同じ項目を指定しない限り上書きしません。逆に、直接の変更がExpress Modeの設定と衝突しないかの検証もしません。外で直すのが前提の項目は次のとおりです。

• カナリアの待機時間（bake time）：ECSサービスのデプロイ設定で延ばします。
• 独自ドメイン：ALBのリスナールールと証明書を直接編集します（後述）。
• AWS WAF：Web ACLをALBに関連付けます。
• ログの保持期限・追加のスケーリングポリシー：CloudWatch LogsとApplication Auto Scalingで設定します。

注意したいのは、コンテナ名Mainを変えるとExpress Modeからの以後の更新が効かなくなることと、サイドカーを足したタスク定義でもログ設定をExpress Mode側で更新するとログドライバーがawslogsに戻ることです。Fluent Bitなどのサイドカーを恒常的に使うなら、タスク定義を直接書き換えるより、カスタムタスク定義としてtaskDefinitionArnで渡すほうが管理が一本になります。FireLensの設定例はFluent Bitとは？読み方・Fluentdとの違い・AWSでの設定例【v5.1対応】で扱っています。Express Modeの管理から完全に外したい場合は、リソースのManagedタグを外すか、IAMでExpress Mode APIの実行を禁止します。

ECS Express Modeのネットワーク：サブネットで決まるALBの公開範囲

サブネットを省くと、デフォルトVPCのパブリックサブネットにインターネット向けALBが作られます。デフォルトVPCには、2つ以上のAZにパブリックサブネットが2つ以上あり、各サブネットのCIDRブロックごとに8個以上の空きIPが必要です。社内向けのシステムを既定値のまま作ると外部に公開されてしまうので、本番では必ずサブネットを指定します。

• パブリックサブネットを渡す：インターネット向けALBが作られ、タスクにもパブリックIPが付きます。
• プライベートサブネット（ルートテーブルにインターネットゲートウェイが無いサブネット）を渡す：内部ALBになり、タスクはパブリックIPを持ちません。インターネット上の外部APIへ接続するにはNAT Gatewayなどの出口が必要です。ECRなど対応するAWSサービスへは、必要なVPCエンドポイントを構成して接続する方法もあります。
• IPv6が有効なサブネットを渡す：デュアルスタックのALBが作られます。

見落としやすいのは、VPCで最初に作ったExpress Modeサービスのサブネットが、そのVPCのALBのAZを決めることです。2つ目以降のサービスは、そのALBが対応するAZのサブネットを指定しなければなりません。開発者ガイドは、最初から全AZのサブネットを指定するよう勧めています。東京リージョンなら3つのAZのサブネットをそろえて作るのが安全です。

セキュリティグループを指定しない場合は、サービス用とALB用の2つが作られます。自分のセキュリティグループを渡すと、既定のものに加えて受信経路を1つ足す扱いになる点に注意します。

CloudFormation・CDK・TerraformでのIaC対応と対応差

Express ModeはCloudFormation・CDK・Terraformで管理できますが、2026年10月31日時点で、ツールごとに使える項目がそろっていません。

CloudFormationのExpressGatewayService定義とARM64の指定方法

CloudFormationのリソースリファレンスで必須なのはInfrastructureRoleArnだけで、PrimaryContainerを使う場合はその中のImageが必須です。プロパティ名はPascalCaseで書きます。以下はテンプレートの抜粋で、InfraRole・ExecRoleの定義と既存クラスターが別途必要です。イメージURIとサブネットIDも実際の値に置き換えます。

Resources:
  ApiService:
    Type: AWS::ECS::ExpressGatewayService
    Properties:
      ServiceName: my-api
      Cluster: my-cluster
      InfrastructureRoleArn: !GetAtt InfraRole.Arn
      ExecutionRoleArn: !GetAtt ExecRole.Arn
      Cpu: "1024"
      Memory: "2048"
      HealthCheckPath: /healthz
      PrimaryContainer:
        Image: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-api:1.5.0
        ContainerPort: 8080
      NetworkConfiguration:
        Subnets: [subnet-aaaa, subnet-bbbb, subnet-cccc]
      ScalingTarget:
        MinTaskCount: 2
        MaxTaskCount: 10
        AutoScalingMetric: AVERAGE_CPU
        AutoScalingTargetValue: 60
Outputs:
  Url:
    Value: !GetAtt ApiService.Endpoint
  AlbArn:
    Value: !GetAtt ApiService.ECSManagedResourceArns.IngressPath.LoadBalancerArn

Fn::GetAttでは、URLのEndpointのほか、ALB・リスナー・リスナールール・証明書・ターゲットグループのARNを取り出せます。WAFの関連付けやRoute 53のエイリアスを同じテンプレートで書くときに使います。

リファレンスにはCpuArchitectureのプロパティがありません。CloudFormationでARM64を使うには、runtimePlatformにARM64を指定したタスク定義を作り、TaskDefinitionArnで渡します。既存のスタックにTaskDefinitionArnを初めて足すときは、ロールバックに備えて先に一度スタックを再デプロイするよう更新の説明が求めています。

AWS CDKはL1のCfnExpressGatewayServiceだけ

CDKでは、CloudFormationリソースに1対1で対応するL1のCfnExpressGatewayServiceをv2.230.0（2025年11月26日）から使えます。高レベルのL2コンストラクトは提供されておらず、要望のaws-cdkのissue #36234は2026年10月31日時点でもオープンのままです。L1なので、ecs.FargateServiceのような型付きのメソッドは使えず、プロパティはCloudFormationと同じ構造で書きます。ARM64の扱いもCloudFormationと同じくタスク定義経由になります。

TerraformのExpress Mode定義とプロバイダーバージョンによる対応差

Terraformではaws_ecs_express_gateway_serviceがAWSプロバイダー6.23.0（2025年11月26日）で追加され、cpu_architectureは6.71.0（2026年10月28日）で加わりました。task_definition_arnの引数はまだ無いので、カスタムタスク定義を使う構成はCloudFormationかCLIで組みます。以下のTerraform例は既存構成への追加用で、参照するクラスター・IAMロール・ECRリポジトリ・サブネット・ポリシー添付を別途定義し、AWSプロバイダー6.71.0以降を使用します。プライベートサブネットを指定するため、作成されるALBは内部向けです。

resource "aws_ecs_express_gateway_service" "api" {
  service_name            = "my-api"
  cluster                 = aws_ecs_cluster.main.name
  execution_role_arn      = aws_iam_role.execution.arn
  infrastructure_role_arn = aws_iam_role.infrastructure.arn
  cpu                     = "1024"
  memory                  = "2048"
  cpu_architecture        = "ARM64"
  health_check_path       = "/healthz"

  primary_container {
    image          = "${aws_ecr_repository.api.repository_url}:1.5.0"
    container_port = 8080
  }

  network_configuration {
    subnets = aws_subnet.private[*].id
  }

  scaling_target {
    min_task_count            = 2
    max_task_count            = 10
    auto_scaling_metric       = "AVERAGE_CPU"
    auto_scaling_target_value = 60
  }

  depends_on = [aws_iam_role_policy_attachment.infrastructure]
}

depends_onはリソース説明の注記に従ったものです。インフラロールのポリシーが先に消えると、削除中のサービスがDRAININGのまま止まります。6.50.0（2026年6月10日）では、network_configurationのセキュリティグループで「inconsistent result after apply」が出る不具合が直り、代わりにec2:DescribeSecurityGroupsの権限が必要になりました。古い版でignore_changesを入れて回避していた構成は、6.50.0以降へ上げてから外せます。

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

Express Modeの更新は、更新の説明に書かれた次の順で進みます。

1. 変更を入れた新しいタスク群を起動する
2. トラフィックの5％を新しいタスク群へ送る
3. 3分間の待機（bake time）の後、100％を新しいタスク群へ移す
4. さらに3分間監視してから、古いタスクを順に止める

この間、4xxと5xxを合わせたエラー率が1％を超えるデータポイントが3分以内に2つ記録されると、アラームによって自動で元のリビジョンへ戻ります。1回の更新は、新しいタスクの起動とヘルスチェックの時間に加えて最低6分かかる計算です。

ここで判断が要るのは、4xxもロールバックの条件に入っている点です。認証切れの401や存在しないパスへの404が普段から1％を超えるAPIでは、コードに問題が無くても毎回ロールバックされます。その場合は、ECSサービス側に作られたアラームのしきい値を見直すか、Express Modeを使わず標準のECSでデプロイ設定を自分で組みます。待機時間はECSサービスのカナリア設定で延ばせますが、戦略そのものはExpress Modeの更新では変えられません。ライフサイクルフックやテスト用リスナーが要るなら、ECSネイティブBlue/Greenデプロイの設定手順｜Terraform・CDK例とライフサイクルフック・CodeDeploy移行【2026年版】の構成を選びます。

なお、APIリファレンスのUpdateExpressGatewayServiceの説明は「rolling deployment」と書いていますが、開発者ガイド・Terraformのリソース説明・既定値一覧はいずれもカナリアとしています。ここも資料間の表記揺れです。

独自ドメインを設定する手順（Route 53とACM）

払い出されるon.awsのURLの代わりに独自ドメインで公開するには、ALBのリスナールールと証明書を直接編集します。公式の手順は次のとおりです。

1. ACMで独自ドメインの証明書を発行しておく
2. ECSコンソールでサービスの「Resources」タブからリスナールールを開き、「Edit Rule」を選ぶ
3. 今のホストヘッダー条件（払い出されたURL）を控えて条件を削除し、ホストヘッダー条件を作り直して、払い出されたURLと独自ドメインの両方をOR条件で入れる
4. ALBのリスナーの「Certificates」タブで独自ドメインの証明書を追加する
5. Route 53のホストゾーンで、ALBへのエイリアスレコードを作る

ホストヘッダーの条件は1つのルールに1種類しか置けないため、条件を足すのではなく作り直す手順になっています。払い出されたURLを条件から消すと、ECSのコンソールやヘルス確認で使うURLが通らなくなるので、両方を残します。DNSをRoute 53以外で管理する場合、サブドメインにはALBのDNS名へのCNAMEを設定できます。ゾーン頂点には通常のCNAMEを設定できないため、DNS事業者のALIAS相当機能への対応を確認します。証明書の発行と更新の仕組みはAWS Certificate Managerとは？有効期間198日化とACME対応・料金と採用判断を実装者目線で解説で扱っています。

1台のALBに25サービスを相乗りさせ、それぞれに独自ドメインを付けると、リスナーの証明書の数も増えます。ALBのクォータでは、既定証明書とは別に追加できる証明書は既定で1台あたり25枚です。Express Modeが自動で作る証明書も同じリスナーに載るため、独自ドメイン用の証明書と合算して上限に届かないかを確認し、超える見込みならService Quotasで先に引き上げておきます。

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

ECSには、2026年10月20日にもう1つ「ALBを自動で作る」仕組みとしてECS Gatewayが加わりました。Express Modeと混同しやすいので、4つを並べます。

採用してよいのは、HTTPSで公開するステートレスなWebアプリやAPIを、少人数のチームが手早く本番に出したい場合です。既定値のうちサブネット・CPU・メモリ・ヘルスチェックを明示すれば、そのまま本番の土台になります。

選ぶべきでないのは、次のいずれかに当てはまる場合です。TCPやUDPで待ち受けるサービス（ALBのHTTPSリスナーとホストヘッダーのルーティングしか作られません）、パス単位の振り分けやブルー/グリーンが要るサービス、4xxが常に1％を超えるAPI、VPCのALB構成を自分で設計したい組織です。複数サービスのタスク定義やデプロイを自分で管理しつつ、ALBの作成・共有を任せたいなら、Amazon ECS Gatewayとは：共有ALBでECSサービスを公開する手順とCLI例【2026年10月】のほうが合います。なお、ECS GatewayにはExpress Modeのサービスを接続できません。

App Runnerから移る場合は、同時リクエスト数でのスケールがCPU使用率の目標追跡に変わり、一時停止の操作が無くなり、ALBの固定費が加わります。設定の対応表と東京リージョンでの月額比較はAWS App Runnerは終了する？新規受付停止後の現状とECS Express Modeへの移行手順・東京の料金比較【2026年10月】にまとめています。ECSそのものの構成要素から確認したい場合はAWS ECSとは？Dockerコンテナを動かす手順と起動タイプ・料金・EKSとの違い【2026年10月】が入口です。既存システムのコンテナ化やAWS上の構成設計を外部に任せる場合は、AWS・Google Cloud・Azureのインフラ構築支援で相談を受けています。

ECS Express Modeでよくある質問

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

Express Mode自体は無料です。かかるのはFargate・ALB・CloudWatch・データ転送の料金です。Fargateの料金とPrice List APIの東京リージョン単価で、1vCPU・2GBのタスク1個を720時間動かすと、x86で約44.37ドル、ARM64で約35.49ドルです。最小タスク数を2にすれば2倍になります。これにALBの時間料金約17.50ドル（25サービスまで共有）とLCU料金、パブリックサブネットならパブリックIPv4の料金が加わります。

CDKでECS Express Modeを使えますか？

L1のCfnExpressGatewayService（v2.230.0以降）で使えます。L2コンストラクトは2026年10月31日時点で未提供で、GitHubのissue #36234がオープンのままです。プロパティはCloudFormationのAWS::ECS::ExpressGatewayServiceと同じ構造で書きます。

ECS Express ModeでARM64（Graviton）のコンテナを動かせますか？

動かせます。CLIやSDKではcpuArchitectureにARM64を指定し、Terraformは6.71.0以降のcpu_architectureを使います。CloudFormationとCDKには直接のプロパティが無いため、ARM64を指定したタスク定義をTaskDefinitionArnで渡します。いずれもイメージがarm64用にビルドされていることが前提です。

カナリアの待機時間（bake time）は変えられますか？

変えられます。Express Modeが作ったECSサービスのデプロイ設定で、カナリアの待機時間を延ばします。ただし、デプロイ戦略をローリングやブルー/グリーンへ変えることはできません。

Express Modeのサービスを削除するとALBも消えますか？

そのALBを使っているサービスが他に無ければ消えます。Express Modeのほかのサービスや、Express Mode以外のサービスと共有していれば残ります。IAMロールは削除されず、ロググループは資料によって削除・保持の記述が分かれるため、削除後にCloudWatch Logsで確認します。

関連記事

• AWS App Runnerは終了する？新規受付停止後の現状とECS Express Modeへの移行手順・東京の料金比較【2026年10月】
• AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順
• Amazon ECS Gatewayとは：共有ALBでECSサービスを公開する手順とCLI例【2026年10月】
• AWS ECSとは？Dockerコンテナを動かす手順と起動タイプ・料金・EKSとの違い【2026年10月】
• AWS Fargateとは？ECSのEC2起動タイプとの違い・料金・運用をわかりやすく解説【2026年版】