AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

1. サービス概要

Amazon EC2 Auto Scaling は、需要に応じて EC2 インスタンスを自動的に起動・停止するフルマネージドサービスです。 Auto Scaling グループ（ASG）という論理的なグループ単位でインスタンスを管理し、 設定した最小台数・最大台数・希望台数（Desired）の範囲内でインスタンス数を自動調整します。

ELB と組み合わせることで高可用性とスケーラビリティを同時に実現できます。 Auto Scaling はサービス自体は無料で、起動した EC2 インスタンスの料金のみが発生します。

2. 主な特徴と機能

2.1 Auto Scaling グループ（ASG）の基本設定

• Min / Max / Desired: グループの最小台数・最大台数・希望台数を設定。Desired が自動調整の目標値。
• 起動テンプレート（推奨）: AMI・インスタンスタイプ・セキュリティグループ・ユーザーデータなど EC2 起動設定をバージョン管理できるテンプレート。混合インスタンスポリシー（Spot 併用）にも対応。
• 起動構成（レガシー）: 旧来の起動設定オブジェクト。バージョン管理不可。新規利用は非推奨、起動テンプレートへの移行を推奨。
• マルチ AZ 分散: 複数 AZ のサブネットを指定することで AZ 障害時の高可用性を確保。

2.2 スケーリングポリシー

• ターゲット追跡スケーリング（推奨）: 指定したメトリクス（CPU 使用率・ALB RequestCountPerTarget・SQS キュー深度等）をターゲット値に保つようインスタンス数を自動調整。設定が最もシンプル。
• ステップスケーリング: CloudWatch アラームがトリガーし、アラームの違反幅（ステップ）に応じた台数を増減。細かい段階制御が可能。
• シンプルスケーリング（旧来）: CloudWatch アラーム 1 つにつき固定台数を増減。クールダウン中は追加アクション不可。ステップスケーリングへの移行を推奨。
• スケジュールスケーリング: 特定の日時・繰り返しスケジュールで Min/Max/Desired を変更（例: 平日 9:00 に台数増加）。
• 予測スケーリング（Predictive Scaling）: 過去のメトリクス履歴を ML で分析し、将来のトラフィックを予測して事前にスケールアウト。ウォームアップ時間がかかるワークロードに有効。

2.3 クールダウンとウォームアップ

• クールダウン期間（デフォルト 300 秒）: スケーリングアクション後、次のアクションが発動するまでの待機時間。過剰スケーリングを防止。
• インスタンスウォームアップ: 新規インスタンスが起動してから CloudWatch メトリクスに反映されるまでの期間。ターゲット追跡・ステップスケーリングでは事前設定でウォームアップ中のインスタンスをメトリクスから除外できる。

2.4 ヘルスチェックと自動置き換え

• EC2 ヘルスチェック（デフォルト）: インスタンスのステータスチェック（ハイパーバイザー・OS レベル）に基づく。
• ELB ヘルスチェック（推奨）: ALB/NLB のヘルスチェック結果も利用してアプリレベルの異常を検知。ELB ヘルスチェックを有効にするとより正確。
• 異常と判定されたインスタンスは自動的に終了され、新しいインスタンスに置き換えられます。

2.5 ライフサイクルフック

インスタンスの起動時（Pending:Wait）や終了時（Terminating:Wait）に一時停止し、カスタム処理を実行できます。 Lambda・SNS・SQS と連携して、ソフトウェアのインストール、ログ収集、接続のドレイニングなどを実現します。 タイムアウト（デフォルト 3,600 秒）後または明示的な CONTINUE/ABANDON で次のフェーズに移行します。

2.6 インスタンスリフレッシュ

起動テンプレートの更新後、ローリング方式で既存インスタンスを新しい設定のインスタンスに置き換えます。 健全性のパーセンテージ（Min Healthy %）を指定してゼロダウンタイムの更新が可能です。

2.7 Spot インスタンス統合

混合インスタンスポリシーで On-Demand と Spot を混在させ、コストを大幅削減できます。 Spot 中断時に自動的に On-Demand または別の Spot に置き換えます。

3. アーキテクチャおよび技術要素

