【AWS入門】VPC構成図がわかる｜サブネット・IGW・NAT Gatewayの役割を5分で理解

はじめに

AWSの入門書や公式ドキュメントを開くと、まず最初にこんな図が出てきます。

「VPC」「サブネット」「ゲートウェイが2種類」と、初見だと用語の多さで挫けがちな構成図ですよね。でもこれ、AWS設計の超定番パターンで、これさえ読めれば入門のヤマは越えたと言っていいやつです。

この記事のゴールは、上の図を自分の言葉で説明できるようになること。読了目安は5分です。

対象読者

• AWSに触り始めたばかりの人
• インフラ未経験で、構成図を見てもピンと来ない人
• 「Public」と「Private」の違いがフワッとしている人

登場人物は4人だけ

この図に出てくる主要な要素は、たった4つです。1人ずつ役割を見ていきましょう。

1. VPC ：自分専用のネットワーク区画

VPC は Virtual Private Cloud の略で、AWS上に作る「自分専用の仮想ネットワーク」のことです。

AWSというマンションの中で、「ここからここまでが私の部屋ですよ」と区画を借りるイメージ。図の 172.16.0.0/16 というのは、その区画で使えるプライベートIPアドレスの範囲を表しています¹。

2. サブネット：VPCの中の「部屋」

VPC は広いので、さらに小さく区切って使います。これがサブネットです。

図には2つのサブネットがあります。

種類	役割
Public subnet	インターネットに直接面した「玄関先の部屋」
Private subnet	外から直接見えない「奥の部屋」

Public/Privateの違いは「論理的な設定」で決まる

実は、AWSの仕様上「Public subnet」「Private subnet」という固有のリソースタイプがあるわけではありません。ルートテーブルにInternet Gatewayへのルートが設定されているサブネットを Public、されていないものを Private と呼ぶ、という慣習です。

つまり、Public/Privateの違いは「物理的な隔離」ではなく「ルーティング設定の違い」なんですね。

3. Internet Gateway ：VPCの玄関

Internet Gateway（IGW）は、VPCとインターネットを繋ぐ「玄関」です。VPCに1つだけアタッチでき、料金もかかりません。

ここで意外と知られていない事実を一つ。IGWは単なる通り道ではなく、内部で1:1のNAT変換を行っています。

具体的には、こんな処理をしています。

• 外向き：パケットの送信元IPを「プライベートIP」→「パブリックIP（またはEIP）」に書き換える
• 内向き：宛先IPを「パブリックIP」→「プライベートIP」に書き換える

なので、Public subnet にあるリソースが「インターネットと通信できる」ためには、そのリソース自身がパブリックIPまたはElastic IPを持っている必要があるわけです。

4. NAT Gateway ：片道通行の改札

NAT Gateway（NAT GW）は、Private subnet の住人が外には出ていけるけど、外からは入って来られないようにする「片道改札」です。

公式ドキュメントの仕様を整理するとこうなります。

• アウトバウンド（中→外）の通信は通す
• インバウンド（外→中）の新規セッションは通さない
• 戻りの通信（自分が始めた通信への応答）は通す
• Public subnet に配置する必要がある（自身が IGW 経由で外に出ていくため）

NAT Gateway は時間課金＋通信量課金の二重課金

東京リージョン（ap-northeast-1）での料金は以下の通りです（2026年4月時点）。

• 時間料金：$0.062/時間 → 24時間×30日で約 $45/月
• データ処理料金：$0.062/GB

「起動しているだけで月45ドル」がポイント。試しに作って消し忘れると地味に痛いです。最新の料金は公式ページで確認してください。

なぜこの構成にするのか？

ここまで読んで、こう思った人もいるかもしれません。

「App Server を直接 Public subnet に置いて、IGW 経由で通信すればよくない？ NAT Gateway いらなくない？」

これ、動きます。動くんですけど、セキュリティ的にマズいんです。

直接Publicに置いた場合の問題

App Server を Public subnet に置くと、その App Server にはパブリックIPが割り当てられることになります。すると、インターネット側からも IPアドレスでアクセスできる状態になってしまいます。

つまり、攻撃の入口を世界中に晒している状態。Security Group で入口を絞ることはできますが、設定を1つミスっただけで漏れます。

NAT Gatewayを挟むメリット

そこで、こういう要件を実現したくなります。

• App Server にはプライベートIPしか振らない（インターネットから到達不可能）
• でも、パッケージ更新や外部API呼び出しなど、外への通信は必要

この「外からは見えないけど、中からは出ていける」を実現するのが NAT Gateway の役目です。

NAT Gateway がパブリックIPを持って代理で外と通信し、戻ってきた応答だけを App Server に届けてくれる。これで App Server 自体は外から見えないまま、必要な外部通信ができるわけです。

データの流れを追ってみる

最初の図の矢印を、1ステップずつ追ってみましょう。

App Server が「外部APIにリクエストを送りたい」というシナリオです。

ポイントは 「NAT Gateway は自分が送り出した通信の戻りだけを通す」 こと。これがあるので、外部から App Server に向けて新規にアクセスしようとしても弾かれます。

まとめ：4つの役割を1行ずつ

最後に、もう一度図を見てください。今度はちゃんと読めるはず。

コンポーネント	一言で
VPC	AWS上の自分専用ネットワーク
Public subnet	IGWへのルートを持つ、外向きの部屋
Private subnet	IGWへのルートを持たない、奥の部屋
Internet Gateway	VPCの玄関（無料、1:1 NAT付き）
NAT Gateway	Privateの住人を外に通す片道改札（有料）

公式ハンズオン

軽めの記事としてはここまで。
公式ハンズオンチュートリアルが分かりやすいので、手を動かしたい方はこちらから。

1. /16 は「先頭16ビットが固定」という意味で、172.16.0.0 から 172.16.255.255 までの約65,000個のIPアドレスが使えます。 ↩