はじめに
2026 年 7 月 1 日、AWS は Amazon ECS Express Mode に対して、カスタムタスク定義のサポートを発表しました。Express Mode で作成したサービスに独自のタスク定義を紐づけられるようになり、これまで自動生成されたタスク定義に限定されていた構成を、ユーザー自身の要件に合わせて拡張できることが大きな特徴です。
ECS で Express Mode を試したことがある方の中には、サイドカーコンテナを追加したい、カスタムヘルスチェックを設定したい、FireLens でログの送信先を切り替えたいといった要件に直面し、Express Mode の手軽さは魅力的でありながら本番導入を見送った経験がある方もいるのではないでしょうか。今回のアップデートは、その課題に直接応えるものです。
本記事では、何が変わったのか、どのような組織・チームにとって意味のあるアップデートなのか、そしてどのようなアーキテクチャでどう有効化すればよいのかを中心に解説します。ECS を運用しているエンジニアの方や、既存のワークロードを Express Mode へ移行することを検討している方を想定読者としています。
Express Mode とは
Amazon ECS Express Mode は、2025 年 11 月に発表された機能で、コンテナイメージとわずかな設定だけで ECS 上に本番相当のサービスを立ち上げられることを目的としています。サービスの作成には、次の 3 つの入力だけが必要です。
| 入力項目 | 内容 |
|---|---|
| コンテナイメージ | デプロイしたいアプリケーションのコンテナイメージ |
| タスク実行ロール | ECS がイメージの取得やログの書き込みを行うための IAM ロール |
| インフラストラクチャロール | ECS が ALB などの周辺リソースを作成・管理するための IAM ロール |
Express Mode はこれらの入力から、ALB によるロードバランシング、HTTPS 終端、Auto Scaling、CloudWatch によるモニタリングといった、通常であれば個別に設計・構築する必要があるコンポーネントを自動的に組み立てます。
ALB の共有によるコスト最適化
Express Mode の特徴的な仕組みの一つに、ALB の共有があります。ホストヘッダーベースのルーティングによって、最大 25 個の Express Mode サービスを 1 つの ALB にまとめることができ、サービスごとに ALB を個別に持つ場合と比べてコストを抑えられます。また、Express Mode によって作成されたリソースはすべてユーザーのアカウント内に存在し、コンソールや API から直接参照・変更できるため、手軽さと引き換えにブラックボックス化するといった心配をせずに使い始められる設計になっています。
これまでの前提: タスク定義は自動生成
一方で、Express Mode はこれまで、サービスの作成・更新時にタスク定義を自動生成する仕組みが前提となっていました。コンテナイメージや CPU、メモリ、環境変数といった基本的な設定は Express Mode 側の入力項目から調整できるものの、タスク定義そのものを自分で用意して差し替えるという使い方は想定されていませんでした。この前提が、次の章で紹介するアップデートによって変わることになります。
何が変わったのか
Express Mode がタスク定義をどのように扱っていたか、これまで意識したことがない方も多いかもしれません。実は、サービスの作成・更新時にタスク定義そのものを直接指定する手段はなく、コンテナイメージや CPU、メモリといった限られた入力項目から、Express Mode が内部的にタスク定義を生成していました。
| 項目 | 従来 | 今回のアップデート後 |
|---|---|---|
| タスク定義の指定方法 | Express Mode が入力項目から自動生成 | 既存のタスク定義をそのまま指定可能 |
| CI/CD・IaC との親和性 | 既存のタスク定義資産を持ち込めない | 既存パイプラインのタスク定義を再利用可能 |
| 高度な設定 | 非対応 | サイドカー、ヘルスチェック、FireLens などに対応 |
従来の課題
サイドカーコンテナを使ったオブザーバビリティやセキュリティの強化、コンテナ単位の詳細なヘルスチェック、FireLens によるログルーティングの切り替えといった構成は、Express Mode を使わずに ECS を運用してきたユーザーにとってはごく普通のものです。しかし、これまでの Express Mode では、自動生成されたタスク定義の範囲を超えることができず、こうした構成が必要になった時点で Express Mode の利用を諦めるか、ECS の通常のワークフローに移行するかを選ぶ必要がありました。
カスタムタスク定義のサポートによる解決
今回のアップデートでは、AWS CLI の create-express-gateway-service コマンドに --task-definition-arn オプションを渡すことで、既存のタスク定義を Express Mode サービスに紐づけられるようになりました。これにより、オブザーバビリティやセキュリティ用のサイドカーコンテナの追加、コンテナ単位での詳細なヘルスチェックの設定、ulimits や Linux ランタイム設定の調整、FireLens を使ったログの送信先のカスタマイズなど、これまで実現できなかった構成が可能になりました。
なお、カスタムタスク定義を一度 Express Mode サービスに紐づけた後も、運用方法を一方に固定する必要はありません。具体的な更新方法は第 6 章で扱いますが、タスク定義側を直接更新する形でも、Express Mode の API を通じて更新する形でも、どちらの方法でも継続してサービスを管理できます。ロードバランシングや Auto Scaling、カナリアデプロイといったインフラ面の管理は引き続き Express Mode が担うため、タスク定義の柔軟性とインフラ管理の手軽さを両方享受できる点が、このアップデートのポイントだと言えます。
この機能が必要なのはどんな組織か
カスタムタスク定義のサポートは、すべての Express Mode ユーザーに一律で恩恵があるわけではなく、特定のニーズを持つチームにこそ価値を発揮するアップデートです。導入を検討する前に、自分たちのケースに当てはまるかどうかを整理しておくと判断がしやすくなります。
この機能が活きるのは、既存の ECS ワークロードを Express Mode に移行したいが、サイドカーコンテナや FireLens などの構成をすでに使っているチーム、CI/CD パイプラインや IaC で管理しているタスク定義を Express Mode でも再利用したいチーム、そしてプラットフォームチームとして開発者に一定の観測性・セキュリティ要件を組み込んだタスク定義を配布したい組織です。逆に、シンプルなステートレスな Web アプリケーションや API をとにかく早く公開したいだけであれば、これまでの Express Mode の入力項目だけで十分なケースも多く、無理にカスタムタスク定義を持ち込む必要はありません。
カスタムタスク定義を Express Mode サービスに紐づける際には、コンテナ名やポートマッピングの形式など、いくつかの要件を満たす必要があります。詳しい要件と設計上の勘所は次章で扱います。
アーキテクチャ解説
カスタムタスク定義のサポートが「具体的に何を変えているのか」を、もう少し踏み込んで見ていきます。
ポイントは、Express Mode サービスの構造そのものが変わったわけではないという点です。ALB によるロードバランシング、Auto Scaling、CloudWatch によるモニタリング、カナリアデプロイといったインフラ面の管理は、これまでと同じく Express Mode が担い続けます。変わったのは、その配下で動く ECS タスクの定義を、Express Mode の自動生成に任せるか、ユーザー自身が用意したものを渡すかを選べるようになった、という一点です。
タスク定義の要件
ユーザーが用意するタスク定義は、以下の要件を満たす必要があります。
| 要件 | 内容 |
|---|---|
| コンテナ名 |
Main という名前のコンテナを 1 つ含む |
| ポートマッピング |
Main コンテナに単一の TCP ポートマッピング(ポート番号とポート名の両方)を設定する |
| 起動タイプ |
FARGATE との互換性が必要(EC2 起動タイプはそのままでは利用できない) |
| パラメータの排他性 |
taskDefinitionArn と、primaryContainer / executionRoleArn / taskRoleArn / cpu / memory は同じ API 呼び出しで同時に指定できない |
Express Mode は Main コンテナをアプリケーションの受信ポートとして扱い、ALB のターゲットグループに登録します。また、taskDefinitionArn を指定した場合、CPU やメモリ、実行ロールといった値はタスク定義から自動的に導出されるため、タスク定義の外側から個別に上書きする余地は残されていません。CPU・メモリの割り当てやロールの設定は、タスク定義自体の中で完結させておく必要があります。
サイドカーコンテナの追加
サイドカーコンテナを追加する場合は、Main コンテナと同じタスク内に定義するだけで済みます。awsvpc ネットワークモードのタスクでは、同一タスク内のコンテナが同じネットワーク名前空間を共有するため、オブザーバビリティエージェントやセキュリティエージェントを localhost 経由で Main コンテナと連携させるといった、通常の ECS で行われている構成をそのまま持ち込めます。
有効化の手順
実際にカスタムタスク定義を使って Express Mode サービスを作成する手順を見ていきます。ここでは AWS CLI での作成方法と、作成後の確認方法を中心に扱います。
タスク定義を用意する
まず、Main コンテナを含み、前章で紹介した要件を満たすタスク定義を、通常の ECS タスク定義として登録しておきます。サイドカーコンテナや FireLens の設定なども、このタスク定義の中で定義しておきます。
AWS CLI でサービスを作成する
登録したタスク定義の ARN を、create-express-gateway-service コマンドの --task-definition-arn オプションに渡します。
aws ecs create-express-gateway-service \
--infrastructure-role-arn arn:aws:iam::<account-id>:role/ecsInfrastructureRoleForExpressServices \
--task-definition-arn arn:aws:ecs:<region>:<account-id>:task-definition/<task-definition-family>:<revision> \
--health-check-path "/health" \
--monitor-resources
--task-definition-arn を指定する場合、--primary-container、--execution-role-arn、--task-role-arn、--cpu、--memory は同時に指定できません。これらの値はすべてタスク定義側から導出されます。--monitor-resources を付けておくと、リソースのプロビジョニング状況をそのまま確認でき、完了すると ARN や URL を含むサービス情報が返ってきます。
CloudFormation から作成する
AWS CloudFormation を使う場合は、AWS::ECS::ExpressGatewayService リソースの TaskDefinitionArn プロパティに、同様にタスク定義の ARN を指定できます。コンソールや Terraform、SDK でも同様のパラメータが提供される想定ですが、本記事執筆時点ではそれぞれの画面・フィールドの詳細までは確認できていません。導入の際は、お使いのツールのバージョンや公式ドキュメントを確認することをおすすめします。
既存サービスのタスク定義を更新する
すでに作成済みの Express Mode サービスに対しても、update-express-gateway-service コマンドに --task-definition-arn を渡すことで、後からカスタムタスク定義を紐づけたり、タスク定義のリビジョンを切り替えたりできます。
aws ecs update-express-gateway-service \
--service-arn <service-arn> \
--task-definition-arn arn:aws:ecs:<region>:<account-id>:task-definition/<task-definition-family>:<revision> \
--monitor-resources
create-express-gateway-service と同様、--task-definition-arn を指定する場合は --primary-container、--execution-role-arn、--task-role-arn、--cpu、--memory を同時に指定できません。タスク定義側で新しいリビジョンを登録し、その ARN をこのコマンドに渡すだけで、サービスに反映されます。
作成後の確認
サービスが ACTIVE になっているか、意図したタスク定義が使われているかを確認します。
| 確認項目 | コマンド・方法 |
|---|---|
| サービスの状態 | aws ecs describe-express-gateway-service --service-arn <service-arn> |
| デプロイの進捗 | aws ecs monitor-express-gateway-service --service-arn <service-arn> |
| 使用中のタスク定義 |
describe-express-gateway-service のレスポンスに含まれる taskDefinitionArn を確認 |
| アプリケーションの疎通 | 発行された URL(https://<service-name>.ecs.<region>.on.aws/)にアクセスして応答を確認 |
サービス作成後の運用は、タスク定義側の更新でも、上記の update-express-gateway-service でも、途中で切り替えることなく継続できます。
活用シーン
ここまでの内容を踏まえて、実際にどのような場面でこの機能が活きるのか、具体的なシナリオで見ていきます。
既存 ECS ワークロードの Express Mode への移行
CI/CD パイプラインでタスク定義 JSON を管理し、register-task-definition で新しいリビジョンを登録する運用をすでに行っているチームであれば、そのタスク定義の ARN をそのまま --task-definition-arn に渡すだけで、Express Mode の ALB 共有や Auto Scaling の恩恵を受けられます。Express Mode に合わせてタスク定義を作り直す手間や、パイプライン側の変更が最小限で済む点が大きなメリットです。
AWS Distro for OpenTelemetry(ADOT)によるオブザーバビリティ強化
アプリケーションのメトリクスやトレースを収集するため、ADOT Collector をサイドカーとして追加したいケースです。ADOT Collector は同一タスク内のサイドカーとして動作し、アプリケーションコンテナは http://localhost:4317 などのローカルエンドポイントにテレメトリを送るだけで済みます。この構成をそのままタスク定義に含めて Express Mode に渡せば、CloudWatch や AWS X-Ray、Amazon Managed Service for Prometheus といった収集先への連携を、Express Mode サービスでも変わらず利用できます。
FireLens による外部ログ基盤への転送
社内で Datadog や Splunk、Amazon OpenSearch Service といったログ基盤への集約が標準化されている組織にとっても有効です。FireLens 用の Fluent Bit サイドカーをタスク定義に含めておけば、アプリケーションコンテナのログドライバーを awsfirelens に設定するだけで、Express Mode サービスから出力されるログも同じログ基盤に統合できます。
まとめ
本記事では、Amazon ECS Express Mode のカスタムタスク定義サポートについて解説しました。既存のタスク定義をそのまま Express Mode サービスに紐づけられるようになったことで、サイドカーコンテナやカスタムヘルスチェック、FireLens によるログルーティングといった、これまで実現できなかった構成が可能になり、既存の ECS ワークロードや CI/CD 資産を活かしたまま Express Mode の手軽さを享受できるようになりました。
一方で、この機能はすべての Express Mode ユーザーに一律で必要というわけではありません。シンプルなステートレスアプリケーションを素早く公開したいだけであれば、これまで通り Express Mode の入力項目だけで十分なケースも多いはずです。カスタムタスク定義を利用する場合は、Main コンテナの命名やポートマッピング、FARGATE との互換性といった要件を満たす必要がある点も踏まえて導入を検討してください。
なお、本機能は追加コストなしで、Amazon ECS Express Mode が利用可能な全リージョンで利用できます。コンソールや Terraform など、CLI・CloudFormation 以外のツールでの対応状況については、導入前に最新の公式ドキュメントを確認することをおすすめします。