2026年7月5日
AWS で WordPress を止まりにくくするには、Web サーバー・データベース・アップロードファイル・キャッシュのそれぞれを、2つ以上のアベイラビリティーゾーン（AZ）にまたがる形で配置します。具体的には、ALB と Auto Scaling グループで EC2 を複数の AZ に分散し、RDS を Multi-AZ にし、wp-content/uploads を EFS か S3 に移すのが基本の形です。この記事では、各層をどう冗長化するか、どこに単一障害点が残りやすいか、構築後にフェイルオーバーをどう試すかを説明します。
ここでの説明は2026年10月現在の AWS の公開情報をもとにしていますが、各サービスの機能やコンソールの表記は更新されることがあります。構成を変える前には RDS のスナップショットと EC2 のバックアップを取り、まずステージング環境で試してください（2026年10月現在）。
Multi-AZ で防げる障害と防げない障害
AZ は、同じリージョン内で電源やネットワークが独立した1つ以上のデータセンターの集まりです。Multi-AZ 構成にすると、1つの AZ で停電やネットワーク障害が起きても、残りの AZ でサービスを続けられます。インスタンス単体のハードウェア障害にも強くなります。
一方で、次のような事態は Multi-AZ だけでは防げません。
- リージョン全体に及ぶ障害：別リージョンへのバックアップや、別リージョンでの復旧手順が必要です。
- 誤操作やデータの破損：誤って削除した記事や、プラグインの不具合で壊れたデータは、スタンバイにもそのまま複製されます。復元できるのはバックアップからです。
- アプリ自体の不具合：プラグインの更新で致命的なエラーが出れば、すべての EC2 で同じように止まります。
Multi-AZ はバックアップの代わりにはならない、という点を最初に押さえておくと、設計の抜けを防げます。
全体の構成
一般的な構成は次のとおりです。
- ネットワーク：VPC 内に、AZ ごとにパブリックサブネットとプライベートサブネットを用意します。最低2つの AZ を使います。
- 入口：ALB を複数の AZ のパブリックサブネットに配置します。ALB は作成時に2つ以上の AZ のサブネットを指定する仕組みです。
- Web サーバー：EC2 をプライベートサブネットに置き、Auto Scaling グループで複数の AZ に分散させます。
- データベース：RDS for MySQL / MariaDB を Multi-AZ にするか、Aurora MySQL を使います。
- アップロードファイル：EFS で複数の EC2 から共有するか、S3 に移して CloudFront から配信します。
- キャッシュ：オブジェクトキャッシュを使うなら、ElastiCache を複数の AZ にノードを置く構成にします。
ステップ1：Web 層を複数の AZ に分散する
ALB のターゲットグループに EC2 を登録し、ヘルスチェックのパスを設定します。WordPress のトップページをそのまま使うと、重いページや外部 API の遅延でヘルスチェックが失敗することがあります。軽い静的ファイルや、データベースへの接続だけを確かめる専用のパスを用意すると、誤判定を減らせます。
Auto Scaling グループには、各 AZ のプライベートサブネットを指定し、最小台数を AZ の数以上にします。最小1台だと、その1台がある AZ に障害が起きたときに、新しいインスタンスが起動するまでサービスが止まります。ヘルスチェックの種類を ELB にしておくと、ALB から見て応答しないインスタンスも自動で入れ替わります。
サーバーに状態を持たせない
複数台構成で最もつまずきやすいのが、サーバーごとにファイルが違う状態になることです。管理画面から画像をアップロードすると、そのリクエストを受けた1台にしかファイルが保存されず、別の台に振り分けられた訪問者には画像が表示されません。プラグインやテーマを管理画面から更新した場合も同じことが起きます。
そのため、アップロードファイルは EFS か S3 に置き、プラグインやテーマの更新は管理画面から行わず、起動テンプレートの AMI やデプロイの仕組みで全台にそろえて配布する運用にします。WordPress のログイン状態は Cookie で管理されるため、通常はスティッキーセッションは不要ですが、セッションを使うプラグインを入れている場合は動作を確認してください。
ステップ2：データベースを Multi-AZ にする
RDS には可用性を高める方式がいくつかあります。
- Multi-AZ DB インスタンス：別の AZ に同期レプリケーションのスタンバイを置きます。スタンバイは読み取りには使えず、障害時に自動で昇格します。
- Multi-AZ DB クラスター：読み取りにも使える2つのスタンバイを別々の AZ に置く方式です。対応するエンジンやバージョンが限られるため、事前に確認します。
- Aurora：ストレージ自体が複数の AZ にまたがって複製されます。別の AZ に Aurora レプリカを置いておくと、障害時にそのレプリカが昇格します。
既存の単一 AZ の RDS インスタンスは、変更の操作で Multi-AZ に切り替えられます。切り替え中はスナップショットの取得やスタンバイの作成が行われ、性能が一時的に落ちることがあるため、アクセスの少ない時間帯に行います。
リードレプリカと Multi-AZ は目的が違う点に注意してください。リードレプリカは非同期の複製で、読み取りの負荷分散が主な目的です。障害時に自動では昇格しないため、可用性を高めたい場合は Multi-AZ を使います。
WordPress 側の接続先
フェイルオーバーが起きると、RDS のエンドポイントの DNS が新しいプライマリを指すように切り替わります。wp-config.php の DB_HOST には、IP アドレスではなく RDS のエンドポイント名を書いておく必要があります。WordPress はリクエストごとにデータベースへ接続し直すため、切り替え後は新しい接続から順に復旧します。切り替えにかかる時間は、一般に1〜2分程度とされていますが、負荷や構成によって変わります。接続の切り替えを速めたい場合は RDS Proxy を検討する選択肢もありますが、対応するエンジンと費用を確認してから導入してください。
ステップ3：アップロードファイルとキャッシュ
EFS は複数の AZ からマウントできるファイルシステムで、wp-content/uploads をそのまま共有する用途に向いています。各 AZ にマウントターゲットを作り、EC2 の起動時にマウントするよう起動テンプレートのユーザーデータなどで設定します。小さなファイルを大量に読み書きする用途では遅く感じることがあるため、テーマやプラグインのコードまで EFS に置くのは避け、アップロードファイルだけにするのが無難です。
S3 に移す方式なら、メディアの保存先を S3 にするプラグインを使い、CloudFront から配信します。既存の画像の URL が変わるため、移行の手順とロールバックの方法を決めてから作業します。
オブジェクトキャッシュに ElastiCache（Redis OSS 互換や Valkey）を使う場合は、レプリカを別の AZ に置き、自動フェイルオーバーを有効にします。キャッシュが一時的に使えなくなっても WordPress がエラーにならないかも、ステージングで確かめておくと安心です。
見落としやすい単一障害点
構成図では冗長化されているように見えても、次の部分が1つしか無いことがよくあります。
- NAT ゲートウェイ：NAT ゲートウェイは AZ ごとのリソースです。1つの AZ にしか置いていないと、その AZ の障害で、プライベートサブネットの EC2 が外部の API やアップデートの取得に使う経路が止まります。
- 踏み台サーバーや cron 用のサーバー：WP-Cron を無効にして1台のサーバーから定期実行している場合、そのサーバーの停止で予約投稿などが止まります。
- Elastic IP を付けた単体のサーバー：古い構成の名残で、一部の処理だけが特定のサーバーに依存していることがあります。
また、AZ をまたぐ通信にはデータ転送の料金がかかります。冗長化の度合いを上げるほど費用も増えるため、許容できる停止時間と費用のバランスで構成を決めてください。
ステップ4：フェイルオーバーを試す
構築しただけでは、本当に切り替わるかは分かりません。ステージング環境で、次の試験を行います。
# RDS の Multi-AZ のフェイルオーバーを試す（スタンバイへ切り替えて再起動する）
aws rds reboot-db-instance \
--db-instance-identifier wordpress-staging-db \
--force-failover実行中はサイトにアクセスし続け、エラーが出る時間と、復旧後に投稿の保存やログインが正常にできるかを確認します。RDS のイベントにフェイルオーバーの開始と完了が記録されるので、所要時間もそこで確認できます。
Web 層は、1台の EC2 を停止して、ALB がそのインスタンスを切り離し、Auto Scaling が新しいインスタンスを起動するまでの流れを確認します。AWS Fault Injection Service を使うと、AZ の障害に近い状況をより体系的に試験できます。いずれも本番で試す場合は、影響を説明したうえで時間帯を決めて行ってください。
まとめ
- Multi-AZ は AZ やインスタンスの障害に備える仕組みで、誤操作やリージョン障害への備えにはバックアップが別に必要です。
- Web 層は ALB と Auto Scaling グループで複数の AZ に分散し、最小台数を AZ の数以上にします。
- サーバーに状態を持たせないよう、アップロードファイルは EFS か S3 に置き、コードはデプロイの仕組みで全台にそろえます。
- RDS は Multi-AZ か Aurora を使い、DB_HOST にはエンドポイント名を書きます。リードレプリカは可用性の代わりになりません。
- NAT ゲートウェイや cron 用サーバーなどの単一障害点を洗い出し、ステージングでフェイルオーバーを試験します。