Amazon Route 53 ベストプラクティス

Amazon Route 53 を安全かつ高可用に運用するための設計・運用上のポイントをまとめたものです。

目次

  1. ホストゾーン設計
  2. レコード設計
  3. TTL の設計
  4. ヘルスチェックとフェイルオーバー
  5. ルーティングポリシーの使い分け
  6. 高可用性・レジリエンス
  7. セキュリティ
  8. プライベート DNS と Resolver
  9. ドメイン登録
  10. IaC と変更管理
  11. 監視とロギング
  12. コスト最適化
  13. チェックリスト

1. ホストゾーン設計

  • 環境ごとにゾーンを分離する
    • 例: example.com（本番）、dev.example.com / stg.example.com（サブドメインを委任）
    • サブドメインのホストゾーンを各環境の AWS アカウントに置き、親ゾーンから NS レコードで委任すると、権限と影響範囲を分離できる。
  • マルチアカウント構成では委任を活用する
    • 親ゾーンはネットワーク／共有サービスアカウントで一元管理し、子ゾーンは各ワークロードアカウントに配置する。
  • パブリックとプライベートでスプリットホライズン DNS を使う
    • 同じドメイン名でパブリックホストゾーンとプライベートホストゾーンを作り、VPC 内外で異なる応答を返せる。内部向けエンドポイントを外部に露出させない。
  • 不要なホストゾーンを放置しない
    • 使われていないゾーンは月額課金が発生し、委任が残っているとサブドメインテイクオーバーの温床になる。
  • 再利用可能な委任セット（Reusable Delegation Set）を検討する
    • 多数のゾーンで同じネームサーバーを使いたい場合（ホワイトラベル DNS など）に有効。

2. レコード設計

  • AWS リソースには Alias レコードを使う
    • ALB / NLB、CloudFront、API Gateway、S3 静的ウェブサイト、Global Accelerator、同一ゾーン内の他レコードなどに対応。
    • Alias へのクエリは無料、ゾーンの頂点（Zone Apex、例: example.com）にも設定可能、リソースの IP 変更に自動追従する。
    • Zone Apex に CNAME は設定できないため、Apex には Alias を使う。
  • Evaluate Target Health を有効にする
    • Alias 先（ELB など）のヘルス状態をフェイルオーバー判定に利用できる。
  • ダングリングレコードを残さない
    • 削除済みの S3 バケット、Elastic IP、CloudFront ディストリビューションなどを指すレコードは、第三者による乗っ取り（サブドメインテイクオーバー）のリスクがある。リソース削除時にはレコードも削除する。
  • メール関連レコードを整備する
    • SPF（TXT）、DKIM（CNAME/TXT）、DMARC（TXT）、MX を正しく設定する。メールを送信しないドメインでも v=spf1 -all と DMARC p=reject を設定してなりすましを防ぐ。
  • CAA レコードを設定する
    • 証明書を発行できる認証局を制限する（例: 0 issue "amazon.com"）。
  • 命名規則を統一する
    • <サービス>.<環境>.<リージョン>.example.com のように、用途が分かる規則を決めておく。

3. TTL の設計

用途推奨 TTL の目安理由
フェイルオーバー対象のレコード60 秒程度切り替えを素早くクライアントに反映するため
通常の A / CNAME300 秒〜3600 秒クエリ数（コスト）とキャッシュ効率のバランス
NS / MX など変更頻度の低いレコード3600 秒〜172800 秒安定性とクエリ削減
Alias レコード設定不可参照先の TTL が使われる
  • 変更・移行の前に TTL を下げる
    • 移行作業の数日前（現在の TTL 以上の時間前）に TTL を短くし、作業後に元へ戻す。
  • 短すぎる TTL はコストとレイテンシを増やす
    • クエリ課金は件数ベースのため、必要以上に短くしない。
  • NS レコードの TTL に注意する
    • ネームサーバー変更時は、親ゾーン（TLD）側の NS の TTL も考慮する（最大 2 日程度の反映遅延がありうる）。

