はじめに
2025 年 9 月 30 日、AWS は ECS Managed Instances を 6 リージョンで発表しました。
そして 2025 年 10 月 27 日、全商用AWSリージョンでの利用が可能になりました。
全リージョン展開によりグローバル展開企業にとっても現実的な選択肢となった今、「結局いつ使えばいいのか？」という疑問に答える必要があります。
ECS Managed Instances は「EC2 と Fargate のいいとこ取り」と言われますが、実際には明確なトレードオフと制約が存在します。
本記事では、3 つの選択肢の多角的な比較、採用判断基準、制約とその対処法についてまとめています。
ECS における 3 つの選択肢の詳細比較
ECS には以下の 3 つの主要なコンピュート選択肢があります。
- Amazon EC2：最も柔軟だが、最も手間がかかる
- AWS Fargate：インフラ管理ゼロだが、柔軟性は限定的
- ECS Managed Instances：EC2の柔軟性 + Fargateの運用容易性
本章ではいくつかの視点からそれぞれの選択肢を比較していきます。
インフラ管理と制御
| 項目 | EC2 | Fargate | Managed Instances |
|---|---|---|---|
| インスタンス管理 | ユーザー | 不要 | AWS |
| パッチ適用 | ユーザー責任 | AWS 自動 | AWS 自動（14 日サイクル） |
| Auto Scaling 設定 | ASG 手動設定必須 | タスク単位で自動 | 自動（タスクベース） |
| インスタンスタイプ選択 | 完全自由 | 選択不可 | 属性ベース指定 |
| カスタム AMI | 〇 | - | × |
| OS | 自由選択 | AWS 管理 | Bottlerocket（固定） |
| SSH アクセス | 〇 | - | × |
| デバッグ方法 | SSH/SSM/ECS Exec | ECS Exec | ECS Exec |
ポイント
- EC2：完全な制御が必要なら唯一の選択肢
- Fargate：管理を完全に手放したいなら最適
- Managed Instances：GPU 等の特殊 HW が必要だが管理は任せたい場合に最適
パフォーマンスと起動特性
| 項目 | EC2 | Fargate | Managed Instances |
|---|---|---|---|
| タスク起動速度 | 速い | 遅い（コールドスタート） | 速い |
| タスク配置 | 手動設定 | 1 タスク 1 環境 | 自動密集配置 |
| リソース効率 | 手動最適化 | 個別割り当て | 自動最適化 |
| GPU 対応 | 全種類 | 未対応 | 指定可能 |
| CPU Architecture | x86/ARM | x86/ARM | x86/ARM |
| Privileged Mode | 〇 | × | 〇 |
ポイント
- Managed Instances は自動的に複数タスクを密集配置してリソース利用を最適化
- GPU：EC2 と Managed Instances のみ対応
- Privileged Mode：EC2 と Managed Instances のみ対応
ネットワーク
| 項目 | EC2 | Fargate | Managed Instances |
|---|---|---|---|
| Network Mode | bridge/host/awsvpc/none | awsvpc（固定） | awsvpc/host |
| Service Connect | 〇 | 〇 | × |
| Service Discovery | 〇 | 〇 | 〇 |
| Load Balancer | ALB/NLB/CLB | ALB/NLB/GLB | ALB/NLB/GLB |
| Target Type | instance/ip | ip（固定） | ip（固定） |
ポイント
- Service Connect は Managed Instances で利用不可
- Service Discovery（DNS 名前解決）は全てで利用可能
- マイクロサービス統合に Service Connect が必須なら Fargate/EC2 を選択
ストレージ
| 項目 | EC2 | Fargate | Managed Instances |
|---|---|---|---|
| EBS Volume | 自由設定 | - | 30GB-16,384GB |
| Ephemeral Storage | - | 20GB-200GB | - |
| デフォルトサイズ | 設定次第 | 20GB | 80GB |
| EFS対応 | 〇 | 〇 | 〇 |
| Instance Store | 〇 | × | × |
ポイント
- Fargate は「ephemeral storage」（一時ストレージ）
- Managed Instances は EBS ボリューム（インスタンス間で共有されない）
- 大容量ストレージが必要なら EC2 or Managed Instances
セキュリティとコンプライアンス
| 項目 | EC2 | Fargate | Managed Instances |
|---|---|---|---|
| インスタンス寿命 | 無制限 | タスク単位 | 最大 14 日 |
| SSH | 設定次第 | - | 強制無効 |
| Root ファイルシステム | 通常 | イミュータブル | イミュータブル |
| SELinux | 設定次第 | 有効 | 有効 |
| コンプライアンス | PCI/HIPAA/FedRAMP | PCI/HIPAA/FedRAMP | PCI/HIPAA/FedRAMP |
ポイント
- Managed Instances は 14 日でインスタンスが自動入れ替わり（長時間実行タスクには不適）
- Managed Instances は SSH 完全無効
コストと最適化
| 要素 | EC2 | Fargate | Managed Instances |
|---|---|---|---|
| 基本料金 | EC2 料金 | vCPU + メモリ | EC2 料金 + 管理費 |
| 課金単位 | 秒（1 分最小） | 秒（1 分最小） | 秒（1 分最小） |
| Savings Plans | 〇 | 〇 | 〇 |
| Reserved Instances | 〇 | - | 〇 |
| Spot | 〇 | Fargate Spot | 未対応 |
| 過剰プロビジョニング | リスク高 | なし | リスク低 |
ポイント
- Managed Instances の管理費は追加コスト
ユースケース別適性マトリックス
| ユースケース | 最適 | 次点 | 避ける | 理由 |
|---|---|---|---|---|
| 一般 Web（Service Connect 使用） | Fargate | EC2 | Managed Instances | Service Connect 必須 |
| GPU 機械学習推論 | Managed Instances | EC2 | Fargate | GPU + 管理容易性 |
| バッチ処理（コスト優先） | EC2 Spot | Managed Instances | Fargate | コスト最優先 |
| 長時間実行タスク（15 日以上） | EC2 | Fargate | Managed Instances | 14日制限 |
| スタートアップ MVP | Fargate | Managed Instances | - | 速度優先 |
| カスタム AMI 必要 | EC2 | - | Managed Instances/Fargate | AMI 制約 |
採用判断フローチャート
よくある判断ミス
| 間違った判断基準 | なぜ問題か | 正しい判断基準 |
|---|---|---|
| 運用が楽そう | 制約（Service Connect 非対応等）を見落とす | 必要機能を満たすか確認 |
| コストが安そう | 管理費を考慮していない | 総コスト（EC2 + 管理費）で比較 |
| 新しいから | 既存で十分なケースも多い | 移行の必要性・ROI を検証 |
判断の原則
ワークロードの要件を先に明確化し、それに合った選択肢を選ぶ
見落としがちな制約
Service Connect 非対応
問題
マイクロサービス間の名前解決とメトリクス収集の統合機能が使えない
対処法
- Service Discovery（DNS 名前解決）で代替
- 内部 ALB でルーティング
- ハイブリッド構成：Fargate（フロントエンド）+ Managed Instances（バックエンド）
14 日のインスタンスライフタイム
問題
最大 14 日でインスタンスが入れ替わる
対処法
- タスクをステートレスに設計
- 外部ストア（DynamoDB/S3）に状態保存
- グレースフルシャットダウン実装（SIGTERM 対応）
- EC2 Event Windows でメンテナンス時間を制御
カスタム AMI 非対応
問題
Bottlerocket AMI 固定、OS 層のカスタマイズ不可
対処法
- 必要な機能をコンテナイメージに含める
- Init container で起動時設定
- そもそも OS 層のカスタマイズが必要か再検討
SSH アクセス不可
問題
セキュリティのため SSH 完全無効
対処法
- ECS Exec でコンテナ内アクセス
- ログ基盤の充実（CloudWatch Logs Insights）
- 運用を「SSH で調査」から「ログで調査」へ転換
まとめ
ECS Managed Instances の位置づけ
ECS Managed Instances は「GPU 等の特殊ハードウェアが必要だが、運用負荷は削減したい」という、これまで明確な解がなかったニーズに応える選択肢です。
採用判断の核心
選択を迷った時は、以下の 3 つの質問に答えてください。
- GPU や特定インスタンスタイプが必要か?
- Service Connect が必須か?
- タスクは 14 日以内に完了するか?
3 つ全てが Managed Instances 向きなら、採用を検討する価値があります。
全リージョン展開の意味
2025 年 10 月 27 日の全リージョン展開により、グローバル展開企業にも現実的な選択肢となりました。
ただし、「新しい = 良い」ではありません。制約を正確に理解し、ワークロードの特性に合った選択を行うことが重要です。
次のステップ
- 現状把握：既存ワークロードの要件を整理（GPU 要否、Service Connect 使用状況、実行時間）
- 小規模検証：非本番環境で 1-2 週間の PoC
- コスト試算：公式料金ページでコスト試算
- 段階的導入: 影響の小さいワークロードから開始