VPC を作る画面で、CIDR を /16 にして、サブネットを公開と非公開に分けて、AZ を 2 つ選ぶ。ウィザードの出力は動くのに、なぜその値なのかを聞かれると答えられない。この記事は、その「なぜ」を言える順番を作ります。コンソールの操作は書きません。判断の軸だけを扱います。
この記事の結論
- 最初に決めるのは CIDR です。作成後に既存ブロックのサイズは変えられず、足せるのはセカンダリだけで、他の VPC やオンプレミスとの重なりは接続の段階で効いてきます。
- サブネットは「ルートテーブルが違うもの」で分けます。インターネットと直接出入りする層（ロードバランサーなど）と、出入りしない層（アプリ・DB）を分けます。
- 各層は AZ ごとに同じ形で複製します。1 つの AZ が使えなくなっても、残りで動かせる形にするためです。
- NAT ゲートウェイは AZ ごとに置き、同じ AZ のプライベートサブネットから向けます。AZ をまたぐ経路を作りません。
- サブネットの分け方と、セキュリティグループ（SG）による層間の許可は役割が別です。数を増やすより SG で絞ります。
VPC の設計は何を決めることか｜変えにくい順に並べる
VPC の設計で決めることは 4 つあります。CIDR（アドレスの範囲）、層（どこで分けるか）、AZ（何か所に複製するか）、出口（外へどう出るか）です。この 4 つは、決めたあとの直しやすさが違います。
この記事では「あとから変えにくい順」に決めます。途中で気づいて直すとき、CIDR まで戻ると全部に響き、出口だけなら影響が小さいからです。
DECIDE FROM THE HARDEST変えにくい順に
VPC の設計は変えにくいものから順に決める
出口の見直し
- CIDR — VPC 全体のアドレス範囲
- 層 — 公開と非公開の分け方
- AZ — 層を何か所に複製するか
- 出口 — NAT・エンドポイントの置き方
AZ・層の見直し
- CIDR — VPC 全体のアドレス範囲
- 層 — 公開と非公開の分け方
- AZ — 層を何か所に複製するか
- 出口 — NAT・エンドポイントの置き方
CIDR の見直し
- CIDR — VPC 全体のアドレス範囲
- 層 — 公開と非公開の分け方
- AZ — 層を何か所に複製するか
- 出口 — NAT・エンドポイントの置き方
変更が届く段届かない段
| 決めること | 何を決めるか | 直すときの重さ |
|---|---|---|
| CIDR | VPC 全体のアドレス範囲 | 既存ブロックのサイズは変えられない。接続先との重なりにも効く |
| 層 | 公開と非公開をどこで分けるか | 経路が違う単位なので、あとから分け直すと配置の移し替えになる |
| AZ | 各層を何か所に複製するか | 足すことはできるが、層ごとに同じ形を増やす作業になる |
| 出口 | NAT ゲートウェイやエンドポイントの置き方 | ルートの付け替えが中心で、比較的軽い |
ルートテーブルがどう通信を決めるかは VPC の通信が外に出る仕組み で扱いました。この記事はその部品を「いくつ、どこに置くか」の側から見ます。
READ ALSO — 学習中向け・段2 構成
VPC の通信が外に出る仕組み｜ルートテーブル・IGW・NAT ゲートウェイ・VPC エンドポイントの役割
CIDR はどう決めるのか｜広さ・重なり・予約アドレスの見積もり
CIDR の読み方そのものは サブネットと CIDR の入門 に任せ、ここでは「何を考えて広さを選ぶか」を扱います。
VPC の IPv4 の CIDR ブロックは /16 から /28 の範囲で決められます。範囲は RFC 1918 のプライベートアドレスを使うのが推奨で、0.0.0.0/8 のように使えない範囲もあります。
作ったあとにできること、できないこと
公式ドキュメントでは、VPC を作成したあとに既存の CIDR ブロックのサイズを変えることはできないとされています。できるのは、セカンダリの CIDR ブロックを追加することです。IPv6 についても、IPv4 だけで作った既存の VPC に IPv6 の CIDR を関連付けて、デュアルスタックにできます。そのときはルートテーブルと SG にも IPv6 のルールを足す必要があります。
つまり「足りなくなったら足す」手は残っていますが、足したブロックを含めて、全体の設計を説明できなくなるのは避けたいところです。最初に十分な余白を取るほうが、あとの手間が少なくなります。
広ければよいわけではない理由
広くするほど、同じ範囲を選んだ別の VPC やオンプレミスと重なる確率も上がります。重なりが問題になるのは、VPC を作る段階ではなく、つなぐ段階です。たとえば Direct Connect ゲートウェイの配下にある VPC どうしは、CIDR を重ねられません。VPC ピアリングや Transit Gateway も、重なる CIDR をそのままは扱えません。重なりを避けられないときは、プライベート NAT ゲートウェイなどで回避する手がありますが、設計が複雑になります。
だから、複数のアカウントや部署が VPC を作る組織では、VPC IPAM のプールを階層に分け、作成時にプールから重ならない範囲を割り当てる、という「先に計画する」やり方がとられます。つなぎ方の選択そのものは ネットワーク設計（プロ向け） の領域なので、ここでは「重ならない範囲を最初に選ぶ」ことだけ押さえてください。
見積もりの考え方
サブネットには、AWS が使う予約アドレスがあります。見かけの CIDR の数より、実際に割り当てられる数は少なくなります（予約の数は公式の「サブネットの CIDR」のページで確認してください）。台数を見積もるときは、この目減りと、将来の増加、ロードバランサーなど AWS が内部で使うアドレスも見込みます。
CHECK 1ここまでの確認
作成済みの VPC のアドレス範囲が足りなくなりました。VPC の CIDR についてできることは?
答えと解説
答え: 2. セカンダリの CIDR ブロックを追加する
既存ブロックのサイズは作成後に変えられませんが、セカンダリを足すことはできます。読み直すなら「CIDR はどう決めるのか」の章です。
サブネットは何で分けるのか｜公開層と非公開層、ルートテーブルの違いで切る
サブネットを分ける基準は「ルートテーブルが違うこと」です。見た目の用途や名前で分けるのではありません。
公開サブネットは、関連付けたルートテーブルに、インターネットゲートウェイ（IGW）向けのルートがあるサブネットです。非公開サブネットは、そのルートがないサブネットです。サブネット自体に「公開」「非公開」という種類の設定があるわけではありません。
3 つの層に分ける典型
Web システムでは、次の 3 層に分けるのが定番です。
| 層 | 置くもの | ルートテーブルの違い |
|---|---|---|
| 公開層 | ロードバランサー、NAT ゲートウェイ | IGW 向けのルートがある |
| アプリ層 | アプリケーションのサーバー | NAT ゲートウェイ向けのルートで外へ出る（IGW へは向けない） |
| DB 層 | データベース | 外へ出るルートを持たない |
公開層に置くのは、インターネットとの出入りの窓口になるものだけです。アプリと DB は、直接インターネットから届かないところに置きます。
分けることと許可を絞ることは別
サブネットを分けると「経路」は変えられますが、「誰からの通信を受けるか」まで絞れるわけではありません。層をまたぐ許可は SG で書き、ここでは送信元に別の SG を指定します。たとえばアプリ層の SG で「Web 層の SG からの 8080 番だけ」を許可すれば、Web 層のサーバーが増減して IP が変わっても、許可は自動で追随します。
SG とネットワーク ACL の違いは セキュリティグループとネットワーク ACL の仕組み に任せます。サブネットを細かく切りすぎず、経路が同じなら 1 つにまとめて、絞り込みは SG に任せるのが基本です。
TWO KINDS OF GATES経路と許可の門
経路の門とSG の門は役割が別
各層の境界
- インターネット→公開層IGW 向けのルートあり 届くロードバランサー
- 公開層→アプリ層SG が送信元の SG を許可 通るWeb 層の SG
- インターネット→アプリ層IGW 向けのルートなし 経路が無い直接
- アプリ層→DB 層SG が送信元の SG を許可 通るアプリ層の SG
CHECK 2ここまでの確認
あるサブネットが「公開サブネット」だと言えるのは、何があるからですか?
答えと解説
答え: 2. 関連付けたルートテーブルに、インターネットゲートウェイ向けのルートがある
公開か非公開かは名前や設定の種類ではなく、ルートテーブルの経路で決まります。読み直すなら「サブネットは何で分けるのか」の章です。
AZ はいくつ使い、どう並べるのか｜層 × AZ の表で考える
サブネットは 1 つの AZ の中に作ります。つまり「層を分ける」と「AZ を分ける」は別々の次元で、サブネットの数は層 × AZ になります。
層 × AZ の表にする
各層を AZ ごとに同じ形で複製します。2 つの AZ に 3 つの層なら、サブネットは 6 つです。
LAYER x AZ層 × AZ の表
各層をAZ ごとに同じ形で複製する
AZ-a
同じ形で複製
- 公開層 — ALB・NAT ゲートウェイ
- アプリ層 — プライベートサブネット
- DB 層 — プライベートサブネット
AZ-c
同じ形で複製
- 公開層 — ALB・NAT ゲートウェイ
- アプリ層 — プライベートサブネット
- DB 層 — プライベートサブネット
こうしておくと、1 つの AZ が使えなくなっても、残りの AZ の同じ層でサービスを続けられます。ロードバランサーは複数の AZ のサブネットにまたがって置けるので、AZ を 2 つ以上用意するのが前提になります。
いくつの AZ を使うか
1 つだと AZ の障害に耐えられず、2 つで冗長になります。3 つ以上にすると、1 つ失っても残りで負荷を受け持ちやすくなります。ただし、AZ を増やすほどサブネットと NAT ゲートウェイが増えるので、可用性の要求と管理の手間のバランスで決めます。
CIDR の割り当て方
VPC の範囲をサブネットに分けるときは、層ごとにまとまりのある範囲を割り当てておくと、あとでルールを書くのが楽になります。たとえば 10.0.0.0/16 の VPC で、公開層を 10.0.0.0/24 と 10.0.1.0/24、アプリ層を 10.0.10.0/24 と 10.0.11.0/24 のように決める、といった具合です。数字はあくまで例で、将来の増加分は使わずに残しておきます。
CHECK 3ここまでの確認
アプリ層の許可を「Web 層の IP アドレス一覧」ではなく「Web 層の SG」を送信元にして書くと、何がよいですか?
答えと解説
答え: 1. Web 層の台数や IP が変わっても、許可が自動で追随する
SG を送信元にすると、その SG を持つ ENI が増減しても許可の書き換えが要りません。読み直すなら「AZ はいくつ使い、どう並べるのか」の章です。
出口はどこに置くのか｜NAT ゲートウェイ・ゲートウェイエンドポイントを AZ ごとにどう置くか
アプリ層のサーバーが、OS の更新やインターネット上の API の呼び出しで外へ出るには、出口が要ります。IPv4 で外へ出る典型が NAT ゲートウェイです。
NAT ゲートウェイは AZ ごとに
NAT ゲートウェイは公開サブネットに置き、同じ AZ のプライベートサブネットのルートテーブルから 0.0.0.0/0 の行き先として向けます。1 つの AZ にしか置かず全 AZ から向けると、その AZ が止まったときに他の AZ の外向き通信まで止まります。AZ をまたぐ経路を作らないことで、障害の影響をその AZ に閉じ込められます。
つまり、ルートテーブルも AZ ごとに用意することになります。アプリ層用のルートテーブルは AZ の数だけ必要で、各々が自分の AZ の NAT ゲートウェイを指します。
NAT ゲートウェイは時間と処理したデータ量で課金されます。台数が AZ の数だけ増えるので、金額は料金ページで確認してください。
ゲートウェイエンドポイントで NAT を通さない
S3 のように、インターネットを通さずに行きたい相手には、ゲートウェイエンドポイントがあります。これはルートテーブル単位で効きます。エンドポイントを作ったのに通信が NAT を通り続けるときは、そのサブネットに関連付けたルートテーブルが、エンドポイントに関連付けられていないことがまず疑われます。
ルートテーブルは「サブネットが何を向くか」を決める唯一の場所なので、出口の設計もルートテーブルの数と関連付けで考えます。
CHECK 4ここまでの確認
3 つの AZ のプライベートサブネットから外へ出す NAT ゲートウェイの置き方として、障害の影響を AZ に閉じ込められるのは?
答えと解説
答え: 2. AZ ごとに置き、同じ AZ のプライベートサブネットから向ける
NAT ゲートウェイは AZ ごとに置き、同じ AZ から向けると、1 つの AZ の障害が他に広がりません。読み直すなら「出口はどこに置くのか」の章です。
設計の例：3 層の Web システムを 2 AZ に置く
ここまでの判断を、1 つの例にまとめます。数字は説明用の例で、規模に応じて変えます。
| 項目 | 例 | 理由 |
|---|---|---|
| VPC の CIDR | 10.0.0.0/16 | 他の VPC・オンプレミスと重ならない範囲を、先に台帳で確認して選ぶ |
| AZ | 2 つ（a と c など） | 1 つが止まっても動く最小の形 |
| 公開層 | 各 AZ に 1 つ（ALB・NAT ゲートウェイ） | IGW 向けのルートがある |
| アプリ層 | 各 AZ に 1 つ | 同じ AZ の NAT ゲートウェイへ 0.0.0.0/0 を向ける |
| DB 層 | 各 AZ に 1 つ | 外へ出るルートを持たない |
| 層間の許可 | SG の送信元に SG を指定 | 台数が増減しても許可が追随する |
| S3 への通信 | ゲートウェイエンドポイント | アプリ層のルートテーブルに関連付ける |
サブネットは合計 6 つ、アプリ層のルートテーブルは 2 つ、NAT ゲートウェイは 2 つです。
設計でやりがちな失敗と見直しの観点
見直すときに疑う 4 つ
- CIDR が他の VPC やオンプレミスと重なっている
- 層を分けたのに、アプリ層のルートテーブルが IGW を指している
- NAT ゲートウェイが 1 つの AZ にしかなく、全 AZ から向けている
- サブネットを細かく分け、許可の絞り込みまでサブネットで済ませようとしている
見直すときは、4 つの段を上から順にではなく、下から（CIDR → 層 → AZ → 出口）確かめます。下の段のずれは上の段すべてに響くからです。
既定の VPC は、CIDR とサブネットが自動で決められています。学習や試し置きには手軽ですが、本番では、なぜその範囲で、なぜその層なのかを自分で説明できる VPC を選ぶことを勧めます。
Cloudory 執筆者（AWS 認定 全冠）
この記事は公式ドキュメントの規則から組んだ設計の判断軸です。実際の規模や接続先に合わせて、数字は必ず自分の環境で見積もり直してください。複数の VPC や拠点をつなぐ段階になると、ここで決めた CIDR が効いてきます。
まとめ
- VPC の設計は、CIDR → 層 → AZ → 出口の順に、変えにくいものから決める。
- サブネットは経路（ルートテーブル）が違う単位で分け、層間の許可は SG で絞る。
- 各層を AZ ごとに複製し、NAT ゲートウェイも AZ ごとに置いて同じ AZ から向ける。
参照ソース
- VPC の CIDR ブロック（AWS 公式ドキュメント） — CIDR の長さの範囲、作成後にサイズを変えられずセカンダリを追加できる点、重なりの制約の根拠
- プライベートサブネットと NAT ゲートウェイを持つ VPC の例（AWS 公式ドキュメント） — 2 AZ に公開・非公開サブネットを置く構成、NAT ゲートウェイを AZ ごとに置く点、公開・非公開のルートテーブルの違い、S3 ゲートウェイエンドポイントの根拠
