Transit GatewayとVPC Peeringの違い｜東京リージョン料金とCLI構築手順

AWS Transit Gateway（TGW）は、複数のVPCやオンプレミス網を1つのハブに集約してルーティングする中継ルーターです。VPC Peeringと役割が重なりますが、両者の違いは突き詰めると「推移的ルーティングの可否」に集約されます。この記事では、TGWの仕組み、VPC Peeringとの違い（推移性・上限値・MTU）、東京リージョンの単価と月額試算、AWS CLIでの最小構築手順までを、2026年10月時点のAWS公式ドキュメントにもとづいて解説します。

まとめ：Transit GatewayとVPC Peeringの違いと選び分けの結論

Transit Gatewayは多数のVPCやオンプレ網を中央に集約する「ハブ＆スポーク」型、VPC Peeringは少数VPCを直接つなぐ「1対1」型です。最大の判断軸は推移的ルーティングの可否で、Peeringは非対応のため3つ以上のVPCは網の目状に接続を張るしかありません。Transit Gatewayなら各VPCをハブに1本つなぐだけで相互到達できます。

料金は、Transit Gatewayが東京リージョンでアタッチメント0.07ドル毎時とデータ処理0.02ドル/GB、VPC Peeringは時間課金なし・同一AZ内無料・AZ跨ぎ各方向0.01ドル/GBです。費用だけならPeeringが常に安く、TGWの料金は運用を中央に寄せる対価と考えます。VPCが2〜3個ならPeering、4個以上やオンプレ集約が絡むならTransit Gatewayです。

AWS Transit Gatewayとは：VPC間フルメッシュを解くハブ＆スポーク

AWS Transit Gatewayは、VPC・VPN・AWS Direct Connectなどの接続をリージョン単位のハブに集約し、その間のトラフィックを中継するマネージドルーターです。略称はTGWです。IPの到達性ではなくサービス単位でVPCやアカウントを横断する選択肢には、Amazon VPC Latticeがあります。

VPC Peeringでn個のVPCを相互接続するにはn(n−1)/2本の接続が要り、5個なら10本、10個なら45本、20個なら190本と増えます。このフルメッシュを、中央ハブに各VPCを1本ずつ束ねる構成へ置き換えるのがTransit Gatewayです。VPCを追加するときに必要な接続は、追加するVPCから中央のハブへ向かう1本で、この接続を足すだけで全体に届きます。接続方式全体の地図はAWSのネットワーク接続方式まとめで整理しています。

Transit Gatewayの仕組み：アタッチメント・ルートテーブル・伝播の3層構造

Transit Gatewayは「何をつなぐか」「どう経路を持つか」「どう中継するか」の3層で動きます。

TGWアタッチメント5種類の接続先と時間課金の請求先アカウントの違い

アタッチメントは、TGWに接続先を結びつける単位です。VPC、Site-to-Site VPN、Direct Connect Gateway、別のTGWとつなぐPeering、SD-WAN機器を収容するConnectの5種類があります。時間課金の請求先は種類で異なり、VPCアタッチメントはVPC所有アカウント、VPNとConnectはTGW所有者、Direct ConnectはDirect Connect Gateway所有者です（Transit Gateway料金ページ）。

TGWルートテーブルのアソシエーションとルート伝播（propagation）の役割分担

TGWは独自のルートテーブルを持ちます。アタッチメントをどのルートテーブルに従わせるかを決めるのがアソシエーション（経路の参照先）、アタッチメント側のCIDRを自動登録するのがルート伝播（経路の登録元）です。本番VPCと開発VPCを互いに見せたくないなら、ルートテーブルを2枚に分け、共有サービスVPCだけを両方へ伝播させます。

TGW同士のPeeringアタッチメントは伝播に非対応で、静的ルートを書きます。クォータは、1つのTGWの全ルートテーブル合計で既定10,000ルート、ルートテーブル数は既定20です（2026年10月時点）。

ルーティングの流れと推移的ルーティング：VPC A→ハブ→VPC Cの経路

