はじめに
Part3 まででコンテナアプリケーションの本番稼働環境を構築しましたが、今回は FARGATE_SPOT を導入してコストを大幅に削減します。
これまでの記事
- Part1: VPC 基盤インフラ構築
- Part2: HTTPS 対応
- Part3: ECS Fargate でアプリケーション稼働
- Part4（本記事）: FARGATE_SPOT でコスト最適化 ← 今ここ
対象読者
- ECS Fargate のコストを削減したい方
- FARGATE_SPOT の導入を検討している方
- Terraform でインフラをコード管理している方
- コンテナワークロードの最適化に興味がある方
概要
Part3 で構築した 3 つの ECS サービスのうち、静的サイト（Nginx） を FARGATE_SPOT に移行しました。
なぜ FARGATE_SPOT？
従来の FARGATE の課題:
- 24 時間稼働で月額約 $5.19
- 静的サイトには過剰なコスト
FARGATE_SPOT の利点:
- 最大 70% コスト削減（月額 $5.19 → $1.56）
- AWS 管理のインフラで運用負荷なし
- 自動フェイルオーバーで可用性を確保
開発環境
ローカル環境
| 項目 | バージョン/内容 |
|---|---|
| OS | Windows 11 |
| Terraform | v1.6.0 以上 |
| AWS CLI | v2.13.0 以上 |
AWS 環境
| 項目 | 内容 |
|---|---|
| リージョン | ap-northeast-1（東京） |
| ECS クラスター | app-cluster |
構成図
変更点
変更前:
Static Site Service → FARGATE で稼働 ($5.19/月)
変更後:
Static Site Service → FARGATE_SPOT で稼働 ($1.56/月)
↓ フォールバック
FARGATE (最低 1 タスク確保)
今回実現したこと
1. FARGATE_SPOT による 70% コスト削減
実装方法: Capacity Provider Strategy
resource "aws_ecs_service" "static_site" {
name = "static-site-service"
cluster = aws_ecs_cluster.main.id
task_definition = aws_ecs_task_definition.static_site.arn
desired_count = 1
# Fargate Spot優先でコスト削減（最大70%削減）
capacity_provider_strategy {
capacity_provider = "FARGATE_SPOT"
weight = 100 # SPOT を優先的に使用
base = 0 # SPOT でタスクを起動
}
capacity_provider_strategy {
capacity_provider = "FARGATE"
weight = 0 # 通常は使わない
base = 1 # 最低 1 タスクは FARGATE で確保
}
network_configuration {
subnets = [aws_subnet.private_fargate.id]
security_groups = [aws_security_group.fargate.id]
}
load_balancer {
target_group_arn = aws_lb_target_group.app.arn
container_name = "static-site-container"
container_port = 80
}
}
パラメータ解説:
| パラメータ | 値 | 説明 |
|---|---|---|
| FARGATE_SPOT | ||
| weight | 100 | SPOT を優先的に使用 |
| base | 0 | SPOT でタスクを起動 |
| FARGATE | ||
| weight | 0 | 通常は使わない |
| base | 1 | 最低 1 タスクは FARGATE で確保 |
動作イメージ:
- 通常時: FARGATE_SPOT でタスクが稼働（70% コスト削減）
- SPOT 中断時: FARGATE にフェイルオーバー（最低 1 タスク確保）
- SPOT 復旧時: 自動的に FARGATE_SPOT に戻る
2. 適切なワークロードの選定
FARGATE_SPOT に移行したサービス: 静的サイト（Nginx）
理由:
- ステートレス（セッション情報なし）
- 中断されても再起動で復旧可能
- 重要度が比較的低い
FARGATE_SPOT に移行しなかったサービス: Node.js, .NET Blazor
理由:
- アプリケーションロジックを持つ
- API エンドポイントとして使用
- 中断による影響が大きい
技術的なポイント
ポイント1: FARGATE_SPOT の仕組み
FARGATE_SPOT とは？
- AWS の余剰キャパシティを活用したサービス
- 通常の FARGATE より 最大 70% 安い
- AWS が容量を必要とする場合、2 分前に通知して中断
中断時の動作:
1. AWS から中断通知（2 分前）
↓
2. ECS が FARGATE_SPOT タスクを停止
↓
3. Capacity Provider Strategy により FARGATE にフェイルオーバー
↓
4. SPOT 容量が復旧したら自動的に SPOT に戻る
ポイント2: Base と Weight の使い分け
base（基準タスク数）:
- 最低限このキャパシティプロバイダーで起動するタスク数
- 上記例: FARGATE で最低 1 タスクを確保
weight（重み）:
- base を超えるタスクの分散比率
- 上記例: base を超えるタスクは 100% FARGATE_SPOT に配置
計算例（desired_count = 3 の場合）:
FARGATE: base=1 → 1 タスク
FARGATE_SPOT: weight=100 → 残り 2 タスク
結果: FARGATE 1 台、FARGATE_SPOT 2 台
ポイント3: コスト計算
FARGATE 料金（1 タスクあたり）: $5.19/月
FARGATE_SPOT 料金（70% 削減）:
$5.19 × 0.3 = $1.56/月
削減額:
$5.19 - $1.56 = $3.63/月（1 サービスあたり）
FARGATE_SPOT を使うべきワークロード
✅ 適している（SPOT 推奨）
-
バッチ処理
- 夜間実行のデータ処理
- レポート生成
- 定期的なバックアップ
-
ステートレスなウェブサービス
- 静的サイト（今回の例）
- キャッシュサーバー
- API プロキシ
-
開発/テスト環境
- 本番以外の環境
- CI/CD パイプライン
❌ 適していない（通常 FARGATE 推奨）
-
ステートフルなアプリケーション
- セッション管理が必要
- 長時間実行される処理
- データベース
-
高可用性が求められるサービス
- 決済処理
- 認証サービス
- リアルタイム通信
コスト試算
Part3 からの変更
| サービス | Part3 | Part4 | 削減額 |
|---|---|---|---|
| Node.js | $5.19 | $5.19 | $0 |
| .NET Blazor | $5.19 | $5.19 | $0 |
| Static Site | $5.19 | $1.56 | $3.63 |
| ECS 合計 | $15.57 | $11.94 | $3.63 |
全体コスト（月額）
| サービス | 詳細 | Part3 | Part4 | 削減額 |
|---|---|---|---|---|
| ALB | 時間料金 + LCU | $20.00 | $20.00 | $0 |
| VPC Endpoint | $7.30 × 3 | $21.90 | $21.90 | $0 |
| ECS Fargate | 3 サービス | $15.57 | $11.94 | $3.63 |
| ECR | イメージ保存 | $0.50 | $0.50 | $0 |
| CloudWatch Logs | 7 日保持 | $3.26 | $3.26 | $0 |
| 合計 | $61.23 | $57.60 | $3.63 |
削減率: 約 6%（ECS 部分では 23%）
感想
学んだこと
1. Capacity Provider Strategy の柔軟性
FARGATE_SPOT と FARGATE を組み合わせることで、コスト削減と可用性を両立できました。
# この設定だけで:
# - 通常時は SPOT でコスト削減
# - 中断時は FARGATE にフェイルオーバー
# - 完全に AWS が管理
capacity_provider_strategy {
capacity_provider = "FARGATE_SPOT"
weight = 100
base = 0
}
2. ワークロードの適性判断が重要
すべてのサービスを SPOT にすればよいわけではなく、適切なワークロードを見極める必要があります。
判断基準:
- ステートレスか？
- 中断されても問題ないか？
- 重要度は低いか？
苦労した点
-
どのサービスを SPOT にするか迷った
- 最初は全サービスを SPOT にしようとした
- 中断リスクを考慮して静的サイトのみに決定
-
Capacity Provider Strategy の理解
- base と weight の違いがわかりにくかった
- 実際に試して動作を確認した
参考資料
AWS 公式ドキュメント
読んだ本
- AWS コンテナ設計・構築本格入門
次回予告
Part5: 時間ベース Auto Scaling でさらなるコスト削減
以下を実装予定：
-
EventBridge + Lambda による時間制御
- 22:00 JST: 全サービス停止
- 05:00 JST: 全サービス起動
-
削減効果
- 現在: 24h 稼働で $11.94/月
- 削減後: 17h 稼働で $8.44/月（29% 削減）
お楽しみに！
まとめ
この記事で実現したこと
- ✅ FARGATE_SPOT で静的サイトのコストを 70% 削減
- ✅ Capacity Provider Strategy で可用性を確保
- ✅ 適切なワークロードの選定
- ✅ Terraform による完全な IaC 化
コスト削減効果
- 月額 $3.63 削減（ECS 部分で 23% 削減）
- 年間 $43.56 削減
次のステップ
- 🔧 時間ベース Auto Scaling の実装
- 🔧 監視・アラート基盤の構築
- 🔧 さらなるコスト最適化の検討