AWSは最近、EC2 Auto Scaling向けのウォームプールをリリースした。これは、事前に初期化されたインスタンスのプールを維持することで、アプリケーションをスケールアウト（水平スケール）するための時間とコストを削減する。
ウォームプールは、構成された数のインスタンスをバックグラウンドで起動する。それによって、長い時間がかかるアプリケーションの初期化またはブートストラップを実行できるようになり、その後、必要になるまでそれらのインスタンスを止めておくことができる。さらに、ユーザはウォームプールを停止しないように設定して、停止状態から実行状態に移行することによって発生する遅延を減らすことができる。
ウォームプールはカスタマイズ可能であり、ユーザはプールのサイズを構成したり、インスタンスの状態を変更したり、ライフサイクルフックを有効にしたりできる。
2009年以来、AWSの顧客はEC2 Auto Scalingを使ってAWSでアプリケーションを構築およびスケールすることができる。EC2は、自動スケーリンググループを使ってリアルタイムのアプリケーションに対する需要に対応する方法を提供するが、一方でインスタンスをブートストラップするのに長い時間がかかっていた。
ウォームプール内の事前に初期化されたインスタンスを起動して、最短30秒でトラフィックを処理できる。これは、数秒で稼働する通常のスケールアウトタスクには最適ではない場合があるが、特に起動時間が長いアプリケーション（データベース、アプリケーションサーバーなど）では、起動時間が大幅に短縮される。
遅延の問題を回避するために、一部のユーザは、自動スケーリンググループの最小サイズを増やして、アプリケーションに対する需要が増加したときにすぐに利用できるインスタンスがあることを保証する必要があった。過剰なプロビジョニングは、コストの増加、コンピューティングの浪費、メトリックの偏りなど、他の問題を引き起こした。
EC2向けのウォームプールを使用する際に留意すべきいくつかの制限がある。
ウォームプールは、混合インスタンスポリシーがある、またはスポットインスタンスを使用している自動スケーリンググループに追加できない。CloudFormationまたはCodeDeployは、この記事の執筆時点ではサポートされておらず、まもなく提供される可能性がある。
Elastic Container Services (ECS)あるいはElastic Kubernetes Service (EKS)でウォームプールを使用している場合、これらのサービスは、インスタンスがウォームプールを利用できるようになる前に、インスタンスでジョブをスケジュールする場合がある。
EC2インスタンスは、そこに接続されているAmazon Elastic Block Store（EBS）ボリュームを唯一のルートデバイスとして使用している場合にのみ、停止状態にすることができる。インスタンスストアをルートデバイスとして使用しているインスタンスは停止できない。
スケールアウトイベントが発生したときにウォームプールが使用可能なすべてのインスタンスを使い果たすと、インスタンスは自動スケーリンググループに直接起動する（コールドスタートとも呼ばれる）。また、これは、アベイラビリティーゾーンの容量が不足している場合に起こる可能性がある。
ウォームプールを使用すると、インスタンスを事前に初期化することで、自動スケーリンググループを使用してアプリケーションを迅速にスケールアウトできるようになり、サービスをすぐに利用できるようになる。
ウォームプールはライフサイクルフックと組み合わせることで、インスタンスがウォームプールに出入りするときに、開発者とオペレーターがアプリケーションの操作を管理できるようになる。ユーザは、最新のAWSコマンドラインインターフェース（CLI）あるいは任意のAWS SDKを使ってウォームプールの使用を始めることができる。