結論ファースト：ルート分離設計で覚えるべき3つ
ルート分離とは「本番と開発のネットワークが互いに通信できないように壁を作る」こと。Transit Gateway（TGW）と Cloud WAN はアプローチが異なるが、目的は同じ。
🔵 TGW = ルートテーブルで分離
単一リージョン内で「どのVPCがどのルートテーブルに属すか」を制御。シンプルだが、リージョンごとに設定が必要。
🟠 Cloud WAN = セグメントで分離
グローバルに「セグメント」という論理的ネットワーク境界をポリシーで定義。マルチリージョンを一元管理できる。
🔵 TGWの選択基準
単一リージョン、コスト優先、既存TGWがある環境。アカウント数が少なく、手動管理の手間が許容できるケース。
🟠 Cloud WANの選択基準
マルチリージョン、ポリシー一元管理、大規模組織。将来の拡張性やSD-WAN連携が求められるケース。
🏨 AWS ネットワーク・ホテル（Transit Gateway / Cloud WAN）
4F 管理階
(Management)
🔑 管理VPC
📊 監視VPC
🔐 セキュリティVPC
🔒
3F 本番階
(Production)
🖥️ 本番App VPC
🗄️ 本番DB VPC
🔒
2F 開発階
(Development)
💻 開発VPC
🧪 ステージングVPC
🔒
1F 共用階
(Shared)
🌐 DNS/NTP VPC
📡 Egress VPC
🔗 Direct Connect
🔓
🚪 ロビー（インターネット / オンプレミス接続）
🏨 ホテルの要素
- ホテル全体 → TGW / Cloud WAN
- 各フロア → ルートテーブル / セグメント
- 各客室 → VPC（アタッチメント）
- カードキー → ルート（経路情報）
- フロア間エレベーター → ルート伝播設定
- 共用階アクセス権 → Shared Service 設定
🔑 フロア分離のルール
- 3F（本番）のカードキーでは2F（開発）に入れない
- 2F（開発）のカードキーでは3F（本番）に入れない
- 1F（共用）はどのカードキーでも入れる
- 4F（管理）は管理者カードキーだけで入れる
- フロアごとにカードリーダーを設定 = ルート伝播制御
- フロア追加 = 新しいルートテーブル/セグメント作成
🚧 ルート分離とは何か？ Before → After
ルート分離がない状態と、ルート分離を適用した状態の違いを可視化します。ルートテーブルを分けることで、VPC間の通信経路を制御し、意図しないトラフィックの流入を防ぎます。
❌ Before：分離なし（全VPCが通信可能）
本番 VPC-A
開発 VPC-B
共用 VPC-C
↕ ↕ ↕
単一ルートテーブル
⚠️ 全VPCが同一テーブル → 開発から本番に通信可能
リスク：開発環境の設定ミスが本番DBに影響
✅ After：ルート分離済み
本番
✕
開発
|
本番
✓
共用
|
開発
✓
共用
結果：本番↔開発は遮断、共用サービスは両方から利用可能
Transit Gateway
🔵 TGW：ルートテーブルによる分離
Transit Gateway では「ルートテーブル」を複数作成し、各VPCアタッチメントを適切なルートテーブルに関連付け（Association）することで通信経路を分離します。ルート伝播（Propagation）でどのルートテーブルに経路を広告するかを制御します。
TGW ルートテーブル分離アーキテクチャ
🔵 Transit Gateway
Association（関連付け）↓
+
Propagation（ルート伝播）↓
🔴 本番ルートテーブル
✅ 本番 VPC → 伝播あり
✅ 共用 VPC → 伝播あり
🚫 開発 VPC → 伝播なし
🔵 開発ルートテーブル
✅ 開発 VPC → 伝播あり
✅ 共用 VPC → 伝播あり
🚫 本番 VPC → 伝播なし
🟢 共用ルートテーブル
✅ 本番 VPC → 伝播あり
✅ 開発 VPC → 伝播あり
✅ 共用 VPC → 伝播あり
↓ アタッチメント
🏨 ホテルで例えると：
各フロア（ルートテーブル）にカードリーダー（Association）を設置し、「このフロアのカードキーで入れる部屋リスト」（Propagation）を個別に設定する方式。フロアごとにリーダーの設定を手動で行う必要がある。
Cloud WAN
🟠 Cloud WAN：セグメントによる分離
Cloud WAN では「セグメント」という論理的ネットワーク分離単位を使います。Network Policy でセグメント間の接続ルールを一括定義し、すべてのリージョンに自動適用されます。Segment Actions の allow / deny でセグメント間の通信可否をコントロールします。
Cloud WAN セグメント分離アーキテクチャ
🟠 Cloud WAN Global Network
↓ Core Network Policy（グローバル定義）
🔴 prod セグメント
本番環境用
✅ → shared 共有可
🚫 → dev 共有不可
🔵 dev セグメント
開発環境用
✅ → shared 共有可
🚫 → prod 共有不可
↓ 各リージョンに自動適用
🌏 ap-northeast-1（東京）
本番VPC
開発VPC
共用VPC
🌍 us-east-1（バージニア）
本番VPC
開発VPC
共用VPC
🏨 ホテルで例えると：
本社（Global Network）が「全支店のフロアルール」を一括で定義する方式。東京支店でも大阪支店でも同じカードキールールが自動適用される。新しい支店（リージョン）がオープンしても、ルールは自動で適用される。
📊 TGW vs Cloud WAN：ルート分離の詳細比較
どちらも「分離」は実現できますが、管理スコープ・コスト・柔軟性が大きく異なります。
| 比較項目 |
🔵 Transit Gateway |
🟠 Cloud WAN |
| 分離の単位 |
ルートテーブル（RT） |
セグメント（Segment） |
| 管理スコープ |
⚠️ リージョン単位（TGWごとに設定） |
✅ グローバル（ポリシーで全リージョン一括） |
| 設定方法 |
Association + Propagation を個別設定 |
Network Policy（JSON/YAML）で宣言的に定義 |
| 共用サービス接続 |
Propagation で共用RTに伝播 |
segment-actions の share で定義 |
| マルチリージョン |
⚠️ TGW Peering を追加構成 |
✅ 標準機能としてビルトイン |
| ルート数上限 |
RTあたり 10,000 ルート |
セグメントあたり 10,000 ルート |
| コスト感 |
✅ 低〜中（データ処理料+アタッチメント料） |
⚠️ 中〜高（Core Network Edge 料金が加算） |
| SD-WAN連携 |
❌ 標準では未対応 |
✅ Connect Attachment で対応 |
| 運用負荷 |
リージョン×環境数 分の設定管理 |
ポリシー1つで全環境を管理 |
| ホテルで例えると |
各支店が独自にカードキーを管理 |
本社が全支店のカードキーを一括管理 |
🎨 代表的なルート分離パターン 4選
実際の設計で頻出するルート分離パターンを図解します。要件に応じて組み合わせて使います。
1
環境分離パターン（本番 / 開発）
最も基本的なパターン。本番と開発を完全分離し、共用サービス（DNS・Egress）のみ両方からアクセス可能にする。
┌─ prod RT ──────────────┐
│ 本番VPC-A 本番VPC-B │
│ 共用VPC（伝播あり） │
│ 開発VPC（伝播なし）🚫 │
└────────────────────────┘
┌─ dev RT ───────────────┐
│ 開発VPC-A 開発VPC-B │
│ 共用VPC（伝播あり） │
│ 本番VPC（伝播なし）🚫 │
└────────────────────────┘
💡 用途：ほぼ全てのマルチアカウント設計の基礎
2
Spoke-Hub パターン（Shared Service Hub）
共用VPCをハブとして、各環境VPC（スポーク）がハブ経由でのみ通信する。スポーク同士は直接通信不可。
┌──────────┐
│ 共用 Hub │
│ (DNS,NW) │
└────┬─────┘
┌─────┼─────┐
↓ ↓ ↓
┌────┐ ┌────┐ ┌────┐
│本番│ │開発│ │STG │
└────┘ └────┘ └────┘
(互いに通信不可 🚫)
💡 用途：中央集約型NWサービス（Inspection VPC、NAT等）
3
BU（事業部）分離パターン
事業部ごとにセグメント/RTを分離。各事業部は独立運用しつつ、共用プラットフォームだけ共有。
┌─ BU-A seg ─┐ ┌─ BU-B seg ─┐
│ VPC-A1 │ │ VPC-B1 │
│ VPC-A2 │ │ VPC-B2 │
└──────┬─────┘ └──────┬─────┘
│ 🚫 相互遮断 │
↓ ↓
┌──── shared seg ─────┐
│ セキュリティ / 監視 │
└─────────────────────┘
💡 用途：M&A後の統合、コンプライアンス要件の厳しい組織
4
Inspection 挿入パターン
セグメント間通信にFirewall/IDS（Inspection VPC）を強制挟み込み。ルートテーブルのBlackholeとスタティックルートで制御。
┌─ prod seg ──┐ ┌─ dev seg ──┐
│ 本番VPC │ │ 開発VPC │
└──────┬──────┘ └──────┬─────┘
↓ ↓
┌─────── inspection seg ──────┐
│ 🔥 AWS Network Firewall │
│ (トラフィック検査・フィルタ) │
└─────────────────────────────┘
↕ 検査後のみ通信許可
💡 用途：金融・医療などの高セキュリティ要件
🔧 ルート分離を実装する5ステップ
TGW / Cloud WAN のどちらでも、基本的な流れは同じです。
1
分離境界の設計
環境別（本番/開発）、事業部別（BU-A/BU-B）、コンプライアンス別（PCI/非PCI）など、何を基準に分離するかを決定。
🏨 ホテルで例えると：フロアの区切り方（用途別？VIP別？）を決める
2
ルートテーブル/セグメントの作成
TGWなら専用ルートテーブルを作成、Cloud WANならNetwork PolicyにSegment定義を追加。
🏨 ホテルで例えると：各フロアにカードリーダーを設置する
3
VPCアタッチメントの関連付け
各VPCを適切なルートテーブル/セグメントに紐付け。TGWではAssociation、Cloud WANではsegment-nameを指定。
🏨 ホテルで例えると：客室を正しいフロアに配置する
4
ルート伝播/共有ルールの設定
共用サービスへの経路を必要なテーブルに伝播（Propagation）するか、segment-actionsのshareで共有設定。不要な経路は伝播しない。
🏨 ホテルで例えると：「1F共用階にはどのカードでも入れる」設定を追加
5
検証とBlackholeルート設定
意図した通信のみ可能かテスト。万全を期すなら、明示的にBlackholeルート（破棄ルート）を追加して、分離漏れを防ぐ。
🏨 ホテルで例えると：全カードキーで出入りテスト → 非常階段に鍵をかける
💻 設定コード例
TGW（CloudFormation）と Cloud WAN（Network Policy JSON）の実装例を比較します。
TGW（CloudFormation）
Cloud WAN（Policy JSON）
Resources:
ProdRouteTable:
Type: AWS::EC2::TransitGatewayRouteTable
Properties:
TransitGatewayId: !Ref TransitGateway
Tags:
- Key: Name
Value: prod-route-table
DevRouteTable:
Type: AWS::EC2::TransitGatewayRouteTable
Properties:
TransitGatewayId: !Ref TransitGateway
Tags:
- Key: Name
Value: dev-route-table
ProdAssociation:
Type: AWS::EC2::TransitGatewayRouteTableAssociation
Properties:
TransitGatewayAttachmentId: !Ref ProdVpcAttachment
TransitGatewayRouteTableId: !Ref ProdRouteTable
SharedToProdPropagation:
Type: AWS::EC2::TransitGatewayRouteTablePropagation
Properties:
TransitGatewayAttachmentId: !Ref SharedVpcAttachment
TransitGatewayRouteTableId: !Ref ProdRouteTable
BlockDevFromProd:
Type: AWS::EC2::TransitGatewayRoute
Properties:
TransitGatewayRouteTableId: !Ref ProdRouteTable
DestinationCidrBlock: 10.1.0.0/16
Blackhole: true
{
"version": "2021.12",
"core-network-configuration": {
"asn-ranges": ["64512-65534"],
"edge-locations": [
{ "location": "ap-northeast-1" },
{ "location": "us-east-1" }
]
},
"segments": [
{
"name": "prod",
"require-attachment-acceptance": true,
"isolate-attachments": false
},
{
"name": "dev",
"require-attachment-acceptance": false,
"isolate-attachments": false
},
{
"name": "shared",
"require-attachment-acceptance": false,
"isolate-attachments": false
}
],
"segment-actions": [
{
"action": "share",
"mode": "attachment-route",
"segment": "shared",
"share-with": ["prod", "dev"]
}
],
"attachment-policies": [
{
"rule-number": 100,
"conditions": [
{ "type": "tag-value",
"key": "Environment",
"value": "prod" }
],
"action": {
"association-method": "constant",
"segment": "prod"
}
}
]
}
⚠️ よくあるアンチパターンと対策
ルート分離設計で陥りやすい落とし穴と、正しい対処法を対比します。
❌ 単一ルートテーブルに全VPCを詰め込む
「設定が楽だから」とデフォルトRTに全VPCをアタッチ。環境間の通信が全て許可される。
⚡ 影響：開発環境のテストトラフィックが本番DBに到達するリスク
✅ 環境ごとにルートテーブルを分ける
最低でも「本番」「開発」「共用」の3つのRTを作成。共用サービスだけ両環境にPropagation。
🛡️ 効果：本番と開発が完全に論理分離。セキュリティ境界が明確化
❌ Blackholeルートを入れずに「伝播しない＝安全」と思い込む
Propagationを設定しなくてもスタティックルートの追加漏れや将来の変更でルートが追加される可能性。
⚡ 影響：運用中にルートが意図せず追加され、分離が崩壊するリスク
✅ Blackholeルートで明示的に遮断する
分離したいCIDRに対してBlackholeルートを明示的に設定。「伝播しない」ではなく「破棄する」で防御。
🛡️ 効果：Defense-in-Depth（多層防御）。万が一の伝播ミスも最終防壁で遮断
✨ ルート分離 ベストプラクティス 6選
📋 1. 命名規則を統一する
ルートテーブル名/セグメント名を「{env}-{purpose}-rt」形式で統一。タグも合わせて管理。
🚫 2. Blackhole ルートで多層防御
Propagation未設定に加え、分離対象のCIDRにBlackholeを設定して明示的に遮断する。
🔍 3. VPC Flow Logs + Route Analyzer で検証
分離が正しく機能しているかを定期的に検証。Cloud WANにはRoute Analyzerが標準搭載。
📐 4. IaCで構成をコード管理
CloudFormation / Terraform でルートテーブル・セグメント構成を管理し、変更履歴を追跡可能に。
🏷️ 5. タグベースの自動振り分け
Cloud WANのattachment-policiesでタグ条件を定義し、VPCアタッチメントを自動でセグメントに振り分け。
📊 6. CIDRの重複を絶対に避ける
異なるセグメント間でCIDRが重複するとルーティングが破綻。IPAM（IP Address Manager）で一元管理。
🤔 どちらを選ぶ？ 判断フローチャート
自分の環境に合ったルート分離サービスを選択しましょう。
❓ マルチリージョン構成が必要？
YES
🟠 Cloud WAN を推奨
ポリシー一元管理のメリット大
NO
❓ VPC数が20以上 or 将来的な拡大予定？
💡 補足：TGW → Cloud WAN への移行パスもある。まずTGWで始めて、必要に応じてCloud WANに移行する段階的アプローチも有効。