AWS中級 #5 Route 53 — ドメインと DNS

#4 RDS までで、バックエンドのコンピューティング / ストレージ / DB の場をひと通り掴みました。次はユーザーが私たちのシステムに最初に出会う場 — DNS です。AWS のマネージド DNS が Route 53 (TCP 53 ポートの DNS から命名)。

この記事では DNS の全体像 → Route 53 の形 → レコード種別 (特に Alias の場) → ルーティングポリシー → ヘルスチェックまで 1 本の線で通していきます。

DNS の場 — 5 秒復習 #

DNS は example.com → IP のマッピングを担うサービスです。ブラウザが example.com を打つと次が起きています。

1. ブラウザ: `example.com` キャッシュ確認 → なし
2. OS: `/etc/hosts` → なし
3. OS: システム DNS resolver (通常はルーター、または 1.1.1.1)
4. resolver: キャッシュ確認 → なし → root → .com TLD → example.com の NS
5. example.com の NS = Route 53 → A レコード → 192.0.2.10
6. 応答が逆順に戻りつつキャッシュ

この絵の 5 番、つまりドメインの権威 (authoritative) DNS が Route 53 です。

TTL の場 #

各レコードには TTL (Time To Live) が付いています — resolver / ブラウザがどれだけキャッシュするか。

TTL が長いと応答が速く費用も低いが 変更の伝搬が遅くなります。運用の cutover では TTL を事前に下げておく のが定石。

Route 53 の形 #

Route 53 の場は 4 つ:

ドメイン登録 vs Hosted Zone #

紛らわしい場。ドメインをどこで買ったか (Registrar) と DNS をどこで解くか (Hosted Zone) は 別物。

お名前 (Registrar):
  example.com の NS = ns-1234.awsdns-56.com  ← Route 53 NS を指定
                       ns-2345.awsdns-67.org
                       ns-3456.awsdns-78.net
                       ns-4567.awsdns-89.co.uk

Route 53 Hosted Zone:
  example.com.
    NS    ns-1234... (自動生成)
    SOA   ... (自動生成)
    A     www → 192.0.2.10
    A     api → 198.51.100.20

別所で買ったドメインを Route 53 に移す手順:

1. Route 53 で Public Hosted Zone を作成 — 自動で NS 4 つが付与される
2. その NS 4 つを Registrar コンソールの NS 欄に入力
3. 伝搬 (数分~24 時間)
4. dig / nslookup で確認

Hosted Zone の種類 #

Public Hosted Zone #

インターネットのどこからでも解ける DNS。最も一般的な使い方です。

aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference $(date +%s)

Private Hosted Zone #

VPC 内だけで 解ける DNS。内部サービスディスカバリに活用します。

内部ドメイン: api.internal.example.com → 10.0.10.100 (アプリ EC2)
              db.internal.example.com → RDS endpoint

VPC の EC2 だけ解け、インターネットでは解けません。社内マイクロサービスで活躍します。

レコード種別 #

A / AAAA — ドメインを IP に #

最も基本:

A     api.example.com.    300   192.0.2.10        (IPv4)
AAAA  api.example.com.    300   2001:db8::10      (IPv6)

CNAME — ドメインをドメインに #

別ドメインのエイリアス。

CNAME  www.example.com.    300   example.com.
CNAME  blog.example.com.   300   ghs.googlehosted.com.

制限:

• ルートドメイン (example.com 自身) には CNAME 不可 ← DNS 標準の制約
• CNAME があると 他のレコードと共存できない (MX、TXT 等)

ルートドメインを ALB / CloudFront に向けたい — CNAME 不可。ここで Alias が登場します。

Alias — Route 53 だけの場 #

Alias は Route 53 が作った非標準レコード — DNS 応答時には A / AAAA のように IP を返します。CNAME の制限を回避。

A   example.com.   ALIAS  d111111abcdef8.cloudfront.net    (CloudFront)
A   www.example.com. ALIAS my-alb-1234567890.elb.amazonaws.com  (ALB)
A   shop.example.com. ALIAS my-bucket.s3-website-ap-northeast-2.amazonaws.com (S3)

特徴:

