Route 53 アウトバウンドエンドポイント使用時の送信元IPについて

Last updated at 2026-01-23Posted at 2026-01-16

概要

Route 53 Resolverのアウトバウンドエンドポイントを利用してオンプレミスの名前解決を行う際、疎通がうまくいかないケースに遭遇しました。

AWS上のEC2（Windows Server）から、オンプレミス側のドメインを名前解決しようとしたところ、応答が返ってこない事象が発生しました。

簡易構成図

原因は、オンプレミス側に到達するDNSクエリの送信元IPアドレスにありました。

EC2から名前解決を試行した場合でも、Route53転送ルールなどでアウトバウンドエンドポイントを使用する場合、オンプレミス側に届くパケットの送信元は**「EC2のIP」ではなく「アウトバウンドエンドポイント（ENI）のIP」**となります。

実際にどのような挙動になっているか、2つのポイントで確認を行いました。

EC2だけでなく、アウトバウンドエンドポイントに関連付けられたENIのフローログを確認します。

VPCを押下→フローログタブを押下→ログを確認(自環境だとS3だった)

AWSから射出されたパケットが、境界デバイス（ファイアウォール/ルーター）およびターゲットのDNSサーバーに到達しているかを確認します。

ログの検証結果: アウトバウンドエンドポイントのIPを送信元とするリクエストの到達を確認。

補足: 確認コマンドやログの確認場所は、利用しているネットワーク機器（Cisco, Palo Alto, Fortinet等）やOSの仕様に準じます。

検証結果に基づき、以下の3点においてアウトバウンドエンドポイントのIPを許可するよう見直しを行いました。

エンドポイント自体に適用されているセキュリティグループのアウトバウンドルールで、オンプレミスDNSサーバーへの53番ポート通信を許可されていることを確認。

アウトバウンドエンドポイントが配置されているサブネットのルートテーブルで、オンプレミス側ネットワーク宛のターゲットに向いていることを確認。

ファイアウォール/ルーター: アウトバウンドエンドポイントのIPからの通信を許可。
DNSサーバー（ACL）: サーバー側で、アウトバウンドエンドポイントのIPからのクエリを許可するよう修正。
初期調査ではオンプレミス側でアウトバウンドエンドポイントのIPが拒否対象となっていたため、ここを修正したことで名前解決が正常化しました

ハイブリッド環境におけるDNSの疎通確認では、パケットの送信元IPも意識することが必要ですね。