はじめに

この記事は、FUJITSU Advent Calendar 2025 22日目の記事です。

AWS ECSの キャパシティプロバイダー(Capacity Provider) を活用すると、
ECSクラスタのスケーリングをタスクの起動要求ベースで自動化できます。

今回は、この仕組みを使い「ECS on EC2」で動作するバッチ処理のスケーリングを
完全自動化した事例を紹介します。

背景

AWS ECS on EC2上でコンテナを運用しているシステムがありました。
追加開発要件として、「月に数日間だけ大規模バッチ処理を動かす」ことが発生したため
スケーリング設計を見直すことにしました。

既存構成と課題

従来はEC2 Auto Scaling Group(ASG)の「CPU使用率」をスケーリングトリガーとしておりました。

はじめはこのスケーリング手法を踏襲しようと思っていたのですが
検討を進めていく中でいくつかの課題が見つかりました。

バッチ開始時にEC2が自動起動しないため、事前に手動でEC2のスケールアウトが必要
バッチ終了後もEC2が自動でスケールインせず、不要なインスタンスが残る
CPU使用率を基準にしているため、スケールアウトまでに数分の遅延

タスクの起動リクエストが急増しても、CPU使用率が上がるまでEC2が増えないため、タスクの起動失敗が発生しておりました。

「タスク増加に応じてEC2も自動で増減してほしい」
そんな理想を叶えてくれそうなのが、キャパシティプロバイダーという仕組みでした。

キャパシティプロバイダーとは？

ECSのタスク起動要求をトリガーに自動でEC2の台数を調整してくれる仕組みです。
ポイントは以下の3点です。

・ECSは「タスク起動要求」を監視している
・タスク起動要求に対して、キャパシティが足りないと判断したら、自動でEC2をスケールアウト
・タスクが減って、必要キャパシティも少なくなったら、自動でEC2をスケールイン

これにより、「CPU使用率が上がるまで待つ」という遅延を解消し、ECSの需要とEC2の供給をリアルタイムに連動させられます。

詳しい仕組みはAWS公式ブログが参考になりそうです。

環境への設定

ECSコンソールの「インフラストラクチャー」タブから設定が可能です。

設定の中でポイントとなるのが「ターゲットキャパシティー(%)」です。
これはEC2のリソース使用率の目標値を指定するものです。
例えば90%に指定すると、「EC2リソースを90%利用した状態を保つ」ようにスケールが制御されます。
今回はバッチ処理でリソースを余すことなく使いたかったため、100% に設定しました。

ターゲットキャパシティを100%に設定するとEC2がフル稼働になります。

タスク配置戦略をbinpackにしたら、さらなるコスト削減に！

キャパシティプロバイダーによる自動スケーリングに加えて、タスク配置戦略をbinpackに変更しました。
binpack は、CPUまたはメモリの最小空きリソースに基づいてタスクを詰め込む戦略です。

binpack戦略を使うことで、少ないEC2台数でタスクを効率的に集約可能です。

結果として以下を実現できました。

EC2リソースを最大限に活用
バッチ終了後の自動スケールインが安定
従来方式からのコスト削減

個人的ベストプラクティスまとめ

設定項目	推奨値
ターゲットキャパシティ	100%
タスク配置戦略	binpack
ASG最小台数	0に指定

まとめ

キャパシティプロバイダーを導入することで、ECSタスク数とEC2スケーリングを連動できる
CPUベースのASGスケーリングでは困難だった、バッチ処理の自動スケールが実現可能
binpack戦略を組み合わせることで、さらなるコスト最適化も可能

ECS on EC2構成でも、キャパシティプロバイダーを導入すれば、Fargate並みの運用自動化を実現できます。

補足

ECSタスクのCPU/メモリサイジングは適切に設定すること。
リソース不足や過剰割り当てを防ぐことで、スケーリング精度が向上します。
Spotインスタンスや異なるインスタンスタイプの混在も可能。
これによりコスト最適化や冗長性の向上が期待できます