送信元VPCのルートテーブルが宛先CIDRをTGWへ向け、TGWは自身のルートテーブルを見て該当アタッチメントへ転送します。VPC AとVPC Cがどちらも同じTGWにつながっていれば、A→ハブ→Cの通信が成立します。これが推移的ルーティングです。TerraformでのTGW構築とRAM共有はTransit Gatewayクロスアカウント構築手順｜TerraformとRAM共有で扱っています。

Transit GatewayとVPC Peering比較：推移性・上限値・MTU・料金

接続トポロジ、推移性、上限値とMTU、セキュリティグループ参照の順に比べ、最後に一覧表にまとめます。

接続トポロジの違い：1対1メッシュとハブ＆スポークで変わる接続本数

VPC Peeringは2つのVPCを直結する1対1の接続で、全VPCをつなぐとメッシュになります。接続1本ごとに両側のルートテーブルへ相手のCIDRを書くため、10個のVPCをフルメッシュにすると45本×両側で90箇所の経路設定です。Transit Gatewayなら経路はハブに集まり、伝播で自動登録もできます。

推移的ルーティングの可否：VPC Peeringで3つ目のVPCに届かない理由

VPC Peeringは推移的ルーティングに対応しません。VPC Peeringの公式解説には、AとB、AとCをPeeringしてもBからAを経由してCへは届かず、BとCを直接Peeringする必要があると明記されています。相手VPCのインターネットゲートウェイ、NAT、VPN・Direct Connectを経由する「エッジ間ルーティング」も不可です。

「3つ以上のVPCを相互につなぐ」「共有VPCのNATやVPNを他のVPCにも使わせる」なら、Peeringは選択肢から外れます。2つのVPCを直結するだけならPeeringで足ります。この一点が決定打です。

上限値・帯域・MTUの違い：ピアリング50本とアタッチメント5,000の差

VPC Peeringのクォータは、VPCあたりのアクティブな接続が既定50本・申請で最大125本です。フルメッシュでは各VPCがn−1本を持つため、既定値なら51個で頭打ちです。TGWはアタッチメント既定5,000で、桁が2つ違います。

TGWのVPCアタッチメントはAZあたり各方向最大100Gbps、MTUは8,500バイトです。Peeringは同一リージョンでMTU 9,001バイト、リージョン間は8,500バイトです。公式クォータページは、PeeringからTGWへの移行時はMTU差でパケットが落ちうるため両側のVPCを同時に切り替えるよう注意しています。

セキュリティグループ参照とDNS解決：移行時に変わる設定2点

Peeringは同一リージョンなら相手VPCのセキュリティグループをルールに指定できます。TGWもTGWとアタッチメントの両方で有効にすれば参照できますが、インバウンドルールのみで、TGW Peering越しやPrivateLinkエンドポイントには使えません（VPCアタッチメントの公式解説）。アウトバウンドの参照は移行前にCIDR指定へ書き換えます。

DNSは、PeeringならDNS解決オプションで相手VPCのプライベートDNS名を引けますが、TGW Peeringは非対応のため、リージョン跨ぎの名前解決はRoute 53 Resolverで設計します。Peeringのルート・SG・DNSを書く手順はVPC Peeringの設定手順（CLIとTerraformで作る接続・ルート・DNS）で解説しています。

比較表：VPC PeeringとTransit Gatewayを9つの観点で一覧化

表のうち選択を左右するのは推移的ルーティングとオンプレ集約の2行で、残りは採用後の設計で気にする項目です。

3つの接続の対象比較：VPC Peering・TGW・TGW Peering

同じ「Peering」でも対象が違うため、VPC Peering・Transit Gateway・TGW Peeringの3者を、何と何をつなぐ接続なのかという対象と役割で切り分けます。

Transit Gateway Peeringは、ハブであるTGWを別のTGWへつなぐ仕組みで、リージョンを跨ぐInter-Region Peeringと、同一リージョン内のIntra-Region Peering（2021年12月提供開始）があります。接続対象は別部門や外部パートナーが管理するTGW同士であり、間にブリッジVPCを設けずに直接接続できる仕組みです。経路は静的ルートで通し、リージョン間の通信はVPC Peeringと同じ基盤でAES-256暗号化されます。「transit gateway peering」はVPCではなくTGW同士の話です。

