AWS Auto Scalingの設計と実践｜EC2スケーリングポリシーと本番環境での安定稼働
現場実践｜AWS Auto Scaling設計
AWS Auto Scalingの設計と実践｜EC2スケーリングポリシーと本番環境での安定稼働
「急なアクセス急増でEC2が落ちた」「コスト削減のためにサーバーを自動で減らしたい」——AWS Auto ScalingのEC2 Auto Scalingグループ・スケーリングポリシーの種類・本番環境での安定稼働のための設定を解説します。
💡 Auto Scalingは「負荷に応じてEC2を自動で増減させる」サービス。「繁忙期だけ台数を増やす」「深夜は台数を減らしてコストを削減する」という設計がAWSで最も費用対効果の高いアプローチです。
1. Auto Scalingグループの基本設定
- 起動テンプレートを使う：EC2の起動設定は必ず起動テンプレート（Launch Template）を使う。旧来の起動設定（Launch Configuration）は非推奨になっている
- マルチAZ配置：Auto Scalingグループは必ず複数のアベイラビリティゾーンにまたがって配置する。1つのAZに障害が発生しても残りのAZで継続稼働できる
- 最小・希望・最大台数の設定：最小台数は本番環境では2台以上に設定。希望台数はクールタイム経過後の安定台数。最大台数はコスト上限として機能する
2. スケーリングポリシーの3種類
| ポリシー種別 | 動作の仕組み | 適したユースケース |
|---|---|---|
| シンプルスケーリング | CloudWatchアラームがトリガーされたら指定台数を追加・削除 | シンプルな設定で十分な場合 |
| ステップスケーリング | CPU使用率の閾値に応じて段階的に台数を変更（60%→+2台、80%→+4台等） | 負荷の変化が大きいWebアプリ |
| ターゲット追跡スケーリング | CPU使用率を指定した目標値に維持するよう自動調整（例：CPU50%を維持） | 最も推奨。シンプルで効果的 |
3. スケールアウト・スケールインの注意点
ウォームアップ期間
新しいEC2が起動してアプリが準備完了するまでの時間。この間は新インスタンスをヘルスチェックの判定に含めないよう設定する。
スケールイン保護
処理中のEC2を途中で削除されないよう、スケールイン保護を一時的に有効化する仕組み。バッチ処理中のインスタンスに特に重要。
スケジュールスケーリング
毎朝9時に最小台数を4台に増やして、深夜2時に2台に戻す等の予測可能なトラフィックパターンに有効。
4. ALBとの連携でヘルスチェックを正しく設定
Auto ScalingグループはALBのターゲットグループのヘルスチェック結果を使って不健全なEC2を自動的に置き換えることができます。EC2のヘルスチェックより精度が高く、「アプリは起動しているが正常に応答できないEC2」も検知して置き換えてくれます。
📌 この記事のポイント
- ターゲット追跡スケーリングポリシーが最もシンプルで効果的。CPU使用率50〜70%を目標値に設定する
- マルチAZ配置・最小2台・ウォームアップ期間の設定が本番Auto Scalingの3つの基本
- スケジュールスケーリングで予測可能な繁忙時間帯に事前に台数を増やしコスト効率を最大化する
キャリアの疑問、一緒に解決しませんか？
Route Bloomでは、インフラ系ITエンジニアを目指す方への個別サポートを行っています。2026年7月からフリーランス講師として本格始動予定です。
ABOUT ME
