--- title: "Transit GatewayとVPC Peeringの違い｜東京リージョン料金とCLI構築手順" url: "https://www.issoh.co.jp/tech/details/4263/" published: 2024-11-20 updated: 2026-10-03 categories: ["AWS"] publisher: "株式会社一創" --- # 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](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)は、VPC・VPN・AWS Direct Connectなどの接続をリージョン単位のハブに集約し、その間のトラフィックを中継するマネージドルーターです。略称はTGWです。IPの到達性ではなくサービス単位でVPCやアカウントを横断する選択肢には、[Amazon VPC Lattice](https://www.issoh.co.jp/tech/details/15503/)があります。 VPC Peeringでn個のVPCを相互接続するにはn(n−1)/2本の接続が要り、5個なら10本、10個なら45本、20個なら190本と増えます。このフルメッシュを、中央ハブに各VPCを1本ずつ束ねる構成へ置き換えるのがTransit Gatewayです。VPCを追加するときに必要な接続は、追加するVPCから中央のハブへ向かう1本で、この接続を足すだけで全体に届きます。接続方式全体の地図は[AWSのネットワーク接続方式まとめ](https://www.issoh.co.jp/column/details/2805/)で整理しています。 ## 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料金ページ](https://aws.amazon.com/transit-gateway/pricing/)）。 ### TGWルートテーブルのアソシエーションとルート伝播（propagation）の役割分担 TGWは独自の[ルートテーブル](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html)を持ちます。アタッチメントをどのルートテーブルに従わせるかを決めるのがアソシエーション（経路の参照先）、アタッチメント側のCIDRを自動登録するのがルート伝播（経路の登録元）です。本番VPCと開発VPCを互いに見せたくないなら、ルートテーブルを2枚に分け、共有サービスVPCだけを両方へ伝播させます。 TGW同士のPeeringアタッチメントは伝播に非対応で、静的ルートを書きます。[クォータ](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-quotas.html)は、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共有](https://www.issoh.co.jp/tech/details/17694/)で扱っています。 ## 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の公式解説](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html)には、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のクォータ](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-connection-quotas.html)は、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アタッチメントの公式解説](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)）。アウトバウンドの参照は移行前にCIDR指定へ書き換えます。 DNSは、PeeringならDNS解決オプションで相手VPCのプライベートDNS名を引けますが、TGW Peeringは非対応のため、リージョン跨ぎの名前解決はRoute 53 Resolverで設計します。Peeringのルート・SG・DNSを書く手順は[VPC Peeringの設定手順（CLIとTerraformで作る接続・ルート・DNS）](https://www.issoh.co.jp/tech/details/17877/)で解説しています。 ### 比較表：VPC PeeringとTransit Gatewayを9つの観点で一覧化 | 観点 | VPC Peering | Transit Gateway | | ---------------- | ---------------- | ------------------ | | トポロジ | 1対1メッシュ | ハブ＆スポーク | | 推移的ルーティング | 非対応 | 対応 | | n VPC相互接続の接続数 | n(n−1)/2 | n | | オンプレ接続(VPN/DX)集約 | 不可 | 可 | | 既定の上限 | VPCあたり50本 | TGWあたり5,000 | | MTU | 9,001(同一リージョン) | 8,500(VPN経由は1,500) | | SG参照 | 同一リージョンで可 | インバウンドのみ可 | | 時間課金 | なし | 東京0.07ドル毎時 | | データ課金 | AZ跨ぎ各方向0.01ドル/GB | 処理量0.02ドル/GB | 表のうち選択を左右するのは推移的ルーティングとオンプレ集約の2行で、残りは採用後の設計で気にする項目です。 ## 3つの接続の対象比較：VPC Peering・TGW・TGW Peering 同じ「Peering」でも対象が違うため、VPC Peering・Transit Gateway・TGW Peeringの3者を、何と何をつなぐ接続なのかという対象と役割で切り分けます。 | 名称 | つなぐ対象 | 使う場面 | | ----------------------- | ---------------- | ----------- | | VPC Peering | VPC ↔ VPC | 少数VPCの1対1直結 | | Transit Gateway | 多数のVPC/オンプレ ↔ ハブ | 多数を集約・推移的接続 | | Transit Gateway Peering | TGW ↔ TGW | TGW同士を相互接続 | [Transit Gateway Peering](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html)は、ハブである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です。[公式料金ページ](https://aws.amazon.com/transit-gateway/pricing/)の例示はUS East（Ohio）の0.05ドル毎時なので、東京は時間単価が4割高くなります。 ピアリングアタッチメント経由で届いたデータにはデータ処理課金がかかりません（リージョン間転送料は別途）。VPC Peeringは[VPC料金ページ](https://aws.amazon.com/vpc/pricing/)のとおり、AZを跨ぐ転送がIn・Outの両方向で0.01ドル/GBで、同一AZ内は無料です。 ### VPC数別の月額試算：3・5・10個でVPC Peeringとの差額を比較 1か月730時間、VPC間の転送量を合計1,000GB（すべてAZ跨ぎ）と置いた試算です。税は含めていません。 | VPC数 | Peering接続数 | Peering月額 | TGW時間課金 | TGW月額合計 | | ---- | ---------- | --------- | ------- | ------- | | 3 | 3本 | 約20ドル | 約153ドル | 約173ドル | | 5 | 10本 | 約20ドル | 約256ドル | 約276ドル | | 10 | 45本 | 約20ドル | 約511ドル | 約531ドル | 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](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway.html)と[create-transit-gateway-vpc-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-vpc-attachment.html)のリファレンスで確認しました。 ### 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でのサブネット設計](https://www.issoh.co.jp/tech/details/13322/)で解説しています。 ### 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](https://docs.aws.amazon.com/cli/latest/reference/ec2/search-transit-gateway-routes.html)は`--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との違い](https://www.issoh.co.jp/tech/details/15476/)、IKE設定とstrongSwanでの接続は[Site-to-Site VPNの接続手順](https://www.issoh.co.jp/tech/details/17873/)で扱っています。 ## 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のインフラ構築](https://www.issoh.co.jp/service/system/aws/)でもご相談を受けています。 ### サービス単位の接続の選択肢：PrivateLinkとVPC Lattice 特定のサービスだけを別VPCへ公開したいなら、TGWもPeeringも過剰です。[AWS PrivateLink](https://www.issoh.co.jp/tech/details/15473/)は提供側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ゲートウェイとの料金比較・損益分岐点](https://www.issoh.co.jp/tech/details/2326/)：VPCからAWSサービスへの経路と料金の比較 - [AWS NATゲートウェイとは？インターネットゲートウェイとの違い・料金・配置の基本](https://www.issoh.co.jp/column/details/3105/)：TGWで集約することが多いNATの基本 - [AWSのネットワーク接続方式まとめ｜VPC内・VPC間・オンプレ・インターネットの選び分け](https://www.issoh.co.jp/column/details/2805/)：接続方式全体の中でのTGWとPeeringの位置づけ - [ブロックパブリックアクセス（VPC BPA）の設定手順とモード選択](https://www.issoh.co.jp/tech/details/4396/)：VPCのインターネット経路を一括で遮断する設定 --- 出典: [Transit GatewayとVPC Peeringの違い｜東京リージョン料金とCLI構築手順]()（株式会社一創）