Amazon EC2 Auto Scaling入門｜オンプレの手動増設から脱却するスケーリンググループ設計と料金ガイド

オンプレミス環境でサーバーを増設するときのことを思い出してください。機器調達に数週間、ラッキングとケーブリング、OS・ミドルウェアのセットアップ、監視設定——繁忙期に「今すぐサーバーが2台必要だ」と言われても、間に合わないことが大半です。Amazon EC2 Auto Scalingは、そんなインフラ担当者の「夜中に急に電話がくる恐怖」から解放してくれる仕組みです。

この記事では、Amazon EC2 Auto Scalingをオンプレのインフラエンジニアにわかりやすく解説します。スケーリンググループの設計判断から具体的なコンソール操作、コスト感覚、ハマりポイントまで体系的にカバーします。

なぜEC2 Auto Scalingが必要なのか——オンプレとの根本的な違い

オンプレでは、ピーク負荷に対応するために「最大負荷時の処理能力」を基準にサーバーを購入します。その結果、平常時は7割以上のリソースが余り続けます。年に数回の繁忙期のために、常時高スペックのサーバーを維持するのは当然ですが、コストの観点では非常に非効率です。

クラウドとオンプレの最大の違いは「需要に応じてリソースを動的に変更できる」点です。EC2 Auto Scalingを使えば、CPUやネットワーク負荷に応じてEC2インスタンスを自動で増減させ、ピーク時は多くのサーバーを立ち上げ、閑散期は最小限に抑えることができます。

EC2 Auto Scalingの基本概念

3つの主要コンポーネント

EC2 Auto Scalingは以下の3つのコンポーネントで構成されます。

・起動テンプレート（Launch Template）: 起動するEC2インスタンスの仕様を定義する設計書です。AMI、インスタンスタイプ、セキュリティグループ、キーペア、ユーザーデータ（起動スクリプト）などを記載します。以前は「起動設定（Launch Configuration）」が使われていましたが、現在は起動テンプレートが推奨です。
・Auto Scalingグループ（ASG）: EC2インスタンスをグループとして管理する単位です。「最小台数・最大台数・希望台数」の3つの値を設定します。
・スケーリングポリシー: いつ・どのようにインスタンスを増減するかのルールです。CPU使用率・ネットワーク帯域・カスタムメトリクスなどをトリガーにできます。

スケーリングの3種類

・動的スケーリング（Dynamic Scaling）: CloudWatchのメトリクスをトリガーに自動でスケールする方式。最もよく使われます。
・スケジュールスケーリング（Scheduled Scaling）: 特定の日時・曜日・時刻にあらかじめスケールする方式。「毎週月曜9時に最小5台」のような予測可能な需要に対して使います。
・予測スケーリング（Predictive Scaling）: 過去の負荷パターンをMLで分析し、事前にスケールする方式。突発的なトラフィックスパイクに対しても予測的に対応できます。

基本的な使い方

1. 起動テンプレートの作成

マネジメントコンソールの「EC2」→「起動テンプレート」→「起動テンプレートを作成」から設定します。最低限必要な設定項目は以下のとおりです。

・AMI（Amazon Machine Image）: Auto Scalingで起動するEC2の元となるイメージ。Webサーバーであれば、アプリのデプロイ済みカスタムAMIを使うのが一般的です。
・インスタンスタイプ: スケールアウト時に起動するインスタンスのタイプ（例: t3.medium、m6g.large）
・セキュリティグループ: 起動するインスタンスに適用するSG
・IAMインスタンスプロファイル: インスタンスにアタッチするIAMロール
・ユーザーデータ: インスタンス起動時に実行するシェルスクリプト（アプリ起動・設定取得など）

2. Auto Scalingグループの作成

「EC2」→「Auto Scalingグループ」→「Auto Scalingグループを作成」から設定します。重要な設定項目を説明します。

台数設定（容量）:

# Auto Scalingグループの容量設定（AWS CLI）
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-web-asg \
  --launch-template LaunchTemplateName=my-web-lt,Version='$Latest' \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 3 \
  --vpc-zone-identifier "subnet-xxxxxxxx,subnet-yyyyyyyy" \
  --health-check-type ELB \
  --health-check-grace-period 300 \
  --region ap-northeast-1

・最小台数（min-size）: スケールインしても絶対に下回らない台数。「0」にすると全インスタンスが停止する場合があるため、本番では最低2以上を推奨（マルチAZ対応）
・最大台数（max-size）: スケールアウトしても絶対に超えない台数。コスト上限の防衛ラインとして機能
・希望台数（desired-capacity）: Auto Scalingが維持しようとする現在の目標台数。スケーリングポリシーによって自動で変化する

可用性ゾーン（AZ）の設定: 複数のAZにわたってインスタンスを分散させることで、1つのAZが障害を起こしても残りのAZで処理を継続できます。東京リージョン（ap-northeast-1）であれば、ap-northeast-1a、ap-northeast-1c、ap-northeast-1dの少なくとも2つを指定します。

3. スケーリングポリシーの設定

最も一般的な「ターゲット追跡スケーリング」の設定例です。CPU使用率50%を目標に維持するポリシーです。

# ターゲット追跡スケーリングポリシーの作成（AWS CLI）
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-web-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 50.0,
    "ScaleInCooldown": 300,
    "ScaleOutCooldown": 60
  }' \
  --region ap-northeast-1

ロードバランサーとの連携設計

EC2 Auto ScalingはALB（Application Load Balancer）またはNLB（Network Load Balancer）と組み合わせて使うのが基本です。

