Transit Gateway か共有VPC か — マルチアカウントの接続集約

アカウントが数個のうちはVPC Peeringで足ります。しかし十数、数十と増えた瞬間に接続の組み合わせは爆発し、設計は静かに破綻します。この記事では、Transit Gateway・共有VPC・Peeringの3方式を、スケール性・コスト・統制の3軸で正直に比較し、どの規模でどれを選ぶかの判断材料を整理します。

「アカウントごとにVPCを立てて、必要なところをPeeringでつなぐ」——最初の数アカウントでは、この素朴なやり方がいちばん速く、いちばん安く済みます。問題は、その延長線上に数十アカウントの世界が無いことです。ある日、新しいアカウントを1つ追加するために既存の全VPCへPeeringを張り、全ルートテーブルを書き換える作業に気づいたとき、方式そのものを見直す時期が来ています。

本記事では、マルチアカウントのネットワーク接続を束ねる代表的な3方式——VPC Peering（フルメッシュ）、Transit Gateway（ハブ&スポーク）、共有VPC（RAMで1つのVPCを複数アカウントに共有）——を、スケール性・コスト・統制の観点で比較します。どれが正解という話ではなく、規模と組織の成熟度で選び分けるものだ、という前提で読み進めてください。

01なぜPeeringのフルメッシュは破綻するのか

VPC Peeringは2つのVPC間を1対1でつなぐ機能です。安価（Peeringの接続自体に時間課金はなく、リージョン内の通信ならデータ転送も比較的抑えられます）で低レイテンシ、構成もシンプル。だからこそ2〜3アカウントの環境では第一選択になります。

破綻するのは、全VPCを相互に通信させようとした瞬間です。Peeringは推移的ルーティング（transitive routing）に非対応——A-B、B-Cをつないでも、AはCと通信できません。全ノードを相互接続するには、N個のVPCに対して N×(N-1)/2 本の接続が必要になります。5VPCで10本、10VPCで45本、20VPCなら190本です。

現場のコツ：Peeringの本数だけでなく、各VPCのルートテーブルのエントリ数が効いてきます。1つのVPC追加ごとに、既存の全VPCのルートテーブルへ手を入れる運用は、変更のたびにレビュー対象が全アカウントに広がるということです。IaCで管理していても、この「変更の波及範囲」自体が統制上のリスクになります。

図：3方式の接続構造。Peeringは接続数がノード数の二乗で増え、Transit Gatewayは中央のハブで集約、共有VPCは1つのVPCを複数アカウントで分け合う。

02Transit Gateway：ハブ&スポークでスケールさせる

Transit Gateway（TGW）は、リージョン内のVPC・VPN・Direct Connect Gatewayを1つのハブに集約するルーターです。各VPCはTGWに「アタッチメント」として接続し、TGWのルートテーブルが宛先を振り分けます。推移的ルーティングに対応しているため、N個のVPCをつなぐのに必要なアタッチメントはN本——Peeringのメッシュとは増え方がまったく違います。

スケール面の勝ちは明確ですが、TGWの価値は本数の削減だけではありません。

ルート集約の制御点が1箇所になる：Direct ConnectやSite-to-Site VPNもTGWにぶら下げられるため、オンプレとの接続もハブに集まります。オンプレ接続の選択についてはVPNとDirect Connectの選び方もあわせてご確認ください。
TGWルートテーブルでセグメント分割できる：本番系と検証系を別のTGWルートテーブルに割り当てれば、「検証VPCから本番VPCへは到達させない」といった分離を、中央で宣言的に表現できます。
マルチアカウント配布はRAMで：TGW自体を共有アカウント（ネットワークハブアカウント）に置き、AWS Resource Access Manager（RAM）で各アカウントへ共有します。各アカウントは自分のVPCをアタッチするだけで済みます。

課金は「アタッチメント時間 + データ処理」の2階建て

TGWのコストは大きく2要素です。1つはアタッチメントごとの時間課金（us-east-1では1アタッチメントあたり時間単位、月約36ドルが目安。VPCアタッチメントの課金はVPC所有者側に付きます）。もう1つはTGWを通過したデータの処理料金（GBあたりの従量。リージョンにより異なります）。正確な単価は公式の料金ページで必ず確認してください。

現場のコツ：見落とされがちなのがデータ処理料金の積み上がりです。アタッチメントの時間課金は本数×固定なので読みやすいのですが、TGWを通る通信量が多い環境では処理料金が主役になります。特に「同一AZ内で完結できた通信をわざわざTGW経由にしていないか」を疑ってください。AZをまたぐ通信のデータ転送料金とTGWデータ処理料金が二重に効くパターンは、コスト最適化の定番論点です。気づかないうちに増えるAWSコスト Top10でも触れています。

03共有VPC：1つのVPCを複数アカウントで分け合う

共有VPC（VPC Sharing）は発想が根本的に異なります。アカウントごとにVPCを作らず、1つのVPCのサブネットをRAMで複数のアカウントに共有し、各アカウントがそのサブネットの中に自分のENI（EC2、RDS、ロードバランサ等）を置く方式です。

この方式の強みは、ネットワークの単純さです。全アカウントが同一VPC・同一サブネットに同居するため、アカウント間の通信はそもそもVPC内通信——PeeringもTGWも不要で、アタッチメント課金もTGWデータ処理料金も発生しません。CIDRの設計も1つのVPCに閉じるため、アカウントを追加するたびにIPアドレス空間の調整に頭を悩ませることも減ります。CIDR設計の考え方はオンプレ接続と重複CIDRの現実解で詳しく扱っています。

