Amazon S3には、Gateway型とInterface型の2種類のVPCエンドポイントがあります。同じVPCに両方を作成した場合、「どちらの優先順位が高いのか」と疑問に思うかもしれません。
結論からいうと、エンドポイント間に固定の優先順位はありません。アクセス先として名前解決されたIPアドレスと、ルートテーブルによって利用経路が決まります。
確認日:2026年9月14日。本文の経路例は、同一リージョンのS3汎用バケットをIPv4で利用する場合を基本にしています。
結論:DNS解決の結果で利用されるエンドポイントが決まる
S3へのアクセスは、概ね次の順序で経路が決まります。
- S3のDNS名を名前解決する
- 解決された宛先IPアドレスを確認する
- 該当するルートテーブルの経路へ送信する
標準のS3 DNS名がパブリックIPに解決され、その宛先にS3のマネージドプレフィックスリストを使ったルートがあればGateway型を通ります。一方、DNS名がInterface型エンドポイントのENIのプライベートIPに解決されればInterface型を通ります。
Gateway型VPCエンドポイントの仕組み
Gateway型はルートテーブルで経路を制御します。例えば東京リージョンのS3へAWS CLIで通常どおりアクセスすると、s3.ap-northeast-1.amazonaws.comなどの標準エンドポイントが使われます。
名前解決の結果がS3のパブリックIPであっても、サブネットに関連付けたルートテーブルに次のような経路があれば、通信はインターネットではなくGateway型VPCエンドポイントへ向かいます。
送信先: com.amazonaws.ap-northeast-1.s3 のプレフィックスリスト
ターゲット: vpce-xxxxxxxx(Gateway型)
Gateway型は追加料金が発生せず、VPC内のEC2やLambdaなどからS3へアクセスする一般的な構成に向いています。
Interface型VPCエンドポイントの仕組み
Interface型はサブネット内にENIを作成し、そのプライベートIPへ通信させます。利用方法は主に2つです。
- Interface型でPrivate DNSを有効にし、標準のS3 DNS名をENIのIPへ解決する
- AWS CLIの
--endpoint-urlなどで、VPCエンドポイント固有のDNS名を明示する
aws s3 ls --region ap-northeast-1 --endpoint-url https://bucket.vpce-xxxxxxxx-yyyyyyyy.s3.ap-northeast-1.vpce.amazonaws.com
上記のDNS名は形式例です。コンソールに表示された実際のDNS名を使用し、S3バケット操作では先頭のワイルドカード(*)をbucketに置き換えます。VPCエンドポイントIDだけからDNS名を組み立てないでください。
Interface型は、Direct ConnectやSite-to-Site VPNを経由するオンプレミス環境からS3へプライベートに接続したい場合に利用できます。ただし、時間料金とデータ処理料金が発生します。
設定別:どちらのエンドポイントが使われるか
| アクセス方法・設定 | 想定される経路 |
|---|---|
| Private DNS無効+標準S3 DNS名 | Gateway型 |
| Private DNS無効+Interface型固有DNS名 | Interface型 |
| Private DNS有効+「インバウンドのみ」は無効+標準S3 DNS名 | Interface型 |
| Private DNS有効+「インバウンドエンドポイントでのみ」を有効+VPC内から接続 | Gateway型 |
| 同設定でオンプレミスからRoute 53 Resolverのインバウンドエンドポイント経由 | Interface型 |
この表はVPC側のDNS設定を利用し、Gateway型を使うサブネットのルートテーブルが正しく関連付けられていることが前提です。独自DNS、プロキシ、別リージョンへのアクセス、より具体的な宛先ルートがある場合は、実際の経路を個別に確認します。
コストを抑える推奨構成
VPC内とオンプレミスの両方からS3へ接続する場合は、2種類を役割分担させる構成が有効です。
- VPC内のワークロード:無料のGateway型
- オンプレミス:Interface型
Interface型のS3エンドポイントでPrivate DNSを有効にする際に、「インバウンドエンドポイントでのみプライベートDNSを有効にする」を選択すると、この使い分けを実現しやすくなります。
「インバウンドのみ」を有効にする場合は、同じVPCにS3 Gatewayエンドポイントを用意し、維持する必要があります。また、Interface型だけでなくResolverエンドポイントなどの関連費用も含めて比較します。「Gateway型が無料」はS3の保存・リクエスト料金まで無料という意味ではありません。
経路を確認する方法
意図したエンドポイントを通っているか確認するときは、まずDNS解決結果を調べます。
nslookup s3.ap-northeast-1.amazonaws.com
dig s3.ap-northeast-1.amazonaws.com
プライベートIPが返ればInterface型、S3のパブリックIPが返り、ルートテーブルにS3プレフィックスリスト宛ての経路があればGateway型と判断できます。Interface型ではセキュリティグループ、Gateway型ではルートテーブルとエンドポイントポリシーも確認しましょう。
切り分け記録の例
DNSの結果だけで調査を終えず、次の項目を1セットとして残すと、経路変更前後の違いを比較できます。
| 記録項目 | 記入例・確認内容 |
|---|---|
| 接続元 | EC2のサブネットID、またはオンプレミス側のセグメント |
| 呼び出したDNS名 | アプリが実際に利用するバケットのホスト名 |
| 名前解決先 | Aレコードと、利用する場合はAAAAレコード |
| 経路 | 該当サブネットのルートテーブル、Gateway型の関連付け、Interface型のENI |
| 結果 | 時刻、成功・失敗、タイムアウトかAccessDeniedか |
IPv6を併用する場合は、AAAAレコードの宛先とIPv6側のエンドポイント・ルートも確認してください。IPv4で成功しただけでは、アプリが選択するIPv6の経路まで確認したことにはなりません。
まとめ
S3のGateway型とInterface型を併用しても、単純な優先順位で選ばれるわけではありません。DNSがInterface型ENIのプライベートIPを返すか、S3のパブリックIPを返すかが最初の分岐点です。その後、ルートテーブルによって最終的な経路が決まります。
VPC内はGateway型、オンプレミスはInterface型と分ければ、閉域性を保ちながらコストも最適化できます。
参考資料
関連記事
具体的な移行構成はAWS MGNの閉域構成とS3エンドポイント、設計時の経路数はFSx for ONTAPの50ルート制限を参照してください。