• ルートドメインでも使用可
• 無料 (CNAME はクエリ単価で課金、Alias は AWS リソース指しなら無料)
• IP 自動更新 — ALB / CloudFront は IP が動的だが Alias が追従

Alias は AWS リソースだけ指せます (ALB、NLB、CloudFront、API Gateway、S3 website、同一 zone の他レコード等)。外部ドメインは CNAME を使う必要あり。

MX — メール #

MX  example.com.   300   10 inbound-smtp.us-east-1.amazonaws.com.
                          20 inbound-smtp.us-east-2.amazonaws.com.

10、20 は優先度 — 小さい値が優先。SES / Google Workspace / Microsoft 365 の SMTP ホストを指定します。

TXT — テキスト #

ドメイン検証 / SPF / DKIM 等。

TXT   example.com.   300   "v=spf1 include:_spf.google.com ~all"
TXT   _dmarc.example.com. 300  "v=DMARC1; p=quarantine; rua=mailto:..."
TXT   _acme-challenge.example.com. 300  "lemonjuice123..." (Let's Encrypt 検証)

NS / SOA — 自動 #

Hosted Zone 作成時に自動生成。ほぼ触りません。

CAA — 証明書発行権限 #

どの CA がこのドメインの証明書を発行できるかを制限。

CAA  example.com.  300  0 issue "amazon.com"

ACM (#6) で証明書を取るとき CAA が塞いでいると失敗するので注意。

ルーティングポリシー — Route 53 の真の魅力 #

同じドメインに 複数の IP を異なる条件で 応答できます。

1) Simple Routing #

最も単純。1 ドメイン → 1 / 複数 IP。複数なら round robin。

2) Weighted Routing — 比重分散 #

各レコードに 重み を付けて比率で分配。カナリアデプロイに魅力。

A   api.example.com   ALIAS   alb-v1.elb...   weight=90
A   api.example.com   ALIAS   alb-v2.elb...   weight=10

3) Latency Routing — 近い場へ #

複数リージョンに同じ場を立て、ユーザーを 最寄りリージョン にルーティング。

A   api.example.com   ALIAS   alb-seoul...   region=ap-northeast-2
A   api.example.com   ALIAS   alb-tokyo...   region=ap-northeast-1
A   api.example.com   ALIAS   alb-tokyo...   region=us-east-1

韓国ユーザー → ソウル、日本ユーザー → 東京、米国ユーザー → バージニア。

4) Failover Routing — 自動 failover #

Primary / Secondary の 2 つを置き、Primary が health check 失敗したら Secondary へ。

A   api.example.com   ALIAS   alb-prod-seoul...   PRIMARY   health-check=HC1
A   api.example.com   ALIAS   alb-dr-tokyo...     SECONDARY

5) Geolocation Routing — 国 / 大陸別 #

ユーザーの地理的位置 でルーティング。コンプライアンス / コンテンツ差分の場。

A   api.example.com   ALIAS   alb-kr...   geolocation=KR (Korea)
A   api.example.com   ALIAS   alb-jp...   geolocation=JP (Japan)
A   api.example.com   ALIAS   alb-default... geolocation=DEFAULT (それ以外)

6) Geoproximity Routing #

地理 + bias。AWS 内部アルゴリズムがより複雑 — ほぼ触りません。

7) Multivalue Answer Routing #

複数 IP をランダム応答。Health check と組み合わせて生きている IP のみ返す。シンプルなクライアント側負荷分散。

ポリシー決定ガイド #

1 つだけなら → Simple
配信比率を分けたい → Weighted
複数リージョンの近い方 → Latency
DR / バックアップ → Failover
国単位コンプライアンス → Geolocation
DNS 単位の負荷分散 → Multivalue

Health Check #

ルーティングポリシーの中心の相棒。エンドポイントが生きているか 30 秒ごとにチェック。

aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "api.example.com",
    "ResourcePath": "/health",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

種別:

• HTTP / HTTPS / TCP — エンドポイントを直接チェック
• Calculated — 他 health check の AND / OR 組み合わせ
• CloudWatch Alarm ベース — アラーム状態で判断

Health Check の場 #

• Failover ルーティング の自動切替トリガー
• Multivalue ルーティング の生きた IP フィルタ
• 単独でも使えるが、通常はルーティングポリシーと結合