4. ヘルスチェックとフェイルオーバー

  • ヘルスチェックの種類を使い分ける
    • エンドポイント監視（HTTP/HTTPS/TCP）
    • 他のヘルスチェックの監視（計算済みヘルスチェック：複数条件の AND/OR）
    • CloudWatch アラームの監視（プライベートリソースやメトリクスベースの判定に有効）
  • アプリケーションの実際の健全性を反映するエンドポイントを使う
    • /health のような軽量パスを用意し、依存先（DB など）の状態も考慮する。ただし依存先の一時的障害で全リージョンが同時に unhealthy にならないよう設計する。
  • 文字列一致（String matching）で誤判定を防ぐ
    • ステータスコード 200 だけでなく、レスポンス本文の内容も確認する。
  • しきい値と間隔を適切に設定する
    • 標準 30 秒 / 高速 10 秒間隔、失敗しきい値（デフォルト 3）を要件に合わせて調整する。
  • ヘルスチェッカーの IP を許可する
    • ファイアウォールやセキュリティグループで Route 53 ヘルスチェッカーの IP レンジ（ip-ranges.json の ROUTE53_HEALTHCHECKS）を許可する。
  • プライベートリソースは CloudWatch アラーム経由で監視する
    • Route 53 ヘルスチェッカーはインターネット経由のため、VPC 内リソースを直接チェックできない。
  • フェイルオーバーを定期的にテストする
    • ゲームデーなどで実際に切り替えが機能するかを確認する。

5. ルーティングポリシーの使い分け

ポリシー主な用途
シンプル単一リソース向け。ヘルスチェック不可
フェイルオーバーアクティブ／パッシブ構成の DR
加重（Weighted）Blue/Green、カナリアリリース、段階的な移行
レイテンシーマルチリージョンで最も低レイテンシなリージョンへ誘導
位置情報（Geolocation）国・大陸単位での振り分け、コンテンツのローカライズ、規制対応
地理的近接性（Geoproximity）バイアスを付けた距離ベースの振り分け
複数値回答（Multivalue）最大 8 件の健全なレコードを返す簡易的な負荷分散
IP ベースクライアントの CIDR に基づく振り分け（ISP 単位の最適化など）
  • ポリシーはネスト（組み合わせ）できる
    • 例: レイテンシー（リージョン選択）→ 加重（リージョン内の Blue/Green）→ フェイルオーバー。
    • 複雑な構成は Traffic Flow（トラフィックポリシー）で可視化・バージョン管理できる（ただしポリシーレコードごとに課金あり）。
  • 位置情報ルーティングにはデフォルトレコードを必ず用意する
    • 該当地域がないクエリに応答できず NXDOMAIN 相当の応答（NODATA）になるのを防ぐ。
  • 加重ルーティングで重み 0 を活用する
    • 全レコードの重みが 0 の場合は均等に振り分けられる点に注意。

6. 高可用性・レジリエンス

  • データプレーンに依存し、コントロールプレーンに依存しない設計にする
    • Route 53 のデータプレーン（DNS 応答・ヘルスチェック）は非常に高い可用性を持つ一方、コントロールプレーン（レコード変更 API）は特定リージョンに依存する。
    • 障害時に「レコードを書き換えて切り替える」手順ではなく、事前に設定したヘルスチェック／フェイルオーバーで自動的に切り替わる設計にする。
  • Route 53 Application Recovery Controller（ARC）を検討する
    • ルーティングコントロールにより、データプレーン経由でトラフィックを手動切り替えでき、安全ルールで誤操作も防げる。厳しい RTO が求められるマルチリージョン構成に有効。
  • アクティブ／アクティブ構成ではキャパシティを確保する
    • 片方のリージョンが落ちたときに残りで全トラフィックを処理できるか確認する。
  • フェイルオーバー先が静的な S3 サイトや CloudFront の「メンテナンスページ」でもよい
    • 完全な DR が難しい場合でも、最低限のユーザー体験を確保できる。

