![[アップデート] ECS Express Mode を利用できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-6d4fdf3578638cab4e6e4655b3d692aa/15a803840d72679e6593006354d5766b/amazon-elastic-container-service?w=3840&fm=webp)
[アップデート] ECS Express Mode を利用できるようになりました
概要
ECS タスク定義や ECS サービスなどの多くの設定を意識することなく簡単にコンテナアプリケーションをデプロイ可能な ECS Express Mode が登場しました。
マネジメントコンソールを見ればデプロイ時の簡単さが一目瞭然です。
タスク実行ロールやインフラストラクチャーロールは必要なものの、その他の必須項目はコンテナイメージのみというシンプルさです。
コンソールを見るだけだと、App Runner よりもシンプルですね。
とはいえ、あくまで ECS を簡単にデプロイするためのサービスで、すべてのリソースが AWS アカウント内に作成される点に注意が必要です。
While Express Mode creates and configures resources like Amazon ECS services, load balancers, and auto scaling policies, all resources remain in your AWS account and are fully accessible for direct management. You can modify these resources outside of Express Mode using the AWS Console, AWS CLI, or APIs, but doing so may affect Express Mode's ability to manage your service.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-advanced-customization.html
この点では App Runner より Copilot CLI に近いサービスと言えます。
What's New
AWS ブログ
公式ドキュメント
触ってみて感じた内容のまとめ
詳細は追って記載しますが、気になった点を最初にまとめておきます。
- ECS Express Mode はあくまで ECS 環境の作成を簡単に行える機能
- ACM、ALB、ECS、CloudWatch ロググループなどを自動生成可能
- 各種リソースはユーザー側の AWS アカウント内に作成され、マネジメントコンソールや CLI などで変更可能
- CPU アーキテクチャ (x86 or ARM) のような最初から指定しておきたいけど、設定できない項目がある点には注意が必要
- ネットワーク
- 指定が無ければ default VPC のパブリックサブネットに ALB と ECS タスクが配置される
- プライベートサブネットのみを指定すると Internal ALB として構成されるため、そのままではインターネット公開できない
- ALB と ECS タスクを別サブネットに分離する設計を採用できない点に注意が必要
- デプロイ戦略
- デフォルトで Canary パーセント 5% のカナリアデプロイであり、現状は変更不可のため若干デプロイフローが複雑になる
- カスタムドメイン
- 追加の証明書設定、ALB リスナールール変更、Route 53 設定が必要で、ALB を共有できるとはいえ、少し複雑な操作を求められる
- IaC との相性
- CloudFormation リソースはあるが、Express Mode 外変更が前提となる場面があり一貫管理はやや不向き
- App Runner との住み分け
- 超低トラフィックなら App Runner がコスト有利（アイドル時 CPU 課金なし）
- VPC を意識せずにコンテナアプリケーションを扱いたい場合や、ソースコードリポジトリ連携が要件なら App Runner が良い
- WebSocket アプリケーションを簡単に展開したい場合は ECS Express Mode が良い
試してみる
さっそく ECS Express Mode を利用してサービスを公開してみます。
できる限り Express Mode に任せて作成してみますが、コンテナイメージ、ECS タスク実行ロール、インフラストラクチャーロールは必ず設定が必要です。
コンテナイメージの指定
簡単なアプリケーションを作成して ECR にイメージをプッシュしておきます。
サンプルアプリケーションは下記資材を利用して予め ECR にプッシュしておきました。
コンテナイメージを選択する際は、イメージダイジェストを参照するかイメージタグを参照するかを選択可能です。
よくわからなかったらデフォルトの「イメージダイジェスト」を選択しておくのがおすすめです。
一応下記補足しておきます。
コンテナにおいて、イメージタグが指す対象はタイミングに依って異なる可能性があります。
例えば、latest タグなどはイメージプッシュの度に対象のイメージが変わっていると思います。
「イメージダイジェスト」を選択すると、ECS サービスを作成または更新した際にイメージタグをイメージハッシュに変換して、スケールアウト時にも最初のイメージハッシュを厳密に指定して利用可能です。
詳しくは下記ブログを参照下さい。
ECS タスク実行ロールの作成
タスク実行ロールは Express Mode 関係なく ECS サービス作成時に必要なロールです。
既に環境に存在している場合はそちらを指定しても良いです。
マネジメントコンソールの「新しいロールを作成」からも作成が可能です。
ecs-tasks.amazonaws.com から引き受け可能で、AmazonECSTaskExecutionRolePolicy を付与した IAM ロールを作成すれば問題ありません。
インフラストラクチャーロールの作成
インフラストラクチャーロールは ECS Express Mode 専用のものを作成する必要があります。
こちらもマネジメントコンソールの「新しいロールを作成」から作成可能です。
ecs.amazonaws.com から引き受け可能で、AmazonECSInfrastructureRoleforExpressGatewayServices を付与した IAM ロールを作成すれば問題ありません。
用意されている AWS マネージドポリシーに付与されている権限は下記でした。
Express Mode 作成
コンテナイメージ、タスク実行ロール、インフラストラクチャロールと最低限必要な設定は行うことができたので、「作成」をクリックします。
IAM ロールの作成があったので多少手順が増えましたが、2 サービス目からは使い回せるため、より簡単にサービスを公開できると思います。
コンテナイメージ以外に設定可能な項目として、ECS クラスターやコンテナポート、タスクロールやサイジングなどがあります。
配置先 VPC も選択が可能で、特に指定しないと default VPC に作成されます。
これらの項目は create-express-gateway-service 実行時に指定可能なだけで、他の項目 (ALB 周りなど)もリソースデプロイ後に変更することは可能です。
とはいえ、CPU アーキテクチャあたりは最初から指定したい気がしますね (デフォルトは x86_64)。
6 分程度経って、下記が作成されました。
- ECS クラスター
- タスク定義
- ECS サービス
- ALB
- ALB リスナー
- ACM
- ターゲットグループ
- CloudWatch ロググループ
- スケーリング設定
Express Mode で作成された ECS サービスに「Express」とつきます。
アプリケーション URL が HTTPS アクセス可能な形で払いだされます。
リクエストを送ると無事アクセスできました。
% curl -I https://sa-0a7c6de4b0444e7482b9007a1573f36a.ecs.ap-northeast-1.on.aws
HTTP/2 200
date: Sat, 22 Nov 2025 04:35:20 GMT
content-type: text/html; charset=utf-8
content-length: 14
x-powered-by: Express
etag: W/"e-pNj4d5u78E/mRi2IR6lRzO1W3mw"
今回は VPC を指定しなかったのでデフォルト VPC のパブリックサブネットに配置され、ECS タスクにパブリックも IP も付与されました。
パブリック IP を付与していることを意識してセキュリティグループなどで制限すれば良いものの、あまり深く考えずに ECS のセキュリティグループを変更して意図しないポートがインターネット公開しないように注意が必要です。
ちなみに、作成時にプライベートサブネットのみを指定した場合は Internal ALB が作成されるので、CloudFront や API Gateway などを挟まないとインターネット公開できません。
パブリックサブネットとプライベートサブネットを両方含む設定にして ALB だけパブリック IP を持つ設定にすることもできません。
If none are provided, Express Mode will use the default public subnets in the default VPC.
The default VPC must have at least two public subnets, in at least two availability zones, with at least 8 free IPs available, per assigned CIDR block, per subnet.
If you provide custom public subnets, Express Mode will provision an internet-facing ALB and turn on assignPublicIP for your tasks. If you provide private subnets (subnets without an internet gateway in their route table), Express Mode will provision an internal ALB.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-work.html#express-service-network-defaults
ECS にパブリック IP を付与する設定だと Security Hub の [ECS.2] ECS services should not have public IP addresses assigned to them automatically にも違反するので悩ましいですね。
Security Hub の HIGH 以上に対応必須な環境などでは採用し辛くなります。
セキュリティグループについては、「ネットワーク設定をカスタマイズ」にチェックを入れつつ未指定状態でも default が割り当たることは無く、ALB からの HTTP アクセスのみを許可したセキュリティグループが作成されました。
VPC を指定した場合もセキュリティグループ周りは任せてしまって良いかなと思います。
ECS クラスターも存在しないと default という命名で作成されますが、わかりやすい命名で作成して指定した方が良いと思います。
ECS クラスターはそこまで設定項目が多くないですが、存在自体にお金がかかるものでは無いですし、Container Insights を利用するのであれば利用目的ごとに分けておいた方が無難です。
サイジングは 1vCPU、メモリ 2GB で作成されました。
一番ミニマムなサイジングというわけでも無いですし、多くの場合こちらも設定した方が良いと思います。
その他、デフォルト設定は下記ページを参照下さい。
モニタリングについて
ECS サービス詳細に「オブザーバビリティ」タブが存在し、CPU/メモリ利用率やレイテテンシー、ALB の 4xx/5xx エラーレートなど、運用上特に確認したいメトリクスはここから確認できるようになっています。
すぐ横の「ログ」タブからコンテナログも確認可能です。
とりあえずこちらで運用を開始できますし、もっと細かく見たくなった場合は、作成されたリソースの各種メトリクスを参照してダッシュボードを作成すれば良いです。
もちろん ECS クラスター側で設定すれば Container Insights も利用可能です。
カスタムドメインについて
カスタムドメインを変更する際、下記を作成されたリソースに対して設定する必要があります。
- ACM を作成して追加の証明書として ALB リスナーに設定
- リスナールール修正
- Route53 レコード追加
まず、ACM を追加の証明書として取り込みます。
最初からホストベースでルーティングするリスナールールが設定されているので、そちらをカスタムドメイン名のものに変更します。
複数サービスで ALB を共有できるのはコストメリットがありますし、あえてホストベースルーティングを利用する設計にしているのは理解できます。
Cost optimization - Shares Application Load Balancers across multiple Express Mode services using the same networking conifguration to reduce costs.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-overview.html#express-service-benefits
ただ、カスタムドメインを利用しようとした場合、リスナールールを直接変更する必要がでてくるので操作が複雑になりますし、ちょっとしたオペレーションミスで影響が大きくなりそうに感じました。
ACM やカスタムドメイン周りはもう少し抽象化してくれた方が嬉しいと思ったので、今後のアップデートに期待したいと思います。
デプロイについて
ECR に新しいコンテナイメージをプッシュした後、「サービスの更新」をクリックします。
プッシュしたイメージのイメージタグを選択します。
「更新」をクリックします。
Canary パーセント 5% のカナリアデプロイでデプロイされました。
従来の CodeDeploy を利用したものでは無く、最近アップデートされた ECS ビルトインデプロイのカナリアデプロイですね。
また、現時点でデプロイ戦略は変更不可なようです。
deploymentConfiguration: Canary by default - Express Mode service uses Canary deployments
Note that deployment strategy can not be updated on Express Mode services.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-work.html#express-service-service-defaults
個人的には無駄にデプロイフローを複雑化したくないので、デフォルトは単なるローリングアップデートで良いように感じました。
カナリアデプロイであることにも気づき辛いので、リクエストによって古いバージョンが返されたり新しいバージョンが返されたりして混乱する人もいそうだなと思いました。
知っていればその前提で動作確認すれば良いものの、デプロイ中にテストするなら 5% を引き当て無いといけないので、少しやり辛いと感じました。
カナリアデプロイを利用したいユースケースもあると思いますが、設定でローリングアップデートを選択できるようになると良いですね。
CloudFormation について
AWS::ECS::ExpressGatewayService を利用すれば Express Mode で ECS サービスを作成可能です。
設定例としては下記のようになります。
AWSTemplateFormatVersion: "2010-09-09"
Description: "ECS Express Mode Test Service"
Resources:
ExpressGatewayService:
Type: AWS::ECS::ExpressGatewayService
Properties:
Cluster: "express-mode-test-cluster"
Cpu: "256"
Memory: "512"
ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole"
InfrastructureRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsInfrastructureRoleForExpressServices"
NetworkConfiguration:
Subnets:
- "subnet-05eb44939ba18b426"
- "subnet-00617c394346d1a32"
PrimaryContainer:
Image: !Sub "${AWS::AccountId}.dkr.ecr.ap-northeast-1.amazonaws.com/sample-ecs-app:v1"
ContainerPort: 80
ただし、Express Mode で作成したサービスに対して、CloudFormation を介さずに変更を入れる必要がある点からあまり IaC との相性は良くないと思います。
カスタムドメイン対応で Express Mode 経由で作成された ALB のリスナー設定を修正してもドリフトは検出されませんでした。
ECS Express Mode で作成されたリソースに対してカスタムドメイン設定やサイドカーコンテナ追加を行うことは想定されているようですし、CloudFormation 側から設定を巻き戻してしまうような事故は起きなそうです。
ただ、IaC の一貫性を持って複数環境を扱えるメリットは大きく損なわれてしまう印象です。
このあたりを重視して IaC の利用を視野に入れているのであれば、多少手をかけても最初から ECS や ALB を IaC で定義しておく方が良いでしょう。
App Runner との比較
コスト
ECS Express Mode は良くも悪くも従来の ECS そのものを簡単に作成する機能です。
そのため、App Runner のメリットであるリクエストが無い時に CPU 料金が発生しないような料金体系にはなっていません。
極めてリクエストが少なく、稀にリクエストがあるようなケースだと App Runner にコストメリットがあるでしょう。
ただ、Fargate Spot もあるため、ある程度継続的なリクエストがあれば ECS Fargate の方が有利な場面もあり、ケースバイケースですね。
また、ECS Express Mode は ALB を複数サービスで共有することを想定しているので、この点でもコストメリットがあると思います。
カスタムドメイン
前述の通り、ECS Express Mode だとカスタムドメインを利用したい時の操作がわかり辛いです。
App Runner だとカスタムドメインを管理するための設定があるので、この点は ECS Express Mode の弱い所だと思いました。
ECS Express Mode はカスタムドメインさえ利用しなければリスナールールを意識せずにホストベースルーティングを扱えるメリットがあるので、カスタムドメインを使う場合も ECS 側の設定で完結するようになると嬉しいですね。
SLA
App Runner は SLA を定義していないサービスですが、ECS Express Mode は従来の ALB と ECS 相当なので計算可能です。
ただし、SLA を定義するようなユースケースなら従来の ECS で細かくパラメータを設計した方が良いとは思います。
ソースコードリポジトリ連携
App Runner は GitHub などのリポジトリをリンクするだけで、ビルドして展開してくれる機能がありました。
ECS Express Mode はイメージの URI を指定する必要があるので、こちらに相当する機能はありません。
とはいえ、App Runner の本機能を利用するとビルドログが不十分で困ったことがあったので私はあまり利用していませんでした。
ここはもうコンテナイメージを ECR にプッシュする方向で良いかなという感触ですが、今後こういった機能が追加されると嬉しい場面はあるかもしれません。
VPC は意識する必要あり
App Runner は VPC を意識せずに利用することができ、Aurora DSQL のような VPC を意識しないサービスとの相性が良いです。
以前、VPC レスでマルチリージョンのコンテナアプリケーションを構築してみましたが、かなり体験が良かったです。
ECS Express Mode はどうしても VPC を意識する必要があるので、こういった使い方はできません。
全コンポーネントをパブリックサブネットに配置するか全コンポーネントをプライベートサブネットに配置するかしか選べないことなど、どうしても VPC を扱うことで考慮事項が増えている感じはあって、ここは App Runner の方が良いなと思うポイントです。
まぁ VPC を意識したくないなら Lambda があるというのもわかります。
WebSocket 対応
App Runner は長らく WebSocket に対応しておらず、今後も対応予定は無さそうでした。
ECS Express Mode は単なる ALB と ECS なのでもちろん WebSocket を利用できます。
この点がネックで App Runner を利用できていなかったケースにはドンピシャで刺さるアップデートだと思います。
各種メトリクスについて
ECS Express Mode はあくまで各種リソースを AWS アカウントにデプロイしているだけなので、見ようと思えば各リソースの詳細なメトリクスを確認可能です。
App Runner ですと CPU/メモリ使用率や HTTP ステータスなどの代表的なメトリクスしか見れないのでここは ECS Express Mode の良い所です。
App Runner でも確認できるような代表的なメトリクスを確認したければ、最初から「オブザーバビリティ」タブにまとまっているというのも良いポイントです。
最後に
現時点では構成の自由度が減っているデメリットが簡単に構成できるメリットを上回っているように見えており、利用ケースは限定的になりそうに感じました(特に配置サブネット、デプロイ周りなど)。
とはいえ、これらはトレードオフの問題なので、今後のアップデートでカスタムドメインを上手く ECS の設定で扱えるようになったり、デプロイ方式を柔軟に設定できるようになれば、利用ケースは増えると思います。
現状はネットワークやドメイン周りなど、土台となっている AWS リソースのことを結局考えさせられる点が気になったので、大多数のユースケースで ECS のサービスページから上手く GUI 等で管理できるようになれば刺さるケースは多いと思います。
細かくカスタマイズしたくなったら通常の ECS として運用できる点もコンセプトとしては非常に良いと感じました。
また、しばらく App Runner に目立ったアップデートが無いですし、Copilot CLI に関しては一度メンテナンスモードと明確に表記されました。
今後のアップデートも考えると、これらのサービスよりは ECS Express Mode を採用しておく方がベターには思えています。
この点は現時点では何とも言えないため、追加情報があればまたブログで紹介したいと思います。