Transit Gateway料金：東京リージョン単価とVPC Peeringの月額比較

東京リージョン（ap-northeast-1）の単価を確定させ、VPC数別の月額をPeeringと並べます。

東京リージョンの単価：アタッチメント0.07ドル毎時とデータ処理0.02ドル/GB

Price List API（AmazonVPCオファー、東京版の公開日2026年9月17日）で確認した東京の単価は、VPC・VPN・Direct Connect・Connect・Peeringの各アタッチメントが0.07ドル毎時、VPC・VPN・Direct Connectアタッチメントからのデータ処理が0.02ドル/GBです。公式料金ページの例示はUS East（Ohio）の0.05ドル毎時なので、東京は時間単価が4割高くなります。

ピアリングアタッチメント経由で届いたデータにはデータ処理課金がかかりません（リージョン間転送料は別途）。VPC PeeringはVPC料金ページのとおり、AZを跨ぐ転送がIn・Outの両方向で0.01ドル/GBで、同一AZ内は無料です。

VPC数別の月額試算：3・5・10個でVPC Peeringとの差額を比較

1か月730時間、VPC間の転送量を合計1,000GB（すべてAZ跨ぎ）と置いた試算です。税は含めていません。

TGWのデータ処理とPeeringのAZ跨ぎ往復はどちらも0.02ドル/GBなので、差はほぼアタッチメントの時間課金（1個あたり月約51ドル）です。TGWを選ぶ理由は費用ではなく、45本の接続を10本に減らせる運用面にあります。

Price List APIで東京リージョンのTGW単価を自分で確認するコマンド

料金ページの表はJavaScriptで描画されるため、スクリプトからは認証不要のPrice List APIで読みます。標準ライブラリだけで動くPythonです。

import json, urllib.request

BASE = "https://pricing.us-east-1.amazonaws.com"
idx = json.load(urllib.request.urlopen(BASE + "/offers/v1.0/aws/AmazonVPC/current/region_index.json"))
url = BASE + idx["regions"]["ap-northeast-1"]["currentVersionUrl"]
offer = json.load(urllib.request.urlopen(url))
print("version:", offer["version"])
for sku, p in offer["products"].items():
    usage = p["attributes"].get("usagetype", "")
    if "TransitGateway" not in usage:
        continue
    for term in offer["terms"]["OnDemand"].get(sku, {}).values():
        for dim in term["priceDimensions"].values():
            print(usage, p["attributes"].get("operation"), dim["pricePerUnit"]["USD"], dim["unit"])

APN1-TransitGateway-Hoursが時間課金、APN1-TransitGateway-Bytesがデータ処理課金です。versionを見積書に添えると、いつ時点の単価かを後から追えます。

AWS CLIでTransit Gatewayを作りVPC2つを接続する最小構築手順

同一アカウント・東京リージョンでVPC AとVPC Bをつなぐ最小手順です。IDは自分の環境の値に置き換えます。オプション名はcreate-transit-gatewayとcreate-transit-gateway-vpc-attachmentのリファレンスで確認しました。

TGW作成とVPCアタッチメント作成：AZごとに1サブネットを指定する

1. 自動アソシエーションと自動伝播を有効にしてTGWを作る
2. 状態がavailableになるのを待つ
3. VPCごとにアタッチメントを作り、使うAZのサブネットを1つずつ渡す

aws ec2 create-transit-gateway \
  --description "hub-tokyo" \
  --options AmazonSideAsn=64512,DefaultRouteTableAssociation=enable,DefaultRouteTablePropagation=enable,DnsSupport=enable,SecurityGroupReferencingSupport=enable \
  --region ap-northeast-1

aws ec2 describe-transit-gateways \
  --transit-gateway-ids tgw-0123456789abcdef0 \
  --query "TransitGateways[0].State"

aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-0123456789abcdef0 \
  --vpc-id vpc-0aaaaaaaaaaaaaaaa \
  --subnet-ids subnet-0a1111111111111a subnet-0c1111111111111c \
  --options DnsSupport=enable,SecurityGroupReferencingSupport=enable

aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-0123456789abcdef0 \
  --vpc-id vpc-0bbbbbbbbbbbbbbbb \
  --subnet-ids subnet-0a2222222222222a subnet-0c2222222222222c \
  --options DnsSupport=enable,SecurityGroupReferencingSupport=enable

アタッチメントを置かないAZのリソースはTGWへ届きません。アタッチメント用には/28程度の専用サブネットを切ると、後でACLやルートを分けやすくなります。CIDRとサブネットの切り方はCIDRの読み方とAWS VPCでのサブネット設計で解説しています。

VPCルートテーブルへの経路追加と、TGW側に伝播した経路の確認

TGW側は自動伝播で経路が入りますが、VPC側は手で書きます。VPC A（10.0.0.0/16）とVPC B（10.1.0.0/16）なら、相手のCIDRをTGWへ向けます。

aws ec2 create-route \
  --route-table-id rtb-0aaaaaaaaaaaaaaaa \
  --destination-cidr-block 10.1.0.0/16 \
  --transit-gateway-id tgw-0123456789abcdef0

aws ec2 create-route \
  --route-table-id rtb-0bbbbbbbbbbbbbbbb \
  --destination-cidr-block 10.0.0.0/16 \
  --transit-gateway-id tgw-0123456789abcdef0

aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-0123456789abcdef0 \
  --filters Name=type,Values=propagated \
  --query "Routes[].{cidr:DestinationCidrBlock,state:State}"

両VPCのCIDRがactiveで並べばTGW側は揃っています。search-transit-gateway-routesは--filtersが必須です。疎通しないときはVPCルートテーブル、セキュリティグループ、ネットワークACLの順に見ます。Peeringなら同じ2VPCは接続の作成・承認とルート追加だけで済み、この手数の差も2〜3VPCならPeeringで足りる理由です。

Direct Connect・Site-to-Site VPNのTGW経由オンプレ集約

専用線ならDirect Connect Gatewayアタッチメント、インターネット経由のIPsecならSite-to-Site VPNアタッチメントをTGWにつなぎ、BGPでオンプレ側ルータと経路を交換します。ハブを1点でオンプレと接続して全VPCへ配れるため、VPCごとにオンプレ回線を張る必要がなくなります。Peeringはエッジ間ルーティング不可なので、この構成は取れません。

TGWのMTUはVPC・Direct Connect間で8,500バイト、VPN経由は1,500バイトです。専用線の仕組みと料金はAWS Direct Connectの仕組みとVPNとの違い、IKE設定とstrongSwanでの接続はSite-to-Site VPNの接続手順で扱っています。

Transit Gateway導入前に確認する制約：CIDR重複・リージョン・クォータ

• CIDRの重複：重なったアドレス範囲は正しくルーティングできません。Peeringは重複するCIDRを1つでも持つVPC同士では接続自体を作れないと公式に明記しています。
• リージョン跨ぎ：1つのTGWはリージョン内を束ねます。別リージョンとは各リージョンのTGWをInter-Region Peeringで結びます。
• クォータ：ピアリングアタッチメントはTGWあたり50、TGWはアカウントあたり5個、1つのVPCに付けられるTGWは5個（変更不可）が既定です。

なかでもCIDR重複は稼働後の再採番の影響が広いため、最初のアドレス設計で避けておきます。

判断：VPC Peeringのままでよい条件とTransit Gatewayへ移る条件

迷ったら「推移性が要るか」「VPCが4個を超えるか」の2問で決めて構いません。

VPC Peeringで足りる条件：VPC3個以下・推移不要・同一AZ転送が多い

VPCが2〜3個で、オンプレ集約も推移的通信も要らないならVPC Peeringです。時間課金がなく同一AZ内は無料なので、同じAZ内で大量に転送するDBレプリケーションのような用途では明確に安くなります。この条件でTGWを入れるのは過剰です。ただし1年以内にVPCが4個を超える計画があるなら、最初からTGWに寄せます。Peeringを足し続けると接続とルート設定が二次関数的に膨らむためです。

