← AWSサービスの内部原理 コース
112. VPCエンドポイントはAWSサービスへの私道である — ルートで曲げるゲートウェイ型とENIを置くインターフェイス型
「プライベートサブネットからS3に行きたい。NATを通るしかないのか?」——この問いに、VPCエンドポイントという2つの私道の作り方を図で追っていきます。
① まず問題設定: エンドポイントがない世界
EC2プライベートサブネット
唯一の抜け道は
ルートテーブルlocalルートのみ
IGWへの直行ルートが無い経由して
NATデバイスパブリックサブネットに配置
ようやく届く
Internet Gateway
通ってもAWSの外には出ないAmazon S3
DynamoDB
- 公式の言い回し: パブリックサブネットならS3/DynamoDB宛てはIGWへルーティングされサービスに届く。しかし「private subnets do not have routes to an internet gateway」——プライベートサブネットから届かせるにはパブリックサブネットにNATデバイスを置き、そこへ流す必要がある
- 重要な但し書き(公式): 「While traffic to Amazon S3 or DynamoDB traverses the internet gateway, it does not leave the AWS network.」——IGWを通ってもトラフィックはAWSネットワークの外には出ない。それでもプライベートサブネットからはNATデバイスが必須になる、というのが問題の本体
経路を制御するのはルートテーブル(レッスン3)。プライベートサブネットにはIGWへのルートが無いという定義そのものが、S3への到達をNAT頼みにしている。私道が欲しくなるのはここだ。
② ゲートウェイエンドポイント: ルートテーブルに1行足すだけ
ゲートウェイEP作成S3・DynamoDB専用
追加料金なし(Not billed)。作成時に有効化するルートテーブルを選ぶ宛先がS3のとき、どの行が勝つ?
prefix list行→ ゲートウェイEP
手で変更・削除できない0.0.0.0/0→ IGW
local→ VPC内
prefix listの方が 0.0.0.0/0 より具体的
最長プレフィックス一致レッスン3の再登場
S3宛てだけ曲がるエンドポイントへ
他宛てはそのまま0.0.0.0/0 → IGW
- 自動追加される行は「Destination = そのサービスのプレフィックスリスト(AWS所有・AWS管理のIP範囲リスト)、Target = ゲートウェイエンドポイント」。公式: 「you cannot modify or delete them」——このエンドポイントルートは手で変更・削除できない(関連付け解除やエンドポイント削除でのみ消える)
- 公式の落とし穴: 「Traffic that's destined for the service in a different Region goes to the internet gateway because prefix lists are specific to a Region.」——プレフィックスリストはリージョン固有。別リージョンのS3宛てはこの行に載らず 0.0.0.0/0 → IGW 側へ流れる
- さらに公式: 同一リージョンでもサービスの正確なIP範囲を指すルートを別に書けば、それがエンドポイントルートより優先される(より具体的なので)
ゲートウェイ型の正体は「案内板の1行」。DynamoDB編・S3編で叩いてきたサービスへの経路が、最長プレフィックス一致(レッスン3)の実戦投入としてルートテーブル上に初めて地図化される。曲がるのはS3宛てだけ、しかも同一リージョンだけ、という挙動は全部この1行の「具体性」から出てくる。
③ インターフェイスエンドポイント: 入口をVPCの中に建てる (AWS PrivateLink)
インターフェイスEP作成サブネットを指定する
宛先はDNSで解決(次レッスンの伏線)
エンドポイントENIVPC内のプライベートIPを持つ
「サービスの入口」が自VPCの住人として現れるAWS内で完結公共のインターネットを通らない
- 公式: 「For each subnet that you specify when you create a VPC endpoint, we create an endpoint network interface in the subnet.」ENIは「entry point for traffic destined to an endpoint service ...」であり、VPCエンドポイントがIPv4対応ならそのENIはIPv4アドレスを持つ
- 「VPC内のプライベートIP」の直接の根拠(S3公式): このアドレスは「private IP addresses from subnets in your VPC」——自VPCのサブネットから割り当てられたプライベートIPだ
- 宛先解決: インターフェイスエンドポイントは「Traffic destined for the endpoint service is resolved using DNS」。この「リモートのサービスをローカルのアドレスに見せかける」やり方こそ、次のDNSレッスンの入口
- 経路: 「Traffic between a VPC endpoint and an endpoint service or resource stays within the AWS network, without traversing the public internet.」
ゲートウェイ型が「案内板を書き換える」なら、インターフェイス型は「入口を建てる」。ENIという実体をVPC内に置き、リモートのAWSサービスを自分のVPCのプライベートIPに見せかける——API Gateway編のリバースプロキシと同族の「見せかけ」の発想だ。
④ 提供側の構造: PrivateLinkはAWS専用ではない
VPCエンドポイント消費者(Consumer)側
自分のVPCにENI(プライベートIP)提供者になれるのは
EPサービス提供者(Provider)側
ロードバランサーの後ろにサービスを置いて公開AWS
AWSパートナー
他のAWSアカウント
- 公式: 「A service provider must specify a load balancer when creating an endpoint service. The load balancer receives requests from service consumers and routes them to your service.」——提供者はLBの後ろにサービスを置き「エンドポイントサービス」として公開する
- 「Service providers include AWS, AWS Partners, and other AWS accounts.」——PrivateLinkはAWSサービス専用ではなく、他社SaaSや自社サービスも同じ仕組みに載る
- ただし公式の区別: 「Gateway endpoints do not use AWS PrivateLink, unlike the other types of VPC endpoints.」——②のゲートウェイ型はPrivateLinkを使わない別方式。PrivateLinkに載るのはインターフェイス型の方
インターフェイス型は「消費者がVPCエンドポイントを作り、提供者のエンドポイントサービス(LBの背後)につなぐ」という左右対称の構造。だからAWSサービスも他社SaaSも自社サービスも同じ土俵に載る。ゲートウェイ型だけはこの仕組みの外にいる。
⑤ アクセス制御は別レイヤー: エンドポイントポリシー
経路の制御ルートテーブル / ENI
どこへ通じる私道か権限の制御エンドポイントポリシー
この私道を通って何をしてよいかデフォルトは全許可 → 絞るなら明示的に書く
IAMリソースポリシーエンドポイントに付ける
このバケットだけ絞る例
このアカウントの資源だけ絞る例
- 公式: 「A VPC endpoint policy is an IAM resource policy that you attach to a VPC endpoint. ... The default VPC endpoint policy allows all actions by all principals on all resources over the VPC endpoint.」——デフォルトは全許可(all actions by all principals on all resources)なので、絞りたいなら明示的に書く
- これは認証暗号編の「リソースポリシー(場所に付く許可)」の再登場。経路(ルート/ENI)が通っていても、ポリシーで「この私道を通って何をしてよいか」を別途絞れる
「経路が通じている」ことと「そこで何をしてよいか」は別レイヤー。エンドポイントポリシーは場所(エンドポイント)に付くリソースポリシーで、デフォルト全許可を絞り込む道具。認証暗号編で見たリソースポリシーが、ネットワークの文脈で再登場する。
⑥ 締めの対比: 案内板を書き換えるか、入口を建てるか
ゲートウェイ型ルートテーブルの1行
案内板を書き換えるインターフェイス型ENIという実体
入口を建てる(PrivateLink)S3・DynamoDBのみ対応サービス
多数のサービス対応: AWS/SaaS/自社
追加料金なし料金: Not billed
課金あり料金: Billed
VPC内専用オンプレ不可・別リージョンのVPCからも不可
外からも届くオンプレはVPN/Direct Connect経由・別リージョンVPCはピアリング/Transit Gateway経由
S3とDynamoDBは両方式に対応 → 選べる
同じ公開DNS名宛先解決: DNS名+ルート
固有DNS名宛先解決: DNSで(次レッスン)
VPC内で安く→ ゲートウェイ型(無料)
外からも私道でオンプレ/別リージョン → インターフェイス型
併用も定石VPC内=GW / オンプレ=IF
- 公式S3比較表(ゲートウェイ型): 「Not billed」/「Do not allow access from on premises」/「Do not allow access from another AWS Region」/「Use Amazon S3 public IP addresses」/「Use the same Amazon S3 DNS names」
- 公式S3比較表(インターフェイス型): 「Billed」/「Allow access from on premises」(VPN・Direct Connect経由)/「Allow access from a VPC in another AWS Region」(VPCピアリングまたはAWS Transit Gateway経由)/「Use private IP addresses from your VPC」/エンドポイント固有のDNS名が必要
- 併用: 公式は「in-VPC applications to continue accessing Amazon S3 through the gateway endpoint, which is not billed. Then, only your on-premises applications would use interface endpoints」と明記。VPC内は無料のGW、オンプレはIF、という使い分けが定石
- DVAの定番論点「プライベートサブネットからS3/DynamoDBへ」は、この表の1段目・2段目(実体と料金)がそのまま答えになる
同じ「プライベートに行きたい」に対する2つの実装。ゲートウェイ型は案内板を1行書き換えるだけ(無料・S3/DynamoDB限定・VPC内専用)、インターフェイス型はENIという入口を建てる(課金・多数サービス対応・オンプレや別リージョンVPCからも到達)。S3とDynamoDBだけが両方に対応するので、料金と到達範囲で選ぶ。「経路の制御」と「権限の制御(⑤)」が別レイヤーだった事実と合わせて、ネットワークとIAMが噛み合う地図がこれで一枚になる。