Amazon ECS本番運用Vol1｜ECS Anywhere/Blue-Green/Managed Instances

1. ECS高度運用の全体像と本記事の差別化

Amazon ECSは2021年のECS Anywhere登場以来、2024〜2025年にかけてネイティブBlue/Greenデプロイ・ECS Managed Instances・1-click rollback・custom container stop signalsといった機能を次々と追加し、コンテナオーケストレーション基盤としての射程を大きく広げています。Fargate・ECR・Service Connectを軸とした基礎構成を整えたあと、実際の本番運用フェーズに入ると「どのコンピュートモデルを選ぶか」「オンプレミス資産をどう統合するか」「デプロイをいかに安全に続けるか」「クラスタキャパシティをどう自動化するか」という設計上の問いが次々と現れます。本記事はその問いに対する設計判断軸を整理した応用編です。

1-1. 本記事の射程と既存Vol1との境界

前提記事「Amazon ECS 本番運用 Vol1」では、ECS基礎の全容を解説しています。本記事では以下の内容は扱いません。

前提記事をまだお読みでない方は、先にそちらで基礎を固めてから本記事をご覧ください。

本記事が扱うのは次の5軸です。

軸1 — ECS Anywhere（§2）

EXTERNAL起動タイプを使い、オンプレミスのサーバや他クラウドの仮想マシンをECSコントロールプレーンに接続してタスクを実行する仕組みです。

• 外部インスタンスの登録手順（SSM Agent + ECS container agent + Dockerインストール）
• hardware fingerprintベースのIAM認証情報の自動ローテーション（約30分ごと）
• EXTERNAL起動タイプのネットワーク考慮（awsvpc不可・bridge/hostモード選択）
• $0.01025/外部インスタンス時間の料金設計とderegister管理
• ハイブリッド運用パターン（Fargate + EXTERNAL混在・段階移行・CI/CD統一）

軸2 — ECS Managed Instances（§3）

2025年9月30日にGA（一般提供）となった新コンピュートモデルです。EC2インスタンスを使いながら、プロビジョニング・OSパッチ・スケーリング・ライフサイクル管理をAWSが担います。

• AWSが管理する範囲（プロビジョニング・OSパッチ14日サイクル・スケーリング）
• Fargate・EC2起動タイプ・ECS Anywhereとの責任分界点比較
• Capacity Provider の定義方法（デフォルト最適選択 vs GPUインスタンス指定）
• いつManaged Instancesを選ぶか（使い分けの判断軸と回避すべきシーン）
• 2025年12月のEC2 Spot対応とコスト最適化への影響

軸3 — コンピュートモデルの意思決定（§4）

5系統のコンピュートモデルを比較し、ワークロード特性に応じた選択基準と混在戦略を整理します。

• 5モデル（Fargate / Fargate Spot / EC2起動タイプ / Managed Instances / ECS Anywhere）の全体マップ
• 意思決定木（配置場所 → EC2管理度合い → Spot活用可否 の3ステップ）
• 混在戦略パターン（Fargate + Spot / EC2 + Managed Instances / Anywhere + Fargate）
• コスト最適化の組み合わせ効果（Graviton + Spot で最大76%削減）

軸4 — ネイティブECS Blue/Greenデプロイ（§5）

2025年7月にリリースされた、ECSデプロイコントローラー内蔵のBlue/Green機能です。CodeDeploy不要でトラフィックシフトを実現します。

• ALL_AT_ONCE・CANARY・LINEARの3トラフィックシフト戦略（CANARYとLINEARは2025年10月追加）
• deployment lifecycle hooks（BeforeTrafficShift・AfterTrafficShift）によるLambda自動検証
• bake time設定とダウンタイムなしロールバックの設計
• CodeDeploy版との比較（deployment controller・TG数・セットアップ難度・適合シーン）
• ALB / NLB / ECS Service Connect との連携

軸5 — EC2 managed scalingとデプロイ安全機構の2025差分（§6・§7）

§6ではEC2クラスタキャパシティの自動調整、§7では2024〜2025年に追加された安全機構の差分を扱います。

• targetCapacityの設計（100 vs 70〜90のトレードオフ・Warm Poolとの組み合わせ）
• managed termination protectionによるスケールイン保護の仕組み
• FARGATEおよびFARGATE_SPOTへのmanaged scaling非適用の明確化
• 1-click rollbackとbake timeによる人的判断ロールバック
• custom container stop signalsによるアプリ停止シグナルのカスタマイズ（2025年12月）
• Graviton(ARM64) Fargate Spotの活用（2024年9月対応）

1-2. 想定読者と持ち帰れる設計判断軸

本記事の想定読者は主に3つの立場です。

ECSで本番サービスを運用するプラットフォームエンジニア・SRE にとっては、既存Fargate/EC2構成からManaged Instancesへの移行可能性の評価基準（カスタムAMI要否・14日タスク継続上限・GPUの有無）、ネイティブBlue/Greenへの切り替えコスト・メリットの試算（CodeDeploy廃止による設定削減と新設定の対応範囲）、1-click rollbackとbake timeを組み合わせた多層防御のデプロイ設計、custom container stop signalsによるgraceful shutdown制御の実装、EC2 ASG Capacity ProviderのtargetCapacity設計指針が主な目的になります。

ハイブリッドクラウド基盤・エッジ運用を担当するインフラエンジニア にとっては、ECS AnywhereによるオンプレとAWSクラウドの統合運用パターン（§2の推奨パターン1〜3）と、外部インスタンスのIAM認証情報ローテーション・セキュリティ設計・コスト試算の実務知識が主な目的です。ECS Anywhereとは別物であるECS Managed Instances（§3）との技術的差異を正確に理解し、設計段階での混同を防ぐことが特に重要です。

AWS認定試験（DVA-C02・DOP-C02・SAP-C02）を準備している方 にとっては、ECS Anywhereのアーキテクチャ（EXTERNAL起動タイプ・SSM Agent認証・hardware fingerprintローテーション・料金$0.01025/インスタンス時間）、ECS Managed Instancesの位置づけ（Bottlerocket AMI・14日サイクルパッチ・カスタムAMI不可・2025年9月30日GA）、ネイティブBlue/GreenとCodeDeploy版の比較（deployment controller・TG数・設定難度・適合シーン）、EC2 managed scalingとFargate Service Auto Scalingの切り分けが頻出論点です。

本記事を読み通すことで得られる設計判断軸は4つです。

1. 配置場所の選択基準: AWSリージョン内で完結するか、オンプレミス・エッジへの延伸が必要かという配置場所の判断（§2・§4の意思決定木を活用）
2. EC2管理の委譲範囲: AMIパッチ・スケーリング・ライフサイクルをどこまでAWSに委譲するかという運用負荷とのトレードオフ評価（§3・§4の比較表を活用）
3. デプロイの多層防御設計: トラフィックシフト戦略・lifecycle hooks・bake time・自動/手動ロールバックという複数の安全層を組み合わせた設計（§5・§7）
4. クラスタキャパシティの自動化: EC2 ASG Capacity ProviderのtargetCapacityによる設計と、FargateのService Auto Scalingとの適用範囲の違い（§6）

目的に応じて次の順序で読み進めることも効果的です。

1-3. 2024〜2025年のECS進化と本記事の位置づけ

Amazon ECSは2024〜2025年にかけて次の主要機能を追加しています（東京リージョン含む全商用リージョンで利用可能、2026年7月時点）。

これらの進化のベクトルを読むと、ECSの拡張方向が明確になります。「どこでコンテナを動かすか（Managed Instances・ECS Anywhere）」「どう安全にバージョンを切り替えるか（ネイティブBlue/Green）」「問題発生時にどう速く戻すか（1-click rollback）」「停止時にアプリが正しく終了できるか（custom stop signals）」「コストをどう最適化するか（Graviton Fargate Spot・Managed Instances Spot）」という5つの問いに対して、それぞれ具体的な機能が追加されています。AWSのECSへの投資は2026年7月時点でも継続しており、EOLやメンテナンスモードではありません。

これらの機能は互いに補完的です。Managed Instancesで本番環境を動かしながらネイティブBlue/Greenで安全にデプロイし、問題時は1-click rollbackで即時復旧し、コンテナ停止時のgraceful shutdownをcustom stop signalsで制御するという組み合わせが実践的です。本記事を通読することで、こうした5軸の統合設計パターンを把握できます。

ECS本番運用 Vol1（基礎構成）の上に本記事の5軸（ECS Anywhere・Managed Instances・コンピュートモデル選択・ネイティブBlue/Green・managed scaling・安全機構差分）を組み合わせることで、ECSを「立ち上げて安定稼働させる基盤」から「安全に変化し続けられる本番基盤」へ進化させる設計判断の全体像が揃います。本記事を設計チェックリストや技術選定の参考資料として活用してください。

なお、Amazon ECSのコントロールプレーン自体は無料です（タスクの実行リソース課金のみ）。ECS Anywhereだけは外部インスタンスに対して$0.01025/インスタンス時間が別途発生します。各機能の最新料金はAWS公式の価格ページで確認してください。

各章の内容は独立して読み進めることができ、設計フェーズや担当領域に応じて必要な§から参照してください。

2. ECS Anywhere — EXTERNAL起動タイプによるオンプレ・ハイブリッド運用

2-1. ECS Anywhereとは — EXTERNAL起動タイプの位置づけとユースケース

ECS Anywhereは、オンプレミスのサーバや他クラウドの仮想マシンをAmazon ECSのコントロールプレーンに接続し、統一されたAPIとツールセットで管理できるサービスです。2021年に一般提供が開始されて以来、データ主権の要件やレイテンシ制約を持つワークロードのコンテナ化を実現する手段として活用されています。

ECS Anywhereの技術的な核心は「EXTERNALという専用の起動タイプ」にあります。Fargateがサーバレス、EC2がAWS内のEC2インスタンスを使うのに対し、EXTERNALはAWS外部の任意のサーバにタスクを配置します。ECSクラスターは通常どおり東京リージョン（ap-northeast-1）に作成しますが、そこへ登録する「外部インスタンス」の実体はオンプレミスのラックに置かれたサーバや、他クラウドの仮想マシンでも構いません。

ECS Anywhereが解決する主なユースケースは3つあります。第一はデータ主権・コンプライアンス要件です。規制産業では特定のデータをAWS外のオンプレミス設備に留める義務がある場合があり、コンテナオーケストレーション自体はAWSのコントロールプレーンに集約しながら、データ処理は設備内で完結させられます。第二は低レイテンシ・エッジ処理です。製造ラインの品質検査や小売店舗のリアルタイム在庫管理など、ネットワークレイテンシが数十ミリ秒以内でなければならないユースケースでは、オンプレミスでの処理が不可欠です。第三は既存オンプレ資産の漸進的移行です。まず既存サーバ群をECSに接続してコンテナ管理を統一し、その後段階的にFargateやEC2へ移行するロードマップを取ることができます。

なお、ECS Anywhereと§3で解説するECS Managed Instancesは明確に別物です。ECS AnywhereはAWS外部の任意サーバを対象とし、ECS Managed InstancesはAWSがライフサイクルを管理するEC2インスタンスを対象とする2025年の新コンピュートモデルです。混同しないよう注意してください。

2-2. 外部インスタンスの登録手順

