LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

ECS/Fargateのコストが膨らむ理由：タスクサイズ×稼働×台数と過剰割り当て

ECS/Fargateのコスト最適化とは、Amazon ECS（Elastic Container Service）上でサーバーレスにコンテナを実行するAWS Fargateの課金コストを、AWS公式の推奨手法を用いて体系的に削減する取り組みを指します。

AWS公式によると、Fargateの料金はタスクに割り当てたvCPUとメモリの量に、タスクの稼働時間を掛け合わせて計算されます^*1。つまり「タスクサイズ（vCPU・メモリ）×稼働時間×同時稼働タスク数」がコストの基本構成です。この3要素のいずれかが過剰であれば、余分なコストが発生し続けます。

コストが膨らむ典型的なパターンは「タスクへのvCPU・メモリの過剰割り当て」です。実際の処理に必要なリソース量より多く割り当てると、余分なvCPU・メモリ時間分がそのまま課金されます。AWS Cost Optimization Hub（コスト最適化ハブ）を使うと、実際のリソース使用率と割り当て量の乖離を可視化できます^*1。

もう一つの原因は「常時フルスタンバイ」です。アクセスが少ない深夜帯や週末もピーク時と同じタスク数を稼働させ続けると、稼働時間分の課金が積み重なります。Application Auto Scaling（アプリケーション・オートスケーリング）を導入して負荷に応じてタスク数を増減させることが、この無駄を解消する基本です。

Kubernetes（K8s）と異なり、Fargateはクラスタノードの管理が不要なサーバーレス実行環境です。ノードのEC2インスタンス選定・オートスケーラー設定・ノードグループ管理が不要な分、インフラ運用の工数は少なくなります。その代わりコストの単位がタスクの割り当てリソースに直結するため、タスク定義のサイズ調整が費用削減の中心的な作業になります。

Fargate Spotの活用：中断耐性ワークロードとCapacity Provider戦略

Fargate Spot（ファーゲート・スポット）は、中断耐性のあるワークロード向けにAWSの余剰キャパシティを利用する仕組みです。AWS公式によると、通常のFargate（オンデマンド）に比べて大幅に低い価格水準で利用でき、AWSが公表している目安として割引が示されています^*2。ただし価格はAWSの余剰キャパシティの状況で変動するため、固定の割引率ではありません。

中断が発生する際、AWS公式によるとタスクへSTOPPEDシグナル（SIGTERM）が送られ、その後にタスクが停止します^*2。アプリケーション側でこのシグナルを受け取り、処理の状態をS3等に保存したり未完了ジョブをキューに戻す仕組みを実装することが、Fargate Spot活用の前提条件です。

Fargate Spotに向くワークロード

中断耐性があり、かつ継続的な稼働が必須でない処理がFargate Spotの適用候補です。代表的なものとして次の種類があります。

• バッチ処理・データパイプライン：ログ集計・ETL処理・機械学習の前処理など、再実行可能な処理
• CI/CDパイプラインのテスト実行：テストが失敗しても再実行できる構成
• 開発・検証環境のワークロード：本番への影響がなく、中断しても再起動で対応できる環境
• 非同期タスク処理：Amazon SQSなどのキューと組み合わせた非同期処理

一方、常時稼働が必要なAPIサーバーや、ユーザーリクエストを直接受けるウェブ層は中断の影響が大きいため、Fargate Spotには向きません。これらは通常のFargate（オンデマンド）またはSavings Plansの対象とすることが適切です。

Capacity Provider戦略：通常タスクとFargate Spotの混在

AWS公式によると、ECSのCapacity Provider（キャパシティプロバイダー）戦略を設定することで、通常FargateとFargate Spotを同一のサービスで混在させることができます^*2。たとえばベースとなるタスクを通常Fargateで確保しつつ、追加の処理分をFargate Spotで補う構成が可能です。

この戦略では、Fargate Spotの容量が確保できない場合に自動的に通常Fargateへフォールバックする設定も行えます。中断リスクを許容しながらも、稼働保証が必要なベースラインを維持できる点がCapacity Provider戦略の利点です。

