Amazon Route 53 のよくある質問

はい。エニーキャストはネットワーキングとルーティングのテクノロジーで、お客様のエンドユーザーの DNS クエリが、そのときのネットワーク状況下で最適な Route 53 ロケーションから返信されるようサポートします。その結果、Route 53 はお客様のユーザーに高可用性をもたらし、パフォーマンスが改善されます。

各 Amazon Route 53 アカウントでは、ホストゾーンが最大 500、各ホストゾーンにつきリソースレコードセットが 10,000 に制限されています。制限の引き上げリクエストを行っていただくと、2 営業日以内にお客様のリクエストに返信いたします。

Route 53 では標準 DNS ゾーンファイルのインポートをサポートしており、このゾーンファイルは多くの DNS プロバイダーおよび BIND などの標準 DNS サーバーソフトウェアからエクスポートできます。新しく作成されたホストゾーン、および既定の NS と SOA レコードを除く空の既存のホストゾーンの場合は、ゾーンファイルを直接 Route 53 コンソールへ貼り付けることができ、Route 53 が自動的にホストゾーンにレコードを作成します。ゾーンファイルのインポートを開始するには、「Amazon Route 53 デベロッパーガイド」のチュートリアルをお読みください。

はい。複数のホストゾーンを作成すると、DNS 設定を「テスト」環境で検証し、「本番稼働用」ホストゾーンで設定を複製できます。たとえば、ホストゾーン Z1234 は example.com のテストバージョンで、ネームサーバー ns-1、ns-2、ns-3、ns-4 でホストされるとします。同様に、ホストゾーン Z5678 は example.com の本番稼働用バージョンで、ns-5、ns-6、ns-7、ns-8 でホストされるとします。各ホストゾーンには、そのゾーンに関連するネームサーバーのバーチャルセットがあるため、Route 53 は DNS クエリに送信するネームサーバーに応じて、別々に example.com の DNS クエリに返信します。

いいえ。Amazon Route 53 は、権威 DNS サービスであり、ウェブサイトホスティングを提供しません。ただし、Amazon Simple Storage Service (Amazon S3) を使用して、静的ウェブサイトをホストできます。動的ウェブサイトや他のウェブアプリケーションをホストするために、Amazon Elastic Compute Cloud (Amazon EC2) を利用できます。同サービスは柔軟性とコントロールに優れており、従来のウェブホスティングソリューションと比較して大幅なコスト削減を提供します。Amazon EC2 の詳細については、こちらをご覧ください。静的なウェブサイトでも動的なウェブサイトでも、Amazon CloudFront を使用すれば、全世界のエンドユーザーに対して低いレイテンシーで配信を行うことができます。Amazon CloudFront の詳細については、こちらをご覧ください。

Amazon Route 53 は現在、以下の DNS レコードタイプをサポートしています。

• A (アドレスレコード)
• AAAA (IPv6 アドレスレコード)
• CNAME (正規名レコード)
• CAA (認証機関認可)
• MX (メール交換レコード)
• NAPTR (名前付け権限ポインタレコード)
• NS (ネームサーバーレコード)
• PTR (ポインタレコード)
• SOA (管理情報の始点レコード)
• SPF (センダーポリシーフレームワーク)
• SRV (サービスロケーター)
• TXT (テキストレコード)
• Amazon Route 53 では、Amazon Route 53 固有の DNS への拡張子であるエイリアスレコードが提供されます。エイリアスレコードを作成して、Amazon Elastic Load Balancing ロードバランサー、Amazon CloudFront ディストリビューション、AWS Elastic Beanstalk 環境、API Gateway、VPC インターフェイスエンドポイント、あるいはウェブサイトとして設定されている Amazon S3 バケットなどの選択された AWS リソースにトラフィックをルーティングすることができます。エイリアスレコードのタイプは通常 A または AAAA ですが、CNAME レコードのように機能します。エイリアスレコードを使用すると、お客様のレコード名 (例: example.com) を AWS リソース用の DNS 名 (elb1234.elb.amazonaws.com) にマッピングすることができます。リゾルバーには、A または AAAA レコードと AWS リソースの IP アドレスが表示されます。

今後さらに多くのレコードタイプを追加する予定です。

はい。ドメインの DNS をさらに設定しやすくするために、Amazon Route 53 は NS レコードを除くすべてのレコードタイプに対してワイルドカードエントリをサポートします。ワイルドカードエントリは DNS ゾーンのレコードであり、ドメイン名のリクエストを設定に基づいてマッチングします。たとえば、*.example.com などのワイルドカード DNS レコードは、www.example.com と subdomain.example.com のクエリをマッチングします。

DNS リゾルバーが返答をキャッシュする時間の長さは、各レコードに関連付けられた有効期限 (TTL) と呼ばれる値によって設定されます。Amazon Route 53 には、いずれのレコードタイプについてもデフォルトの TTL はありません。キャッシュする DNS リソルバーが TTL を介して DNS レコードを指定した時間の長さにキャッシュされるように、各レコードの TTL を常に指定する必要があります。

はい。エイリアスレコードは、サブドメイン (www.example.com、pictures.example.com など) を ELB ロードバランサーや CloudFront ディストリビューション、S3 ウェブサイトバケットにマッピングするときにも使用できます。

はい。トランザクショナルな変更は、変更に一貫性と信頼性を持たせ、他の変更の影響を受けないようにするものです。Amazon Route 53 は、変更が個別の DNS サーバー上で完結するか、またはまったく行われないように設計されています。これにより、DNS クエリは常に着実に返信されます。送信先サーバー間のフリッピングなどの変更を行うときには重要です。API を使用する際、ChangeResourceRecordSets への各呼び出しは、変更ステータスのトラッキングに使うことができる識別子を返します。ステータスが INSYNC とレポートされると、変更はすべての Route 53 サーバーで実施されます。

はい。地理的に分散されたウェブサーバーの負荷のバランスを取るために、複数の IP アドレスが単一のレコードと関連付けられることが多くあります。Amazon Route 53 は、A レコードに対して複数の IP アドレスを一覧表示し、構成された IP アドレスのリストを使って DNS リクエストに返信します。

Amazon Route 53 は、通常の条件では 60 秒以内に DNS レコードへのアップデートを全世界の権威 DNS サーバーのネットワークに反映するよう設計されています。API コールが INSYNC ステータスリスト項目を返すと、変更は世界中に正常に伝達されました。

DNS リゾルバーは、Amazon Route 53 サービスのコントロール外にあり、DNS リゾルバーの有効期限 (TTL) に従ってリソースレコードセットをキャッシュします。変更の INSYNC または PENDING ステータスは、Route 53 の権威 DNS サーバーの状態だけを示します。

はい。AWS CloudTrail を介して、Route 53 の API 呼び出し履歴を記録できます。使用を開始するには、CloudTrail の製品ページをご覧ください。

いいえ。AWS CloudTrail のログをホストゾーンへの変更のロールバックに使用しないことをお勧めします。CloudTrail のログを使用して再構成されたゾーンの変更履歴は不完全になる場合があるためです。

AWS CloudTrail のログは、セキュリティ分析、リソース変更の追跡、およびコンプライアンス監査のために使用することができます。

はい。既存および新規のパブリックホストゾーンで DNSSEC 署名を、さらに Amazon Route 53 Resolver で DNSSEC 検証を有効にすることができます。さらに、Amazon Route 53 では DNSSEC のドメイン登録は許可されています。

はい。Amazon Route 53 は、フォワード (AAAA) とリバース (PTR) の両方の IPv6 レコードをサポートしています。Amazon Route 53 サービス自体も IPv6 経由で利用できます。IPv6 ネットワークの再帰的な DNS リゾルバーは、Amazon Route 53 への DNS クエリの送信に IPv4 と IPv6 のいずれかのトランスポートを利用できます。Amazon Route 53 ヘルスチェックは、IPv6 プロトコルを使用したエンドポイントのモニタリングもサポートしています。

はい。Amazon Route 53 では、Zone Apex (例: example.com) DNS 名を ELB ロードバランサー用の DNS 名 (例: my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com) にマッピングできる、「エイリアス」レコードと呼ばれる特別なタイプのレコードを提供しています。ロードバランサーに関連付けられている IP アドレスは、拡張、縮小、ソフトウェア更新などためにいつでも変更することができます。Route 53 にエイリアスレコードをリクエストすると、ロードバランサーの IP アドレスが 1 つ以上返されます。Route 53 は、Application Load Balancer、Network Load Balancer、Classic Load Balancer の、3 つのタイプのロードバランサー向けのエイリアスレコードをサポートしています。AWS ELB ロードバランサーにマッピングされたエイリアスレコードへのクエリに追加料金はかかりません。このようなクエリは、Amazon Route 53 の使用状況レポートに "Intra-AWS-DNS-Queries" として記載されます。

