Amazon Route 53 の DNS ルーティングとルーティングポリシー
Amazon Route 53 のドメイン管理、DNS レコード、名前解決の流れと、可用性や利用者の位置に応じて応答を変えるルーティングポリシーを学びます。
Route 53 が担う役割
Amazon Route 53 は、可用性と拡張性を備えたマネージド DNS サービスです。ドメイン名を登録・管理する機能、ドメインの DNS レコードを公開する権威 DNS 機能、エンドポイントの状態を調べるヘルスチェックなどを提供します。DNS の応答を通じて、利用者の接続先を AWS 上のリソースや、DNS で到達可能なオンプレミス環境のエンドポイントへ案内できます。
役割を混同しないために、DNS とアプリケーションの負荷分散を分けて考えます。Route 53 のルーティングポリシーは、名前解決時にどの名前や IP アドレスを返すかを決めます。DNS の応答を受け取った後、ELB は確立された接続を複数のターゲットへ振り分けます。DNS に複数の値が登録されていても、Route 53 が個々の HTTP リクエストを見て配分しているわけではありません。
ドメイン登録と DNS ホスティングも別の機能です。ドメインを登録した後、そのドメインの名前解決を Route 53 のホストゾーンで行うには、親側の委任情報がホストゾーンのネームサーバーを指すように設定します。Route 53 は複数のトップレベルドメインを扱いますが、登録できるドメインや条件はドメイン末尾によって異なります。
DNS レコードで名前と接続先を表す
ホストゾーンは、特定のドメインとその配下の名前について、権威を持つ DNS レコードをまとめる場所です。レコードの名前、タイプ、値を設定し、問い合わせられた名前に対してどの種類の情報を返すかを定義します。
代表的なレコードタイプは次のとおりです。
| レコード | 主な役割 |
|---|---|
| A | ホスト名に IPv4 アドレスを対応付ける |
| AAAA | ホスト名に IPv6 アドレスを対応付ける |
| CNAME | あるホスト名を別の正式な DNS 名の別名にする |
| MX | ドメイン宛てメールを受け取るメールサーバーと優先度を指定する |
| TXT | ドメイン検証や送信メールポリシーなどのテキスト情報を公開する |
| NS / SOA | ゾーンを担当するネームサーバーや、ゾーンの管理情報を表す |
Route 53 のエイリアスレコードは、AWS リソースや同じホストゾーン内の別レコードを参照する Route 53 独自の機能です。DNS 標準のレコードタイプとしての ALIAS があるわけではなく、レコードを A または AAAA として設定し、値の代わりにターゲットを選びます。AWS リソースをターゲットにした場合、IP アドレスが変わっても、そのリソースの現在のアドレスを Route 53 が評価して応答できます。AWS リソースへのエイリアスは Route 53 が対応する対象に限られ、任意の外部ドメイン名に向ける用途には CNAME を使います。
CNAME はドメイン名を別のドメイン名へ向けるレコードであり、IPv4 や IPv6 アドレスを直接保持しません。一方、エイリアスは Route 53 が対応する AWS リソースへ向けられます。AWS リソースの DNS 名を使いたい場合、特にゾーン頂点（例: kotori-market.jp 自体）に向ける場合はエイリアスが選択肢になります。ゾーン頂点には NS や SOA などのレコードも存在するため、CNAME を置く一般的な DNS の制約に触れずに AWS リソースへ接続できます。
DNS クエリが解決される流れ
ブラウザーや OS は通常、まず ISP や企業ネットワークなどの再帰 DNS リゾルバーへ問い合わせます。リゾルバーが答えをキャッシュしていれば、その結果が利用者へ返ります。キャッシュがなければ、ルート DNS サーバー、トップレベルドメイン（TLD）の DNS サーバー、対象ドメインの権威ネームサーバーへと問い合わせをたどります。権威サーバーが Route 53 のホストゾーンであれば、そのレコードとルーティングポリシーに基づく答えが返ります。
名前の例を store.kotori-market.jp とすると、.jp が TLD です。リゾルバーは最初にルートへ問い合わせ、.jp を担当するサーバーの情報を得ます。続いてそのサーバーから kotori-market.jp の権威ネームサーバー情報を得て、Route 53 の権威サーバーに store.kotori-market.jp のレコードを問い合わせます。Route 53 は要求されたレコードタイプに応じた値を返し、リゾルバーは TTL に従って応答をキャッシュし、利用者へ返します。利用者のブラウザーはその後、得られた接続先へ HTTPS などで接続します。
**TTL（Time to Live）**は、再帰リゾルバーが DNS 応答をキャッシュしてよい時間です。長い TTL は権威 DNS への問い合わせを減らしますが、レコードを変更した後も古い答えが使われる時間が長くなる可能性があります。短い TTL は新しい答えが参照されやすくなる反面、問い合わせ数が増える傾向があります。
ヘルスチェックとフェイルオーバーポリシーを組み合わせても、変更した応答がすべての利用者へ即時に届くとは限りません。リゾルバーやアプリケーションが既に得た応答をキャッシュし、既存の接続を維持することがあるためです。DNS による切り替えの速さは、ヘルス判定に加えて TTL やクライアントの挙動にも左右されます。
ルーティングポリシーで応答を選ぶ
同じ名前とレコードタイプに対して複数の応答候補を用意するとき、ルーティングポリシーによって Route 53 がどの値を返すかを決めます。選ぶべきポリシーは「比率を指定したい」「遅延を減らしたい」「障害時に待機先へ切り替えたい」など、応答を選ぶ条件によって異なります。
| ポリシー | 応答の選び方 | 要件の手がかり |
|---|---|---|
| シンプル | 特別な選択ルールを設けず、設定した値を返す。複数値を設定した場合はその値が応答に含まれる | 単一の接続先など、条件分岐が不要 |
| 加重（Weighted） | 各レコードに設定した重みに応じた割合で応答する | 段階的リリース、移行、複数環境への比率配分 |
| レイテンシー（Latency） | 利用者からの遅延が小さいと判定される AWS リージョンのレコードを選ぶ | 複数リージョンで応答遅延を抑えたい |
| 位置情報（Geolocation） | DNS クエリの発信元の地理的位置に合うレコードを選ぶ | 国や大陸に応じて異なる内容を返したい |
| 地理的近接性（Geoproximity） | 利用者とリソースの地理的な位置を基にし、バイアスで振り分け範囲を調整する | どの地域をどのリソースへ寄せるか調整したい |
| IP ベース（IP-based） | クエリ元の IP アドレスが属する CIDR 範囲に基づいてレコードを選ぶ | 特定の送信元ネットワークを特定の接続先へ案内したい |
| フェイルオーバー（Failover） | プライマリを通常時に使い、ヘルスチェックで異常と判断した場合にセカンダリを返す | アクティブ／パッシブ構成で障害時に切り替えたい |
| マルチバリュー（Multivalue answer） | 最大 8 件の正常なレコードをランダムに選んで返す | 複数の接続先を提示し、異常な値を応答から外したい |
比率と障害切り替え
加重ルーティングは、設定した重みを使って応答するレコードを選びます。たとえば新旧のアプリケーション環境を並行稼働させ、新しい環境への応答割合を段階的に増やす場合に使えます。重みは応答の割合を制御するものであり、実際の HTTP リクエスト数が厳密に同じ割合になる保証ではありません。DNS キャッシュや利用者側の再利用も影響します。
フェイルオーバールーティングはプライマリとセカンダリを定義し、ヘルスチェックなどの評価に応じて返す側を切り替えます。これは通常時に主系を使い、障害時に待機系へ誘導するアクティブ／パッシブ構成です。プライマリとセカンダリを同時に利用したい場合は、加重やレイテンシーなど別のポリシーを検討します。Route 53 が選ぶのは DNS の応答であり、待機系の起動やデータ同期を自動で代行するわけではありません。
利用者やリソースの地理に応じた応答
位置情報ルーティングは、DNS クエリの発信元を国、大陸、米国の州などの位置情報に対応付け、設定されたレコードを返します。たとえば国ごとに表示内容や提供するサービスが異なるときに使えます。問い合わせ元の位置を特定できない場合や一致するレコードがない場合に備え、既定の応答も設計します。既定のレコードがないと、Route 53 は該当クエリに答えを返しません。
位置情報に基づいて応答を変えることは、利用者の通信を拒否したり、攻撃を防いだりするアクセス制御ではありません。DNS 応答はキャッシュされ、別の DNS 名や IP アドレスを使った接続もあり得ます。提供地域外からのアクセス制限や攻撃対策には、アプリケーション、ファイアウォール、AWS WAF など別の制御を組み合わせます。
地理的近接性ルーティングは、DNS クエリの位置だけでなく、AWS リージョンや他のリソースの位置も考慮します。トラフィックフローで定義し、バイアスを使ってリソースへ寄せる範囲を広げたり狭めたりできます。位置情報は「問い合わせ元がどの地域か」で応答を決めるのに対し、地理的近接性は「問い合わせ元とリソースがどこにあり、どの範囲をそのリソースに担当させるか」を調整する点が異なります。
レイテンシールーティングは地図上の距離を直接比較する機能ではなく、利用者から AWS リージョンへの遅延情報に基づいて応答先を選びます。この遅延情報は利用者と AWS データセンター間の通信を基にしています。そのため、AWS リージョン以外にあるリソースの実際の遅延が、Route 53 の遅延情報と大きく異なることがあります。最も近い地理的位置にあるリソースと、最も低い遅延が見込まれるリージョンが常に一致するとは限りません。
送信元 IP と複数値の応答
IP ベースルーティングでは、クエリ元 IP の CIDR 範囲とレコードの対応関係を設定します。位置情報ポリシーが地理区分を条件にするのに対し、IP ベースでは IP アドレス範囲を条件に細かく定義します。クエリ元として見えるアドレスは利用者の端末そのものとは限らず、再帰リゾルバーのアドレスが基になることがあります。このポリシーはパブリックホストゾーンで利用でき、プライベートホストゾーンのレコードには設定できません。
マルチバリュー応答ルーティングは、1 回の DNS 応答で最大 8 件の正常な値を返し、関連付けたヘルスチェックが異常を示す値を候補から除外できます。応答の一部に異常なエンドポイントを混ぜないことは可用性に役立ちますが、接続後のリクエスト配分やセッション維持を行うロードバランサーではありません。また、ヘルスチェックのないレコードについて、Route 53 がアプリケーションの正常性を自動で判定するわけではありません。
試験での選び分けと設計上の注意
- 指定割合でリリースや移行を進めるなら 加重。
- プライマリの異常時に待機先へ誘導するなら フェイルオーバー。
- 低いネットワーク遅延を狙ってリージョンを選ぶなら レイテンシー。
- 国や大陸など問い合わせ元の地理で内容を変えるなら 位置情報。
- リソースと利用者の近接性を基に担当範囲を調整するなら 地理的近接性。
- IP アドレス範囲を基に明示的な経路を選ぶなら IP ベース。
- 複数の正常な値を返し、ヘルスチェックで異常値を除きたいなら マルチバリュー。
どのポリシーでも、DNS が決めるのは名前解決時に返す接続先です。実際の接続可否、リクエストの配分、認証、地域制限、攻撃防御はそれぞれの仕組みで設計します。また、ヘルスチェックで不健康と判定できても、DNS キャッシュや既存接続のために利用者全員が直ちに切り替わるとは限りません。
あわせて読む
公式ドキュメント
重要ポイント
- ▸Route 53 はドメイン登録、権威 DNS、ヘルスチェックを提供し、DNS 応答によって接続先の名前や IP アドレスを選ぶ
- ▸再帰リゾルバーがキャッシュにない名前をルート、TLD、権威ネームサーバーの順にたどり、TTL に従って結果を保持する
- ▸A / AAAA、CNAME、MX、TXT などの標準レコードと、AWS リソースを参照する Route 53 エイリアスを使い分ける
- ▸加重、レイテンシー、位置情報、地理的近接性、IP ベース、フェイルオーバー、マルチバリューは異なる条件で DNS 応答を選ぶ
- ▸位置情報ルーティングは通信を拒否する仕組みではなく、マルチバリューも ELB のような接続単位の負荷分散ではない
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
VPC とネットワーク に関連するトピックを続けて確認できます。