翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Route 53 のベストプラクティス
このセクションでは、以下を含む Amazon Route 53 のさまざまなコンポーネントのベストプラクティスについて説明します。
1. **DNS ベストプラクティス:**
+ Time to Live (TTL) 値と、応答性と信頼性のトレードオフを理解します。
+ パフォーマンス向上とコスト削減のために、可能な限り CNAME レコードの代わりにエイリアスレコードを使用します。
+ デフォルトのルーティングポリシーを設定して、すべてのクライアントがレスポンスを受け取れるようにします。
+ レイテンシーベースのルーティングを活用し、アプリケーションのレイテンシーおよび位置情報/地理的近接性ルーティングを最小限に抑えて、安定性と予測可能性を高めます。
+ 自動ワークフロー用の `GetChange` API を使用して、変更の伝播を検証します。
+ 一貫したルーティングのために親ゾーンからサブドメインを委任します。
+ 複数値回答ルーティングを使用して、大規模な単一レスポンスを回避します。
1. **リゾルバーのベストプラクティス:**
+ Resolver ルールとそのインバウンドエンドポイントの両方に同じ VPC を関連付けないようにすることで、ルーティングループを防止します。
+ セキュリティグループルールを実装し、接続追跡のオーバーヘッドを減らして、クエリスループットを最大化します。
+ 冗長性を確保するために、複数のアベイラビリティーゾーンに IP アドレスを持つインバウンドエンドポイントを設定します。
+ 潜在的な DNS ゾーンウォーキング攻撃に注意し、エンドポイントでスロットリングが発生した場合は AWS サポートにお問い合わせください。
1. **ヘルスチェックのベストプラクティス:**
+ Amazon Route 53 のヘルスチェックを最適化するための推奨事項に従って、リソースを確実にモニタリングします。
これらのベストプラクティスに従うことで、DNS インフラストラクチャのパフォーマンス、信頼性、セキュリティを最適化し、アプリケーションやサービスへのトラフィックの効率的かつ効果的なルーティングを実現できます。
**Topics**
+ [Amazon Route 53 DNS のベストプラクティス](best-practices-dns.md)
+ [VPC Resolver のベストプラクティス](best-practices-resolver.md)
+ [Amazon Route 53 ヘルスチェックのベストプラクティス](best-practices-healthchecks.md)
# Amazon Route 53 DNS のベストプラクティス
Amazon Route 53 DNS サービスを使用するときに最良の結果が得られるようにするには、以下のベストプラクティスに従ってください。
**DNS フェイルオーバーとアプリの回復にデータプレーン機能を使用してください**
ヘルスチェックを含む Route 53 のデータプレーンと Amazon アプリケーション回復コントローラー (ARC) のルーティングコントロールは、グローバルに分散されており、重大なイベント中でも 100% の可用性と機能性を実現するように設計されています。これらは互いに統合され、コントロールプレーンの機能に依存しません。コンソールを含むこれらのサービスのコントロールプレーンは、一般的に非常に信頼性が高いですが、より一元化された方法で設計されており、高可用性よりも耐久性と一貫性が優先されます。ディザスタリカバリ時のフェイルオーバーなどのシナリオでは、DNS を更新するためにデータプレーン機能を利用する、Route 53 のヘルスチェックや ARC のルーティング制御などの機能の使用をお勧めします。詳細については、「[コントロールプレーンとデータプレーンの概念](route-53-concepts.md#route-53-concepts-control-and-data-plane)」、および「[Creating Disaster Recovery Mechanisms Using Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)」(ブログ: Amazon Route 53 を使用した災害回復メカニズムの作成) を参照してください。
**DNS レコードの TTL 値の選択**
DNS TTL とは、Route 53 に対してさらなるクエリを行わずにレコードをキャッシュできる期間を決定するために DNS リゾルバーが使用する数値 (秒単位) です。すべての DNS レコードには TTL が指定されている必要があります。TTL 値の推奨範囲は 60 ～ 172,800 秒です。
TTL の選択は、レイテンシーと信頼性、および変化に対する応答性との間のトレードオフです。レコードの TTL が短くなると、DNS リゾルバーはより頻繁にクエリを実行する必要があるため、レコードの更新が速くなります。これにより、クエリのボリューム (およびコスト) が増大します。TTL を長くすると、DNS リゾルバーはキャッシュからのクエリに頻繁に応答します。これは通常、高速で、安価で、場合によってはインターネットを介したクエリを回避するため信頼性が高くなります。絶対的に正しい値は存在せず、応答性と信頼性のどちらがより重要であるかを考える価値はあります。
TTL 値を設定する際に考慮すべき事項:
+ 変更が有効になるのを待つ余裕があれば、DNS レコード TTL を設定します。これは、委任 (NS レコードセット) や、MX レコードなど、ほとんど変更されない他のレコードで特に当てはまります。これらのレコードでは、より長い TTL が推奨されます。一時間 (3600 秒) から 1 日 (86,400 秒) の間が一般的な数値です。
+ 高速フェールオーバーメカニズム (特にヘルスチェックされるレコード) の一部として変更する必要があるレコードについては、TTL を下回るのが適切です。このシナリオでは、TTL を 60 秒または 120 秒に設定するのが一般的です。
+ 重要な DNS エントリに変更を加える場合、TTL を一時的に短くすることをお勧めします。そうすれば、必要に応じてすばやく変更、監視、ロールバックを行うことができます。変更が確定し、期待どおりに機能した後、TTL を長くすることができます。
詳しくは、「[TTL (秒)](resource-record-sets-values-shared.md#rrsets-values-common-ttl) 」を参照してください。
**CNAME レコード**
DNS 内の CNAME レコードは、あるドメイン名を別のドメイン名でポイントする手段になります。DNS リゾルバーが domain-1.example.com を解決し、domain-2.example.com を指している CNAME が見つかった場合、DNS リゾルバーは応答する前に domain-2.example.com を解決する必要があります。これらのレコードは、例えば、ウェブサイトに複数のドメイン名がある場合に一貫性を保つためなど、多くの状況で役立ちます。
ただし、DNS リゾルバーは CNAME に応答するために、より多くのクエリを作成する必要があり、レイテンシーとコストが増加します。可能であれば、Route 53 エイリアス レコードを使用するのが高速かつ安価な代替手段です。エイリアスレコードにより、Route 53 は AWS リソース (ロードバランサーなど) および同じホストゾーン内の他のドメインに対して直接応答できます。
詳細については、「[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)」を参照してください。
**高度な DNS ルーティング**
+ 位置情報、地理的近接性またはレイテンシーベースのルーティングを使用する場合は、一部のクライアントが*回答なし*のレスポンスを受信できるようにする場合を除き、常にデフォルトを設定します。
+ アプリケーションのレイテンシーを最小限に抑えるには、レイテンシーベースのルーティングを使用します。このタイプのルーティングデータは頻繁に変更されることがあります。
+ ルーティングの安定性と予測可能性を確保するには、位置情報ルーティングまたは地理的近接性ルーティングを使用します。
詳細については[位置情報ルーティング](routing-policy-geo.md)、[地理的近接性ルーティング](routing-policy-geoproximity.md)、および[レイテンシーに基づくルーティング](routing-policy-latency.md)を参照してください。
**DNS 変更の伝播**
Route 53 コンソールまたは API を使用して、レコードやホストゾーンを作成または更新する場合、変更内容がインターネット上に反映されるまでにしばらく時間がかかります。これは*変更の伝播*と呼ばれます。通常、伝播はグローバルに 1 分未満で到達しますが、例えば、1 つのロケーションへの同期の問題や、まれに中央コントロールプレーン内の問題など、変更に時間がかかることがあります。自動プロビジョニングワークフローを構築している場合、またはD次のワークフローステップに進む前に、変更の伝播が完了するのを待つことが重要です。DNS の変更が反映されたこと (`Status =INSYNC`) を確認するために、[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API を使用します。
**DNS の委任**
DNS で複数のレベルのサブドメインを委任する場合、常に親ゾーンから委任することが重要です。たとえば、委任している場合www.dept.example.comとすると、example.comゾーンからではなくdept.example.comゾーンからそのようにすべきです。*祖父母*から*子*ゾーンへ委任すると、一切機能しないか、動作することもありますがそれは偶然に過ぎません。詳しくは、「[サブドメインのトラフィックのルーティング](dns-routing-traffic-for-subdomains.md) 」を参照してください。
**DNS レスポンスのサイズ**
大きなシングルレスポンスの作成は避けてください。512 バイトを超えると、多くの DNS リゾルバーは UDP ではなく TCP で再試行する必要があります。これにより、レスポンスが遅くなり、信頼性が低下する可能性があります。レスポンスを 512 バイトの限度内に保つために、8 個の健全でランダムな IPアドレス を選択する複数値のアンサールーティングを使用するようお勧めします。
詳細については、「[複数値回答ルーティング](routing-policy-multivalue.md)」および「[DNS Reply Size Test Server](https://www.dns-oarc.net/oarc/services/replysizetest/)」を参照してください。
# VPC Resolver のベストプラクティス
このセクションでは、Amazon Route 53 VPC Resolver を最適化するためのベストプラクティスと、以下のトピックについて説明します。
1. **Resolver エンドポイントとのループ構成を防ぐ:**
+ 同じ VPC が Resolver ルールとそのインバウンドエンドポイントの両方に関連付けられないようにすることで、ルーティングループを防止します。
+ 適切なルーティング設定を維持しながら AWS RAM 、 を使用してアカウント間で VPCs を共有します。
詳細については、[Resolver エンドポイントとのループ構成を防ぐ](best-practices-resolver-endpoints.md)を参照してください。
1. **Resolver エンドポイントのスケーリング:**
+ 接続状態に基づいてトラフィックを許可するセキュリティグループルールを実装して、接続追跡のオーバーヘッドを削減する
+ インバウンドおよびアウトバウンドの Resolver エンドポイントの推奨されるセキュリティグループルールに従って、クエリスループットを最大化します。
+ 容量が制限されないように、DNS トラフィックを生成する一意の IP アドレスとポートの組み合わせを監視します。
詳細については、[Resolver エンドポイントのスケーリング](best-practices-resolver-endpoint-scaling.md)を参照してください。
1. **Resolver エンドポイントの高可用性:**
+ 冗長性を確保するために、少なくとも 2 つのアベイラビリティーゾーンに IP アドレスを持つインバウンドエンドポイントを指定します。
+ メンテナンスやトラフィックの急増時に可用性を確保するための追加のネットワークインターフェイスをプロビジョニングする
詳細については、[Resolver エンドポイントの高可用性](best-practices-resolver-endpoint-high-availability.md)を参照してください。
1. **DNS ゾーンウォーキング攻撃の防止:**
+ 攻撃者が DNSSEC 署名付き DNS ゾーンからすべてのコンテンツを取得しようとする潜在的な DNS ゾーンウォーキング攻撃に注意してください。
+ ゾーンウォーキングが疑われるためにエンドポイントでスロットリングが発生した場合は、 AWS サポートにお問い合わせください。
詳細については、[DNS ゾーンウォーキング](best-practices-resolver-zone-walking.md)を参照してください。
これらのベストプラクティスに従うことで、VPC Resolver デプロイのパフォーマンス、スケーラビリティ、セキュリティを最適化し、アプリケーションとリソースの DNS 解決の信頼性と効率性を確保できます。
# Resolver エンドポイントとのループ構成を防ぐ
Resolver ルールとそのインバウンドエンドポイントに対しては、(エンドポイントが直接ターゲットとしているか、オンプレミスの DNS サーバー経由でターゲットとしているかに関係なく) 同じ VPC を関連付けないようにしてください。アウトバウンドエンドポイントが、同じ Resolver ルールと VPC を共有するインバウンドエンドポイントを指している場合、インバウンドエンドポイントとアウトバウンドエンドポイント間でループが生成され、クエリの伝達が継続的に発生する場合があります。
転送ルールは、 AWS Resource Access Manager () を使用して他のアカウントと共有されている他の VPCs に関連付けることができますAWS RAM。この場合も、ハブに関連付けられたプライベートホストゾーン、つまり中央の VPC において、クエリからインバウンドエンドポイントへの解決が行われます (転送リゾルバーのルールでは、この解決は変更されません)。
# Resolver エンドポイントのスケーリング
Resolver エンドポイントセキュリティグループは、エンドポイントを出入りするトラフィックに関する情報を収集するために接続追跡を使用します。各エンドポイントインターフェイスが追跡可能な接続には最大数の制限があり、この接続数を超える大量の DNS クエリが送られた場合は、スロットリングやクエリの損失が発生する可能性があります。接続追跡は AWS、セキュリティグループ (SGs。SG における接続追跡を使用することでトラフィックのスループットが低下しますが、追跡されていない接続を実装してオーバーヘッドを減らし、パフォーマンスを改善することができます。詳細については、「[追跡されていない接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections)」を参照してください。
制限付きセキュリティグループルールを使用して接続追跡が強制される場合、またはクエリが Network Load Balancer ([自動追跡された接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking)を参照) を介してルーティングされる場合、エンドポイントの IP アドレスごとの 1 秒あたりの合計最大クエリ数は 1,500 に抑えられます。
**インバウンド Resolver エンドポイントの送受信セキュリティグループルールの推奨事項**
****
|
|
| **受信ルール** |
| --- |
| プロトコルのタイプ | ポート番号 | 送信元 IP |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
| **送信ルール** |
| --- |
| プロトコルのタイプ | ポート番号 | 送信先 IP |
| TCP | All | 0.0.0.0/0 |
| UDP | All | 0.0.0.0/0 |
**アウトバウンド Resolver エンドポイントの送受信セキュリティグループルールの推奨事項**
****
|
|
| **受信ルール** |
| --- |
| プロトコルのタイプ | ポート番号 | 送信元 IP |
| TCP | All | 0.0.0.0/0 |
| UDP | All | 0.0.0.0/0 |
| **送信ルール** |
| --- |
| プロトコルのタイプ | ポート番号 | 送信先 IP |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
**注記**
**セキュリティグループポートの要件:**
**インバウンドエンドポイント**には、ポート 53 の TCP と UDP がネットワークから DNS クエリを受信できるようにする進入ルールが必要です。エグレスルールでは、エンドポイントがさまざまなソースポートからのクエリに応答する必要がある可能性があるため、すべてのポートを許可できます。
**アウトバウンドエンドポイント**では、エグレスルールにおいてネットワークの DNS クエリに使用するポートで TCP および UDP アクセスを許可する必要があります。ポート 53 は最も一般的な DNS ポートですが、ネットワークが異なるポートを使用する可能性があるため、上記の例に示しています。イングレスルールでは、すべてのポートが DNS サーバーからのレスポンスに対応できます。
**インバウンド Resolver エンドポイント**
インバウンドリゾルバーエンドポイントを使用するクライアントの場合、IP アドレスとポートの (DNS トラフィックを生成している) 固有の組み合わせが 40,000 個を超えると、Elastic Network Interface の容量に影響が生じます。
# Resolver エンドポイントの高可用性
VPC リゾルバーのインバウンドエンドポイントを作成する場合、Route 53 では、ネットワーク上の DNS リゾルバーがクエリを転送する IP アドレスを少なくとも 2 つ作成する必要があります。冗長性を確保するために、少なくとも 2 つのアベイラビリティーゾーンで IP アドレスを指定する必要があります。
複数の Elastic Network Interface エンドポイントを常時使用できるようにする場合は、必要とするネットワークインターフェイス数の他に少なくとも 1 つ余分にインターフェイスを作成し、トラフィックが急増した場合にも処理できるよう追加の容量を確保しておくことをお勧めします。また、追加のネットワークインターフェイスでメンテナンスやアップグレードなどのサービス作業を行っている間の可用性も確保できます。
詳細については、この詳細なブログ記事[「Resolver エンドポイントと で DNS の高可用性を実現する方法](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/)」を参照してください[インバウンドエンドポイントを作成または編集するときに指定する値](resolver-forwarding-inbound-queries-values.md)。
# DNS ゾーンウォーキング
DNS ゾーンウォーキング攻撃とは、DNSSec 署名付き DNS ゾーンからすべてのコンテンツを取得しようとすることです。VPC Resolver チームがエンドポイントで DNS ゾーンがウォークされたときに生成されたトラフィックパターンと一致するトラフィックパターンを検出すると、サービスチームはエンドポイントのトラフィックをスロットリングします。その結果、DNS クエリのタイムアウトの割合が高くなることがあります。
エンドポイントの容量が減少し、エンドポイントが誤って調整されたと思われる場合は、https://console.aws.amazon.com/support/home\$1/ にアクセスしてサポートケースを作成してください。
# Amazon Route 53 ヘルスチェックのベストプラクティス
可用性と回復力の高いインフラストラクチャを維持するには、効果的なヘルスチェック設定が不可欠です。Amazon Route 53 ヘルスチェックをセットアップおよび管理する際に考慮すべきいくつかのベストプラクティスを以下に示します。
1. **エンドポイントのヘルスチェックを行う際に Elastic IP アドレスを使用する:**
+ ヘルスチェックエンドポイントに Elastic IP アドレスを活用して、一貫したモニタリングを確保します。
+ Amazon EC2 インスタンスを使用しなくなった場合は、潜在的なセキュリティリスクやデータ侵害を避けるため、関連するヘルスチェックを忘れずに削除してください。
詳細については、「[ヘルスチェックを作成または更新するときに指定する値](health-checks-creating-values.md)」を参照してください。
1. **適切なヘルスチェック間隔を設定する:**
+ アプリケーションの要件とモニタリング対象リソースの重要度に基づいてヘルスチェック間隔を設定します。
+ 間隔を短くすると、障害検出が速くなりますが、Route 53 のコストが増加し、リソースに負荷がかかる可能性があります。
+ 間隔を長くすると、コストとリソースの負荷は軽減されますが、障害の検出が遅くなる可能性があります。
詳細については、「[高度な設定 (「エンドポイントを監視」する場合のみ)](health-checks-creating-values.md#health-checks-creating-values-advanced)」を参照してください。
1. **アラーム通知を実装する:**
+ ヘルスチェックが失敗または回復したときに通知を受信するように Amazon CloudWatchalarms を設定します。
+ アプリケーションの要件とリソースの予想される動作に基づいて、適切なアラームのしきい値を設定します。
+ 通知をモニタリングおよびインシデントレスポンスプロセスと統合します。
詳細については、「[CloudWatch を使用したヘルスチェックのモニタリング](monitoring-health-checks.md)」を参照してください。
1. **ヘルスチェックリージョンを戦略的に活用する:**
+ ユーザーとリソースの地理的分布に基づいてヘルスチェックリージョンを選択します。
+ 信頼性を向上させ、リージョンの停止の影響を軽減するために、重要なリソースに複数のヘルスチェックリージョンを使用することを検討してください。
1. **ヘルスチェックのログとメトリクスをモニタリングする:**
+ Route 53 ヘルスチェックのログと CloudWatch メトリクスを定期的に確認し、潜在的な問題やパフォーマンスのボトルネックを特定する
+ ヘルスチェックの失敗の理由を分析し、根本的な問題を解決するための適切なアクションを実行します。
1. **フェイルオーバー戦略とフェイルバック戦略を実装する:**
+ Route 53 のフェイルオーバールーティングポリシーを活用して、障害発生時に正常なリソースにトラフィックを自動的にルーティングします。
+ フェイルオーバーとフェイルバックのプロセスを計画してテストし、停止や復旧中にシームレスな移行を確実に行います。
詳細については、「[DNS フェイルオーバーの設定](dns-failover-configuring.md)」を参照してください。
1. **ヘルスチェックを定期的に確認および更新する:**
+ 必要に応じてヘルスチェックのエンドポイント、間隔、アラームしきい値を更新して、最適なモニタリングとパフォーマンスを維持します。
これらのベストプラクティスに従って、Amazon Route 53 ヘルスチェックを効果的に活用して、リソースのヘルスと可用性をモニタリングし、アプリケーションとサービスに信頼性とパフォーマンスの高いインフラストラクチャを確保できます。