高可用性・スケーラブルなアーキテクチャの根幹をなすのがAuto Scalingです。本記事ではEC2・ECS・EKSそれぞれのスケーリング機構の違いと、SAPレベルでの高度な設計を解説します。

SAA レベル：基礎概念

EC2 Auto Scalingの基本要素

起動テンプレート (Launch Template): インスタンスの設定（AMI、インスタンスタイプ等）を定義
Auto Scaling グループ (ASG): 最小・最大・希望キャパシティを持ち、インスタンス数を自動調整
スケーリングポリシー: いつ、どれだけスケールするかを定義するルール

SAA 試験のポイント

ASGは複数のAZにまたがってインスタンスを分散配置するのが基本です。単一AZにすべてのインスタンスを起動する設定は、AZ障害時に全滅するリスクがあるため避けるべき、という原則がSAAで問われます。

スケーリングポリシーの種類

ポリシー	説明
ターゲット追跡スケーリング	CPU使用率50%などの目標値を維持するよう自動調整
ステップスケーリング	しきい値超過の度合いに応じて段階的にスケール
シンプルスケーリング	単一のしきい値超過でスケール（クールダウンあり）

SAA 頻出

特別な理由がない限り、ターゲット追跡スケーリングが最もシンプルで推奨される方式です。目標値を設定するだけで、CloudWatchアラームの詳細な閾値設計を自分で行う必要がありません。

SAP レベル：高度な設計シナリオ

ウォームプールによる起動時間の短縮

SAP 試験のポイント

インスタンスの起動に時間がかかるワークロード（大きなアプリケーションの初期化処理等）では、需要増加時にAuto Scalingでインスタンスを起動しても、実際にトラフィックを処理できるまでにタイムラグが生じます。ウォームプールを使うと、事前に初期化済み（または起動済み・停止状態）のインスタンスをプールしておき、スケールアウト時に即座に投入できます。これによりスケールアウトの応答速度が大幅に改善されます。

混合インスタンスポリシー（Mixed Instances Policy）

1つのASGで複数のインスタンスタイプと**購入オプション（オンデマンド/Spot）**を組み合わせて起動できる
Spotインスタンスの中断リスクを、複数のインスタンスプールに分散することで軽減する

設計上の落とし穴

Spotインスタンスを使う際、単一のインスタンスタイプに依存すると、そのタイプの需給が逼迫した瞬間に大量のインスタンスが同時に中断されるリスクがあります。SAPレベルでは、**複数のインスタンスタイプ・複数のAZに分散させる「キャパシティの多様化」**が中断リスクを下げる鍵になる、という設計原則が問われます。

ECS・EKSにおけるスケーリングの違い

観点	ECS Service Auto Scaling	EKS（Cluster Autoscaler / Karpenter）
スケール対象	タスク数（コンテナ）	ノード（EC2）＋Pod
主な仕組み	Application Auto Scalingでタスク数を調整	KarpenterがPodの要求に応じて最適なノードを直接起動

SAP 試験のポイント

EKSでは、従来のCluster Autoscalerに加えてKarpenterが主流になりつつあります。Karpenterは、あらかじめ定義されたノードグループの制約を受けず、Podのリソース要求に応じて最適なインスタンスタイプをオンデマンドで選択・起動できるため、リソース効率とコスト最適化の両面で優れているという特徴が問われます。

まとめ

SAA: ASGのマルチAZ分散、ターゲット追跡スケーリングの基本を理解する。
SAP: ウォームプールによる起動遅延対策、混合インスタンスポリシーによるSpot中断リスク分散、EKSにおけるKarpenterの優位性を踏まえた設計ができる。

次は Elastic Load Balancing（ALB/NLB/GWLB）の使い分けを見ていきましょう。