ECS Expressモードのメリット・デメリットについてお話しします

Posted at 2025-11-28

はじめに

先日、ECS Expressモードがリリースされました。

今回はこのモードのメリット・デメリットについて書いていきます。
なお、先日投稿しましたこのモードについての記事は以下のとおりです。

タスク実行ロールやインフラストラクチャーロールは必要なものの、その他の必須項目はコンテナイメージのみがあればデプロイできるというシンプルさがメリットと言えるでしょう。
App Runnerよりもシンプルかも。

・ACM、ALB、ECS、CloudWatchロググループなどを自動生成可能

・各種リソースはユーザー側のAWS アカウント内に作成され、マネジメントコンソールやCLIなどで変更可能

App Runnerと違い、ExpressモードはALBとECSという構成なのでWebSocketを利用できます。

ECS Expressモードはリクエストが無いときでも、CPU料金が発生する料金体系になっています。
一方、App Runnerはリクエストが無いときはPU料金が発生しません。

稀にリクエストがあるようなケースだとApp Runnerにコストメリットが出てきます。
ECS ExpressモードはALBを複数サービスで共有することを想定しているので、このようなユースケースではコストメリットが出てきます。
(今後のアップデートに期待)

・指定が無ければ default VPCのパブリックサブネットにALBとECSタスクが配置される。
　(これは仕方ないか)

・プライベートサブネットのみを指定すると Internal ALBとして構成されるため、
　そのままではインターネット公開できない
→CloudFront や API Gateway などを挟む必要がある
　(これはきちんと設定する必要がある)

・ALB と ECSタスクを別サブネットに分離する設計を採用できない

・パブリックサブネットとプライベートサブネットを両方含む設定にしてALBだけパブリックIPを持つ設定にすることもできない

・ECS にパブリック IP を付与する設定だとSecurity Hub上のルールに違反してしまう
→Security HubのHIGH以上に対応必須な環境などには不向き
(VPCを指定した場合もセキュリティグループ周りはいじらない方がいいかも)

デプロイ戦略がカナリア一択となっており、他のデプロイ戦略を選択することができない
→しかも5%→95％というもの一択となっており正直使いにくい
(メリットとしてはデプロイ自体はECSマネージドなものであるということ)

ECSのデプロイ戦略については先日投稿しました記事があるのでそれも貼っておきます。

CloudFormationについては、AWS::ECS::ExpressGatewayServiceを利用すれば Express MモードでECS サービスを作成可能

ただし、Expressモードで作成したサービスに対して、CloudFormationを介さずに変更を入れる必要がある
(IaCには不向き)

コスト面については「トレードオフの関係」と言っていいのかわかりませんが、ある程度シンプルに手数をかけずにできるサービスというのはコストはかかってきます。

あくまでも現状のExpressモードの建て付けは「ECS環境の作成を簡単に行える機能」ということです。
今後のアップデート、さらにはApp Runnerについてもアップデートを期待し、両方のサービスで使い分けがきちんとできるようになってくれると嬉しいです。