ただし「分離が弱い」というトレードオフ

共有VPCの弱点は、責任分界の設計にあります。役割は明確に分かれています。

VPCの所有者（オーナーアカウント）だけがVPC構成を変更できる：ルートテーブル、Internet Gateway、NAT Gateway、VPC本体の属性は、参加アカウント（パーティシパント）からは変更できません。参加アカウントは共有されたサブネットにリソースを配置できるだけです。
参加アカウントは共有されたセキュリティグループを変更できない：参加アカウントは自分でセキュリティグループを作成・利用できますが、オーナーが共有したセキュリティグループのルールを追加・削除・変更することはできません。
NAT Gateway等の共有リソースの費用配賦：オーナーのVPCにNAT Gatewayを1つ置いて全アカウントで使う構成は効率的ですが、費用がオーナーに集中します。誰の通信でいくらかかったかの内訳は自明ではありません。NAT Gatewayのコスト設計もご参照ください。

つまり共有VPCは「ネットワークは中央集権、アプリは各アカウント」というモデルです。爆発半径（blast radius）の観点では、VPC単位の境界を複数アカウントで共有してしまうため、TGW+アカウント別VPCの構成に比べてアカウント間の分離が弱くなります。強い分離を組織のガードレールとして敷いている場合は、この点が効いてきます。統制の設計はマルチアカウント統制やOrganizations と SCPとセットで考えてください。

043方式の使い分け

実務での目安を整理します。数値はあくまで判断の起点で、組織の統制要件が優先します。

図：3方式の比較マトリクス。スケール性はTGW、接続コストの低さは共有VPC、境界の明快さはアカウント別VPC＋TGWが優位。組織の統制要件で重み付けが変わる。

2〜3アカウント、当面増えない：Peeringで十分。過剰にTGWを入れると固定費だけ増えます。
数十アカウント、部門・システムごとに分離したい：TGWがハブとして本命。オンプレ接続もハブに集約でき、TGWルートテーブルで本番/検証のセグメント分離も表現できます。
同一チームが管理する、密結合な複数アカウント群：共有VPCが刺さります。ネットワーク運用を1アカウントに集約でき、接続課金もかかりません。ただしアカウント間の分離は弱いことを承知の上で。

現場のコツ：実際の大規模環境では併用が普通です。「TGWを全社の背骨にしつつ、特定の密結合なワークロード群だけ共有VPCで束ねる」「オンプレ接続はTGWに集約し、アカウント内はPeeringやPrivateLinkで最短経路を作る」といった組み合わせです。1方式に統一しようと無理をせず、境界の単位（=どこで分離を効かせたいか）から逆算して選ぶのが実務的です。

05統制・コストとの関係で見る

接続方式の選択は、ネットワーク単体の問題ではありません。EMWがこの判断を統制とセットで考えることを勧める理由は3つあります。

ネットワークハブアカウントは「統制の核」になる：TGWや共有VPCのオーナーアカウントは、全社の通信が集まる場所です。ここのIAM・変更管理を緩くすると、全社の到達性を握られます。最小権限の設計はIAM設計の現実解を、アカウント設計の土台はアカウント初期設定を参照してください。
コストの可視化を最初から仕込む：TGWのデータ処理料金は「誰の通信か」が見えにくいコストです。アタッチメントやフローにコスト配分タグを付け、Cost Explorerで内訳を追える状態を初期構築時に作っておくと、後から効きます。円安下でのコスト管理の観点は円安時代のAWSコスト管理もあわせてどうぞ。
設計ガイドラインに明文化する：「新規アカウントの接続はTGWアタッチメント経由に統一する」といったルールを設計ガイドラインに落としておくと、アカウントが増えても接続方式のばらつきを防げます。ばらついた瞬間に、Peering・TGW・共有VPCが混在した迷宮ができあがります。

移行プロジェクトの中でこの判断を下す場合は、移行の全体フローのどの段階でネットワーク方式を固定するかも重要です。CIDR設計とアカウント設計が終わる前に接続方式だけ先に決めると、後で手戻りが出ます。

—まとめ

マルチアカウントの接続集約は、規模と統制要件で選び分けるものです。2〜3アカウントならPeeringのシンプルさが最適、数十アカウントで分離を効かせたいならTransit Gatewayのハブ&スポークが本命、同一チームが密結合なアカウント群を束ねるなら共有VPCが刺さります。

要点を再掲します。

Peeringは安価だが推移的ルーティング非対応。接続数がノード数の二乗で増え、数十アカウントでは破綻する。
Transit Gatewayはハブ&スポークでスケールし、オンプレ接続も集約できる。課金はアタッチメント時間＋データ処理の従量で、通信量が多いと処理料金が主役になる。
共有VPCは接続課金なしでネットワークを単純化できるが、VPC構成の変更権限はオーナーに集中し、アカウント間の分離は弱い。

正解は1つではなく、実際の大規模環境では併用が普通です。「どこで分離を効かせたいか」という境界の設計から逆算して選ぶこと、そしてネットワークハブアカウントの統制とコスト可視化を最初から仕込むこと——この2点が、後から効いてくる実務のポイントです。

数十アカウント規模の接続集約は、コスト・統制・運用のトレードオフを現場で見極める必要があります。手を動かせるコンサルとしての設計・移行支援は、EMWの実務経験が活きる領域です。まずはお問い合わせからご相談ください。

相談する

← ブログ一覧へ戻る

Transit Gateway か 共有VPC か — マルチアカウントの接続集約