Graviton（ARM64）と右サイジング：価格性能比とCost Optimization Hubの活用

GravitonはAWSが独自に開発したARMベースのプロセッサです。AWS公式によると、GravitonベースのFargate（ARM64アーキテクチャ）は、x86アーキテクチャと比べて価格性能比が高く、同等の処理を低コストで実行できるとされています^*1。Fargate Spotもx86・ARM64の両アーキテクチャで利用可能です。

Graviton移行の手順は、タスク定義のruntimePlatformでCPU_ARCHITECTUREをARM64に指定し、コンテナイメージをlinux/arm64としてビルドし直すことです。マルチアーキテクチャイメージを作成すれば、x86環境との共存も可能です。ただし、使用しているライブラリや依存パッケージがARM64に対応しているかの事前確認が必要です。

右サイジング：CPU/メモリの実使用に合わせた最適化

「右サイジング（right-sizing）」とは、タスクに割り当てるvCPUとメモリを、実際の使用量に合わせて最適化することです。AWS公式によると、Cost Optimization Hub（コスト最適化ハブ）ではECS Fargateのタスクに対して、実際のリソース使用率に基づいた推奨割り当てサイズを確認できます^*1。

右サイジングに取り組む際は、まずCloudWatch（クラウドウォッチ）のメトリクスやCost Optimization Hubで現在の実使用率を確認し、余裕率を含めた適切な割り当て値を算出します。過小割り当てによるスロットリング（処理遅延・エラー）を避けるため、段階的に縮小しながらアプリケーションの動作を確認することが重要です。

内製チームがこれらを適切に進めるには、ECSのタスク定義管理・CloudWatchによるリソースメトリクスの読み取り・ARM64向けイメージのビルド設定変更という複合的な作業が必要です。誤ったサイジングはアプリケーションの性能劣化につながるリスクがあります。

オートスケールとSavings Plans：Application Auto Scalingと割引の組み合わせ

タスク数を需要に応じて自動調整するApplication Auto Scalingは、常時フルスタンバイのコスト無駄を解消する手段です。AWS公式によると、ECS上のサービスに対してApplication Auto Scalingを設定することで、CPUやメモリ使用率・カスタムメトリクスに基づいてタスク数を自動的に増減できます^*3。

スケーリングポリシーには「ターゲット追跡スケーリング」「ステップスケーリング」「スケジュールスケーリング」の3種類があります。ターゲット追跡スケーリングは指定したメトリクス値（例：CPU使用率60%）を維持するようにタスク数を調整します。スケジュールスケーリングは夜間・週末などアクセスが少ない時間帯のタスク数を予め減らすのに有効です。

Compute Savings PlansとFargate Spot の組み合わせ

AWS公式によると、Compute Savings PlansはAWS Fargateの使用に対しても適用されます^*1。1年または3年の利用量を前約することで、オンデマンドFargate料金から割引を受けられます。常時稼働するAPIサーバーや安定したベースライン負荷があるサービスに有効です。

Savings PlansはFargate Spotと組み合わせることもできます。稼働し続けるベースライン分をSavings Plansでカバーし、変動分や中断耐性のあるバッチ処理はFargate Spotで補うCapacity Provider戦略が、コスト削減の複合的なアプローチとして推奨されています。

Savings Plansの適正な前約量は、過去の使用量をAWS Cost ExplorerのSavings Plans推奨事項機能で確認して決めることが大切です。前約量を過大にすると、使い切れない場合にも課金が発生してしまいます。

最適化の進め方と外注の使いどころ：診断・設計・実装の委託判断軸

ECS/Fargateのコスト最適化を実際に進めるには、コスト診断・手法選定・設計・実装・テスト検証・継続モニタリングという複数の専門的な工程が必要です。各工程で異なるスキルと判断が求められます。

内製対応が難しくなる3つの場面

外注委託を検討する場面として、次の3点が挙げられます。

