はじめに
こんにちは、山本です。
私が前職でオンプレミスでシステム運用をしていた頃、DNSサーバーは必ず プライマリ／セカンダリ構成 にしていました。
しかし AWS を勉強&業務活用し始めてから「Amazon Route 53はリージョンを選ばなくても冗長化されている」、「 SLA が100％」と聞き、「いったいどうやって可用性を担保しているのか？」と疑問に思いました。
今回は、オンプレのDNS構成とAmazon Route 53の内部冗長設計を比較しながら、Amazon Route 53の DNS 可用性の考え方を整理していきます。
オンプレミス時代のDNS可用性： Primary / Secondary 構成
オンプレミスのDNSでは、冗長化の基本は「プライマリ／セカンダリ構成」でした。
[Primary DNS] -----( AXFR/IXFR でゾーン転送)-----> [Secondary DNS]
Primary DNS
ゾーン情報を編集・管理するサーバ。Secondary DNS
Primaryからゾーン情報を定期的に転送( AXFR/IXFR )して複製し、読み取り専用で運用。(構成によってはセカンダリでもゾーン情報を編集できることもあります)
※ AXFR/IXFR についてはこちらのサイトを参照
上記の構成により、Primary DNS が障害で停止してもSecondary DNS が名前解決を継続できていました。
また、前職では閉塞的ネットワーク内でシステム運用していたこともあり2台の DNS サーバは同じネットワークに配置していましたが、要件によってはネットワーク的に分離された複数拠点で冗長化することで可用性を担保していました。
AWS における DNS 冗長化：Amazon Route 53はグローバル分散アーキテクチャ
AWS の DNS サービスである Amazon Route 53 は、 この「 Primary／Secondary 構成」という考え方そのものを不要にするアーキテクチャで設計されています。
Amazon Route 53 はリージョンレス（グローバルサービス）
AWS には「リージョンサービス」と「グローバルサービス」があります。 Amazon Route 53 は後者に分類され、世界中で1つの分散システムとして動作しています。
つまり、東京リージョンやバージニア北部リージョンといった概念は Amazon Route 53 には存在しません。
DNS ゾーンやレコードは、グローバルなコントロールプレーン上に保存・複製されています。
※コントロールプレーンはDNSゾーン情報を管理する層です。
ネットワーク最適化：Anycastによるグローバル分散
Amazon Route 53 は Anycast ネットワーク上で動作しています。
同じ IP アドレスを世界中の DNS サーバ群が共有し、クライアントは最も近い DNS へ自動的にルーティングされます。
''' text クライアント ↓（最寄りの経路に自動誘導） [Amazon Route 53 DNS エッジサーバ群] ↓ AWS内部の分散コントロールプレーン ↓ Hosted Zone データ（複数のリージョンに複製） '''
データ耐久性：ゾーン情報の多重複製
オンプレでは、Primaryサーバーのゾーンファイルが壊れると復旧が大変でしたが、Amazon Route 53ではゾーン情報が複数のAWSリージョンに自動レプリケーションされています。
つまり、ユーザーが意識的にセカンダリを立てる必要はなく、AWS内部でゾーンデータが多重冗長化されているという仕組みです。
この仕組みによって普段私たちが何気なく Amazon Route 53 を使っているバックグラウンドで可用性が担保されています。
可用性：フェイルオーバーと設計のネイティブ対応
Amazon Route 53 は DNS 自体の冗長化だけでなく、ヘルスチェックとフェイルオーバーDNSレコードの機能を提供しています。
- DNS フェイルオーバー：ヘルスチェックに失敗したエンドポイントを自動的に無効化し、正常系へトラフィックを切り替える。
- 加重・地理的ルーティング：トラフィックを複数エンドポイントに分散、または地域ごとに最適化。
これらは従来で言う「セカンダリ DNS で引き継ぐ」動作を、クラウド内のマネージド機能として実装していると考えると理解しやすいです。
参考：
オンプレミスでの DNS と Route 53 の比較
ここまで Amazon Route 53 での機能について深掘りしてましたが、簡単な比較として表に示します。
| 観点 | オンプレミス DNS | Amazon Route 53 |
|---|---|---|
| 冗長構成 | Primary / Secondary | Anycast + グローバル分散（自動複製） |
| ゾーン同期 | AXFR / IXFR プロトコル | AWS 内部の自動レプリケーション |
| フェイルオーバー | Secondary 側で受け継ぐ | DNS フェイルオーバー設定で自動 |
| 可用性SLA | 無し（構成次第） | 100% |
| 運用コスト | 高（手動設定・監視） | 低（マネージドサービス） |
おわりに
オンプレミス時代に私が行っていた「 Primary/Secondary 構成での冗長化」は、 AWSではサービスアーキテクチャそのものが冗長化を内包しているため、ユーザーが意識的に構成を組む必要がありません。
Amazon Route 53は「冗長化を設計するサービス」ではなく、「冗長化が前提で設計されたサービス」です。 クラウドにおける DNS 可用性の考え方はサーバーを二重化することから、分散アーキテクチャを活用することへシフトしているのではないかと今回調査を行う中で感じました。
今回の記事のように、普段何気なく扱っているサービスの裏側がどうなっているのか また、オンプレミスの時代ではどのように実現していて何がボトルネックとなっていたのかを考えながら学習することで、より深い AWS サービスへの理解度が得られるのではないかと思います。
今回の記事が皆さんの資格勉強や実際にサービスを実務で取り扱う際に参考になれば幸いです。
山本 竜也 (記事一覧)
2025年度新入社員です！AWSについてはほぼ未経験なのでたくさんアウトプットできるよう頑張ります✨
