Route53 - AWS

最終更新日: 2026-07-30

TOP(About this memo)) > 一覧(AWS) > Route53

Route53

AWSのDNS管理機能。AWS上の各サービスを独自ドメインで利用する上で便利な機能が用意されている。
(IMO) Route53で管理する最大のメリットは、ELBやCloudFrontなどの他サービスとAliasレコードで連携しやすくなる点だと思う。

料金

Route53には無料枠が設定されていないため、若干の料金が発生する。
- ホストゾーン1つにつき0.50USD/月
- 100万件のクエリごとに0.400USD
- Aliasレコードで名前解決するAWSリソース(ELB、CloudFront等)へのクエリはこの課金対象外(?)。

ホストゾーンとは

ホストゾーン1つは、1個のドメイン(example.com)を管理するグループの単位。
ホストゾーンには2種類ある。
- パブリックホストゾーン: インターネット上から名前解決できる、通常のドメイン管理用。
- プライベートホストゾーン: 1つ以上のVPCに関連付け、そのVPC内からのみ名前解決できる。社内向けの内部ドメインなどに使う。

レコードタイプ

Route53では一般的なDNSレコードタイプに加えて、AWS独自の「Aliasレコード」を設定できる。

標準的なレコードタイプ

A: ドメイン名 → IPv4アドレス
AAAA: ドメイン名 → IPv6アドレス
CNAME: ドメイン名 → 別のドメイン名(正規名)。ゾーンApex(example.comのようなドメイン自体)には設定できない制約がある。
MX: メールサーバーの優先順位付きリスト
TXT: 任意のテキスト。ドメイン所有権の証明、SPF、DKIM、DMARCなどに利用されることが多い(SES参照)。
NS: そのゾーンを管理するネームサーバー
SOA: ゾーンの管理情報(シリアル番号、TTLなど)。ホストゾーン作成時に自動生成される。
SRV: サービスが提供されるホスト名とポート番号
PTR: IPアドレス → ドメイン名の逆引き
CAA: そのドメインの証明書発行を許可する認証局(CA)を指定
NAPTR / DS: それぞれENUMなどの用途、DNSSECの鍵情報に使われる(?)。

Aliasレコード

AliasレコードはRoute53の内部で扱う特殊なタイプで、外から見るとただのAレコード(またはAAAAレコード)に見える。一言で言えば「各AWSプロダクトで利用するDNS名専用の、CNAMEレコード風の挙動を実現するレコード」。
CNAMEと異なり、ゾーンApexでも設定できる。また前述の通りAWSリソース向けのクエリは課金対象にならない(?)。
ELB、CloudFront、S3の静的website、API Gateway、Elastic Beanstalk、Global Acceleratorなど、多くのAWSリソースをAliasの参照先として指定できる。
(参考) https://dev.classmethod.jp/cloud/aws/amazon-route-53-alias-records/

ルーティングポリシー

1つのレコード名に対して複数の値・振り分けルールを設定する仕組み。トラフィックの制御方法によって以下のように分類される。

シンプル: 単一のリソースへ固定的に振り分ける、最も基本的な方式。
加重(Weighted): 設定した比率に応じて複数のリソースへ振り分ける。カナリアリリースやA/Bテストなどに使われる。
レイテンシーベース: リクエスト元から見て最もレイテンシーの低いリージョンのリソースへ振り分ける。
フェイルオーバー: プライマリ/セカンダリの構成にしておき、ヘルスチェックの結果に応じて自動的に切り替える。
位置情報(Geolocation): クライアントの地理的位置(国・大陸単位など)に基づいて振り分け先を変える。
地理的近接性(Geoproximity): リソースの位置とクライアントの位置に基づいて振り分ける。バイアス値でどこまで有利にするか調整可能。Traffic Flow機能経由でのみ設定できる(?)。
複数値回答(Multivalue Answer): 複数のレコード(最大8件)をランダムな順で返す。ヘルスチェックと組み合わせることで簡易的な負荷分散・冗長化に使える。

ヘルスチェック

エンドポイント(IP/ドメイン)に対して定期的にHTTP/HTTPS/TCPで死活監視を行う機能。
フェイルオーバールーティングと組み合わせて、異常時に別リソースへ自動的に切り替える用途で使われることが多い。
複数のヘルスチェックを論理的に組み合わせる「計算されたヘルスチェック」や、CloudWatchアラームの状態をそのままヘルスチェックとして扱う方法もある(?)。

その他の機能

Route53 Resolver: オンプレミス環境とVPCの間でDNSクエリを相互に転送する仕組み(インバウンド/アウトバウンドエンドポイント)。ハイブリッド環境での名前解決に使われる。
DNSSEC: パブリックホストゾーンに対してレコードの署名・検証を行い、DNSの応答改ざんを防ぐ。
クエリロギング: パブリックホストゾーンへのDNSクエリをログとして出力できる(?)。
Traffic Flow: 上記のルーティングポリシーを視覚的なエディタで組み合わせて設定できる機能(通常のレコード設定より複雑なルーティングを組みたい場合向け、追加課金あり(?))。

ドメインの取得

Route53でもドメイン自体を取得できるが、維持コストや取得コストを比較すると他のドメイン登録サービスのほうが安く済むことが多い(?)。

外部で取得したドメインをRoute53で使う