外部インスタンスをECSクラスターに登録するには、対象サーバに3つのコンポーネントをインストールします。SSM Agent（AWS Systems Manager Agent）、ECS container agent、そしてDockerランタイム（またはcontainerd）です。SSM Agentが認証と通信チャネルを担い、ECS container agentがタスクの起動・停止を実行します。

登録の流れは次のとおりです。まずAWS CLIでアクティベーションコードとアクティベーションIDを払い出します。

aws ssm create-activation \
  --iam-role ECSAnywhereInstanceRole \
  --registration-limit 10 \
  --region ap-northeast-1

このコマンドは ActivationId と ActivationCode を返します。次に対象サーバでAWSが提供するインストールスクリプトを実行します。

curl --proto "https" --tlsv1.2 -sSf \
  https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install.sh \
  | sudo bash -s -- \
 --cluster my-hybrid-cluster \
 --activation-id <ActivationId> \
 --activation-code <ActivationCode> \
 --region ap-northeast-1

スクリプトはSSM AgentとECS container agentのインストール・起動、Dockerが未導入であればインストールを行い、最後にSSMアクティベーションを使ってECSクラスターに外部インスタンスを登録します。

外部インスタンス用のIAMロール（ECSAnywhereInstanceRole）には、AmazonEC2ContainerServiceforEC2Role・AmazonSSMManagedInstanceCore・AmazonEC2ContainerRegistryReadOnly の3ポリシーをアタッチします。これにより外部インスタンスはECRから非公開イメージをプルし、ECSコントロールプレーンと通信できます。

登録後、AWS Management Consoleの「ECS → クラスター → インスタンス」タブや次のCLIコマンドで外部インスタンスの状態を確認できます。

aws ecs list-container-instances \
  --cluster my-hybrid-cluster \
  --filter "attribute:ecs.os-type==linux"

ステータスが ACTIVE になれば、EXTERNALタスクを配置できる状態です。

2-3. IAM認証情報のローテーションとセキュリティ設計

ECS Anywhereの外部インスタンスは、物理的なハードウェアの識別情報（hardware fingerprint）をベースにした認証メカニズムを採用しています。SSM AgentがフィンガープリントをAWS SSMに送信し、SSMがIAM認証情報（一時的なアクセスキー・シークレットキー・セッショントークン）を発行します。この認証情報は約30分ごとに自動ローテーションされるため、漏洩時のリスクウィンドウが小さく抑えられます。

ローテーションは完全に自動で、オペレーターが操作する必要はありません。ただしSSM Agentが正常に稼働していることが前提です。SSM Agentが停止・通信断すると認証情報の更新が止まり、やがて期限切れとなってタスクの起動・停止操作が失敗します。SSM Agentの死活監視をCloudWatch AgentやDatadog等で行い、停止を即座に検知できる体制が必要です。

セキュリティ設計上のポイントが3点あります。

第一に、外部インスタンスとECSコントロールプレーン間の通信はSSM Session Manager経由（TCPポート443のみ）で行われます。そのため外部インスタンスからインターネットへのアウトバウンドHTTPS（またはVPCエンドポイント）が必要です。オンプレミスファイアウォールで443番ポートをSSMエンドポイント（ssm.ap-northeast-1.amazonaws.com 等）へのみ許可する構成が推奨です。

第二に、外部インスタンスはECS container agentを通じてのみAWS APIにアクセスするため、インスタンス上でAWS CLIを直接実行するような構成は最小化すべきです。インスタンス上の追加IAM操作を禁止し、必要な権限はタスクロール（Task Role）で付与する設計が望ましいです。

第三に、アクティベーションコードとアクティベーションIDは registration-limit の範囲で複数回使用できるため、払い出し後は安全な場所に保管し、不要になり次第 aws ssm delete-activation で無効化します。

2-4. EXTERNAL起動タイプのタスク配置とネットワーク考慮

ECSタスク定義でEXTERNAL起動タイプを指定するとき、ネットワークモードの選択が重要です。awsvpcモードは外部インスタンスでは利用できません。awsvpcはAWS VPC内のENI（Elastic Network Interface）をタスクに直接アタッチするモデルですが、外部インスタンスはVPC外に存在するためENIを持てません。

外部インスタンスでは主にbridgeモードまたはhostモードを使用します。bridgeモードはDockerの仮想ブリッジネットワーク（docker0）を使い、タスク間の通信をブリッジ経由で行います。ホストのポートを動的に割り当てるため、同一ホスト上で複数のタスクが同じコンテナポートを使う場合は動的ポートマッピング（hostPort: 0）を活用します。hostモードはコンテナがホストのネットワーク名前空間を直接使用するため最も高いネットワーク性能が得られますが、ポート競合のリスクが高まります。ワークロードの要件と多重度に応じて選択してください。

タスク配置戦略もEXTERNAL特有の考慮が必要です。外部インスタンスにはカスタム属性を付与でき、タスク配置時に属性フィルタを使って特定のハードウェア（GPU搭載機など）へのスケジューリングが可能です。

aws ecs put-attributes \
  --cluster my-hybrid-cluster \
  --attributes \
 "name=zone,value=onprem-osaka-dc1,targetId=<container-instance-id>"

これによりタスク定義のplacement constraintsで attribute:zone == onprem-osaka-dc1 と指定し、大阪DC1のインスタンスのみにタスクを配置できます。ラック・電源系統・ハードウェアスペックに応じた属性設計を行うことで、精密な配置制御が実現します。

EXTERNALタスクの配置をサービスとして定義する場合は、ECSサービスの launchType に EXTERNAL を指定します。以下はCLIでEXTERNALサービスを作成するパラメータの例です。

{
  "cluster": "my-hybrid-cluster",
  "serviceName": "edge-processor",
  "taskDefinition": "edge-processor:3",
  "launchType": "EXTERNAL",
  "desiredCount": 2,
  "placementConstraints": [
 {
"type": "memberOf",
"expression": "attribute:zone == onprem-osaka-dc1"
 }
  ],
  "placementStrategy": [
 {
"type": "spread",
"field": "instanceId"
 }
  ]
}

placementStrategy に spread を指定することで、複数の外部インスタンスへタスクを均等に分散できます。単一ノード障害時の影響を最小化するため、本番環境では2台以上の外部インスタンスへの分散配置を推奨します。

タスク定義では requiresCompatibilities に ["EXTERNAL"] を設定し、ネットワークモードは bridge を指定します。

{
  "family": "edge-processor",
  "requiresCompatibilities": ["EXTERNAL"],
  "networkMode": "bridge",
  "taskRoleArn": "arn:aws:iam::123456789012:role/EdgeProcessorTaskRole",
  "containerDefinitions": [
 {
"name": "processor",
"image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/edge-processor:latest",
"memory": 512,
"portMappings": [
  { "containerPort": 8080, "hostPort": 0 }
]
 }
  ]
}

hostPort: 0 とすることでDockerが空きポートを動的に割り当てます。外部インスタンスへのロードバランシングが必要な場合は、ALBのターゲットグループをIPタイプで作成し、外部インスタンスのIPアドレスを登録します。外部インスタンスはVPC外に存在するため、ALBとの経路（VPN・Direct Connect等）を確保したうえで、ターゲットのヘルスチェックが外部インスタンスまで到達できることを確認してください。

2-5. 料金モデルとコスト設計・監視

ECS Anywhereの料金体系はシンプルです。$0.01025 / 外部インスタンス・時間（1分最小課金）が追加費用として発生します。例えば、24時間365日稼働する外部インスタンスが10台あれば、月額でおよそ$75.5（10台 × $0.01025/時間 × 24時間 × 30日）になります。ECS自体のコントロールプレーン使用料は通常どおり無料ですが、ECS Anywhere登録中のインスタンス数に対してこの料金が加算されます。

課金はインスタンスのregister（登録）からderegister（登録解除）の期間に基づきます。インスタンスをderegisterせずに電源を落とすだけでは課金が継続する点に注意が必要です。不要になった外部インスタンスは必ず次のコマンドで登録解除します。

aws ecs deregister-container-instance \
  --cluster my-hybrid-cluster \
  --container-instance <container-instance-id> \
  --force

1アカウント・1リージョンあたり1,000インスタンス超から登録インスタンスにAWS Systems Manager managed instance料金が追加で発生する可能性があります。大規模なオンプレ運用を想定する場合はService QuotaとSSM料金体系を事前に確認してください。

コスト監視にはCost Explorerで「Amazon ECS」サービスフィルタを利用します。外部インスタンスにタグ（例：ecs-anywhere: true）を付けておくと、ECS Anywhere固有のコストをチームごとに追跡しやすくなります。登録インスタンス数の推移はSSMのマネージドインスタンスカウントからも把握できるため、定期的に棚卸しを行い、不要なままregisteredになっているインスタンスを解除する運用が重要です。

以下はECS Anywhere利用料の月次コスト概算です（2026年7月時点の料金）。

ランニングコストは台数に比例するため、年間スケールで見るとオンプレサーバの電力・保守コストと比較した総所有コスト（TCO）分析が導入判断の材料となります。ECSコントロールプレーン自体の料金は0円であるため、EC2インスタンスの費用が不要な点もコスト優位性の一つです。

2-6. ハイブリッド運用パターンとアンチパターン

推奨パターン1: Fargate + EXTERNAL のコンテナ一元管理です。ステートレスなAPIレイヤーはFargateで、データ処理ロジックはオンプレのGPUサーバ（EXTERNAL）で動かし、ECSクラスターとECRリポジトリは共有します。CI/CDパイプラインは1本に統一でき、デプロイ手順やイメージ管理の方法が共通化されます。ECSクラスター単位でCloudWatchダッシュボードを構成すれば、FargateタスクとEXTERNALタスクを同一画面で監視できます。

推奨パターン2: 段階的クラウド移行のゲートウェイです。既存オンプレサーバをEXTERNALとして接続した後、負荷のピーク時だけFargate/EC2起動タイプのタスクをスケールアウトします。外部インスタンスで常時稼働するベースロードをカバーしつつ、クラウドでバーストを吸収するコスト効率の高い構成です。段階的にオンプレのワークロードをFargateへ移行するロードマップを実現しやすくなります。

アンチパターン1: ECS Anywhereを永続的解決策として過信することは避けてください。ECS Anywhereはオンプレ資産の移行期間や特定のデータ主権要件に対して有効ですが、オンプレサーバのプロビジョニング・OSパッチ・ハードウェア保守は依然として自前で行う必要があります。EC2やFargateへ移行できるワークロードは積極的に移行し、EXTERNAL起動タイプを使い続けるケースを最小化することがトータルの運用コスト削減につながります。

推奨パターン3: CI/CDパイプラインの統一です。Fargate向けのデプロイパイプライン（GitHub Actions / CodePipeline）をそのままEXTERNALタスクにも適用できます。コンテナイメージのビルドとECRへのプッシュは共通のステップで行い、aws ecs update-service によるサービス更新コマンドも起動タイプを問わず同一の構成が使えます。オンプレ固有のデプロイ手順と二重管理になることを避け、ECS APIを通じた統一デプロイに集約することが運用の複雑度を下げる鍵です。

