Tech Starlog

AWS SAA 試験勉強(12日目)

投稿日:2026/03/12

  • AWS SAAにおいて、Auto Scaling は「可用性」「コスト効率」「パフォーマンス」の3つを同時に最適化するための必須サービスです。
  • 「いつ、どのように、どれくらい」インスタンスを増減させるのか。その判断基準を整理します。

1. Auto Scaling の3つの構成要素

Auto Scaling を設定する際は、次の3ステップで定義します。

  1. 起動テンプレート (Launch Template): 「何を」起動するか。
    • AMI、インスタンスタイプ、キーペア、セキュリティグループ、IAM ロール、ユーザーデータ。
    • ※以前の「起動設定 (Launch Configuration)」は古い形式なので、最新の「起動テンプレート」を使いましょう。
  2. Auto Scaling グループ (ASG): 「どこで」「何台」動かすか。
    • VPC、サブネット(マルチAZを推奨)。
    • 最小容量、最大容量、希望する容量。
  3. スケーリングポリシー: 「いつ」増減させるか。
    • CPU使用率やリクエスト数などの条件。

2. スケーリングポリシーの種類と選択基準

試験では、シナリオに合わせて最適なポリシーを選ばせる問題が出ます。

ポリシー名 特徴 最適なケース
ターゲット追跡 「CPU使用率を常に50%に保つ」ように自動調整。 最も一般的。 負荷に合わせて柔軟に追跡したい時。
スケジュール 特定の日時に実行(例:平日朝9時に10台に増やす)。 予測可能な負荷(セール開始、始業時間など)。
ステップ メトリクスの閾値に応じて段階的に増やす。 負荷の急増に対して一気に台数を増やしたい時。
予測スケーリング 機械学習で過去の傾向から未来の負荷を予測。 定期的な周期性がある大規模なワークロード。

3. ヘルスチェックとインスタンスの置き換え

Auto Scaling は「常に正常な台数を維持する」役割も持っています。

  • EC2 ヘルスチェック: インスタンスが「起動しているか」を確認(OSフリーズなどは検知不可)。
  • ELB ヘルスチェック(推奨): ロードバランサー経由で「アプリケーションが応答しているか」を確認。
    • 試験のポイント: アプリの応答がなくなった時にインスタンスを自動で入れ替えたいなら、ASGの設定で「ELB ヘルスチェック」を有効にする必要があります。

4. ライフサイクルフック (Lifecycle Hooks)

インスタンスの「起動時」または「終了時」に、一時停止させて特定の処理を行う機能です。

  • 用途例:
    • 終了前: インスタンスが削除される前に、ローカルにあるログファイルを S3 に転送する。
    • 起動後: ソフトウェアのインストールが完全に終わってからサービスインさせる。

5. コスト最適化:スポットインスタンスの活用

Auto Scaling グループでは、オンデマンドインスタンスとスポットインスタンスを混ぜて構成することができます。

  • 試験のポイント: 「可用性を保ちつつコストを最小化したい」という問題では、ベースの台数をオンデマンドで確保し、急増する負荷分をスポットインスタンスで補う構成が正解になることがあります。

試験での「判断基準」チェックリスト

  1. 「毎週月曜日の朝にアクセスが急増することが分かっている」
    • 回答:スケジュールスケーリング
  2. 「CPU負荷が上がった時に、自動でインスタンスを増やしてほしい」
    • 回答:ターゲット追跡スケーリング
  3. 「インスタンスは動いているが、アプリがエラーを返している。これを自動復旧したい」
    • 回答:ELB ヘルスチェック を ASG に設定する
  4. 「インスタンスが削除される前に、重要なログを保存したい」
    • 回答:ライフサイクルフック を利用する

まとめ(12日目の振り返り)

  • Auto Scaling は単に「便利」なだけでなく、必要な時に、必要な分だけ というクラウドの本質を体現したサービスです。
  • ELB と組み合わせることで、どんな負荷変動にも耐えられる「弾力性(Elasticity)」のあるアーキテクチャが完成します。