翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ルーティングポリシーの選択 レコードを作成するときは、Amazon Route 53 がクエリに応答する方法を決定するルーティングポリシーを選択します。 + **シンプルルーティングポリシー** – ドメインで特定の機能を実行する単一のリソースがある場合に使用します。例えば、example.com ウェブサイトにコンテンツを提供する 1 つのウェブサーバーなどです。シンプルルーティングは、プライベートホストゾーンにレコードを作成するために使用できます。 + **フェイルオーバールーティングポリシー** – アクティブ/パッシブフェイルオーバーを構成する場合に使用します。フェイルオーバールーティングは、プライベートホストゾーンにレコードを作成するために使用できます。 + **位置情報ルーティングポリシー** – ユーザーの位置に基づいてトラフィックをルーティングする場合に使用します。位置情報ルーティングは、プライベートホストゾーンにレコードを作成するために使用できます。 + **地理的近接性ルーティングポリシー** – リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する場合に使用します。地理的近接性ルーティングは、プライベートホストゾーンにレコードを作成するために使用できます。 + **レイテンシールーティングポリシー** – 複数の にリソースがあり AWS リージョン 、レイテンシーが最も高いリージョンにトラフィックをルーティングする場合に使用します。レイテンシールーティングは、プライベートホストゾーンにレコードを作成するために使用できます。 + **IP ベースのルーティングポリシー** – トラフィックの送信元の IP アドレスがわかっており、ユーザーの位置に基づいてトラフィックをルーティングする際に使用します。 + **複数値回答ルーティングポリシー** – ランダムに選ばれた最大 8 つの正常なレコードを使用して Route 53 が DNS クエリに応答する場合に使用します。複数値回答ルーティングは、プライベートホストゾーンにレコードを作成するために使用できます。 + **加重ルーティングポリシー**– 指定した比率で複数のリソースにトラフィックをルーティングする場合に使用します。加重ルーティングポリシーは、プライベートホストゾーンにレコードを作成するために使用できます。 **Topics** + [シンプルルーティング](routing-policy-simple.md) + [フェイルオーバールーティング](routing-policy-failover.md) + [位置情報ルーティング](routing-policy-geo.md) + [地理的近接性ルーティング](routing-policy-geoproximity.md) + [レイテンシーに基づくルーティング](routing-policy-latency.md) + [IP ベースルーティング](routing-policy-ipbased.md) + [複数値回答ルーティング](routing-policy-multivalue.md) + [加重ルーティング](routing-policy-weighted.md) + [Amazon Route 53 が EDNS0 を使用してユーザーの場所を推定する方法](routing-policy-edns0.md) # シンプルルーティング シンプルルーティングでは、Route 53 の特殊な加重ルーティングやレイテンシールーティングを使用せずに、標準の DNS レコードを設定できます。シンプルルーティングでは、通常、1 つのリソース (ウェブサイトのウェブサーバーなど) にトラフィックをルーティングします。 プライベートホストゾーンのレコードに、シンプルルーティングポリシーを使用できます。 Route 53 コンソールでシンプルルーティングポリシーを選択した場合は、複数のレコードを同じ名前と型で作成することはできませんが、同一レコードに複数の値 (複数の IP アドレスなど) を指定することができます (エイリアスレコードのシンプルなルーティングポリシーを選択した場合は、現在のホストゾーンで 1 つの AWS リソースまたは 1 つのレコードのみを指定できます）。複数の値を 1 つのレコードに指定すると、Route 53 はすべての値をランダムな順序で再帰的リゾルバーに返し、リゾルバーはこれらの値を DNS クエリを送信したクライアント (ウェブブラウザなど) に返します。次に、クライアントは 1 つの値を選択してクエリを再送信します。シンプルルーティングポリシーでは複数の IP アドレスを指定できますが、これらの IP アドレスのヘルスチェックは行われません。 シンプルルーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、以下のトピックを参照してください。 + [シンプルなレコードに固有の値](resource-record-sets-values-basic.md) + [シンプルなエイリアスレコードに固有の値](resource-record-sets-values-alias.md) + [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md) + [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md) # フェイルオーバールーティング フェイルオーバーのルーティングにより、リソースが正常な場合にリソースにトラフィックをルーティングできます。また、最初のリソースが正常でない場合は別のリソースにルーティングできます。プライマリレコードとセカンダリレコードのトラフィックのルーティング先は、ウェブサイトとして設定されている Amazon S3 バケットから、複雑なレコードのツリーまで、何でも構いません。詳細については、「[アクティブ/パッシブ (フェイルオーバー)。](dns-failover-types.md#dns-failover-types-active-passive)」を参照してください。 フェイルオーバールーティングポリシーは、プライベートホストゾーンのレコードに使用できます。 フェイルオーバールーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、以下のトピックを参照してください。 + [フェイルオーバーレコードに固有の値](resource-record-sets-values-failover.md) + [フェイルオーバーエイリアスレコードに固有の値](resource-record-sets-values-failover-alias.md) + [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md) + [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md) # 位置情報ルーティング 位置情報ルーティングでは、ユーザーの地理的場所、つまり DNS クエリの送信元の場所に基づいて、トラフィックを処理するリソースを選択できます。例えば、ヨーロッパからのすべてのクエリをフランクフルトリージョンの Elastic Load Balancing ロードバランサーにルーティングしなければならない場合があります。 位置情報ルーティングを使用する場合は、コンテンツをローカライズし、ウェブサイトの一部またはすべてをユーザーの言語で表示できます。また、位置情報ルーティングを使用して、コンテンツの配布を、配布の権利がある場所だけに制限することもできます。もう 1 つの考えられる使用方法は、予測可能な管理しやすい方法で、複数のエンドポイントにわたって負荷を分散することです。この場合、各ユーザーの場所は、一貫して同じエンドポイントにルーティングされます。 地理的場所は、大陸別、国別、米国の州別に指定できます。重なり合う地理的リージョンについて別々のレコードを作成した場合は (例えば、北米用のレコードが 1 つ、カナダ用のレコードが 1 つ)、最も小さい地理的リージョンが優先されます。これにより、大陸のクエリを 1 つのリソースにルーティングし、その大陸の一部の国のクエリを異なるリソースにルーティングすることができます (各大陸の国の一覧については、「[ロケーション](resource-record-sets-values-geo.md#rrsets-values-geo-location)」を参照してください)。 位置情報は、IP アドレスを場所にマッピングすることで動作します。しかし、一部の IP アドレスは地理的場所にマッピングされません。そのため 7 つの大陸をすべて網羅した位置情報レコードセットを作成した場合でも、Amazon Route 53 が受け取る DNS クエリには場所を識別できないものがあります。デフォルトリソースレコードセットを作成して、どの場所にもマッピングされない IP アドレスからのクエリと、位置情報レコードを作成していない場所からのクエリの両方を処理することができます。デフォルトレコードを作成しない場合、Route 53 はそのような場所からのクエリに対して "応答なし" という応答を返します。 位置情報ルーティングは、パブリックホストゾーンとプライベートホストゾーンの両方のレコードに使用できます。 詳細については、「[Amazon Route 53 が EDNS0 を使用してユーザーの場所を推定する方法](routing-policy-edns0.md)」を参照してください。 位置情報ルーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、以下のトピックを参照してください。 + [位置情報レコードに固有の値](resource-record-sets-values-geo.md) + [位置情報エイリアスレコードに固有の値](resource-record-sets-values-geo-alias.md) + [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md) + [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md) # プライベートホストゾーンのジオロケーションルーティング プライベートホストゾーンの場合、Route 53 はクエリの送信元の VPC AWS リージョン の に基づいて DNS クエリに応答します。のリストについては AWS リージョン、*Amazon EC2 ユーザーガイド*[」の「リージョンとゾーン](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)」を参照してください。 DNS クエリがハイブリッドネットワークのオンプレミス部分から発信された場合は、VPC が配置されている AWS リージョン から発信されたと見なされます。 ヘルスチェックを含めると、次のデフォルトレコードを作成できます。 + 地理的な場所にマップされていない IP アドレス。 + 位置情報レコードを作成していない場所からの DNS クエリ。 DNS クエリのリージョンの位置情報レコードが正常でない場合、デフォルトのレコードが返されます (正常である場合)。 次の図の設定例では、us-east-1 AWS リージョン (バージニア) からの DNS クエリは 1.1.1.1 エンドポイントにルーティングされます。 ![\[プライベートホストゾーンの位置情報レコードを示すスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/geolocation-phz.png) # 地理的近接性ルーティング 地理的近接性ルーティングでは、Amazon Route 53 はユーザーとリソースの地理的場所に基づいてリソースのトラフィックをルーティングします。利用可能な最も近いリソースにトラフィックをルーティングします。また、必要に応じて、*「バイアス」*という値を指定することによって特定のリソースにルーティングするトラフィックの量を変更できます。バイアスは、リソースにルーティングされるトラフィックのルーティング元である地理的リージョンのサイズを拡大または縮小します。 リソースで地理的近接性ルールを作成し、各ルールに次の値のいずれかを指定します。 + AWS リソースを使用している場合は、リソースを作成した AWS リージョン またはローカルゾーングループを指定します。 + AWS リソース以外の を使用している場合は、リソースの緯度と経度を指定します。 AWS ローカルゾーンを使用するには、まずローカルゾーンを有効にする必要があります。詳細については、「*AWS Local Zones ユーザーガイド*」の「[Getting started with Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html)」を参照してください。 AWS リージョン とローカルゾーンの違いについては、*Amazon EC2 ユーザーガイド*[」の「リージョンとゾーン](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)」を参照してください。 Route 53 がリソースにルーティングするトラフィックの発信元の地理的リージョンのサイズを必要に応じて変更するには、バイアスに適切な値を指定します。 + Route 53 がリソースにルーティングするトラフィックの発信元の地理的リージョンのサイズを拡大するには、バイアスに 1 から 99 までの正の整数を指定します。Route 53 は隣接するリージョンのサイズを縮小します。 + Route 53 がリソースにルーティングするトラフィックの発信元の地理的リージョンのサイズを縮小するには、-1 から -99 までの負のバイアスを指定します。Route 53 は隣接するリージョンのサイズを拡大します。 **注記** Route 53 の Traffic Flow コンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 お使いのコンソールのタブを選択します。 + [新しいコンソール](#traffic-flow-geoprox-routing-map-new) + [旧コンソール](#traffic-flow-geoprox-routing-map-old) ------ #### [ New console ] 次のマップは 4 AWS リージョン (1～5 の番号) を示しています。 1. 米国西部 (オレゴン) 1. 欧州 (フランクフルト) 1. アジアパシフィック (東京) 1. アフリカ (ケープタウン) 1. 中東 (バーレーン) **注記** マップは Traffic Flow でのみ使用できます。 ![\[米国西部 (オレゴン)、欧州 (フランクフルト)、アジアパシフィック (東京)、アフリカ (ケープタウン)、中東 (バーレーン) の AWS リージョン のリソースの地理的近接性レコードがある場合の、トラフィックがどのようにルーティングされるかを示す世界地図。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png) 次のマップでは、米国西部 (オレゴン) リージョン (マップ上の **1**) に \$125 のバイアスが追加されています。北米ではそれまでより広範囲から、さらに南米全域からもトラフィックがそのリージョンにルーティングされるようになっています。 ![\[米国東部 (バージニア北部) リージョンに +25 のバイアスを追加した場合のトラフィックのルーティングを示す世界地図。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png) 次のマップでは、米国西部 (オレゴン) リージョンのバイアスが -25 に変更されています。トラフィックは、以前よりも北米と南米の小さな部分からそのリージョンのリソースにルーティングされ、隣接するリージョン **2**、**3**、**4** のリソースにルーティングされるトラフィックが増えます。 ![\[米国西部 (オレゴン) リージョンに -25 のバイアスを追加した場合のトラフィックのルーティングを示す世界地図。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png) ------ #### [ Old console ] 次のマップは、4 AWS リージョン (番号 1～4) と、緯度と経度で指定された南アフリカのヨハネスブルグ (5) の場所を示しています。 **注記** マップは Traffic Flow でのみ使用できます。 ![\[米国西部 (オレゴン）、米国東部 (バージニア北部）、欧州 (パリ）、アジアパシフィック (東京) AWS リージョン の リソースの地理的近接性レコードがあり、南アフリカのヨハネスブルクでAWS 非リソースのレコードがある場合に、トラフィックがどのようにルーティングされるかを示す世界のマップ。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png) 次のマップでは、米国東部 (バージニア北部) リージョン (マップ上の **2**) に \$125 のバイアスが追加されています。北米ではそれまでより広範囲から、さらに南米全域からもトラフィックがそのリージョンにルーティングされるようになっています。 ![\[米国東部 (バージニア北部) リージョンに +25 のバイアスを追加した場合のトラフィックのルーティングを示す世界地図。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png) 次のマップでは、米国東部 (バージニア北部) リージョンのバイアスが -25 に変更されています。北米および南米では、より狭い範囲からのトラフィックがそのリージョンのリソースにルーティングされ、隣接するリージョン (**1**、**3**、**5**) のリソースにルーティングされるトラフィックが増えています。 ![\[米国東部 (バージニア北部) リージョンに -25 のバイアスを追加した場合のトラフィックのルーティングを示す世界地図。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png) ------ リソースのバイアスを変更する効果は、以下を含む多くの要素によって決まります。 + 所有するリソース数。 + リソースの相互の距離。 + 地理的地域の境界地域のユーザー数。たとえば、 AWS リージョン 米国東部 (バージニア北部) と米国西部 (オレゴン) にリソースがあり、米国テキサス州ダラス、オースティン、サンアントニオに多数のユーザーがいるとします。これらの都市はリソース間でほぼ等しいため、バイアスのわずかな変化により、リソース間のトラフィックが大きく変動する可能性があります AWS リージョン 。 予期しないトラフィックの移動によりリソースに過度の負担がかからないように、バイアスの変更は小規模にすることをお勧めします。 詳細については、「[Amazon Route 53 が EDNS0 を使用してユーザーの場所を推定する方法](routing-policy-edns0.md)」を参照してください。 ## Amazon Route 53 がバイアスを使用してトラフィックをルーティングする方法 以下は、Amazon Route 53 がトラフィックをルーティングする方法を決定するのに使用する式です。 **Bias (バイアス)** `Biased distance = actual distance * [1 - (bias/100)]` バイアスの値が正の場合、Route 53 は DNS クエリのソースと地理的近接性レコードで指定したリソース ( の EC2 インスタンスなど AWS リージョン) を、実際よりも近くにあるものとして扱います。例えば、以下の地理的近接性のレコードがあるとします。 + ウェブサーバー A のレコード、正のバイアスは 50 + ウェブサーバー B のレコード、バイアスなし 地理的近接性のレコードで正のバイアスが 50 ある場合、Route 53 はクエリのソースとそのレコードのリソース間の距離を半分にします。次に、Route 53 はクエリのソースに近いのはどのリソースかを計算します。ウェブサーバー A はクエリのソースから 150 km の距離にあり、ウェブサーバー B はクエリのソースから 100 km の距離にあるとします。どちらのレコードにもバイアスがない場合、Route 53 はクエリをより近くにあるウェブサーバー B にルーティングします。ただし、ウェブサーバー A のレコードには正のバイアス 50 があるので、Route 53 はウェブサーバー A をクエリのソースから 75 km の距離にあるものとして扱います。その結果、Route 53 はクエリをウェブサーバー A にルーティングします。 以下に、正のバイアス 50 の計算を示します。 ``` Bias = 50 Biased distance = actual distance * [1 - (bias/100)] Biased distance = 150 kilometers * [1 - (50/100)] Biased distance = 150 kilometers * (1 - .50) Biased distance = 150 kilometers * (.50) Biased distance = 75 kilometers ``` # レイテンシーに基づくルーティング アプリケーションが複数の でホストされている場合 AWS リージョン、レイテンシーが最も低い からのリクエストを処理することで AWS リージョン 、ユーザーのパフォーマンスを向上させることができます。 **注記** ユーザーとリソース間のレイテンシーに関するデータは、ユーザーと AWS データセンター間のトラフィックに完全に基づいています。でリソースを使用していない場合 AWS リージョン、ユーザーとリソース間の実際のレイテンシーはレイテンシ AWS ーデータと大きく異なる場合があります。これは、リソースが AWS リージョンと同じ都市にある場合でも当てはまります。 レイテンシーベースルーティングを使用するには、複数の AWS リージョンのリソース用にレイテンシーレコードを作成します。ドメインまたはサブドメイン (example.com または acme.example.com) の DNS クエリを受信した Route 53 は、レイテンシーレコードが作成された AWS リージョン を判定し、ユーザーに対するレイテンシーが最も小さいリージョンを判定し、そのリージョンのレイテンシーレコードを選択します。Route 53 は、ウェブサーバーの IP アドレスなど、選択したレコードの値で応答します。 例えば、米国西部 (オレゴン) リージョンとアジアパシフィック (シンガポール) リージョンに Elastic Load Balancing ロードバランサーがあるとします。各ロードバランサーのレイテンシーレコードを作成します。ロンドンのユーザーがブラウザにあなたのドメイン名を入力した場合は次のようになります。 1. DNS がクエリを Route 53 ネームサーバーにルーティングします。 1. Route 53 は、ロンドンとシンガポールリージョン間のレイテンシーおよびロンドンとオレゴンリージョン間のレイテンシーに基づいて、そのリクエストのデータを参照します。 1. ロンドンとオレゴンリージョン間のレイテンシーのほうが低い場合、Route 53 はオレゴンのロードバランサーの IP アドレスをクエリに対して返します。ロンドンとシンガポールリージョン間のレイテンシーの方が低い場合、Route 53 はシンガポールのロードバランサーの IP アドレスをクエリに対して返します。 インターネット上のホスト間のレイテンシーは、ネットワーク接続やルーティングに変更があると、時間の経過と共に変化する場合があります。レイテンシーベースルーティングは一定期間中に実施されたレイテンシー測定の値に基づいており、これらの測定値はレイテンシーの変化を反映しています。この週にオレゴンリージョンにルーティングされたリクエストは、次の週にシンガポールリージョンにルーティングされる場合があります。 **注記** ブラウザまたは他のビューアが EDNS0 の edns-client-subnet 拡張をサポートする DNS リゾルバーを使用している場合、DNS リゾルバーはユーザーの IP アドレスを切り捨てたアドレスを Route 53 に送信します。レイテンシーベースルーティングを設定した場合、Route 53 はトラフィックをリソースにルーティングする際にこの値を考慮します。詳細については、「[Amazon Route 53 が EDNS0 を使用してユーザーの場所を推定する方法](routing-policy-edns0.md)」を参照してください。 レイテンシールーティングポリシーは、プライベートホストゾーンのレコードに使用できます。 レイテンシールーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、以下のトピックを参照してください。 + [レイテンシーレコードに固有の値](resource-record-sets-values-latency.md) + [レイテンシーエイリアスレコードに固有の値](resource-record-sets-values-latency-alias.md) + [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md) + [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md) # プライベートホストゾーンのレイテンシーに基づくルーティング プライベートホストゾーンの場合、Route 53 は、同じ にある AWS リージョンエンドポイント、またはクエリの送信元の VPC AWS リージョン の に最も近いエンドポイントを使用して DNS クエリに応答します。 **注記** アウトバウンドエンドポイントがインバウンドエンドポイントに転送されている場合、レコードはアウトバウンドエンドポイントではなく、インバウンドエンドポイントの位置に基づいて解決されます。 ヘルスチェックを含め、クエリのオリジンに対するレイテンシーが最も低いレコードが異常である場合、レイテンシーが次に低い正常なエンドポイントが返されます。 次の図の設定例では、us-east-1 AWS リージョンまたはそれに最も近い DNS クエリが 1.1.1.1 エンドポイントにルーティングされます。us-west-2 からの DNS クエリ、またはそれに最も近いクエリは、2.2.2.2 エンドポイントにルーティングされます。 ![\[プライベートホストゾーンの 2 つのレイテンシーレコードを示すスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/latency-phz.png) # IP ベースルーティング Amazon Route 53 の IP ベースルーティングでは、ネットワーク、アプリケーション、およびクライアントについて把握することで DNS ルーティングを微調整し、エンドユーザーのための最適な DNS ルーティングを決定できます。IP ベースのルーティングでは、ユーザー IP からエンドポイントにマッピングする形で Route 53 にデータをアップロードするので、パフォーマンスの最適化やネットワークコスト削減のための、きめ細かな制御が可能になります。 位置情報およびレイテンシーベースのルーティングは、Route 53 により収集され最新の状態に維持されているデータに基づいています。このアプローチは大多数の顧客にとってうまく機能しますが、IP ベースのルーティングを使用することで、顧客ごとに特有な情報に基づいてルーティングを最適化できる追加機能が提供されます。例えば、グローバルな動画コンテンツプロバイダーが、特定のインターネットサービスプロバイダー (ISP) からエンドユーザーをルーティングする場合があります。 以下に、IP ベースルーティングでの一般的なユースケースを示します。 + ネットワーク伝送コストやパフォーマンスを最適化するために、特定の ISP から特定のエンドポイントにエンドユーザーをルーティングしたい場合。 + クライアントの物理的な場所に関する情報に基づいて、位置情報ルーティングなど、既存の Route 53 ルーティングタイプにオーバーライドを追加したい場合。 **IP 範囲の管理とリソースレコードセット (RRSet) への関連付け** IPv4 では長さ 1 ～ 24 ビットの CIDR ブロックを使用できますが、IPv6 では 1 ～ 48 ビットの長さの CIDR ブロックを使用できます。ゼロビット CIDR ブロック (0.0.0.0/0 または ::/0) を定義するには、デフォルト (「\$1」) の場所を使用します。 CIDR コレクションで指定されたものよりも長い CIDR を持つ DNS クエリの場合、Route 53 はそれを短い CIDR と一致させます。例えば、CIDR コレクションの CIDR ブロックとして 2001:0DB8::/32 を指定し、クエリが 2001:0DB8:0000:1234::/48 から発信された場合、そのクエリは一致します。一方、CIDR コレクションで 2001:0DB8:0000:1234::/48 を指定し、クエリが 2001:0DB8::/32 から発信された場合、これは一致せず、Route 53 はデフォルト (「\$1」) ロケーションのレコードで応答します。 CIDR ブロック (または IP 範囲) のセットは、CIDR ロケーション内にグループ化することができ、このグループは以下のように、CIDR コレクションと呼ばれる再利用可能なエンティティにグループ化されます。 **CIDR ブロック** CIDR 表記での IP 範囲。例:192.0.2.0/24 または 2001:DB8::/32。 **CIDR ロケーション** CIDR ブロックの名前付きリスト。これは例えば、example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001:DB8::/32 ]、のようになります。CIDR ロケーションリスト内のブロックは、隣接している必要や、同じ範囲である必要はありません。 IPv4 ブロックと IPv6 ブロックの両方を単一のロケーションに含めることが可能で、このロケーションはそれぞれ A レコードセットと AAAA レコードセットの両方に関連付けることができます。 慣例では、このロケーション名は土地の名前であることが多いですが、任意の文字列でも問題ありません (*Company-A* など)。 **CIDR コレクション** 名前付きロケーションのコレクション。これは例えば、mycollection = [example-isp-seattle, example-isp-tokyo] のようになります。 IP ベースのルーティングリソースレコードセットはコレクション内のロケーションを参照します。同じ名前とタイプのレコードセットでは、すべてのリソースレコードセットが同じコレクションを参照する必要があります。例えば、2 つのリージョンに Web サイトを作成し、これら 2 つの異なる CIDR ロケーションから、発信元 IP アドレスに基づいて特定の Web サイトに DNS クエリを送信する場合は、それらの両方のロケーションを同じ CIDR コレクションにリストする必要があります。 IP ベースルーティングポリシーは、プライベートホストゾーンのレコードに使用できません。 シンプルルーティングポリシーを使用してレコードを作成する際に指定する値については、以下のトピックを参照してください。 + [IP ベースレコード特有の値](resource-record-sets-values-ipbased.md) + [IP ベースエイリアスレコードに特有の値](resource-record-sets-values-ipbased-alias.md) + [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md) + [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md) **Topics** + [Creating a CIDR collection with CIDR locations and blocks (CIDR ロケーションとブロックを使用した CIDR コレクションの作成)](resource-record-sets-creating-cidr-collection.md) + [CIDR ロケーションと CIDR ブロックの操作](resource-record-sets-working-with-cidr-locations.md) + [CIDR コレクションの削除](resource-record-sets-delete-cidr-collection.md) + [位置情報ルーティングの IP ベースのルーティングへの移動](resource-record-sets-move-geolocation-to-cidr.md) # Creating a CIDR collection with CIDR locations and blocks (CIDR ロケーションとブロックを使用した CIDR コレクションの作成) 使用を開始するには、CIDR コレクションを作成し、そのコレクションに CIDR ブロックとロケーションを追加します。 **Route 53 コンソールを使用して CIDR コレクションを作成するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで、**[IP-based routing]** (IP ベースルーティング)、**[CIDR collections]** (CIDR コレクション) の順に選択します。 1. **[Create CIDR collection]** (CIDR コレクションを作成) を選択します。 1. **[Create CIDR collection]** (CIDR コレクションの作成) ペインで、**[Details]** (詳細) の下にコレクションの名前を入力します。 1. **[Create collection]** (コレクションを作成) を選択し、空のコレクションを作成します。 - または - **[CIDR ロケーションの作成]** セクションの**[CIDR ロケーション]**ボックスに CIDR ロケーションの名前を入力します。ロケーション名には、識別できる任意の文字列を使用できます。例えば **company 1**、または **Seattle** などです。これらは、実際の地理的な名前でなくても問題ありません。 **重要** CIDR ロケーション名の最大長は 16 文字です。 **[CIDR ブロック]** ボックスに CIDR ブロックを 1 行に 1 つずつ入力します。これらの指定には、IPv4 アドレス (/0 から /24 の範囲) または IPv6 アドレス (/0 から /48 の範囲) を使用します。 1. さらにロケーションと CIDR ブロックの入力を続ける場合は、CIDR ブロックを入力した後、**[Create CIDR collection]** (CIDR コレクションを作成) または **[Add another location]** (別のロケーションを追加) を選択します。コレクションごとに複数の CIDR ロケーションを入力できます。 1. CIDR ロケーションを入力し終えたら、**[Create CIDR collection]** (CIDR コレクションを作成) を選択します。 # CIDR ロケーションと CIDR ブロックの操作 **Route 53 コンソールから CIDR ロケーションを操作するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで、**[IP-based routing]** (IP ベースルーティング)、**[CIDR collections]** (CIDR コレクション) の順に選択した後、**[CIDR collections]** (CIDR コレクション) セクションで **[Collection name]** (コレクション名) リストの [CIDR collections] (CIDR コレクション) へのリンクをクリックします。 **[CIDR locations]** (CIDR ロケーション) ページでは、CIDR ロケーションの作成や削除、ロケーションとそのブロックの編集を行うことができます。 + **[Create CIDR location]** (CIDR ロケーションを作成) を選択し、ロケーションを作成します。 + **[Create CIDR location]** (CIDR ロケーションの作成) ペインで、ロケーションとロケーションに関連付けられた CIDR ブロックの名前をそれぞれ入力し、**[Create]** (作成) を選択します。 + CIDR ロケーションと内部のブロックを表示するには、ロケーションペインで、名前と CIDR ブロックを表示する対象のロケーションの横にあるラジオボタンをオンにします。 このペインにある **[編集]** をクリックすると、ロケーションと CIDR ブロックの名前を更新することもできます。編集が完了したら、**[Save]** (保存) を選択します。 + CIDR ロケーションとその中のブロックを削除するには、削除する対象のロケーションの横でラジオボタンをオンにし、次に **[Delete]** (削除) を選択します。削除されたことを確認するには、テキスト入力フィールドにロケーション名を入力した上で、もう一度、**[Delete]** (削除) を選択します。 **重要** 削除された CIDR ロケーションは元に戻せません。削除ロケーションに DNS レコードを関連付けている場合、使用しているドメインに到達できなくなる可能性があります。 # CIDR コレクションの削除 **Route 53 コンソールを使用して、CIDR コレクション、そのロケーション、およびブロックを削除するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで、**[IP-based routing]** (IP ベースルーティング)、**[CIDR collections]** (CIDR コレクション) の順に選択します。 1. **[CIDR collections]** (CIDR コレクション) セクションで、削除するコレクションとリンクしている名前を選択します。 1. **[CIDR locations]** (CIDR ロケーション) ページで、1 つずつ各ロケーションを 選択した上で **[Delete]** (削除) を選択し、ダイアログボックスに対象の名前を入力した後、**[Delete]** (削除) を選択します。CIDR コレクションに関連付けられている個々のロケーションを削除した後、そのコレクションを削除できるようになります。 1. 各 CIDR ロケーションの削除が完了したら、**[CIDR locations]** (CIDR ロケーション) ページで、削除するコレクションの横にあるラジオボタンをオンにした上で、**[Delete]** (削除) を選択します。 # 位置情報ルーティングの IP ベースのルーティングへの移動 地理的な位置情報ルーティング、または地理的な近接ルーティングポリシーのいずれかを使用しており、物理的な場所やネットワークトポロジにとって最適ではないエンドポイントに、特定のクライアントが一貫してルーティングされている場合には、IP ベースルーティングを使用することで、これらのクライアントのパブリック IP 範囲をより適切にターゲットできます。 次の表に、既存の位置情報ルーティングでカリフォルニア IP 範囲を微調整する場合の、地理的な位置情報設定の例を示します。 | レコードセット名 | ルーティングポリシーと送信元 | アプリケーションエンドポイントの IP アドレス | | --- | --- | --- | | example.com | 位置情報ルーティング (米国) | `198.51.100.1` | | example.com | 位置情報ルーティング (欧州) | `198.51.100.2` | カリフォルニア州からの IP 範囲を上書きして新しいアプリケーションエンドポイントに移動させるには、初めに、新しいレコードセット名を使用して位置情報ルーティングを再作成します。 | レコードセット名 | ルーティングポリシーと送信元 | アプリケーションエンドポイントの IP アドレス | | --- | --- | --- | | geo.example.com | 位置情報ルーティング (米国) | `198.51.100.1` | | geo.example.com | 位置情報ルーティング (欧州) | `198.51.100.2` | 次に、新たに再作成した位置情報ルーティングレコードセットを指す、IP ベースのルーティングレコードとデフォルトレコードを作成します。 | レコードセット名 | ルーティングポリシーと送信元 | アプリケーションエンドポイントの IP アドレス | | --- | --- | --- | | example.com | IP ベースルーティング (デフォルト) | デフォルトに設定する、アプリケーションエンドポイント (geo.example.com) へのエイリアスレコード。例えば、`198.51.100.1`。 | | example.com | IP ベースルーティング (カリフォルニア IP 範囲) | `198.51.100.3` | # 複数値回答ルーティング 複数値回答ルーティングにより、Amazon Route 53 が DNS クエリに対する応答として複数の値 (ウェブサーバーの IP アドレスなど) を返すように設定できます。ほとんどすべてのレコードに複数値を指定できますが、複数値回答ルーティングは各リソースが正常かどうかも確認するため、Route 53 は正常なリソースの値のみを返します。これはロードバランサーに置き換わるものではありませんが、正常であることが確認できる複数の IP アドレスを返す機能により、DNS を使用してアベイラビリティーとロードバランシングを向上させることができます。 トラフィックを複数のリソース (ウェブサーバーなど) にほぼランダムにルーティングするには、各リソースに対し複数値回答のレコードを 1 つ作成します。また、オプションで各レコードに Route 53 ヘルスチェックを関連付けます。Route 53 は最大 8 つの正常なレコードを持つ DNS クエリに応答し、DNS リゾルバーごとに異なる回答を返します。リゾルバーが応答をキャッシュした後にウェブサーバーが使用できなくなる場合、クライアントソフトウェアは応答内の別の IP アドレスを試ことができます。 次の点に注意してください。 + ヘルスチェックを複数値回答のレコードと関連付けている場合、Route 53 はヘルスチェックの結果が正常である場合にのみ、対応する IP アドレスを DNS クエリに返します。 + ヘルスチェックを複数値回答レコードと関連付けない場合、Route 53 は常にレコードを正常であると見なします。 + 8 つ以下の正常なレコードがある場合、Route 53 はすべての DNS クエリに正常なすべてのレコードを返します。 + すべてのレコードが異常である場合、Route 53 は DNS クエリに最大 8 つの異常なレコードを返します。 複数値回答ルーティングポリシーは、プライベートホストゾーンのレコードに使用できます。 複数値回答ルーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、[複数値回答レコードに固有の値](resource-record-sets-values-multivalue.md) および [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md) を参照してください。 # 加重ルーティング 加重ルーティングにより、単一のドメイン名 (example.com) またはサブドメイン名 (acme.example.com) に複数のリソースを関連付け、各リソースにルーティングされるトラフィックの数を選択できます。これは負荷分散や新しいバージョンのソフトウェアのテストなど、さまざまな目的に有用です。 加重ルーティングを設定するには、各リソース同じ名前とタイプでレコードを作成します。各リソースに送信するトラフィックの数に対応する相対的な重みを各レコードに割り当てます。グループ内のすべてのレコードの重みの合計に対する割合として、Amazon Route 53 はレコードに割り当てられた重みに基づいてリソースにトラフィックを送信します。 ![\[特定のリソースにルーティングされるトラフィック量を表す式: 特定のレコードの重み/すべてのレコードの重みの合計\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/WRR_calculation.png) 例えば、トラフィックのごく一部を 1 つのリソースに送信し、残りを別のリソースに送信する場合、重みとして 1 つ 255 を指定します。重みが 1 のリソースは、トラフィックの 1/256 (1/(1\$1255)) を、他のリソースは 255/256 (255/(1\$1255)) を取得します。重みを変更するとバランスは徐々に変更できます。リソースへのトラフィックの送信を停止するには、レコードの重みを 0 に変更します。 加重ルーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、以下のトピックを参照してください。 + [加重レコードに固有の値](resource-record-sets-values-weighted.md) + [加重エイリアスレコードに固有の値](resource-record-sets-values-weighted-alias.md) + [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md) + [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md) 加重ルーティングポリシーは、プライベートホストゾーンのレコードに使用できます。 ## ヘルスチェックと加重ルーティング 加重レコードのグループ内のすべてのレコードにヘルスチェックを追加する一方で、一部のレコードにゼロ以外の重みを付け、他のレコードの重みをゼロにした場合、ヘルスチェックは、次の例外を除いて、すべてのレコードの重みがゼロ以外の場合と同様に動作します。 + 最初に Route 53 は、ゼロ以外の加重レコード (存在する場合) のみを対象とします。 + 重みが 0 より大きいレコードがいずれも異常であった場合、Route 53 は、重みがゼロである加重レコードを対象にします。 次の表は、重みが 0 のレコードにヘルスチェックが含まれる場合の動作の詳細を示しています。 | | レコード 1 | レコード 2 | レコード 3 | | --- |--- |--- |--- | | 重み | 1 | 1 | 0 | | ヘルスチェックが含まれていますか? | はい | はい | はい | | | | --- | | ヘルスチェックステータス | 異常 | 異常 | 正常 | | DNSクエリに回答しましたか? | いいえ | なし | はい | | | | --- | | ヘルスチェックステータス | 異常 | 異常 | 異常 | | DNS query answered? | はい | あり | なし | | | | --- | | ヘルスチェックステータス | 異常 | 正常 | 異常 | | DNSクエリに回答しましたか? | いいえ | あり | なし | | | | --- | | ヘルスチェックステータス | 正常 | 正常 | 異常 | | DNSクエリに回答しましたか? | はい | あり | なし | | | | --- | | ヘルスチェックステータス | 正常 | 正常 | 正常 | | DNSクエリに回答しましたか? | はい | あり | なし | 次の表は、重みが 0 のレコードにヘルスチェックが含まれない場合の動作の詳細を示しています。 | | レコード 1 | レコード 2 | レコード 3 | | --- |--- |--- |--- | | 重み | 1 | 1 | 0 | | ヘルスチェックが含まれていますか? | はい | あり | なし | | | | --- | | ヘルスチェックステータス | 正常 | 正常 | N/A | | DNS query answered? | Yes | はい | No | | | | --- | | ヘルスチェックステータス | 異常 | 異常 | 該当なし | | DNSクエリに回答しましたか? | いいえ | なし | はい | | | | --- | | ヘルスチェックステータス | 異常 | 正常 | 該当なし | | DNS query answered? | いいえ | あり | なし | # Amazon Route 53 が EDNS0 を使用してユーザーの場所を推定する方法 位置情報、地理的近接性、IP ベース、およびレイテンシーに関するルーティングの精度を高めるために、Amazon Route 53 は EDNS0 の edns-client-subnet 拡張をサポートしています (EDNS0 では、DNS プロトコルにオプションの拡張がいくつか追加されています)。Route 53 では、DNS リゾルバーが edns-subnet をサポートしている場合のみ、edns-subnet を使用できます。 + ブラウザまたは他のビューアが edns-client-subnet をサポートしない DNS リゾルバーを使用している場合、Route 53 は DNS リゾルバーのソース IP アドレスを使ってユーザーのおよその場所を特定し、位置情報クエリにリゾルバーの場所の DNS レコードを返します。 + ブラウザまたは他のビューアが edns-client-subnet をサポートする DNS リゾルバーを使用している場合、DNS リゾルバーはユーザーの IP アドレスを切り捨てたアドレスを Route 53 に送信します。Route 53 は、DNS リゾルバーのソース IP アドレスではなく切り捨てられた IP アドレスに基づいてユーザーの場所を判断します。通常は、この方がユーザーの場所をより正確に推定できます。Route 53 は、ユーザーの場所の DNS レコードを位置情報クエリに返します。 + EDNS0 は、プライベートホストゾーンには適用されません。プライベートホストゾーンの場合、Route 53 は、プライベートホストゾーン AWS リージョン がある の VPC リゾルバーからのデータを使用して、位置情報とレイテンシーのルーティングを決定します。 edns-client-subnet の詳細については、EDNS Client Subnet RFC の「[DNS リクエストのクライアントサブネット](https://www.rfc-editor.org/rfc/rfc7871)」を参照してください。