アンチパターン1: ECS Anywhereを永続的解決策として過信することは避けてください。ECS Anywhereはオンプレ資産の移行期間や特定のデータ主権要件に対して有効ですが、オンプレサーバのプロビジョニング・OSパッチ・ハードウェア保守は依然として自前で行う必要があります。EC2やFargateへ移行できるワークロードは積極的に移行し、EXTERNAL起動タイプを使い続けるケースを最小化することがトータルの運用コスト削減につながります。

アンチパターン2: 外部インスタンスをderegisterしないまま廃棄することも注意が必要です。廃棄したサーバがECSクラスターにDRAININGステータスで残り続け、課金と監視ノイズの原因になります。サーバ廃棄のRunbookにECS deregister手順を必ず含め、deregister後にSSMアクティベーションも削除する流れを自動化することを推奨します。

3. ECS Managed Instances — 2025年の新コンピュートモデル

3-1. ECS Managed Instancesとは — 登場背景とAWSの管理範囲

Amazon ECS Managed Instances（以下、Managed Instances）は、2025年9月30日にGA（一般提供）が開始されたAmazon ECSの新しいコンピュートモデルです。EC2インスタンスを使ったコンテナ実行の柔軟性を持ちながら、インスタンスのプロビジョニング・OSパッチ・スケーリング・ライフサイクル管理をAWSが担う「フルマネージドEC2」という位置づけです。2025年10月に全商用リージョンへの展開が完了し、東京リージョン（ap-northeast-1）でも利用できます。

Managed Instancesが登場した背景には、従来の選択肢が持つトレードオフがありました。Fargateはインフラ管理が不要な反面、GPUや特殊インスタンスタイプが利用できず、高メモリ・高帯域の大規模ワークロードを収容できないケースがありました。一方、EC2起動タイプ（自前ASG）はインスタンス選択の自由度が最大ですが、AMIのパッチ適用・ASGのライフサイクル管理・ECS container agentのバージョン管理など、EC2レイヤーの運用負荷が課題でした。Managed Instancesはこの「Fargateの運用コスト」と「EC2の柔軟性」を両立させるモデルです。

★重要: Managed InstancesはECS Anywhere（§2）とは全くの別物です。ECS AnywhereはAWS外部のサーバ（オンプレ・他クラウド）をECSコントロールプレーンに接続する仕組みですが、Managed InstancesはAWSがAWSリージョン内のEC2インスタンスを管理する仕組みです。タスク定義のrequiresCompatibilitiesで指定するキーワードも異なります（ECS Anywhere = EXTERNAL、Managed Instances = MANAGED_INSTANCES）。設計時に混同しないよう注意してください。

AWSが管理する範囲

Managed InstancesでAWSが担う運用責任は4つの柱に整理できます。

プロビジョニングと最適なインスタンス選択

デフォルトのCapacity Providerでは、タスク定義に指定したCPU・メモリ要件に基づき、AWSが最もコスト最適化された汎用EC2インスタンスタイプを自動選択して起動します。カスタムCapacity Providerを使えば、GPUアクセラレータ（NVIDIA/AMD）・CPU製造元（Intel/AMD/Graviton）・高ネットワーク帯域・特定のインスタンスファミリーといった属性を指定することも可能です。デフォルトではコスト効率を最大化するため、1つの大きなインスタンスに複数の小タスクを詰めて配置する「マルチタスク配置」が有効になっています。

OSパッチとセキュリティ更新

Managed Instancesが使用するAMIはAWS管理のBottlerocketベースAMIです。カスタムAMIは使用できません。AWSは14日間のサイクルでインスタンスドレイニングを開始し、最新のセキュリティパッチが適用された新インスタンスへとタスクを自動移行させます。定期メンテナンスはEC2イベントウィンドウで希望する時間帯を設定することで、業務ピーク時間との重複を避けられます。

スケーリングと配置最適化

ECSはワークロードの要求に応じてEC2インスタンスを動的に増減させます。アイドル状態のインスタンスは積極的にスケールインされ、不要なEC2コストを削減します。2025年11月には設定可能なscale-in delay（最大60分）が追加され、一時的な低負荷での過剰スケールイン防止ができるようになりました。

セキュリティ強化

SSHアクセスは無効化されており、インスタンスへの直接接続はできません。デバッグにはECS Execを使用します。ルートファイルシステムはイミュータブルであり、SELinuxによるカーネルレベルのMACが有効化されています。高度なネットワーク監視ツール（eBPFベース等）が必要な場合は、privileged Linuxケーパビリティ（CAP_NET_ADMIN・CAP_SYS_ADMIN・CAP_BPF等）を有効化することも可能です。

対応リージョンとOS

2025年10月に全商用リージョンへのGA拡充が完了し、東京リージョン（ap-northeast-1）でも利用できます。2025年11月にはAWS GovCloud（US-East・US-West）リージョンにも対応しました。

対応OSはLinuxコンテナのみ（BottlerocketベースのAWS管理AMI）で、CPUアーキテクチャはX86_64とARM64（Graviton）が選択できます。Windowsコンテナには対応していません（2026年7月時点）。

3-2. 従来EC2起動タイプ / Fargate / ECS Anywhereとの違い

責任分界点の対比

4つのコンピュートモデルを責任の所在という観点で整理すると、選択判断の材料になります。

この表から、Managed InstancesはEC2起動タイプとFargateの「中間」に位置するモデルであることが分かります。

Fargateとの主な違い

Fargateとの最大の違いは「インスタンスタイプの選択肢」と「料金体系」です。Fargateはコンテナ実行にEC2インスタンスが存在せず、AWSが定義したサイズ（vCPU・メモリの組み合わせ）の範囲内でタスクのリソースを指定します。Managed InstancesではGPUインスタンスや高メモリインスタンスを含むEC2の全インスタンスタイプが利用できます。

料金体系も異なります。FargateはタスクのvCPU・メモリ消費を秒単位で課金しますが、Managed InstancesはEC2インスタンス料金に加えてAWSによるインスタンス管理料金が発生します（両方とも秒単位・1分最小課金）。複数タスクを1インスタンスに集約するマルチタスク配置が効く場合はFargateより安価になる可能性がありますが、タスクが疎らな時間帯ではインスタンスをキープしたままの料金が発生するため、ワークロードの密度によって損益分岐点が変わります。Compute Savings PlansはManaged Instancesにも適用できます。

なお、Fargateのタスク定義（platform version 1.4.0対応）はそのままManaged Instancesでも利用できます。requiresCompatibilitiesにMANAGED_INSTANCESを追加するだけで、タスク定義の書き直しはほとんど不要です。FargateからManaged Instancesへの移行ハードルは技術的に低く設計されています。

従来EC2起動タイプ（自前ASG）との主な違い

従来のEC2起動タイプとの最大の違いは「AMI管理とスケーリングを誰が担うか」です。従来はAMIのパッチ適用タイミング・ASGのscale-in/out条件・ECS container agentのバージョン管理がすべてユーザーの責任でした。Managed InstancesではこれらすべてをAWSが行います。

ただし、カスタムAMIは利用できません。起動に特殊なソフトウェアが必要なワークロードや、特定バージョンのカーネルを固定したいユースケースでは、従来のEC2起動タイプを継続することになります。また、インスタンス稼働期間が最大14日である点も異なります。14日を超えて同一インスタンス上で継続実行が必要なワークロードは、従来のEC2起動タイプが適しています。

3-3. 導入手順と設定

事前準備 — IAMロールの作成

Managed Instancesを使うには2つのIAMロールが必要です。

Infrastructure Role（例：ecsInfrastructureRole）はAWSがユーザーのアカウント内でEC2インスタンスを起動・停止・管理するための権限を付与するロールです。ECSサービスプリンシパル（ecs.amazonaws.com）が信頼するIAMロールとして作成し、AWSが提供するマネージドポリシーをアタッチします。AWSマネジメントコンソールのECSクラスター作成フローを使うと自動生成されます。

Instance Profile（例：ecsInstanceProfile）は起動されたEC2インスタンスに付与するIAMインスタンスプロファイルです。ECSコントロールプレーンとの通信・ECRからのイメージプル・CloudWatch Logsへのログ送信・ECS Exec実行などに必要な権限（AmazonEC2ContainerServiceforEC2Roleポリシー相当）を含めます。

Capacity Providerの作成

デフォルト設定（インスタンスタイプをAWSに最適選択させる）のCapacity Provider定義例です。

{
  "name": "my-managed-instances-cp",
  "managedInstancesProvider": {
 "infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole",
 "instanceLaunchTemplate": {
"ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile",
"networkConfiguration": {
  "subnets": ["subnet-abc123", "subnet-def456"],
  "securityGroups": ["sg-0abc1234"]
}
 }
  }
}

GPUインスタンスが必要な場合はinstanceRequirementsでアクセラレータタイプを指定します。

{
  "managedInstancesProvider": {
 "infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole",
 "instanceLaunchTemplate": {
"ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile",
"networkConfiguration": {
  "subnets": ["subnet-abc123", "subnet-def456"],
  "securityGroups": ["sg-0abc1234"]
},
"instanceRequirements": {
  "vCpuCount": { "min": 4 },
  "memoryMiB": { "min": 16384 },
  "acceleratorTypes": ["gpu"]
},
"storageConfiguration": {
  "storageSizeinGiB": 100
}
 }
  }
}

作成したCapacity ProviderをECSクラスターに関連付けます。

aws ecs put-cluster-capacity-providers \
  --cluster my-cluster \
  --capacity-providers my-managed-instances-cp \
  --default-capacity-provider-strategy \
 capacityProvider=my-managed-instances-cp,weight=1,base=0

タスク定義の設定

Managed Instances用タスク定義ではrequiresCompatibilitiesにMANAGED_INSTANCESを指定します。ネットワークモードはawsvpc（推奨）またはhostを選択します。

{
  "family": "my-managed-task",
  "requiresCompatibilities": ["MANAGED_INSTANCES"],
  "networkMode": "awsvpc",
  "cpu": "2048",
  "memory": "4096",
  "taskRoleArn": "arn:aws:iam::123456789012:role/MyTaskRole",
  "containerDefinitions": [
 {
"name": "app",
"image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest",
"portMappings": [{ "containerPort": 8080, "protocol": "tcp" }],
"logConfiguration": {
  "logDriver": "awslogs",
  "options": {
 "awslogs-group": "/ecs/my-managed-task",
 "awslogs-region": "ap-northeast-1",
 "awslogs-stream-prefix": "ecs"
  }
}
 }
  ]
}

既存のFargate用タスク定義（platform version 1.4.0）はrequiresCompatibilitiesにMANAGED_INSTANCESを追加するだけで流用できます。FargateからManaged Instancesへの移行は技術的な障壁が最も低いパスです。

ストレージ設定

Managed InstancesにはデフォルトでEBSデータボリューム（デフォルト80GiB・最小30GiB・最大16,384GiB）がアタッチされます。コンテナイメージのプルと展開にもこのボリュームが使用されるため、大きなコンテナイメージを使う場合はサイズに余裕を持たせてください。storageConfigurationで容量を指定できます。

インスタンスストア搭載インスタンス（c5d・m5d等）では、EBSの代わりにインスタンスストアをデータボリュームとして利用できます（2025年11月対応）。インスタンスストアはコスト追加なし・高I/O性能が利点ですが、インスタンス終了時にデータが消える点に注意してください。永続性が必要なデータにはEFSやS3を使用します。

3-4. いつManaged Instancesを選ぶか — 使い分けの判断軸

