ECS on Fargate のコスト構造を分解する - Spot・ARM・スケーリングの実践的な組み合わせ
ECS on Fargate の料金体系を CPU・メモリ・ストレージの 3 軸で分解し、Fargate Spot、Graviton (ARM)、Service Auto Scaling を組み合わせたコスト最適化の実践手法を解説します。
Fargate の料金体系を正確に理解する
Fargate のコスト最適化は、料金体系の正確な理解から始まります。Fargate の課金は vCPU 秒とメモリ GB 秒の 2 軸で計算されます。単価はリージョンごとに異なり改定も入るため、対象リージョンの vCPU 単価とメモリ単価は AWS 公式の Fargate 料金ページで確認します。ここで見落としがちなのは、タスク定義で指定した CPU とメモリの組み合わせには制約があるという点です。たとえば 0.25 vCPU を選択した場合、メモリは 0.5GB、1GB、2GB のいずれかしか選べません。1 vCPU なら 2GB〜8GB の範囲です (組み合わせ表は AWS 公式ドキュメント・2026 年 9 月時点)。実際のワークロードが 0.3 vCPU と 1.5GB メモリを必要とする場合、0.5 vCPU + 2GB の組み合わせを選ぶことになり、vCPU は 40% (0.2/0.5)、メモリは 25% (0.5/2) が使われないまま課金されます。無駄の割合は軸ごとに違うため、切り上げの主因が CPU 側かメモリ側かを分けて把握するのが先です。この「切り上げコスト」を意識せずにタスク定義を設計すると、想定以上の料金が発生します。エフェメラルストレージは 1 タスクあたり 20GB が既定で付属し、この範囲なら追加料金はかかりません (AWS 公式の Fargate 料金ページ・2026 年 9 月時点)。課金対象は 20GB を超えて設定した分だけで、上限は 200GiB です (200GiB までの設定は 2021 年 4 月の AWS 発表で対応・上限値は 2026 年 9 月時点の公式ドキュメントでも同じ)。大量の一時ファイルを扱うワークロードでは、EFS マウントとの比較検討が必要です。
Fargate Spot で最大 70% のコスト削減を実現する
Fargate Spot は、AWS の余剰キャパシティを利用して Fargate タスクを最大 70% 割引 (AWS 公式の Fargate 料金ページ・2026 年 9 月時点の表記) で実行する仕組みです。EC2 Spot インスタンスと同様に、キャパシティが不足すると 2 分前の通知後にタスクが中断されます。Fargate Spot を効果的に活用するには、ワークロードの中断耐性を正しく評価する必要があります。バッチ処理、データ変換パイプライン、CI/CD のビルドジョブ、開発・テスト環境のように、中断されても再実行可能なワークロードが最適な候補です。ECS サービスでは、キャパシティプロバイダー戦略を使って Fargate と Fargate Spot の比率を制御できます。たとえば、base を 2 (最低 2 タスクは通常 Fargate で確保)、Fargate Spot の weight を 3、通常 Fargate の weight を 1 に設定すれば、ベースラインの 2 タスクは安定稼働を保証しつつ、スケールアウト分の 75% を Spot で賄えます。本番環境の Web サービスでも、この戦略でベースラインは通常 Fargate、ピーク時の追加タスクは Spot という構成にすれば、可用性を維持したままピーク分のコストを抑えられます。上の例ではスケールアウト分の 75% が Spot になるため、最大 70% の割引が効けば追加タスクのコストは半分以下まで下がります。
Graviton (ARM) で同じ構成を 20% 安く動かす
Fargate は 2021 年から Graviton (ARM64) アーキテクチャをサポートしています (ECS on Fargate の Graviton2 対応は 2021 年 11 月に AWS 公式ブログで発表されました)。Graviton ベースの Fargate タスクは、x86 と比較して約 20% 安価です (AWS が 2021 年 11 月の発表で示した「20% 低いコスト」が根拠・現行の単価差は公式の料金ページで確認します)。性能の出方はワークロードの特性で変わるため、移行前に自環境で比較測定します。移行のハードルは、コンテナイメージを ARM64 向けにビルドする必要がある点です。Go、Node.js、Python、Java のような言語はクロスコンパイルやマルチアーキテクチャビルドが容易で、docker buildx を使えば 1 つの Dockerfile から AMD64 と ARM64 の両方のイメージを生成できます。C/C++ のネイティブ拡張に依存するライブラリがある場合は、ARM64 環境でのビルドとテストが必要です。タスク定義の runtimePlatform で cpuArchitecture を ARM64 に指定するだけで、Graviton 上で実行されます。Fargate Spot と Graviton は併用できます (AWS 公式の Fargate 料金ページに Fargate Spot の Linux/ARM 単価が掲載されています・2026 年 9 月時点。利用できる組み合わせは AWS 公式ドキュメントで確認します)。両方を適用すれば Graviton の約 20% 割引と Spot の最大 70% 割引が重なりますが、Spot の割引率はキャパシティの状況で変動します。理論値を前提に予算を組まず、適用後の請求で実際の削減幅を確認してください。
Service Auto Scaling の設計パターン
Fargate のコスト最適化で最も見落とされがちなのが、Service Auto Scaling の適切な設定です。スケーリングが遅すぎるとピーク時にパフォーマンスが劣化し、速すぎると不要なタスクが起動してコストが増加します。ECS Service Auto Scaling は、ターゲット追跡スケーリング、ステップスケーリング、スケジュールベーススケーリングに加え、履歴パターンに基づく予測スケーリングをサポートしています (AWS 公式ドキュメント・2026 年 9 月時点)。まず検討しやすいのはターゲット追跡スケーリングです。CPU 使用率 70% をターゲットに設定すれば、ECS が自動的にタスク数を調整してターゲット値を維持します。ただし、ターゲット追跡スケーリングのスケールイン冷却期間は ECS サービスではデフォルト 300 秒 (5 分・Application Auto Scaling の公式ドキュメント 2026 年 9 月時点) で、トラフィックが急減した後もタスクが 5 分間維持されます。コスト重視の場合は冷却期間を 120 秒に短縮できますが、トラフィックの波が激しいワークロードではフラッピング (頻繁なスケールイン・アウトの繰り返し) が発生するリスクがあります。予測可能なトラフィックパターンがある場合は、スケジュールベーススケーリングと組み合わせて、営業時間帯は最小タスク数を引き上げ、夜間は引き下げる設計が効果的です。
コスト最適化の優先順位と実践ステップ
Fargate のコスト最適化は、効果の大きい施策から順に適用するのが合理的です。第 1 ステップは、タスク定義の CPU・メモリ設定の見直しです。CloudWatch Container Insights で実際のリソース使用率を確認し、過剰にプロビジョニングされたタスクを適正サイズに変更します。削減幅は現状どれだけ切り上げているかで決まります (本記事では 20〜40% 程度を目安としていますが、AWS が公表している数値ではありません)。第 2 ステップは、Graviton への移行です。コンテナイメージの ARM64 ビルドを追加し、タスク定義の cpuArchitecture を変更すれば、Graviton の単価差がそのまま効きます。第 3 ステップは、Service Auto Scaling の導入です。固定タスク数で運用している場合、トラフィックの谷間で無駄なコストが発生しています。ターゲット追跡スケーリングを設定すれば、需要に応じてタスク数が自動調整され、谷間の無駄がそのまま削れます (本記事の目安は 20〜30% で、実際の効果はトラフィックの変動幅に比例します)。第 4 ステップとして、中断耐性のあるワークロードに Fargate Spot を適用します。AWS が公式に示している割引率は Fargate Spot の最大 70% (料金ページ・2026 年 9 月時点) と Graviton の約 20% (2021 年 11 月の発表値) で、残る 2 つの施策は現状の過剰分をどれだけ削れるかに依存します。合計の削減率は構成によって大きく変わるため、施策を 1 つ適用するごとに Cost Explorer で前後を比較し、効果を確かめてから次へ進むのが確実です。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。