7. セキュリティ

  • IAM で最小権限を徹底する
    • route53:ChangeResourceRecordSets を特定ホストゾーンに限定する。
    • 条件キー（route53:ChangeResourceRecordSetsNormalizedRecordNames、route53:ChangeResourceRecordSetsRecordTypes、route53:ChangeResourceRecordSetsActions）でレコード名・タイプ・操作単位まで制限できる。
  • DNSSEC 署名を有効にする
    • パブリックホストゾーンで DNSSEC 署名を有効化し、親ゾーンに DS レコードを登録する。
    • KSK は KMS のカスタマー管理キー（us-east-1、ECC_NIST_P256）で管理される。キーの削除・無効化はゾーン全体の名前解決不能につながるため、KMS キーポリシーで削除を厳しく制限する。
    • DNSSECInternalFailure と DNSSECKeySigningKeysNeedingAction の CloudWatch アラームを設定する。
  • VPC 側で DNSSEC 検証を有効にする
    • Route 53 Resolver の DNSSEC 検証を有効化し、改ざんされた応答を拒否する。
  • Route 53 Resolver DNS Firewall を使う
    • 既知の悪性ドメインへの名前解決をブロックし、DNS 経由のデータ流出を防ぐ。AWS マネージドドメインリストを活用する。
    • 厳格な環境では許可リスト方式（必要なドメインだけ許可）も検討する。
  • ドメイン登録をロックする
    • 登録ロック（Transfer Lock）を有効化し、不正な移管を防ぐ。
  • サブドメインテイクオーバー対策を行う
    • 定期的にレコードを棚卸しし、存在しないリソースを指すレコードを削除する（AWS Config や自前スクリプトで検出）。
  • 変更を CloudTrail で監査する
    • レコード変更 API の呼び出しを記録し、重要ゾーンの変更はアラート対象にする。

8. プライベート DNS と Resolver

  • プライベートホストゾーンの VPC 関連付けを適切に管理する
    • マルチアカウントでは、別アカウントの VPC 関連付け（承認 → 関連付け）を使う。
    • VPC の enableDnsHostnames と enableDnsSupport を有効にしておく。
  • Route 53 Profiles で設定を一元配布する
    • プライベートホストゾーン、Resolver ルール、DNS Firewall ルールグループなどの DNS 設定をまとめ、RAM で複数アカウント・VPC に共有できる。多数の VPC を持つ組織では管理負荷を大きく下げられる。
  • ハイブリッド DNS は Resolver エンドポイントで構成する
    • インバウンドエンドポイント：オンプレミス → AWS の名前解決
    • アウトバウンドエンドポイント + 転送ルール：AWS → オンプレミスの名前解決
    • エンドポイントは複数 AZ に ENI を配置し冗長化する。
    • 共有サービス VPC にエンドポイントを集約し、転送ルールを RAM で共有するハブ＆スポーク構成が一般的。
  • Resolver エンドポイントのキャパシティに注意する
    • ENI あたりの処理クエリ数に上限があるため、InboundQueryVolume / OutboundQueryVolume メトリクスを監視し、必要に応じて ENI を追加する。
  • VPC の DNS クエリ上限を意識する
    • EC2 インスタンスの ENI ごとに Resolver へのクエリ数上限（1 秒あたり 1024 パケット）がある。大量クエリが発生するワークロードではローカルキャッシュ（例: systemd-resolved、dnsmasq、nscd）を利用する。

9. ドメイン登録

  • 自動更新を有効にする
    • 期限切れによるサービス停止・ドメイン喪失を防ぐ。
  • 連絡先情報を最新に保ち、プライバシー保護を有効にする
    • WHOIS 上の個人情報を非公開にする（TLD が対応している場合）。
  • ドメイン登録用アカウントを分離する
    • ドメイン登録は Organizations の管理アカウント以外の、アクセスを絞った専用アカウントで行うと安全。
  • ネームサーバーの不一致に注意する
    • ホストゾーンを作り直した場合、登録ドメイン側の NS とホストゾーンの NS が一致しているか必ず確認する。

