Route 53 では、同じドメイン名に「通常時の向き先」と「障害時の向き先」の2つのレコードを登録し、ヘルスチェックの結果で自動的に切り替える「フェイルオーバールーティング」を設定できます。この記事では、WordPress のサーバーが応答しなくなったときに、静的なメンテナンス画面へ自動で切り替える構成を例に、ヘルスチェック用ページの作り方、ヘルスチェックの作成、フェイルオーバーレコードの登録、障害を模擬した切り替えテスト、監視の設定までを説明します。ホストゾーンの作成やネームサーバーの切り替えは済んでいて、すでに Route 53 でサイトが表示できている状態を前提にしています。
Route 53 の機能や上限、コンソールの表記は更新されることがあります。ここでは AWS の公開ドキュメント（2026年10月現在）に沿って説明しますが、作業前に公式ドキュメントでも確認してください。レコードの変更はサイト全体に影響するので、現在のレコードを書き出して控えを取ってから進めます。
構成の全体像と向いている場面
作る構成は次のとおりです。
- プライマリ：通常の WordPress サーバー（EC2 や VPS）。ヘルスチェックを付けます。
- セカンダリ：S3 に置いたメンテナンス用の HTML を CloudFront で配信するもの。プライマリが異常と判定されている間だけ、DNS の応答がこちらに切り替わります。
この方法は、1台構成のサーバーが止まったときに「接続できません」というブラウザのエラーではなく、状況を説明するページを出したい場合に向いています。ただし、DNS の切り替えなので即座には効きません。利用者側の DNS キャッシュが切れるまで（TTL の秒数ほど）は、古い向き先に接続し続けます。また、すでにサイト全体を CloudFront で配信している場合は、同じドメイン名を別のディストリビューションに設定できないため、この構成ではなく CloudFront のオリジンフェイルオーバーやカスタムエラーページで対応するほうが自然です。
手順1：ヘルスチェック用のページを用意する
トップページをそのままヘルスチェックの対象にすると、ページキャッシュが効いていて DB が止まっていても正常と判定されたり、重いページへの定期アクセスでサーバーに負荷がかかったりします。そこで、DB に接続できるかだけを確かめる軽いページを別に作ります。WordPress のルート（wp-load.php と同じ場所）に healthz.php として置きます。
<?php
// healthz.php：DB に接続できれば固定の文字列を返すだけのページ
define( 'SHORTINIT', true ); // WordPress の読み込みを最小限にする
require __DIR__ . '/wp-load.php';
header( 'Cache-Control: no-store' );
header( 'Content-Type: text/plain; charset=utf-8' );
global $wpdb;
if ( '1' === (string) $wpdb->get_var( 'SELECT 1' ) ) {
echo 'wp-health-ok';
} else {
http_response_code( 503 );
echo 'ng';
}SHORTINIT を定義すると、DB 接続など最小限の部分だけを読み込み、プラグインやテーマは読み込みません。DB に接続できないときは WordPress がエラー画面を返すので、wp-health-ok という文字列は含まれず、異常と判定されます。出力は固定の文字列だけにして、エラーの詳細やバージョンなどの情報は出さないようにしています。
ブラウザで https://example.com/healthz.php を開き、wp-health-ok だけが表示されれば準備完了です。サーバー側でページキャッシュ（nginx の FastCGI キャッシュなど）を使っている場合は、このパスをキャッシュの対象から外してください。
手順2：ヘルスチェックを作る
ヘルスチェックは、世界各地にある Route 53 の確認用サーバーから定期的にアクセスし、一定の割合が正常と判定すれば「正常」とみなす仕組みです。CDN を通すとキャッシュで障害が隠れるため、対象は WordPress サーバー（オリジン）を直接指すホスト名にします。ここでは origin.example.com がサーバーの IP アドレスを指している前提です。
aws route53 create-health-check \
--caller-reference "wp-origin-$(date +%Y%m%d%H%M%S)" \
--health-check-config '{
"Type": "HTTPS_STR_MATCH",
"FullyQualifiedDomainName": "origin.example.com",
"Port": 443,
"ResourcePath": "/healthz.php",
"SearchString": "wp-health-ok",
"RequestInterval": 30,
"FailureThreshold": 3,
"EnableSNI": true
}'HTTPS_STR_MATCH は、HTTPS で応答が返り、本文の先頭部分に指定した文字列が含まれているかを確認する種類です。RequestInterval は確認の間隔（秒）、FailureThreshold は何回続けて失敗したら異常とみなすかです。この例では、30秒間隔で3回続けて失敗すると異常になります。間隔を短くしたり閾値を下げたりすると早く切り替わりますが、一時的な遅れでも切り替わりやすくなります。
作成後に結果に表示される Id を控えておきます。次のコマンドで、各確認用サーバーからの判定を確認できます。
aws route53 get-health-check-status --health-check-id your-health-check-idここで失敗が並ぶ場合は、ファイアウォールやセキュリティグループで確認用サーバーの通信を止めていないかを見ます。確認用サーバーの IP アドレス範囲は、AWS が公開している ip-ranges.json に ROUTE53_HEALTHCHECKS として載っています。WAF やセキュリティ系のプラグインで、短い間隔のアクセスを攻撃とみなして遮断していないかも確認してください。
手順3：セカンダリ（メンテナンス画面）を用意する
S3 バケットにメンテナンス用の index.html を置き、CloudFront のディストリビューションで配信します。サイトと同じドメイン名で HTTPS を使うため、ディストリビューションの代替ドメイン名に example.com を設定し、米国東部（バージニア北部）リージョンの ACM で発行した証明書を付けます。メンテナンス画面には、復旧の見込みや連絡先など、訪問者が知りたいことを短く書いておきます。
CloudFront のドメイン（d111111abcdef8.cloudfront.net のような形）を直接開いて表示を確かめてから、次の手順に進みます。
手順4：フェイルオーバーレコードを登録する
フェイルオーバーでは、同じ名前・同じタイプのレコードを2つ作り、それぞれに PRIMARY と SECONDARY を指定します。注意したいのは、同じ名前・タイプの通常のレコード（シンプルルーティング）が残っていると登録できない ことです。既存のレコードの削除と、2つのレコードの追加を1回の変更にまとめて送ると、途中で名前解決ができなくなる時間を作らずに置き換えられます。
{
"Comment": "example.com を failover 構成に置き換える",
"Changes": [
{
"Action": "DELETE",
"ResourceRecordSet": {
"Name": "example.com", "Type": "A", "TTL": 300,
"ResourceRecords": [ { "Value": "203.0.113.10" } ]
}
},
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "example.com", "Type": "A",
"SetIdentifier": "primary", "Failover": "PRIMARY",
"TTL": 60,
"ResourceRecords": [ { "Value": "203.0.113.10" } ],
"HealthCheckId": "your-health-check-id"
}
},
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "example.com", "Type": "A",
"SetIdentifier": "secondary", "Failover": "SECONDARY",
"AliasTarget": {
"HostedZoneId": "Z2FDTNDATAQYW2",
"DNSName": "d111111abcdef8.cloudfront.net",
"EvaluateTargetHealth": false
}
}
}
]
}aws route53 change-resource-record-sets \
--hosted-zone-id your-hosted-zone-id \
--change-batch file://failover.jsonDELETE の内容は、今あるレコードと TTL や値まで一致していないと失敗します。aws route53 list-resource-record-sets で現在の値を確認し、その内容を写してください。Z2FDTNDATAQYW2 は CloudFront をエイリアスの向き先にするときに使う固定のホストゾーン ID です。IPv6 用の AAAA レコードがある場合は、同じ考え方で AAAA も置き換えます。
プライマリの TTL を60秒と短めにしているのは、切り替えの遅れを小さくするためです。TTL を短くすると問い合わせの回数は増えますが、切り替えを優先する構成ではこのくらいがよく使われます。
手順5：障害を模擬して切り替えを確かめる
本番で初めて切り替えが動く、という状態は避けたいところです。ヘルスチェックには判定を反転させる設定があり、サーバーを止めずに切り替えを試せます。アクセスの少ない時間帯に行ってください。
# 判定を反転（正常でも異常として扱われる）
aws route53 update-health-check --health-check-id your-health-check-id --inverted
# Route 53 のネームサーバーに直接問い合わせて応答を見る
dig +short example.com A @ns-123.awsdns-45.com
# 確認できたら忘れずに元に戻す
aws route53 update-health-check --health-check-id your-health-check-id --no-inverted反転後しばらくすると、dig の応答が CloudFront の IP アドレスに変わり、ブラウザ（キャッシュが切れた後）でメンテナンス画面が表示されます。元に戻すと、ヘルスチェックが正常に戻った時点で自動的にプライマリへ戻ります。ネームサーバー名はホストゾーンの NS レコードに表示されている自分の値に置き換えます。
手順6：切り替わったことに気づけるようにする
自動で切り替わっても、気づかなければ復旧が遅れます。ヘルスチェックの状態は CloudWatch の HealthCheckStatus メトリクス（正常で1、異常で0）として記録されるので、これにアラームを設定して SNS で通知します。Route 53 のヘルスチェックのメトリクスは 米国東部（バージニア北部）リージョン に記録されるため、アラームと通知先の SNS トピックもそのリージョンに作る点に注意してください。東京リージョンで探しても見つからない、というのはよくあるつまずきです。
また、メンテナンス画面に切り替わっている間は、WordPress への投稿や問い合わせフォームの送信もできません。切り替えが起きたときに誰が何を確認するのか（サーバーの状態、DB、直近の更新）を、手順書にまとめておくと対応が早くなります。
まとめ
- フェイルオーバールーティングは、同じ名前・タイプのレコードを PRIMARY と SECONDARY の2つ作り、ヘルスチェックで自動的に切り替える。
- ヘルスチェックは CDN を通さずオリジンを直接見る。対象は DB 接続だけを確かめる軽いページにし、固定の文字列で判定する。
- 確認用サーバーの通信をファイアウォールや WAF で止めないようにする。
- 既存のシンプルレコードの削除と2つのレコードの作成は、1回の変更にまとめる。TTL を短めにして切り替えの遅れを抑える。
- 判定の反転で切り替えを事前に試し、
HealthCheckStatusのアラームは米国東部リージョンに作る。