VPC が10を超え、アカウントも事業部ごとに分かれ、オンプレミスのデータセンターとも専用線でつなぐことになった。ピアリングを1本ずつ張ってきた構成は、新しい VPC を足すたびにルートの設定が増え、誰もネットワーク全体の図を描けなくなっています。「Transit Gateway にすべきか」「Cloud WAN が要るのか」「専用線は何本引けばいいのか」と聞かれても、サービスの説明では答えになりません。
答えは要件で変わります。この記事は、規模・アカウント数・規制・可用性・コスト・運用体制の6つの軸から、接続方式・回線の冗長化・アドレス設計・出口の置き方を判断の順番として整理します。
この記事の結論
- 3つ以上の VPC やオンプレミスを相互につなぐなら、メッシュよりハブ型（Transit Gateway）を選ぶのが Well-Architected の推奨です。
- 特定のサービスだけを一方向に公開するなら、VPC 全体をつながずに PrivateLink を使うと、CIDR が重複していても接続できます。
- 多くのリージョンと拠点をポリシーで一貫して区分したいときは、Transit Gateway の組み合わせより Cloud WAN が候補になります。
- 専用線は「どの障害まで耐えるか」で本数とロケーションを決め、費用を抑えるなら Site-to-Site VPN をバックアップに置きます。
- CIDR の重複は後から直すのが最も高くつくので、IPAM のプールから割り当てる仕組みを最初に作ります。
ネットワーク設計で先に決める要件とは
接続方式を選ぶ前に、次の6つを文章で書き出します。ここが曖昧なまま「Transit Gateway でいいですか」と聞かれても、比較の土台がありません。
| 軸 | 何を確かめるか | 答えが変えるもの |
|---|---|---|
| 規模 | VPC の数、リージョンの数、1年後の見込み | ピアリングかハブ型か、Transit Gateway か Cloud WAN か |
| アカウントと所有 | 誰が VPC を作り、誰がルートを変えるか | 共有 VPC にするか、VPC をアカウントごとに持たせるか |
| 規制 | インターネットを通せない通信、暗号化、検査の義務 | 専用線と VPN の組み合わせ、集中型の検査を置くか |
| 可用性 | 回線やロケーションの障害でどこまで止まってよいか | 専用線の本数とロケーション、VPN のバックアップ |
| コスト | 時間単位の料金とデータ処理の料金のどちらが効くか | ハブを経由させる通信の範囲、出口を集めるか |
| 運用体制 | ネットワークを専任で見るチームがいるか | 中央で持つ部品の量、ポリシーで宣言する仕組みを選ぶか |
AWS Well-Architected フレームワークの信頼性の柱は、ネットワークの設計で「ハブアンドスポークをメッシュより優先する」「接続するアドレス空間の範囲を重複させない」「オンプレミスとの接続を冗長にする」をベストプラクティスとして挙げています。この3つは要件が何であっても外さない前提として置き、残りを6つの軸で決めます。
DESIGN INPUTS先に書き出す要件
接続方式は要件の軸を書いてから選ぶ
-
1.規模 — VPC とリージョンの数、1年後の見込み
2つならピアリング、3つ以上ならハブ型、多数のリージョンなら Cloud WAN
-
2.所有 — 誰が VPC を作り、誰がルートを変えるか
共有 VPC で中央に寄せるか、アカウントごとに持たせるか
-
3.規制 — 閉域・暗号化・検査の義務
専用線と VPN の組み合わせ、集中型の検査
-
4.可用性と体制 — どの障害まで耐え、誰が運用するか
専用線の本数とロケーション、中央で持つ部品の量
とくに見落とされやすいのが「運用体制」です。Transit Gateway のルートテーブルを分けてセグメントを作る設計は柔軟ですが、関連付けと伝播の意味を理解している人がいないと、変更のたびに通信が止まります。ネットワークの専任チームがいない組織では、部品を減らす方向（共有 VPC で VPC の数を減らす、ハブを1つにする）に倒すほうが、構成図の上では地味でも運用で崩れにくい設計になります。
VPC 同士をどうつなぐか ─ ピアリング・Transit Gateway・PrivateLink・Cloud WAN の違いは?
4つは「何をつなぐか」が違います。VPC 全体を互いに通すのか、特定のサービスだけを片方向に見せるのかで、候補がまず半分に分かれます。
| 方式 | つなぐ単位 | 推移（A→B→C） | CIDR の重複 | 料金の形 | 向く場面 |
|---|---|---|---|---|---|
| VPC ピアリング | VPC と VPC を1対1 | しない | 扱えない | データ転送料のみ | 少数の VPC、2つの間の大量の通信、リージョン間の直結 |
| Transit Gateway | リージョン内のハブに VPC・VPN・専用線を集約 | ルートテーブルで制御 | 扱えない | アタッチメントの時間料金＋データ処理 | 3つ以上の VPC とオンプレミス、環境ごとの分離 |
| PrivateLink | 特定のサービス（NLB の背後）を一方向に公開 | 対象外 | 扱える | エンドポイントの時間料金＋データ処理 | SaaS の提供、共有サービス、AWS の API への閉域の到達 |
| Cloud WAN | 複数リージョンと拠点をポリシーで束ねる | セグメントで制御 | 扱えない | 公式の料金ページで確認 | 多数のリージョンと拠点、全体で一貫した区分 |
料金の具体的な単価は公式の料金ページで確認してください。形だけ見ても、ピアリングに時間単位の料金が無いことは効きます。AWS のホワイトペーパー「Building a Scalable and Secure Multi-VPC AWS Network Infrastructure」も、Transit Gateway がピアリングの管理の複雑さを解く一方で、コストの低さや経由する機器が1つ減る点からピアリングが今も妥当な選択肢だと書いています。
判断の順番は次のとおりです。
- 片方向のサービス公開で足りるか。 顧客や他部署に API を見せるだけなら PrivateLink。VPC 全体をつながないので、相手の CIDR が重複していても接続でき、到達範囲もサービス1つに絞れます。
- 相互につなぐ VPC は2つだけか、増えないか。 ピアリングで足ります。3つ以上を相互につなぐなら、ピアリングは推移しないためメッシュが膨らみます。
- 1〜少数のリージョンか。 Transit Gateway をハブにし、ルートテーブルの関連付けと伝播で本番・開発・共有サービスを分けます。リージョン間は Transit Gateway 同士をピアリングし、相手の CIDR は静的ルートで足します。
- 多数のリージョンと拠点を、同じ区分で一貫して管理したいか。 Cloud WAN のコアネットワークポリシーでセグメント（分離されたルーティングの領域）を定義し、アタッチメントをタグでセグメントに割り当てます。
HOW TO CONNECT VPCSつなぐ単位と数
3つ以上を相互につなぐならハブ型、サービス単位ならPrivateLink
相互に通す範囲の広さ →
VPC ピアリング
少数の VPC を1対1で。推移しない。料金はデータ転送だけ
Transit Gateway / Cloud WAN
多数をハブで束ね、ルートテーブルやセグメントで分ける
PrivateLink
特定のサービスだけを一方向に。CIDR が重複していても使える
エンドポイントを集約
共有サービス VPC にまとめ、プライベートホストゾーンで各 VPC から引く
つなぐ VPC とリージョンの数 →
4つは排他ではありません。ホワイトペーパーも、API 型のクライアントとサーバーの通信は PrivateLink、大量の通信がある2つの VPC はピアリング、多数の VPC とオンプレミスの集約は Transit Gateway、と組み合わせる形を示しています。ハブを通すと料金と経由する機器が増えるので、「全部をハブに通す」のではなく「ハブに通す理由がある通信だけを通す」と決めておくと、後からコストの説明がつきます。
CHECK 1ここまでの確認
5つの VPC をすべて互いに通信させたいとき、VPC ピアリングだけで組むと何が起きる?
答えと解説
答え: 1. ピアリングは推移しないので、組み合わせの数だけ接続とルートが要る
ピアリングは1対1で、A と B、A と C をつないでも B と C は通れません。数が増えるほどメッシュが膨らむので、3つ以上をつなぐならハブ型を検討します（「VPC 同士をどうつなぐか」の比較表）。
オンプレミスとの接続は Direct Connect と VPN をどう組み合わせるか?
専用線（Direct Connect）の設計は、「どの障害まで耐えるか」を先に決めると本数とロケーションが決まります。AWS の Direct Connect のドキュメントは、回復性の水準を次のように分けています。
| 構成 | 耐える障害 | 向く要件 |
|---|---|---|
| Site-to-Site VPN だけ | インターネット経路の揺らぎには弱い | 帯域と遅延の安定を求めない、まず閉域でつなぎたい |
| 専用線1本＋VPN をバックアップ | 回線断（帯域は下がる） | 費用を抑えつつ、回線が切れても業務を続けたい |
| 開発・テスト向け（1ロケーション・別デバイス） | デバイスの障害。ロケーション全体の障害には耐えない | 重要度の低いワークロード |
| 高い回復性（2ロケーションに1本ずつ） | 回線断・デバイス障害、ロケーション全体の障害への備え | 重要なワークロード |
| 最大の回復性（2ロケーション以上・別デバイスに2本ずつ） | デバイス・回線・ロケーション全体の障害 | 止まると業務に大きな影響が出る基幹系 |
HYBRID RESILIENCYオンプレミスとの接続
専用線の本数はどの障害まで耐えるかで決まる
-
VPN
Site-to-Site VPN だけ
まず閉域でつなぐ。インターネット経路の揺らぎには弱い
-
1本＋VPN
専用線1本に VPN をバックアップとして足す
回線断でも帯域を落として続ける。同じ経路なら専用線が優先
-
高い
2つのロケーションに1本ずつ
回線断・デバイス障害に加え、ロケーションの障害に備える
-
最大
2つ以上のロケーションで、別デバイスに2本ずつ
デバイス・回線・ロケーション全体の障害に耐える基幹系向け
VPN と専用線に同じプレフィックスを広告すると、AWS は専用線側の経路を優先します。VPN が「普段は使われず、専用線が切れたときだけ使われる」予備になるのはこの性質のためです。優先度を細かく決めたいときは、AWS からオンプレミスへの方向は BGP コミュニティで、オンプレミスから AWS への方向はオンプレミス側のルーターで決めます。向きによって設定する場所が違うことは、設計書に明記しておくと障害時の切り分けが速くなります。
複数のリージョンと複数の VPC に1本の専用線から届かせるときは、Direct Connect ゲートウェイが中継になります。VPC が多いなら、トランジット仮想インターフェイスで Direct Connect ゲートウェイと各リージョンの Transit Gateway をつなぐ形が、VPC ごとの設定を増やさずに済みます。
規制で暗号化が求められる場合、専用線を引いただけでは要件を満たせません。対応する専用接続で MACsec を有効にするか、専用線の上に IPsec の VPN を張ります。VPN の終端にパブリック IP を使えない規程なら、Transit Gateway とトランジット仮想インターフェイスでプライベート IP の VPN を組みます。VPN の帯域を1本のトンネルより増やしたいときは、ECMP に対応する Transit Gateway 側で複数の VPN を束ねます。
冗長化は「組んだ」だけでは完成しません。Direct Connect には BGP セッションを意図的に落として切り替わりを確かめる試験の仕組みがあります。本番の前に、片方を落としても業務の通信が残ることを確かめ、結果を記録します。
CHECK 2ここまでの確認
専用線1本の構成に、費用を抑えて回線断への備えを足すなら、まず何を検討する?
答えと解説
答え: 2. Site-to-Site VPN をバックアップとして足し、BGP で専用線の経路を優先させる
帯域が下がっても業務を続けられればよいなら、VPN をバックアップにするのが安い組み合わせです。同じ経路なら専用線側が優先されます（「オンプレミスとの接続」の段階の表）。
IP アドレスと DNS を先に決める理由とは
接続方式は後から変えられますが、CIDR の重複は後から直すのが最も高くつきます。ピアリングも Transit Gateway も VPN も、重複した範囲どうしを経路でつなげません。Well-Architected の信頼性の柱も、接続するすべてのプライベートアドレス空間で範囲を重複させないこと、必要なときに割り当てられる仕組みを持つことを求めています。
CIDR は台帳ではなくプールから割り当てる
アドレスの設計は、大きな範囲をリージョン・環境の順に分け、その下から VPC に割り当てる階層にします。こうするとリージョンごとに経路をまとめて広告でき、オンプレミス側のルーターが受け取る経路の数も減ります。
この割り当てを表計算で管理すると、アカウントが増えたところで重複が起きます。VPC IP Address Manager（IPAM）でプールを階層化し、AWS Organizations と連携して組織のアカウントに共有すれば、VPC を作るときにプールから重複しない CIDR が割り当てられます。使用状況の監視と割り当ての履歴も同じ画面で追えます。
すでに重複している場合（買収した会社の VPC が同じ範囲を使っている、など）の選択肢は2つです。サービス単位で足りるなら PrivateLink。VPC どうしの通信が要るなら、重複しないセカンダリ CIDR を足してプライベート NAT ゲートウェイで変換し、その範囲だけを経路に載せます。どちらも回避策で、構成は複雑になります。
ハイブリッド DNS は Resolver のエンドポイントを1か所に集める
オンプレミスと AWS の間で互いの名前を引けないと、つながっているのに使えないネットワークになります。Route 53 の Resolver は、オンプレミスから AWS の名前を引くためのインバウンドエンドポイントと、AWS からオンプレミスの名前を引くためのアウトバウンドエンドポイントと転送ルールで、DNS サーバーを別に立てずに双方向の名前解決を組めます。
アカウントが多いときは、エンドポイントを共有サービスの VPC に集め、転送ルールを AWS RAM で各アカウントに共有して VPC に関連付けます。エンドポイントは可用性のため、異なる AZ の2つ以上のサブネットに置くことが推奨されています。インターフェイス型の VPC エンドポイントも同じ考え方で共有サービスの VPC に集め、プライベートホストゾーンを各 VPC に関連付けると、VPC ごとにエンドポイントを作る費用と手間を減らせます。
READ ALSO — 未経験向け・段1 入口
サブネットと CIDR とは何か｜/24 の読み方・プライベート IP・ネットワーク部とホスト部
共有 VPC と集中型の出口 ─ 何をネットワークアカウントに寄せるか
アカウントを分けても、ネットワークまでアカウントごとに持たせる必要はありません。何を中央（ネットワークアカウント）に寄せ、何を各アカウントに残すかが、マルチアカウントのネットワーク設計の中心の判断です。
共有 VPC（AWS RAM）で VPC の数を減らす
VPC の所有者が AWS RAM でサブネットを同じ組織の他のアカウントに共有すると、参加者のアカウントはそのサブネットに自分のリソースを作れます。サブネット・ルートテーブル・ネットワーク ACL・ゲートウェイ・Transit Gateway のアタッチメントは所有者が管理し、参加者は他の参加者や所有者のリソースを見たり変えたりできません。
VPC とアタッチメントの数が減り、IP アドレスの消費も抑えられる一方、1つの VPC を多くのチームが使うので、所有者のルート変更の影響範囲は広がります。アプリチームが経路を自分で変えたい文化なら、VPC をアカウントごとに持たせて Transit Gateway を RAM で共有する形のほうが合います。
出口と検査を集めるか、VPC ごとに持つか
| 観点 | VPC ごとに NAT と検査を持つ | 検査用 VPC に集める |
|---|---|---|
| 通信の経路 | VPC から直接インターネットへ | Transit Gateway で検査用 VPC を経由 |
| 部品の数 | VPC の数だけ NAT ゲートウェイと検査の仕組み | 1か所（リージョンごと） |
| ルールの一貫性 | VPC ごとにずれやすい | 1つのポリシーで揃う |
| 障害の影響範囲 | その VPC だけ | 集約した全 VPC に及ぶ |
| 料金の形 | NAT ゲートウェイの時間料金が VPC の数だけ | NAT は減るが、Transit Gateway のデータ処理が加わる |
集中型の出口では、各 VPC のアタッチメントを関連付けた Transit Gateway のルートテーブルに、すべての外向き通信を検査用 VPC に送る静的ルートを置きます。検査用 VPC で AWS Network Firewall を通し、許可された通信だけが NAT ゲートウェイからインターネットへ出ます。ステートフルな検査では、行きと帰りが別の AZ を通ると通信が壊れるので、検査用 VPC のアタッチメントでアプライアンスモードを有効にします。
マルチアカウントのネットワークで起きやすい事故の型
- CIDR を各チームに任せ、つなぐ段になって重複が見つかる
- 専用線を2本引いたが同じロケーション・同じデバイスで、ロケーションの障害で両方止まる
- 集中型の検査で経路が非対称になり、特定の AZ を通る通信だけが落ちる
- 共有 VPC の参加者がルートを変えられないことを知らずに、障害対応が所有者待ちで止まる
CHECK 3ここまでの確認
事業部ごとにネットワークアカウントが VPC を作り、アプリチームのアカウントにサブネットを共有した。ルートテーブルを変えられるのは誰?
答えと解説
答え: 2. VPC を所有するネットワークアカウント
共有 VPC では、サブネット・ルートテーブル・ネットワーク ACL・ゲートウェイは所有者の責任です。参加者は自分のリソースだけを操作します（「共有 VPC と集中型の出口」の章）。
判断の順番をまとめると
- 要件を6つの軸で書く。 規模・アカウントと所有・規制・可用性・コスト・運用体制。
- アドレスの計画を先に作る。 IPAM のプールを階層化し、重複しない CIDR をプールから割り当てる。
- つなぐ単位を決める。 サービス単位なら PrivateLink、少数の VPC ならピアリング、3つ以上なら Transit Gateway、多数のリージョンと拠点を一貫して区分するなら Cloud WAN。
- 専用線の水準を決める。 どの障害まで耐えるかで本数とロケーションを決め、VPN をバックアップに置くかを決める。暗号化の要件があれば MACsec か VPN を足す。
- 中央に寄せるものを決める。 共有 VPC、Resolver のエンドポイント、インターフェイス型エンドポイント、出口と検査。寄せるほど一貫し、寄せるほど影響範囲が広がる。
- 切り替えを試して、判断を記録する。 専用線の切り替え試験の結果と、選ばなかった案とその理由を残す。
どの構成にも、得るものと捨てるものがあります。ピアリングは安くて速いが増えると管理できない、Transit Gateway は束ねられるが料金と経由する機器が増える、集中型の出口は揃うが止まったときの範囲が広い。要件が変わったら（リージョンが増えた、規制が変わった、専任チームができた）、この順番をもう一度たどります。設計の判断を根拠つきで説明する型は、次に読む記事で扱います。
参照ソース
- Building a Scalable and Secure Multi-VPC AWS Network Infrastructure（AWS ホワイトペーパー） — 複数 VPC の接続方式の全体像と組み合わせ方の根拠（2026-09 時点の記載）
- Transit Gateway vs VPC peering（同ホワイトペーパー） — ピアリングと Transit Gateway の料金の形・経由する機器の違い（2026-09 時点の記載）
- AWS PrivateLink（同ホワイトペーパー） — サービス単位の一方向の公開という位置づけ（2026-09 時点の記載）
- Centralized egress to internet（同ホワイトペーパー） — 集中型の出口と Network Firewall による検査の構成（2026-09 時点の記載）
- What is AWS Cloud WAN? と Cloud WAN のセグメント — コアネットワークポリシーとセグメントの定義（2026-09 時点の記載）
- What is a transit gateway?（Amazon VPC Transit Gateways） — Transit Gateway の役割（2026-09 時点の記載）
- Resilience in AWS Direct Connect — 開発・テスト／高い回復性／最大の回復性の3つの水準と切り替え試験（2026-09 時点の記載）
- What is AWS Site-to-Site VPN? — VPN 接続の仕組み（2026-09 時点の記載）
- What is IPAM? — プールからの CIDR の割り当てと組織全体での管理（2026-09 時点の記載）
- Share your VPC subnets with other accounts と 所有者と参加者の責任 — 共有 VPC の前提と責任の分担（2026-09 時点の記載）
- Route 53 Resolver endpoints and forwarding rules（Hybrid Cloud DNS Options for Amazon VPC） — インバウンド・アウトバウンドエンドポイントと転送ルール、RAM での共有（2026-09 時点の記載）
- REL02-BP04 Prefer hub-and-spoke topologies over many-to-many mesh・REL02-BP05 非重複の IP アドレス範囲・REL02-BP02 冗長な接続（Well-Architected 信頼性の柱） — ハブ型・アドレスの非重複・接続の冗長化のベストプラクティス（2026-09 時点の記載）