ドメイン登録サービス側でネームサーバーを、Route53のネームサーバーに設定する。先にAレコードを登録しないとエラーになることがある(?)。
(参考) https://mel.onl/onamae-domain-aws-route-53/
具体的な手順は後述の「実践: よくある設定の流れ」を参照。

ELBを使う場合の設定例

EC2を直接SSL化する(証明書を自分で取得する)のはコストがかかるため現実的ではない。そのため、AWS上で無料発行できる証明書が利用可能なELBやCloudFrontをEC2の前に立てる構成にする。
その場合、AレコードはエイリアスとしてELB(dualstack.〜.ap-〜.elb.amazonaws.com.のようなもの)を設定し、ELB側でドメインを登録する。
EC2に直接アクセスする用の内部ドメインは、hoge.ドメイン名など適当なサブドメインにしておく。

他サービスとの関連

Route53は単体で使うより、証明書やCDN、配信先リソースと組み合わせて使うことが多い。以下は代表的な関連の全体像。

ドメイン登録(Route53 or 他社レジストラ)
        │ ネームサーバー設定
        ▼
      Route53 (ホストゾーン)
        │
        │ Aliasレコード / 各種レコード
        ├──────────────┬──────────────┬──────────────┐
        ▼              ▼              ▼              ▼
     ALB/NLB       CloudFront      S3(静的サイト)  API Gateway
        │              │
        │              └── ACM証明書(us-east-1固定)をアタッチ
        │
        └── ACM証明書(利用リージョン)をアタッチ

  ACM ──── 証明書検証用のCNAMEレコードを登録 ────▶ Route53

  SES ──── ドメイン検証用TXT/DKIM用CNAME/SPF・DMARC用TXT等を登録 ────▶ Route53

  ヘルスチェック ──▶ フェイルオーバールーティングでの切替に利用
                ──▶ CloudWatchアラームと連携し異常検知にも利用可能

ACMで発行した証明書は、発行時にRoute53へCNAMEレコードを追加してドメイン所有権を検証する。ホストゾーンがRoute53にある場合はコンソールから自動でレコードを追加できる。詳細はSSL証明書・ACMを参照。
SESのドメイン認証やDKIM、SPF/DMARCも同様にRoute53側へレコードを追加する形で連携する。
CloudFrontの詳しい構成パターン(Origin・Behavior・キャッシュ設定など)はCloudFrontの構成パターンを参照。

実践: よくある設定の流れ

ここまでの機能が実際にどう組み合わさって使われるか、具体的な手順に沿って整理する。

ホストゾーンを作成した直後の状態

パブリックホストゾーンを新規作成すると、レコードを1つも追加していない時点で自動的に2種類のレコードが生成されている。
- NSレコード(通常4件): そのドメインを管理するAWS側のネームサーバー群。外部レジストラでドメインを取得している場合、この4つを後述の手順でレジストラ側のネームサーバー設定に反映する必要がある。
- SOAレコード(1件): ゾーンの管理情報(プライマリネームサーバー、管理者連絡先、シリアル番号、TTLなど)。通常は自分で編集する必要はない。
この2つ以外のレコード(A/CNAME/MXなど)は、用途に応じて自分で追加していく必要がある。

外部ドメインをRoute53管理下に移す一連の流れ

Route53でホストゾーンを作成する(この時点で上記のNS/SOAレコードが自動生成される)。
生成されたNSレコードの値(4つのネームサーバー名)を確認する。
ドメインを取得した外部レジストラの管理画面で、ネームサーバーの設定を2で確認した4つに書き換える(外部で取得したドメインをRoute53で使うも参照)。
DNSの伝播を待つ(反映には数分〜数十時間かかることがある(?))。
切り替え前に主要なレコード(Aレコード等)をRoute53側へ用意しておかないと、ネームサーバー切り替え直後にそのレコードだけ引けず到達不能になる時間帯が生まれることがある(?)ため、事前に用意しておくのが安全。

ACM証明書を発行してALBにアタッチするまでの流れ

ACMで対象ドメイン(例: example.com、www.example.com)の証明書をリクエストする。
ACMが検証用のCNAMEレコード(名前・値ともにACMが自動生成するランダムな文字列)を提示する。
ホストゾーンがRoute53にある場合、ACMコンソールの「Route53でレコードを作成」ボタンを押すと2のCNAMEレコードが自動的に追加される(手動の場合は表示された名前・値をそのままコピーしてCNAMEレコードを作成する)。
DNSの反映後、ACM側が自動的にそのCNAMEレコードを検証し、証明書のステータスが「発行済み」になる。
ALBのリスナー(443)にこの証明書をアタッチする。
Route53側で、対象ドメインのAレコードをALB宛のAliasレコードとして作成する。

(IMO) 3〜4は自動で進むため体感的な作業はほぼ無い。「証明書がいつまでも発行済みにならない」場合は、まずこの検証用CNAMEレコードが正しく登録されているか、単にDNSの反映待ちなだけかを疑うとよい。

SESのドメイン認証の流れ

SESコンソールでドメインを追加すると、ドメイン検証用のトークンと、DKIM用の3つのトークンが発行される。
それぞれTXTレコード(ドメイン検証用)、CNAMEレコード×3(DKIM用)としてRoute53に登録する。
SES側の検証が完了すると、そのドメインからのメール送信が可能になる。

詳細はSESを参照。

This site is open source. Improve this page.