はい。Amazon Route 53 には、「エイリアス」レコードと呼ばれる特別なタイプのレコードがあり、これを利用して zone apex（example.com）DNS 名を Amazon S3 ウェブサイトバケット（つまり example.com.s3-website-us-west-2.amazonaws.com）にマッピングできます。Amazon S3 ウェブサイトエンドポイントに関連付けられている IP アドレスは、拡張、縮小、ソフトウェア更新などの理由でいつでも変更できます。Route 53 は、エイリアスレコードのリクエストを受け取ると、応答としてバケットの IP アドレスを 1 つ返します。Route 53 では、エイリアスレコードに対するクエリが、ウェブサイトとして設定されている S3 バケットにマッピングされた場合、そのクエリには課金されません。このようなクエリは、Amazon Route 53 の使用状況レポートに "Intra-AWS-DNS-Queries" として記載されます。

はい。Amazon Route 53 には、「エイリアス」レコードと呼ばれる特別なタイプのレコードがあり、これを利用して zone apex（example.com）DNS 名を Amazon CloudFront ディストリビューション（d123.cloudfront.net など）にマッピングできます。Amazon CloudFront のエンドポイントに関連付けられた IP アドレスは、(エンドユーザーを最寄りの CloudFront エッジロケーションに転送するため) エンドユーザーのロケーションによって変更されるほか、拡張、縮小、またはソフトウェア更新などの理由で随時変更できます。Route 53 は、エイリアスレコードのリクエストを受け取ると、応答としてディストリビューションの IP アドレスを返します。Route 53 では、CloudFront ディストリビューションにマッピングされているエイリアスレコードへのクエリは課金されません。このようなクエリは、Amazon Route 53 の使用状況レポートに "Intra-AWS-DNS-Queries" として記載されます。

はい。Amazon Route 53 には、"エイリアス" レコードと呼ばれる特別なタイプのレコードがあり、これを利用して zone apex (example.com) DNS 名を AWS Elastic Beanstalk DNS 名 (例えば example.elasticbeanstalk.com) にマッピングできます。AWS Elastic Beanstalk 環境に関連付けられている IP アドレスは、拡張、縮小、ソフトウェア更新などの理由でいつでも変更できます。Route 53 にエイリアスレコードをリクエストすると、環境の IP アドレスが 1 つ以上返されます。AWS Elastic Beanstalk 環境にマッピングされたエイリアスレコードへのクエリは無料です。このようなクエリは、Amazon Route 53 の使用状況レポートに "Intra-AWS-DNS-Queries" として記載されます。

はい。Amazon Route 53 には、「エイリアス」レコードと呼ばれる特別なタイプのレコードがあり、これを利用して zone apex (example.com) DNS 名を Amazon API Gateway DNS 名 (つまり、api-id.execute-api.region.amazonaws.com/stage) にマッピングできます。Amazon API Gateway に関連付けられている IP アドレスは、拡張、縮小、ソフトウェア更新などの理由でいつでも変更できます。Route 53 にエイリアスレコードをリクエストすると、API Gateway の IP アドレスが 1 つ以上返されます。Amazon API Gateway にマッピングされたエイリアスレコードへのクエリに追加料金はかかりません。これらのクエリは、「Intra-AWS-DNS-Queries」として Route 53 使用状況レポートに一覧表示されます。

はい。Amazon Route 53 には、「エイリアス」レコードと呼ばれる特別なタイプのレコードがあり、これを利用して zone apex (example.com) DNS 名を Amazon VPC エンドポイント DNS 名 (つまり、vpce-svc-03d5ebb7d9579a2b3.us-east-1.vpce.amazonaws.com) にマッピングできます。Amazon VPC エンドポイントに関連付けられている IP アドレスは、拡張、縮小、ソフトウェア更新などの理由でいつでも変更できます。Route 53 にエイリアスレコードをリクエストすると、VPC エンドポイントの IP アドレスが 1 つ以上返されます。Amazon VPC エンドポイントにマッピングされたエイリアスレコードへのクエリに追加料金はかかりません。このようなクエリは、Amazon Route 53 の使用状況レポートに "Intra-AWS-DNS-Queries" として記載されます。

Amazon CloudFront で配信されているウェブサイトまたは Amazon S3 でホストされている静的ウェブサイトでは、Amazon Route 53 サービスを使用して、CloudFront ディストリビューションまたは S3 ウェブサイトバケットを指すエイリアスレコードをドメインに作成できます。静的なウェブサイトをホストするよう設定されていない S3 バケットには、ドメイン用の CNAME レコードと Amazon S3 バケット名を作成できます。いずれの場合も、お客様のドメイン名とバケットまたは配布用 AWS ドメイン名との間のエイリアスを確実に確立するには、代替のドメイン名エントリを使用して、S3 バケット名または CloudFront 配布名をそれぞれ設定する必要があります。

静的なウェブサイトをホスティングするよう設定されている CloudFront ディストリビューションおよび S3 バケットには、CNAME を使用する代わりに、CloudFront ディストリビューションまたは S3 ウェブサイトバケットにマッピングされる「エイリアス」レコードを作成することを推奨します。エイリアスレコードには 2 つの利点があります。1 つは、CNAME とは異なり、エイリアスレコードは zone apex (例えば、www.example.com ではなく example.com) に対しても作成できることです。もう 1 つは、エイリアスレコードへのクエリは無料であることです。

Amazon Route 53 でリソースレコードセットが変更されると、お客様の DNS レコードに行われた更新が権威 DNS サーバーのワールドワイドネットワークに伝搬されます。伝搬が完了する前にレコードをテストした場合、dig または nslookup ユーティリティーを使用したときに古い値が表示されることがあります。さらに、インターネットの DNS リゾルバーは Amazon Route 53 サービスの管理外にあり、リソースレコードセットを自身の有効期限 (TTL) に従ってキャッシュします。dig/nslookup コマンドに対してキャッシュされた値が返される場合があるということです。また、ドメイン名レジストラーが Amazon Route 53 ホストゾーン内のネームサーバーを使用しているかどうかも確認する必要があります。そうしない場合、Amazon Route 53 はお客様のドメインへのクエリにとって信頼できないものになります。

はい。加重ラウンドロビンを使用して、異なる応答が提供される頻度を指定するためにリソースレコードセットに加重を割り当てることができます。ソフトウェアを変更したサーバーへトラフィックの一部を送信して A/B テストを行うのに、この機能を使用できます。例えば、加重3と加重1の、1つ DNS 名に関連付けられている2つのレコードがあるとします。この場合、Route 53 の 75% の時間は加重 3 のレコードセットに返答し、Route 53 の 25% の時間は加重 1 のレコードセットに返答されます。0～255 の間で加重を指定できます。

Amazon Route 53 に新たに追加された LBR (Latency Based Routing) 機能は、グローバルにユーザーが分散するアプリケーションのパフォーマンスを高めるのに役立ちます。アプリケーションを複数の AWS リージョンで、世界各地の多数のエッジロケーションを使用して実行するときに Amazon Route 53 を利用すると、エンドユーザーからのリクエストは、レイテンシーが最小の AWS リージョンにルーティングされます。

Amazon Route 53 の新しい LBR 機能は、AWS マネジメントコンソールからでも、単純な API からでも、簡単に利用を開始できます。さまざまな AWS エンドポイントの IP アドレスまたは ELB 名を含むレコードセットを作成して、そのレコードセットを「LBR 対応レコードセット」と指定するだけです (加重レコードセットの指定をするのと同様です)。後の処理は、Amazon Route 53 によって自動的に行われます。リクエストごとに最適なエンドポイントを特定し、それに応じてエンドユーザーからのリクエストをルーティングします。Amazon のグローバルコンテンツ配信サービスである Amazon CloudFront の機能によく似ています。レイテンシーベースルーティングの使用方法の詳細については、「Amazon Route 53 デベロッパーガイド」をご覧ください。

AWS の他のサービスと同様に、Amazon Route 53 と LBR を使用するときも、前払い金や長期契約は不要です。お支払いいただくのは、実際に使用したホストゾーンとクエリに対する料金のみです。レイテンシーベースのルーティングのクエリに対する料金の詳細については、Amazon Route 53 の料金ページを参照してください。

