Transit Gateway ルーティング完全ガイド
クロスリージョン・クロスアカウントVPC接続の完全なルーティングパスを
「国際空港ハブ」のたとえ話で徹底理解
国際空港ハブで理解するTransit Gateway
あなたが東京から大阪、ニューヨーク、ロンドンへ旅行したいとします。各都市に直行便を飛ばすのは非効率ですよね？
そこで「ハブ空港」を使います。東京はまずハブ空港へ行き、そこから各都市へ乗り継ぎます。
Transit Gatewayはまさにこの「ハブ空港」です。各VPC（都市）を直接つなぐ代わりに、
中央のハブを経由することで、管理がシンプルになります。
そして異なるリージョンのTGWをつなぐ「ピアリング」は、東京の成田空港とロンドンのヒースロー空港の間に
国際線を開設するようなものです。
図: 空港ハブのたとえ話と AWS サービスの対応マップ — 左の空港概念が右のAWSサービスに対応
全体アーキテクチャ図
図1: クロスリージョン・クロスアカウントでの Transit Gateway 接続アーキテクチャ
TGWルーティングの4大要素
空港の発着案内板に相当。アタッチメント間でトラフィックの転送先を定義します。 デフォルトルートテーブルのほか、カスタムルートテーブルを作成して セグメンテーション（分離）が可能です。
チャーター便の手配に相当。管理者が手動で「宛先CIDRブロック → 特定アタッチメント」を定義。 TGWピアリング接続では必須（伝播が使えないため）。
航空会社が自動で路線を登録するイメージ。VPCやVPNアタッチメントのCIDRブロックが TGWルートテーブルへ自動追加されます。 ただしピアリング接続では伝播がサポートされません。
各搭乗ゲートが特定のターミナルに所属するようなもの。各アタッチメントは1つのルートテーブルに 関連付けられ、そのテーブルに基づいてルーティングが行われます。
ルートテーブルの関係性
図2: パケットの経路選択フロー — 各ルートテーブルの検索と転送の順序
完全なルーティングパス（6ステップ）
VPC-A（東京リージョン、10.1.0.0/16）のEC2インスタンスから、VPC-C（大阪リージョン、10.3.0.0/16）のEC2インスタンスへ通信する場合の完全なルーティングパスです。
10.3.0.0/16 → tgw-tokyo-001 のエントリを検索し、TGWへ転送。
💡 ここは手動設定が必要！
10.3.0.0/16 → peering-attachment の静的ルートを検索。
10.3.0.0/16 → vpc-c-attachment のルート（伝播 or 静的）を検索。
10.3.0.0/16 → local）が一致。
VPC内のローカルルーティングでEC2（10.3.1.20）へ配送。
設定が必要なルートエントリ一覧
図3: 全ルートテーブルのエントリと転送フロー — 色分けで手動/自動を一目で判別
Transit Gateway ピアリングの詳細
TGWピアリングは、成田空港（東京TGW）とヒースロー空港（大阪TGW）の間に国際線を開設するようなものです。 国内線の路線（VPCアタッチメントの伝播）は自動で案内板に反映されますが、 国際線は両空港それぞれで手動で案内板に登録する必要があります。 また、片方だけ登録しても意味がなく、往復の両路線を登録しなければ旅行者が帰れなくなります。
異なるAWSリージョン間のTGWを接続可能。同一アカウントでも異なるアカウントでも利用できます。 転送はAWSグローバルネットワーク上で暗号化されます。
ピアリングアタッチメントではルート伝播はサポートされていません。 相手リージョンのCIDRを手動で静的ルートとして追加する必要があります。
両方のTGWルートテーブルに適切なルートを設定する必要があります。 片方向だけではレスポンスパケットが戻れず、通信が失敗します。
TGW-A ↔ TGW-B ↔ TGW-C の構成で、TGW-Aから直接TGW-Cには通信できません。 TGW-A ↔ TGW-C の直接ピアリングが必要です（フルメッシュ）。
実装コード例
TGWピアリング構築とルート設定
# ===== 1. Transit Gateway の作成（東京リージョン） ===== aws ec2 create-transit-gateway \ --description "Tokyo TGW" \ --options AutoAcceptSharedAttachments=enable,\ DefaultRouteTableAssociation=enable,\ DefaultRouteTablePropagation=enable \ --region ap-northeast-1 # ===== 2. VPCアタッチメントの作成 ===== aws ec2 create-transit-gateway-vpc-attachment \ --transit-gateway-id tgw-0abc1234def567890 \ --vpc-id vpc-0aaa1111 \ --subnet-ids subnet-0aaa1111 \ --region ap-northeast-1 # ===== 3. TGWピアリングの作成 ===== aws ec2 create-transit-gateway-peering-attachment \ --transit-gateway-id tgw-0abc1234def567890 \ --peer-transit-gateway-id tgw-0xyz9876abc543210 \ --peer-region ap-northeast-3 \ --region ap-northeast-1 # ===== 4. ピアリングの承認（大阪リージョン側） ===== aws ec2 accept-transit-gateway-peering-attachment \ --transit-gateway-attachment-id tgw-attach-0peer1234 \ --region ap-northeast-3 # ===== 5. 静的ルートの追加（東京TGW → 大阪CIDR） ===== aws ec2 create-transit-gateway-route \ --transit-gateway-route-table-id tgw-rtb-tokyo001 \ --destination-cidr-block 10.3.0.0/16 \ --transit-gateway-attachment-id tgw-attach-0peer1234 \ --region ap-northeast-1 # ===== 6. VPCルートテーブルの更新 ===== aws ec2 create-route \ --route-table-id rtb-vpc-a \ --destination-cidr-block 10.3.0.0/16 \ --transit-gateway-id tgw-0abc1234def567890 \ --region ap-northeast-1
AWSTemplateFormatVersion: '2010-09-09' Description: 'Transit Gateway with Cross-Region Peering' Resources: # Transit Gateway（東京リージョン） TokyoTransitGateway: Type: AWS::EC2::TransitGateway Properties: Description: Tokyo Region TGW AutoAcceptSharedAttachments: enable DefaultRouteTableAssociation: enable DefaultRouteTablePropagation: enable # VPCアタッチメント VpcAAttachment: Type: AWS::EC2::TransitGatewayAttachment Properties: TransitGatewayId: !Ref TokyoTransitGateway VpcId: !Ref VpcA SubnetIds: - !Ref SubnetA # TGW静的ルート（大阪リージョン向け） RouteToOsaka: Type: AWS::EC2::TransitGatewayRoute Properties: TransitGatewayRouteTableId: !Ref TokyoTgwRouteTable DestinationCidrBlock: 10.3.0.0/16 TransitGatewayAttachmentId: !Ref PeeringAttachment # VPCルートテーブルエントリ VpcARouteToOsaka: Type: AWS::EC2::Route Properties: RouteTableId: !Ref VpcARouteTable DestinationCidrBlock: 10.3.0.0/16 TransitGatewayId: !Ref TokyoTransitGateway
# ===== Transit Gateway（東京リージョン） ===== resource "aws_ec2_transit_gateway" "tokyo" { description = "Tokyo Region TGW" auto_accept_shared_attachments = "enable" default_route_table_association = "enable" default_route_table_propagation = "enable" provider = aws.tokyo } # ===== VPCアタッチメント ===== resource "aws_ec2_transit_gateway_vpc_attachment" "vpc_a" { transit_gateway_id = aws_ec2_transit_gateway.tokyo.id vpc_id = aws_vpc.vpc_a.id subnet_ids = [aws_subnet.vpc_a_private.id] provider = aws.tokyo } # ===== TGWピアリング ===== resource "aws_ec2_transit_gateway_peering_attachment" "tokyo_osaka" { transit_gateway_id = aws_ec2_transit_gateway.tokyo.id peer_transit_gateway_id = aws_ec2_transit_gateway.osaka.id peer_region = "ap-northeast-3" provider = aws.tokyo } # ===== 静的ルート（東京→大阪） ===== resource "aws_ec2_transit_gateway_route" "to_osaka" { destination_cidr_block = "10.3.0.0/16" transit_gateway_attachment_id = aws_ec2_transit_gateway_peering_attachment.tokyo_osaka.id transit_gateway_route_table_id = aws_ec2_transit_gateway.tokyo.association_default_route_table_id provider = aws.tokyo } # ===== VPCルートテーブル更新 ===== resource "aws_route" "vpc_a_to_osaka" { route_table_id = aws_route_table.vpc_a.id destination_cidr_block = "10.3.0.0/16" transit_gateway_id = aws_ec2_transit_gateway.tokyo.id provider = aws.tokyo }
ベストプラクティス vs アンチパターン
トラブルシューティング
aws ec2 associate-transit-gateway-route-table で
ピアリングアタッチメントを適切なルートテーブルに関連付ける
accept-transit-gateway-peering-attachment を実行する
試験対策ポイント
② VPCルートテーブルの手動更新 — TGWルートテーブルの伝播とVPCルートテーブルの手動更新を混同させる選択肢が頻出。「VPCルートテーブルには手動設定が必要」が正解。
③ 推移的ルーティングの制限 — TGWピアリングは推移的ルーティングをサポートしません。3リージョン構成の場合、フルメッシュピアリングが必要です。
④ セキュリティグループとNACL — TGWを通過するトラフィックでも、宛先VPCのセキュリティグループとNACLは適用されます。
よくある質問（FAQ）
宛先CIDR → TGW ID のルートを手動で追加する必要があります。
また、セキュリティグループやNACLによるブロックも確認してください。