Amazon EC2 Auto Scaling

Amazon EC2 Auto Scaling は、アプリケーションの需要変動に合わせて EC2 インスタンスの台数を自動的に増減させるサービスです。手動でのキャパシティ管理から解放され、可用性の維持とコスト最適化を同時に実現できます。

解決する課題

固定台数の EC2 で運用すると、ピーク時に合わせると平常時に過剰なリソースを抱えてコストが無駄になり、平常時に合わせるとピーク時に性能不足や障害を招きます。需要を正確に予測することは難しく、アクセス急増やスパイク的な負荷に手動で対応していては遅れが生じます。

EC2 Auto Scaling は、この需要と供給のミスマッチを自動化された仕組みで解消します。負荷が増えればインスタンスを追加し、負荷が落ち着けば不要なインスタンスを削除します。また、インスタンスが異常になった場合は自動で置き換えるため、最小限の正常な台数を常に維持できます。これにより、人手による監視と判断を介さずに可用性とコストのバランスを保てます。

主要概念と用語

• Auto Scaling グループ（ASG）: スケーリング対象となる EC2 インスタンスの論理的なまとまり。最小・最大・希望容量を定義し、グループ全体としてキャパシティを管理する。
• 起動テンプレート: 起動するインスタンスの構成（AMI、インスタンスタイプ、キーペア、セキュリティグループ、ユーザーデータなど）を定義するテンプレート。バージョン管理に対応し、推奨される構成方法。
• 起動設定: 起動テンプレートの前身にあたる旧方式。2023 年以降は新しいインスタンスタイプが追加されず、2024 年 10 月 1 日以降に作成されたアカウントでは新規作成できない。既存 ASG も起動テンプレートへ移行する。
• 希望容量（Desired Capacity）: グループが維持しようとするインスタンス数。スケーリングポリシーによって最小と最大の範囲内で増減する。
• 最小容量・最大容量: グループが取りうるインスタンス数の下限と上限。スケーリングはこの範囲内でのみ行われる。
• スケーリングポリシー: いつ、どれだけインスタンスを増減させるかを定義するルール。動的スケーリングには目標追跡・ステップ・シンプルがあり、別に予測スケーリングとスケジュールされたアクションがある。新規設計では通常、目標追跡から検討する。
• ヘルスチェック: インスタンスの正常性を判定する仕組み。EC2 ステータスチェックに加え、ロードバランサのヘルスチェック結果も利用できる。
• ライフサイクルフック: インスタンスの起動時や終了時に処理を差し込み、一時停止して初期化や後処理を実行できる仕組み。
• ウォームアップ（インスタンスウォームアップ）: 新しいインスタンスがメトリクスに寄与し始めるまでの待機時間。起動直後の不安定なメトリクスによる過剰なスケーリングを防ぐ。
• クールダウン: 主にシンプルスケーリングで、増減後の追加アクションを抑制する待機時間。目標追跡やステップでは、グループ既定のインスタンスウォームアップを適切に設定する。

仕様・制限・クォータ

EC2 Auto Scaling はリージョン単位のサービスで、1 つの ASG は同一リージョン内の複数のアベイラビリティーゾーン（AZ）にまたがって展開できます。複数 AZ にインスタンスを分散させることで、特定 AZ の障害に対する耐性が高まります。

既定クォータは 1 リージョンあたり 500 ASG です。1 ASG あたりのスケーリングポリシーは 50、スケジュールされたアクションは 125、ライフサイクルフックは 50 で、後者には引き上げできない項目があります。実効上限はアカウントの Service Quotas と公式クォータ表で確認します。

スケーリングは最小容量と最大容量の範囲内でのみ行われ、希望容量がこの範囲を外れることはありません。インスタンスタイプの混在（複数インスタンスタイプ・複数購入オプションの併用）にも対応しており、オンデマンドとスポットを組み合わせた構成を取れます。なお、EC2 Auto Scaling 自体に追加料金はかからず、課金対象は起動された EC2 インスタンスや関連リソースです。

内部の仕組み

横にスクロール

ASG は希望容量と現在の実行台数を常に比較し、差分を埋めるようにインスタンスの起動・終了を行います。スケーリングポリシーや CloudWatch アラーム、スケジュールに基づくトリガーが発火すると希望容量が変更され、その変更に追随してインスタンス数が調整されます。

目標追跡ポリシーでは、CPU 使用率やリクエスト数などのメトリクスに対して目標値を設定すると、その値を維持するように必要な希望容量が自動計算されます。内部的には CloudWatch アラームが生成され、メトリクスの推移に応じて段階的に台数を調整します。ステップスケーリングでは、メトリクスの逸脱度合いに応じて複数の段階を定義し、逸脱が大きいほど一度に多くのインスタンスを増減できます。