Managed Instancesが最も効果を発揮するのは、次の条件が重なるユースケースです。

選択すべきシーン

第一に、GPU・特殊インスタンスが必要でインフラ管理を減らしたい場合です。機械学習推論（g4dn・p3インスタンス等）・リアルタイム動画エンコード・大規模データ処理など、Fargateでは対応できない特殊ハードウェアが必要なワークロードに適しています。GPUインスタンスを使いながらAMIパッチをAWSに任せられる点が、従来のEC2起動タイプとの最大の差別化です。

第二に、EC2起動タイプのAMI管理・ASG運用がボトルネックになっているチームです。インフラチームのリソースが限られており、AMIのローテーション作業がリリース速度の制約になっている場合、Managed Instancesへの移行でその負荷を解消できます。

第三に、Fargateサイズの上限を超えるワークロードです。Fargateには最大vCPU数・メモリの上限があります。これを超えるリソースが必要でEC2の柔軟性を求めるなら、Managed Instancesが選択肢になります。

選択を避けるべきシーン

インスタンスの稼働期間が最大14日に制限されるため、14日以上継続して動かし続ける必要があるワークロード（例：ステートをEC2ローカルに保持する長時間処理）は適していません。また、カスタムAMIが必須のワークロード（特定カーネルモジュールや独自パッケージが必要）や、SSH直接接続が前提の運用フローが残っている場合も、従来のEC2起動タイプを継続する必要があります。

Spot Instancesとの組み合わせ（2025年12月追加）

2025年12月にManaged InstancesでEC2 Spot Instancesのサポートが追加されました。Spot活用でオンデマンド比最大90%のコスト削減が見込め、耐障害性のあるバッチ処理・非同期ワーカー系のワークロードでManaged Instancesを採用するコスト上の動機が高まっています。Spot中断時のタスク再配置もECSが自動処理します。Fargate Spotが利用できない特殊インスタンスタイプ（GPU等）の要件がある場合に特に有効な組み合わせです。

4. コンピュートモデル選択の意思決定 — Fargate / EC2 / Anywhere / Managed Instances / Spot

ECSでワークロードを本番運用する際、どのコンピュートモデルを選ぶかは設計の中核となる意思決定です。選択肢は大きく5系統に整理でき、ワークロードの性質・運用体制・コスト目標によって最適な組み合わせは異なります。Capacity Providerのbase/weight設定やFargate Spot中断ハンドリングの実装詳細はECS基礎Vol1で解説していますので、本節は「どのモデルをいつ選ぶか」という意思決定の軸に集中します。

4-1. 5つのコンピュートモデルの全体マップ

ECSが提供するコンピュートモデルは、管理負荷・コスト特性・柔軟性・配置場所の4軸で整理できます。

各モデルの詳細を以下に説明します。

Fargate は最もシンプルな選択肢です。EC2インスタンスの調達・パッチ適用・ASG設定をAWSが担い、利用者はコンテナの定義とサービス設計に専念できます。コストはvCPU・メモリの秒単位課金であり、常時稼働の大規模ワークロードでは相対的に高くなります。ただし、EC2管理の運用コストを削減できるため、トータルの総所有コスト（TCO）では有利になるケースも多いです。

Fargate Spot はFargateと同じフルマネージドの利点を持ちながら、AWSの余剰キャパシティを活用して最大70%のコスト削減を実現します。ただし、AWSがキャパシティを必要とした際にタスクが中断される点を前提としなければなりません。中断通知としてSIGTERMが送信され、最大2分間の猶予でgraceful shutdownを完了させる実装が必須です。バッチ処理・CI/CDジョブ・開発/ステージング環境などに特に適しています。なお、WindowsコンテナはFargate Spotに対応していません。2024年9月にGraviton（ARM64）対応が追加され、ARM64アーキテクチャのWorkloadでも活用できるようになっています。

EC2起動タイプ（自前ASG） は最大の柔軟性を持ちます。EC2インスタンスタイプの自由な選択・カスタムAMIの利用・GPU/FPGAなどの特殊ハードウェア・高ネットワーク帯域のワークロードに対応できます。その一方で、AMIのパッチ適用・ASGの設計・ライフサイクルフックの管理・ECS container agentのバージョン管理など、EC2レイヤーの運用は全て利用者の責任となります。

ECS Managed Instances（2025年登場）は、EC2の柔軟性を保ちながら、EC2インスタンスのプロビジョニング・パッチ・ライフサイクル管理をAWSに委譲できる新しいモデルです。「EC2の柔軟性が必要だが、インフラ管理の負荷は下げたい」というニーズに応えます。従来のEC2起動タイプ（自前ASG）とFargateの中間的な位置づけで、詳細は§3をご参照ください。

ECS Anywhere（EXTERNAL） はECSの5系統の中で唯一、AWSのデータセンター外にコンテナを配置できるモデルです。オンプレミスのサーバ・他クラウドのVM・エッジデバイスにSSM AgentとECS container agentをインストールすることで、ECSコントロールプレーンから統一的に管理できます。配置場所の自由度が最も高い代わりに、外部インフラの維持・SSMエージェント管理・ネットワーク疎通の確保など、運用の手間も相応に大きくなります。詳細は§2をご参照ください。

ユースケース別の推奨モデル早見表

ワークロードの特性とコンピュートモデルの対応を整理すると、選択の出発点として次の表が役立ちます。

この表はあくまでも出発点です。実際の選択では後述の意思決定木と混在戦略を組み合わせて最終判断を行います。

なお、複数のモデルが候補に挙がった場合は、チームのEC2運用経験・既存インフラとの親和性・中長期のコスト目標の3点を軸に優先度をつけると判断がしやすくなります。

4-2. 意思決定木 — 配置場所・管理度合い・コスト最適化

コンピュートモデルの選択は、次の3つの問いかけを順番に検討することで絞り込めます。

新しい本番サービスを立ち上げる場合はステップ1から順に検討し、既存のEC2 launch type環境をモダナイズする場合はステップ2から入るとスムーズです。すでにFargateで運用中であればステップ3のコスト最適化から始めることが多くなります。

ステップ1: どこにコンテナを配置するか

最初の分岐点は「AWSのデータセンター内で動かすか、それ以外か」です。以下のいずれかの要件がある場合は、ECS Anywhere（EXTERNAL）が実質的に唯一の選択肢になります。

• 特定の物理サーバ・オンプレミス設備でなければならないデータ主権要件がある
• 既存のオンプレ資産を活かしてコンテナ運用を始めたい
• エッジや低レイテンシを要求する現場に近い場所でコンテナを動かしたい
• 法規制や契約上の理由でデータをAWSリージョン外に置かなければならない

上記に当てはまらない場合は、AWSリージョン内（Fargate/EC2/Managed Instances）でのモデル選択に進みます。

ステップ2: EC2インスタンスの管理をどこまで自前で行うか

AWSリージョン内でのワークロードと決まったら、次はEC2レイヤーの管理責任の分担を決定します。

EC2を全く意識したくない（フルマネージドで良い）

→ Fargate（通常 または Spot）を選択してください。

Fargateはサーバレスのコンテナ実行環境です。EC2インスタンスが存在しないため、AMIパッチやASGの設計が不要です。起動が速く、セキュリティパッチは自動的にAWSが適用するため、小規模チームでもスケーラブルな運用が実現できます。特殊なインスタンスタイプや高ネットワーク帯域が不要で、コンテナの開発・デプロイに集中したいチームに最適です。

EC2の柔軟性が必要だが、EC2管理の負荷は削減したい

→ ECS Managed Instancesを選択してください。

インスタンスタイプの選択やEC2水準の柔軟性は維持しながら、プロビジョニング・パッチ・ライフサイクル管理をAWSに任せられます。既存のEC2 launch typeで運用負荷が高まっていると感じる場合の移行先候補です。

EC2を完全に制御したい（カスタムAMI/特殊ハードウェア/細かいネットワーク設定/独自スポット戦略を含む）

→ EC2起動タイプ（自前ASG）を選択してください。

Multiple Instance Type ASGでスポットとオンデマンドを混在させるなど、コスト最適化の余地が最も大きいモデルです。GPUインスタンスや特定のENA設定が必要なワークロード、既存のEC2運用ノウハウを活かしたいチームに適しています。ただし、AMIローテーション・ASGライフサイクル・managed terminationの設定など、EC2レイヤーの管理コストを見込んで判断してください。

ステップ3: コスト最適化のためにSpotを活用するか

FargateまたはEC2起動タイプを選択した場合、コスト最適化の観点でSpotの活用可否を検討します。

• タスクが中断耐性を持つ（バッチ処理・非同期ワーカー・開発環境・CI/CDジョブなど）→ Fargate Spotを混在させてコスト削減
• タスクが中断耐性を持たない（同期APIサーバ・ステートフルなリアルタイム処理・SLA要件が厳格なサービスなど）→ 通常Fargateのみで安定性を確保

Fargate Spotを活用する際は、Capacity Provider StrategyでFargate（base=1以上）を確保し、FARGATE_SPOTのweightを高めに設定してバースト分をSpotで賄うパターンが基本です。これにより、最小限の通常Fargateタスクでサービスの安定性を確保しながら、余剰分は安価なSpotで動かせます。Fargate Spot中断実装の詳細（graceful shutdown・stopTimeout設定）はECS基礎Vol1を参照してください。

ここでECS Managed Instancesを選ぶ基準も補足します。Managed InstancesはEC2起動タイプと同様にインスタンスタイプを指定できますが、AWSがインスタンスのプロビジョニング・パッチ・ライフサイクル（起動/停止/入れ替え）を管理する点が異なります。「特定のインスタンスファミリーが必要だが、EC2 AMIの更新運用は避けたい」「既存のEC2起動タイプから段階移行したい」「SRE/インフラチームの人手が限られている」という状況でManaged Instancesへの移行を検討する価値があります。一方で、完全にカスタムなAMIや特殊なネットワーク設定（例: ENA Express/SR-IOV設定）が必要な場合は、今後も自前EC2起動タイプが適切です。

4-3. 混在戦略とトレードオフ

実際の本番環境では単一モデルに固執せず、複数モデルを組み合わせることでコスト・安定性・運用負荷のバランスを最適化できます。代表的な混在パターンを紹介します。

パターン1: Fargate + Fargate Spot（ハイブリッドCapacity Provider Strategy）

最も広く採用されるパターンです。Capacity Provider StrategyでFargate（base=最低保証タスク数）とFARGATE_SPOT（weight=コスト削減したい比率）を組み合わせます。例えば、base=2でオンデマンドFargateタスクを常時2つ確保し、追加スケールアウト分をFargate Spotで賄う設計です。

トレードオフとして、Spot中断発生時にFargateタスクが素早く引き継げる設計（ターゲットグループの接続ドレイン・ECSのロードバランサderegistration delay・ヘルスチェック設定の調整）が必要です。中断耐性のあるタスクとないタスクをサービス単位で分け、耐性のないサービスにはFargate onlyのStrategyを適用することで、サービスごとに適切な安定性を確保できます。

base/weight設計の考え方

Capacity Provider Strategyのbaseとweightはサービスの特性に応じて次のように設定します。