Route 53 の Geo DNS では、リクエスト元の地理的な場所に基づいて、リクエストを特定のエンドポイントに転送することで、負荷を均等に分散できます。Geo DNS では、ローカライズするコンテンツをカスタマイズできます (詳細ページを適切な言語で提示する、コンテンツのディストリビューションをライセンス許可した市場のみに制限するなど)。また、Geo DNS を使用すると、予測可能な管理しやすい方法でエンドポイント全体に負荷を分散でき、各エンドユーザーの位置を一貫して同じエンドポイントにルーティングできます。Geo DNS には 3 つのレベルの地理的粒度 (大陸、国、州) とグローバルレコードが用意されています。グローバルレコードは、作成したいずれの Geo DNS レコードにもエンドユーザーの位置が一致しない場合に使用できます。Geo DNS を、レイテンシーベースルーティングや DNS フェイルオーバーなどの他のルーティングタイプと組み合わせて、レイテンシーが低く耐障害性のあるさまざまなアーキテクチャを実現することもできます。各種ルーティングタイプの構成方法の詳細については、「Amazon Route 53 のドキュメント」を参照してください。

Amazon Route 53 の Geo DNS 機能は、AWS マネジメントコンソールからでも、Route 53 API からでも、簡単に利用を開始できます。レコードセットを作成し、そのレコードセットに適切な値を指定して Geo DNS 対応レコードセットとしてマーキングし、レコードに適用する地理的な地域（グローバル、大陸、国、または州）を選択するだけです。Geo DNS の使用方法の詳細については、Amazon Route 53 Developer Guide をご覧ください。

はい、グローバルレコードを構成することを強くお勧めします。これにより、エンドユーザーが位置すると思われる各大陸、国、または州の特定のレコードを作成していたとしても、Route 53 はエンドユーザーが存在する可能性のあるすべての場所からの DNS クエリに返答できるようになります。Route 53 は、次の場合に、グローバルレコードに含まれる値を返します。

DNS クエリが Route 53 の Geo IP データベースで識別されない IP アドレスからのものである場合。

DNS クエリが、作成した Geo DNS レコードのいずれにも含まれない場所からのものである場合。

はい、Geo DNS レコードは重複する地理的地域 (ある大陸とその大陸内の国、またはある国とその国内の州など) に対して指定できます。各エンドユーザーの場所について、Route 53 は、その場所を含む最も詳細な Geo DNS レコードを返します。つまり、対象のエンドユーザーの場所について、Route 53 は最初に州レコードを返し、州レコードが見つからない場合、国レコードを返します。国レコードが見つからない場合は大陸レコードを返します。大陸レコードが見つからない場合はグローバルレコードを返します。

AWS の他のサービスと同様に、Amazon Route 53 と Geo DNS を使用するときも、前払い金や長期契約は不要です。お支払いいただくのは、実際に使用したホストゾーンとクエリに対する料金のみです。Geo DNS クエリの料金の詳細については、Amazon Route 53 の料金ページにアクセスしてください。

Geo DNS は、リクエストの地理的場所に基づいてルーティングを決定します。いくつかのケースでは、地域はレイテンシーに対する適切なプロキシとなりますが、そうではない場合もあります。レイテンシーベースルーティングは、ビューワーネットワークと AWS データセンター間のレイテンシー計測を利用します。これらの計測は、どのエンドポイントがユーザーに最も近いかを判断するために使用されます。

エンドユーザーのレイテンシーを最小化することが目標である場合、レイテンシーベースルーティングの使用が推奨されます。コンプライアンス、ローカライズ要件、または特定の地域から特定のエンドポイント間の安定したルーティングを必要とするその他のユースケースがある場合、Geo DNS を使用することが推奨されます。

Route 53 は、DNS クエリに対する複数値の返答をサポートするようになりました。ロードバランサーに代わるものではありませんが、DNS クエリに対して複数のヘルスチェック可能な IP アドレスを返す機能は、DNS を使用して可用性と負荷分散を向上させるための手段となります。ウェブサーバーなどの複数のリソースにランダムにトラフィックをルーティングする場合は、リソースごとに複数値の返答レコードを 1 つ作成することができ、必要に応じて Amazon Route 53 ヘルスチェックを各レコードに関連付けることができます。Amazon Route 53 は、各 DNS クエリに対して最大 8 つの正常なレコードをサポートします。

Amazon Route 53 トラフィックフローは、使いやすくコスト効率の高いグローバルトラフィック管理サービスです。Amazon Route 53 トラフィックフローを使うと、世界中で複数のエンドポイントが実行され、レイテンシー、地理的場所、エンドポイントの状態に基づいてユーザーが最適なエンドポイントに接続されるため、エンドユーザーのためにアプリケーションのパフォーマンスと可用性を向上させることができます。Amazon Route 53 トラフィックフローを使用すると、デベロッパーは、レイテンシー、エンドポイントの状態、負荷、地理的近接性、地理的場所を含め、最も注意すべき制約に基づいてトラフィックをルーティングするポリシーを簡単に作成できます。お客様は、AWS マネジメントコンソールでシンプルなビジュアルポリシービルダーを使用して、このようなテンプレートをカスタマイズすることや、ポリシーをゼロから構築することができます。

トラフィックポリシーは、エンドユーザーのリクエストをアプリケーションのエンドポイントの 1 つにルーティングするようにユーザーが定義するルールのセットです。トラフィックポリシーを作成するには、Amazon Route 53 コンソールの Amazon Route 53 トラフィックフローセクションでビジュアルポリシービルダーを使用します。また、JSON 形式のテキストファイルとしてトラフィックポリシーを作成し、Route 53 API、AWS CLI、またはさまざまな AWS SDK を使用してポリシーをアップロードすることもできます。

トラフィックポリシー自体は、アプリケーションへのエンドユーザーのルーティング方法に影響しません。これは、トラフィックポリシーがアプリケーションの DNS 名 (www.example.com など) にまだ関連付けられていないためです。Amazon Route 53 トラフィックフローの使用を開始し、作成したトラフィックポリシーを使用してアプリケーションにトラフィックをルーティングするには、ポリシーレコードを作成し、所有する Amazon Route 53 ホストゾーン内の適切な DNS 名にトラフィックポリシーを関連付けます。たとえば、my-first-traffic-policy という名前を付けたトラフィックポリシーを使用して www.example.com にあるアプリケーションのトラフィックを管理する場合、ホストゾーン example.com 内の www.example.com 用のポリシーレコードを作成し、my-first-traffic-policy をトラフィックポリシーとして選択します。

ポリシーレコードは、Amazon Route 53 コンソールの Amazon Route 53 トラフィックフローセクションと Amazon Route 53 ホストゾーンセクションに表示されます。

はい。1 つのポリシーを再利用して複数の DNS 名を管理する方法は 2 つあります。1 つ目の方法として、ポリシーを使用して追加のポリシーレコードを作成できます。この方法を使用した場合、作成したポリシーレコードごとに請求が発生するために追加料金がかかります。

2 つ目の方法では、ポリシーを使用して 1 つのポリシーレコードを作成します。その後、ポリシーを使用して管理する追加の DNS 名ごとに、作成したポリシーレコードの DNS 名を参照する標準の CNAME レコードを作成します。たとえば、example.com 用のポリシーレコードを作成する場合、www.example.com、blog.example.com、および www.example.net 用の DNS レコードを作成し、各レコードの CNAME 値に example.com を設定できます。example.net、example.org、example.co.uk など、Zone Apex (ドメイン名の前に www や別のサブドメインが付かない) に対してこの方法を使用することはできません。zone apex のレコードでは、トラフィックポリシーを使用してポリシーレコードを作成する必要があります。

はい。トラフィックポリシーで管理されている DNS 名を参照するエイリアスレコードを作成できます。

料金はポリシーレコードに対してのみ発生します。トラフィックポリシー自体を作成しても料金は発生しません。

ポリシーレコード単位で請求されます。ポリシーレコードは、トラフィックフローポリシーを特定の DNS 名 (www.example.com など) に適用することを表します。このトラフィックポリシーを使用して、その DNS 名へのリクエストにどのように応答するかを管理します。請求は月単位に行われ、1 か月未満の場合は日割り計算されます。ポリシーレコードによって DNS 名に関連付けられていないトラフィックポリシーに料金は発生しません。料金の詳細については、「Amazon Route 53 の料金ページ」を参照してください。

トラフィックフローでは、レイテンシー、エンドポイントの状態、複数値の返答、加重ラウンドロビン、地理を含むすべての Amazon Route 53 の DNS ルーティングポリシーがサポートされています。これらに加えて、トラフィックフローではトラフィックバイアスを使用した地理的近接性ベースのルーティングもサポートされています。