ドメイン運用 — よく使うパターン #

1) メインサイト + サブドメイン #

A      example.com.        ALIAS   www.example.com.    (root → www)
A      www.example.com.    ALIAS   d111...cloudfront.net
A      api.example.com.    ALIAS   alb-prod...elb.amazonaws.com
A      app.example.com.    ALIAS   d222...cloudfront.net
TXT    _dmarc.example.com. "v=DMARC1; p=reject; ..."
MX     example.com.        10 inbound-smtp.ses-us-east-1.amazonaws.com.

2) 環境別の分離 #

api.dev.example.com       ← dev 環境 ALB
api.staging.example.com   ← staging
api.example.com           ← prod

または 別の Hosted Zone で dev.example.com を持つことも。権限委任がきれいになります。

3) Apex (ルート) ドメインの ALB / S3 #

CNAME が使えない場は Alias。ALB の zone は自動マッチング (コンソールでドロップダウン)。

費用 #

小さいサイトは月 $1~2 ほど。

よくハマる罠 #

1) NS を変更せずに Route 53 だけ触る #

Hosted Zone は作ったが Registrar の NS が依然旧設定 — 変更が一切反映されません。NS 4 つを Registrar に入力 したか確認。

dig NS example.com +short

2) Apex CNAME 試行 #

example.com CNAME myapp.heroku.com → 拒否される。Alias は AWS リソースのみ。外部の場 (Heroku 等) をルートドメインに置きたいなら そのサービスが ALIAS 系機能を提供する (例: CloudFlare CNAME flattening)、または別途リダイレクター (S3 redirect → Apex → www) パターン。

3) TTL が長すぎて cutover が遅い #

運用の cutover (例: ALB 入替) 直前は TTL を 60 秒程度に下げ、安定後にまた上げる。事前に下げておかないと旧 IP が 24 時間キャッシュされうる。

4) Health Check が false positive #

チェックパスが 認証を要求する場 だと常に 401 → unhealthy。/health のような 公開エンドポイント を用意。

5) Failover なのに health check を付けない #

PRIMARY レコードに health check がないと自動 failover しません。コンソールが “evaluate target health” の場を抜かす実装ミスがありがち。

6) DNSSEC 有効化して放置 #

DNSSEC の KSK / ZSK ローテーションを忘れるとドメイン解決自体が失敗。有効化は慎重に / 自動化と一緒に。

7) Private Hosted Zone の解決が VPC で動かない #

VPC の enableDnsHostnames / enableDnsSupport がオフだと Private Hosted Zone が解けません。両方 true を確認。

8) MX の優先度文法ミス #

MX 10 mail.example.com. で 10 の場を抜かすと解決自体が壊れる。

まとめ #

今回押さえたこと:

• Route 53 = AWS のマネージド DNS。Domain Registration / Hosted Zone / Health Check / Resolver の 4 つの場
• Domain Registrar ↔ Hosted Zone は別物。Registrar の NS を Route 53 NS に向けるのが起点
• Public Hosted Zone = インターネット解決、Private Hosted Zone = VPC 内のみ
• A / AAAA / CNAME / TXT / MX / NS / SOA / CAA が一般的なレコード
• Alias は Route 53 だけの場 — ルートドメインでも可、AWS リソース指しなら無料、IP 自動更新
• ルーティングポリシー 7 種 — Simple / Weighted / Latency / Failover / Geolocation / Geoproximity / Multivalue
• Health Check は Failover / Multivalue ルーティングの自動切替トリガー
• 運用パターン — 環境別サブドメイン / 別 Hosted Zone / Apex の Alias
• 罠 — NS 更新、Apex CNAME、TTL 大のまま cutover、health check false positive、Multi-AZ + Failover、Private Hosted Zone DNS オプション、MX 文法

次回 — ALB / NLB / ACM #

DNS の場は片付きました。次はそのドメインが指す場 — ロードバランサーと HTTPS へ続きます。

#6 ALB / NLB と ACM (HTTPS) では、ALB / NLB / GWLB の場の違い、Listener / Target Group / Health Check の流れ、ACM の証明書発行と自動更新、HTTPS の運用パターンを整理します。