EC2 Auto Scaling は、起動テンプレートで「どんなインスタンスを起動するか」を定義し、Auto Scaling グループで「何台をどのサブネットに置き、どの指標で増減させるか」を決めて設定します。ロードバランサー（ALB）と組み合わせれば、負荷に応じた台数の増減と、故障したインスタンスの自動的な入れ替えができます。この記事では、設定の順番、各項目の意味、スケーリングポリシーの選び方、WordPressを載せるときに先に解決すべき点、動作の確認方法までを説明します。
コンソールの画面やサービスの既定値は変わることがあるため、ここでの説明は2026年10月現在の情報をもとにした目安です（2026年10月現在）。料金はEC2などの利用分がかかり、Auto Scaling の機能自体には追加の料金がかからない仕組みですが、詳しくはAWSの料金ページで確認してください。
先に決めておくこと：WordPressはそのままでは増やせない
Auto Scaling の設定より先に、アプリケーションが「どのインスタンスに振り分けられても同じ結果を返せる」状態になっている必要があります。1台で動いていたWordPressをそのまま複製すると、次の問題が起きます。
- アップロードしたファイル：画像を1台目にアップロードしても、2台目には存在しません。メディアをS3に置くプラグインを使うか、複数のインスタンスで共有できるAmazon EFSに
wp-content/uploadsを置きます。 - データベース：各インスタンスの中にMySQLを持たせると、データがばらばらになります。データベースはAmazon RDSなどに分けます。
- プラグインやテーマの更新：管理画面から更新すると、そのリクエストを受けた1台だけが更新されます。更新はAMIの作り直しやデプロイの仕組みで行い、本番の管理画面からのファイル変更は
wp-config.phpにdefine( 'DISALLOW_FILE_MODS', true );を書いて止めるのが一般的です。 - WP-Cron：アクセスのたびに各インスタンスで予約処理が走ります。
define( 'DISABLE_WP_CRON', true );で止め、1か所から定期的に実行する仕組みに置き換えます。
ログインの状態はCookieとデータベースで管理されるため、全インスタンスで wp-config.php の認証用キーとソルトが同じなら、スティッキーセッションがなくてもログインは維持されます。オブジェクトキャッシュを使う場合は、各インスタンスのメモリではなくElastiCacheのような共有のキャッシュに置きます。
ステップ1：AMIと起動テンプレートを作る
まず、WordPressの動作に必要なソフトウェア（Webサーバー、PHP、WordPress本体、プラグイン）を入れたインスタンスを1台用意し、そこからAMIを作ります。設定に問題がない状態のサーバーをイメージにするので、作る前に動作を確認しておきます。
次に、起動テンプレートを作成します。起動テンプレートには、AMI、インスタンスタイプ、セキュリティグループ、IAMインスタンスプロフィール、ユーザーデータ、メタデータの設定（IMDSv2のみにする）などを書きます。以前は「起動設定（Launch Configuration）」という仕組みもありましたが、新しい機能は起動テンプレートにしか追加されず、新規のアカウントでは起動設定を作れなくなっています。これから作るなら起動テンプレートを使います。
起動テンプレートでは、ネットワーク（サブネット）は指定せず、Auto Scaling グループ側で指定するのが一般的です。テンプレートは版を持つため、AMIを更新したら新しい版を作り、グループが使う版を切り替えます。
ステップ2：ALBとターゲットグループを用意する
Auto Scaling で起動したインスタンスにアクセスを振り分けるため、ALBとターゲットグループを作ります。ターゲットグループのヘルスチェックのパスは、軽くて、PHPやデータベースが正常なときだけ200を返すものにします。トップページをチェックに使うと、重いページの生成が繰り返されるうえ、リダイレクトを返すと異常と判定されることがあります。
セキュリティグループは、ALBに443番を公開し、インスタンス側ではALBのセキュリティグループからの80番だけを許可する形にします。インスタンスは外部から直接アクセスされない状態になります。
ステップ3：Auto Scaling グループを作る
グループの作成では、次の項目を決めます。
- 起動テンプレートと版：使う起動テンプレートと、その版（既定の版・最新の版・特定の版）を指定します。
- サブネット：2つ以上のアベイラビリティーゾーンのサブネットを選びます。1つのゾーンに障害が起きても、別のゾーンのインスタンスでサービスを続けられます。
- 台数：最小・希望・最大の3つを設定します。本番では最小を2以上にすると、1台が入れ替わっている間もサービスが止まりません。最大は費用の上限を決める意味も持ちます。
- ヘルスチェックの種類：既定はEC2のステータスチェックだけですが、ELBのヘルスチェックも有効にすると、OSは動いていてもWordPressが応答しないインスタンスを異常として入れ替えられます。
- ヘルスチェックの猶予期間：起動直後はソフトウェアの準備が終わっていないため、この期間はヘルスチェックの結果で入れ替えません。短すぎると、準備中のインスタンスを異常と判定して起動と終了を繰り返します。
CLIで作る場合の例です。名前やIDは自分の環境の値に置き換えてください。
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name wp-asg \
--launch-template 'LaunchTemplateName=wp-lt,Version=$Default' \
--min-size 2 --desired-capacity 2 --max-size 4 \
--vpc-zone-identifier "subnet-aaaaaaaa,subnet-bbbbbbbb" \
--target-group-arns arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/wp-tg/0123456789abcdef \
--health-check-type ELB \
--health-check-grace-period 300ステップ4：スケーリングポリシーを設定する
台数を増減させる条件には、いくつかの方式があります。
- ターゲット追跡：「平均CPU使用率を50%前後に保つ」のように目標値を決めると、それに近づくよう台数を自動で調整します。最初に選ぶならこの方式が扱いやすく、CloudWatchのアラームも自動で作られます。
- ステップスケーリング：アラームの値の範囲ごとに、何台増やすか・減らすかを細かく決めます。
- スケジュール：毎朝の始業時やキャンペーンの開始時など、負荷の時間帯が分かっている場合に、あらかじめ台数を変えておきます。
- 予測スケーリング：過去の負荷の傾向から、必要な台数を先回りして用意します。
ターゲット追跡でCPU使用率を指標にする例です。
aws autoscaling put-scaling-policy \
--auto-scaling-group-name wp-asg \
--policy-name cpu-target-50 \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
"TargetValue": 50.0
}'ここでつまずきやすいのは、t3などのバースト可能なインスタンスでCPU使用率を指標にすることです。CPUクレジットが尽きると処理が遅くなりますが、使用率の見え方と実際の性能が一致しないことがあります。ALBのターゲットあたりのリクエスト数を指標にする方法もあるので、サイトの負荷の特徴に合わせて選びます。
ステップ5：動作を確認する
設定が終わったら、次の点を確かめます。
- 台数：グループの「インスタンスの管理」で、希望の台数のインスタンスが
InServiceになっているか。ターゲットグループでもhealthyになっているか。 - 自動の入れ替え：検証環境で1台を手動で終了し、新しいインスタンスが起動してターゲットグループに登録されるか。
- スケールアウト：負荷テストのツールで負荷をかけ、ポリシーどおりに台数が増え、負荷を止めると減るか。グループの「アクティビティ」タブに、起動と終了の理由が記録されます。
台数が増えたり減ったりを短い間隔で繰り返す場合は、ヘルスチェックの猶予期間が短すぎる、インスタンスのウォームアップの時間が短い、目標値が厳しすぎる、といった原因が考えられます。
AMIを更新するときはインスタンスの更新を使う
WordPressやプラグインを更新したAMIに切り替えるときは、起動テンプレートの新しい版を作り、インスタンスの更新（Instance Refresh）で順番に入れ替えます。一定の割合のインスタンスを正常に保ちながら置き換えるため、サービスを止めずに更新できます。
aws autoscaling start-instance-refresh \
--auto-scaling-group-name wp-asg \
--preferences '{"MinHealthyPercentage": 90}'更新の前には、データベースのスナップショットを取っておきます。プラグインの更新がデータベースの構造を変える場合は、新旧のインスタンスが同時に動く時間があることにも注意し、まず検証環境で手順を確かめます。
まとめ
- Auto Scaling の前に、メディア・データベース・キャッシュ・WP-Cron・ファイルの更新をインスタンスの外に出し、どの台でも同じ結果を返せる構成にする。
- 起動テンプレートにAMI・セキュリティグループ・IAMロール・IMDSv2を定義し、起動設定ではなく起動テンプレートを使う。
- グループは2つ以上のゾーンに置き、最小2台、ELBのヘルスチェックと十分な猶予期間を設定する。
- 最初はターゲット追跡のポリシーから始め、負荷テストで増減を確認する。
- AMIの更新はインスタンスの更新で順番に入れ替え、事前にスナップショットを取る。