AWS Service Comparison Matrix (Compute)¶
ホスティング・コンピュートサービスの選定判断材料。EC2、コンテナ関連サービスを比較する。
History¶
| 日付 | 内容 |
|---|---|
| 2026-05-28 | 初版作成 |
| 2026-10-10 | AWS 公式ドキュメントで App Runner が新規顧客の受付を終了し、後継として Amazon ECS Express Mode への移行が案内されていることを確認。App Runner 行の最大メモリを実値 (12GB) に修正し、ECS Express Mode への移行案内を追記 (#911) |
| 2026-10-10 | AWS 公式ドキュメントで Lambda durable functions (AWS 公式) が GA 済みであることを確認。非同期実行時は最大 1 年までチェックポイント・再開が可能な長時間ワークフローを構築できる旨を Lambda 比較表に追記 (#935) |
Container Orchestration: ECS vs EKS vs App Runner¶
⚠️ App Runner は新規顧客の受付を終了済み (2026 年、AWS 公式)。既存顧客は従来どおり利用可能だが新機能追加は予定されていない。AWS は後継として Amazon ECS Express Mode への移行を案内している。ECS Express Mode は Fargate 上に ECS サービス・ALB・Auto Scaling・ネットワークを単一 API 呼び出しで自動構築し、App Runner 相当の運用簡易性を ECS の機能幅で提供する (追加課金なし、利用した AWS リソース分のみ課金)。新規構築では App Runner ではなく ECS Express Mode を検討する。
| 比較項目 | ECS | EKS | App Runner |
|---|---|---|---|
| ドキュメント | ECS | EKS | App Runner |
| 課金モデル | コントロールプレーン無料 + Fargate/EC2 課金 (料金) | クラスター \$0.10/h + Fargate/EC2 課金 (料金) | vCPU/メモリ従量 (料金) |
| 主用途 | AWS ネイティブなコンテナワークロード | Kubernetes エコシステム活用、マルチクラウド | シンプルな Web アプリ・API |
| SLA | 99.99% | 99.95% | 99.95% |
| 学習コスト | 低い | 高い (Kubernetes 知識必須) | 非常に低い |
| スケーリング | Service Auto Scaling | HPA / Karpenter / Cluster Autoscaler | 自動 (リクエストベース) |
| 主要サービス制限 | タスク数 5000/クラスター、サービス数 5000/クラスター (Quotas) | Pod 数 110/ノード、ノード数 5000/クラスター (Quotas) | 同時実行 200、最大 4 vCPU / 12GB メモリ、リクエストタイムアウト 120 秒 (Pricing) |
| コスト (常時高負荷) | 安い | 中程度 (クラスター費用加算) | 高い |
| コスト (バースト) | 中程度 | 中程度 | 安い (アイドル時課金なし) |
| ネットワーク制御 | VPC、Security Group、Service Connect | VPC、Security Group、Pod レベル制御 | VPC Connector (制限あり) |
| サービスメッシュ | ⚠️ Service Connect (基本的) | ✅ Istio / App Mesh / Linkerd | ❌ |
| CI/CD 統合 | CodeDeploy、ecspresso、CDK | ArgoCD、Flux、Helm | 自動デプロイ (ECR/GitHub 連携) |
| スケジュールタスク | ✅ EventBridge + ECS Task | ✅ CronJob | ❌ |
| GPU サポート | ✅ (EC2 起動タイプ) | ✅ | ❌ |
| Windows コンテナ | ✅ | ✅ | ❌ |
| マルチクラウド移植性 | ❌ AWS 専用 | ✅ Kubernetes 標準 | ❌ AWS 専用 |
| Terraform 対応 | ✅ | ✅ | ✅ |
Guidelines¶
→ ECS を標準採用する。 AWS ネイティブで学習コスト・運用負荷が低く、Fargate との組み合わせでインフラ管理を最小化できる。
- Kubernetes エコシステム (Helm、ArgoCD、Istio 等) の活用やマルチクラウド移植性が必要な場合は EKS を検討
- シンプルな Web API で VPC 制御やスケジュールタスクが不要な場合は ECS Express Mode を検討 (App Runner は新規顧客受付終了のため新規採用を避ける)
- 既存の App Runner ワークロードは ECS Express Mode への移行を計画する (AWS 公式が移行手順を提供)
- App Runner はネットワーク制御・カスタマイズ性に制限があるため、要件が複雑化した時点で ECS へ移行する前提で採用する
Compute Host: EC2 vs ECS on Fargate vs ECS on EC2 vs Lambda¶
ℹ️ Lambda durable functions (AWS 公式) が GA 済み。関数コード内でチェックポイント・再開を伴う複数ステップのオーケストレーションを記述でき、非同期実行では最大 1 年まで実行可能 (同期実行は従来どおり最大 15 分)。AI エージェントのような長時間・多段階ワークフローで Step Functions を使わずに Lambda の開発体験のまま実装したい場合に検討する。
| 比較項目 | EC2 | ECS on Fargate | ECS on EC2 | Lambda |
|---|---|---|---|---|
| ドキュメント | EC2 | Fargate | ECS | Lambda |
| 課金モデル | インスタンス時間 RI/SP 割引あり (料金) | vCPU + メモリ秒 (料金) | EC2 インスタンス RI/SP 割引あり (料金) | リクエスト + 実行時間 (料金) |
| 主用途 | フルカスタマイズが必要なワークロード | 標準的なコンテナワークロード | GPU/大容量メモリ/特殊要件 | イベント駆動・短時間処理 |
| SLA | 99.99% | 99.99% (ECS SLA) | 99.99% | 99.95% |
| 学習コスト | 中程度 (OS 管理含む) | 低い | 中程度 | 低い |
| スケーリング | Auto Scaling Group (分単位) | Service Auto Scaling (分単位) | ASG + Service Auto Scaling (分単位) | 自動 (秒単位) |
| 主要サービス制限 | インスタンスタイプ依存 (Quotas) | 16 vCPU / 120 GB メモリ (Quotas) | インスタンスタイプ依存 (Quotas) | 実行時間 15 分、メモリ 10GB、ペイロード 6MB、同時実行 1000 (Quotas) |
| コスト (常時高負荷) | 安い (RI/SP 適用時) | 中程度 | 安い (RI/SP 適用時) | 高い |
| コスト (バースト) | 高い (ピークに合わせたサイジング) | 中程度 | 高い | 安い (使った分だけ) |
| 最大実行時間 | 無制限 | 無制限 | 無制限 | 15 分 |
| コールドスタート | なし (常時稼働) | あり (数十秒) | なし (常時稼働) | あり (数百 ms〜数秒) |
| 最大リソース | インスタンスタイプ依存 (数百 vCPU) | 16 vCPU / 120 GB メモリ | インスタンスタイプ依存 | 10 GB メモリ / 6 vCPU |
| ステートフル | ✅ | ⚠️ (EBS マウント可、制限あり) | ✅ | ❌ |
| SSH アクセス | ✅ | ❌ (ECS Exec で代替) | ✅ | ❌ |
| OS カスタマイズ | ✅ | ❌ | ✅ | ❌ |
Guidelines¶
→ ECS on Fargate を標準採用する。 インフラ管理不要でコンテナワークロードに集中でき、運用負荷が最も低い。
- 常時高負荷で RI/SP によるコスト最適化が重要な場合は ECS on EC2 を検討
- GPU、特殊カーネルモジュール、大容量メモリが必要な場合は ECS on EC2 または EC2 を検討
- イベント駆動で 15 分以内に完了する処理は Lambda を検討
- 複数ステップにまたがる長時間処理 (AI ワークフロー等) を Lambda の開発体験のまま実装したい場合は Lambda durable functions (非同期実行、最大 1 年) を検討
- EC2 直接利用はレガシーワークロードの移行先、または特殊要件がある場合に限定する
ECS Launch Type: Fargate vs EC2¶
| 比較項目 | Fargate | EC2 |
|---|---|---|
| ドキュメント | Fargate | ECS on EC2 |
| 課金モデル | vCPU + メモリ秒 (料金) | EC2 インスタンス時間 (料金) |
| 主用途 | 標準コンテナワークロード | GPU/高密度/特殊要件ワークロード |
| SLA | 99.99% (ECS SLA) | 99.99% |
| 学習コスト | 低い | 中程度 (AMI/容量管理) |
| スケーリング | タスク単位で自動 | インスタンス + タスクの 2 層管理 |
| 主要サービス制限 | タスクサイズ 16 vCPU/120GB、ENI 数制限 (Quotas) | インスタンスタイプ依存 (Quotas) |
| コスト (常時高負荷) | 高い | 安い (RI/SP + 高密度配置) |
| コスト (バースト) | 安い (使った分だけ) | 高い (インスタンス常時課金) |
| インフラ管理 | 不要 | AMI 更新、パッチ適用、容量管理必要 |
| 最大タスクサイズ | 16 vCPU / 120 GB | インスタンスタイプ依存 |
| EBS マウント | ✅ (制限あり) | ✅ |
| EFS マウント | ✅ | ✅ |
| GPU | ❌ | ✅ |
| Spot 利用 | ✅ Fargate Spot (最大 70% 割引) | ✅ Spot Instance |
| RI/SP 割引 | ✅ Savings Plans | ✅ RI + Savings Plans |
| daemonset 相当 | ❌ | ✅ (daemon スケジューリング) |
Guidelines¶
→ Fargate を標準採用する。 運用負荷の削減を最優先し、インフラ管理をゼロにする。
- 月額コストが Fargate > EC2 (RI 適用) で 30% 以上差が出る高負荷ワークロードは EC2 起動タイプを検討
- GPU ワークロードは EC2 起動タイプ必須
- daemonset パターン (サイドカーではなくホストレベルのエージェント) が必要な場合は EC2 起動タイプを検討