1. 起動テンプレートと ASG（Min/Max/Desired・対象 AZ・サブネット）を作成し、ALB のターゲットグループを関連付け。
2. CloudWatch がインスタンスのメトリクス（CPU・リクエスト数・カスタムメトリクス）を収集。
3. スケーリングポリシーの条件を満たすと Auto Scaling がインスタンスを起動または終了。
4. ライフサイクルフックが設定されていれば Pending:Wait → カスタム処理 → CONTINUE → InService の順に遷移。
5. ELB が新規インスタンスをターゲットグループに自動登録し、ヘルスチェック通過後にトラフィックを流す。
6. スケールイン時はターミネーションポリシーに従い古い/課金境界に近いインスタンスを選択して終了。

スケールアウトはクールダウン終了後すぐに再判定されますが、スケールインには追加のウェイトが設けられることが多く（スケールイン保護・クールダウン）、過剰なインスタンス削減を防ぎます。

4. セキュリティと認証・認可

• IAM ロール（インスタンスプロファイル）: 起動テンプレートに IAM ロールを指定し、EC2 インスタンスが AWS API を安全に呼び出せるようにする（アクセスキー不要）。
• セキュリティグループ: 起動テンプレートにセキュリティグループを指定。ALB のセキュリティグループからのみ受け付ける構成が推奨。
• EBS 暗号化: 起動テンプレートで暗号化を有効化すると、ASG が起動するすべてのインスタンスの EBS ボリュームが KMS で暗号化。
• スケールイン保護: 特定インスタンスをスケールインから保護する設定。ステートフルな処理中のインスタンスを誤って終了させない。
• CloudTrail: CreateAutoScalingGroup / PutScalingPolicy 等の API 呼び出しを記録・監査。

5. 料金形態

• EC2 Auto Scaling 自体: 無料。
• EC2 インスタンス料金: 起動している時間（On-Demand / Spot / Reserved）に応じて課金。スケールインで台数が減るとコスト削減。
• CloudWatch 料金: カスタムメトリクスの送信・詳細モニタリング（1 分間隔）は有料（標準モニタリングの 5 分間隔は無料）。
• Elastic Load Balancing 料金: ELB 稼働時間・LCU に応じた課金（Auto Scaling とは別）。

6. よくあるアーキテクチャ・設計パターン

• ALB + ASG（標準 Web 構成）: ALB がトラフィックを分散 → ASG が CPU/リクエスト数でスケールアウト/イン。ELB ヘルスチェックで不健全なインスタンスを自動置換。
• SQS キュードリブンスケーリング: SQS キューの ApproximateNumberOfMessagesVisible をカスタムメトリクスとしてターゲット追跡に使用し、バッチワーカーをキュー深度に比例してスケール。
• スポット混合インスタンス（コスト最適化）: 混合インスタンスポリシーで On-Demand の基盤台数を確保しつつ残りを Spot に充当。Spot 中断時に自動置換。
• ローリングデプロイ（インスタンスリフレッシュ）: 起動テンプレートを新バージョンに更新後、Instance Refresh でゼロダウンタイムの入れ替えを実施。
• 定期スケールアウト（夜間バッチ）: スケジュールスケーリングで深夜にインスタンスを追加起動し、バッチ完了後にスケールインしてコスト節減。

7. 設定・デプロイ手順（ハンズオン例）

1. EC2 コンソールで起動テンプレートを作成（AMI・インスタンスタイプ・SG・IAM ロール・ユーザーデータを設定）。
2. Auto Scaling コンソールで ASG を作成（起動テンプレート指定・対象 VPC/サブネット（複数 AZ）・Min/Max/Desired 設定）。
3. ALB のターゲットグループを ASG に関連付け、ELB ヘルスチェックを有効化。
4. スケーリングポリシーを追加（ターゲット追跡: CPU 使用率 50% を目標）。
5. ライフサイクルフックが必要なら追加（起動時: アプリ設定スクリプト実行など）。
6. CloudWatch ダッシュボードで GroupInServiceInstances・CPU 使用率・リクエスト数を監視。

8. 試験で問われやすいポイント