本記事はアジアクエスト Advent Calendar 2025の記事です。
はじめに
アジアクエスト クラウドインテグレーション部の須藤匠です。
過去に参画したハイブリッドクラウド案件で直面したInterfaceエンドポイントとRoute 53 Resolverを組み合わせたマルチアカウント名前解決における課題と、課題を解消するための設計と実装ポイントを解説します。
1. 課題：Hybrid Activationが失敗した背景
「オンプレミスとAWSをDirect Connect（DX）でプライベート接続しているにもかかわらず、一部AWSサービスへアクセスする際の宛先がパブリックIPアドレスとなってしまう」という事象が発生しました。PJの要件、あるいはオンプレミス側のネットワークの設定でパブリックIPアドレス宛の通信が禁止されている場合、プライベートIPアドレス内で通信が完結しないとAWS Systems Manager（SSM）のHybrid Activationなどの重要な処理が失敗し、支障をきたすケースがあります。
この問題の原因は、Gatewayエンドポイント使用時に「通信経路はプライベートでも、DNSの名前解決結果がパブリックIPアドレスになっている」という点にありました。
つまり、ネットワーク的にはAWSバックボーンを経由していても、名前解決の段階でパブリック通信判定になってしまうのです。
根本原因：Gatewayエンドポイントの名前解決の挙動
当初の設計ではS3のGatewayエンドポイントとSSMのInterfaceエンドポイントを利用していましたが、なぜかオンプレミスからの通信がブロックされるという問題が発生していました。
| 観点 | Gatewayエンドポイント利用時の挙動 |
|---|---|
| 通信経路 | ルーティングテーブルによりAWSバックボーン内を通過（インターネット経由ではない） |
| 名前解決 | AmazonProvidedDNSがパブリックIPアドレスを返す |
関係者にヒアリングし、通信経路自体はプライベートであっても、名前解決結果がパブリックIPアドレスのため、オンプレミス側のファイアウォールポリシーに抵触して通信が拒否されていたことが判明しました。
2. Gatewayエンドポイントの「パブリックIPアドレス」の真実
S3 Gatewayエンドポイント利用時におけるVPC内からの名前解決の挙動を詳しく確認します。
2.1. 名前解決のプロセスとAmazonProvidedDNS
VPC内のインスタンスがS3エンドポイント名を問い合わせる場合、そのクエリは常にVPC内のDNSリゾルバーであるAmazonProvidedDNSに送信されます。
- 問い合わせ先： DNSクエリは、VPCのDHCPオプションセットでデフォルトで指定されているAmazonProvidedDNS（VPC CIDR +2のIPアドレスをもつDNSサーバ）に送信されます
- 回答： Gatewayエンドポイントが設定されている場合でも、AmazonProvidedDNSはS3サービスのパブリックIPアドレスを返します
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 のよくある質問
3. 解決策：InterfaceエンドポイントによるプライベートIP解決の強制
問題を根本的に解決し、S3へのアクセスを完全にVPCのプライベートIP空間で完結させるために、Interfaceエンドポイントへの置換を実行しました。
3.1. Interfaceエンドポイントへの移行（プライベートIPの確保）
Interfaceエンドポイントに移行すると、名前解決の挙動が変化します。
- プライベートIPの付与： InterfaceエンドポイントはVPC内にENIを作成し、VPC内のプライベートIPアドレスが付与されます
- 名前解決の変化： Interfaceエンドポイント作成後、AmazonProvidedDNSはS3のエンドポイント名に対して、ENIに割り当てられたプライベートIPアドレスを応答するようになります
これにより、クライアントは最初からプライベートIPアドレス宛に通信を開始するため、オンプレミス側ポリシーへの抵触という問題（パブリックIPアドレスが宛先となる通信の発生）が解消されます。
3.2. ハイブリッド&マルチアカウント環境でのDNSの構築
オンプレミス環境から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へフォワードする設定とします。
3.2.1. ファイル共有アカウント側の設定
ファイル共有アカウントでは、対象となるAWSサービス（例：S3）に対して Interfaceエンドポイントを作成します。
※プライベートDNS名の有効化が必要です。
これにより、VPC内のAmazonProvidedDNSはs3.ap-northeast-1.amazonaws.com に対してエンドポイントの プライベートIPアドレスを返すようになります。
このDNS応答はAWS内部で自動的に管理されるため、Route 53 Private Hosted Zone（PHZ）を作成したり、レコードを登録したりする必要はありません。
3.2.2. 共通サービスアカウント側の設定
共通サービスアカウントでは、オンプレミスからのDNSクエリを受け取り、ファイル共有アカウントへフォワードするためのRoute 53 Resolver構成を用意します。
- Route 53 Resolverアウトバウンドエンドポイント
- オンプレミスネットワークからのクエリを受け取り、AWS側に転送するエンドポイントです
- フォワードルール
s3.ap-northeast-1.amazonaws.comなどの目的のサービスのドメイン名に対するクエリを、TGW経由でファイル共有アカウントのVPC CIDR +2（AmazonProvidedDNS） に転送するよう設定
これにより、共通サービスアカウントやオンプレミスからのDNSクエリがファイル共有VPCのAmazonProvidedDNSへ転送され、InterfaceエンドポイントのプライベートIPが返されるようになります。
3.2.3. オンプレミス環境での設定
オンプレミスのDNSサーバーでは、AWSサービスのドメイン（例：s3.ap-northeast-1.amazonaws.com）へのクエリを共通サービスアカウントのRoute 53 Resolverアウトバウンドエンドポイントへ転送するように設定します。
この転送経路により、オンプレミスのクライアントはAWSバックボーン上のプライベートDNS経路を通じてAWSサービスに到達できるようになります。
3.3. プライベートIP解決フロー（PHZ不要構成）
- オンプレミスから
s3.ap-northeast-1.amazonaws.comを問い合わせる - クエリがDX経由で共通サービスVPCのResolverへ転送される
- Resolverのフォワードルールにより、TGW経由でファイル共有VPCのAmazonProvidedDNSへ転送
- AmazonProvidedDNSがInterfaceエンドポイントのENIのプライベートIPを応答
- 応答が共通サービスVPC→オンプレミスへ返り、オンプレミスからプライベートIP宛通信が開始される
このように、PHZやレコード登録を行わなくても、InterfaceエンドポイントのプライベートDNS機能により自動的にプライベートIPが返されるため、設計がシンプルになり、レコード管理の運用コストも不要です。
4. 教訓：セキュアなHybrid設計におけるDNSの重要性
- Gateway vs Interfaceの判断軸
- 「名前解決結果もプライベートIPにできるか」を考慮して、S3エンドポイントのタイプを検討するべきでした
- プライベートDNSの活用
- InterfaceエンドポイントとRoute 53 Resolver、そしてAmazonProvidedDNSを組み合わせて活用することで、プライベートホストゾーンやレコードを管理せずに通信経路と名前解決の両方がPrivateネットワーク内で完結し、コンプライアンスを満たすセキュアな設計を実現できます
5. まとめ
- ハイブリッドクラウド環境の場合、要件によっては、単に通信経路をAWSバックボーンに通すだけでなく、DNSの名前解決結果もプライベート化することが必要になります
- Gatewayエンドポイントは経路最適化に優れていますが、DNS応答がパブリックIPアドレスであるため、用件に適さないケースも存在します
- Interfaceエンドポイント + Route 53 Resolver + AmazonProvidedDNSによる名前解決設計は、次のメリットをもたらします
- コンプライアンス順守： パブリック通信禁止要件を満たし、ポリシーへの抵触を回避します
- 通信の明確化： すべてのAWSサービス通信をプライベートIP経由で実現できます
- 簡易な設計： ホストゾーンやレコードの登録なしにDNS解決を提供可能です