トラフィックフローポリシーを作成すると、AWS リージョン (AWS リソースを使用している場合)、または各エンドポイントの緯度および経度のいずれかを指定できます。たとえば、AWS の米国東部 (オハイオ) リージョンと米国西部 (オレゴン) リージョンに EC2 インスタンスを所有しているとします。シアトルのユーザーがお客様のウェブサイトにアクセスする場合、地理的近接性を使用したルーティングにより、DNS クエリは地理的に近い米国西部 (オレゴン) リージョンの EC2 インスタンスにルーティングされます。詳細については、地理的近接性ルーティングに関するドキュメントをご覧ください。

エンドポイントの地理的近接性のバイアス値を変更すると、Route 53 がリソースにトラフィックをルーティングする送信元のエリアが拡大あるいは縮小します。ただし、地理的近接性のバイアスは負荷要素を厳密に予測することはできません。これは、地理的地域のサイズにおける小規模の変動に大量のクエリを生成する大きな都市地域が含まれる場合と含まれない場合があるためです。詳細については、「ドキュメント」を参照してください。

現時点で、バイアスを適用できるのは地理的近接性ルールに対してのみです。 

プライベート DNS は、Route 53 の機能の 1 つで、自社の DNS レコード (リソースの名前や IP アドレスを含む) をインターネットに公開せずに VPC 内に権威 DNS を置くことができます。

はい。Amazon Route 53 のプライベート DNS 機能を使用して、Virtual Private Cloud (VPC) 内のプライベート IP アドレスを管理できます。プライベート DNS を使用すると、プライベートホストゾーンを作成できます。プライベートホストゾーンに関連付けた VPC 内からクエリを実行すると、Route 53 はこれらのレコードのみを返します。詳細は、「Amazon Route 53 のドキュメント」を参照してください。

プライベート DNS をセットアップするには、Route 53 でホストゾーンを作成し、ホストゾーンを「プライベート」にするオプションを選択し、ホストゾーンと VPC の 1 つを関連付けます。ホストゾーンを作成した後は、追加の VPC をそのホストゾーンに関連付けることができます。プライベート DNS を構成する方法の詳細については、「Amazon Route 53 のドキュメント」を参照してください。

インターネット接続のない VPC 内のリソースからでも、内部 DNS 名を解決できます。ただし、プライベート DNS ホストゾーンの構成を更新するには、VPC の外側にある Route 53 API エンドポイントにアクセスするためのインターネット接続が必要になります。

いいえ。Route 53 のプライベート DNS では、プライベート DNS ホストゾーンの可視性を管理し DNS 解決をするために VPC を使用します。Route 53 のプライベート DNS を活用するためには、VPC を構成し、リソースを VPC に移行する必要があります。

はい、複数の VPC を 1 つのホストゾーンに関連付けることができます。

はい、異なるアカウントに属する VPC を 1 つのホストゾーンに関連付けることができます。詳細は、「こちら」を参照してください。

はい。DNS からの応答は、プライベートホストゾーンに関連付けたすべての VPC 内で利用できます。なお、あるリージョンのリソースが別のリージョンにあるリソースにアクセスできるようにするには、それぞれのリージョン内にある VPC が相互に接続できる必要があります。現在、Route 53 プライベート DNS は、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、および南米 (サンパウロ) の各リージョンでサポートされています。

はい。ヘルスチェックとプライベート DNS ホストゾーン内のリソースレコードセットを関連付けることで DNS フェイルオーバーを設定できます。エンドポイントが Virtual Private Cloud (VPC) 内にある場合は、これらのエンドポイントに対してヘルスチェックを設定する複数のオプションがあります。エンドポイントにパブリック IP アドレスが設定されている場合は、各エンドポイントのパブリック IP アドレスに対して標準のヘルスチェックを作成できます。エンドポイントにプライベート IP アドレスのみが設定されている場合は、それらのエンドポイントに対して標準のヘルスチェックは作成できません。しかし、標準の Amazon Route 53 ヘルスチェックと同様に機能するメトリクスベースのヘルスチェックを作成できます。ただし、このヘルスチェックでは外部ロケーションからエンドポイントに対してリクエストを送信するのではなく、既存の Amazon CloudWatch メトリクスをエンドポイントのヘルス情報源として使用します。

はい、できます。ドメイン名や特定の DNS 名をブロックするために、それらの名前を 1 つまたは複数のプライベート DNS ホストゾーン内に作成し、それらの名前が自社のサーバー (または自社で管理している別の場所) を参照するように設定できます。

DNS フェイルオーバーは、「ヘルスチェック」と「フェイルオーバー」の 2 つの要素で構成されます。ヘルスチェックとは自動化されたリクエストであり、インターネットを介してお客様のアプリケーションに送信されます。この目的は、アプリケーションが到達可能で、使用可能で、機能していることを確認することです。このヘルスチェックは、アプリケーションのユーザーからの典型的なリクエスト (例えば、特定 URL のウェブページをリクエスト) に似たものとなるように設定することもできます。DNS フェイルオーバーを利用すると、リソースが正常な状態で外部から到達可能である場合にのみ、そのリソースに対する回答が返されるようになります。お客様のアプリケーションの中に正常に動作していない部分がある場合は、その部分へのエンドユーザーからのアクセスは別の場所にルーティングされます。

詳しい開始方法については、「Amazon Route 53 デベロッパーガイド」を参照してください。DNS フェイルオーバーの設定は、Route 53 コンソールから行うこともできます。

はい。Elastic Load Balancer (ELB) の DNS フェイルオーバーを設定することができます。ELB エンドポイントの DNS フェイルオーバーを有効にするには、ELB を指定したエイリアスレコードを作成し、[Evaluate Target Health] パラメータを [True] に設定します。Route 53 が ELB のヘルスチェックを自動的に作成し、管理します。Route 53 による ELB ヘルスチェックを独自に作成する必要はありません。ユーザーが ELB のリソースレコードセットを独自のヘルスチェックに関連付ける必要もありません。ユーザーに代わって Route 53 が管理するヘルスチェックに、リソースレコードセットが自動的に関連付けられます。また、ELB ヘルスチェックは、その ELB の背後にあるバックエンドインスタンスの状態を継承します。ELB エンドポイントで DNS フェイルオーバーを使用する方法について詳しくは、「Route 53 デベロッパーガイド」を参照してください。

はい。DNS フェイルオーバーを使用すると、バックアップサイトを用意しておいて (例えば、静的サイトを Amazon S3 ウェブサイトバケット上で運用する)、プライマリサイトが到達不可能になったときに、このバックアップサイトにフェイルオーバーさせることができます。

SOA と DNS レコードを除いて、Route 53 でサポートされるレコードタイプを関連付けることができます。

はい。独自にヘルスチェックを作成しなくても、Amazon Route 53 コンソールから、Elastic Load Balancing および Amazon S3 ウェブサイトバケットの DNS フェイルオーバーを設定できます。このようなエンドポイントタイプについては、ユーザーに代わって Route 53 がヘルスチェックを自動的に作成し、管理します。このヘルスチェックは、ユーザーが ELB または S3 ウェブサイトバケットを指定したエイリアスレコードを作成し、エイリアスレコードで [Evaluate Target Health] パラメータを有効にすると使用されます。

その他すべてのエンドポイントについては、DNS 名 (www.example.com など) か、またはエンドポイントの IP アドレス (そのエンドポイントのヘルスチェックを作成する場合) を指定できます。

はい。Route 53 リソースレコードを作成するときに AWS 外部のアドレスを指定できるのと同様に、ヘルスチェックの対象として、アプリケーションのうち、AWS の外部で実行される部分を指定することができます。エンドポイントの場所にかかわらず、どのエンドポイントへのフェイルオーバーも可能です。例えば、レガシーのアプリケーションが AWS 外部のデータセンターで実行されており、そのアプリケーションのバックアップインスタンスが AWS 内部で実行されているとします。AWS 外部で実行されるレガシーアプリケーションのヘルスチェックをセットアップしておき、アプリケーションのヘルスチェックが不合格となったときに、自動的に AWS 内のバックアップインスタンスにフェイルオーバーすることができます。

いいえ。Route 53 は、ルーティングに関する決定を行うときに、エンドポイントの負荷やトラフィックキャパシティーの空きを考慮しません。障害状態となったエンドポイントに向かっていたトラフィックを処理できるようにするには、他のエンドポイントのキャパシティーの空きがあることや、エンドポイントのスケーリングが可能であることの保証を、お客様側で行っていただく必要があります。

