VPCピアリング vs Transit Gateway — スケール・コスト・ルーティングの違い

VPCピアリングとTransit Gatewayの根本的な違い

2つのVPCを接続する方法として、VPCピアリングとTransit Gatewayがある。それぞれの設計思想を理解することがアーキテクチャ選択の鍵だ。

特徴	VPCピアリング	Transit Gateway
接続モデル	1対1（メッシュ）	ハブアンドスポーク
推移的ルーティング	不可	可能
最大接続数	125ピアリング/VPC	5,000 VPC/TGW
クロスアカウント	可能	可能（RAM共有）
クロスリージョン	可能（Inter-Region Peering）	可能（TGW Peering）
コスト	データ転送料金のみ	TGW時間料金＋データ処理料金

VPCピアリングの制約

推移的ルーティング不可

VPC A ←ピアリング→ VPC B ←ピアリング→ VPC C

AとCを直接通信させたい場合:
❌ A → B → C は不可（推移的ルーティング禁止）
✅ AとCを直接ピアリングする必要がある

メッシュ接続数の爆発

VPC数が増えると接続数がn(n-1)/2で増加する。

VPC 10個の完全メッシュ: 10×9/2 = 45本のピアリング
VPC 20個の完全メッシュ: 20×19/2 = 190本のピアリング（上限125を超える）

各ピアリングに対してルートテーブルの手動更新が必要なため、管理コストも指数的に増大する。

Transit Gatewayの仕組み

Transit Gateway（TGW）はハブとして機能し、すべてのVPCやVPN/Direct Connectをそこに接続する。

                    Transit Gateway
                         ↑
          ┌──────────────┼──────────────┐
      VPC A            VPC B            VPC C
          └──────────────┴──────────────┘
                VPN/Direct Connect

TGWのルートテーブルを一元管理することで、VPC同士・VPCとオンプレミスの通信経路を統括できる。

# TGWアタッチメント作成
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-xxx \
  --vpc-id vpc-yyy \
  --subnet-ids subnet-aaa subnet-bbb

# TGWルートテーブルにルートを追加
aws ec2 create-transit-gateway-route \
  --transit-gateway-route-table-id tgw-rtb-xxx \
  --destination-cidr-block 10.1.0.0/16 \
  --transit-gateway-attachment-id tgw-attach-yyy

セグメンテーション設計

Transit Gatewayの複数ルートテーブルを使って、セグメント間のトラフィックを分離できる。

ルートテーブルA（本番環境）:
  本番VPC → 本番VPC: 許可
  本番VPC → 開発VPC: 禁止

ルートテーブルB（開発環境）:
  開発VPC → 開発VPC: 許可
  開発VPC → 本番VPC: 禁止

→ 本番と開発を完全に分離しつつ、各環境内は相互通信可能

コスト比較

VPCピアリング:
  接続自体の固定料金: なし
  データ転送: $0.01/GB（同リージョン、アベイラビリティゾーン間は$0.01）

Transit Gateway:
  アタッチメント料金: $0.05/時間/アタッチメント
  データ処理料金: $0.02/GB

例: 1ヶ月100GBのデータを3VPC間で転送する場合
  ピアリング（3本）: 3×$0 + 100GB×$0.01 = $1
  TGW（3アタッチ）: 3×$0.05×730時間 + 100GB×$0.02 = $109.5 + $2 = $111.5

VPC数が少なく転送量も少ない場合はピアリングが安い。VPC数が多い場合はTGWの管理コスト削減効果が料金を上回る。

選択基準

VPCピアリングが適するケース:
  - VPC数が少ない（5つ以下）
  - 特定のVPC間のみ接続（全結合不要）
  - コストを最小化したい
  - シンプルな構成を維持したい

Transit Gatewayが適するケース:
  - VPC数が多い（10以上）
  - 全VPCを相互接続したい
  - オンプレミスとVPCを一元管理したい
  - 環境ごとのセグメンテーションが必要
  - マルチアカウントの集中管理

マルチアカウントでのTGW共有

AWS RAMを使ってTGWを複数アカウントで共有できる。

# TGWをRAMで共有（管理アカウント側）
aws ram create-resource-share \
  --name shared-tgw \
  --resource-arns arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway/tgw-xxx \
  --principals arn:aws:organizations::123456789012:organization/o-xxx

試験頻出ポイント

シナリオ	回答
VPC AからCへ（B経由のピアリング）	不可（推移的ルーティング禁止）
VPC数20個の完全メッシュ接続	Transit Gateway
シンプルな2VPC接続でコスト最小化	VPCピアリング
本番/開発の通信を分離しつつTGW使用	TGWの複数ルートテーブル

まとめ

VPCピアリングはシンプルで安価だが推移的ルーティングができず、VPC数が増えると管理が複雑になる。Transit GatewayはコストはかかるがVPC数が多い環境での管理を大幅に簡素化できる。実際のアーキテクチャではVPC数と接続パターンでどちらを選ぶか判断する。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感