CR2課の前田です。
お客様環境で既にS3 Gateway Endpointを使っているVPCに、新たにS3 Interface Endpointを追加する機会がありました。
お客様から「Interface Endpointを追加することで、今までGateway Endpoint経由で動いていたEC2の通信に悪影響がないか？」とご質問いただいたことをきっかけとしてまして、実機で検証してみました。
結論
- Interface EndpointをPrivate DNS無効で作成した場合、既存EC2の通信経路は変わらない。
- Interface EndpointをPrivate DNS有効 + 「Enable private DNS only for inbound endpoint」有効で作成した場合も、既存EC2の通信経路は変わらない。
- Interface EndpointをPrivate DNS有効 + 「Enable private DNS only for inbound endpoint」無効で作成した場合、既存EC2の通信がInterface Endpoint経由に変わってしまう。
前提知識
用語
| 用語 | 説明 |
|---|---|
| Gateway Endpoint | S3/DynamoDB専用のVPCエンドポイント。Route Tableにprefix listを追加することで動作する。無料。 |
| prefix list | AWSが管理するIPアドレスレンジの集合体。S3の場合、52.219.x.x/xxのようなS3パブリックIPがまとめられている。Gateway EndpointをRoute Tableに関連付けると、このprefix list宛ての通信がGateway Endpoint経由でS3に到達する。 |
| Interface Endpoint | AWS PrivateLink経由のVPCエンドポイント。VPC内にENI（プライベートIP）が作られる。有料。 |
| Private DNS | Interface Endpointの設定項目。有効にするとVPC内でサービスのDNS名がENIのプライベートIPに解決されるようになる。 |
| Enable private DNS only for inbound endpoint | Private DNSのサブオプション。有効にするとPrivate DNS（Private Hosted Zone）の効力がRoute 53 Resolver Inbound Endpoint経由のクエリのみに限定される。長いため本記事では「Inbound Only」と呼称。 |
仕組み: EC2からS3への通信経路はどう決まるか
- EC2が
s3.ap-northeast-1.amazonaws.comをDNS解決する - パブリックIP（例: 52.219.x.x）が返った場合 → Route Tableのprefix listにマッチ → Gateway Endpoint経由でS3にアクセス
- プライベートIP（例: 10.0.1.x）が返った場合 → Interface EndpointのENIのIPアドレスに名前解決→Interface Endpoint経由でS3にアクセス
つまりGateway EndpointとInterface Endpointのどちらが使われるかは、DNS解決で何が返るかで決まります。ここが今回の検証のポイントです。
仕組み: Private DNSオプションの設定でDNS解決結果が変わる
Interface EndpointでPrivate DNSを有効にすると、VPC内にRoute 53 Private Hosted Zoneが作成されます。
これによりs3.ap-northeast-1.amazonaws.comがENIのプライベートIPに解決されるようになり、VPC内の名前解決先も全てInterface Endpoint経由になってしまいます。
この問題に対処するために、2023年3月に「Enable private DNS only for inbound endpoint」というオプションが追加されました（※1）。
このオプションを有効にすると、Private Hosted Zoneの効力がRoute 53 Resolver Inbound Endpoint経由のDNSクエリにのみに限定されます。VPC内部から直接発行されるDNSクエリには影響しないため、VPC内のEC2は引き続きパブリックIPを解決してGateway Endpoint経由でS3にアクセスできます。
上記のようなことがドキュメントからは分かるのですが、これから実際に検証していきます。
※1…詳細が記載されているドキュメントは下記になります。
- Introducing private DNS support for Amazon S3 with AWS PrivateLink
- Amazon S3 用 AWS PrivateLink - プライベートDNS
既存通信がInterface Endpointに流れると何が問題になるか
検証の前に、仮に設定を誤って既存EC2の通信がInterface Endpoint経由に変わってしまった場合に何が起きるのか整理しておきます。
- コスト増: Gateway Endpointは無料だが、Interface Endpointは時間課金（$0.014/ENI/時）とデータ転送料（$0.01/GB）が発生する。通信量が多いワークロードだと無視できない金額になる。
- セキュリティグループによるブロック: Interface EndpointにはENIが作成され、セキュリティグループが紐づく。このセキュリティグループで通信を絞っている場合、既存EC2からの通信がブロックされてS3アクセスに失敗する可能性がある。
- VPCエンドポイントポリシーの不一致: Gateway EndpointとInterface Endpointで異なるエンドポイントポリシーを設定している場合、今まで許可されていたS3操作がInterface Endpoint側のポリシーで拒否される可能性がある。
検証環境
下記のような構成になります。
S3 Gateway Endpointには下記画像のIDが割り振られています。
※今回は、今までGateway Endpointを利用していたVPC内部のEC2にどのような影響があるか確認するのが主目的ですので、オンプレミスを送信元と仮定してInterface Endpointを利用する通信については検証しません。
検証1: Interface Endpoint追加前（ベースライン）
まずはGateway Endpointのみが存在する状態で確認します。
DNS解決
sh-5.2$ dig s3.ap-northeast-1.amazonaws.com +short 3.5.155.176 3.5.159.14 3.5.155.54 52.219.136.232 3.5.157.153 3.5.159.174 3.5.155.163 52.219.151.16
S3アクセス
sh-5.2$ aws s3 ls s3://s3-test-maeda 2026-06-16 02:48:17 0 test-dev.txt 2026-06-16 02:48:17 0 test-prod.txt 2026-06-16 02:48:17 0 test.txt
CloudTrail確認
S3のデータイベントを確認します。vpcEndpointIdフィールドにGateway EndpointのID（vpce-0901c283b32c30b87）が記録されています。イベント名はListObjectsとして記録されます。
Gateway Endpoint経由でアクセスしていることを確認できました。
検証2: Interface Endpoint追加（Private DNS有効 + Inbound Only無効）
先に問題が起きるパターンを確認します。
Interface EndpointをPrivate DNS有効、「Enable private DNS only for inbound endpoint」を無効で作成します。
DNS解決
パブリックIPではなくInterface EndpointのENIのIPアドレスが返るようになりました。
sh-5.2$ dig s3.ap-northeast-1.amazonaws.com +short 192.0.2.4
S3アクセス
動作自体は正常で、S3に問題なくアクセス可能です。
sh-5.2$ aws s3 ls s3://s3-test-maeda 2026-06-16 02:48:17 0 test-dev.txt 2026-06-16 02:48:17 0 test-prod.txt 2026-06-16 02:48:17 0 test.txt
CloudTrail確認
vpcEndpointIdフィールドにInterface EndpointのID（vpce-0c60d31fb0a1b5ee0）が記録されています。
通信がInterface Endpoint経由に変わってしまったことが分かります。
検証3: Interface Endpoint設定変更（Private DNS有効 + Inbound Only有効）
Private DNSは有効のまま、「Enable private DNS only for inbound endpoint」を有効にします。
DNS解決
検証1と同じく、パブリックIPに名前解決されました。 そのため、S3 Gateway Endpoint経由での通信に戻ることが期待できます。
sh-5.2$ dig s3.ap-northeast-1.amazonaws.com +short 3.5.155.245
S3アクセス
sh-5.2$ aws s3 ls s3://s3-test-maeda 2026-06-16 02:48:17 0 test-dev.txt 2026-06-16 02:48:17 0 test-prod.txt 2026-06-16 02:48:17 0 test.txt
CloudTrail確認
vpcEndpointIdがGateway EndpointのID（vpce-0901c283b32c30b87）に戻ったため、S3 Gateway Endpoint経由で通信が行われていると言えます。
検証4: Interface Endpoint設定変更（Private DNS無効）
Interface EndpointのPrivate DNSを無効にします。
DNS解決
検証1、3の結果と同じく、パブリックIPに名前解決されました。 そのため、S3 Gateway Endpoint経由で通信できそうです。
sh-5.2$ # 検証3と検証4はどちらもS3 Gateway Endpointへアクセスできることが正となるが、検証3から続けて実施すると本当にプライベートDNSを無効にしたからなのか分からない sh-5.2$ # いったんInterface EndpointをプライベートDNS有効 + Inbound Only無効（検証2のパターン）に戻し、Interface Endpoint経由になるようにする sh-5.2$ dig s3.ap-northeast-1.amazonaws.com +short 192.0.2.4 sh-5.2$ sh-5.2$ sh-5.2$ # 検証4実施。Interface EndpointのプライベートDNS無効後 sh-5.2$ dig s3.ap-northeast-1.amazonaws.com +short 3.5.155.114 3.5.157.151 52.219.150.200 3.5.155.11 52.219.151.12 52.219.163.60 3.5.159.250 3.5.159.81
S3アクセス
sh-5.2$ aws s3 ls s3://s3-test-maeda 2026-06-16 02:48:17 0 test-dev.txt 2026-06-16 02:48:17 0 test-prod.txt 2026-06-16 02:48:17 0 test.txt
CloudTrail確認
vpcEndpointIdがGateway EndpointのID（vpce-0901c283b32c30b87）となっているため、S3 Gateway Endpoint経由で通信できていることが確認できました。
まとめ
検証1～4の結果をまとめると、下記のような結果になりました。
| 検証 | Private DNS設定 | digの結果 | EC2の通信経路 | 既存EC2への影響 |
|---|---|---|---|---|
| 1 | Interface Endpoint未作成 | パブリックIP | Gateway | - |
| 2 | DNS有効 + Inbound Only無効 | プライベートIP | Interface | あり |
| 3 | DNS有効 + Inbound Only有効 | パブリックIP | Gateway | なし |
| 4 | DNS無効 | パブリックIP | Gateway | なし |
上記のことから、冒頭に記載した結論が導き出せます。
- Interface EndpointをPrivate DNS無効で作成した場合、既存EC2の通信経路は変わらない。
- Interface EndpointをPrivate DNS有効 + 「Enable private DNS only for inbound endpoint」有効で作成した場合も、既存EC2の通信経路は変わらない。
- Interface EndpointをPrivate DNS有効 + 「Enable private DNS only for inbound endpoint」無効で作成した場合、既存EC2の通信がInterface Endpoint経由に変わってしまう。
補足: Private DNS無効 と Private DNS有効（Inbound Only有効）の使い分け
検証3と検証4ではどちらも既存EC2に影響がないという結果でしたが、どのように使い分ければよいのでしょうか。違いは、オンプレミスからInterface Endpoint経由でS3にアクセスする際の指定方法です。
Private DNS無効の場合
オンプレミスからアクセスする際、endpoint固有DNS名を明示指定する必要があります。
aws s3 ls s3://my-bucket/ \
--endpoint-url https://bucket.vpce-0c60d31fb0a1b5ee0-zjhynu0b.s3.ap-northeast-1.vpce.amazonaws.com
Private DNS有効 + Inbound Only有効の場合
オンプレミスから通常通りのコマンドでInterface Endpoint経由のアクセスが可能です。
aws s3 ls s3://my-bucket/
ただし、これはRoute 53 Resolver Inbound Endpointを設けて、オンプレミス側DNSから s3.ap-northeast-1.amazonaws.com のクエリをInbound Endpoint経由でVPCに転送できていることが前提です。 この転送設定がなければ、Inbound Onlyを有効にしても意味がありません。
オンプレミスからのアクセスがある構成ではPrivate DNS有効 + Inbound Only有効、オンプレミスからのアクセスがない構成ではPrivate DNS無効がシンプルかと思います。
なお、AWS内（VPC内のEC2など）からInterface Endpointを明示的に使いたい場合は、どちらの設定でも --endpoint-url の指定が必要です。
aws s3 ls s3://my-bucket/ \
--endpoint-url https://bucket.vpce-0c60d31fb0a1b5ee0-zjhynu0b.s3.ap-northeast-1.vpce.amazonaws.com
感想
「Interface Endpointを追加しただけで既存の通信経路が変わるのか」という疑問に対して、Private DNSの設定次第で変わりうることが確認できました。結論だけ見れば当然の挙動ですが、「Enable private DNS only for inbound endpoint」というオプションはなかなか意識しないのではないかと思います。同じ構成を検討されている方の一助になれば幸いです。