デフォルトのヘルスチェックによる監視のしきい値は 3 回です。3 回連続してエンドポイントのヘルスチェックに失敗すると、Route 53 はエンドポイントを障害状態と見なします。ただし、Route 53はそのエンドポイントに対するヘルスチェックは引き続き実行し、再び合格すると、そのエンドポイントへのトラフィック送信を再開します。このしきい値は 1 ～ 10 回の間で変更できます。詳細は、『Amazon Route 53 デベロッパーガイド』を参照してください。

障害状態のエンドポイントが、ヘルスチェックを作成するときに指定したヘルスチェックによる監視の回数 (デフォルトのしきい値は 3 回) に連続して合格すると、Route 53 は DNS レコードを自動的に復元し、そのエンドポイントに対するトラフィックは再開されます。お客様が何か操作する必要はありません。

ヘルスチェックによる監視は、デフォルトで 30 秒間隔で行われます。必要に応じて、10 秒という短い監視間隔を選択できます。

ヘルスチェックの監視間隔が 3 倍速くなるため、Route 53 がエンドポイントの障害状態をすばやく確認し、DNS フェイルオーバーに必要な時間が短縮され、エンドポイントの障害に対応してトラフィックをリダイレクトできるようになります。

このような短いヘルスチェック間隔にすると、エンドポイントに対するリクエスト数も 3 倍になります。この点は、エンドポイントのウェブトラフィックに対応する容量が制限されている場合、考慮事項の 1 つになる可能性があります。短いヘルスチェック間隔など、ヘルスチェックのオプション機能の料金の詳細については、「Route 53 の料金ページ」を参照してください。詳細は、『Amazon Route 53 デベロッパーガイド』を参照してください。

各ヘルスチェックは、世界中の複数の場所から実行されます。ロケーションの数と組み合わせを設定できます。Amazon Route 53 コンソールまたは API を使用して、それぞれのヘルスチェックを実行できるロケーションの数を変更できます。各ロケーションでは、選択した間隔で独立してエンドポイントをチェックします (デフォルトは 30 秒間隔、必要に応じて 10 秒間隔)。現在のデフォルトのヘルスチェックロケーションの数によると、標準のヘルスチェック間隔の場合、エンドポイントは平均して 2～3 秒ごとに 1 リクエストを受け取り、短いヘルスチェック間隔の場合は 1 秒につき 1 件以上のリクエストを受け取ります。

いいえ。Route 53 のヘルスチェックでは、HTTP の 3xx コードを正常な応答と見なします。そのため、リダイレクトに従いません。これにより、文字列マッチングのヘルスチェックの場合は、予期しない結果になる可能性があります。ヘルスチェックは、指定した文字列をリダイレクトの本文から検索します。ヘルスチェックはリダイレクトに従わないため、リダイレクト先の場所にリクエストを送信しません。また、その場所から応答を受け取りません。文字列マッチングのヘルスチェックの場合、HTTP リダイレクトを返す場所のヘルスチェックを指定することは避けることをお勧めします。

要約すると、ヘルスチェックが不合格となってフェイルオーバーが発生した場合は次のイベントが実行されます。

Route 53 によって、アプリケーションのヘルスチェックが実行されます。この例では、アプリケーションは 3 回連続してヘルスチェックに不合格となり、次のイベントがトリガーされます。

Route 53 によって、障害状態のエンドポイントのリソースレコードが無効化されます。それ以降は、そのレコードが返されることはありません。これがフェイルオーバーのステップであり、これ以降、トラフィックは障害状態のエンドポイントではなく正常なエンドポイントにルーティングされるようになります。

DNS リゾルバーが返答をキャッシュする時間の長さは、各レコードに関連付けられた有効期限 (TTL) と呼ばれる値によって設定されます。DNS フェイルオーバーを使用するときは、TTL を 60 秒以下にすることをお勧めします。これは、障害状態のエンドポイントへのトラフィックルーティングを停止するのに要する時間を最小化するためです。ELB および S3 ウェブサイトエンドポイントの DNS フェイルオーバーを設定するには、固定 TTL が 60 秒のエイリアスレコードを使用する必要があります。これらのエンドポイントタイプについては、DNS フェイルオーバーを使用するための TTL の調整は必要ありません。

Route 53 によるエンドポイントへのフェイルオーバーは、そのエンドポイントが正常である場合に限られます。リソースレコードセット内に正常なエンドポイントが 1 つも残っていない場合は、Route 53 はすべてのヘルスチェックが合格であるものとして動作します。

はい。DNS フェイルオーバーは、LBR を使用していなくても設定できます。特に、DNS フェイルオーバーを使用する目的が単純なフェイルオーバーシナリオであり、プライマリウェブサイトを Route 53 でモニタリングしてそのサイトが使用不可能になったときにバックアップサイトにフェイルオーバーするという場合です。

はい。Route 53 では、HTTPS、HTTP、または TCP を経由するヘルスチェックがサポートされます。

いいえ。HTTPS ヘルスチェックでは、SSL でエンドポイントに接続できるかどうか、エンドポイントが有効な HTTP 応答コードを返すかどうかが確認されますが、エンドポイントから返される SSL 証明書は検証されません。

はい。HTTPS ヘルスチェックは SNI をサポートします。

Route 53 のヘルスチェックを使用して、サーバー応答の中に指定の文字列があるかどうかを調べることができます。このようにするには、「Enable String Matching」オプションを選択します。このオプションを使用すると、ウェブサーバーから配信される HTML の中に指定の文字列があることを確認できます。または、専用のステータスページを作成します。このページを使用して、サーバーの稼働状態を内部または運用の視点から調べることができます。詳細は、『Amazon Route 53 デベロッパーガイド』を参照してください。

ヘルスチェックの現在の状態や障害が起きた詳しい原因は、Amazon Route 53 コンソールか、Route 53 の API から確認できます。

加えて、それぞれのヘルスチェックの結果は Amazon CloudWatch メトリクスとして公開され、エンドポイントの状態と、任意でエンドポイントの応答のレイテンシーが示されます。Amazon Route 53 コンソールの [Health checks] タブに Amazon CloudWatch メトリクスのグラフが表示され、そこで現在と過去のヘルスチェックのステータスを確認できます。ヘルスチェックの状態が変更した場合に通知を送信できるよう、メトリクスで Amazon CloudWatch アラームを作成することもできます。

すべての Amazon Route 53 ヘルスチェックの Amazon CloudWatch メトリクスも、Amazon CloudWatch コンソールで確認できます。それぞれの Amazon CloudWatch メトリクスには、ヘルスチェック ID（例: 01beb6a3-e1c2-4a2b-a0b7-7031e9060a6a）が含まれます。この ID を基に、メトリクスが追跡しているヘルスチェックを特定できます。

Amazon Route 53 ヘルスチェックには、エンドポイントがリクエストに応答するまでの時間のデータを提供する、オプションのレイテンシー計測機能が含まれています。レイテンシー計測機能を有効にすると、追加の Amazon CloudWatch メトリクスが Amazon Route 53 ヘルスチェックによって生成され、Amazon Route 53 ヘルスチェッカーが接続を確立し、データを受信し始めるまでの時間を示します。Amazon Route 53 は、Amazon Route 53 ヘルスチェックが実施される AWS リージョンごとの個別のレイテンシーメトリクスを提供します。

Route 53 ヘルスチェックの結果は、CloudWatch メトリクスとして公開されます。これにより、ヘルスチェックの値が指定したしきい値を超えた場合に、さまざまな CloudWatch 通知と自動アクションがトリガーされるよう設定できます。まず、Route 53 または CloudWatch コンソールのヘルスチェックメトリクスで CloudWatch アラームを設定します。次に、通知アクションを追加し、通知の発行先の E メールアドレスまたは SNS トピックを指定します。詳細については、「Route 53 デベロッパーガイド」をご覧ください。

確認メールは SNS コンソールから再送できます。アラームに関連付けられた SNS トピック名を探すには、Route 53 コンソール内でアラーム名をクリックし、[Send notification to] ボックスを確認します。

SNS コンソール内で、トピックリストを展開し、アラームのトピックを選択します。[Create Subscription] ボックスを開き、プロトコルとして [Email] を選択し、目的のメールアドレスを入力します。[Subscribe] をクリックすると、確認メールが再送されます。

ELB エンドポイントについて DNS フェイルオーバーを作成するお勧めの方法は、[Evaluate Target Health] オプションを有効にしたエイリアスレコードを使用することです。このオプションを使う場合は、ELB エンドポイント用に独自のヘルスチェックを作成しないため、Route 53 はこうしたエンドポイント用に特に CloudWatch メトリクスは生成しません。