第一に、Cost Optimization Hubでの診断結果をどのような順序・優先度で対応するか判断できない場合です。右サイジング・Fargate Spot・Graviton・Savings Plansのいずれを先に対応すべきかは、ワークロードの特性・現在のコスト構成・実装難易度を総合的に判断する必要があります。

第二に、Fargate Spotの中断耐性実装の経験がない場合です。SQSキューとの組み合わせ・SIGTERM受信処理・状態保存ロジックの実装は、コンテナアプリケーションとAWSのサービス連携の両方の知識が必要です。実装を誤ると、中断時にデータが失われたりジョブが二重実行されるリスクがあります。

第三に、Graviton移行を適切な手順で進める体制がない場合です。ARM64対応のビルド環境構築・依存ライブラリの互換性確認・CI/CDパイプラインの変更・本番前の十分なテストを実施しないと、移行後に本番障害が発生します。これらを内製で適切に進めるには、コンテナビルド・AWS ECS・ARM64対応の知識を持つエンジニアの工数が必要になります。

外注委託先を選ぶ判断軸

委託先を選定する際は、以下の3点を確認することが大切です。まず、ECS/Fargateのコスト最適化設計の実績があるかどうかです。Fargate Spot・Graviton・右サイジングの組み合わせ対応経験がない委託先では、対応品質が不安定になります。

次に、コスト診断から設計・実装・テスト検証まで一貫して対応できるかです。診断フェーズと実装フェーズを別の委託先に分けると、診断結果の意図が実装に伝わらずコスト削減が中途半端になります。元請（プライムベンダー）として一括受託できるベンダーを選ぶと、工程間の情報ロスを防ぎやすいです。

また、導入後の継続的なコスト効果測定と定期的な最適化提案の体制があるかも重要です。ECS/Fargateのコスト最適化はワークロードの増加・新機能追加・Savings Plansの前約更新など、継続的な見直しが必要です。初期設計だけでなく運用フェーズも見据えた委託先選定が長期的なコスト管理につながります。

委託の進め方：診断フェーズから段階的に

全工程を一括で委託するより、まず「コスト診断フェーズ」から始める段階的な進め方がリスクを抑えやすいです。現状のタスク定義・稼働パターン・コスト構成を可視化し、削減できる余地と優先度を整理した上で、設計・実装フェーズへ移行するかを判断する流れが実務的です。

内製チームがAWS上の操作権限を保持したまま、設計の判断支援や技術レビューだけを委託するかたちも選択肢です。この場合は委託範囲（診断のみか、実装まで含めるか）を契約前に明確にしておくことが重要です。

まとめ：ECS/Fargateコスト最適化外注の3つの判断軸

本稿では、ECS/Fargateのコスト構造から主要な削減手法（Fargate Spot・Graviton・右サイジング・Application Auto Scaling・Savings Plans）、外注委託の判断軸までを整理しました。要点を3つにまとめます。

第一に、ECS/FargateのコストはタスクのvCPU・メモリ割り当て×稼働時間×タスク数で決まります。過剰割り当てと常時フルスタンバイがコスト増の主因です。Cost Optimization Hubで実使用率と割り当て量の乖離を可視化することが最適化の出発点になります。

第二に、Fargate SpotはAWS公表の目安として大幅に低い価格水準で利用できますが、中断耐性の実装が前提です。GravitonはARMベースで価格性能比が高く、x86からの切り替えで同等の処理をより低コストで実行できます。Capacity Provider戦略で通常FargateとFargate Spotを組み合わせることで、安定性とコスト削減を両立できます。

第三に、診断・設計・中断耐性実装・Graviton移行には複合的な専門知識が必要です。内製対応が難しい場合は診断フェーズからの段階的な外注委託が有効です。委託先にはFargate最適化の実績・一貫対応体制・継続モニタリングの提供有無を確認してから依頼しましょう。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「AWS Fargate の料金」（2025年）
2. *2　出典：Amazon Web Services「AWS Fargate キャパシティプロバイダー」（2025年）
3. *3　出典：Amazon Web Services「Amazon ECS サービスのオートスケーリング」（2025年）

Tweet