本記事はアジアクエスト Advent Calendar 2025の記事です。
アジアクエスト クラウドインテグレーション部の須藤匠です。
過去に参画したハイブリッドクラウド案件で直面したInterfaceエンドポイントとRoute 53 Resolverを組み合わせたマルチアカウント名前解決における課題と、課題を解消するための設計と実装ポイントを解説します。
「オンプレミスとAWSをDirect Connect（DX）でプライベート接続しているにもかかわらず、一部AWSサービスへアクセスする際の宛先がパブリックIPアドレスとなってしまう」という事象が発生しました。PJの要件、あるいはオンプレミス側のネットワークの設定でパブリックIPアドレス宛の通信が禁止されている場合、プライベートIPアドレス内で通信が完結しないとAWS Systems Manager（SSM）のHybrid Activationなどの重要な処理が失敗し、支障をきたすケースがあります。
この問題の原因は、Gatewayエンドポイント使用時に「通信経路はプライベートでも、DNSの名前解決結果がパブリックIPアドレスになっている」という点にありました。
つまり、ネットワーク的にはAWSバックボーンを経由していても、名前解決の段階でパブリック通信判定になってしまうのです。
当初の設計ではS3のGatewayエンドポイントとSSMのInterfaceエンドポイントを利用していましたが、なぜかオンプレミスからの通信がブロックされるという問題が発生していました。
| 観点 | Gatewayエンドポイント利用時の挙動 |
|---|---|
| 通信経路 | ルーティングテーブルによりAWSバックボーン内を通過（インターネット経由ではない） |
| 名前解決 | AmazonProvidedDNSがパブリックIPアドレスを返す |
関係者にヒアリングし、通信経路自体はプライベートであっても、名前解決結果がパブリックIPアドレスのため、オンプレミス側のファイアウォールポリシーに抵触して通信が拒否されていたことが判明しました。
S3 Gatewayエンドポイント利用時におけるVPC内からの名前解決の挙動を詳しく確認します。
VPC内のインスタンスがS3エンドポイント名を問い合わせる場合、そのクエリは常にVPC内のDNSリゾルバーであるAmazonProvidedDNSに送信されます。
nslookupによる例（Gatewayエンドポイント利用時）
$ nslookup s3.ap-northeast-1.amazonaws.com
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
Name: s3.ap-northeast-1.amazonaws.com
Address: 52.219.150.28
# 以下略
Gatewayエンドポイントは通信経路を変更するだけであり、名前解決の応答自体を変更してプライベートIPを返す機能はありません。
つまり、クライアントが通信を開始する際の宛先IPはパブリックとなるため、オンプレミス側で厳格なポリシーが存在する場合では問題となります。
※この「パブリックIPアドレス」宛のGatewayエンドポイントへの通信はインターネットを通るわけではありません。
詳細は以下の公式FAQを参照してください。
参考：Amazon VPC のよくある質問
問題を根本的に解決し、S3へのアクセスを完全にVPCのプライベートIP空間で完結させるために、Interfaceエンドポイントへの置換を実行しました。
Interfaceエンドポイントに移行すると、名前解決の挙動が変化します。
これにより、クライアントは最初からプライベートIPアドレス宛に通信を開始するため、オンプレミス側ポリシーへの抵触という問題（パブリックIPアドレスが宛先となる通信の発生）が解消されます。
オンプレミス環境からAWSサービス（例：S3）へのアクセスを完全にプライベート通信として実現するため、 InterfaceエンドポイントのプライベートIPアドレスがAWSサービスの名前解決結果となるようにRoute 53 Resolverを設定します。
例として、以下のような構成を想定します。
オンプレ
↓（オンプレDNSによるフォワード）
共通サービスアカウント（Route 53 Resolverインバウンドエンドポイント&アウトバウンドエンドポイント有り）
↓（Route 53 Resolver転送ルールによるフォワード）
ファイル共有アカウント（Interfaceエンドポイント有り）
↓
AWSサービス（例：S3）
両アカウントのVPCはTransit Gateway（TGW） で接続されており、共通サービスアカウントのRoute 53 Resolverは、特定のドメイン（例：s3.ap-northeast-1.amazonaws.com.）に対するDNSクエリをファイル共有アカウントのVPC内AmazonProvidedDNSへフォワードする設定とします。
ファイル共有アカウントでは、対象となるAWSサービス（例：S3）に対して Interfaceエンドポイントを作成します。
※プライベートDNS名の有効化が必要です。
これにより、VPC内のAmazonProvidedDNSはs3.ap-northeast-1.amazonaws.com に対してエンドポイントの プライベートIPアドレスを返すようになります。
このDNS応答はAWS内部で自動的に管理されるため、Route 53 Private Hosted Zone（PHZ）を作成したり、レコードを登録したりする必要はありません。
共通サービスアカウントでは、オンプレミスからのDNSクエリを受け取り、ファイル共有アカウントへフォワードするためのRoute 53 Resolver構成を用意します。
s3.ap-northeast-1.amazonaws.com などの目的のサービスのドメイン名に対するクエリを、TGW経由でファイル共有アカウントのVPC CIDR +2（AmazonProvidedDNS） に転送するよう設定これにより、共通サービスアカウントやオンプレミスからのDNSクエリがファイル共有VPCのAmazonProvidedDNSへ転送され、InterfaceエンドポイントのプライベートIPが返されるようになります。
オンプレミスのDNSサーバーでは、AWSサービスのドメイン（例：s3.ap-northeast-1.amazonaws.com）へのクエリを共通サービスアカウントのRoute 53 Resolverアウトバウンドエンドポイントへ転送するように設定します。
この転送経路により、オンプレミスのクライアントはAWSバックボーン上のプライベートDNS経路を通じてAWSサービスに到達できるようになります。
s3.ap-northeast-1.amazonaws.com を問い合わせるこのように、PHZやレコード登録を行わなくても、InterfaceエンドポイントのプライベートDNS機能により自動的にプライベートIPが返されるため、設計がシンプルになり、レコード管理の運用コストも不要です。