ロードバランサーの状態に関するメトリクスを取得するには、2 つの方法があります。1 つ目の方法は、ロードバランサーの状態と、その背後にある正常なインスタンスの数を示すメトリクスを Elastic Load Balancing で公開することです。ELB の CloudWatch メトリクスを設定する方法の詳細については、『ELB デベロッパーガイド』を参照してください。2 つ目の方法は、elb-example-123456678.us-west-2.elb.amazonaws.com など、ELB で提供された CNAME に対するヘルスチェックを独自に作成することです。このヘルスチェックは DNS フェイルオーバー自体に対しては使用しません ([Evaluate Target Health] オプションにより自動的に DNS フェイルオーバーが行われるため) が、このヘルスチェックの CloudWatch メトリクスを表示したり、ヘルスチェックで異常が検出された場合に通知するアラームを作成したりすることはできます。

ELB エンドポイントで DNS フェイルオーバーを使用する方法の詳細については、『Route 53 デベロッパーガイド』を参照してください。

Amazon Route 53 は、それぞれの AWS リージョン内で、Amazon S3 サービスのヘルスチェックを行います。Amazon S3 ウェブサイトバケットを指すエイリアスレコードで [Evaluate Target Health] を有効にした場合、Amazon Route 53 は、バケットがある AWS リージョン内の Amazon S3 サービスの状態を考慮します。Amazon Route 53 は、特定のバケットが存在するかどうか、または有効なウェブサイトコンテンツが含まれているかどうかをチェックしません。バケットが存在する AWS リージョンで Amazon S3 サービスを利用できない場合にのみ、Amazon Route 53 は他のロケーションにフェイルオーバーします。

Route 53 ヘルスチェックでの CloudWatch メトリクスは無料で利用できます。

はい。Amazon Route 53 のメトリクスベースのヘルスチェックでは、AWS が提供するメトリクスや自身のアプリケーションのカスタムメトリクスなど、Amazon CloudWatch で利用可能ないずれかのメトリクスに基づいて DNS フェイルオーバーを実行できます。Amazon Route 53 でメトリクスベースのヘルスチェックを作成すると、関連する Amazon CloudWatch メトリクスがアラーム状態となった場合は、常にヘルスチェックが異常状態となります。

メトリクスベースのヘルスチェックは、プライベート IP アドレスのみを持つ Virtual Private Cloud (VPC) 内のインスタンスなど、標準の Amazon Route 53 ヘルスチェックでは対応できないエンドポイントに対して DNS フェイルオーバーを有効にする場合に役立ちます。また、Amazon Route 53 の計算済みヘルスチェック機能を使用すれば、メトリクスベースのヘルスチェックの結果と、世界中のチェッカーネットワークから 1 つのエンドポイントに対してリクエストを送信する標準の Amazon Route 53 ヘルスチェックの結果を組み合わせることでさらに高度なフェイルオーバーシナリオを作成できます。例えば、公開ウェブページが利用できなくなった場合、または CPU 負荷、ネットワークの送受信、ディスク読み取りなどの内部メトリクスによってサーバー自体が異常状態になった場合に、エンドポイントに対してフェイルオーバーを実行するように設定できます。

時折、Amazon Route 53 の利用者が、自分のものではない IP アドレスやドメイン名を指定したヘルスチェックを作成することがあります。Amazon Route 53 ヘルスチェックからの不要な HTTP(s) リクエストがウェブサーバーに届いている場合、こちらのフォームに不要なヘルスチェックについての情報をご記入ください。当社のカスタマーとともに問題を修正いたします。

ドメイン名を Amazon Route 53 ヘルスチェックのエンドポイントとして指定した場合、Amazon Route 53 はそのドメイン名の IPv4 アドレスを検索し、IPv4 を使用してエンドポイントに接続します。Amazon Route 53 は、ドメイン名で指定されているエンドポイントの IPv6 アドレスの検索を試みません。IPv4 ではなく IPv6 を介したヘルスチェックを実行したい場合は、エンドポイントのタイプとして「ドメイン名」ではなく「IP アドレス」を選択し、[IP address] フィールドに IPv6 アドレスを入力してください。

AWS は、現在の IP アドレス範囲を JSON 形式で公開します。現在の範囲を表示するには、次のリンクを使用して .json ファイルをダウンロードしてください。このファイルにプログラムでアクセスする場合は、AWS サーバーによって返される TLS 認証を正常に検証した後で、アプリケーションがファイルをダウンロードするようにしてください。

ip-ranges.json をダウンロードします。

Route 53 サーバーの IP 範囲を見つけるには、[service] フィールドで以下の値を検索してください。

Route 53 DNS サーバー: 「ROUTE53」の検索

Route 53 ヘルスチェック: 「ROUTE53_HEALTHCHECKS」の検索

詳細については、アマゾン ウェブ サービスの全般的なリファレンスの「AWS IP アドレスの範囲」を参照してください。

IPv6 範囲はこのファイルに表示されないこともあるためご注意ください。参考までに、Amazon Route 53 ヘルスチェックの IPv6 範囲は次のとおりです。

2600:1f1c:7ff:f800::/53
2a05:d018:fff:f800::/53
2600:1f1e:7ff:f800::/53
2600:1f1c:fff:f800::/53
2600:1f18:3fff:f800::/53
2600:1f14:7ff:f800::/53
2600:1f14:fff:f800::/53
2406:da14:7ff:f800::/53
2406:da14:fff:f800::/53
2406:da18:7ff:f800::/53
2406:da1c:7ff:f800::/53
2406:da1c:fff:f800::/53
2406:da18:fff:f800::/53
2600:1f18:7fff:f800::/53
2a05:d018:7ff:f800::/53
2600:1f1e:fff:f800::/53
2620:107:300f::36b7:ff80/122
2a01:578:3::36e4:1000/122
2804:800:ff00::36e8:2840/122
2620:107:300f::36f1:2040/122
2406:da00:ff00::36f3:1fc0/122
2620:108:700f::36f4:34c0/122
2620:108:700f::36f5:a800/122
2400:6700:ff00::36f8:dc00/122
2400:6700:ff00::36fa:fdc0/122
2400:6500:ff00::36fb:1f80/122
2403:b300:ff00::36fc:4f80/122
2403:b300:ff00::36fc:fec0/122
2400:6500:ff00::36ff:fec0/122
2406:da00:ff00::6b17:ff00/122
2a01:578:3::b022:9fc0/122
2804:800:ff00::b147:cf80/122

はい。AWS マネジメントコンソールまたは API を使用して、Route 53 で新しいドメイン名を登録できます。また、他のレジストラから既存のドメイン名を転送して Route 53 で管理するようにリクエストすることもできます。ドメイン名登録サービスは、ドメイン名登録の利用規約に基づいて提供されます。

Route 53 では、一般的なトップレベルドメイン (「gTLD」: .com や .net など) と国コードのトップレベルドメイン (「ccTLD」: .de や .fr など) の両方で幅広い選択肢が用意されています。完全な一覧については、Route 53 ドメイン登録の料金表を参照してください。

まずアカウントにログインし、[Domains] をクリックします。次に、大きな青い [Register Domain] ボタンをクリックし、登録プロセスを完了します。

選択した TLD に応じて、数分から数時間かかります。ドメインが正常に登録されたら、アカウントにその旨が表示されます。

最初の登録期間は通常 1 年間となりますが、いくつかのトップレベルドメイン (TLD) のレジストリにおいては登録期間がさらに延長される場合があります。Amazon Route 53 でドメインを登録する、または Amazon Route 53 にドメイン登録を移行する場合、ドメインの自動的な更新が設定されます。詳細については、「Amazon Route 53 デベロッパーガイド」のドメインの「登録を更新する」をご覧ください。

ドメイン名を登録するには、登録者の連絡先情報 (名前、住所、電話番号、 E メールアドレスなど) を提供する必要があります。管理用と技術用の連絡先が異なる場合は、もう一方の連絡先も提供する必要があります。

ドメイン登録の管理機関 ICANN は、すべてのドメイン名登録について、レジストラーで連絡先情報 (名前、住所、電話番号など) が提供されていること、また、レジストラーで Whois データベースによりこの情報が公開されていることを義務付けています。(会社や組織ではなく) 個人として登録するドメイン名の場合、Route 53 ではプライバシー保護が提供され (無償)、個人の電話番号、E メールアドレス、住所が公開されることはありません。代わりに、レジストラの名前、電子メールアドレスが、レジストラが生成した転送電子メールアドレスとともに Whois に保存され、この情報が必要に応じて、サードパーティがお客様に連絡を取る際に使用される場合があります。

