2026-08-14（金）VPC（ネットワークの土台）

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

本範囲（第2章2-3後半・まとめ、p.46-50）は、多数のVPCやオンプレミス拠点が混在するエンタープライズ環境において、ネットワークトポロジーをいかにシンプルかつスケーラブルに統合するかを扱います [p.46]。

1対1のVPCピアリング接続では不可能な「中継ルーティング（推移的ルーティングの禁止）」を解決し、複数の接続先を中心で一元制御する「 AWS Transit Gateway 」の仕様を深く理解することが重要です [p.40, p.46-47]。

試験では、接続の規模感（小規模なピアリングか、大規模なTransit Gatewayによるスター型集約か）とコストの最適化を天秤にかける設計判断が頻出します [p.47, p.51-52]。

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

キーワード	説明
AWS Transit Gateway (TGW) [p.46]	複数のVPC、AWS Site-to-Site VPN、AWS Direct Connectなどの接続を集約し、クラウド上の仮想ルーター（ハブ）としてスター型トポロジーで中央ルーティングする接続管理サービス [p.46-47]。
スター型（ハブ＆スポーク）トポロジー [p.46]	中央に「ハブ（中継拠点）」を置き、そこから各ネットワーク（スポーク）へ車輪のスポークのように放射状に回線をマッピングする論理構造 [p.46-47]。管理複雑性を一定（O(1)）に保ちます [p.47]。
フルメッシュ接続（スパゲッティ化） [p.47]	多数のVPC同士を1対1で漏れなく繋ぐ手法 [p.47]。VPC数が「N」の場合、必要な接続数は「\\(N(N-1)/2\\)」となり、ルート管理や設定変更が破滅的に破綻します [p.47, p.51]。
推移的（Transit）ルーティングの禁止 [p.40]	VPCピアリングやDirect Connect ゲートウェイにおいて、接続された中間のネットワークを経由して「その隣のネットワーク」へ通信を踏み越えて転送することを禁じる仕様制限 [p.40, p.51-52]。

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

試験では、「 VPCピアリング」「Direct Connect ゲートウェイ」「Transit Gateway 」の3つのルーティング範囲と限界の違いが鋭く問われます [p.40, p.45, p.46]。

① VPC間接続の使い分け：VPCピアリング vs AWS Transit Gateway [p.40, p.46-47, p.51]

比較項目	VPCピアリング接続 [p.40]	AWS Transit Gateway [p.46]
通信トポロジー	1対1（P2P）の直接接続 [p.40]。	ハブ＆スポーク（スター型）の中央集約接続 [p.46]。
推移的ルーティング	非サポート（A ⇔ B ⇔ C のとき、AからCへB経由では通信不可） [p.40, p.51-52]。	サポート（TGWをハブとして、接続されたすべてのVPC間で相互中継ルーティングが可能） [p.47]。
大規模化への耐性	接続数が増えるほど設定・管理（ルートテーブル管理等）が指数関数的に複雑化する [p.47, p.51]。	接続数が数十〜数百に増えても、中央のTGWにアタッチするだけでルートが一元管理できる [p.46-47]。
課金・コスト構造	設定費用は無料（ピアリング内のデータ転送量にのみ課金）。	デプロイされるアタッチメントごとの時間料金（基本料）＋データ処理手数料が有料で発生。
試験での決定シグナル	「 2〜3個程度の少ないVPCを、最も追加コストをかけずにシンプルに閉域直結したい」 [p.47]	「数十〜数百のVPCがあり、それらの間で網の目のような相互通信やVPN・DX回線の動的な一括ルーティング共有を確立したい」 [p.46-47, p.52]

② ハイブリッド一元化：Direct Connect ゲートウェイ vs Transit Gateway [p.45, p.46-47, p.51]

比較項目	Direct Connect ゲートウェイ (DXGW) [p.45]	AWS Transit Gateway (TGW) [p.46]
接続の主目的	異なるリージョン・アカウントにある最大10個のVPC（VGW）へ、1本のDX回線を安価に集約接続する [p.45, p.51]。	クラウド上のあらゆるリソース（VPC、VPN、DX）をスター型に相互通信ルーティングする [p.46-47]。
アタッチしたVPC間の通信	不可能（DXGW自体にルーター機能はないため、VPC同士のパケット往来は完全に遮断される） [p.51]。	可能（オンプレミスへの閉域アクセスだけでなく、TGW配下のVPC同士も自由に高速中継通信できる） [p.47]。
試験での決定シグナル	「オンプレミスから複数リージョンのVPCへ専用線で繋ぐだけでよく、VPC同士を通信させる必要は全くない（むしろセキュリティ上、VPC同士は完全隔離したい）」 [p.45, p.51]	「オンプレミスとの専用線接続に加え、複数のVPC同士も相互に通信させてマイクロサービス間連携を行いたい」 [p.46-47, p.52]

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

ひっかけ①：VPC-A、VPC-B、VPC-Cの3つがあり、VPC-Bを中心に置いてAとピアリング、Cともピアリングした。このとき、VPC-Bのルートテーブルにて「A宛てはピアリングAへ」「C宛てはピアリングCへ」と正しくパケット設定を書き込めば、VPC-AからVPC-CへBを経由して通信させることができる。
- 真実: 通信できません [p.40, p.51-52]。
- 理由: VPCピアリングには「 推移的（Transit）ルーティングの禁止 」という厳格な物理仕様制限があるため、中間に位置するVPC-Bのルーターを踏み台にして隣接VPCへ通信をスルー中継することは絶対に不可能です [p.40, p.51-52]。この要件では、AとCの間に直接1対1のピアリングを張るか [p.40]、3つのVPCを AWS Transit Gateway に接続して中央ルーティングを行う必要があります [p.46-47, p.52]。
ひっかけ②：1本のAWS Direct Connect（物理専用回線）を効率よく利用するため「Direct Connect ゲートウェイ（DXGW）」を構築し、そこへ3つの子アカウントのVPCをそれぞれ接続した。この状態で、各VPC同士が互いのプライベートIPを使って直接パケットを受け渡しできるようにルーティング定義を追加する。
- 真実: Direct Connect ゲートウェイを介して、接続されたVPC同士が互いに直接通信することは物理仕様上不可能です [p.51-52]。
- 理由: DXGWはオンプレミス ⇔ VPC 間のマルチリージョン・マルチアカウント引き込みを仲介するだけのオブジェクトであり、VPC間ルーティングの中継ハブとしては機能しません [p.45, p.51-52]。オンプレミスへの専用線接続と、VPC同士の相互通信を両立させるためには、必ず Transit Gateway を構築してDX回線（トランジット仮想インターフェース：Transit VIF）および各VPCをそこに接続するアーキテクチャが必須となります [p.46-47, p.52]。