スケールアウト時に新しく起動したインスタンスは、ALBのターゲットグループに自動登録されます。ヘルスチェックが通過すると、実際のトラフィックが流れ始めます。スケールイン時は、接続が完了してからインスタンスを削除する「接続ドレイン（登録解除の遅延）」機能を使うことで、処理中のリクエストを中断せずにインスタンスを安全に削除できます。

料金の仕組み（コスト感覚）

Auto Scaling自体の機能には追加料金はかかりません。起動されたEC2インスタンスの使用時間に対するEC2通常料金のみが発生します。

コスト最適化のポイント:

・スポットインスタンスの組み合わせ: Auto Scalingグループは「混合インスタンスポリシー」を使い、オンデマンドとスポットを混在させられます。例えば「常に2台はオンデマンド、追加分はスポット」という設定にすると、急なスケールアウト時もスポット価格（最大90%割引）でコストを抑えられます。
・インスタンスタイプの柔軟化: t3.large単独ではなく「t3.large、m5.large、m6i.large」のように複数タイプを許容すると、スポットインスタンスの中断リスクが下がります。
・最小台数のゼロ設定（開発環境）: 開発・ステージング環境であれば最小台数を0にして、業務時間外に全インスタンスを停止するスケジュールスケーリングを組み合わせると大幅なコスト削減が可能です。

Auto Scalingグループの運用で見落としがちなコストが、スケールアウト時のデータ転送料金です。新しいインスタンスがS3・ElastiCache・RDSなどにアクセスする際のデータ転送は、同一AZ内では無料ですが、AZ間通信は0.01USD/GBで双方向課金されます。スケールアウト先のインスタンスが存在するAZと、依存するデータストアのAZを揃える設計が重要です。

応用・実務Tips

ライフサイクルフックの活用: デフォルトでは、Auto Scalingはインスタンス起動後すぐに「InService」状態に遷移させます。しかしアプリの起動には数十秒～数分かかることがあります。「ライフサイクルフック」を設定すると、インスタンスが完全に準備できるまで「Pending:Wait」状態を維持させ、準備完了後に「InService」に切り替える制御が可能です。アプリの初期化完了をUserDataスクリプトからAuto Scalingに通知するパターンが現場ではよく使われます。

インスタンスの保護（Scale-in Protection）: 特定のインスタンスを「スケールインから保護」する設定があります。バッチ処理を実行中のインスタンスを誤って削除しないようにするために使われます。処理完了後に保護を解除すると、次のスケールイン判断時に通常通り削除されます。

ウォームプール（Warm Pool）: スケールアウト時のインスタンス起動に数分かかる問題への解決策です。ウォームプールにあらかじめ起動済みの「待機インスタンス」を用意しておき、需要増加時にすぐ「InService」に昇格させます。AMIのアプリケーションインストールに時間がかかる場合に特に有効です。

Linuxサーバーの基礎構築については、姉妹サイトLinuxMaster.JPで詳しく解説しています。Auto Scalingで起動するEC2インスタンスのUserDataスクリプト作成には、Linuxの基本コマンドやサービス管理の知識が役立ちます。

よくあるトラブルと対処法

スケールアウトしたのにトラフィックが流れない: 最も多いのは「ヘルスチェック猶予期間が短すぎてインスタンスが起動直後に削除されるループ」です。アプリの起動時間を計測し、猶予期間をその1.5倍程度に設定してください。また、セキュリティグループがALBからのヘルスチェックポートを許可しているかも確認が必要です。

意図しないスケールインで処理が止まった: スケールインのクールダウン期間が短すぎる、またはライフサイクルフックを設定していないケースで発生します。バッチ処理系のインスタンスには必ずScale-in Protectionかライフサイクルフックを設定してください。

スケールアウトが止まらない（コスト爆発）: CloudWatchアラームの設定ミスやアプリのバグ（CPU100%を永続的に引き起こす）が原因で起こります。最大台数（max-size）の設定と、AWS Budgetsのコスト上限アラートを必ず設定してください。CloudWatchのAlarmHistoryで何がトリガーになったかを確認できます。

マルチAZ環境でAZが偏る: Auto Scalingのデフォルトの「再分散（Rebalancing）」機能は、AZ間のインスタンス数が偏るとインスタンスを削除・再起動して均等にしようとします。この挙動が予期せずスケールインに見える場合があります。再分散の動作を理解した上で、「BalancedBestEffort」か「BalancedOnly」を選択してください。

本記事のまとめ

Amazon EC2 Auto Scalingは、クラウドで「需要に応じたインフラ」を実現するための中核サービスです。

・オンプレとの違い: 手動増設から自動スケールへ。計画的な設備投資（CAPEX）から実際の需要に連動した従量課金（OPEX）へ
・設計の核心: 起動テンプレート（何を起動するか）＋ ASG（何台維持するか）＋スケーリングポリシー（いつ増減するか）の3つを正しく設計する
・ALBとの連携: ヘルスチェック猶予期間と接続ドレインの設定がサービス無停止スケーリングの要
・コスト最適化: スポットインスタンスとの混在、最小台数ゼロ設定（開発環境）が効果的
・運用の要: ライフサイクルフック・Scale-in Protection・最大台数設定でスケール暴走とバッチ処理中断を防ぐ

Auto Scalingを正しく設計できると、夜中にオンコールで起こされる「サーバーが落ちた！増設してください」の電話がなくなります。オンプレ時代の「手動で何とかする」インフラ運用から、「設計で自動化する」クラウドネイティブな運用への転換の第一歩として、ぜひ実際に設定してみてください。