• 中断耐性ゼロのAPIサービス: FARGATE base=必要最低タスク数、FARGATE_SPOTは設定しない（または weight=0）
• 一部Spot許容のAPIサービス: FARGATE base=2（最低保証数）、FARGATE_SPOT weight=3（残りをSpotで補う）
• 完全Spotで問題ないバッチ: FARGATE base=0、FARGATE_SPOT weight=1（全タスクをSpotで動かす）

baseは「最低でもこの数のタスクを通常Fargateで維持する」という下限保証です。Spotが大量中断した際もbaseで設定した数のタスクは通常Fargateに切り替わるため、サービス断のリスクを限定できます。weightはCapacity Providerどうしの相対的な割合を示し、合計に対する比率でSpotへ振り分けるタスク数が決まります。サービス要件が変わった際はStrategyの値を変更するだけで、インフラの再構築なく切り替えられます。

パターン2: EC2起動タイプ（自前ASG）+ ECS Managed Instances

既存のEC2クラスタに一部ワークロードをManaged Instancesへ段階的に移行するパターンです。GPUや特殊インスタンスが必要なサービスは自前ASGに残し、汎用Webサービス・APIサーバなど標準的なワークロードはManaged Instancesへ移行することで、段階的な運用負荷の削減が実現できます。完全移行を急がず、ワークロード特性に応じて共存させるアプローチが現実的です。

パターン3: ECS Anywhere + Fargate（ハイブリッドデプロイ）

オンプレミスのデータ処理レイヤー（EXTERNAL起動タイプ）とAWSのAPIレイヤー（Fargate）を並立させるパターンです。データの物理的な移動が規制上許されないデータ処理はEXTERNALで実行し、フロントエンドAPIや集約ロジックはFargateで動かすといった設計が典型例です。ECSのコントロールプレーンを共有することで、デプロイやタスク管理のオペレーションを統一的に扱えます。

ただし、EXTERNAL起動タイプとFargate/EC2起動タイプは同一クラスタに共存できますが、Capacity Provider StrategyはEXTERNAL専用のプロバイダとFargate/EC2系を分けて設計する必要があります。ネットワーク経路（オンプレとAWS間のVPN/DirectConnect）や監視の統合設計も事前に計画してください。

避けたいアンチパターン

次のパターンは障害・コスト増・運用ミスにつながりやすいため、設計段階で排除することを推奨します。

• Fargate Spotのみで中断耐性のないサービスを運用する: Spot中断時にサービス断が発生します。中断耐性のないサービスには必ず通常Fargateのbaseを確保してください。
• EC2起動タイプでAMIパッチを放置する: パッチ未適用のAMIがASGに残り続けると、スケールアウト時に脆弱なインスタンスが起動します。AMIのローテーション自動化を必ず組み込んでください。
• ECS AnywhereとECS Managed Instancesを混同して設計する: 前者はオンプレ/他クラウドの外部インフラが対象、後者はAWSが管理するEC2が対象です。アーキテクチャレビュー時に両者の区別を明確にしておくことが重要です。
• すべてのサービスに同一のCapacity Provider Strategyを適用する: 中断耐性の有無・SLA要件・バースト特性はサービスによって異なります。サービス単位でStrategyを設計してください。
• Fargate Spotをbaseなしで本番APIに使う: base=0でFARGATE_SPOTのみを指定すると、スポットキャパシティが逼迫したリージョンで全タスクが一斉中断し、サービスが完全停止するリスクがあります。中断耐性が不明なサービスは必ずFargate baseを設定してから段階的に評価してください。

混在戦略は「完璧な設計を最初から実現する」必要はありません。まずはFargate単一構成で安定運用を確立し、バッチ処理やCI/CDなど中断耐性が明確なワークロードからFargate Spotを段階的に適用するアプローチが現実的です。コスト削減効果と運用負荷のバランスを継続的に評価しながら、最終的な混在構成へ移行していくことを推奨します。

4-4. コスト最適化の観点

Fargate Spotの活用

Fargate Spotは中断耐性があるワークロードに対して最大70%のコスト削減をもたらします。バッチ処理・CI/CDパイプライン・定期ジョブ・非同期イベント処理・開発環境などが典型的な適用対象です。Fargate Spot中断時のSIGTERMハンドリング（graceful shutdown・stopTimeout=最大120秒設定）の詳細実装はECS基礎Vol1に委ねています。

Fargate Spotを本番で安定して活用するには、中断イベントの可視化も重要です。ECSはタスク中断時にEventBridgeへtask state STOPPINGイベント（stopCode: SpotInterruption）を送信します。このイベントをトリガーとしてCloudWatch Alarmや通知フローを組むことで、中断頻度の監視や自動リトライの起点にできます。中断頻度が高いリージョン・アベイラビリティゾーンが偏っている場合は、タスク配置戦略（SPREADでAZ分散）を見直すことで安定性を改善できます。

Graviton（ARM64）の活用

FargateはタスクのcpuArchitectureにARM64を指定することでGraviton2ベースの実行環境を利用できます。一般に、ARM64はx86_64と比較して同等の処理性能をより低コストで提供します。2024年9月にFargate SpotもGravitonに対応し、ARM64 + Fargate Spotの組み合わせで相乗的なコスト削減が見込めます。コンテナイメージはmulti-platform image（linux/amd64とlinux/arm64を同一imageタグに収録）として構築しておくと、移行時の変更が最小化されます。

Graviton移行の具体的な手順は次の3ステップが基本です。まず、コンテナイメージをARM64でビルドし、ECRのマルチアーキテクチャマニフェストに収録します（docker buildx build --platform linux/amd64,linux/arm64）。次に、タスク定義のcpuArchitectureをARM64に変更した新リビジョンを作成します。最後に、開発環境または低トラフィックのサービスへのデプロイで動作確認してから本番へ展開します。依存ライブラリや言語ランタイムの大半はARM64に対応していますが、一部のネイティブコードを含むライブラリ（例: 特定のPythonパッケージのC拡張）では再コンパイルが必要になるケースがあるため、事前の検証が重要です。

EC2スポットインスタンスとの組み合わせ

EC2起動タイプを採用する場合、ASGのMixed Instances PolicyでスポットとオンデマンドのInstances Distributionを設定し、オンデマンドのbaseを確保しながら余剰をスポットで賄う構成がコスト最適化の定石です。ECSのmanaged scalingと組み合わせることで、クラスタキャパシティの過不足を自動調整できます（詳細は§6）。

コスト最適化の組み合わせ効果

各アプローチを組み合わせた場合の概算効果を整理します。なお、実際のコストはリージョン・インスタンスタイプ・稼働率によって大きく異なります。

Graviton（ARM64）への移行は、コンテナイメージのARM64対応ビルドが主な準備工数です。マルチアーキテクチャイメージ（linux/amd64とlinux/arm64を同一タグに収録）を整備しておくと、タスク定義のcpuArchitecture変更だけで移行が完結します。まずは開発環境やバッチ処理でGravitonを試して、ワークロード互換性を検証してから本番へ展開する段階的アプローチが推奨です。

5. ネイティブECS Blue/Green デプロイ 2025 — CodeDeploy不要のトラフィックシフト

5-1. ネイティブBlue/Greenの登場（2025-07）とCodeDeploy版との使い分け

AWSは2025年7月、ECS deployment controller内に直接Blue/Greenデプロイ機能を組み込んだ「ECSネイティブBlue/Green」を発表しました。これまでBlue/Greenデプロイを実現するには、ECSデプロイコントローラーとしてCODE_DEPLOYを選択し、ターゲットグループを2つ用意し、appspec.ymlを管理する必要がありました。ネイティブBlue/Greenでは、これらの外部依存がなくなり、ECSサービスの標準デプロイコントローラー（ECS）のまま、安全なトラフィックシフトとロールバックが可能になります。

CodeDeploy版のBlue/Greenデプロイ（appspec.ymlの書き方・ターゲットグループ切替・デプロイグループ設計）については、ECS CI/CDパイプラインVol2で詳しく解説しています。本章ではネイティブ版に絞って説明します。

5-2. トラフィックシフト戦略（ALL_AT_ONCE / CANARY / LINEAR）と設定

ネイティブBlue/Greenは、ECSサービスのdeploymentConfiguration内のblueGreenDeploymentConfigurationでトラフィックシフト戦略を制御します。2025年7月のリリース時点ではALL_AT_ONCEのみ対応し、2025年10月にCANARYとLINEARへの対応が拡充されました。

ALL_AT_ONCE（一括切替）

すべてのトラフィックを即座に新バージョン（Green）へ切り替えます。最もシンプルな方式で、切替後にbake timeの観測期間を設けます。問題を検知した場合は、ECSが自動的にトラフィックをBlueへ戻します。

deploymentConfiguration:
  deploymentCircuitBreaker:
 enable: true
 rollback: true
  blueGreenDeploymentConfiguration:
 trafficRoutingConfig:
type: ALL_AT_ONCE
 terminateBlueInstancesOnDeploymentSuccess:
action: KEEP_ALIVE
terminationWaitTimeInMinutes: 10

terminateBlueInstancesOnDeploymentSuccessのKEEP_ALIVE設定により、切替完了後もbake time（10分）の間はBlueのタスクを維持します。観測期間中に問題がなければBlueは自動終了します。

CANARY（カナリア）

最初に一定割合のトラフィックをGreenへ送り、安定を確認してから残りを一括切替します。本番トラフィックの一部で新バージョンを検証できるため、リスクの高いデプロイに適しています。

deploymentConfiguration:
  blueGreenDeploymentConfiguration:
 trafficRoutingConfig:
type: CANARY
canaryRoutingConfig:
  canaryPercentage: 10
  canaryIntervalMinutes: 5
 deploymentReadyOption:
actionOnTimeout: STOP_DEPLOYMENT
waitTimeInMinutes: 60

canaryPercentage: 10は最初にGreenへ送るトラフィックの割合（10%）、canaryIntervalMinutes: 5はcanary段階の継続時間（5分）を示します。5分後に問題がなければ残り90%を一括切替します。waitTimeInMinutes: 60はcanary段階での最大待機時間で、超過した場合はデプロイを停止しロールバックします。

LINEAR（段階的）

定期的な間隔で段階的にトラフィック割合を増やしていきます。たとえば10分ごとに10%ずつ増加させ、100%に達したらデプロイ完了とする方式です。

deploymentConfiguration:
  blueGreenDeploymentConfiguration:
 trafficRoutingConfig:
type: LINEAR
linearRoutingConfig:
  linearPercentage: 10
  linearIntervalMinutes: 10

この設定では10分ごとに10%ずつGreenへのトラフィックが増加し、100分後に完全切替となります。段階が細かいほど問題の早期検知が可能ですが、デプロイ完了までの時間が長くなります。ビジネスの変更リスクとデプロイ速度のバランスで戦略を選択してください。

5-3. deployment lifecycle hooks による独自検証

ECSネイティブBlue/Greenには、デプロイの各フェーズにカスタム検証を差し込める「deployment lifecycle hooks」が組み込まれています。代表的なhookポイントは以下の2つです。

• BeforeTrafficShift: トラフィック切替前に実行されます。Greenタスクが起動しヘルスチェックをパスした後、実際のトラフィックを送信する前にスモークテストやAPIレスポンス確認などのカスタム検証を実施できます。
• AfterTrafficShift: トラフィック切替完了後に実行されます。本番トラフィックを受けているGreenのエラーレートやレイテンシを確認する用途に適しています。

