Amazon Route 53で実現するグローバル・ロードバランシング（DNSフェイルオーバー）の基礎と構築手順
Webサービスや基幹システムの運用において、システムを停止させない構成（高可用性）の確保は最優先課題の一つです。
AWSのDNSサービスであるAmazon Route 53を利用すると、世界中に分散したインフラへのトラフィック分散（グローバル・ロードバランシング）と、障害発生時の自動切り替え（DNSフェイルオーバー）をシンプルかつ低コストで実現できます。
本記事では、一般的なDNSが抱える課題から、DNSフェイルオーバーの仕組み、代表的な利用シーン、構築手順、テスト方法、運用時の注意点までを体系的に解説します。
この記事の目次
一般的なDNSの挙動と課題
DNSフェイルオーバーの必要性と価値を理解するために、まずは一般的なDNSの挙動や負荷分散の仕組み、その課題について整理します。
一般的なDNSの仕組み
一般的なDNS運用では、1つのドメイン名（例：example.com）に対して、特定のIPアドレスを固定で紐付けます（静的なAレコード設定）。ユーザがWebサイトにアクセスしようとすると、DNSサーバーは常に登録された同じIPアドレスを返します。
また、複数台のサーバーにアクセスを振り分ける標準的な手法として「DNSラウンドロビン」があります。これは、1つのドメイン名に対して複数のIPアドレスを登録しておき、DNSサーバーが問い合わせを受けるたびに順番を変えて応答することで、簡易的な負荷分散を実現する仕組みです。
一般的なDNSが抱える3つの課題
一見すると便利に思われる一般的なDNS運用やDNSラウンドロビンですが、高可用性が求められる環境においては非常に大きなリスクが存在します。
障害発生（ダウン）したサーバーのIPを返し続けてしまう
一般的なDNSの最大の課題は、「DNSサーバー自体は接続先のサーバーが正常に稼働しているかどうか（死活状態）を感知できない」という点です。例えば、DNSラウンドロビンで2台のWebサーバー（サーバーA・サーバーB）にアクセスを分散させているときに、サーバーAが障害で停止したとします。一般的なDNSはサーバーAの停止を検知できないため、問い合わせてきたユーザの半数に対して、障害が発生しているサーバーAのIPアドレスを返し続けてしまいます。 その結果、サーバーAへアクセスしたユーザにはエラー画面が表示されます。
手動切り替えによる復旧の遅延（ダウンタイムの増大）
サーバーがダウンした際、一般的なDNSの構成のままアクセスを正常なサーバーへ寄せるには、管理者が手動でDNSのAレコードを削除・変更しなければなりません。
障害の検知から担当者への連絡、DNS設定の書き換えまでを人が行うため、どうしても数分〜数時間のタイムラグが発生します。特に夜間や休日に障害が発生した場合、システムの停止時間（ダウンタイム）が大幅に延びる原因になります。
DNSキャッシュ（TTL）による遅延の影響
さらに、仮に管理者がDNSレコードを手動で迅速に変更できたとしても、すぐにすべてのユーザのアクセス先が切り替わるわけではありません。
世界中のプロバイダ（ISP）やユーザの端末（PC・スマートフォンなど）には、過去の名前解決結果（DNSキャッシュ）が保持されています。TTL（キャッシュの保持時間）が長めに設定されている場合、DNSレコードを書き換えた後もキャッシュが切れるまでの間、ユーザは障害が発生している古いIPアドレスへアクセスし続けてしまいます。
DNSフェイルオーバーとは
ここまで解説してきた一般的なDNSの課題を解決するのが、DNSフェイルオーバーです。
仕組みと特徴
DNSフェイルオーバーとは、DNSサーバーが対象エンドポイント（Webサーバーやロードバランサーなど）に対して定期的にヘルスチェック（死活監視）を行い、異常を検知した際に自動でDNS応答を正常な環境へ切り替える技術です。
- 障害検知：世界中の監視ノードからHTTP/HTTPS/TCPなどのリクエストを定期送信。
- 自動除外：応答がない（またはエラーを返す）サーバーのIPアドレスをDNSの応答リストから即座に除外。
- 自動迂回：正常に稼働している別のサーバーや、待機用のSorryページのIPアドレスのみを応答。
単一のリージョン内（同一データセンター内）のEC2インスタンス間の障害検知・切り離しは、通常ALB（Application Load Balancer）などのL7ロードバランサーが行います。一方で、リージョンやクラウド、拠点をまたぐ障害の検知・切り離しを担うのがDNSフェイルオーバーです。
DNSフェイルオーバーの代表的な利用シーン
DNSフェイルオーバーは、主にシステム全体の停止が許されない場面や、単一拠点・単一クラウドの限界を超える可用性が必要な場面で導入されます。
| 利用シーン | 概要・構成 |
| ① ディザスタリカバリ（DR・災害対策） | 通常時はメインの「東京リージョン」で処理し、大地震や広域障害で東京リージョン全体に障害が発生した際に、自動で「大阪リージョン」や海外拠点へアクセスを切り替える（アクティブ/パッシブ構成）。 |
| ② 静的Sorryページの自動表示 | Webサーバー群やデータベースが障害・メンテナンスによって利用できない場合、S3などでホストしている「ただいまメンテナンス中です」という静的ページへ自動で誘導する。 |
| ③ マルチリージョンでの常時負荷分散 | 東京と大阪（または世界各国）の複数拠点を常時稼働（アクティブ/アクティブ）させて通常時のアクセスを分散しつつ、障害が発生した拠点のみを自動的に切り離す。 |
| ④ マルチクラウド / ハイブリッド構成 | AWSとオンプレミス（自社データセンター）、あるいはAWSとGoogle Cloud/Azure間など、クラウド環境をまたいで冗長化・フェイルオーバーを行う。 |
Route 53によるグローバル・ロードバランシングの仕組み
Amazon Route 53では、ヘルスチェックと多様なルーティングポリシーを組み合わせることで、高度なグローバル・ロードバランシングを実現します。
- レイテンシーベースルーティング：ユーザから最もネットワーク遅延が少ないリージョンへ自動で誘導する。
- 位置情報（Geolocation）ルーティング：ユーザの国や地域ごとに最適なサーバーへ誘導する。
- 加重ルーティング：複数のエンドポイントへ指定した比率（例：80%と20%）でアクセスを分散させる。
- フェイルオーバールーティング：プライマリ（メイン）とセカンダリ（予備）を明示的に定義して切り替える。
Route 53によるDNSフェイルオーバーの構築手順（東京ALB・大阪ALBの例）
Route 53でマルチリージョン（東京・大阪）のDNSフェイルオーバーを構築する具体的な手順を解説します。
手順1. Route 53 パブリックホストゾーンの作成
レコードを作成する前に、対象ドメインの管理領域となるホストゾーンを作成し、ネームサーバーを設定します。
- Route 53コンソールの左メニューから [ホストゾーン] を選択し、[ホストゾーンの作成] をクリック
- ドメイン名：取得済みのドメイン名（例：example2.com）を入力
- タイプ：「パブリックホストゾーン」 を選択して作成
- ネームサーバー（NS）の設定：作成後に表示される4本のNSレコード（例：ns-xxx.awsdns-xx.com） を、お名前.comやValue Domainなどのレジストラ管理画面に設定
手順2. エンドポイント（ALB）の準備
マルチリージョンインフラの準備を行います。
プライマリ環境（東京）およびセカンダリ環境（大阪）のそれぞれにロードバランサーを用意します。
手順3. Route 53ヘルスチェックの作成
FQDN（ドメイン名）を指定し、東京・大阪それぞれのALBに対する死活監視を作成します。
【東京ALBの例】
- Route 53 コンソールの [ヘルスチェック] ＞ [ヘルスチェックの作成] を選択
- 名前：hc-tokyo-alb-secondary
- 監視対象：「エンドポイント」
- 監視方法：「ドメイン名（FQDN）」 ※ALBのIPアドレスは変動するためIP指定は不可
- ドメイン名：東京ALBのDNS名（例：tokyo-alb-xxxxxx.ap-northeast-1.elb.amazonaws.com）＊ロードバランサーのDNS名を参照してください
- プロトコル：HTTP（または HTTPS）
- 高度な設定：評価間隔 30秒（または 10秒）、失敗の閾値 3回
大阪ALB側も同様に hc-osaka-alb-primary として作成します。
手順4. ホストゾーンでのレコード作成と紐付け
手順1で作成したホストゾーン内で、エイリアスレコードとフェイルオーバーポリシーを設定します。
1. プライマリレコード（東京ALB）の追加:
- レコード名：空欄（ルートドメイン example.com の場合）。本記事では「test」を設定します。
- レコードタイプ：A – IPv4 アドレスにトラフィックをルーティングします。
- エイリアス：有効
- トラフィックのルーティング先：「Application Load Balancer と Classic Load Balancer のエイリアス」
- リージョン／ロードバランサー：ap-northeast-1 / 東京ALBを選択
- ルーティングポリシー：「フェイルオーバー」
- フェイルオーバーレコードタイプ：「プライマリ」
- ヘルスチェックに関連付ける：はい ＞ hc-tokyo-alb-secondary を選択
- レコード ID：Tokyo-ALB-Secondary
2. セカンダリレコード（大阪ALB）の追加:
[別のレコードを追記] をクリックし、同じレコード名・Aタイプで設定します。
- エイリアス先：ap-northeast-3 / 大阪ALBを選択
- ルーティングポリシー：「フェイルオーバー」
- フェイルオーバーレコードタイプ：「セカンダリ」
- ヘルスチェックに関連付ける：はい ＞ hc-osaka-alb-primary を選択
- レコード ID：Osaka-ALB-Primary
手順5. 障害シミュレーション（切り替えテスト）
フェイルオーバー構成が正しく機能するかを確認するため、以下の3フェーズで擬似障害を発生させた動作確認と切り戻しテストを行います。
フェーズ1：通常状態（正常時）の確認
端末のターミナルから dig や nslookup を実行し、返ってくるIPアドレスが「大阪ALB」のものであることを確認します。
フェーズ2：擬似障害の発生とフェイルオーバー確認
1. 擬似障害を発生させる：東京ALBのセキュリティグループのインバウンドルールを一時的に削除し、Route 53ヘルスチェック用IPおよび外部からの通信（80/443）を完全に遮断します。
2. ステータス変化を確認：Route 53の「ヘルスチェック」画面で、hc-osaka-alb-primary のステータスが「正常」から「異常」に変わることを確認します（約90秒）。
3. 名前解決の切り替え確認：DNSキャッシュの影響を避けるため、Route 53の権威DNSサーバーへ直接問い合わせを実行します。
応答IPアドレスが大阪ALBのIPアドレスへ自動的に切り替わっていれば成功です。
フェーズ3：復旧（切り戻し）の確認
1. 東京ALBのセキュリティグループのインバウンドルールを元の状態に戻します。
2. 現在のステータスが「正常」に復帰することを確認します。
3. 再度 dig を実行し、DNS応答がプライマリ（東京ALB）のIPアドレスへ自動で戻る（切り戻される）ことを確認します。
Route 53を導入するメリットと注意点
メリット
リージョンやクラウドをまたぐ環境における高可用性
単一のAWSリージョン障害にも耐えられる堅牢なインフラを、最小限の構成で実現できます。
低コストでの運用
専用のハードウェアロードバランサーを導入することなく、DNS機能＋ヘルスチェック料金のみで利用が可能です。
デメリットと導入時の注意点
【設定時】ALB指定時の「IPAddress」型エラー
IaC（CloudFormationやTerraform）やAPIでヘルスチェックを設定する際、ALBのDNS名を IPAddress パラメーターに渡してしまうと not a valid value of union type ‘IPAddress’ という構文エラーになります。必ず FullyQualifiedDomainName (fqdn) を指定して作成してください。
【運用時】DNSキャッシュによる「切り替えの遅延（TTLの影響）」
クライアントのPCやプロバイダ（ISP）に旧IPアドレスのキャッシュが残っていると、フェイルオーバー後も一定期間は障害環境へアクセスしようとしてしまいます。
対策：フェイルオーバー対象レコードのTTL（Time To Live）を60秒などの短時間に設定しておきます。
【設計時】データベース（DB）同期の課題
トラフィックを即座に別リージョンへ切り替えても、DBのデータレプリケーション（同期）が遅延しているとデータの不整合が発生します。
対策：Amazon Aurora Global Databaseなどを導入し、データ層のマルチリージョン化もあわせて設計する必要があります。
まとめ
Amazon Route 53を活用したDNSフェイルオーバーは、通常時の負荷分散から広域障害時の自動リカバリまでをカバーする有効なソリューションです。
単一サーバーの障害にはALBなどのローカルなロードバランサーで対応し、データセンターやリージョン規模の広域障害にはRoute 53のDNSフェイルオーバーで対応するという役割分担を理解しておくことが、堅牢なインフラ設計の第一歩となります。
ベアサポートでは、AWSをはじめとするマルチクラウドの設計・構築から、24時間365日の監視・運用代行までお客さまのシステム基盤をトータルでサポートしています。広域障害対策やDR構成でお悩みの方は、ぜひお気軽にご相談ください。
