ECS on Fargate のコスト構造を分解する - Spot・ARM・スケーリングの実践的な組み合わせ
ECS on Fargate の料金体系を CPU・メモリ・ストレージの 3 軸で分解し、Fargate Spot、Graviton (ARM)、Service Auto Scaling を組み合わせたコスト最適化の実践手法を解説します。
Fargate の料金体系を正確に理解する
Fargate のコスト最適化は、料金体系の正確な理解から始まります。Fargate の課金は vCPU 秒とメモリ GB 秒の 2 軸で計算されます。us-east-1 の場合、vCPU あたり 1 時間 0.04048 USD、メモリ 1GB あたり 1 時間 0.004445 USD です。ここで見落としがちなのは、タスク定義で指定した CPU とメモリの組み合わせには制約があるという点です。たとえば 0.25 vCPU を選択した場合、メモリは 0.5GB、1GB、2GB のいずれかしか選べません。1 vCPU なら 2GB〜8GB の範囲です。実際のワークロードが 0.3 vCPU と 1.5GB メモリを必要とする場合、0.5 vCPU + 2GB の組み合わせを選ぶことになり、約 40% のリソースが無駄になります。この「切り上げコスト」を意識せずにタスク定義を設計すると、想定以上の料金が発生します。さらに、2024 年から Fargate のエフェメラルストレージが 20GB を超える場合は追加料金が発生するようになりました。大量の一時ファイルを扱うワークロードでは、EFS マウントとの比較検討が必要です。
Fargate Spot で最大 70% のコスト削減を実現する
Fargate Spot は、AWS の余剰キャパシティを利用して Fargate タスクを最大 70% 割引で実行する仕組みです。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 という構成にすれば、可用性を維持しながらコストを 30〜50% 削減できます。
Graviton (ARM) で同一性能を 20% 安く動かす
Fargate は 2023 年から Graviton (ARM64) アーキテクチャをサポートしています。Graviton ベースの Fargate タスクは、x86 と比較して vCPU あたり約 20% 安価で、かつ同等以上のパフォーマンスを発揮します。移行のハードルは、コンテナイメージを ARM64 向けにビルドする必要がある点です。Go、Node.js、Python、Java のような言語はクロスコンパイルやマルチアーキテクチャビルドが容易で、docker buildx を使えば 1 つの Dockerfile から AMD64 と ARM64 の両方のイメージを生成できます。C/C++ のネイティブ拡張に依存するライブラリがある場合は、ARM64 環境でのビルドとテストが必要です。タスク定義の runtimePlatform で cpuArchitecture を ARM64 に指定するだけで、Graviton 上で実行されます。Fargate Spot と Graviton は併用可能なので、両方を適用すれば通常の Fargate x86 と比較して最大 76% のコスト削減 (20% の Graviton 割引 + 70% の Spot 割引) を理論上実現できます。ただし、Spot の割引率は変動するため、実際の削減率は 50〜70% 程度と見積もるのが現実的です。
Service Auto Scaling の設計パターン
Fargate のコスト最適化で最も見落とされがちなのが、Service Auto Scaling の適切な設定です。スケーリングが遅すぎるとピーク時にパフォーマンスが劣化し、速すぎると不要なタスクが起動してコストが増加します。ECS Service Auto Scaling は、ターゲット追跡スケーリング、ステップスケーリング、スケジュールベーススケーリングの 3 種類をサポートしています。最も推奨されるのはターゲット追跡スケーリングです。CPU 使用率 70% をターゲットに設定すれば、ECS が自動的にタスク数を調整してターゲット値を維持します。ただし、ターゲット追跡スケーリングのスケールイン冷却期間はデフォルト 300 秒 (5 分) で、トラフィックが急減した後もタスクが 5 分間維持されます。コスト重視の場合は冷却期間を 120 秒に短縮できますが、トラフィックの波が激しいワークロードではフラッピング (頻繁なスケールイン・アウトの繰り返し) が発生するリスクがあります。予測可能なトラフィックパターンがある場合は、スケジュールベーススケーリングと組み合わせて、営業時間帯は最小タスク数を引き上げ、夜間は引き下げる設計が効果的です。
コスト最適化の優先順位と実践ステップ
Fargate のコスト最適化は、効果の大きい施策から順に適用するのが合理的です。第 1 ステップは、タスク定義の CPU・メモリ設定の見直しです。CloudWatch Container Insights で実際のリソース使用率を確認し、過剰にプロビジョニングされたタスクを適正サイズに変更します。これだけで 20〜40% のコスト削減が見込めます。第 2 ステップは、Graviton への移行です。コンテナイメージの ARM64 ビルドを追加し、タスク定義の cpuArchitecture を変更するだけで 20% のコスト削減が得られます。第 3 ステップは、Service Auto Scaling の導入です。固定タスク数で運用している場合、トラフィックの谷間で無駄なコストが発生しています。ターゲット追跡スケーリングを設定すれば、需要に応じたタスク数の自動調整でさらに 20〜30% の削減が可能です。第 4 ステップとして、中断耐性のあるワークロードに Fargate Spot を適用します。これら 4 つの施策を組み合わせれば、最適化前と比較して 50〜70% のコスト削減を実現できます。コンテナのコスト設計を体系的に学ぶには、専門書籍 (Amazon)が参考になります。