はい。 Route 53 では、追加料金なしでプライバシー保護が提供されています。プライバシー保護により電話番号、E メールアドレス、住所が公開されることはありません。TLD レジストリおよびレジストラの設定で許可されている場合は、名前が公開されることはありません。プライバシー保護を有効にしている場合、ドメインの Whois クエリでは、住所の欄に登録者のメールアドレスが、名前の欄に登録者の名前が表示されます (許可されている場合)。使用されるメールアドレスはレジストラーが生成した転送メールアドレスとなり、この情報はサードパーティーがお客様に連絡を取る際に必要に応じて使用される場合があります。TLD レジストリおよびレジストラの設定で許可されている場合、企業または組織によって登録されたドメイン名はプライバシー保護の対象となります。

TLD のリストについては料金表を、各 TLD の特定の登録要件については『Amazon Route 53 デベロッパーガイド』および当社のドメイン名登録規約を参照してください。

ドメイン名を作成するとき、Route 53 ではお客様のドメインを 4 つの一意の Route 53 ネームサーバー (別名、委託セット) と自動的に関連付けます。お使いのドメインの委託セットは、Amazon Route 53 コンソールで確認できます。これらは、お客様のドメインの登録時に当社で自動的に作成するホストゾーンに表示されます。

デフォルトでは、お客様が作成した各ホストゾーンに対して、Route 53 は新しい一意の委託セットを割り当てます。ただし、Route 53 の API を使用して「再利用可能な委託セット」を自分で作成し、作成した複数のホストゾーンに適用することもできます。多数のドメイン名を持つお客様の場合は、再利用可能な委託セットを使用すると、Route 53 への移行が容易になります。Route 53 によって管理されているすべてのドメインについて、同じ委託セットを使用するようにドメイン名レジストラーに指示できるためです。この機能を利用すると、ns1.example.com や ns2.example.com などの「ホワイトレーベル」の名前サーバーアドレスを作成し、それらのアドレスが自社の Route 53 名前サーバーを参照するように設定することもできます。その後、必要な数のドメイン名に対する権威名前サーバーとして、「ホワイトレーベル」の名前サーバーのアドレスを使用できます。詳しくは、Amazon Route 53 のドキュメントを参照してください。

Route 53 がお客様のドメイン名用に作成したホストゾーン、また、Route 53 がサービス提供するこのホストゾーンに対する DNS クエリに対して料金が発生します。Route 53 ホストゾーンを削除して、Route 53 の DNS サービスで料金を発生させないようにすることもできます。一部の TLD では、ドメイン名登録の一環として有効なネームサーバーを使用する必要があることにご注意ください。これらの TLD のいずれかのドメイン名の場合、そのドメイン名の Route 53 ホストゾーンを安全に削除するには、他のプロバイダーから DNS サービスを入手し、そのプロバイダーのネームサーバーアドレスを入力する必要があります。

AWS では、ICANN 認定レジストラーに登録されたドメイン名を販売しています。Amazon Registrar, Inc. は ICANN にドメイン登録を認定されている Amazon の会社です。レコードのレジストラはお客様のドメインの WHOIS レコードに "Sponsoring Registrar" として掲載され、お客様のドメインを実際に登録したレジストラを示します。

Amazon は、レジストラー Gandi のリセラーです。レコードのレジストラーである Gandi は、登録者に問い合わせてその連絡先情報を初期登録時に検証することが ICANN により義務付けられています。ドメイン名が中断されることがないよう、Gandi のリクエストに応じて、登録日から 15 日以内に連絡先情報を確認してください。また、ドメインの更新時期には、Gandi によりリマインダー通知が送信されます。

使用する基盤となるレジストラを動的に選択します。ほとんどのドメインは Amazon Registrar を通じて登録されます。Amazon Route 53 で現在登録可能なドメインのリストについては、ドキュメントを参照してください。

Whois とはドメイン名の公開データベースで、連絡先情報と、ドメイン名に関連付けられたネームサーバーが記載されています。Whois データベースには、広く利用できる WHOIS コマンドを使用して誰でもアクセスできます。このコマンドは多くのオペレーティングシステムに含まれており、多くのウェブサイトでウェブアプリケーションとしても利用できます。ICANN (Internet Corporation for Assigned Names and Numbers) では、ドメイン名の所有者に連絡を取る必要がある場合に備えて、すべてのドメイン名に対して連絡先情報の公開を義務付けています。

まずアカウントにログインし、[Domains] をクリックします。次に、画面上部にある [Transfer Domain] ボタンをクリックし、移転プロセスを完了します。移転プロセスを開始する前に、以下について確認してください。(1) ドメイン名が、現在のレジストラでロック解除されている、(2) ドメイン名でプライバシー保護が無効になっている (該当する場合)、および (3) 有効な認証コード (または「authcode」) を現在のレジストラから入手している。このコードは、移転プロセスで入力する必要があります。

最初に、ドメイン名の DNS レコードデータのリストを取得します。リストは一般に、既存の DNS プロバイダーから取得可能な「ゾーンファイル」の形で利用できます。DNS レコードデータを取得したら、Route 53 のマネジメントコンソールまたは単にウェブサービスのインターフェイスを使用して、ドメイン名の DNS レコードを保存するためのホストゾーンを作成し、その転送プロセスに従います。このプロセスには、ドメイン名のネームサーバーを、ホストゾーンに関連付けられたネームサーバーに更新するステップなどが含まれます。ドメイン名の転送プロセスを完了するには、ドメイン名の登録に使用したレジストラーに連絡し、その転送プロセスに従います。このプロセスには、ドメイン名のネームサーバーを、ホストゾーンに関連付けられたネームサーバーに更新するステップなどが含まれます。レジストラが新しいネームサーバーの委託を配布するとすぐに、お客様のエンドユーザーからの DNS クエリが Route 53 DNS サーバーにより返答を開始します。

ドメイン名移転のステータスは、Route 53 コンソールのホームページの [Alerts] セクションで確認できます。

現在のレジストラーに連絡し、転送が失敗した理由を特定する必要があります。問題が解決されると、移転リクエストを再提出できるようになります。

ドメイン名を Route 53 から転送するには、新しいレジストラーで転送リクエストを開始する必要があります。新しいレジストラが、ドメイン名が移転され新しいレジストラで管理されるようリクエストします。

Amazon Route 53 の各新規アカウントは、最大 20 個のドメインに制限されています。制限の引き上げリクエストについては、当社までお問い合わせください。

はい。既存および新規のパブリックホストゾーンに対して DNSSEC 署名を有効にできます。

DNSSEC が有効なドメインを Amazon Route 53 に転送するステップバイステップガイドは、ドキュメントを参照してください。

Route 53 リゾルバーは、EC2 にホストされたネームおよびインターネット上のパブリックネームを検索する再帰的な DNS を提供する地域型の DNS サービスです。この機能は、すべての Amazon Virtual Private Cloud (VPC) にデフォルトで用意されています。ハイブリッドなクラウド上のシナリオでは、条件付きの転送ルールと DNS エンドポイントを設定して、AWS Direct Connect および AWS マネージド VPN 間で DNS 解決を実行できます。

Amazon Route 53 は、権威のある DNS サービスと再帰的 DNS サービスの両方です。権威のある DNS には DNS クエリへの最終的な回答 (一般的には IP アドレス) が含まれています。クライアント (モバイルデバイス、クラウド上で実行されるアプリケーションやデータセンターのサーバーなど) は、稀なケースを除き、権威のある DNS サービスと実際に直接やり取りをしません。その代わり、クライアントは再帰的な DNS サービス (DNS リゾルバーとも呼ばれる) とやり取りし、これによってすべての DNS クエリに正確な権威のある回答が検索されます。Route 53 リゾルバーは、再帰的な DNS サービスです。

クエリを受信すると、Route 53 リゾルバーなどの再帰的な DNS サービスは、クエリを自動的に特定の再帰的な DNS サーバーに直接転送するように設定されているか、あるいはドメインのルートから再帰的な検索を開始して最終的な回答が見つかるまで検索を続行します。どちらの場合でも、回答が検索されると、再帰的な DNS サーバーは一定期間この回答をキャッシュして、次回に同じ名前を引き続いてクエリするときにより素早く回答することができます。

