構成

構成は以下の通り。

CloudFrontではIPv6を有効にし、Route 53にはAレコードとAAAAレコードのAliasを登録していた。

症状

主な症状は以下。

CloudFrontでは接続元などに応じて複数のエッジIPが返されるため、AAAAレコードの回答が毎回異なること自体は異常でないと判断。

問題は、IPv6経由の通信がかなり不安定だったことだった。

Windows環境で、IPv4とIPv6を明示して curl を実行した。

curl.exe -4 -I https://cress.cc/
curl.exe -6 -I https://cress.cc/

IPv4を指定した場合は正常に応答する一方、IPv6を指定した場合は接続リセットが頻発した。

この結果から、S3オリジンやCloudFrontのキャッシュ設定ではなく、クライアントからCloudFrontまでのIPv6経路に問題があると判断した。

HTTPの403、502、503、504などが返るのではなく、通信自体が途中でリセットされていたことも、オリジン側ではなく通信経路側の問題と考える材料になった。

以下の対応を行った。

CloudFrontの対象ディストリビューションを開き、IPv6を無効にした。

設定変更後、CloudFrontのデプロイが完了するまで待つ。

CloudFrontでIPv6を無効にした後、Route 53に登録していたAAAAレコードのAliasを削除した。

AレコードのAliasはそのまま残した。

これにより、独自ドメインへのアクセスをIPv4に限定した。

IPv6を無効にしてAAAAレコードを削除したところ、接続リセットは発生しなくなった。

Google Search Consoleから取得できなかったサイトマップについても、IPv6経由でCloudFrontへの接続に失敗していた可能性が高い。

CloudFrontでIPv6を無効にした直後は、設定が各エッジへ反映されるまで多少時間がかかる。

また、端末やルーター、DNSリゾルバにAAAAレコードがキャッシュされている場合がある。

Windowsでは、必要に応じて以下を実行する。

ipconfig /flushdns

ブラウザも完全に終了してから再起動する。

CloudFront + S3で以下のような症状が出た場合、IPv6経路を疑う価値がある。

切り分けには、次の2コマンドが有効だった。

curl.exe -4 -I https://example.com/
curl.exe -6 -I https://example.com/

IPv6側だけ失敗する場合は、CloudFrontのIPv6を無効化し、Route 53のAAAAレコードを削除することで改善する可能性がある。