10. IaC と変更管理

  • レコードはコードで管理する
    • CloudFormation、Terraform、AWS CDK などを使い、レビューと履歴管理を行う。
  • 重要ゾーンは削除保護を考慮する
    • CloudFormation の DeletionPolicy: Retain、Terraform の prevent_destroy などで誤削除を防ぐ。
  • 変更は小さく、段階的に行う
    • 加重ルーティングで少量のトラフィックから新環境へ移行する。
  • 変更の伝播を確認する
    • ChangeResourceRecordSets の結果が INSYNC になったことを GetChange で確認してから次の作業に進む。
  • 手動変更を防ぐ
    • 本番ゾーンへのコンソール操作を IAM / SCP で制限し、ドリフトを防ぐ。
  • ゾーンを定期的にバックアップする
    • ListResourceRecordSets でエクスポートし、S3 などに保存しておく。

11. 監視とロギング

  • パブリック DNS クエリログ
    • CloudWatch Logs に出力（ロググループは us-east-1 に作成する必要がある）。不審なクエリの調査やトラフィック分析に利用する。
  • Resolver クエリログ
    • VPC 内からの DNS クエリを CloudWatch Logs / S3 / Kinesis Data Firehose に出力する。セキュリティ調査や DNS Firewall のチューニングに有効。
  • ヘルスチェックの CloudWatch アラーム
    • HealthCheckStatus を監視し、SNS で通知する（ヘルスチェックのメトリクスは us-east-1）。
  • Amazon GuardDuty を有効にする
    • DNS ログを分析し、C&C 通信や暗号資産マイニングなどの脅威を検出する。
  • CloudTrail で変更を監査する
    • Route 53 はグローバルサービスのため、API イベントは us-east-1 に記録される。

12. コスト最適化

  • Alias レコードを優先する
    • AWS リソースを指す Alias へのクエリは無料。
  • TTL を必要以上に短くしない
    • クエリ件数の削減につながる。
  • 不要なホストゾーン・ヘルスチェックを削除する
    • どちらも月額課金が発生する。
  • ヘルスチェックのオプション機能を必要な場合にだけ使う
    • HTTPS、文字列一致、高速間隔、レイテンシー測定などは追加料金がかかる。
  • Traffic Flow のポリシーレコードは必要性を検討する
    • ポリシーレコードあたりの月額料金が比較的高いため、単純な構成なら通常のレコードで十分。
  • Resolver エンドポイントは集約する
    • ENI 単位で時間課金されるため、共有サービス VPC に集約して共有する。

13. チェックリスト

設計

  • 環境・アカウントごとにホストゾーンを分離し、サブドメイン委任を使っている
  • AWS リソースには Alias レコードを使っている
  • Zone Apex に CNAME を使っていない
  • TTL が用途に合わせて設定されている
  • 位置情報ルーティングにデフォルトレコードがある

可用性

  • 重要なエンドポイントにヘルスチェックとフェイルオーバーを設定している
  • 障害時の切り替えがコントロールプレーンに依存していない
  • フェイルオーバーを定期的にテストしている

セキュリティ

  • IAM で変更権限をホストゾーン・レコード単位に絞っている
  • DNSSEC 署名を有効化し、関連アラームを設定している
  • DNS Firewall で悪性ドメインをブロックしている
  • ドメインの登録ロックと自動更新を有効にしている
  • ダングリングレコードを定期的に棚卸ししている
  • CAA / SPF / DKIM / DMARC を設定している

運用

  • レコードを IaC で管理している
  • クエリログ・Resolver クエリログを有効にしている
  • CloudTrail と GuardDuty を有効にしている
  • 不要なホストゾーン・ヘルスチェックを削除している

参考資料

0件のページ

    バックリンク