Transit Gatewayへ移る条件と、移行で詰まりやすいMTU差とSG参照

VPCが4個以上に増える、VPN/Direct Connectでオンプレと束ねる、共有VPCのNATやVPNを複数VPCで使う、のいずれかならTransit Gatewayです。移行時は、MTU差（9,001→8,500バイト）とアウトバウンドのSG参照の書き換えを切り替え手順に先に組み込みます。

VPC設計からTGWの経路分割、Terraformでのコード化まで含めてAWSのネットワークを組み直す場合は、一創のAWS・Google Cloud・Azureのインフラ構築でもご相談を受けています。

サービス単位の接続の選択肢：PrivateLinkとVPC Lattice

特定のサービスだけを別VPCへ公開したいなら、TGWもPeeringも過剰です。AWS PrivateLinkは提供側NLBの裏のサービスだけをエンドポイントとして見せる方式で、CIDRが重複していても接続できます。HTTPやgRPCのサービス間通信をアカウント横断で束ねるならVPC Latticeも候補です。到達させたい範囲が「ネットワーク全体」か「特定のサービス」かを先に決めると、方式を取り違えません。

よくある質問

Transit GatewayとVPC Peeringの比較で、検索の多い質問に答えます。

TGWとは何の略ですか？

TGWはTransit Gateway（トランジットゲートウェイ）の略称です。AWSの公式ドキュメントやCLIでも使われ、TGWのIDはtgw-、TGWルートテーブルのIDはtgw-rtb-で始まります。複数のVPCやオンプレ網を1つのハブに集約して中継するマネージドルーターを指し、「transit gateway」「トランジットゲートウェイ」「tgw」のどれで検索しても同じサービスです。

VPC PeeringとTransit Gatewayはどちらを使うべきですか？

相互接続するVPCが2〜3個でオンプレ接続も推移的通信も不要なら、時間課金のないVPC Peeringが割安です。VPCが4個以上に増える、VPNやDirect Connectでオンプレを束ねる、ハブ経由の到達性が要る、のいずれかに当てはまるならTransit Gatewayを選びます。費用だけならPeeringが常に安く、TGWの料金は運用を中央に寄せる対価です。

Transit Gatewayは推移的ルーティングができますか？

できます。各スポークがハブを経由して相互に到達するため、推移的ルーティングが成立します。VPC Peeringは非対応で、AとB、AとCをPeeringしてもBからAを経由してCへは届きません。相手VPCのNATやVPNを経由する通信もできないため、この差がTransit Gatewayを選ぶ主な理由になります。

Transit Gatewayの料金はいくらですか？

アタッチメントの時間課金とデータ処理課金の2要素です。2026年10月時点の東京リージョンは、アタッチメント1個あたり0.07ドル毎時（730時間で月約51ドル）、データ処理が0.02ドル/GBです。VPCを5個つなぐと時間課金だけで月約256ドルになります。改定がありうるため、見積もり時は公式料金ページかPrice List APIで確認してください。

別リージョンのVPCと接続できますか？

できます。接続の構成は、それぞれのリージョンにTGWを配置し、両方のTGWをInter-Region Peeringで相互につなぐ形です。同一リージョン内で別々のTGWをつなぐIntra-Region Peeringもあり、どちらも静的ルートで経路を通します。VPCが2つだけなら、リージョン間VPC Peering（MTU 8,500バイト）で直接つなぐ方法もあります。

関連記事

• VPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較・損益分岐点：VPCからAWSサービスへの経路と料金の比較
• AWS NATゲートウェイとは？インターネットゲートウェイとの違い・料金・配置の基本：TGWで集約することが多いNATの基本
• AWSのネットワーク接続方式まとめ｜VPC内・VPC間・オンプレ・インターネットの選び分け：接続方式全体の中でのTGWとPeeringの位置づけ
• ブロックパブリックアクセス（VPC BPA）の設定手順とモード選択：VPCのインターネット経路を一括で遮断する設定