はじめまして！短足犬です。
ちいかわも草むしり検定5級に受かったというところで、私も資格を取ろうと思い、AWS ソリューションアーキテクトを取得しようとしています！
今回は「VPC」についてまとめてみました！
目次
- 結論（この記事の要点）
- VPC（Virtual Private Cloud）とは
- サブネットとは（AZ 単位で作る理由）
- インターネット接続（IGW / NAT / EIP）
- ルートテーブルとルーティング
- セキュリティ（セキュリティグループ / NACL）
- VPC 間接続（Peering / PrivateLink / Transit Gateway）
- 実務での構成パターン（Webアプリ視点）
- よくある誤解と落とし穴
- 理解度チェック（練習問題）
- まとめ
結論（この記事の要点）
AWS のネットワークは、「どのレイヤーで通信を制御するか」という視点で理解すると一気に整理できます。
VPC はその中心にある、AWS ネットワークの“土台”です。
VPC（Virtual Private Cloud）
AWS 上に作る自分専用のネットワーク空間。IP 範囲・ルート・セキュリティを自由に設計できる。
サブネット
VPC 内のネットワーク区画。AZ 単位で作成し、Public / Private を分けて使う。
インターネット接続（IGW / NAT / EIP）
外部との通信を制御する“出入口”。Public は IGW、Private は NAT を経由する。
ルートテーブル
通信経路を決める“道路地図”。どのサブネットがどこへ向かうかを定義する。
セキュリティ（SG / NACL）
通信を許可・拒否する“門番”。SG はインスタンス単位、NACL はサブネット単位。
VPC 間接続（Peering / PrivateLink / TGW）
他の VPC やオンプレと接続するための仕組み。用途に応じて使い分ける。
これらはすべて、「VPC → サブネット → ルート → セキュリティ → 外部接続」
というネットワーク構造のレイヤーで理解できます。
この構造を押さえると、VPC の全体像が一気にクリアになります。
VPC（Virtual Private Cloud）とは
VPC は、AWS 上に作る「自分専用のネットワーク空間」です。
AWS 全体という巨大なクラウドの中から、あなた専用のネットワークを切り出して使える仕組みです。
IP アドレスの範囲（CIDR）・サブネットの構成・ルーティング・セキュリティなど、
ネットワークの基本要素をすべて自分で設計できます。
オンプレのネットワークをクラウド上に再現するイメージに近いです。
VPC の特徴
- 完全に隔離されたネットワーク空間（他のユーザーと混ざらない）
- IP アドレス範囲（CIDR）を自由に決められる
- サブネットは AZ 単位で作成（高可用性の基礎）
- ルートテーブルで通信経路を制御
- セキュリティグループ / NACL で通信をフィルタリング
- オンプレや他 VPC と接続可能（Peering / PrivateLink / Transit Gateway）
よくある誤解
- VPC＝サブネットではない（サブネットは VPC の中の区画）
- VPC＝リージョン全体ではない（1リージョン内に複数作れる）
- VPC を作っただけではインターネットに出られない（IGW が必要）
- Public サブネット＝危険、ではない（設計次第）
実務での使いどころ
- Web アプリの基盤となるネットワークを構築
- Public / Private サブネットを分けてセキュアな構成にする
- オンプレと接続してハイブリッド環境を構築
- 複数システムを VPC Peering や TGW で統合
VPC は AWS ネットワークの「土台」であり、
サブネット・ルート・セキュリティのすべてがここから始まります。
サブネットとは（AZ 単位で作る理由）
サブネットは、VPC 内に作る「ネットワークの区画」です。
VPC 全体の IP アドレス範囲（CIDR）を、用途や役割に応じて分割したものです。
AWS ではサブネットは 必ず特定の AZ に属するため、
サブネット＝AZ 単位のネットワーク区画 と理解すると全体像がつかみやすくなります。
サブネットの特徴
- AZ 単位で作成される（AZ を跨ぐサブネットは作れない）
- Public / Private に分けて使うのが基本
- ルートテーブルを紐づけて通信経路を決める
- セキュリティグループ / NACL と組み合わせて通信を制御
- Web / AP / DB など役割ごとに分割するのが一般的
なぜサブネットは AZ 単位なのか？
- 高可用性（HA）を実現するため
→ 片方の AZ が落ちても、別 AZ のサブネットでサービスを継続できる - 物理的に独立したネットワークだから
→ AZ ごとに電源・ネットワークが分離されている - マルチ AZ 構成の基礎になるため
→ EC2 / ECS / RDS などはサブネットを跨いで配置する
Public サブネットと Private サブネット
- Public サブネット：IGW（Internet Gateway）へルートがある
- Private サブネット：IGW へ直接出られない（NAT 経由）
Web アプリでは、
Public（ALB） → Private（ECS/EC2） → Private（RDS）
という 3 層構成が定番です。
よくある誤解
- サブネット＝VPC ではない（サブネットは VPC の中の区画）
- Public サブネット＝危険 は誤解（設計次第で安全）
- サブネットを作っただけでは通信できない（ルートテーブル必須）
- AZ を跨ぐサブネットは作れない（AWS の仕様）
実務での使いどころ
- Web / AP / DB を役割ごとに分けてセキュリティを強化
- マルチ AZ 構成で高可用性を確保
- Public / Private を分けてインターネット接続を制御
- サブネットごとにルートテーブルを分けて通信経路を最適化
サブネットは 「AZ をどう使うか」 を決める最重要コンポーネントです。
ここを正しく設計できると、VPC 全体の構造が一気に理解しやすくなります。
ルートテーブルとルーティング
ルートテーブルは、サブネットの「通信経路（どこへ向かうか）」を決める設定です。
VPC 内のリソースが外部や他サブネットと通信するとき、
必ずルートテーブルの指示に従って経路が決まります。
サブネットは「どこにあるか」を決めるもの、
ルートテーブルは「どこへ行くか」を決めるもの。
この2つをセットで理解すると、VPC の通信が一気にクリアになります。
ルートテーブルの基本構造
- 宛先（Destination）：どの IP 宛ての通信か
- ターゲット（Target）：どこへ送るか（IGW / NAT / Local / TGW など）
例：
- 10.0.0.0/16 → local（VPC 内の通信）
- 0.0.0.0/0 → igw-xxxx（インターネットへ）
- 0.0.0.0/0 → nat-xxxx（Private → インターネット）
Public サブネットのルート例
- 10.0.0.0/16 → local
- 0.0.0.0/0 → IGW
この「0.0.0.0/0 → IGW」があるサブネットが
Public サブネット と呼ばれます。
Private サブネットのルート例
- 10.0.0.0/16 → local
- 0.0.0.0/0 → NAT Gateway
外部からの通信は遮断しつつ、
内部からの通信だけ NAT 経由で外へ出られるため、
アプリケーションや DB を安全に配置できるのが特徴です。
ルートテーブルの重要ポイント
- サブネットは必ず 1 つのルートテーブルに紐づく
- 複数のサブネットが同じルートテーブルを共有してもよい
- Public / Private を分けるのは「ルートの違い」だけ
- IGW / NAT / TGW などのターゲットが経路を決める
よくある誤解
- Public サブネット＝外部から丸見え は誤解（SG で制御すれば安全）
- ルートテーブルを作っただけでは通信できない（サブネットへの紐づけが必要）
- Private サブネットは「インターネットに出られない」わけではない（NAT 経由で出られる）
- local ルートは消せない（VPC 内通信の基本）
実務での使いどころ
- Public / Private サブネットを明確に分ける
- アプリ層と DB 層を別ルートにしてセキュリティを強化
- VPC Peering / TGW / PrivateLink の経路を制御
- 特定のサブネットだけ外部通信を禁止する構成も可能
ルートテーブルは、VPC の通信を決める「道路地図」です。
Public は IGW、Private は NAT、VPC 内は local
という3つの基本ルートを押さえるだけで、VPC の通信設計が一気に理解できます。
セキュリティ（セキュリティグループ / NACL）
VPC のセキュリティは、「どの通信を許可するか」 を決める仕組みです。
AWS では、セキュリティグループ（SG） と NACL（Network ACL） の2つがあり、
それぞれ役割が異なります。
簡単に言うと、
SG はインスタンスの“門番”、NACL はサブネットの“外壁” です。
① セキュリティグループ（SG）
インスタンス単位で適用されるファイアウォールです。
EC2 / ECS / RDS などに直接紐づけて使います。
- ステートフル（Stateful）
→ 返りの通信は自動で許可される - 許可ルールのみ
→ 拒否ルールは存在しない - インバウンド / アウトバウンドを個別に設定
- 複数の SG を同時にアタッチ可能
例：
「ALB からの 80 番だけ許可」
「同じ SG 同士の通信だけ許可」
など、“必要な通信だけ通す” のが基本です。
② NACL（Network ACL）
サブネット単位で適用されるファイアウォールです。
VPC の“外壁”として、より広い範囲の通信を制御します。
- ステートレス（Stateless）
→ 返りの通信も明示的に許可が必要 - 許可 / 拒否ルールの両方が使える
- ルールには番号（1〜32766）があり、番号の小さい順に評価
- サブネットに自動で 1 つ紐づく
例：
「特定の IP からのアクセスを拒否」
「特定ポートをサブネット全体でブロック」
など、広範囲の制御に向いています。
SG と NACL の違い（まとめ）
- SG：インスタンスの門番（Stateful）
- NACL：サブネットの外壁（Stateless）
SG は“細かい制御”、
NACL は“広い制御” に向いています。
よくある誤解
- SG と NACL はどちらか片方だけでいい → 誤解（役割が違う）
- Public サブネットは危険 → SG で制御すれば安全
- NACL の拒否ルールを入れすぎると通信が詰まる
- SG は拒否ルールがないので「許可しない＝拒否」になる
実務での使いどころ
- Web → AP → DB の通信を SG で厳密に制御
- 特定 IP の拒否は NACL で広範囲にブロック
- Public サブネットは SG で最小限のポートだけ開ける
- Private サブネットは外部からの通信を完全遮断
VPC のセキュリティは、
「SG で細かく許可し、NACL で広く守る」
という二段構えで設計するのが基本です。
VPC 間接続（Peering / PrivateLink / Transit Gateway）
VPC は単体で使うだけでなく、他の VPC やオンプレと接続して拡張することができます。
AWS では用途に応じて複数の接続方式が用意されており、
「どの経路でつなぐか」 を理解することが設計のポイントです。
結論から言うと、
Peering＝直接つなぐ
PrivateLink＝サービスだけ共有
Transit Gateway＝ハブでまとめる
という役割分担になっています。
① VPC Peering（ピアリング）
2つの VPC を直接つなぐ最もシンプルな接続方式です。
同一リージョンでも、別リージョンでも接続できます。
- ポイントツーポイント接続（1対1）
- ルートテーブルに経路を追加して通信可能
- トラフィックは AWS の内部ネットワークを通るため高速
- トランジティブ（経由通信）は不可
例：
VPC-A ↔ VPC-B は通信できるが、
VPC-A ↔ VPC-B ↔ VPC-C のような経由通信はできません。
② PrivateLink（プライベートリンク）
VPC 間で「サービスだけ」を共有する仕組みです。
ネットワーク全体をつなぐのではなく、
特定のエンドポイント（サービス）だけを公開できます。
- サービス単位の接続（VPC 全体は共有しない）
- 相手 VPC の内部 IP を知らなくてもよい
- セキュリティが高く、SaaS 連携でよく使われる
- インターネットを経由しない（AWS 内部で完結）
例：
SaaS 企業が提供する API を PrivateLink 経由で安全に利用する、など。
③ Transit Gateway（TGW）
複数の VPC やオンプレを「ハブ＆スポーク」でまとめる仕組みです。
大規模ネットワーク向けの中心的なコンポーネントです。
- ハブ型の接続（多対多）
- VPC / VPN / Direct Connect を一元管理
- トランジティブルーティングが可能
- 大規模企業や複数システムの統合に最適
例：
VPC-A、VPC-B、VPC-C、オンプレをすべて TGW に接続して一元管理。
3つの違い（まとめ）
- Peering：VPC 同士を直接つなぐ（小規模向け）
- PrivateLink：サービス単位で共有（SaaS / セキュア用途）
- Transit Gateway：ハブでまとめる（大規模向け）
よくある誤解
- Peering で経由通信できる → できない（非トランジティブ）
- PrivateLink は VPC 全体を共有する → サービスだけ
- TGW は高価だから使わない → 大規模構成ではむしろコスト最適
- Peering と PrivateLink は用途が同じ → 全く別物
実務での使いどころ
- 小規模：Peering でシンプルに接続
- 外部サービス連携：PrivateLink で安全に接続
- 複数システム統合：Transit Gateway でハブ化
- オンプレ接続：TGW + Direct Connect が定番
VPC 間接続は、
「どれだけの範囲をつなぎたいか」 で選ぶのがポイントです。
Peering / PrivateLink / TGW の役割を理解すると、
複雑なネットワーク構成もシンプルに整理できます。
実務での構成パターン（Webアプリ視点）
ここまで紹介した VPC の各コンポーネントは、
単なる知識ではなく Web アプリの実務で直接役立つものばかりです。
ここでは、実際のシステム設計でどのように使われるのかを整理します。
① 3層構成（Web / AP / DB）
最も一般的な Web アプリ構成です。
Public / Private サブネットを分けることで、セキュアかつ高可用な構成を実現します。
- Public サブネット：ALB / Bastion / NAT Gateway
- Private サブネット（AP 層）：EC2 / ECS / Lambda
- Private サブネット（DB 層）：RDS / ElastiCache
外部公開が必要なものだけ Public に置き、
アプリや DB は Private に閉じ込めるのが基本です。
② マルチ AZ 構成（高可用性）
AWS の高可用性の基本は 「AZ を跨いで配置する」 ことです。
- ALB は複数 AZ に自動で配置
- EC2 / ECS は複数 AZ に分散
- RDS はマルチ AZ で自動フェイルオーバー
- NAT Gateway も AZ ごとに配置するのがベストプラクティス
1 つの AZ が落ちても、別 AZ のサブネットでサービスを継続できます。
③ セキュリティ強化（SG / NACL）
Web アプリでは、通信経路を明確に分離することが重要です。
- SG：Web → AP → DB の通信を最小限に制御
- NACL：サブネット全体の広範囲な制御
- Public サブネットは必要なポートだけ開ける
- DB は外部から完全に遮断
「必要な通信だけ通す」 が AWS の基本思想です。
④ 外部 API / SaaS 連携（PrivateLink）
外部サービスと安全に通信したい場合は、
PrivateLink を使うことでインターネットを経由せずに接続できます。
- 外部 API を PrivateLink 経由で利用
- SaaS 企業が提供するエンドポイントに安全に接続
- VPC 間でサービスだけ共有する構成
セキュリティ要件が厳しい企業でよく使われます。
⑤ 複数システムの統合（Transit Gateway）
複数の VPC やオンプレをまとめたい場合は、
Transit Gateway（TGW） が最適です。
- VPC-A / VPC-B / VPC-C を TGW に接続して一元管理
- オンプレとの接続も TGW に集約
- 大規模ネットワークのハブとして利用
企業全体のネットワークを AWS に寄せるときに使われます。
⑥ コスト最適化
VPC 設計はコストにも直結します。
- NAT Gateway は AZ ごとに必要 → 最小限に抑える
- Public サブネットを増やしすぎない
- PrivateLink は高価なので用途を絞る
- 不要な EIP は課金されるので解放する
「必要なものだけ作る」 がコスト最適化の基本です。
実務では、
Public（入口） → Private（アプリ） → Private（DB）
という 3 層構成をベースに、
可用性・セキュリティ・コストのバランスを取りながら設計します。
よくある誤解と落とし穴
VPC は用語が多く、似た概念も多いため、
誤解しやすいポイントがいくつかあります。
SAA でも頻出なので、ここで一度整理しておきます。
① Public / Private サブネットの誤解
- Public サブネット＝危険 は誤解（SG で制御すれば安全）
- Private サブネット＝インターネットに出られない → NAT 経由なら出られる
- Public / Private の違いは「ルートテーブル」だけ
- Public に EC2 を置く＝外部から丸見え、ではない（SG が守る）
② IGW / NAT の誤解
- IGW を付けただけでは通信できない（ルート設定が必要）
- NAT は外部からの通信を受けられない（内→外専用）
- NAT Gateway は AZ 障害に弱い → AZ ごとに配置が必須
- NAT Instance と NAT Gateway は別物（試験でよく出る）
③ ルートテーブルの誤解
- サブネットは必ず 1 つのルートテーブルに紐づく
- ルートテーブルを作っただけでは意味がない（紐づけ必須）
- local ルートは消せない（VPC 内通信の基本）
- Public / Private の違いは「0.0.0.0/0 の行き先」だけ
④ セキュリティ（SG / NACL）の誤解
- SG は拒否ルールがない（許可しない＝拒否）
- NACL はステートレス → 返りの通信も許可が必要
- SG と NACL は役割が違う（片方だけでいいわけではない）
- NACL の拒否ルールを入れすぎると通信が詰まる
⑤ VPC Peering / PrivateLink / TGW の誤解
- Peering は経由通信できない（非トランジティブ）
- PrivateLink は VPC 全体を共有するわけではない（サービス単位）
- TGW は高価だから使わない → 大規模ではむしろ最適
- Peering と PrivateLink は用途が全く違う
⑥ CIDR / IP 設計の誤解
- 後から VPC の CIDR は簡単に変えられない
- サブネットのサイズは用途に合わせて慎重に決める
- 重複 CIDR は Peering / TGW で問題になる
- 10.0.0.0/16 を乱用すると後で詰む
⑦ 可用性に関する誤解
- サブネットは AZ を跨げない（AWS の仕様）
- NAT Gateway は単一 AZ 障害に弱い → 冗長化必須
- RDS / ECS / EC2 はマルチ AZ が前提
- ALB は自動でマルチ AZ だが、EC2 は自分で分散させる必要がある
これらの誤解を避けることで、
VPC の設計がより安全で、より AWS らしい構成になります。
特に「Public / Private の違い」「NAT の役割」「SG と NACL の違い」は
SAA でも実務でも頻出ポイントです。
理解度チェック（練習問題）
最後に、VPC の基本をしっかり理解できているか確認してみましょう。
上司からもらった練習問題をベースにしています。
Q1. Public サブネットと Private サブネットの違いは？
回答を見る
ルートテーブルの違いです。
Public サブネットには 0.0.0.0/0 → IGW のルートがあり、
Private サブネットには 0.0.0.0/0 → NAT のルートがあります。
Q2. セキュリティグループ（SG）は何を制御する？
回答を見る
インスタンス単位の通信を制御する“門番”です。
許可ルールのみで構成され、Stateful（返りの通信は自動許可）です。
Q3. Private サブネットから外に出るために使う AWS サービスは？
回答を見る
NAT Gateway（または NAT Instance）です。
Private サブネット → NAT → IGW → インターネット の流れで外部通信します。
これらの問題がスラスラ解ければ、VPC の基礎はバッチリです。
まとめ
VPC は一見すると用語が多くて複雑に見えますが、
「どのレイヤーで通信を制御するか」 という視点で整理すると一気に理解が進みます。
VPC の構造をレイヤーで整理するとこうなる
- VPC：自分専用のネットワーク空間（土台）
- サブネット：AZ 単位のネットワーク区画（部屋）
- ルートテーブル：通信経路を決める（道路）
- IGW / NAT：外部との接続（出入口）
- SG / NACL：通信の許可・拒否（門番 / 外壁）
- Peering / PrivateLink / TGW：他ネットワークとの接続（橋 / サービス共有 / ハブ）
この構造が生まれた理由
- 高可用性：サブネットは AZ 単位で作成し、マルチ AZ で冗長化
- セキュリティ：Public / Private を分けて最小限の通信だけ許可
- 拡張性：Peering / PrivateLink / TGW で柔軟に接続
- コスト最適化：NAT や EIP を必要な分だけ配置
実務でのポイント
- Web アプリは基本的に Public（ALB） → Private（AP） → Private（DB）
- 高可用性のために 複数 AZ に分散 させる
- セキュリティは SG で細かく、NACL で広く 守る
- 外部 API や SaaS は PrivateLink が安全
- 複数 VPC をまとめるなら Transit Gateway
VPC の全体像（レイヤー × 役割）
| レイヤー | コンポーネント | 主な役割 | 代表的な用途 |
|---|---|---|---|
| 土台 | VPC | ネットワーク全体の枠組み | IP 設計、ネットワーク分離 |
| 区画 | サブネット | AZ 単位のネットワーク分割 | Public / Private の分離 |
| 経路 | ルートテーブル | 通信経路の制御 | IGW / NAT / TGW へのルーティング |
| 出入口 | IGW / NAT | インターネット接続 | Public / Private の通信制御 |
| 防御 | SG / NACL | 通信の許可・拒否 | Web → AP → DB の制御 |
| 接続 | Peering / PrivateLink / TGW | 他ネットワークとの連携 | マルチ VPC / SaaS / ハイブリッド構成 |
このマトリクスを見ると、VPC の構造が
「レイヤー × 役割」 で綺麗に整理されていることがわかります。
SAA の理解にも、実務の設計にも役立つ視点です。
この記事が、あなたの AWS 学習や実務設計の助けになれば嬉しいです！
