Amazon Route 53入門 DNS設定からドメイン管理まで オンプレ経験者のための実践ガイド

オンプレミスでBINDやUnbound、あるいはWindowsのDNSサーバーを運用してきたエンジニアがAWSに移行するとき、意外と戸惑うのがDNSの管理です。ゾーンファイルの編集やnamed.confの設定に慣れた身からすると、「クラウドのDNSは何がどう違うのか」「ドメイン移管の手順はどうなるのか」が気になるところでしょう。

この記事では、Amazon Route 53の基本機能からドメイン管理、料金体系、ヘルスチェックやフェイルオーバーの設定まで、オンプレDNSとの比較を交えながら体系的に解説します。Route 53の全体像を掴んでおけば、AWSでのインフラ設計でDNS周りに迷うことはなくなります。

なぜRoute 53なのか？オンプレDNSとの違い

オンプレミスのDNS運用を思い出してみてください。BINDのゾーンファイルを手動で編集し、シリアル番号をインクリメントして、rndc reloadで反映する。マスター・スレーブ構成を組んで冗長化し、監視ツールでプロセスの死活を見張る。ハードウェア障害が起きれば、深夜でもデータセンターに駆けつけることもありました。

Amazon Route 53は、AWSが提供するフルマネージドのDNSサービスです。名前の由来はDNSが使うTCPポート53番から来ています。

オンプレDNSとの決定的な違いは次の3点です。

・100% SLA: Route 53はAWSサービスの中でも数少ない100%の可用性SLAを掲げています。BINDサーバーの冗長構成で苦労していた日々が嘘のようです
・エニーキャストネットワーク: 世界中のエッジロケーションからDNSクエリに応答します。オンプレでは自社のDNSサーバーが設置されたデータセンターからしか応答できませんでしたが、Route 53ではユーザーに最も近い拠点から自動的に応答します
・AWSサービスとのネイティブ統合: ELB、CloudFront、S3の静的ホスティングなどに「エイリアスレコード」で直接接続できます。CNAMEのようにZone Apexで使えない制約がありません

オンプレDNSの知識はRoute 53でもそのまま活きます。Aレコード、CNAME、MX、TXTといったレコードタイプの概念は同じです。違うのは、インフラの運用負荷がゼロに近くなることと、AWSならではの機能が追加されていることです。

Route 53の基本機能

Route 53の機能は大きく3つに分かれます。DNSルーティング、ドメイン登録、ヘルスチェックです。ここでは、まずDNSルーティングの基本を押さえましょう。

1. ホストゾーンの作成

Route 53でDNSを管理するには、まず「ホストゾーン」を作成します。オンプレでいうゾーンファイルに相当するものです。

ホストゾーンには2種類あります。

・パブリックホストゾーン: インターネットからのDNSクエリに応答する。通常のWebサイトやAPIのDNS管理に使用
・プライベートホストゾーン: VPC内からのDNSクエリにのみ応答する。社内システムの名前解決に使用。オンプレの内部DNSに相当

AWS CLIでパブリックホストゾーンを作成する例を見てみましょう。

# AWS CLI: パブリックホストゾーンを作成
aws route53 create-hosted-zone   --name example.com   --caller-reference 2026-04-02-001

作成するとNSレコードとSOAレコードが自動生成されます。BINDのゾーンファイルを新規作成したときにSOAとNSを手書きしていた作業が不要になります。ドメインのレジストラ側で、Route 53が払い出したNSレコードの値をネームサーバーとして設定すれば、DNSの委任は完了です。

2. レコードの登録

ホストゾーンにレコードを追加する操作は、BINDのゾーンファイル編集に当たります。Route 53では、マネジメントコンソールまたはAWS CLIから操作します。

# AWS CLI: Aレコードを追加するJSON（change-batch.json）
{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "www.example.com",
      "Type": "A",
      "TTL": 300,
      "ResourceRecords": [{"Value": "203.0.113.10"}]
    }
  }]
}

# レコードの適用
aws route53 change-resource-record-sets   --hosted-zone-id Z1234567890ABC   --change-batch file://change-batch.json

BINDと違い、シリアル番号の手動更新は不要です。変更はRoute 53側で自動的にバージョン管理されます。UPSERTを使えば、レコードが存在しなければ作成、存在すれば更新という動作になるため、冪等な操作が可能です。

3. 主要なルーティングポリシー

Route 53のDNSレコードには、オンプレDNSにはないルーティングポリシーを設定できます。

オンプレでGeoDNSやフェイルオーバーを実現しようとすると、F5 GTMのような高額なアプライアンスが必要でした。Route 53なら、レコード設定だけでこれらの機能を使えます。

Route 53の料金体系

Route 53の料金は大きく3つの要素で構成されます（2026年4月時点）。

・ホストゾーン: 1ゾーンあたり月額$0.50。最初の25ゾーンまでは$0.50/ゾーン、26ゾーン以上は$0.10/ゾーン
・DNSクエリ: スタンダードクエリは100万クエリあたり$0.40。レイテンシーベースや位置情報ルーティングのクエリは100万あたり$0.60
・ヘルスチェック: AWSエンドポイントは1チェックあたり月額$0.50。AWS以外のエンドポイントは月額$0.75