hookの実体はLambda関数として定義します。ECSがhookポイントに到達すると指定のLambda関数を呼び出し、関数の戻り値によってデプロイの継続・ロールバックを自動判定します。

{
  "hooks": [
 {
"hookTargetArn": "arn:aws:lambda:ap-northeast-1:123456789012:function:ecs-bluegreen-smoke-test",
"hookPoint": "BEFORE_TRAFFIC_SHIFT"
 },
 {
"hookTargetArn": "arn:aws:lambda:ap-northeast-1:123456789012:function:ecs-bluegreen-verify-prod",
"hookPoint": "AFTER_TRAFFIC_SHIFT"
 }
  ]
}

Lambda関数はECSから渡されるデプロイコンテキスト（deploymentId等）を受け取り、対象タスクセットの状態を確認して検証結果を返します。hookが指定時間内に応答しない場合はデプロイが停止されます。lifecycle hooksを活用することで、外部のCI/CD基盤を持たない構成でもデプロイ品質を担保した自律的な切替フローを実現できます。

lifecycle hooksのLambda実装では、以下の点に注意してください。

• タイムアウト設定: hookの実行に与えられる時間はデフォルト最大60分です。スモークテストが複雑な場合は、Lambda関数自体のタイムアウト（最大15分）に注意し、検証ステップを分割するか非同期で外部のテスト結果を取得する設計を検討してください。
• 冪等性の確保: hookは失敗時に再実行される場合があるため、Lambda関数が冪等に動作するよう設計します。同じdeploymentIdで複数回届いても安全に処理できる実装が求められます。
• ログ出力の充実: Lambda実行ログはCloudWatch Logsに記録されます。hookの成功・失敗の理由と検証内容を詳細に残しておくと、デプロイ失敗時の原因調査が容易になります。
• IAMロールの最小権限: hook用Lambdaに付与するIAMロールは、必要なECS/CloudWatch API操作のみに絞ります。検証に不要なアクセス権限は付与しないことを推奨します。

5-4. bake time とダウンタイムなしロールバック

bake time（観測期間）

トラフィックを100%Greenへ切り替えた後、即座にBlueを廃棄するのではなく、一定時間（bake time）の観測期間を設けます。この間にCloudWatchアラームやエラーレートの異常を検知した場合、ECSが自動的にトラフィックをBlueへ戻します。

bake timeはdeploymentConfigurationのterminateBlueInstancesOnDeploymentSuccessで制御します。

terminateBlueInstancesOnDeploymentSuccess:
  action: KEEP_ALIVE
  terminationWaitTimeInMinutes: 10

action: KEEP_ALIVEはbake time中もBlueのタスクを維持することを意味します。terminationWaitTimeInMinutesで指定した期間（ここでは10分）が経過し問題がなければBlueのタスクが自動終了します。bake timeの長さはサービスのトラフィックパターンに合わせて調整し、バッチ処理や低頻度の夜間トラフィックを持つサービスでは長めに設定することを推奨します。

bake timeの設計目安として、以下の指標を参考にしてください。

bake time中はBlueとGreenの両方のタスクが稼働し続けるため、その分のコスト（タスク課金）が発生します。必要以上に長いbake timeは運用コストを増加させるため、サービスのSLO（サービスレベル目標）と照らし合わせて適切な時間を設定してください。

ダウンタイムなしロールバック

Blue/Greenデプロイの最大のメリットは、ロールバック時もダウンタイムがゼロになる点です。bake time中はBlueのタスクが維持されているため、トラフィックの向き先をBlueへ戻すだけでロールバックが完了します。ECSは以下の条件で自動ロールバックを実行します。

• deployment lifecycle hookが失敗を返した場合
• ECSヘルスチェックが繰り返し失敗した場合
• deploymentReadyOptionのwaitTimeInMinutesを超過した場合
• CloudWatchアラームがアラーム状態になった場合（alarm rollbackが有効の場合）

手動ロールバックはAWS CLIからも実行できます。

aws ecs rollback-service \
  --cluster my-cluster \
  --service my-service

§7で説明する1-click rollback（2025-05）を使えばECSコンソールから1操作で直前の完了済みデプロイへ戻すことも可能です。自動検知によるロールバックと運用者による手動介入の両方を同一フレームワークで実現しており、障害対応の選択肢が広がります。

5-5. ALB/NLB/Service Connect との連携

ALBとの連携

ネイティブBlue/Greenは、ALB（Application Load Balancer）のターゲットグループを通じてトラフィックを管理します。従来のCodeDeploy版では2つのターゲットグループが必要でしたが、ネイティブ版はECSサービスが内部でBlue/Greenのタスクセット切替を管理するため、ALBのターゲットグループは1つで構成できます。

ECSサービスにALBを連携する際は、ヘルスチェックの猶予期間（healthCheckGracePeriodSeconds）をアプリケーションの起動時間より長く設定することが重要です。起動に時間がかかるアプリケーションでこの値が短すぎると、Greenタスクが起動直後にUnhealthyと判定されデプロイが失敗します。

{
  "loadBalancers": [
 {
"targetGroupArn": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-tg/abcd1234",
"containerName": "my-app",
"containerPort": 8080
 }
  ],
  "healthCheckGracePeriodSeconds": 60
}

ECSはBlue→Green切替時にBlueのタスクをドレイニング（接続中リクエストの完了待機）してからデタッチするため、進行中のリクエストへの影響を最小化できます。ドレイニング時間はALBターゲットグループの「登録解除の遅延」設定（デフォルト300秒）で制御します。

NLBとの連携

NLB（Network Load Balancer）のターゲットグループでも利用可能です。NLBを使う場合は、TCP/HTTPのヘルスチェック設定とターゲットの登録解除遅延を適切に調整します。NLBはALBと異なり接続レベルの負荷分散を行うため、既存コネクションのドレイニング動作がALBとは異なる点に注意してください。特にNLBではconnection_termination属性の設定で、登録解除遅延タイムアウト後の接続強制切断動作を制御できます。

ECS Service Connectとの連携

ECS Service Connect経由のサービス間通信にもネイティブBlue/Greenを適用できます。Service ConnectはECSクラスタ内のサービスディスカバリとトラフィック管理を担い、サービスメッシュ的な可視性（メトリクス・ログ）を提供します。ネイティブBlue/Greenのトラフィックシフトと組み合わせることで、マイクロサービス間の安全なバージョン切替が実現します。

新旧のタスクセット（Blue/Green）はいずれもService Connectのサイドカープロキシを通じて通信するため、切替前後のレイテンシやエラーレートをService Connectメトリクスで確認しながらデプロイを進められます。Service Connectの基本設定については、ECSコンテナ本番運用Vol1を参照してください。

6. EC2 ASG Capacity Provider の managed scaling — targetCapacityによるクラスタ自動スケール

6-1. なぜEC2 Capacity Providerか — Fargateとの違いとEC2を選ぶ理由

ECSにはコンテナのコンピュートリソースを管理する「Capacity Provider」という仕組みがあります。大きく分けると、AWSがコンピュートを全て管理するFargate系（FARGATE・FARGATE_SPOT）と、Amazon EC2 Auto Scaling Group（ASG）を利用するASG系（EC2 capacity provider）の2系統があります。本章で扱うmanaged scaling（targetCapacity設定）はEC2 ASG capacity provider専用の機能です。FARGATEおよびFARGATE_SPOTには適用されない点を最初に明確にしておきます。

EC2 capacity providerを選ぶ主な理由は3点あります。第一にGPUや特殊インスタンスが必要なワークロードです。画像認識・機械学習推論・動画処理など、GPUインスタンス（g4dn・p3等）やGraviton3搭載インスタンス（m7g・c7g等）を使いたい場合はEC2 capacity providerを選択します。Fargateは汎用的なサイズのみのため、これらの特殊インスタンスには対応していません。

第二に大規模・長時間稼働のコスト最適化です。常時大量のタスクが稼働するシステムでは、EC2インスタンスのReserved InstancesやSavings Plansを活用することでFargateより総コストを下げられるケースがあります。特に1 vCPUあたりのワークロードが多く、長時間稼働するアプリケーションでは顕著な差が生じます。

第三にタスク間のリソース共有や精密な配置制御が必要な場合です。同一EC2インスタンス上の複数タスク間でEFSボリュームを共有する設計や、Placement Constraintsによるラック・AZ・ハードウェアスペックに基づいた精密な配置制御はEC2起動タイプ特有の機能です。

一方で、汎用ステートレスワークロードにはFargateが有利なケースも多くあります。FargateはOSパッチやAMI管理が不要で、かつFargate SpotでX86_64比約70%のコスト削減も可能です。Fargateのスケーリング設計（Service Auto Scaling・ターゲット追跡スケーリング・ステップスケーリング）については、ECSコンテナ本番運用Vol1で詳しく解説しています。

以下の対比表で主要な観点を整理します。

6-2. managed scaling の仕組み — targetCapacity・Capacity Provider Reservation・ASG連携

EC2 capacity providerのmanaged scalingを有効にすると、ECSがASGのDesired Capacityを自動で増減させ、クラスターのキャパシティ利用率を設定した目標値（targetCapacity）に保ちます。この仕組みの核心は「Capacity Provider Reservation」と呼ばれるCloudWatchメトリクスにあります。

Capacity Provider Reservation とは

Capacity Provider ReservationはECSが自動算出するCloudWatchカスタムメトリクスです。「現在クラスターでPendingまたはRunning状態のタスクを配置・実行するために必要なキャパシティ量」に対して「現在のASGが提供する総キャパシティ量」の比率をパーセンテージで表したものです。ECSは内部でCPU・メモリのリソースユニットを換算して算出します。

Capacity Provider Reservation (%) ≒
  必要な総キャパシティ / 現在の総キャパシティ × 100

Capacity Provider ReservationがtargetCapacityより高い（余裕が少ない・Pendingタスクがある）場合、ECSはASGのDesired Capacityを引き上げてスケールアウトを要求します。逆にCapacity Provider ReservationがtargetCapacityより低い（余裕が多すぎる）場合、ECSはmanaged termination protectionに基づいてスケールインの候補インスタンスを選定します。

スケールアウトの動作フロー

タスクが増えてキャパシティが不足した場合の流れを示します。

1. タスク増加: ECSサービスのDesired Countが増えるか、Service Auto Scalingがタスク数を増やす要求を発行する
2. Pending発生: 配置可能なEC2インスタンスのリソースが不足し、一部のタスクがPENDINGキューに積まれる
3. Reservationメトリクス上昇: ECSがPendingタスクを含めてCapacity Provider Reservationを再算出し、targetCapacityを超えたことを検知する
4. ASGスケールアウト要求: ECSがASGのDesired Capacityを引き上げる（増加量はminimumScalingStepSize〜maximumScalingStepSizeの範囲）
5. 新EC2インスタンス起動: ASGが新しいEC2インスタンスを起動し、ECS container agentがクラスターに登録される
6. タスク配置: PENDINGキューのタスクが新インスタンスに配置されて実行開始となる

起動から配置完了まで通常1〜3分（インスタンスタイプ・AMIによる）かかります。待機時間を短縮したい場合はASGのWarm Pool（起動済み待機インスタンスプール）との組み合わせを検討してください。

スケールインの動作フロー

