こんにちは。
本記事はJapan AWS Ambassador Advent Calendar 2025の7日目の記事です。
re:Inventの興奮冷めやまない中、皆さんいかがお過ごしでしょうか。
re:Inventではたくさんのアップデートがありましたが、2025年のECS関連のアップデートも負けず劣らず豊富でした。例を挙げるとECS Managed Instance, ネイティブBlue/Green対応などですね。
そこで本記事では2025年のECSのアップデートについて地味なものから大きなものまで振り返ってみたいと思います！
2月
02/20: タスク定義で指定可能なCPUハードリミットが増加（10vCPU->192vCPU)
ECS on EC2のタスクにてタスクサイズに指定可能なvCPUの上限が10から192に増加しました。これによりインスタンス内で10vCPUより大きいタスクを複数動かす場合にリソース競合（noisy neighbor）が発生するのを防げるようになりました。（なお、ECS on FargateのvCPU上限は今も変わらず16vCPUのままです。）
02/27: 新たなIAM条件キーが追加
ECSのIAM条件キーが新たに8つ追加されました。SCPでRegisterTaskDefinitionの条件キーにecs:priviledgedを設定しておいて、特権コンテナを含むタスク定義を作成させないとかよさそうですね。
| 条件キー | タイプ | 説明 |
|---|---|---|
| ecs:task-cpu | Numeric | タスクcpuの制限 |
| ecs:task-memory | Numeric | タスクmemoryの制限 |
| ecs:compute-compatibility | ArrayOfString | タスク起動タイプの制限（"FARGATE", "EC2", "EXTERNAL"） |
| ecs:privileged | String | 特権モードの制限 |
| ecs:auto-assign-public-ip | Bool | パブリックIP割り当ての制限 |
| ecs:subnet | ArrayOfString | サブネットの制限 |
| ecs:propagate-tags | String | タグ伝搬の制限 |
| ecs:enable-ecs-managed-tags | Bool | マネージドタグ付与の制限 |
4月
04/16: AWS BatchでECS ExecとFirelensがサポート
AWS BatchでECS ExecとFirelensがサポートされるようになりました。コンテナに入ってデバッグできなかったり、CloudWatch Logsのログ料金が嵩んでいた人にとってはうれしいアップデートですね。
5月
05/06: サービスの1-click手動ロールバックが可能に
ECSのデプロイでサービスの手動ロールバックがワンクリックでできるようになりました。従来までは新しいリビジョンでサービスを更新して失敗した際に、以前のリビジョンに手動で戻すためには、また新しいデプロイメントを開始する必要がありました。これがボタン一つでできるようになりました。
なお、手動を強調しているのは自動ロールバックはCloudWatch Alarm、あるいはサーキットブレーカを用いてこれまでもできたためです。自動ロールバックを待たずいち早く戻したい場合には有効でしょうか。
05/14: ECSにアタッチするEBSのファーストタッチペナルティをプロビジョンドレートで緩和可能に
ECSではEBSのスナップショットからタスクにボリュームをアタッチできますが、
スナップショットを復元した直後に大きなI/O遅延が発生します。
「ファーストタッチペナルティ」と呼ばれ、各ブロックの初回アクセス時にスナップショットが保存されているS3からデータをプルダウンするために発生します。
EBSの「ファーストタッチペナルティ」を防ぐ機能としてFSR（Fast Snapshot Restore）があり、スナップショットであらかじめ有効化しておくことで、「ファーストタッチペナルティ」なしでEBSを復元することができました。一方でFSRは時間課金で料金が発生するのが難点でした。
そんななか2025年5月に発表されたのがEBSのプロビジョンドレートです。これは初期化の速度を指定してスナップショットからEBSのボリュームを作成できるものです。「ファーストタッチペナルティ」をなくすことはできませんが、復元時に速度に応じてコストがかかるだけなのでFSRと比較してコストの抑制を期待できます。EBSのプロビジョンドレートをECSでサポートしたというのが本アップデートになります。
05/20: InspectorでECSで使用しているイメージをマップ可能に
以下に示すように、Inspectorの画面から当該のコンテナイメージがどのECSで利用されているか確認できるようになりました。
こうしてコンテナイメージの脆弱性評価の結果を元に影響範囲を特定できるのはすごくいいですよね。なお、Inspectorの表示はリアルタイムというわけではなく、1日に1回程度の更新なので注意が必要です。
05/22: コンテナの終了メッセージが最大1024文字に
1024文字になる前は255文字でした。終了メッセージが途中で切れて原因わからないじゃん！ということはよくあったのでうれしいアップデートですね。
05/30: MCPサーバが登場
ECSのMCPサーバが登場しました。Toolの一覧はこちらをどうぞ。
06/13: サービスでキャパシティプロバイダ戦略の更新が可能に
ECSサービスのキャパシティプロバイダ戦略の更新が可能になりました。以前は稼働する基盤をFargateからEC2に（あるいは逆に）変更したい場合は、サービスを再作成する必要がありましたがその必要がなくなりました。
06/18: ECRでECSで使用しているイメージをマップ可能に
5月のInspectorのアップデートにつづきECRの画面からも、コンテナイメージがどのクラスタで使われているのかわかるようになりました。
7月
07/01: ヘルス障害サービスイベントにタスクIDが含まれるように
タスクIDが含まれることで障害時の対象の特定を迅速に行えるようになりました。
07/02: ECS最適化AMIにWindows Server 2025が追加
Windows Server 2025のECS最適化AMIがリリースされました。
2025-coreと2025-Fullの二つのプラットフォームが提供されています。
07/04: SOCI Index v2のマニフェストに対応
SOCIはSeekable OCIの略でコンテナの起動を高速化する技術です。コンテナイメージのダウンロード完了を待つのではなく最低限必要なデータが揃ったらコンテナを起動してしまい、その他のデータは遅延読み込みすることで高速化を実現します。
SOCIによるコンテナ起動の高速化 (@_takahash) - Speaker Deck
そのSOCIがv2になって堅牢性が向上し、SOCI利用時のデフォルトになりました。本アップデートはそれに追従するものです。
07/17: ECSネイティブなBlue/Greenデプロイが可能に
ECSはこれまでもサービスのBlue/Greenデプロイを行うことが可能でしたが、実施にはCodeDeployの設定が必要となり、なおかつService Connectには対応していませんでした。
本アップデートでCodeDeployなしでサービスのBlue/Greenデプロイを行うことが可能になりました。また、Service Connectについても対応されました。Service ConnectのBlue/Greenの挙動については以下に記事にしているので良ければご覧ください。
この時点ではリニアデプロイ（決められた割合ずつトラフィックを段階的に移す）、カナリアデプロイといった複雑なデプロイには対応していなかったため、公式でCodeDeployよりこちらが推奨とはいっていても対応するまで利用は限定的だと思っていました。
9月
09/30: IPv6-Onlyサポートの開始
IPv6オンリーで使えるようになりました。
09/30: ECSマネージドインスタンスのリリース
ECSのコンテナの実行環境の選択肢として昔からEC2とFargateがありましたが、第三の選択肢としてECSマネージドインスタンスが追加になりました。マネージドインスタンスではGPUや高速ネットワーキングなどFargateでは難しかったワークロードに対応でき、なおかつEC2の管理・運用をAWSにオフロードすることができます。
一方でFargateの上位互換というわけでもなく今後は3つの選択肢から適切なものを選ぶ流れだと思っています。その辺の話は過去に登壇して話したので良ければご覧ください。
10月
10/02: マネジメントコンソールでのイベントキャプチャとイベント履歴クエリのサポートに対応
これまではECSのイベント履歴を調査したい場合、EventBridgeとCW Logsを自前で構築し、クエリはCloudWath Logs Insightで行うなどの対応が必要でした。このアップデートによって、ECSのマネジメントコンソールからワンクリックでEventBridgeとCW Logsを構築でき、クエリもECSのサービスのタブから直感的に行えるようになりました。
10/14: FirelensのFluent Bitがv4.1.1に対応（AWS for Fluent bit 3.0.0）
Fluent Bit 4.1.1 をベースにした AWS for Fluent Bit 3.0.0 が登場しました。これが出るまでFirelensのログルータは2022年12月にEOLを迎えたFluent Bit 1.9.10がベースとなっていました。つまりOTelを用いたテレメトリの送受信などFluent Bitのv2以降で対応している機能がもともろ使えませんでした。v2以降の機能を使いたい場合は、自前でコンテナイメージを管理するしかなく負担になっていました。
10/15: Firelensをnon-rootで実行可能に
Firelensをroot以外のユーザで実行することが可能になりました。タスク定義は以下のように指定します。
{
"containerDefinitions": [
{
"name": "log_router",
"image": "906394416424.dkr.ecr.us-west-2.amazonaws.com/aws-for-fluent-bit:stable",
"firelensConfiguration": {
"type": "fluentbit"
},
"user": "1000",
"essential": true
}
]
}
10/21: ECSエージェントが発行するAPIをCloudTrailのデータイベントとして記録可能に
ECSエージェントが発行する下表のAPIをCloudTrailデータイベントとして記録できるようになりました。コンプライアンス用件で求められる場合や、ECSエージェントとコントロールプレーンとの接続障害を切り分けたい場合に有用そうです。
| API | Description |
|---|---|
| ecs:Poll | ECSエージェントがタスクをポーリングする際のアクティビティ |
| ecs:StartTelemetrySession | テレメトリセッション開始時のアクティビティ |
| ecs:PutSystemLogEvents | ECS Managed Instancesのログ送信アクティビティ |
10/30: Service Connectエージェントのアクセスログを出力可能に
これまでService Connect（実態はEnvoy）のアプリケーションログを出力することができていましたが、新たにアクセスログも出力できるようになりました。コンプライアンス用件で求められる場合や、通信障害の切り分け字に有用そうです
10/31: 線形デプロイ/カナリアデプロイをネイティブでサポート
07/17にBlue/Greenをネイティブで実行可能になったのに引き続き、線形デプロイやカナリアデプロイも行えるようになりました。これによりCodeDeployによるデプロイの優位性はなくなった認識でいます。
11月
11/7: ローリングデプロイ中に障害が発生した場合の可用性の改善
新バージョンのローリングデプロイ中に現行バージョンのタスクがUnhealthy状態になった場合、タスクは新バージョンのにこれまで置き換えられていました。このため、新バージョンに問題がある場合可用性の低下を招く恐れがありました。このアップデートにより、置き換え先のタスクのバージョンは旧バージョンのものになり不安定化を防ぐような挙動になりました。
11/15: 非ルートユーザによるEBSボリュームマウントのサポート
コンテの実行ユーザがrootじゃなくてもEBSをマウントできるようになりました。
11/15: ECS Express Modeの発表
イメージをあらかじめECRにPushしておけば、複雑な設定などなしにECS上でアプリケーションを動かせる機能です。ECSクラスタやタスク定義、セキュリティグループなどはAWSが全部作成してくれます。Expressモードで作成されたリソースの設定は編集ができるので、ひとまずExpress Modeでアプリを公開しておいて、あとから作成されたリソースの設定をチューニングするような使い方が可能です。
11/15: 「Amazon Qで検査」ボタンの実装
タスクの起動失敗などのエラーメッセージマネジメントコンソールに表示された場合に、「Amazon Qで検査（Inspect with Amazon Q）」ボタンが表示されるようになりました。これによりAIを活用したトラブルシューティングを容易に行えるようになりました。
11/22: フルマネージドリモートECS MCPサーバの発表（プレビュー）
ローカルにMCPサーバを立てることなく、リモートのMCPサーバを利用できるようになりました。端末にソフトウェアのインストールを自由にできないような場合などに有効ですね。ローカルの認証情報は直接リモートMCPサーバーに送信されるのではなく、ローカルのaws-mcp-proxyが認証情報を使用してリモートサービスに安全に接続する仕組みになっています。
12月
12/2: GuardDutyの拡張脅威検出をサポート
GuardDutyの拡張脅威検出は、検出されたFindingsの関連性を分析してまとめてくれる機能です。EKSで先行して導入されていましたが、それがECSにも来ました。利用料は無料でデフォルトで有効化されます。
まとめ
2025年のECSのアップデートを大小問わず振り返ってみました！
今までの設計論や運用論に変更が加わるものも多かった印象で、特に触れていないものはこれからしっかりキャッチアップしていこうと思います。
本記事が何かのお役に立てば幸いです！