この記事でわかること（AWS Certified Cloud Practitioner向け）
- 「スケーリング」と「EC2 Auto Scaling」の基本概念
- Auto Scaling Group（ASG）の最小容量 / 希望する容量 / 最大容量の意味
- 起動テンプレート（Launch Template）の役割
- 試験で選択肢を切るための典型パターン（例付き）
EC2 Auto Scalingとは
Amazon EC2 Auto Scalingは、ワークロード（需要）の増減に合わせてEC2インスタンス数を自動で増減し、 目標の性能・可用性（落ちにくさ）とコストのバランスを取りやすくする仕組みです。 Cloud Practitioner（CLF）では、「需要に応じて自動で増減できる＝弾力性（Elasticity）」の代表例として押さえておくと有利です。
公式一次情報
- https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
- https://aws.amazon.com/ec2/autoscaling/
スケーリングの基本：2つのやり方（試験頻出）
1) スケールアウト / スケールイン（台数を増減）
- スケールアウト（Scale out）：EC2台数を増やす（例：2台→6台）
- スケールイン（Scale in）：EC2台数を減らす（例：6台→2台）
EC2 Auto Scalingが主に扱うのはこの「台数の増減」です。CLFでは「需要増＝スケールアウト」「需要減＝スケールイン」を確実に結びつけて覚えます。
2) スケールアップ / スケールダウン（1台あたりを強化/弱体化）
- スケールアップ（Scale up）：より大きいインスタンスタイプへ（例：t系→m系など）
- スケールダウン（Scale down）：より小さいタイプへ
こちらは「インスタンスタイプ変更」を伴い、運用上は停止/再起動や入れ替えの設計が必要になることがあります。 試験対策としては、まずAuto Scaling＝スケールアウト/イン（台数）を優先して理解するのが近道です。
Auto Scalingの中心：Auto Scaling Group（ASG）
EC2 Auto Scalingでは、EC2を「何台で動かすか」を管理する単位がAuto Scaling Group（ASG）です。 ASGを理解する上で最重要なのが、次の3つの容量設定です。
ASGの3つの容量：最小 / 希望する / 最大
| 項目 | 意味 | イメージ例 |
|---|---|---|
| 最小容量（Min） | どれだけ暇でも、これ未満には減らさない | Min=1（最低1台は常に稼働） |
| 希望する容量（Desired） | 基本的に「今この台数でいてほしい」目標値 | Desired=2（通常時は2台運用） |
| 最大容量（Max） | どれだけ忙しくても、これより増やさない上限 | Max=10（増えすぎによるコスト爆発を防ぐ） |
CLFの選択肢で問われやすいポイントは、「Min/Maxで下限・上限を縛れる」ことです。 つまり、Auto Scalingは「勝手に増える/減る」だけでなく、安全策（ガードレール）を持っていると覚えると理解が安定します。
公式一次情報
なぜ「起動テンプレート」が必要？（同じEC2を自動で増やすため）
Auto ScalingがEC2を増やすには、「どんな設定のEC2を作るのか」を事前に決めておく必要があります。 そこで使うのが起動テンプレート（Launch Template）です。
起動テンプレートに含まれる代表例（覚えるべき）
- AMI：OSや事前設定を含むイメージ
- インスタンスタイプ：CPU/メモリのサイズ
- セキュリティグループ、IAMロール、ユーザーデータ（起動時スクリプト）など
試験視点では、「ASGが増やすEC2は起動テンプレートで定義された同等構成」という理解が重要です。
公式一次情報
スケーリングポリシー：いつ増やし、いつ減らすのか
ASGは、条件（指標）やスケジュールに応じて増減します。この「増減のルール」がスケーリングポリシーです。 CLFでは細かな設定値より、代表的な考え方を押さえるのが効果的です。
代表的な3パターン（試験対策としての整理）
- 動的スケーリング（Dynamic）：CPU使用率などのメトリクスに応じて増減
- スケジュールスケーリング（Scheduled）：決まった時刻に台数を増減（例：昼休みに増やす）
- 予測スケーリング（Predictive）：過去傾向から需要を予測して先回り（サービスにより利用可否・適用条件あり）
試験での切り分け例：
「毎日12時にアクセスが増える」→ Scheduled が候補
「突然アクセスが増える可能性がある」→ Dynamic が候補
※予測スケーリングは概念として把握しておくと良い一方、CLFではまず「動的」と「スケジュール」を確実に選べることが得点効率に直結します。
例で理解する：Min/Desired/Maxとポリシーの動き
例：通常は2台、昼にアクセス増、夜は減るWebサイト
- ASG：Min=1 / Desired=2 / Max=10
- 通常：2台で運用（Desired）
- 昼：CPU上昇やリクエスト増をトリガーにスケールアウト（例：2→6台）
- 夜：負荷低下でスケールイン（例：6→2台、さらに1台まで）
このときMin=1があるので「完全に0台になって応答できない」事故を避けやすく、 Max=10があるので「増えすぎてコストが跳ねる」事故も抑えやすくなります。
CLF（Cloud Practitioner）での“覚えどころ”チェック
- Auto Scaling＝需要に応じた自動増減（弾力性）。主に台数（アウト/イン）。
- ASGのMin/Desired/Maxは頻出。意味をセットで覚える。
- 起動テンプレートで「増やすEC2の型」を定義する。
- 「定時に増える」ならScheduled、「指標に応じて増減」ならDynamic。
参考（AWS認定ページ：試験対策の公式導線）
不確かな点の扱い（本記事の方針）
- (1) 確実に言えること：本記事は、EC2 Auto Scalingの基本概念（ASG、Min/Desired/Max、起動テンプレート、代表的な増減の考え方）に絞って解説しています。これらは公式ドキュメントで定義されている内容です。
- (2) 推測：個別のユースケースで「何分で増えるか」「どの指標が最適か」は構成（アプリ起動時間、監視設計、負荷特性）に依存します。本記事ではCLF対策として一般化した典型を示しました。
- (3) 不明点：読者の環境（ALB有無、メトリクス設計、ステートフル/ステートレス構成）によって最適な設定は変わるため、具体設計は上記公式ドキュメントを前提に追加確認が必要です。