2026-08-11（火）VPC（ネットワークの土台）

1. 【この範囲の全体像】

本範囲（第2章2-2前半）は、AWS上に構築するすべてのシステムの物理的および論理的土台となる「VPCネットワーク」の最重要ルールを扱います [p.31]。

IPアドレス空間を定義する「VPC CIDRブロック」の仕様制限（/16〜/28） [p.32]、リソースの物理区画を決定する「サブネット」の定義 [p.33]、そして高可用（マルチAZ）設計を確立するためのアベイラビリティゾーン（AZ）とサブネットの1対1マッピングの絶対原則を理解することは [p.34]、試験で問われるセキュアかつ耐久性に優れたネットワーク設計を正確に行うための土台となります [p.31, p.34]。

2. 【重要キーワード・サービス一覧】

キーワード	説明
Amazon VPC (Virtual Private Cloud)	AWSクラウド上に論理的に隔離して構築する、ユーザー専用の仮想ネットワーク空間 [p.31]。
CIDR (Classless Inter-Domain Routing)	IPアドレスを範囲（IPブロック）で表現する規格。VPC全体や各サブネットの「収容可能なアドレス空間のサイズ」を定義する [p.32, p.33]。
プライベートIPアドレス範囲	VPCに割り当てる推奨アドレス帯。クラスA（`10.0.0.0`系）、クラスB（`172.16.0.0`系）、クラスC（`192.168.0.0`系）から選定する [p.32]。
サブネット (Subnet)	VPCのCIDR範囲を分割して作成する、個別のIPアドレスレンジを持つネットワークセグメント [p.33]。
AWS予約IPアドレス	各サブネットの「最初4つ」と「最後1つ」の合計5つのアドレス。AWSがシステム制御に用いるためユーザーは一切使用不可 [p.34]。
アベイラビリティゾーン (AZ)	1つのリージョン内にある、物理的・電源的に独立したデータセンター群 [p.26]。1つのサブネットは必ず単一のAZにのみ紐付けられる [p.33]。

3. 【試験で問われる比較ポイント】

① VPCとサブネットの論理・物理的な設計ルール比較 [p.31-34]

「ネットワーク全体を束ねる境界」か、「特定の物理データセンター（AZ）に閉じた区画」かで切り分けます [p.31, p.33]。

比較項目	VPC全体の設計仕様 [p.31, p.32]	サブネットの設計仕様 [p.33, p.34]
役割と境界	アカウント内の論理的に隔離された広大な「仮想ネットワーク境界」の定義 [p.31]。	VPCのアドレス空間を用途やセキュリティに応じてさらに細分化した「リソース配置の区画」 [p.33]。
CIDRのサイズ制限	/16 から /28 の範囲で設定可能（最大サイズである `/16` が強く推奨される） [p.32]。	/16 から /28 の範囲で、かつ親となるVPCのCIDR内に完全に収まるサイズに分割する [p.33]。
AZとの紐付け関係	複数のアベイラビリティゾーン（AZ）にまたがって境界を広げることができる [p.33]。	単一のアベイラビリティゾーン（AZ）にのみ紐付く（複数のAZをまたぐことは物理的に不可能） [p.33, p.34]。
インターネット接続性	デフォルトでは、VPC外部（インターネット等）と一切通信できない完全に隔離された状態 [p.31]。	紐付けるルートテーブルの設定（IGW等へのルート有無）によって、パブリックかプライベートかが決定される [p.38]。

② サブネットCIDRブロックサイズと「実効（実際に利用可能な）IPアドレス数」の比較 [p.33-34]

AWSがサブネットごとに強制的に占有する「5つの予約アドレス」を差し引いた実効数を正確に算出する必要があります [p.34]。

サブネットのCIDR [p.33]	理論上のアドレス総数	AWS予約アドレス数 [p.34]	実際にEC2等に割り当て可能なIP数	試験で選定すべきシナリオ要件
/24	256個	5個 [p.34]	251個	「最低250台のシステムリソースを1サブネット内に稼働させる」要件であれば `/24` で満たすことができる（251 ＞ 250）。
/28	16個	5個 [p.34]	11個	「最低12台のコンテナやEC2をデプロイする」要件の場合、`/28`（11個）ではアドレス枯渇で起動エラーになるため、/27以上を選択する。

💡 重要：AWSが予約する5つのIPアドレスの内訳（例：10.0.1.0/24 の場合） [p.34]

10.0.1.0: ネットワークアドレス [p.34]

10.0.1.1: VPCルーター（デフォルトゲートウェイ用アドレス） [p.33, p.34]

10.0.1.2: DNSサーバー用（AmazonProvidedDNS：ネットワーク範囲の +2） [p.34]

10.0.1.3: 将来の利用のためにAWSが予約したアドレス [p.34]

10.0.1.255: ネットワークブロードキャストアドレス [p.34]

4. 【ひっかけ注意ポイント】

ひっかけ①：「クラスAのプライベートIP範囲である 10.0.0.0 帯をVPCのアドレス空間として適用する場合、オンプレミス環境と同様に 10.0.0.0/8（16,777,216個のIP）という広大なアドレスブロックをそのまま割り当てる。」
- 真実: AWS VPCに設定可能なCIDRブロックの最大サイズは、クラスAであっても 一律で /16（65,536個のIP）までに厳しく制限されています [p.32]。
- 理由: ネットワーク空間が巨大すぎると管理・ルーティング負荷が過大になるためです [p.32]。足りない場合は、後からVPCに「追加のセカンダリCIDRブロック」をアタッチして拡張します [p.32]。
ひっかけ②：「システムの可用性を高める（SPOFを排除する）ため、サブネットA（CIDR: 10.0.1.0/24）をデプロイする際、その割り当てオプションから複数のAZ（ap-northeast-1a と ap-northeast-1c）をまたぐように範囲を指定する。」
- 真実: サブネットは「 1つのアベイラビリティゾーン（AZ）にしか所属できません 」 [p.33]。1つのサブネットが複数のAZをまたぐことは物理仕様上不可能です [p.33]。
- 理由: 高可用（マルチAZ）構成を組む場合のベストプラクティスは、「 AZ-aにサブネットAを、AZ-cにサブネットBをそれぞれ個別に作成し、その2つの異なるサブネットにリソースを分散デプロイする 」ことです [p.34]。
ひっかけ③：「DockerコンテナをホストするECSクラスターをVPC上で安全に動作させるため、VPC全体のCIDRブロックとして 172.17.0.0/16 を割り当てる。」
- 真実: 172.17.0.0/16 などのIPアドレス範囲は、Docker等のコンテナサービスや一部のAWS内部通信でデフォルトとして予約・競合する可能性が極めて高く、使用は非推奨とされています [p.32]。
- 理由: アドレスの重複・衝突が発生するとシステムがパケット転送に失敗するためです [p.32]。VPCを設計する際は、競合する可能性のある予約アドレス範囲を慎重に除外してCIDRをマッピングするのが鉄則です [p.32]。