タスクが減り余剰キャパシティが増えた場合の流れです。

1. タスク減少: Service Auto Scalingまたは手動操作でDesired Countが減少し、タスクが停止される
2. Reservationメトリクス低下: 余剰キャパシティが増加し、Capacity Provider ReservationがtargetCapacity未満になる
3. スケールイン候補選定: ECSがタスク未搭載または搭載タスクが少ないインスタンスをスケールイン候補として選定する
4. managed termination protection適用: 実行中タスクがあるインスタンスはASGスケールインから保護される
5. ドレイニング完了後に終了: 候補インスタンスのタスクが退去してから、インスタンスが終了する

CLIでのCapacity Provider定義

managed scalingを有効にしたEC2 capacity providerを作成する例を示します。

aws ecs create-capacity-provider \
  --name my-ec2-capacity-provider \
  --auto-scaling-group-provider \
 autoScalingGroupArn=arn:aws:autoscaling:ap-northeast-1:123456789012:autoScalingGroup:xxxxxxxx:autoScalingGroupName/my-ecs-asg,managedScaling=\{status=ENABLED,targetCapacity=100,minimumScalingStepSize=1,maximumScalingStepSize=10\},managedTerminationProtection=ENABLED

Terraformでの定義例です。

resource "aws_ecs_capacity_provider" "ec2" {
  name = "my-ec2-capacity-provider"

  auto_scaling_group_provider {
 auto_scaling_group_arn = aws_autoscaling_group.ecs.arn

 managed_scaling {
status  = "ENABLED"
target_capacity  = 100
minimum_scaling_step_size = 1
maximum_scaling_step_size = 10
 }

 managed_termination_protection = "ENABLED"
  }
}

作成したcapacity providerはECSクラスターに関連付けてから使用します。

aws ecs put-cluster-capacity-providers \
  --cluster my-cluster \
  --capacity-providers my-ec2-capacity-provider \
  --default-capacity-provider-strategy \
 capacityProvider=my-ec2-capacity-provider,weight=1,base=0

6-3. targetCapacityの設計 — 100 vs バッファ確保・スケールイン保護・managed termination protection

targetCapacity 100 と バッファ確保の使い分け

targetCapacityは1〜100の整数で設定します。「クラスターのキャパシティを何%利用した状態を維持するか」という目標利用率です。

targetCapacity = 100（高密度・コスト最優先）

全インスタンスリソースをフル活用する設定です。余剰キャパシティをゼロに近づけるため、EC2コストの無駄を最小化できます。その代わり、新しいタスクが発生したときに既存インスタンスに空きがなければ、新EC2インスタンスの起動（通常1〜3分）を待ってから配置されます。起動レイテンシを許容できるバッチ処理やコスト最優先のワークロードに適しています。

targetCapacity = 70〜90（バッファ確保・応答速度優先）

常時10〜30%の余剰キャパシティを維持する設定です。タスクが増加してもすでに空きがあるインスタンスに即座に配置できるため、Pending時間をほぼゼロにできます。余剰インスタンスを常時保持するため、targetCapacity=100より固定コストは高くなります。リクエスト急増頻度が高いWebサービスや、起動遅延が許されないリアルタイム処理に向いています。

targetCapacity=100でも起動レイテンシを解消したい場合は、ASGのWarm Pool（ウォームプール）を設定します。ウォームプールは起動済み・待機中のEC2インスタンスをASGの外に保持し、スケールアウト時にそのインスタンスを即座にASGに追加します。EC2コストはかかりますが、インスタンス起動時間（OS起動・ECS agent登録）を省略できます。

minimumScalingStepSize / maximumScalingStepSize

1回のスケールアクションで変化するインスタンス数の下限・上限を制御します。

managed_scaling {
  status  = "ENABLED"
  target_capacity  = 100
  minimum_scaling_step_size = 1
  maximum_scaling_step_size = 5
}

maximumScalingStepSize=5 にすると、一度のスケールアクションで最大5インスタンスしか起動・終了しません。バッチジョブキューが一気に満杯になるなど急激な需要増加があっても、EC2コストが一気に膨らむリスクを抑えられます。minimumScalingStepSize=1 はスケールアウト・インが1インスタンス単位で細かく動作することを保証します。需要増加の急峻さとコスト管理のトレードオフでパラメータを調整してください。

managed termination protection

managed termination protectionを有効にすると、ECSはタスクが実行中のEC2インスタンスをASGのスケールインから自動的に保護します。スケールイン時の動作は次のとおりです。

1. ECSがスケールイン候補インスタンスを特定する
2. 候補インスタンスに実行中タスクがある場合、ECSがASGのスケールイン保護フラグをONにする
3. タスクが完了またはDrainで別インスタンスに移動される
4. 全タスク退去後、ECSがスケールイン保護フラグをOFFにする
5. ASGがインスタンスを終了する

この仕組みにより、実行中タスクが強制終了されて処理が中断されるリスクを防げます。managed termination protectionが正しく動作するためには、ASG側でインスタンス保護が有効（ECSによる動的な保護フラグ操作を許可する設定）になっていることが必要です。設定後はAWSコンソールまたはCLIでインスタンスの保護フラグが正しく切り替わることを確認してください。

また、managed termination protectionはmanaged scalingが有効（status=ENABLED）のときのみ機能します。managed scalingを無効（DISABLED）にしているか、手動でASGを操作している場合はECSによる保護が働きません。ECSマネジメントコンソールの「クラスター → Capacity Providers」から設定状態を確認できます。

6-4. Fargate系との非適用の明確化 — Fargateのスケーリングは Service Auto Scaling

EC2 capacity providerのmanaged scaling設定（managedScaling・targetCapacity）は、FARGATEおよびFARGATE_SPOTには適用されません。FargateキャパシティプロバイダーにautoScalingGroupProviderは存在しないため、設定自体ができません。

さらに、1つのcapacity provider strategyにFargate系とASG系を混在させることはできません。1つのECSサービスが使用するcapacity provider strategyは、同系統（FARGATE+FARGATE_SPOTの組み合わせ、またはEC2 capacity providerのみ）で構成する必要があります。

{
  "capacityProviderStrategy": [
 {
"capacityProvider": "FARGATE",
"weight": 1,
"base": 2
 },
 {
"capacityProvider": "FARGATE_SPOT",
"weight": 3
 }
  ]
}

上記はFargate系同士の混在（FARGATE + FARGATE_SPOT）の正しい例です。ここに"capacityProvider": "my-ec2-capacity-provider"を追加するとエラーになります。

Fargateタスクのスケーリングは Application Auto Scaling を通じた ECS Service Auto Scaling が担います。ECSサービスのDesired Count（タスク数）をスケーリングポリシーで増減させる仕組みで、以下のポリシータイプを利用できます。

• ターゲット追跡スケーリング: CPU使用率・メモリ使用率を指定した目標値に追従するようDesired Countを自動調整します（最もシンプルで推奨）
• ステップスケーリング: CloudWatchアラームのしきい値超過に応じて段階的にDesired Countを増減します
• スケジュールスケーリング: 時刻・曜日に基づいてDesired Countを事前設定した値へ変更します（予測可能なバーストに有効）

Fargateでは、AWSがFargate層のキャパシティを管理するためインスタンスの増減をユーザーが意識する必要はなく、タスク数の増減に集中できます。Fargateスケーリングの詳細設計については、ECSコンテナ本番運用Vol1を参照してください。

7. デプロイ安全機構の2025最新 — 1-click rollback / custom stop signals / Graviton Spot差分

7-1. デプロイ安全機構の全体像 — 2025差分に絞る理由

ECSのデプロイ安全機構は、リリース以来複数の層として整備されてきました。deployment circuit breakerはローリングアップデートのコントローラーが「steady state未達成」を検知した際に自動でロールバックをトリガーする仕組みです。CloudWatch alarm連動ロールバック（2022年12月リリース）は、デプロイ後にアプリ層のエラーレートや遅延が閾値を超えた際に自動ロールバックを行う機能です。

これら2つは本シリーズの基礎編（cicd1・cicd2・ecspressoシリーズ）でDEEPに解説済みのため、本章では再説明を省略します。

本章が扱うのは、これらの「検知・ロールバック」基盤の上に2024〜2025年に追加された3つの差分です。

• 1-click rollback（2025年5月）: 直前の完了済みデプロイへ1操作で戻す運用オペレーションの改善
• custom container stop signals on Fargate（2025年12月）: コンテナ停止シグナルのカスタマイズによるgraceful shutdown制御
• Graviton(ARM64) Fargate Spot（2024年9月）: ARM64アーキテクチャでのSpotキャパシティ利用

これら3つは互いに補完的であり、「安全に速く戻せる」「中断時にアプリが正常終了できる」「コストを抑えながらSpotを活用できる」という三層の安全設計を実現します。

7-2. 1-click rollback（2025年5月）と bake time — 運用オペレーションの改善

1-click rollbackとは

2025年5月にリリースされた1-click rollback機能は、ECSサービスのデプロイ履歴から直前の「完了済みデプロイ」に対して、単一の操作でロールバックを実行できる機能です。

従来のロールバック手段は次のいずれかでした。

1. デプロイを再実行（古いタスク定義を明示指定してUpdateServiceを呼ぶ）
2. deployment circuit breakerによる自動ロールバック（タスク起動失敗の検知が前提）
3. CloudWatch alarm連動ロールバック（メトリクスが閾値超過することが前提）

1-click rollbackはこの「手動でやりたいが手間がかかる」操作を1ステップに圧縮します。問題が発覚したオペレーターがマネジメントコンソールまたはAWS CLIから即座に実行でき、アラート発火待ちや自動検知に依存せずにロールバックを開始できます。

操作の仕組み

1-click rollbackはデプロイ履歴から直前の COMPLETED ステータスのデプロイを自動で特定し、そのタスク定義でUpdateServiceを実行します。ロールバック先を手動で特定する必要はなく、「直前に成功していた状態」が自動的に選ばれます。

マネジメントコンソールでは、サービスの「Deployments」タブからアクティブなデプロイに対して「Rollback」ボタンが表示されます。CLIからは update-service に --rollback オプションを付けることで同等の操作が可能です。

bake time の設定

1-click rollbackと同時に、deploymentConfigurationに bakeTimeInMinutes が追加されました。bake timeはデプロイ完了後、そのデプロイを「ロールバック候補から外す」までの観察期間です。

{
  "deploymentConfiguration": {
 "deploymentCircuitBreaker": {
"enable": true,
"rollback": true
 },
 "alarms": {
"alarmNames": ["my-app-error-rate"],
"enable": true,
"rollback": true
 },
 "minimumHealthyPercent": 100,
 "maximumPercent": 200,
 "bakeTimeInMinutes": 10
  }
}

bakeTimeInMinutes を設定すると、新デプロイ完了後その時間が経過するまでは前のデプロイがロールバック候補として保持されます。これにより、デプロイ直後にサイレント障害が起きても前の状態に即座に戻せます。

bake timeの推奨値はアプリケーションの特性によって異なりますが、一般的には次の指標を参考にします。

circuit breakerとの役割分担

circuit breakerがインフラ層（タスク起動失敗）を自動検知し、alarm連動ロールバックがアプリ層メトリクス超過を自動検知するのに対し、1-click rollbackは「起動成功したが品質に問題がある」ケースを人が判断して手動で対処します。自動とは補完関係にあり、置き換えではありません。

