翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# チュートリアル
このセクションでは、次のチュートリアルについて説明します。
**Route 53 をサブドメインの DNS サービスとして使用する**
Amazon Route 53 を新しいサブドメインや既存のサブドメインの DNS サービスとして使用し、親ドメインでは引き続き別の DNS サービスを使用する方法を説明します。
**レイテンシーベースルーティングへ移行する**
Route 53 で標準ルーティングからレイテンシーベースのルーティングに徐々に移行し、利用可能な最小レイテンシーの AWS エンドポイントにユーザーを誘導する方法について説明します。
加重レコードとレイテンシーレコードを組み合わせると、フルコントロールとロールバック機能を備えたスムーズでリスクの低い移行が可能になります。
**レイテンシーベースルーティングに別のリージョンを追加する**
新しい AWS リージョンを追加し、トラフィックを新しいリージョンに徐々に移行することで、レイテンシーベースのルーティング設定を拡張します。
**リージョン内の複数の Amazon EC2 インスタンスにトラフィックをルーティングする**
レイテンシーレコードと加重レコードの組み合わせを使用して、特定の AWS リージョン内の複数の Amazon EC2 インスタンスにトラフィックをルーティングします。
**100 を超える加重レコードを管理する**
加重エイリアスレコードと加重レコードのツリーを作成して、100 を超えるエンドポイントにトラフィックを誘導する方法について説明します。
**重み付けを利用した、耐障害性のある複数のレコードでの応答**
複数のレコードを含む DNS レスポンスに重み付けを行う方法を理解し、複数のエンドポイント間で耐障害性と負荷分散を提供します。
これらのチュートリアルでは、Route 53 のルーティングポリシー、加重レコード、レイテンシーベースのルーティングを効果的に活用して、DNS 管理とトラフィックルーティングを最適化するのに役立つ、さまざまなユースケースとシナリオについて説明します。
**Topics**
+ [親ドメインを移行しないで Amazon Route 53 をサブドメインの DNS サービスとして使用する](creating-migrating.md)
+ [Amazon Route 53 でレイテンシーベースルーティングへ移行する](TutorialTransitionToLBR.md)
+ [Amazon Route 53 のレイテンシーベースルーティングに別のリージョンを追加する](TutorialAddingLBRRegion.md)
+ [Amazon Route 53 でレイテンシーおよび加重レコードを使用して、リージョン内の複数の Amazon EC2 インスタンスにトラフィックをルーティングする](TutorialLBRMultipleEC2InRegion.md)
+ [Amazon Route 53 で 100 を超える加重レコードを管理する](TutorialManagingOver100WRR.md)
+ [Amazon Route 53 での重み付けを利用した、耐障害性のある複数のレコードでの応答](TutorialWeightedFTMR.md)
# 親ドメインを移行しないで Amazon Route 53 をサブドメインの DNS サービスとして使用する
Amazon Route 53 によって、サブドメインの DNS を柔軟に管理できるため、親ドメイン全体を移行することなく、その機能を活用できます。
別の DNS サービスプロバイダーでホストされている親ドメインを維持しながら、新しいサブドメインを作成するか既存のサブドメインを Route 53 に移行することができます。
**Route 53 を使用した新しいサブドメインの作成:**
1. 新しいサブドメインのホストゾーンを作成します。
1. サブドメインに必要な DNS レコード (例えば、A、CNAME、MX) をホストゾーンに追加します。
1. ホストゾーンに割り当てられた Route 53 ネームサーバーを取得します。
1. Route 53 ネームサーバーを指す、サブドメインの NS (ネームサーバー) レコードを追加して、親ドメインの DNS 設定を更新します。
**既存のサブドメインを Route 53 に移行する:**
1. サブドメインのホストゾーンを作成します。
1. サブドメインの現在の DNS 設定を既存の DNS サービスプロバイダーから取得します。
1. ホストゾーンに対応する DNS レコードを追加します。
1. ホストゾーンに割り当てられた Route 53 ネームサーバーを取得します。
1. Route 53 ネームサーバーを指す、サブドメインの NS レコードを追加して、親ドメインの DNS 設定を更新します。
これらのステップに従って、既存のプロバイダーで親ドメインの DNS 設定を維持しながら、サブドメインのヘルスチェック、ルーティングポリシー、トラフィックフロー管理などの Route 53 の高度な機能を活用できます。
**Topics**
+ [親ドメインを移行しないで Amazon Route 53 を DNS サービスとして使用するサブドメインを作成する](CreatingNewSubdomain.md)
+ [親ドメインを移行しないでサブドメインの DNS サービスを Amazon Route 53 に移行](MigratingSubdomain.md)
# 親ドメインを移行しないで Amazon Route 53 を DNS サービスとして使用するサブドメインを作成する
別の DNS サービスから親ドメインの移行を行わずに、DNS サービスとして Amazon Route 53 を使用するサブドメインを作成できます。
このプロセスの基本手順は以下のとおりです。
1. まず、この手順を使用すべきかどうかを[判断](#decide-procedure-create-subdomain)します。
1. [サブドメインの Route 53 ホストゾーンを作成します](#CreateZoneNewSubdomain)。
1. Route 53 ホストゾーンに、新しいサブドメインの[レコードを追加](#AddNewSubdomainRecords)します。
1. *API のみ:* すべての Route 53 DNS サーバーに[変更が反映されたことを確認します。](#CheckStatusNewSubdomain)
**注記**
現在、変更が反映されたことを確認するには、[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API アクションを使用する方法しかありません。通常、変更は 60 秒以内にすべての Route 53 ネームサーバーに反映されます。
1. [サブドメインのネームサーバーレコードを追加して、親ドメインの DNS サービスを更新します](#UpdateDNSParentDomain)。
## サブドメインの作成に使用する手順の決定
このトピックの手順では、一般的でないオペレーションを実行する方法について説明します。ドメインの DNS サービスとして Route 53 を既に使用していて、サブドメイン (www.example.com など) のトラフィックをリソース (EC2 インスタンスで実行されているウェブサーバーなど) にルーティングするだけの場合は、「[サブドメインのトラフィックのルーティング](dns-routing-traffic-for-subdomains.md)」を参照してください。
この手順を使用するのは、ドメイン (example.com など) で別の DNS サービスを使用していて、そのドメインの新しいサブドメイン (www.example.com など) で Route 53 を DNS サービスとして使い始める場合に*限ります*。
## 新しいサブドメインのホストゾーンを作成する
親ドメインの移行を行わずに、Amazon Route 53 を新しいサブドメインの DNS サービスとして使用する場合、サブドメインのホストゾーンの作成から開始します。Route 53 は、ホストゾーンにサブドメインの情報を保存します。
Route 53 コンソールを使用したホストゾーンの作成方法については、「[パブリックホストゾーンの作成](CreatingHostedZone.md)」を参照してください。
## レコードの作成
Amazon Route 53 コンソールまたは Route 53 API を使用して、レコードを作成できます。Route 53 で作成したレコードが、サブドメインに対する責任を Route 53 に委任した後で DNS が使用するレコードになります。詳細については、「[サブドメインのネームサーバーレコードで DNS サービスを更新する](#UpdateDNSParentDomain)」を参照してください。
**重要**
Route 53 ホストゾーンに追加のネームサーバー (NS) レコードまたは Start of Authority (SOA) レコードを作成しないでください。また、既存の NS レコードと SOA レコードを削除しないでください。
Route 53 コンソールを使用してレコードを作成するには、「[レコードを使用する](rrsets-working-with.md)」を参照してください。Route 53 API を使用してレコードを作成するには、「`ChangeResourceRecordSets`」を参照してください。詳細については、*[Amazon Route 53 API リファレンス](https://docs.aws.amazon.com/Route53/latest/APIReference/)*の「[ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)」を参照してください。
## 変更のステータスを確認する (API のみ)
新しいホストゾーンの作成や、レコードの変更は、Route 53 DNS サーバーに伝達されるまでに時間がかかります。レコードの作成に [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) を使用した場合、`GetChange` アクションを使用して、変更が反映されたかどうかを判断できます (`ChangeResourceRecordSets` は `ChangeId` の値を返します。これは次の `GetChange` リクエストに含めることができます。コンソールを使用してレコードを作成した場合は、`ChangeId` を使用できません)。詳細については、*Amazon Route 53 API リファレンス*の「[GET GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)」を参照してください。
**注記**
通常、変更は 60 秒以内にすべての Route 53 ネームサーバーに反映されます。
## サブドメインのネームサーバーレコードで DNS サービスを更新する
Amazon Route 53 レコードへの変更が反映された後 (「[変更のステータスを確認する (API のみ)](#CheckStatusNewSubdomain)」を参照)、サブドメインの NS レコードを追加して、親ドメインの DNS サービスを更新します。これは、サブドメインの責任の Route 53 への委任と呼ばれます。例えば、親ドメインの example.com が別の DNS サービスでホストされており、サブドメインの test.example.com を Route 53 で作成していた場合、test.example.com の新しい NS レコードで example.com の DNS サービスを更新する必要があります。
以下の手順を実行します。
1. DNS サービスから提供される方法を使用して、親ドメインのゾーンファイルをバックアップします。
1. Route 53 コンソールで、Route 53 ホストゾーンのネームサーバーを取得します。
1. AWS マネジメントコンソール にサインインし、Route 53 コンソール ([https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)) を開きます。
1. ナビゲーションペインで [**Hosted zones (ホストゾーン)**] をクリックします。
1. [**Hosted Zones (ホストゾーン)**] ページで、ホストゾーンのラジオボタン (名前ではない) を選択し、[**View details (詳細を表示)**] を選択します。
1. ホストゾーンの詳細ページで、[**Hosted zone details (ホストゾーンの詳細)**] を選択します。
1. [**Name Servers (ネームサーバー)**] に表示されている 4 つのサーバー名を書き留めます。
または、`GetHostedZone` アクションを使用できます。詳細については、*Amazon Route 53 API リファレンス*の「[GetHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetHostedZone.html)」を参照してください。
1. 親ドメインの DNS サービスから提供される方法を使用して、親ドメインのゾーンファイルにサブドメインの NS レコードを追加します。これらの NS レコードでは、ステップ 1 で作成したホストゾーンに関連する 4 つの Route 53 ネームサーバーを指定します。
**重要**
親ドメインのゾーンファイルに Start of Authority (SOA) のレコードを追加しないでください。サブドメインは Route 53 を使用するため、親ドメインの DNS サービスはサブドメインに関する権限を保持していません。
DNS サービスが自動的にサブドメインの SOA レコードを追加した場合、サブドメインのレコードを削除します。ただし、親ドメインの SOA レコードは削除しないでください。
# 親ドメインを移行しないでサブドメインの DNS サービスを Amazon Route 53 に移行
別の DNS サービスから親ドメインを移行せずに、Amazon Route 53 を DNS サービスとして使用するサブドメインを移行できます。
このプロセスの基本手順は以下のとおりです。
1. まず、この手順を使用すべきかどうかを[判断](#decide-procedure-migrate-subdomain)します。
1. [サブドメインの Route 53 ホストゾーンを作成します](#CreateZoneMigratedSubdomain)。
1. [親ドメインの現在の DNS サービスプロバイダから現在の DNS 設定を取得します](#GetParentDomainResourceRecords)。
1. Route 53 ホストゾーンに、サブドメインの[レコードを追加](#AddMigratedSubdomainRecords)します。
1. *API のみ:* すべての Route 53 DNS サーバーに[変更が反映されたことを確認します](#MigratingSubdomainCheckStatus)。
**注記**
現在、変更が反映されたことを確認するには、[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API アクションを使用する方法しかありません。通常、変更は 60 秒以内にすべての Route 53 ネームサーバーに反映されます。
1. [サブドメインのネームサーバーレコードを追加して、親ドメインの DNS サービスプロバイダの DNS 設定を更新します](#UpdateOldDNS)。
## サブドメインの作成に使用する手順の決定
このトピックの手順では、一般的でないオペレーションを実行する方法について説明します。ドメインの DNS サービスとして Route 53 を既に使用していて、サブドメイン (www.example.com など) のトラフィックをリソース (EC2 インスタンスで実行されているウェブサーバーなど) にルーティングするだけの場合は、「[サブドメインのトラフィックのルーティング](dns-routing-traffic-for-subdomains.md)」を参照してください。
この手順を使用するのは、ドメイン (example.com など) で別の DNS サービスを使用していて、そのドメインの既存のサブドメイン (www.example.com など) で Route 53 を DNS サービスとして使い始める場合に*限ります*。
## サブドメイン用のホストゾーンの作成
別の DNS サービスから Amazon Route 53 にサブドメインを移行するが、親ドメインは移行しない場合は、まずサブドメイン用のホストゾーンを作成します。Route 53 は、ホストゾーンにサブドメインの情報を保存します。
Route 53 コンソールを使用したホストゾーンの作成方法については、「[パブリックホストゾーンの作成](CreatingHostedZone.md)」を参照してください。
## DNS サービスプロバイダーから現在の DNS 設定を取得
既存のサブドメインを Route 53 に移行するプロセスを単純化するには、現在ドメインにサービスを提供している DNS サービスプロバイダからドメインの現在の DNS 設定を取得します。この情報を基本として、Route 53 をサブドメインの DNS サービスとして設定することができます。
求める情報とその形式は、現在 DNS サービスプロバイダとして使っている会社によって異なります。現在の設定におけるレコードすべてに関する情報を含むゾーンファイルが提供されるのが理想です (レコードは、ドメインとサブドメインのトラフィックのルーティング方法をDNSに伝えます。例えば、誰かがウェブブラウザにドメイン名を入力すると、データセンターのウェブサーバーや、Amazon EC2 インスタンス、CloudFront ディストリビューションなどに、トラフィックをルーティングするかを指定します。) 現在の DNS サービスプロバイダからゾーンファイルを取得できる場合は、ゾーンファイルを編集して、Amazon Route 53 に移行しないレコードを削除することができます。その後、残りのレコードを Route 53 ホストゾーンにインポートすると、処理が大幅に単純化されます。*ゾーンファイル*または*レコードリスト*を取得する方法を、現在の DNS サービスプロバイダのカスタマーサポートに問い合わせてみてください。
## レコードの作成
現在の DNS サービスプロバイダから入手したレコードを基準として使用し、サブドメイン用に作成した Amazon Route 53 ホストゾーンに、対応するレコードを作成します。Route 53 で作成したレコードが、サブドメインに対する責任を Route 53 に委任した後で DNS が使用するレコードになります。詳細については、「[サブドメインのネームサーバーレコードで DNS サービスを更新する](#UpdateOldDNS)」を参照してください。
**重要**
Route 53 ホストゾーンに追加のネームサーバー (NS) レコードまたは Start of Authority (SOA) レコードを作成しないでください。また、既存の NS レコードと SOA レコードを削除しないでください。
Route 53 コンソールを使用してレコードを作成するには、「[レコードを使用する](rrsets-working-with.md)」を参照してください。Route 53 API を使用してレコードを作成するには、「`ChangeResourceRecordSets`」を参照してください。詳細については、*[Amazon Route 53 API リファレンス](https://docs.aws.amazon.com/Route53/latest/APIReference/)*の「[ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)」を参照してください。
## 変更のステータスを確認する (API のみ)
新しいホストゾーンの作成や、レコードの変更は、Route 53 DNS サーバーに伝達されるまでに時間がかかります。レコードの作成に [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) を使用した場合、`GetChange` アクションを使用して、変更が反映されたかどうかを判断できます (`ChangeResourceRecordSets` は `ChangeId` の値を返します。これは次の `GetChange` リクエストに含めることができます。コンソールを使用してレコードを作成した場合は、`ChangeId` を使用できません)。詳細については、*Amazon Route 53 API リファレンス*の「[GET GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)」を参照してください。
**注記**
通常、変更は 60 秒以内にすべての Route 53 ネームサーバーに反映されます。
## サブドメインのネームサーバーレコードで DNS サービスを更新する
Amazon Route 53 レコードへの変更が反映された後 (「[変更のステータスを確認する (API のみ)](#MigratingSubdomainCheckStatus)」を参照)、サブドメインの NS レコードを追加して、親ドメインの DNS サービスを更新します。これは、サブドメインの責任の Route 53 への委任と呼ばれます。例えば、親ドメイン example.com が別の DNS サービスでホストされていて、サブドメイン test.example.com を Route 53 に移行するとします。test.example.com のホストゾーンを作成し、example.com の DNS サービスを、test.example.com の新しいホストゾーンに Route 53 が割り当てた NS レコードで更新する必要があります。
以下の手順を実行します。
1. DNS サービスから提供される方法を使用して、親ドメインのゾーンファイルをバックアップします。
1. ドメインの更新前の DNS サービスプロバイダでネームサーバーの TTL 設定を変更する方法を利用できる場合は、設定を 900 秒に変更することをお勧めします。これにより、使用されていないネームサーバーを使ってクライアントリクエストがドメイン名の解決を試行する時間が制限されます。現在の TTL が 172800 秒 (2 日) である場合は (一般的なデフォルト設定)、リゾルバーとクライアントが更新前の TTL を使用して DNS レコードのキャッシュを停止するまで 2 日間待機する必要があります。TTL の設定期間が終了すると、更新前のプロバイダで保存されていたレコードを安全に削除し、Route 53 にのみ変更を加えることができます。
1. Route 53 コンソールで、Route 53 ホストゾーンのネームサーバーを取得します。
1. AWS マネジメントコンソール にサインインし、Route 53 コンソール ([https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)) を開きます。
1. ナビゲーションペインで [**Hosted zones (ホストゾーン)**] をクリックします。
1. [**Hosted Zones (ホストゾーン)**] ページで、ホストゾーンのラジオボタン (名前ではない) を選択し、[**View details (詳細を表示)**] を選択します。
1. ホストゾーンの詳細ページで、[**Hosted zone details (ホストゾーンの詳細)**] を選択します。
1. [**Name Servers (ネームサーバー)**] に表示されている 4 つのサーバー名を書き留めます。
または、`GetHostedZone` アクションを使用できます。詳細については、*Amazon Route 53 API リファレンス*の「[GetHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetHostedZone.html)」を参照してください。
1. 親ドメインの DNS サービスから提供される方法を使用して、親ドメインのゾーンファイルにサブドメインの NS レコードを追加します。NS レコードにサブドメインと同じ名前を付けます。NS レコードの値には、ステップ 2 で作成したホストゾーンに関連する 4 つの Route 53 ネームサーバーを指定します。DNS サービスが異なると、使用する用語も異なります。このステップを実行する方法については、DNS サービスの技術サポートへの問い合わせが必要になる場合があります。
**重要**
親ドメインのゾーンファイルに Start of Authority (SOA) のレコードを追加しないでください。サブドメインは Route 53 を使用するため、親ドメインの DNS サービスはサブドメインに関する権限を保持していません。
DNS サービスが自動的にサブドメインの SOA レコードを追加した場合、サブドメインのレコードを削除します。ただし、親ドメインの SOA レコードは削除しないでください。
親ドメインのネームサーバーの TTL 設定に応じて、DNS リゾルバーに対する変更の反映は 48 時間以上かかる場合があります。この反映が行われている間も、DNS リゾルバーは親ドメインの DNS サービスのネームサーバーを使用してリクエストに応答することがあります。また、クライアントコンピュータは、サブドメインの以前のネームサーバーをキャッシュに引き続き保持する場合もあります。
1. ドメインのレジストラの TTL 設定期間が終了した後で (ステップ 2 を参照)、親ドメインのゾーンファイルから次のレコードを削除してください。
+ Route 53 に追加したレコードについては、「[レコードの作成](#AddMigratedSubdomainRecords)」を参照してください。
+ DNS サービスの NS レコード。NS レコードの削除が完了すると、ゾーンファイルに含まれる NS レコードは、ステップ 4 で作成した NS レコードだけになります。
# Amazon Route 53 でレイテンシーベースルーティングへ移行する
レイテンシーベースのルーティングを使用すると、Amazon Route 53 は利用可能な最小レイテンシーの AWS エンドポイントにユーザーを誘導できます。例えば、`www.example.com` のような DNS 名を、米国東部 (オハイオ) リージョンや欧州 (アイルランド) リージョンでホストされている ELB Classic、Application、または Network Load Balancer、Amazon EC2 インスタンス、Elastic IP アドレスなどと関連付けることができます。Route 53 DNS サーバーは、過去数週間のネットワークの状態に基づいて、特定のユーザーをどのリージョンのどのインスタンスに割り当てるかを決定します。おそらくロンドンのユーザーは、欧州 (アイルランド) インスタンスに割り当てられ、シカゴのユーザーは、米国東部 (オハイオ) インスタンスに割り当てられるでしょう。Route 53 では、A や AAAA のレコードに対してエイリアスの作成がサポートされているのと同様に、A、AAAA、TXT、CNAME などのレコードに対してレイテンシーベースルーティングがサポートされます。
**注記**
ユーザーとリソース間のレイテンシーに関するデータは、ユーザーと AWS データセンター間のトラフィックに完全に基づいています。 AWS リージョンでリソースを使用していない場合、ユーザーとリソース間の実際のレイテンシーはレイテンシ AWS ーデータと大きく異なる場合があります。これは、リソースが AWS リージョンと同じ都市にある場合でも当てはまります。
スムーズで低リスクな移行を行うために、加重レコードとレイテンシーレコードを併用して、標準のルーティングから各ステージで完全な制御とロールバックを行う機能を備えたレイテンシーベースルーティングへと徐々に移行することができます。米国東部 (オハイオ) リージョンの Amazon EC2 インスタンスで現在ホストされている、`www.example.com` の例を考えてみましょう。インスタンスには Elastic IP アドレス `W.W.W.W` が関連付けられています。該当する場合に米国東部 (オハイオ) リージョンへのトラフィックのルーティングを継続しながら、米国西部 (北カリフォルニア) リージョン (Elastic IP `X.X.X.X`) や欧州 (アイルランド) リージョン (Elastic IP `Y.Y.Y.Y`) にある追加の Amazon EC2 インスタンスにユーザーのルーティングを開始するとします。`example.com` の Route 53 ホストゾーンは、A という**タイプ**と、`W.W.W.W` という**値** (IP アドレス) を持つ `www.example.com` のレコードを既に保持しています。
以下の例を完了すると、2 つの加重エイリアスレコードが作成されます。
+ `www.example.com` の既存のレコードを、米国東部 (オハイオ) リージョンの既存の Amazon EC2 インスタンスに対してトラフィックの大部分を引き続きルーティングする、加重エイリアスレコードに変更します。
+ 3 つのリージョンすべてにトラフィックをルーティングするレイテンシーレコードにトラフィックのごく一部のみを最初にルーティングする、別の加重エイリアスレコードを作成します。
これらの加重エイリアスレコードの重みを更新することにより、米国東部 (オハイオ) リージョンのみにトラフィックのルーティングを行う状態から、Amazon EC2 インスタンスがある 3 つのリージョンすべてにトラフィックをルーティングする状態へと徐々に移行することができます。
**レイテンシーベースルーティングへ移行するには**
1. `www.example.com` のレコードのコピーを作成しますが、新しいドメイン名 (`copy-www.example.com` など) を使います。新しいレコードに、** のレコードと同じように、**タイプ** (A) および**値`W.W.W.W` (`www.example.com`) を指定します。
1. `www.example.com` の既存の A レコードを更新し、加重エイリアスレコードにします。
+ **[Value/Route traffic to]** (値/トラフィックのルーティング先) で、**[Alias to another record in this hosted zone]** (このホストゾーンにある別のレコードへのエイリアス) を選択し、`copy-www.example.com` を指定します。
+ **[Weight]** (ウェイト) で、100 を指定します。
更新が完了すると、Route 53 では、`W.W.W.W` という IP アドレスを持つリソースにすべてのトラフィックをルーティングするために、このレコードを引き続き使用します。
1. 各 Amazon EC2 インスタンスにレイテンシーレコードを作成します。例えば、以下のようにします。
+ 米国東部 (オハイオ)、Elastic IP アドレス `W.W.W.W`
+ 米国西部 (北カリフォルニア)、Elastic IP アドレス `X.X.X.X`
+ 欧州 (アイルランド)、Elastic IP アドレス `Y.Y.Y.Y`
すべてのレイテンシーレコードに同じドメイン名 (`www-lbr.example.com` など) と同じタイプ (A など) を設定します。
レイテンシーレコードの作成が終了すると、Route 53 では、ステップ 2 で更新したレコードを使用して引き続きトラフィックをルーティングします。
`www-lbr.example.com` を使用して検証テストを実行できます。たとえば、各エンドポイントがリクエストを受信できることを確認することができます。
1. `www-lbr.example.com` というレイテンシーレコードを `www.example.com` という加重レコードに追加し、対応する Amazon EC2 インスタンスに対して限られた量のトラフィックのルーティングを開始しましょう。その後、米国東部 (オハイオ) リージョンの Amazon EC2 インスタンスは両方の加重レコードからトラフィックを受け取ります。
`www.example.com` の加重エイリアスレコードを以下の方法でもう 1 つ作成します。
+ **[Value/Route traffic to]** (値/トラフィックのルーティング先) で、**[Alias to another record in this hosted zone]** (このホストゾーンにある別のレコードへのエイリアス) を選択し、`www-lbr.example.com.` を指定します。
+ **[Weight]** (ウェイト) で、1 を指定します。
変更を完了し、その変更を Route 53 サーバーに同期させると、Route 53 では、ステップ 3 でレイテンシーレコードを作成した Amazon EC2 インスタンスにトラフィックのごく一部 (1/101) のルーティングを開始します。
1. エンドポイントが着信トラフィックに応じて適切にスケーリングされることを確認できたら、必要に応じて重みを調節します。例えば、レイテンシーベースルーティングに基づいてリクエストの 10% の受信を希望する場合、重みをそれぞれ 90 と 10 に変更します。
レイテンシーレコードの作成については、「[Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)」を参照してください。
# Amazon Route 53 のレイテンシーベースルーティングに別のリージョンを追加する
レイテンシーベースルーティングを使用中で、新しいリージョンのインスタンスを追加する必要がある場合、「[Amazon Route 53 でレイテンシーベースルーティングへ移行する](TutorialTransitionToLBR.md)」でレイテンシーベースルーティングに徐々にトラフィックを移行したのと同様の方法で、新しいリージョンにトラフィックを徐々に移行することができます。
例えば、`www.example.com` に対するトラフィックのルーティングにレイテンシーベースルーティングを使用し、アジアパシフィック (東京) の Amazon EC2 インスタンスを米国東部 (オハイオ)、米国西部 (北カリフォルニア)、欧州 (アイルランド) のインスタンスに追加するとします。以下の例では、別のリージョンのインスタンスを追加する 1 つの方法について説明します。
この例では、`example.com` のAmazon Route 53 ホストゾーンは既に、`www-lbr.example.com` のレイテンシーベースレコードにトラフィックをルーティングする `www.example.com` の加重エイリアスレコードを保持しています。
+ 米国東部 (オハイオ)、Elastic IP アドレス `W.W.W.W`
+ 米国西部 (北カリフォルニア)、Elastic IP アドレス `X.X.X.X`
+ 欧州 (アイルランド)、Elastic IP アドレス `Y.Y.Y.Y`
加重エイリアスレコードの重みは 100 です。レイテンシーベースルーティングに移行した後、移行に使用した他の加重レコードは削除するとします。
**Route 53 のレイテンシーベースルーティングに別のリージョンを追加するには**
1. トラフィックのルーティングを開始する新しいリージョンと、3 つの元からあるリージョンを含む、4 つの新しいレイテンシーベースレコードを作成します。
+ 米国東部 (オハイオ)、Elastic IP アドレス `W.W.W.W`
+ 米国西部 (北カリフォルニア)、Elastic IP アドレス `X.X.X.X`
+ 欧州 (アイルランド)、Elastic IP アドレス `Y.Y.Y.Y`
+ アジアパシフィック (東京)、Elastic IP アドレス `Z.Z.Z.Z`
すべてのレイテンシーレコードに同じ新しいドメイン名 (`www-lbr-2012-04-30.example.com` など) と同じタイプ (A など) を設定します。
レイテンシーレコードの作成が完了すると、Route 53 では引き続き、元の加重エイリアスレコード (`www.example.com`) とレイテンシーレコード (`www-lbr.example.com`) を使用してトラフィックをルーティングします。
`www-lbr-2012-04-30.example.com` レコードを使用して検証テストを実行できます。たとえば、各エンドポイントがリクエストを受信できることを確認することができます。
1. 新しいレイテンシーレコードの加重エイリアスレコードを作成します。
+ ドメイン名に、既存の加重エイリアスレコードの名前 (`www.example.com`) を指定します。
+ **[Value/Route traffic to]** (値/トラフィックのルーティング先) で、**[Alias to another record in this hosted zone]** (このホストゾーンにある別のレコードへのエイリアス) を選択し、`www-lbr-2012-04-30.example.com` を指定します。
+ **[Weight]** (ウェイト) で、1 を指定します。
完了すると、Route 53 では、ステップ 1 で `www-lbr-2012-04-30.example.com` のレイテンシーレコードを作成した Amazon EC2 インスタンスに、トラフィックのごく一部 (1/101) のルーティングを開始します。残りのトラフィックは、アジアパシフィック (東京) リージョンの Amazon EC2 インスタンスを含まない、`www-lbr.example.com` のレイテンシーレコードに引き続きルーティングされます。
1. エンドポイントが着信トラフィックに応じて適切にスケーリングされることを確認できたら、必要に応じて重みを調節します。たとえば、東京リージョンを含むレイテンシーレコードにリクエストの 10% がルーティングされるようにする場合、`www-lbr.example.com` の重みを 100 から 90 に変更し、`www-lbr-2012-04-30.example.com` の重みを 1 から 10 に変更します。
レコード作成についての詳細は、「[Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)」を参照してください。
# Amazon Route 53 でレイテンシーおよび加重レコードを使用して、リージョン内の複数の Amazon EC2 インスタンスにトラフィックをルーティングする
アプリケーションが 2 つ以上の Amazon EC2 リージョンの Amazon EC2 インスタンスで実行中の場合や 1 つ以上のリージョンの Amazon EC2 インスタンスが 2 つ以上ある場合、レイテンシーベースルーティングを使用して、正確なリージョンにトラフィックをルーティングしてから、加重レコードを使用して、指定した重みに基づいてリージョン内のインスタンスにトラフィックをルーティングできます。
例えば、米国東部 (オハイオ) リージョンに Elastic IP アドレスを持つ Amazon EC2 インスタンスが 3 つあり、米国東部 (オハイオ) リージョンに該当するユーザーについては、3 つすべての IP にリクエストを均等に分散させたいとします。多くのリージョンに同時に同じ方法を適用できますが、他のリージョンでは Amazon EC2 インスタンスは 1 つで十分です。
**Amazon Route 53 でレイテンシーおよび加重レコードを使用して、リージョン内の複数の Amazon EC2 インスタンスにトラフィックをルーティングするには**
1. リージョンで Amazon EC2 インスタンスの加重レコードのグループを作成します。次の点に注意してください。
+ 各加重レコードで、**[Record name]** (レコード名) (`us-east.example.com` など) と **[Record type]** (レコードタイプ) に同じ値を指定します。
+ **[Value/Route traffic to]** (値/トラフィックのルーティング先) で、**[IP address or another value depending on the record type]** (IP アドレスまたはレコードタイプに応じた別の値) を選択し、Elastic IP アドレスのいずれかの値を指定します。
+ Amazon EC2 インスタンスに均等に重みを割り当てる場合は、**[Weight]** (ウェイト) に同じ値を指定します。
+ 各レコードの [**セット ID**] に一意の値を指定します。
加重レコード値の詳細については、[加重ルーティング](routing-policy-weighted.md) を参照してください。
1. その他のリージョンに複数の Amazon EC2 インスタンスがある場合、他のリージョンに対してステップ 1 を繰り返します。各リージョンで [**Name**] に異なる値を指定します。
1. 複数の Amazon EC2 インスタンスがある各リージョンに (米国東部 (オハイオ) など)、レイテンシーエイリアスレコードを作成します。[**Value/Route traffic to**] (次への値/ルートのトラフィック) で、[**Alias to another record in this hosted zone**] (このホストゾーン内の別のレコードへのエイリアス) を選択し、そのリージョンの加重レコードに割り当てた [**Record name**] (レコード名) フィールドの値 (`us-east.example.com` など) を指定します。
1. 1 つの Amazon EC2インスタンスがある各リージョンに、レイテンシーレコードを作成します。**[Record name]** (レコード名) には、ステップ 3 で作成したレイテンシーエイリアスレコードに指定したものと同じ値を指定します。**[Value/Route traffic to]** (値/トラフィックのルーティング先) で、**[IP address or another value depending on the record type]** (IP アドレスまたはレコードタイプに応じた別の値) を選択し、そのリージョンの Amazon EC2 インスタンスの Elastic IP アドレスを指定します。
Amazon EC2 インスタンスへのエイリアスレコードの追加の詳細については、[Amazon EC2 インスタンスへのトラフィックのルーティング](routing-to-ec2-instance.md) を参照してください。
レコード作成についての詳細は、「[Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)」を参照してください。
# Amazon Route 53 で 100 を超える加重レコードを管理する
Amazon Route 53 では、加重レコードを設定することができます。特定の名前やタイプ (たとえば、名前が `www.example.com`で、タイプが A) に対して、最大 100 の代替応答を設定することができ、それぞれに重みを設定できます。`www.example.com` のクエリへ応答する場合、Route 53 DNS サーバーは、重みが設定されたランダム応答を選択し、DNS リゾルバーに返します。重みが 2 の加重レコードの値は、重みが 1 の加重レコードの値よりも平均 2 倍の頻度で返されます。
100 を超すエンドポイントにトラフィックを振り分ける場合は、加重エイリアスレコードと加重レコードのツリーを使用する方法があります。例えば、ツリーの最初の「階層」を最大 100 個の加重エイリアスレコードとし、その各レコードでそれぞれに最大 100 個の加重レコードを指定できます。Route 53 では、再帰レベルは最大で 3 まで可能であり、最大 1,000,000 個の一意の加重エンドポイントを管理することができます。
シンプルな 2 階層のツリーは以下のようになります。
**加重エイリアスレコード**
+ 重みが 1 の `www-a.example.com` に対応する、`www.example.com` エイリアス
+ 重みが 1 の `www-b.example.com` に対応する、`www.example.com` エイリアス
**加重レコード**
+ `www-a.example.com`、タイプ A、値 192.0.2.1、重み 1
+ `www-a.example.com`、タイプ A、値 192.0.2.2、重み 1
+ `www-b.example.com`、タイプ A、値 192.0.2.3、重み 1
+ `www-b.example.com`、タイプ A、値 192.0.2.4、重み 1
レコード作成についての詳細は、「[レコードを使用する](rrsets-working-with.md)」を参照してください。
# Amazon Route 53 での重み付けを利用した、耐障害性のある複数のレコードでの応答
**注記**
複数値回答ルーティングポリシーを使用するレコードは、このチュートリアルで説明されている設定と同じように動作します。主な違いは、チュートリアルの設定により、重みを指定できる点です。これは、エンドポイントごとにキャパシティーが異なる場合に便利です。詳細については、「[複数値回答ルーティング](routing-policy-multivalue.md)」を参照してください。
Amazon Route 53 の加重レコードには、1 つのレコードのみを関連付けることができます。すなわち、1 つの名前 (`example.com` など) と 1 種類のレコードタイプ (A など) の組み合わせのみを関連付けることができます。ただし、複数のレコードを含む DNS 応答に重み付けすることが望ましい場合もあります。
例えば、あるサービスで 8 個の Amazon EC2 インスタンスまたは Elastic IP エンドポイントを使用しているとします。そのサービスが接続をサポートしているクライアントが (多くの一般的なブラウザと同じように) 再試行を行う場合、特定のエンドポイントで障害が発生したときには、DNS 応答で複数の IP アドレスを提供することにより、そのようなクライアントに代替エンドポイントを提供します。2 つ以上のアベイラビリティーゾーンにホストされる IP を複数含む応答を設定する場合、アベイラビリティーゾーンの障害から保護することもできます。
複数のレコードでの応答は、多数のクライアント (モバイルウェブアプリケーションなど) が小規模の DNS キャッシュのセットを共有する場合などにも役に立ちます。この場合、共有するキャッシュから共通の DNS 応答を受け取る場合でも、複数のレコードでの応答により、クライアントのリクエストを複数のエンドポイントにルーティングすることができます。
このようなタイプの重み付けした複数レコードでの応答は、レコードと加重エイリアスレコードの組み合わせを使用することにより実現できます。以下に示すように、8 個のエンドポイントを、それぞれ 4 個の IP アドレスを含む 2 個の異なるリソースレコードセットにグループ化できます。
タイプ A の `endpoint-a.example.com` には、以下の値が含まれます。
+ 192.0.2.1
+ 192.0.2.2
+ 192.0.2.128
+ 192.0.2.129
タイプ A の `endpoint-b.example.com` には、以下の値が含まれます。
+ 192.0.2.3
+ 192.0.2.4
+ 192.0.2.130
+ 192.0.2.131
これにより、次の各グループを指し示す加重エイリアスレコードを作成することができます。
+ タイプ A、重み 1 の `endpoint-a.example.com` に対応する、`www.example.com` エイリアス
+ タイプ A、重み 1 の `endpoint-b.example.com` に対応する、`www.example.com` エイリアス
レコード作成についての詳細は、「[レコードを使用する](rrsets-working-with.md)」を参照してください。