はじめに
AWSサービスをインターネットを経由せずに利用するニーズは年々増えています。
特に大規模環境では、Gateway Endpoint と PrivateLink（Interface Endpoint）の使い分けが コスト・拡張性・セキュリティ の観点で非常に重要になります。
本記事では、両者の「通信の向き」「IPの有無」「ユースケース」を明確に整理し、SAP試験でも問われるポイントをまとめます。
Gateway Endpoint と PrivateLink の違い
Gateway Endpoint（S3 / DynamoDB 専用）
- 通信の向き：VPC → S3/DynamoDB（出口）
- IPを持たない
- ルートテーブルにエントリを追加して使う
- インターネット/NATを経由しないためコストが安い（無料）
- 大量データ転送に向く
つまり、
「VPC から S3/DynamoDB に出ていくトラフィックをプライベート化する仕組み」
PrivateLink（Interface Endpoint）
- 通信の向き：VPC 内にサービスの入口を作る（入口）
- ENI（IPアドレス）を持つ
- AWSサービスやSaaSを“VPC内に引き込む”
- サービス側は VPC 内の ENI からの通信だけを許可できる
- プライベート API 提供や外部連携に向く
つまり、
「サービスの入口を VPC 内に作り、プライベートIPでアクセスできるようにする仕組み」
ユースケース
1. SaaS の API をプライベートに呼びたい → PrivateLink
- SaaS 側が PrivateLink を提供している場合
- VPC 内に ENI が作られ、プライベートIPで API を呼べる
- インターネットを使わないためセキュア
- 例：Snowflake、Datadog、GitHub Enterprise Cloud など
理由：
PrivateLink は IP を持つため、アプリケーションから普通のプライベート通信として扱える。
2. VPC から S3 に大量データをアップロードしたい → Gateway Endpoint
- NAT Gateway 経由だとデータ転送コストが高い
- Gateway Endpoint は無料
- S3/DynamoDB 専用で最適化されている
理由：
Gateway Endpoint は「出口専用」で、インターネットを使わずに S3 に行ける。
3. VPC 内のアプリから AWSサービスを閉域で使いたい → PrivateLink
- STS / KMS / CloudWatch Logs / EventBridge など
- PrivateLink対応サービスは多い
理由：
サービスの入口（ENI）が VPC 内にできるため、完全に閉域でアクセスできる。
4. S3 バケットを複数アカウントから安全に使いたい → Gateway Endpoint + Bucket Policy
- 各アカウントの VPC に Gateway Endpoint を作成
- Bucket Policy で「この Endpoint からのアクセスのみ許可」
理由：
S3 は PrivateLink ではなく Gateway Endpoint が正解。
構成図
まとめ
-
Gateway Endpoint
- VPC → S3/DynamoDB の“出口”
- IPなし
- 無料
- 大量データ向け
-
PrivateLink（Interface Endpoint）
- VPC 内にサービスの“入口”を作る
- IPあり（ENI）
- AWSサービスやSaaSのプライベート接続
- API連携やゼロトラスト構成向け
両者は「どちらが外／内」ではなく、
“出口（Gateway Endpoint）”と“入口（PrivateLink）”という役割の違い
として理解すると設計がブレません。