7-3. custom container stop signals on Fargate（2025年12月）— 停止シグナル制御とgraceful shutdown

従来の課題と概要

2025年12月以前、Fargateコンテナへの停止シグナルはSIGTERMに固定されていました。Node.jsプロセスや一部のJavaフレームワークではSIGTERMを捕捉せずデフォルト動作で即終了するケースがあり、graceful shutdownの実装にラッパースクリプトが必要でした。

custom stop signalsの概要

2025年12月にリリースされたcustom container stop signalsは、タスク定義のコンテナ設定でECSが送信する停止シグナルをカスタマイズできる機能です。タスク定義の stopSignal フィールドにシグナル名を指定することで、ECSはデフォルトのSIGTERMの代わりに指定したシグナルを送信します。

対応している主なシグナルは次のとおりです。

タスク定義での設定

{
  "containerDefinitions": [
 {
"name": "app",
"image": "my-app:latest",
"stopTimeout": 90,
"stopSignal": "SIGUSR1",
"linuxParameters": {
  "initProcessEnabled": true
}
 }
  ]
}

stopSignal に SIGUSR1 を指定すると、ECSはコンテナ停止時にSIGTERMの代わりにSIGUSR1を送信します。アプリ側でSIGUSR1をgraceful shutdown開始トリガーとして実装することで、元のSIGTERMハンドラと衝突せずにECS固有の終了処理を追加できます。stopTimeout 秒後にSIGKILLで強制終了される点は従来と同様です。

stopTimeoutおよびFargate Spot中断との整合（§4連携）

§4で解説したとおり、Fargateの stopTimeout 上限は120秒です。custom stop signalはECS側からの意図的停止（UpdateService・タスク停止操作）に適用されます。Fargate Spot中断時は引き続きSIGTERMが送信され（stopCode: SpotInterruption）、2分間の猶予が与えられます。

ECS意図的停止にSIGUSR1を使う場合、アプリ側でSIGUSR1（ECS停止）とSIGTERM（Spot中断）の両方にgraceful shutdownハンドラを実装します。これにより、原因の異なる2種類の停止トリガーをアプリがそれぞれ適切に処理できます。

7-4. Graviton Fargate Spot（2024年9月）— ARM64でのコスト最適化差分

概要とコスト効果

2024年9月にGraviton(ARM64)プロセッサ搭載タスクでFargate Spotが利用可能になりました。従来のFargate SpotはX86_64のみの対応でしたが、ARM64対応により、コスト削減の組み合わせが拡大しました。

コスト削減率の目安は次のとおりです（ap-northeast-1の参考値）。

Graviton + Spotの組み合わせは、最大で通常Fargateの4分の1以下のコストでワークロードを実行できます。

タスク定義とサービスの設定

runtimePlatform で cpuArchitecture: ARM64 を指定し、サービス側でFargate Spotキャパシティプロバイダーを選択します。

{
  "family": "my-task",
  "runtimePlatform": {
 "operatingSystemFamily": "LINUX",
 "cpuArchitecture": "ARM64"
  },
  "requiresCompatibilities": ["FARGATE"],
  "containerDefinitions": [
 {
"name": "app",
"image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest",
"stopTimeout": 90
 }
  ]
}

サービスのキャパシティプロバイダー戦略でFARGATE_SPOTを指定します。

{
  "capacityProviderStrategy": [
 {
"capacityProvider": "FARGATE_SPOT",
"weight": 1
 }
  ]
}

マルチアーキテクチャイメージの必要性

ARM64タスクを実行するには、コンテナイメージがARM64向けにビルドされている必要があります。マルチアーキテクチャイメージ（linux/amd64 と linux/arm64 の両プラットフォームをサポートするmanifest list）を作成しておくと、X86_64とARM64の両構成で同一イメージタグを利用できます。

docker buildx create --use
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest \
  --push .

Spot中断時のハンドリング（§4との整合）

Graviton Fargate Spot使用時の中断ハンドリングはX86_64 Spotと同一です。SIGTERMがPID 1に送信され、stopTimeout秒（最大120秒）の猶予後にSIGKILLで強制終了、EventBridgeにstopCode: SpotInterruptionイベントが発行されます。§7-3のcustom stop signalsをGraviton Spot構成に適用することで、ECS意図的停止とSpot中断を別シグナルで区別し、それぞれ適切なgraceful shutdownを実装できます。

7-5. 3つの差分機能を組み合わせた安全なデプロイ運用設計

安全機構の層構造

2024〜2025年の3つの差分機能（1-click rollback・custom stop signals・Graviton Fargate Spot）は独立した機能ですが、組み合わせることで相乗効果を発揮します。

[デプロイ実行前]
  bake time設定 → 前デプロイをロールバック候補として保持
↓
[デプロイ中 — 自動ロールバック層（基礎 / CL参照）]
  circuit breaker → タスク起動失敗を自動検知
  alarm連動ロールバック → アプリ層メトリクス超過を自動検知
↓
[デプロイ後 — 人的判断層（2025新機能）]
  1-click rollback → 品質問題を人が判断して即時ロールバック
↓
[コンテナ停止時 — graceful shutdown層（2025新機能）]
  custom stop signals → ECS停止シグナルをアプリに合わせて制御
  Fargate Spot中断 → SIGTERM + 2分猶予（§4と整合）
↓
[コスト最適化層（2024差分）]
  Graviton Fargate Spot → ARM64 + Spotで最大76%削減

設計チェックポイント

Graviton Fargate Spotを採用する本番環境向けに、次のチェックポイントを確認します。

Graviton Fargate Spotが向かないワークロード

Fargate Spotは中断が発生し得るため、全てのワークロードに適用すべきではありません。次のワークロードはX86_64 Fargate（オンデマンド）の利用を優先します。

• セッション状態をメモリに保持するアプリケーション（ステートフル）
• 中断が許容されないリアルタイムトランザクション処理
• 起動時間が長くコールドスタートコストが高いワークロード
• 中断回復コストが削減メリットを上回るバッチ処理

Spot耐性があるワークロード（画像処理・ログ集計・CI/CDジョブ等）に絞って適用することで、コスト削減の恩恵を最大化できます。

8. まとめ — ECSハイブリッド & 2025新機能の運用ベストプラクティス

本記事では、Amazon ECSの基礎を固めた組織が次に取り組む「ハイブリッド運用」と「2025年の新機能」を整理しました。ECS Anywhereによるオンプレ・ハイブリッド統合、ECS Managed Instancesという新コンピュートモデル、CodeDeploy不要のネイティブBlue/Greenデプロイ、EC2 Capacity Providerのmanaged scaling、そして2025年に追加されたデプロイ安全機構という5つの軸を通じて、立ち上げ後のECSを安全に運用し続けるための設計判断軸を提示しました。

8-1. 5軸の要点サマリ

ECS Anywhere（§2）

EXTERNAL起動タイプでオンプレミスや他クラウドのサーバをECSコントロールプレーンに接続します。SSM Agent + ECS container agentのインストールで外部インスタンスを登録し、IAM認証情報は約30分ごとにhardware fingerprintベースで自動ローテーションされます。ネットワークモードはawsvpc不可（bridge/hostを選択）。料金は$0.01025/外部インスタンス時間で、deregisterするまで継続課金されます。サーバ廃棄時のderegister忘れとSSM Agent停止による認証更新断が主要リスクです。

ECS Managed Instances（§3）

2025年9月30日GA。EC2インスタンスのプロビジョニング・OSパッチ（14日サイクル・Bottlerocket AMI）・スケーリングをAWSが管理します。GPUインスタンスや高メモリインスタンスが必要でAMI管理の負荷を下げたいチームに適しています。カスタムAMI不可・インスタンス継続稼働14日上限・SSH不可（ECS Execで代替）という制約があります。2025年12月にEC2 Spot対応が追加され、コスト最適化の選択肢が広がっています。

コンピュートモデル選択（§4）

Fargate・Fargate Spot・EC2起動タイプ・ECS Managed Instances・ECS Anywhereの5系統を「配置場所 → EC2管理度合い → Spot活用可否」の3ステップ意思決定木で絞り込みます。Fargate + Fargate Spotの混在（baseで最低タスク確保・残りをSpotで最大70%削減）、EC2 + Managed Instancesの段階移行など混在戦略も有効です。ECS AnywhereとManaged Instancesの混同は設計事故の原因になります。

ネイティブECS Blue/Green（§5）

2025年7月登場。ECS deployment controller内蔵でCodeDeploy・appspec.yml・ターゲットグループ2つが不要になります。ALL_AT_ONCE（即時）・CANARY（段階確認）・LINEAR（比率漸増）の3戦略をblueGreenDeploymentConfigurationで設定し、deployment lifecycle hooks（Lambda）で切替前後の自動検証を差し込めます。bake time中はBlueタスクを維持し、問題発生時はダウンタイムゼロで自動または手動ロールバックを選択できます。

EC2 managed scaling（§6）

EC2 ASG Capacity Provider専用の機能で、FARGATEおよびFARGATE_SPOTには非対応です。ECSが「Capacity Provider Reservation」メトリクスを算出してtargetCapacityとの差分でASGを自動増減させます。targetCapacity=100はコスト最小（新インスタンス起動待ち有り）、70〜90はバッファ確保で即時配置可能です。managed termination protectionでタスク実行中インスタンスをスケールインから自動保護できます。

デプロイ安全機構2025差分（§7）

circuit breaker・alarm連動ロールバック（基礎）の上に追加された3機能です。1-click rollbackはオペレーターが直前の完了済みデプロイに1操作で戻せる仕組みで、bake timeと組み合わせることでサイレント障害への即時対応が可能です。custom container stop signals（2025年12月）はタスク定義のstopSignalフィールドでECS停止シグナルをSIGTERMからSIGUSR1等に変更でき、アプリのgraceful shutdownをより細かく制御できます。Graviton Fargate Spot（2024年9月）によりARM64 + Spotで通常Fargateの最大約76%コスト削減が可能です。

8-2. 本番運用推奨チェックリスト（本記事範囲）

8-3. 関連記事と対象AWS試験

本記事が扱うECS Anywhere・Managed Instances・ネイティブBlue/Green・managed scalingの各機能は、以下の前提記事・関連記事と組み合わせてご活用ください。

▶ ECS基礎編（前提）: Amazon ECS 本番運用 Vol1 — Fargate/ECR/Service Connect/Capacity Provider/ECS Exec

▶ CodeDeploy版Blue/Green（使い分け）: ECS×Fargate Blue/Greenデプロイ編（CI/CDパイプラインVol2）

本記事の内容は次のAWS認定試験の出題範囲に対応しています。

• DVA-C02（Developer Associate）: ECS Anywhere のアーキテクチャ・EXTERNAL起動タイプ・デプロイ設定（circuit breaker・1-click rollback）
• DOP-C02（DevOps Engineer Professional）: ネイティブBlue/Greenのトラフィックシフト戦略・lifecycle hooks・bake time設計・EC2 managed scalingのtargetCapacity
• SAP-C02（Solutions Architect Professional）: コンピュートモデル選択の意思決定（Fargate / EC2 / Managed Instances / ECS Anywhere）・混在戦略・ハイブリッドアーキテクチャ設計