条件付き転送ルールでは、リゾルバーが希望するターゲット IP アドレス (通常の場合は、オンプレミス DNS リゾルバー) の指定するドメインにクエリを転送できます。ルールは VPC レベルで適用され、1 つのアカウントから管理することも複数のアカウント間で共有することもできます。

DNS エンドポイントには、Amazon Virtual Private Cloud (VPC) にアタッチする 1 つ以上の Elastic Network Interfaces (ENI) が含まれています。各 ENI には、VPC がある場所のサブネットスペースから IP アドレスが割り当てられます。次に、この IP アドレスはオンプレミス DNS サーバーの転送ターゲットとしてクエリを転送するために機能します。エンドポイントは、VPC からネットワークへ転送する DNS クエリトラフィック、および AWS Direct Connect と管理 VPN を経由してネットワークから VPC へのトラフィックの両方で必要となります。

Route 53 リゾルバーは AWS Resource Access Manager (RAM) に統合され、AWS アカウント間あるいは所属する AWS Organization 内でお客様がリソースを共有できる簡単な方法を提供します。ルールは 1 つのプライマリアカウントで作成し、次に RAM を使用して複数のアカウント間で共有できます。共有したら、ルールを有効にするには、ルールをそのアカウントの VPC に適用する必要があります。詳細については、AWS RAM のドキュメントをご覧ください。

そのルールは、以前にルールを共有していたアカウントから使用できなくなります。となり、そのルールが上記のアカウント内の VPC に関連付けられていた場合、これらの VPC から関連付けを解除されます。

Route 53 Resolver が提供されているリージョンについては、AWS リージョン表をご覧ください。

そうではありません。Amazon Route 53 のパブリックとプライベート DNS、トラフィックフロー、ヘルスチェック、およびドメイン名の登録はすべてグローバルなサービスです。

Route 53 Resolver を利用すると、AWS Outposts ラックでローカルにドメインネームサーバー (DNS) クエリを解決し、オンプレミスアプリケーションの可用性を高め、パフォーマンスを改善できます。Outposts で Route 53 Resolver を有効にすると、Route 53 は Outposts ラックに DNS 応答を自動的に保存し、親 AWS リージョンのネットワーク接続が予期せず切断された場合でも、継続的にアプリケーションの DNS ソリューションを提供します。DNS レスポンスをローカルで処理することで、Outposts の Route 53 Resolver は低レイテンシーの DNS
解決を可能にし、オンプレミスアプリケーションのパフォーマンスが向上します。

さらに、Outposts ラックの Route 53 Resolver を Route 53 Resolver エンドポイント経由でオンプレミスのデータセンターの DNS サーバーに接続できます。これにより、Outposts ラックと他のオンプレミスリソース間の DNS クエリを解決できます。

開始方法の詳細については、「Amazon Route 53 デベロッパーガイド」をご覧ください。リゾルバーの設定は、Amazon Route 53 コンソール内から行うこともできます。

はい。Amazon Route 53 Resolver は、インバウンドとアウトバウンドの両方のリゾルバーエンドポイントで DNS over HTTPS (DoH) プロトコルの使用をサポートしています。

Amazon Route 53 Resolver DNS Firewall は、すべての Amazon Virtual Private Cloud (VPC) 全体で DNS 保護を迅速にデプロイできるようにする機能です。繰り返し実行される DNS 解決に Route 53 Resolver を使用している場合、Route 53 Resolver DNS Firewall により、既知の悪意があるドメインに対するクエリを (例えば denylists を作成することで) ブロックし、信頼できるドメインへのクエリは (allowlists により) 許可することが可能になります。また、AWS により管理されるドメインリストを使用すれば、DNS に関する一般的な脅威からの保護を、すばやく立ち上げることができます。Amazon Route 53 Resolver DNS Firewall は AWS Firewall Manager と連携します。これにより、DNS Firewall ルールに基づいてポリシーを作成し、それらのポリシーを VPC とアカウント全体に対し一元的に適用できます。

VPC 内から DNS を通じてクエリできるドメイン名のフィルタリングを可能にしたい場合は DNS Firewall をご利用ください。この機能が提供する柔軟性により、組織ではセキュリティ態勢に最適な構成を、以下の 2 通りの方法から選択できるようになります。(1) DNS の抜き取り要件が厳しい場合、また、承認済みドメインのリストに載っていないドメインに対する、すべてのアウトバウンドの DNS クエリを拒否したい場合には、「walled-garden (塀で囲まれたガーデン)」のアプローチでルールを作成し、DNS のセキュリティを確保します。(2) 組織が、アカウントのデフォルト状態ですべてのアウトバウンド DNS ルックアップの許可を望んでおり、既知の悪意のあるドメインに対する DNS リクエストのみをブロックする場合は、DNS Firewall を使用して拒否リスト (denylist) を作成します。このリストには、組織で認識しているすべての悪意あるドメイン名を含めます。DNS Firewall には、AWS が管理するドメインリストも備わっています。このリストは、疑わしいドメインやコマンドアンドコントロール (C&C) ボットからの保護に役立ちます。

Route 53 Resolver DNS Firewall は、VPC 全体のために Route 53 Resolver DNS トラフィック (例: AmazonProvidedDNS) に対するコントロールと可視性を提供することによって、AWS 上の既存のネットワークおよびアプリケーションセキュリティサービスを補完します。ユースケースに応じて、使用中のセキュリティコントロールと組合せて DNS Firewall を実装します。AWS Network Firewall、Amazon VPC セキュリティグループ、AWS Web Application Firewall ルール、そして AWS Marketplace のアプリケーションなどと供に使用できます。

はい。Route 53 Resolver DNS Firewall はリージョンごとに機能するサービスで、組織およびアカウントレベルで、Route 53 Resolver DNS のネットワークトラフィックを保護します。複数のアカウントでポリシーやガバナンスを管理するには、AWS Firewall Manager を利用すべきです。

料金は、ファイアウォールに保存するドメイン名の数と、検査される DNS クエリの数に基づき決定されます。詳細については、Amazon Route 53 の料金をご覧ください。

詳細な分析と調査のために、DNS Firewall のアクティビティを Amazon S3 バケットまたは Amazon CloudWatch ロググループにログ記録できます。さらに、Amazon Kinesis Firehose を使用することで、サードパーティープロバイダーに、このログを送信することも可能です。

Amazon Route 53 Resolver DNS Firewall と AWS Network Firewall は、いずれもアウトバウンド DNS クエリの脅威に対する保護を提供しますが、異なるデプロイモデルに対応しています。Amazon Route 53 Resolver DNS Firewall は、お客様が DNS 解決に Amazon Route 53 Resolver を使用している場合に、悪意あるドメインや危険なドメインへの DNS リクエストをブロックするきめ細かい制御を提供するように設計されています。AWS Network Firewall は、お客様が DNS リクエストを解決するために外部 DNS サービスを使用している場合に、既知の悪意あるドメインへのアウトバウンド DNS クエリをフィルター/ブロックする同様の機能を提供します。

Amazon Route 53 プロファイルでは、プロファイルの形式で 1 つ以上の共有可能な設定を作成することで、組織全体の DNS 設定を簡単に管理できます。プロファイルを使用すると、プライベートホストゾーン (PHZ) アソシエーション、リゾルバールール、Route 53 リゾルバー DNS ファイアウォールルールグループなどのさまざまな設定を 1 つの RAM 共有可能な設定に組み合わせることができます。プロファイルを AWS アカウント間で共有し、仮想プライべートクラウド (VPC) に関連付けることで、個別のリソースを管理する複雑さなしに、すべての VPC に同じ DNS 設定を簡単に適用できます。

Route 53 プロファイルは AWS RAM とネイティブに統合されているため、アカウント間または AWS 組織とプロファイルを共有できます。

はい。Route 53 プロファイルは RAM 管理権限を利用しているため、ユーザーは各リソースに異なる権限を付与できます。

1 つの Route 53 プロファイルには最大 5,000 個の VPC を関連付けることができます。

はい、アカウントごとに1つ以上のプロファイルを作成できます。ただし、VPC ごとに一度に関連付けることができるプロファイルは 1 つだけです。

Route 53 プロファイルは、プライベートホストゾーンとその中で指定された設定、Route 53 リゾルバールール (転送とシステムの両方)、および DNS ファイアウォールルールグループをサポートします。さらに、一部の VPC 設定はプロファイル内で直接管理されます。これらの構成には、リゾルバールールの逆 DNS ルックアップ構成、DNS ファイアウォール障害モード構成、および DNSSEC 検証構成が含まれます。

いいえ、AWS リージョン間でプロファイルを共有することはできません