NAT GatewayとVPCエンドポイントの使い分け｜プライベートサブネットからの通信
セキュリティのため EC2 をプライベートサブネットに置くと、今度は「OSのアップデートをダウンロードしたい」「S3 にファイルを保存したい」といった外向きの通信をどう通すかが問題になります。答えは NAT Gateway と VPC エンドポイントの使い分けです。
NAT Gateway：外向き専用の出口
- パブリックサブネットに置き、プライベートサブネットのルートテーブルで
0.0.0.0/0を NAT Gateway に向ける - 内側から外への通信は通すが、外から内側への接続は受け付けない
- NAT Gateway は AZ ごとのリソース。高可用性にするには AZ ごとに1つずつ置き、各 AZ のプライベートサブネットは同じ AZ の NAT Gateway を使う
- 料金は「時間課金 ＋ 処理したデータ量」。大量のデータを流すと高くつく
よくあるひっかけ：NAT Gateway を1つの AZ にだけ置くと、その AZ の障害で全 AZ のプライベートサブネットが外に出られなくなります。「高可用性」とあれば AZ ごとに NAT Gateway です。
VPC エンドポイント：AWS サービスへの近道
S3 や DynamoDB など AWS のサービスにアクセスするだけなら、インターネットを経由する必要はありません。VPC エンドポイントを使うと、AWS のネットワーク内だけでサービスに到達できます。
| ゲートウェイ型 | インターフェイス型（PrivateLink） | |
|---|---|---|
| 対象 | S3 と DynamoDB のみ | 多くの AWS サービス（SQS、Secrets Manager など） |
| 仕組み | ルートテーブルにルートを追加 | サブネットに ENI（プライベートIP）を作成 |
| 料金 | 無料 | 時間課金 ＋ データ量 |
| オンプレからの利用 | 不可 | 可（VPN / Direct Connect 経由） |
試験のコツ：「EC2 から S3 への大量転送で NAT Gateway の料金が高い」→ S3 のゲートウェイ型エンドポイントを追加する、が定番の正解です。通信がインターネットを経由しなくなり、NAT の処理料金もかかりません。
関連して出るもの
- Egress-Only インターネットゲートウェイ：IPv6 で「外向きのみ」を実現するもの（IPv6 には NAT が無いため）
- NAT インスタンス：EC2 で NAT を自作する旧方式。管理の手間がかかるため、基本は NAT Gateway
- エンドポイントポリシー：エンドポイント経由でアクセスできるバケットを限定できる。バケットポリシーの
aws:SourceVpceと組み合わせると「特定の VPC からしか読めないバケット」が作れる
理解度チェック：プライベートサブネットの Lambda から Secrets Manager を呼びたい。インターネットには出したくない。どうする？
Secrets Manager のインターフェイス型 VPC エンドポイントを作成する。Secrets Manager はゲートウェイ型の対象ではない点に注意です。
まとめ
- インターネットへの外向き通信 → NAT Gateway（AZ ごとに配置）
- S3 / DynamoDB → 無料のゲートウェイ型エンドポイント
- その他の AWS サービス → インターフェイス型エンドポイント