VPC の構成図には「パブリックサブネット」「プライベートサブネット」「NAT」「エンドポイント」の線が出てきます。なぜその線がそこに引かれるのかが分からないと、試験の構成図も実務の図も暗記になります。この記事は、パケットがどの経路を通るかを追って、線の理由を説明できるようにします。
この記事の結論
- サブネットが「パブリック」かどうかは、関連付けたルートテーブルにインターネットゲートウェイ（IGW）への経路があるかで決まります。サブネット自体の種類ではありません。
- IGW は VPC とインターネットの出入口です。IPv4 では公開 IP と私的 IP の 1 対 1 の変換も担うので、公開 IP が無いインスタンスは経路があっても通信できません。
- プライベートサブネットから外へ出るだけなら NAT ゲートウェイを使います。通れるのは VPC 内から始めた接続だけで、外からの不意の接続は受けません。
- パブリック NAT ゲートウェイはパブリックサブネットに置き、Elastic IP を付け、NAT から IGW へ経路を引きます。AZ の障害に備えるなら AZ ごとに置きます。
- S3 と DynamoDB 宛てはゲートウェイエンドポイント（ルートテーブルに経路を足す）、多くの他のサービスはインターフェイスエンドポイント（サブネットに ENI ができ、DNS で解決）です。どちらもインターネットを通りません。
結論｜VPC の通信の行き先は「ルートテーブル」が決める
VPC の中のインスタンスが通信を始めると、パケットはまずサブネットに関連付いたルートテーブルを見ます。ルートテーブルは「この宛先はあの出口へ」という行の並びです。宛先が VPC 内なら VPC 内へ、0.0.0.0/0（それ以外すべて）の行がどこを向いているかで、外へ出る道が決まります。
つまり、出口は3種類あっても、どれを通るかを決めているのはルートテーブルの行です。この記事で扱う出口は次の3つです。
| 出口 | 向かう先 | 外からの接続 | 経路の足し方 |
|---|---|---|---|
| インターネットゲートウェイ | インターネット全般 | 公開 IP と経路があれば受けられる | 0.0.0.0/0 を IGW に向ける |
| NAT ゲートウェイ | インターネット全般（外向きのみ） | 受けない | プライベート側で 0.0.0.0/0 を NAT に向ける |
| VPC エンドポイント | AWS のサービス | インターネットを通らない | ゲートウェイ型は経路を足す。インターフェイス型は ENI と DNS |
サブネットの分け方や CIDR は subnet-cidr-toha、セキュリティグループと NACL の評価は sg-nacl-shikumi に任せ、ここでは「経路」に絞ります。VPC が論理的に分離された仮想ネットワークで、サブネットとルーティングを自分で制御できることは vpc-toha で確認済みの前提です。
READ ALSO — 学習中向け・段1 入口
VPC とは何か｜サブネット・ルートテーブル・ゲートウェイ・セキュリティグループと NACL の関係を1枚で
パブリックサブネットとは何か｜IGW への経路があるかどうかだけの違い
「パブリックサブネット」という種類のサブネットがあるわけではありません。AWS のドキュメントでは、インターネットゲートウェイへの経路を持つルートテーブルに関連付けたサブネットを、パブリックサブネットと呼びます。経路が無いルートテーブルに関連付けたサブネットは、プライベートサブネットです。
同じ形のサブネットを2つ作り、片方のルートテーブルにだけ 0.0.0.0/0 → IGW の行を足せば、その片方だけがパブリックになります。名前や置いた場所は関係ありません。逆に言うと、構成図の「プライベートサブネット」の中身を知りたければ、関連付いたルートテーブルを見ればよいことになります。
OUTBOUND PATH外へ出る通り道
プライベートの通信はNAT と IGWを順に通って外へ出る
-
インスタンス
プライベートサブネット
-
ルートテーブル
0.0.0.0/0 → NAT
-
NAT ゲートウェイ
パブリックサブネット
-
IGW
0.0.0.0/0 → IGW
-
インターネット
外部 API
上の図は、プライベートサブネットのインスタンスが外部 API を呼ぶときの通り道です。ルートテーブルが NAT ゲートウェイへ向け、NAT ゲートウェイを置いたパブリックサブネットのルートテーブルが IGW へ向けます。ここに出てくる「パブリック」「プライベート」は、どちらもルートテーブルの行き先の呼び名にすぎません。
CHECK 1ここまでの確認
サブネットが「パブリック」になるかどうかを決めているものは?
答えと解説
答え: 2. 関連付けたルートテーブルに、インターネットゲートウェイへの経路があること
サブネット自体に公開・非公開の種類はありません。経路の行き先で決まります。読み直すなら「パブリックサブネットとは何か」の章です。
インターネットゲートウェイの仕組み｜公開 IP との変換と「経路があっても出られない」ケース
インターネットゲートウェイ（IGW）は、VPC とインターネットの間の出入口です。VPC にアタッチして使い、水平にスケールする冗長な部品として AWS が提供しています。利用者が台数や容量を管理する対象ではありません。
もう一つの役割が、IPv4 での 1 対 1 の変換です。インスタンスが持つ私的 IP は、そのままではインターネットで使えません。IGW が、私的 IP と公開 IP を 1 対 1 で対応づけて、出ていくパケットの送信元を公開 IP に、入ってくるパケットの宛先を私的 IP に書き換えます。
ここから、次の条件が導かれます。外とやり取りするインスタンスには、次の2つが両方要ります。
- サブネットのルートテーブルに IGW への経路があること
- インスタンスに公開 IP（または Elastic IP）があること
経路があっても公開 IP が無ければ、インターネットとは通信できません。逆に公開 IP があっても経路が無ければ、パケットは IGW に届きません。インスタンスの SG と NACL が許可していることも当然必要ですが、その評価は sg-nacl-shikumi で扱います。
CAN IT GO OUT出られるかの関門
経路と公開 IP のどちらかが欠ければ出られない
インターネットへの出口（IGW）
- 経路IGW への経路あり 出られる公開 IP あり
- 経路IGW への経路あり 変換先が無い公開 IP なし
- 経路IGW への経路なし IGW に届かない公開 IP あり
IPv6 については、外向きだけを許す Egress-only インターネットゲートウェイがあり、::/0 をそこへ向けます。IPv4 の NAT ゲートウェイに当たる役目を IPv6 で担うものだと対比しておけば十分です。詳細は専門知識の領域なので、この記事では扱いません。
CHECK 2ここまでの確認
インターネットゲートウェイへの経路があるサブネットの EC2 が、外へ出られないことがあります。足りないものとして最も確かなのは?
答えと解説
答え: 2. 公開 IP アドレス（またはそれに当たる変換先のアドレス）
IPv4 では、インターネットゲートウェイが私的 IP と公開 IP を 1 対 1 で変換します。変換先が無ければ通信できません。経路と公開 IP の両方が要ります。「インターネットゲートウェイの仕組み」の章を読み直してください。
NAT ゲートウェイとは何か｜プライベートサブネットが「外へ出るだけ」にする仕組み
データベースや社内向けの処理は、公開 IP を持たせず、外から入れない場所に置きたいものです。しかし OS の更新や外部の API 呼び出しのように、中から外へ出る通信は必要です。この「出るだけ」を実現するのが NAT ゲートウェイです。
AWS のドキュメントでは、NAT ゲートウェイは、プライベートサブネットのインスタンスがインターネットなどの VPC 外のサービスに接続できるようにし、外部のサービスがそれらのインスタンスへの接続を始められないようにするもの、と説明されています。通れるのは、VPC 内から始めた接続だけです。
置き場所と経路は2か所
パブリック NAT ゲートウェイでは、次の3点がセットです。
- パブリックサブネットに置き、Elastic IP を付ける（NAT ゲートウェイ自身が外へ出るため）
- NAT ゲートウェイを置いたサブネットのルートテーブルは、
0.0.0.0/0を IGW に向ける - プライベートサブネットのルートテーブルは、
0.0.0.0/0を NAT ゲートウェイに向ける
NAT ゲートウェイだけがあっても外には出られません。その先に IGW が要る点が、NAT と IGW が混ざりやすい理由です。役割で分けると、IGW は「外との出入口」、NAT ゲートウェイは「私的な側から出ていくときの変換役」です。
VPC に接続した Lambda 関数が外部の SaaS の API を呼ぶ場合も同じ型です。Lambda の ENI には公開 IP が付かないので、プライベートサブネットに接続して 0.0.0.0/0 を NAT ゲートウェイに向けます。これは練習問題の正解とも同じ向きです。
AZ ごとに置く
NAT ゲートウェイは特定の AZ に置くものです。1つの AZ にだけ置くと、その AZ が使えなくなったとき、他の AZ のプライベートサブネットも外へ出られなくなります。そのため、AZ ごとに NAT ゲートウェイを置き、同じ AZ のプライベートサブネットのルートテーブルから、同じ AZ の NAT ゲートウェイへ向けます。AZ 障害の影響をその AZ に閉じ込める構成です。リージョン単位で使える選択肢もあるため、最新の扱いは公式の NAT ゲートウェイのページで確認してください。
NAT ゲートウェイには時間あたりの課金とデータ処理の課金があります。金額は変わりうるので、公式の料金ページで確認します。外向きの通信量が多いとデータ処理の費用が効いてくるため、次の章のエンドポイントが費用の面でも役立ちます。
IPv6 のみのサブネットから IPv4 の宛先へ行く DNS64 と NAT64 の組み合わせもありますが、ここでは触れるだけにします。
CHECK 3ここまでの確認
プライベートサブネットのインスタンスを外へ出すだけにしたい場合、パブリック NAT ゲートウェイをどう置く?
答えと解説
答え: 2. パブリックサブネットに置いて Elastic IP を付け、NAT から IGW へ経路を引く。プライベート側は 0.0.0.0/0 を NAT に向ける
NAT ゲートウェイ自身が外へ出るために、パブリックサブネットと Elastic IP、IGW への経路が要ります。「NAT ゲートウェイとは何か」の章を読み直してください。
VPC エンドポイントの仕組み｜インターネットを通らずに AWS サービスへ行く 2 つの型
S3 や Secrets Manager のような AWS のサービスを使うとき、通信先はサービスのエンドポイントです。NAT ゲートウェイ経由で行くこともできますが、VPC エンドポイントを使えば、インターネットを通らず、IGW も NAT ゲートウェイも使わずに接続できます。型は2つです。
THREE EXITS出口の使い分け
インターネット向けはIGW と NAT、AWS サービス向けはエンドポイント
インターネットへ
外部 API・Web 公開
- IGW — 出入口。公開 IP と 1 対 1 で変換
- NAT ゲートウェイ — 外向きだけ。外からは受けない
AWS サービスへ
S3・DynamoDB・その他
- ゲートウェイ型 — ルートテーブルに経路を足す
- インターフェイス型 — ENI と DNS。インターネットを通らない
ゲートウェイエンドポイント
S3 と DynamoDB 向けの型です。PrivateLink は使いません。作ったエンドポイントをルートテーブルに関連付けると、そのルートテーブルに、対象サービスの宛先（プレフィックスリスト）をエンドポイントに向ける行が足されます。つまりルートテーブル単位で効きます。
「エンドポイントを作ったのに、サブネットの通信が相変わらず NAT ゲートウェイを通っている」場合は、そのサブネットに関連付けたルートテーブルがエンドポイントに関連付いていないことが、最初に疑うところです。通信元のサブネットのルートテーブルを見ます。
インターフェイスエンドポイント
多くの AWS サービス向けの型です。指定したサブネットに ENI（プライベート IP を持つネットワークインターフェイス）ができ、そこが入口になります。サービス名は DNS で ENI の IP アドレスに解決されます。ルートテーブルに経路を足す必要はありません。
プライベート DNS を有効にして、いつもの名前のまま使いたいときは、VPC の DNS 解決と DNS ホスト名の2つの属性が有効なことが前提です。名前が公開側のアドレスのままのときは、この2つを確認します。
どちらの型にもエンドポイントポリシーがあり、そのエンドポイントを通して何ができるかを絞れます。S3 バケット側のポリシーで特定のエンドポイント経由だけを許す設計もあります。権限の設計は kengen-sekkei-pro の領域です。
| 型 | 対象 | 仕組み | ルートテーブル |
|---|---|---|---|
| ゲートウェイ | S3・DynamoDB | ルートテーブルに経路を足す | 関連付けが必要 |
| インターフェイス | 多くの AWS サービス | サブネットに ENI を作り、DNS で解決 | 経路は不要 |
CHECK 4ここまでの確認
S3 へ NAT ゲートウェイを通さずに行かせたいとき、ゲートウェイエンドポイントはどこに効かせる?
答えと解説
答え: 2. サブネットに関連付けたルートテーブル
ゲートウェイエンドポイントはルートテーブルに経路を足す型で、効くのは関連付けたルートテーブルを使うサブネットだけです。「VPC エンドポイントの仕組み」の章を読み直してください。
通り道を追う｜3つの宛先（Web 公開・外部 API・S3）で、どの経路を通るか
ここまでの部品を、宛先ごとに追ってみます。
| 宛先 | 出る側 | 通る経路 | 外からの接続 |
|---|---|---|---|
| 利用者に Web を公開する | パブリックサブネットの Web サーバー（公開 IP あり） | ルートテーブルの 0.0.0.0/0 → IGW |
公開 IP と経路があれば受けられる |
| 外部の API を呼ぶ | プライベートサブネットのアプリ | 0.0.0.0/0 → NAT ゲートウェイ → IGW |
受けない |
| S3 にデータを置く | プライベートサブネットのアプリ | S3 宛て → ゲートウェイエンドポイント | インターネットを通らない |
ルートテーブルには複数の行があり、パケットは宛先に最も具体的に一致する行に従います。S3 宛てのプレフィックスリストの行と 0.0.0.0/0 → NAT の行があれば、S3 宛ては前者、それ以外の外部 API は後者になります。だからエンドポイントを足すと、S3 への通信だけが NAT から外れ、NAT ゲートウェイのデータ処理を避けられます。
つまずきやすい点と次に読むもの
つまずきやすい点を、順番に確認します。
- 「プライベートサブネット」という種類がある、と思う。 経路の行き先の呼び名です。ルートテーブルを見ます。
- IGW の経路を足したのに通信できない。 公開 IP が無いか、SG・NACL が止めている可能性があります。切り分けは経路 → 公開 IP → SG・NACL の順です。
- NAT ゲートウェイを置いたら外から入れると思う。 外向きだけです。外から受けるのは IGW と公開 IP の経路です。
- NAT ゲートウェイ1つで十分と考える。 通常は動きますが、その AZ の障害で他の AZ の外向き通信も止まります。AZ ごとに置く構成が基本です。
- S3 宛てが NAT を通り続ける。 ゲートウェイエンドポイントとルートテーブルの関連付けを確認します。
入口側（外から入ってくる通信をどう受けて、どのサーバーに分けるか）は elb-toha で読みます。同じ「出入口」の話を、ロードバランサーの側から読み進められます。
READ ALSO — 学習中向け・段2 構成
Elastic Load Balancing とは何か｜ALB・NLB・GWLB の違いとヘルスチェック、複数 AZ
参照ソース
- Amazon VPC ユーザーガイド：NAT ゲートウェイ — NAT ゲートウェイの種類、外へ出るだけで外からの接続を受けないこと、パブリック NAT の Elastic IP と IGW への経路の根拠
- Amazon VPC ユーザーガイド：インターネットゲートウェイ — IGW の役割、パブリックサブネットの定義、公開 IP との 1 対 1 の変換、経路と公開 IP の両方が要ることの根拠
- AWS PrivateLink ガイド：概念 — VPC エンドポイントの種類（ゲートウェイ型は S3・DynamoDB 向け、インターフェイス型は ENI と DNS）、エンドポイントポリシーの根拠