インスタンスを終了する際には、終了ポリシーに従って削除対象が選ばれます。既定ではAZ間のバランスを保ちつつ、古い起動テンプレートや起動設定を使うインスタンスなどを優先して終了します。ライフサイクルフックを設定すると、インスタンスが稼働状態になる前や終了する前に一時停止し、アプリケーションの初期化やログ退避といった処理を挟めます。ヘルスチェックで異常と判定されたインスタンスは自動的に終了され、希望容量を満たすために新しいインスタンスが起動されます。

設計パターン / ベストプラクティス

複数 AZ にまたがる ASG を構成し、Elastic Load Balancing と組み合わせるのが基本パターンです。ロードバランサのヘルスチェックを ASG のヘルスチェックに利用することで、アプリケーション層の異常まで検知して置き換えられます。

スケーリングポリシーは、まず目標追跡から検討するのが扱いやすく、CPU 使用率やリクエスト数といった代表的なメトリクスを目標値として運用します。予測可能な定期的負荷にはスケジュールスケーリングを併用し、想定されるピーク前にあらかじめ容量を確保しておくと反応遅れを避けられます。インスタンスの起動に時間がかかる場合は、ウォームアップを適切に設定し、初期化中のインスタンスが過剰なスケールアウトを引き起こさないようにします。

スポットインスタンスを混在させてコストを下げる場合は、複数のインスタンスタイプを許可してキャパシティの確保性を高め、スポット中断に備えてオンデマンドを一定割合で確保する構成が有効です。

運用・監視

CloudWatch メトリクスでグループの稼働台数や希望容量、スケーリングアクティビティを監視します。スケーリングが頻繁に発生して台数が振動する場合は、既定のインスタンスウォームアップ、目標値、指標の集計期間を見直します。シンプルスケーリングを使う既存構成ではクールダウンも確認します。

スケーリング履歴（アクティビティ履歴）を確認すると、いつ・なぜインスタンスが起動・終了したかを追跡できます。インスタンスの更新が必要な場合は、インスタンスリフレッシュ機能で起動テンプレートの新しいバージョンへ段階的に置き換えられ、ローリング更新を安全に実行できます。

コスト

EC2 Auto Scaling の利用そのものに追加料金は発生せず、課金されるのは実際に起動された EC2 インスタンスとそれに付随するリソース（EBS ボリューム、データ転送、ロードバランサなど）です。したがって、不要なインスタンスを需要に応じて自動で終了させることが、そのままコスト削減につながります。

コスト最適化の観点では、平常時の台数を抑えつつピーク時にスケールアウトする運用が基本です。スポットインスタンスやさまざまな購入オプションを混在させることで、さらにコストを下げられます。なお、具体的な料金は購入オプションやリージョンによって変動するため、断定的な金額は示せません。最新の料金は公式の料金ページで確認してください。

セキュリティ

ASG が起動するインスタンスには、起動テンプレートで指定した IAM インスタンスプロファイル、セキュリティグループ、サブネットが適用されます。最小権限の原則に従い、インスタンスに付与するロールの権限は必要最小限に絞ります。

EC2 Auto Scaling の操作自体は IAM ポリシーで制御し、ASG の作成・変更・削除といった操作を権限のある主体のみに限定します。起動テンプレートのユーザーデータに機密情報を直接書き込むことは避け、Secrets Manager や Systems Manager パラメータストアといった仕組みから安全に取得する構成が望ましいです。

Well-Architected の観点

信頼性の観点では、複数 AZ への分散とヘルスチェックによる自動置き換えにより、単一障害点を避けつつ目標とする台数を維持できます。パフォーマンス効率の観点では、需要に追随したスケーリングによって必要なときに必要なだけの処理能力を確保できます。コスト最適化の観点では、過剰なプロビジョニングを避け、需要が低いときに台数を減らすことで無駄な支出を抑えられます。これらを組み合わせることで、可用性とコストのトレードオフを設計上の意図に沿ってバランスさせられます。

試験で問われるポイント

関連サービス・比較

EC2 Auto Scaling は ASG 内の EC2 を扱います。ECS、DynamoDB、Aurora など EC2 以外の個別リソースは Application Auto Scaling が扱い、AWS Auto Scaling Scaling Plans は対応する複数リソースへ設定をまとめて展開します。予測機能だけが目的なら、AWS は各サービスへ直接ポリシーを設定する方式を推奨しています。

ハンズオン / CLI例

起動テンプレートを指定して、複数 AZ にまたがる Auto Scaling グループを作成する例です。

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template "LaunchTemplateName=web-launch-template,Version=1" \
  --min-size 2 \
  --max-size 6 \
  --desired-capacity 2 \
  --vpc-zone-identifier "subnet-aaaaaaaa,subnet-bbbbbbbb" \
  --health-check-type EC2

# CPU 使用率を目標値に保つ目標追跡ポリシーを設定する
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 50.0
  }'