オンプレDNSと比較すると、サーバーのハードウェア費用、OS・BINDのライセンスとパッチ管理、冗長構成のための機器、監視ツール、データセンターの電気代、そして障害対応の人件費が全て不要になります。中小規模のサイトであれば、Route 53の月額コストは数ドル程度で収まるケースがほとんどです。

ドメインの登録・移管にも別途料金がかかります。.comドメインの場合、年間$13.00程度です。ドメインをRoute 53で直接管理すれば、レジストラとDNSが一元管理できるため運用がシンプルになります。

応用・実務Tips

エイリアスレコードを活用する

Route 53の最も便利な機能がエイリアスレコードです。通常のDNSでは、Zone Apex（example.com）にCNAMEレコードを設定できません。RFC違反になるためです。BINDで運用していた方なら、この制約で頭を悩ませた経験があるのではないでしょうか。

Route 53のエイリアスレコードは、Zone ApexでもELBやCloudFrontのエンドポイントを指定できます。しかもエイリアスレコードへのDNSクエリには課金されないため、コスト面でも有利です。

# AWS CLI: Zone ApexにALBのエイリアスレコードを設定
{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "example.com",
      "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z35SXDOTRQ7X7K",
        "DNSName": "my-alb-123456.ap-northeast-1.elb.amazonaws.com",
        "EvaluateTargetHealth": true
      }
    }
  }]
}

ヘルスチェックとフェイルオーバーの組み合わせ

Route 53のヘルスチェックは、指定したエンドポイントの死活監視を行い、異常を検知したら自動的にDNSレコードを切り替えます。オンプレでは監視ツールがアラートを上げて、担当者が手動でDNSを切り替えるか、GTMのような専用機器が必要でした。

ヘルスチェックの設定で押さえておくべきポイントは以下のとおりです。

・チェック間隔: 標準は30秒間隔（高速オプションは10秒、追加料金あり）
・失敗閾値: デフォルトは3回連続失敗でUnhealthy判定
・リージョン: 世界中の複数リージョンからチェックが実行される。特定リージョンからのみ失敗している場合は、ネットワーク経路の問題の可能性がある
・文字列マッチング: HTTPレスポンスのボディに特定の文字列が含まれているかを確認できる。ステータスコード200だがアプリケーションエラーを返しているケースを検知可能

DNSの基盤となるLinuxサーバーの運用については、姉妹サイトLinuxMaster.JPで詳しく解説しています。

Route 53 Resolver（ハイブリッド環境向け）

オンプレミスとAWSのハイブリッド環境では、双方のDNS名前解決が課題になります。Route 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントを使えば、オンプレからVPC内の名前解決、VPCからオンプレの名前解決を相互に実現できます。

オンプレのActive DirectoryドメインをVPCから解決したい場合など、移行期のハイブリッド構成で非常に重宝します。

よくあるトラブルと対処法

レコードを変更したのに反映されない

Route 53側の変更は即座に反映されますが、DNSキャッシュの影響で古いレコードが返り続けることがあります。TTLを短く設定してから変更を行い、反映後にTTLを元に戻すのが定石です。BINDの運用でも同じ手順を踏んでいた方は多いでしょう。

# digコマンドでRoute 53のネームサーバーに直接問い合わせ
dig www.example.com @ns-1234.awsdns-56.org

# TTLと応答内容を確認
dig +noall +answer www.example.com

ドメイン移管時のダウンタイム

他のレジストラからRoute 53へドメインを移管する際、ネームサーバーの切り替えタイミングで名前解決ができなくなるリスクがあります。安全な手順は以下のとおりです。

・Step 1: Route 53にホストゾーンを作成し、現在のDNSレコードをすべて複製する
・Step 2: 現行レジストラ側でTTLを短く（300秒程度）変更し、TTL分の時間が経過するのを待つ
・Step 3: レジストラ側のネームサーバーをRoute 53のNSレコードの値に変更する
・Step 4: 名前解決がRoute 53から応答されることをdigで確認後、ドメイン移管手続きを開始する

ヘルスチェックが誤検知する

セキュリティグループやネットワークACLで、Route 53のヘルスチェッカーのIPアドレスレンジからのアクセスをブロックしていると、正常なエンドポイントがUnhealthy判定されます。AWSが公開しているIPレンジ（ip-ranges.json内のROUTE53_HEALTHCHECKSプレフィックス）を許可リストに追加してください。

本記事のまとめ

Amazon Route 53は、オンプレDNSの知識をそのまま活かしつつ、運用負荷を大幅に削減できるサービスです。

DNSはインフラの根幹です。Route 53を正しく理解しておくことで、ELBやCloudFrontとの連携、マルチリージョン構成、ハイブリッド環境でのDNS統合など、AWSインフラ設計の幅が大きく広がります。まずはホストゾーンの作成とレコード登録から試してみてください。