ウェブコンテンツのトラフィックが間違った CloudFront エッジロケーションにルーティングされるのはなぜですか?

簡単な説明

CloudFront は、ディストリビューションの料金クラス、関連する位置情報データベース、EDNS0-Client-Subnet のサポートに基づいてトラフィックをルーティングします。これらの要因の組み合わせによっては、ウェブサイトの閲覧者が予期しないエッジロケーションにルーティングされる場合があります。これにより、CloudFront エッジロケーションからオブジェクトを取得するための全体的なレイテンシーが増加する可能性があります。

予期しないエッジ位置へのルーティングのトラブルシューティングを行うには、次を確認してください。

• 価格クラスは、予想するエッジロケーションをサポートしている。
• DNS リゾルバーは、Anycast ルーティングをサポートしている。
• DNS リゾルバーは、EDNS0-Client-Subnet をサポートしている。

解決方法

価格クラスは予想するエッジロケーションをサポートしている

CloudFront ディストリビューションの価格クラスに含まれるエッジロケーションを確認します。他のエッジロケーションを含める場合は、ディストリビューションの価格クラスを更新できます。

DNS リゾルバーは Anycast ルーティングをサポートしている

DNS リゾルバーが Anycast ルーティングをサポートしている場合、DNS リゾルバーが使用する複数のエッジロケーションがあります。これは、リクエスタのエッジロケーションが最適なレイテンシーに基づいていることを意味し、リゾルバーの IP アドレスが予期しないロケーションになる可能性があります。

DNS リゾルバーが Anycast をサポートしているかどうかを確認するには、次のコマンドのいずれかを複数回実行します。

注: これらのコマンド例では、example.com を、使用している DNS リゾルバーのドメイン名に置き換えてください。

Linux または macOS で、次のような dig コマンドを実行します。

dig +nocl TXT o-o.myaddr.l.example.com

Windows では、次のような nslookup コマンドを実行します。

nslookup -type=txt o-o.myaddr.l.example.com

コマンドを実行するたびに出力に同じ IP アドレスが含まれる場合、DNS リゾルバーは Anycast をサポートしていません。コマンドを実行するたびに出力に異なる IP アドレスが含まれる場合、DNS リゾルバーは Anycast をサポートしています。これが原因となって、予期しないエッジロケーションが使用されている場合があります。

DNS リゾルバーは EDNS0-Client-Subnet をサポートしている

誤ったルーティングを回避する方法を確認するには、まず、次のコマンドのいずれかを実行して、DNS リゾルバーが EDNS0-Client-Subnet をサポートしているかどうかを確認します。

注: これらのコマンド例では、example.com を、使用している DNS リゾルバーのドメイン名に置き換えてください。

Linux または macOS で、次のような dig コマンドを実行します。

dig +nocl TXT o-o.myaddr.l.example.com

Windows では、次のような nslookup コマンドを実行します。

nslookup -type=txt o-o.myaddr.l.example.com

注意: TTL 値を確認し、TTL の有効期限が切れたら必ずコマンドを実行してください。それ以外の場合、再帰的なリゾルバーからキャッシュされたレスポンスが返されることがあります。

DNS リゾルバーが EDNS0-Client-Subnet をサポートしていない場合、出力は次のようになります。

$ dig +nocl TXT o-o.myaddr.l.example.com  +short
"192.0.2.1"

前の例では、192.0.2.1 は、Anycast を使用している最も近い DNS サーバーの IP アドレスです。この DNS リゾルバーは EDNS0-Client-Subnet をサポートしていません。誤ったルーティングを回避するには、次のいずれかを実行できます。

• DNS リゾルバーを、ウェブサイトのクライアントに地理的に近い場所にある再帰的な DNS リゾルバーに変更します。
• EDNS0-Client-Subnet をサポートする DNS リゾルバーに変更します。

DNS リゾルバーが EDNS0-Client-Subnet をサポートしている場合、出力には、次のような CloudFront 権威ネームサーバーへの切り詰められたクライアントサブネット (/24 または /32) が含まれます。

$ dig +nocl TXT o-o.myaddr.l.example.com @8.8.8.8 +short
"192.0.2.1"
"edns0-client-subnet 198.51.100.0/24"

前の例では、192.0.2.1 が最も近い DNS リゾルバー IP アドレスです。さらに、クライアントサブネットの範囲は 198.51.100.0/24 で、DNS クエリへのレスポンスに使用します。DNS リゾルバーが EDNS0-Client-Subnet をサポートしている場合に誤ったルーティングを回避するには、パブリック位置情報データベースが、DNS リゾルバーにクエリを送信するクライアントサブネット範囲に関連付けられていることを確認します。DNS リゾルバーがクライアント IP アドレスの切り捨てられたバージョンを CloudFront ネームサーバーに転送している場合、CloudFront はいくつかのパブリック位置情報データベースに基づくデータベースをチェックします。リクエストが正しくルーティングされるように、IP アドレスを位置情報データベースに正しくマップする必要があります。

DNS リゾルバーが EDNS0-Client-Subnet をサポートしている場合、dig などの DNS ルックアップコマンドを実行して CloudFront CNAME を最初に解決することにより、次のようにトラフィックがルーティングされるエッジロケーションを確認できます。

$ dig dftex7example.cloudfront.net. +short
13.224.77.109
13.224.77.62
13.224.77.65
13.224.77.75

次に、前のコマンドで返された IP アドレスで DNS リバースルックアップを次のように実行します。

$ dig -x 13.224.77.62 +short
server-13-224-77-62.man50.r.cloudfront.net.

前の例では、トラフィックはマンチェスターのエッジロケーションにルーティングされます。

ヒント: 追加のテストでは、8.8.8.8 または 8.8.4.4 など、EDNS0-client-subnet をサポートするパブリック DNS リゾルバーを使用できます。エッジロケーションの IP アドレスを含むクエリをパブリック DNS リゾルバーに送信します。その後、DNS クエリの結果を確認して、CloudFront に EDNS0-client-subnet に関する正しい情報があるかどうかを確認します。

---