ジオDNS は「利用者がどの地域から問い合わせたか」で返すアドレスを変える仕組み、GSLB は「その拠点が今応答できるか」を見て返すアドレスを決める仕組みです。両方を組み合わせると、普段は利用者に近い拠点を返し、その拠点が止まったときだけ別の地域の拠点を返す構成が作れます。この記事では、日本と米国に WordPress の拠点を置く例で、Amazon Route 53 での組み方（位置情報のレコードの下にフェイルオーバーのレコードを置く形）、位置の判定の限界、既定の地域、WordPress 側で決めておくこと、試験の方法を説明します。
2つの仕組みの役割を分ける
組み合わせるときは、判断を二段に分けて考えると設計が整理できます。
- 一段目（ジオDNS）：問い合わせ元の地域から、「どの地域の担当にするか」を決める
- 二段目（GSLB）：その担当の中で、「主の拠点が正常か。異常ならどこを代わりに返すか」を決める
一段目だけでは、拠点が止まっても同じ地域の利用者には止まった拠点のアドレスを返し続けます。二段目だけでは、すべての利用者が同じ拠点に向かい、遠い地域の利用者は遅くなります。両方を重ねることで「近さ」と「生きているか」の両方を反映できます。
構成例：日本と米国の2拠点
ここでは次の割り当てにします。
問い合わせ元 担当 主の拠点 代わりの拠点
日本 jp 担当 東京 米国
北米 us 担当 米国 東京
それ以外（既定） jp 担当 東京 米国ポイントは、各担当に「代わりの拠点」を決めておくことです。東京が止まったとき、日本の利用者は米国の拠点に向かいます。遅くはなりますが、サイトは見られます。
Route 53 での組み方
Route 53 では、位置情報ルーティングのレコードから、担当ごとのフェイルオーバーのレコードをエイリアスで参照する、入れ子の形で組みます。
まず、担当ごとのフェイルオーバーのレコードを作ります。jp.failover.example.com の例です。
{
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "jp.failover.example.com",
"Type": "A",
"SetIdentifier": "jp-primary-tokyo",
"Failover": "PRIMARY",
"TTL": 60,
"ResourceRecords": [ { "Value": "192.0.2.10" } ],
"HealthCheckId": "your-health-check-id-tokyo"
}
},
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "jp.failover.example.com",
"Type": "A",
"SetIdentifier": "jp-secondary-us",
"Failover": "SECONDARY",
"TTL": 60,
"ResourceRecords": [ { "Value": "198.51.100.20" } ],
"HealthCheckId": "your-health-check-id-us"
}
}
]
}us.failover.example.com も、主と副を入れ替えて同じように作ります。
次に、利用者が問い合わせる www.example.com を位置情報ルーティングで作り、それぞれの担当のレコードをエイリアスで指します。日本と既定の例です（北米は ContinentCode に NA を指定し、us.failover.example.com を指します）。
{
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.example.com",
"Type": "A",
"SetIdentifier": "geo-jp",
"GeoLocation": { "CountryCode": "JP" },
"AliasTarget": {
"HostedZoneId": "your-zone-id",
"DNSName": "jp.failover.example.com",
"EvaluateTargetHealth": true
}
}
},
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.example.com",
"Type": "A",
"SetIdentifier": "geo-default",
"GeoLocation": { "CountryCode": "*" },
"AliasTarget": {
"HostedZoneId": "your-zone-id",
"DNSName": "jp.failover.example.com",
"EvaluateTargetHealth": true
}
}
}
]
}EvaluateTargetHealth を true にすると、参照先の担当の主と副がどちらも異常なとき、位置情報の側でもそのレコードを使えないものとして扱えます。エイリアスのレコードには TTL を書かず、参照先のレコードの TTL が使われます。
同じ構成は、Route 53 の Traffic Flow（トラフィックポリシー）の画面で図として組むこともできます。Cloudflare の Load Balancing や Azure Traffic Manager などにも、地域ごとの振り分けと拠点の監視を組み合わせる機能があります。名称や機能の範囲、料金の体系は変わることがあるため、各社のドキュメントで確認してください（2026年10月現在）。
位置の判定はリゾルバーのアドレスで決まる
ジオDNS が見ているのは、多くの場合、利用者の端末ではなく、問い合わせてきたリゾルバーのアドレスです。リゾルバーが EDNS Client Subnet（ECS）で利用者のアドレスの一部を伝える場合は、その情報も使われます。このため、次のずれが起きます。
- 会社の DNS サーバーが海外にあると、日本の社員が海外の担当になる
- VPN を使う利用者は、VPN の出口の地域で判定される
- ECS を送らない公開リゾルバーを使う利用者は、そのリゾルバーの拠点の位置で判定される（Cloudflare の 1.1.1.1 は、プライバシーの観点から ECS を送らない方針を示しています）
つまり、ジオDNS の割り当ては「おおよその近さ」です。法令や契約で地域ごとにアクセスを制限したい場合は、ジオDNS ではなく、拠点の Web サーバーやアプリケーション側で判定します。
既定の地域を忘れない
位置情報ルーティングで、どの割り当てにも当てはまらない問い合わせが来ると、既定（CountryCode が *）のレコードが無い場合、Route 53 はアドレスを返しません。地域が判定できない問い合わせもあるため、既定のレコードは必須と考えてください。
また、日本の担当が使えない（主と副がどちらも異常）ときには、Route 53 はより広い地域や既定のレコードを探して応答します。この構成では既定も東京と米国を参照するため、両拠点が同時に止まらない限り、どこかの拠点が返ります。
WordPress 側で決めておくこと
DNS の構成より先に、WordPress をどう2拠点で動かすかを決めます。
- 書き込み先は一か所にする：投稿、コメント、ログイン、注文の書き込みは、主のデータベース（例: 東京）に集めます。米国の拠点から東京のデータベースへ書き込むと遅くなるため、米国の拠点は閲覧中心と割り切り、ページキャッシュを厚くします。読み取りと書き込みでデータベースを分けるには
db.phpのドロップイン（HyperDB、LudicrousDB など）を使う方法がありますが、保守の状況と、使っている WordPress の版での動作を確かめてから採用します。 - 管理画面の扱い：管理画面の操作は書き込みが多いため、管理者は主の拠点に直接接続する経路（社内の VPN など）を用意しておくと、ジオDNS の判定に左右されません。
- メディアとファイル：アップロードしたファイルは、共有のストレージや CDN から配信し、拠点ごとに中身が食い違わないようにします。
- どの地域にも同じ内容を返す：地域によってページの内容を変えると、検索エンジンのクローラーが見る内容と利用者が見る内容がずれることがあります。拠点が違っても、同じ URL には同じ内容を返します。
試験の方法
Route 53 の test-dns-answer では、問い合わせ元のアドレスや ECS の値を指定して、どの応答になるかを確かめられます。
aws route53 test-dns-answer --hosted-zone-id your-zone-id \
--record-name www.example.com --record-type A \
--edns0-client-subnet-ip your-jp-ip --edns0-client-subnet-mask 24権威サーバーに dig で ECS を付けて聞く方法もあります。
NS=$(dig +short NS example.com | head -n 1)
dig @"$NS" www.example.com A +subnet=your-jp-ip/24 +short +norecurseアドレスの部分には、日本と米国の実際の回線のアドレスを入れて試します。そのうえで、東京の確認用 URL を異常にして、日本からの問い合わせに米国のアドレスが返ること、戻したあとに東京へ戻ることを確かめます。作業の前には aws route53 list-resource-record-sets でレコードを書き出して保存してください。
まとめ
- ジオDNS で「どの地域の担当か」を、GSLB で「主が正常か、異常ならどこか」を決める二段の構成にします。
- Route 53 では、位置情報ルーティングのレコードから、担当ごとのフェイルオーバーのレコードをエイリアスで参照し、ターゲットの状態を評価させます。
- 位置の判定はリゾルバーのアドレスと ECS で決まるおおよそのものなので、アクセス制限には使いません。既定のレコードは必須です。
- WordPress は書き込み先を一か所にし、遠い拠点は閲覧中心にします。