「VPCピアリングとTransit Gatewayの違いが曖昧で、設計方針を決めきれない」
複数のVPCが増えてきたとき、ネットワーク接続の設計でつまずくエンジニアは多い。ピアリングでいいのか、Transit Gatewayを使うべきなのか。その判断基準がわからないと、後で設計をやり直す羽目になる。
この記事では、VPCピアリングとAWS Transit Gatewayの仕組みと使い分けを解説し、マルチVPC・マルチアカウント環境で崩れない設計パターンを具体的に示す。CIDR設計の落とし穴、ルートテーブルの伝播漏れ、マルチアカウントでのRAM共有まで、現場で必要な知識を網羅する。
この記事のポイント
・VPCピアリングは2VPC間の1対1接続で推移的ルーティングが効かない
・Transit GatewayはハブになりVPC数が増えても接続数がO(n)で収まる
・3VPC以上またはマルチアカウント運用はTransit Gateway一択
・CIDR設計とルートテーブルの伝播ルールが設計の核心
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
VPCピアリングとTransit Gatewayの根本的な違い
まず「どちらも別VPCを繋げるサービス」という点は同じだが、アーキテクチャの思想がまったく違う。VPCピアリングは1対1のプライベート接続だ。VPC-AとVPC-Bを繋ぎ、さらにVPC-BとVPC-Cを繋いでも、VPC-AからVPC-Cへの通信は届かない。これを「推移的ルーティングが効かない」と表現する。VPC-Bが中間にあっても、AWSの設計上ピアリング経由でトラフィックを中継することはできない。VPC-BにEC2を立てて明示的にパケット転送する構成なら可能だが、それは現実的な解決策ではない。
Transit Gateway（TGW）はAWSが提供するクラウドルーターだ。TGWをハブにしてVPCをスポークとして接続する。VPC-A、VPC-B、VPC-Cのすべてがハブに繋がるため、相互通信が可能になる。VPCが10個に増えても、各VPCはTGW1箇所にアタッチするだけで済む。
なお、どちらのサービスもトラフィックはAWSのプライベートネットワーク内を流れる。インターネット経由ではないため、暗号化なしでも通信は外部に露出しない。
接続数の増え方が決定的に違う。
| VPC数 | VPCピアリングに必要な接続数 | Transit Gatewayに必要な接続数 |
|---|---|---|
| 2 | 1 | 2（VPC×TGW間） |
| 3 | 3 | 3 |
| 5 | 10 | 5 |
| 10 | 45 | 10 |
VPCピアリングを選ぶべき場面
VPCピアリングが適しているのは、接続先が固定かつ少数の場合だ。具体的には次のような場面になる。・接続するVPCが永続的に2つだけ（例: 本番とステージング）
・接続元と接続先が同一AWSアカウント内に収まる
・コストを最小化したい（TGWよりピアリングの方がデータ転送料が安い）
VPCピアリングはTGWに比べてシンプルで、追加の管理対象（ルーターリソース）が増えない。2VPCの固定接続なら素直にピアリングを選ぶ方がいい。ただし、将来的に第3のVPCが追加される予定があるなら、最初からTGWを選んでおく方が後戻りコストを抑えられる。
1. VPCピアリングの設定要件
ピアリングを設定する前に必ずCIDRの重複をチェックする。# ピアリングする2つのVPCのCIDRを確認する # CIDR重複はピアリング作成後も通信できない根本原因になる aws ec2 describe-vpcs --query 'Vpcs[*].[VpcId,CidrBlock]' --output table
ピアリング作成後、両側のルートテーブルに相手VPCへのルートを手動で追加する必要がある。これを忘れるとpingが届かない。ルートを片方だけ設定するミスが現場では多い。
もう1つ見落としやすいのがDNS解決の設定だ。ピアリング接続後にプライベートDNS名（例: ip-10-0-0-100.ap-northeast-1.compute.internal）を相手VPCから解決したい場合、ピアリング接続の「DNS解決を有効にする」オプションをリクエスター側・アクセプター側の両方でONにする必要がある。
# ピアリング接続のDNS解決を有効にする（リクエスター側） aws ec2 modify-vpc-peering-connection-options --vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true # ピアリング接続のDNS解決を有効にする（アクセプター側） aws ec2 modify-vpc-peering-connection-options --vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true
2. ルートテーブルの設定例（ピアリング）
# VPC-A（10.0.0.0/16）のルートテーブルにVPC-B宛のルートを追加 aws ec2 create-route --route-table-id rtb-aaaaaaaaaa --destination-cidr-block 10.1.0.0/16 --vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx # VPC-B（10.1.0.0/16）のルートテーブルにVPC-A宛のルートを追加 aws ec2 create-route --route-table-id rtb-bbbbbbbbbb --destination-cidr-block 10.0.0.0/16 --vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx
Terraformで管理することを強く推奨する。手動でルートを追加するとレビューもなく変更されてしまい、あとで設定が散乱する原因になる。Transit Gatewayを選ぶべき場面
次の条件が1つでも当てはまれば、Transit Gatewayの採用を検討すべきだ。・3つ以上のVPCを相互に接続したい
・マルチアカウント構成（AWS Organizations使用）でVPCを共有したい
・オンプレミスとのVPN接続もTGW経由で一元管理したい
・将来的にVPCが増える可能性がある
TGWは一見コストが高く見えるが、VPCが3つを超えると管理コストを含めたトータルコストではTGWの方が安くなる場合が多い。
1. Transit Gatewayの基本構成
TGWの設計には3つのコンポーネントがある。・Transit Gateway本体：ハブになるリソース。リージョンごとに作成する
・TGWアタッチメント：各VPCとTGWを繋ぐ接続単位
・TGWルートテーブル：どのアタッチメントへトラフィックを転送するかを制御
デフォルトでは「デフォルトTGWルートテーブル」が作成され、全アタッチメントへのルートが自動伝播する（DefaultRouteTablePropagation=enable）。これが便利な反面、本番・開発・ステージングを同じTGWに繋ぐ場合は意図しない通信経路ができてしまう。
TGWアタッチメントを作成する際は、VPC内に専用のTGWサブネットを各AZに用意することをAWSは推奨している。アタッチメント専用のサブネットに独自のルートテーブルを割り当てることで、TGW経由トラフィックのルーティング管理が明確になる。各アタッチメント用サブネットは/28（16アドレス）が最小サイズで、通常はそれで十分だ。
2. アタッチメント作成とCIDR設計のポイント
# TGWにVPCをアタッチする aws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id tgw-xxxxxxxxxxxxxxxxx --vpc-id vpc-aaaaaaaaaaaa --subnet-ids subnet-aaaa1111 subnet-aaaa2222 # アタッチメントの状態確認（availableになるまで待つ） aws ec2 describe-transit-gateway-vpc-attachments --filters "Name=transit-gateway-id,Values=tgw-xxxxxxxxxxxxxxxxx" --query 'TransitGatewayVpcAttachments[*].[TransitGatewayAttachmentId,State,VpcId]' --output table
設計推奨のCIDR体系の例を示す。
| 環境 | VPC CIDR | AZ-a サブネット（プライベート） | AZ-c サブネット（プライベート） |
|---|---|---|---|
| 本番（prod） | 10.0.0.0/16 | 10.0.1.0/24 | 10.0.2.0/24 |
| ステージング（stg） | 10.1.0.0/16 | 10.1.1.0/24 | 10.1.2.0/24 |
| 開発（dev） | 10.2.0.0/16 | 10.2.1.0/24 | 10.2.2.0/24 |
| 共有サービス（shared） | 10.3.0.0/16 | 10.3.1.0/24 | 10.3.2.0/24 |
マルチアカウント構成でのTransit Gateway共有
AWS Organizationsを使ったマルチアカウント構成では、TGWを別アカウントから利用できる「Resource Access Manager（RAM）」による共有が重要になる。1. TGWをRAMで共有する手順
# TGWを作成したアカウント（ネットワーキングアカウント）でRAM共有を作成 aws ram create-resource-share --name "TGW-SharedNetwork" --resource-arns arn:aws:ec2:ap-northeast-1:111122223333:transit-gateway/tgw-xxxxxxxxxxxxxxxxx --principals "arn:aws:organizations::111122223333:organization/o-xxxxxxxxxxxx" # 共有されたTGWを参照側アカウントで確認 aws ram get-resource-shares --resource-owner OTHER-ACCOUNTS --query 'resourceShares[*].[name,status]' --output table
2. ルートテーブルで環境間の通信を制御する
デフォルト設定のままでは本番・開発・ステージングが相互に通信できてしまう。これはセキュリティ上好ましくない。解決策はTGWルートテーブルの分離だ。環境ごとに別々のTGWルートテーブルを作成し、アタッチメントをそれぞれのルートテーブルに関連付ける。
・本番ルートテーブル：prod VPC → shared VPCのみ許可
・開発ルートテーブル：dev VPC → shared VPC + stg VPCのみ許可
・共有サービスルートテーブル：全環境からの着信を許可
この設計にすると、本番から開発への直接通信が物理的に遮断できる。SG（セキュリティグループ）だけに頼らず、ルーティングレベルで環境分離するのがAWSのベストプラクティスだ。
Transit Gateway設定でよくあるトラブルと対処法
TGWを初めて設定すると、「ルートが通っているのに通信できない」という問題が起きやすい。原因は大抵次の3点に絞られる。確認コマンドと合わせて解説する。1. TGWルートテーブルへの伝播漏れ
VPCをアタッチしただけではTGWルートテーブルにルートが自動追加されない場合がある。「DefaultRouteTablePropagation」が無効のTGWを使っている場合、アタッチメントを手動でルートテーブルへ関連付ける必要がある。# TGWルートテーブルへのアタッチメント関連付けを確認する aws ec2 get-transit-gateway-route-table-associations --transit-gateway-route-table-id tgw-rtb-xxxxxxxxxxxxxxxxx --query 'Associations[*].[TransitGatewayAttachmentId,State,ResourceId]' --output table # 実行例（出力） # ---------------------------------------------------------- # | tgw-attach-aa | associated | vpc-aaaaaaaaaa | # ---------------------------------------------------------- # ルートの伝播状況を確認する（全アタッチメントが含まれているか） aws ec2 get-transit-gateway-route-table-propagations --transit-gateway-route-table-id tgw-rtb-xxxxxxxxxxxxxxxxx --query 'TransitGatewayRouteTablePropagations[*].[TransitGatewayAttachmentId,State,ResourceId]' --output table
2. VPC側のルートテーブル漏れ
TGW側でルートを設定しても、VPC内のサブネットにTGW経由のルートが追加されていないと通信できない。VPC内の各サブネットに関連付けられたルートテーブルに、宛先CIDRとNextHop=TGWのルートを追加する。# VPCのルートテーブルにTGW経由のルートを追加する # 例: 10.1.0.0/16（ステージングVPC）宛のルートをTGW経由に設定 aws ec2 create-route --route-table-id rtb-aaaaaaaaaa --destination-cidr-block 10.1.0.0/16 --transit-gateway-id tgw-xxxxxxxxxxxxxxxxx # ルートテーブルの設定を確認する aws ec2 describe-route-tables --route-table-ids rtb-aaaaaaaaaa --query 'RouteTables[*].Routes[*].[DestinationCidrBlock,TransitGatewayId,State]' --output table
3. セキュリティグループとNACLの制御
ルートテーブルだけ設定してもSGでインバウンドが拒否されていれば通信は届かない。TGW経由の送信元IPはVPC-AのプライベートIPになるため、宛先EC2のSGに「VPC-A CIDRからのインバウンドを許可」するルールが必要だ。NACL（ネットワークACL）にも注意が必要だ。SGはステートフル（戻り通信が自動許可）だが、NACLはステートレスで戻り通信を明示的に許可する必要がある。NACLでインバウンドだけ許可してアウトバウンドを忘れると、片方向にしか通信できない状態になる。
確認の優先順序は「TGWルートテーブル → VPC側ルートテーブル → NACL → SG」の順で進めると効率がいい。
ネットワーク設計を始めるLinuxエンジニアへ
AWSのVPC設計はLinuxのネットワーク設定（Linux ポート確認の全コマンドやLinux DNS 設定の基本）の知識が直接活きる領域だ。ルートテーブルの概念はLinuxのip routeコマンドと同じ思想で動いている。「AWSのネットワーク設計に入る前に、Linuxのネットワーク基礎を固めたい」という方は、まずLinuxサーバーの基礎から始めることをおすすめする。
VPCピアリング vs Transit Gatewayの選定まとめ
| 判断ポイント | VPCピアリング | Transit Gateway |
|---|---|---|
| VPC数 | 2～3個（固定） | 3個以上 or 今後増える予定 |
| 推移的ルーティング | 不可 | 可能 |
| マルチアカウント | 対応（ただし管理が煩雑） | 対応（RAMで一元共有） |
| オンプレ接続（VPN/DX） | 不可（別途Direct Connect GW等が必要） | TGW経由で統合可能 |
| コスト | 低い（接続数が少ない場合） | 高め（ただしVPC増加後は逆転） |
| 設計の複雑さ | シンプル（ただし接続数が増えると爆発） | 初期設計は複雑・運用は楽 |
| DNS解決（クロスVPC） | 要別途設定（ピアリングオプション有効化） | Route 53 Resolverで統合管理可能 |
AWSの冗長設計については、マルチAZを使ったシステム全体の可用性設計もあわせて理解しておくといい。AWSマルチAZ冗長設計の全体像と組み合わせることで、ネットワーク層とコンピュート層を統合した設計ができるようになる。
本記事のまとめ
・VPCピアリングは推移的ルーティング不可。2～3VPCの固定接続に向く・Transit Gatewayはクラウドルーター。3VPC以上またはマルチアカウントに向く
・VPC数が増えるほどピアリング管理は指数的に複雑化し、TGWが逆転する
・CIDR設計は後から変えられない。最初に/16単位で環境分離して設計する
・TGWルートテーブルの分離で本番/開発/ステージング間の通信をルーティングレベルで制御できる
・マルチアカウントはRAM（Resource Access Manager）でTGWを共有するのがAWSのベストプラクティス
・トラブルシュートの順序は「TGWルートテーブル → VPC側ルートテーブル → NACL → SG」
・ピアリングでもTGWでも、CIDR重複は作り直し以外に解決策がない。設計前に必ず確認する
VPC設計・Transit Gatewayの「型」はLinuxサーバーの基礎から始まります
マルチVPC環境のネットワーク設計を自信を持って進めるには、Linuxのルーティングやネットワーク設定の基礎が土台になります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：AWS Route 53のフェイルオーバールーティングでDNS冗長化する方法｜ヘルスチェックとマルチリージョン設計入門
- 前のページへ：AWS RDSのマルチAZとリードレプリカで可用性を高めるデータベース設計入門
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます