Route 53

Route 53 とは

Amazon Route 53 は、AWS のマネージド DNS サービスで、ドメイン登録、DNS ルーティング、ヘルスチェックを提供する。名前は DNS が使うポート番号 53 に由来する。

「100% の SLA」で知られるが、この数字が指す範囲は限定的だ。サービスコミットメントの対象は権威 DNS のホストゾーンで、月間稼働率が 100% を下回った場合にクエリ料金に対するサービスクレジットを請求できる、という取り決めである (2026 年 8 月時点)。ホストゾーンが「利用不可」と数えられるのも、割り当てられた 4 つの仮想ネームサーバーすべてが 1 分間すべてのクエリに応答しなかった場合に限られる。管理 API やコンソールの可用性は対象外なので、「絶対に止まらない」と読み替えてはいけない。

主な機能

Route 53 は DNS ホスティング (ドメインの DNS レコード管理)、ドメイン登録 (.com, .jp 等の購入)、ヘルスチェック (エンドポイントの死活監視)、ルーティングポリシー (トラフィックの振り分け) を提供する。

レコードタイプ

レコードタイプを以下にまとめる。

タイプ	用途	例
A	IPv4 アドレス	example.com → 1.2.3.4
AAAA	IPv6 アドレス	example.com → 2001:db8::1
CNAME	別ドメインへのエイリアス	www → example.com
Alias (A / AAAA の拡張)	AWS リソースへのエイリアス	example.com → CloudFront
MX	メールサーバー	mail.example.com
TXT	テキスト情報	SPF, DKIM, ドメイン検証

Alias は DNS 標準のレコードタイプではなく、A / AAAA などのレコードに Route 53 が独自に付ける拡張である。CNAME との違いは 4 点ある (2026 年 8 月時点)。

• Zone Apex (ネイキッドドメイン example.com) に設定できる。CNAME は apex に作れない。ただし apex から同一ホストゾーン内の CNAME タイプのレコードへ向ける構成は、Alias でも作れない。
• AWS リソースへの Alias クエリには課金されない。CNAME は課金され、別のレコード名へ向けた CNAME は解決に 2 回の問い合わせが要るため 2 クエリ分として数えられる。
• TTL を自分で指定できない。向き先が AWS リソースならそのリソースの既定値、同一ホストゾーン内のレコードなら対象レコードの TTL が使われる。
• 向き先リソースの IP アドレスが入れ替わっても Route 53 が追従する。ロードバランサーや CloudFront の IP を自分で追いかける必要がない。

向き先にできるのは選ばれた AWS リソースと、同一ホストゾーン内の同タイプのレコードだけである。他社 DNS 上の名前へ向けたい場合は CNAME を使う。

ルーティングポリシー

レコード作成時に選ぶルーティングポリシーは 8 種類ある (2026 年 8 月時点)。

ポリシー	応答の決め方	用途
シンプル	単一の向き先をそのまま返す	通常の DNS
加重	指定した重みの比率で振り分ける	カナリアリリース・段階移行
フェイルオーバー	プライマリが異常ならセカンダリを返す	障害時の退避
レイテンシー	問い合わせ元から最も低レイテンシーのリージョンを返す	マルチリージョン
位置情報	問い合わせ元の国・地域で振り分ける	地域別の出し分け
地理的近接性	リソースの所在地との距離で選び、バイアス値で寄せ幅を調整する	拠点間のトラフィック配分
IP ベース	問い合わせ元 IP の CIDR ブロック単位で振り分ける	特定ネットワークの経路指定
複数値回答	正常なレコードを最大 8 件ランダムに返す	簡易な分散

混同しやすいのは位置情報と地理的近接性である。位置情報は「利用者がどこにいるか」を条件に振り分ける。地理的近接性は「リソースがどこにあるか」を起点に距離で選び、バイアス値で特定拠点への寄せ幅を人が調整する。待機している拠点へ少しだけ寄せる、といった制御は後者でしか書けない。

位置情報・地理的近接性・IP ベースの判定材料になるのは、問い合わせを中継したリゾルバから届く情報である。リゾルバがクライアントのサブネットを伝えてくれば利用者に近い判定になるが、伝えてこない場合はリゾルバ自身の位置で判定される。公開リゾルバや社内リゾルバを経由する利用者では所在地とずれるため、地域別の出し分けを厳密な制御と考えてはいけない。

ヘルスチェックの仕組み

ヘルスチェックには 3 種類ある。エンドポイントを直接監視するもの、他のヘルスチェックの結果を集計するもの (計算ヘルスチェック・子は 255 個まで)、CloudWatch アラームを監視するものである。

エンドポイント監視は世界各地のヘルスチェッカーから 10 秒間隔または 30 秒間隔でリクエストを送る。チェッカー同士は同期していないため、間隔を 30 秒にしていても実際には 1 秒間に複数回届いたり、数秒間まったく来なかったりする。判定は単純な多数決ではなく、正常と報告したチェッカーが 18 % を超えていれば正常とみなす。一部の地域からネットワーク的に孤立しただけで異常と判定されるのを避けるための設計である。

HTTP / HTTPS では 4 秒以内に TCP 接続が確立し、接続後 2 秒以内に 2xx か 3xx が返る必要がある。TCP チェックは接続確立まで 10 秒。応答本文の文字列一致まで行う場合は、探す文字列が本文の先頭 5,120 バイト以内に収まっていなければ失敗する (以上は 2026 年 8 月時点の値)。

落とし穴が 3 つある。1 つ目は HTTPS のヘルスチェックが証明書を検証しないこと。期限切れや不正な証明書でもヘルスチェックは通るので、証明書の期限は別の手段で監視する。2 つ目は CloudWatch アラーム型がアラームの状態ではなくデータストリームを見ていること。データが足りない期間をどう扱うかは設定で選ぶ。3 つ目は作成直後のヘルスチェックが、判定材料が揃うまで正常として扱われること。切り替え試験のたびにここで取り違えが起きる。監視項目そのものの設計は ヘルスチェックパターン を参照。

フェイルオーバールーティング

動作を図で示す。

Route 53
  ├── プライマリ: ALB (ap-northeast-1) ← ヘルスチェック OK
  └── セカンダリ: S3 静的サイト (sorry ページ)

プライマリのヘルスチェック失敗 → セカンダリに自動切り替え

フェイルオーバー が動くには、レコードにヘルスチェックを関連付けておく必要がある。関連付けを忘れると異常時もプライマリを返し続ける。切り替わりといっても DNS の応答が変わるだけなので、リゾルバやクライアントが TTL の間は古い答えを保持し続ける分の遅れが出る。しかも Alias で AWS リソースを指している場合の TTL は対象リソースの既定値に従い、自分で短くすることはできない。数十秒から数分の空白は避けられないものと考え、セカンダリ側を「案内だけは出せる最小構成」にしておくのが現実的な設計になる。

CloudFront + Route 53

CloudFront + Route 53 を図で示す。

ユーザー → Route 53 (DNS) → CloudFront (CDN) → S3 / ALB

Route 53 の Alias レコードで CloudFront ディストリビューションを指定するのが標準構成。

Route 53 の設定を難しくするのは、機能の多さよりも DNS がキャッシュ前提の仕組みだという点にある。ポリシーやヘルスチェックで「どう答えるか」は細かく決められるが、答えが行き渡る速さは TTL とリゾルバ側の都合に握られている。秒単位の切り替えが要件なら DNS だけで解こうとせず、ロードバランサーや CDN 層での振り替えと組み合わせて考えたい。