AWS Transit Gateway: 2026年における大規模マルチアカウント設計パターン

Q: AZ内でのデータ転送が無料なのだから、VPC Peeringを使えばいいのではないでしょうか？

VPC Peeringはn^2の複雑さの問題を生じさせ、推移ルーティングがありません。データ転送コストは安価ですが、管理オーバーヘッドが大規模では法外に高くなります。TGWをバックボーンとして使用し、Peeringは特定の高帯域幅の「エレファントフロー」の間にのみ使用してください。

Q: TGW環境でCIDRの重複をどのように処理すればよいですか？

TGWは1つのルートテーブル内でCIDRの重複をサポートしていません。スポークVPCでPrivate NAT Gatewayを使用するか、専用のTranslation VPCをNAT機能とともに使用して、アドレスがトランジットコアに入る前にマッピングする必要があります。

Q: TGWはマルチキャストをサポートしていますか？

はい、TGWマルチキャストドメインを介してサポートします。VPCサブネットを関連付け、IGMPを使用してグループを管理します。これはニッチですが、レガシーの金融アプリケーションやブロードキャストアプリケーションにとって不可欠な機能です。

Q: 単一のTGWの最大スループットはどれくらいですか？

各アタッチメントは合計スループットで最大50Gbpsをサポートしますが、個々の5タプルフローは通常10Gbpsに制限されます。高性能アプリケーションは、ピーク帯域幅を達成するために複数のフローを利用する必要があります。

Q: SD-WAN統合にTGW Connectを使用すべきですか？

はい。TGW ConnectはGREトンネルとBGPを使用してSD-WAN統合を簡素化します。これにより、仮想アプライアンスを接続する際の標準IPsec VPNに関連するオーバーヘッドとMTUの問題を回避できます。

Q: Appliance Modeはフロー非対称性の問題をどのように解決しますか？

Appliance Modeは、TGWがフロー対称性を維持し、戻りトラフィックをソーストラフィックと同じAZおよびENI経由で強制的にルーティングすることを保証します。これにより、Inspection VPC内のステートフルファイアウォールがパケットをドロップすることを防ぎます。

2026年においても、AWS Transit Gateway (TGW) はエンタープライズグレードのマルチアカウントアーキテクチャにとって議論の余地のないバックボーンであり続けます。しかし、「ハブアンドスポーク」という言葉は、ピアリングの疲労、クォータの制約、そして集中的な検査の絶対的な必要性を考慮に入れないエンジニアにとっては、もはや通用しません。50を超えるアカウントにまたがるスプロール化した環境で、いまだに個々のVPCピアリング接続や手動でのルート伝播を管理しているようでは、アーキテクチャを構築しているのではなく、ルーティングループや「Quota Exceeded」例外が発生してプロダクションスタックがダウンするのを待っているに過ぎません。現代のTGW設計は、East-West間のセキュリティギャップを解決するために、Resource Access Manager (RAM) の自動化、分離されたルーティングドメイン、およびGateway Load Balancer (GWLB) の統合に徹底的に焦点を当てる必要があります。

2026年のマルチアカウントの現実: スケールするか、破綻するか

単一のモノリシックなAWSアカウントが主流だった時代はとうに過ぎ去りました。現在、組織はAWS Organizationsを介して管理される数百のアカウント全体で500を超えるVPCに到達しています。この規模では、TGWは単なるルータではなく、抽象化レイヤーとして機能します。AWS Resource Access Manager (RAM) を使用することで、単一のTGW（専用のネットワークサービス/ハブアカウントに存在する）を組織全体で共有できます。これにより、開発者がローカル要件を満たしつつも企業のエグレスポリシーに違反するような、孤立したVPCを勝手に立ち上げてしまう「シャドーネットワーキング」を防ぎます。

ただし、1,000を超えるVPCへのスケーリングは、特定の制約をもたらします。TGWは理論上、リージョンあたり5,000のAttachmentをサポートしますが、実際のボトルネックはTGWルートテーブルの制限（現在TGWあたり20個）とTGWルートテーブルあたりのルート数（10,000個）です。2026年レベルの規模に対応するには、フラットルーティングから脱却し、複数のルートテーブルを使用してVRFのようなアプローチをTGW内で採用し、アプリケーション層（例：Prod、Dev、Shared Services、Inspection）に合わせて調整する必要があります。

Resource Access Manager (RAM) と自動化パイプライン

コンソールを介したTGWの手動共有は、致命的な過ちです。プロフェッショナルなCI/CD環境では、ハブアカウントがTGWリソースを組織単位（OU）全体と自動的に共有する必要があります。Control TowerまたはカスタムのAccount Factory経由で新しいアカウントがプロビジョニングされると、そのアカウントは自動的に「TGW Attachment Request」を受け取るはずです。

# Terraform snippet for RAM sharing
resource "aws_ram_resource_share" "tgw_share" {
  name                      = "central-tgw-share"
  allow_external_principals = false
}

resource "aws_ram_principal_association" "org_association" {
  principal          = data.aws_organizations_organization.current.arn
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}

resource "aws_ram_resource_association" "tgw_association" {
  resource_arn       = aws_ec2_transit_gateway.main.arn
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}

重要なヒント：TGWのdefault_route_table_associationとdefault_route_table_propagationは常に無効にしてください。これらを有効にしたままにすると、新しいVPCアタッチメントがローカルルートを自動的にグローバルテーブルにダンプし、他のすべてのVPCへのルートを受け取ることになります。これは、影響範囲が非常に広い悪夢です。明示的でインテントベースのルーティングが必要です。

Inspection VPC: エッジでのGWLBの実装

East-Westトラフィック（VPC間）およびNorth-Southトラフィック（VPC-インターネット間）に対するDeep Packet Inspection (DPI) は不可欠です。2026年のゴールドスタンダードは、Gateway Load Balancer (GWLB) とFortiGateまたはPalo Alto VM-Seriesアプライアンスのフリートを利用したInspection VPCパターンです。TGWを使用することで、任意のスポークVPCからのトラフィックを、宛先に到達する前にInspection VPCに誘導できます。

これはAppliance Modeを介して実現されます。Inspection VPCへのTGWアタッチメントでappliance_mode_supportが有効になっていることを確認してください。これが有効になっていないと、TGWはフロー対称性を維持せず、リクエストをあるAZのファイアウォール経由で送信し、レスポンスを別のAZ経由で送信するため、ステートフルファイアウォールがパケットをドロップしてしまいます。ファイアウォール統合の詳細については、FortiGate GWLB設計パターンのガイドをご覧ください。

トラフィックエンジニアリング: Prod、Dev、Shared Servicesの分離

影響範囲を制限するには、TGWルートテーブルをCiscoの世界におけるVRFのように扱います。最低限、以下のルートテーブルを設けるべきです。

Prod_RT: 本番VPCのルートを含みます。Inspection VPCには伝播しますが、Dev_RTには伝播しません。
Dev_RT: 開発環境のルートを含みます。TGWレイヤーでProdから分離されます。
Inspection_RT: すべてのスクラビングが必要なトラフィックの「着陸」テーブルです。このテーブルには、Inspection VPC内のGWLBエンドポイントを指すデフォルトルート（0.0.0.0/0）があります。
Edge_RT: Direct Connect (DX) またはVPNアタッチメント用です。

この設計のコストへの影響は予測可能ですが、かなり大きいです。各TGWアタッチメントは、リージョンあたり約36.50ドル/月（0.05ドル/時間に基づく）と、処理されたデータ1GBあたり0.02ドルがかかります。1,000VPC環境では、アタッチメント料金だけで月額36,500ドルになります。1PBのデータをTGW経由で転送する場合、さらに20,000ドルが追加されます。高スループット、低レイテンシーのニーズには、特定の高頻度通信ペア向けにVPC Peeringを検討し、TGWを管理プレーンとして維持してください。

影響範囲の軽減: ルートフィルタリングとブラックホーリング

TGWルートテーブルにおける1つの誤った設定ルートが、企業全体へのランサムウェアのラテラルムーブメントを助長する可能性があります。ブラックホールルートを戦略的に使用してください。特定のCIDR範囲がTGW経由で決して到達してはならない場合（例：独自のDXを持つオンプレミスのレガシー管理サブネット）、スポークルートテーブルで明示的にブラックホールします。

さらに、Service Control Policies (SCP) を実装して、開発者がTGWをバイパスするためにローカルVPCのルートテーブルを変更することを防ぎます。ローカルVPCルートテーブルは、地域トラフィックを検査するために0.0.0.0/0または特定のCIDRをTGWインターフェースに向けている必要があります。開発者がこれを直接インターネットゲートウェイ（IGW）に変更した場合、彼らはセキュリティスタックをバイパスしたことになります。アカウントが明示的にホワイトリストに登録されていない限り、ゲートウェイIDがIGWである所のec2:CreateRouteおよびec2:DeleteRouteを拒否するようにSCPを使用してください。

Direct Connect Gateway (DXGW) 統合

オンプレミスデータセンターをマルチアカウントTGW環境に接続するには、Direct ConnectにTransit VIFが必要です。これにはPrivate VIFを使用しないでください。これらはスケールせず、TGWでは機能しません。Transit VIFはDirect Connect Gateway (DXGW) で終端され、その後TGWに関連付けられます。これにより、最大3つのTGW（異なるリージョンにある可能性もあります）が同じDX接続を共有できます。

2026年には、より多くの企業が100Gbpsの専用接続を選択しています。この帯域幅では、TGWのフローあたりの制限（VPCアタッチメントのフローあたり約10Gbps）がボトルネックになります。より高速な速度を達成するには、複数のフローを使用するか、フットプリントが本当に10以上のリージョンにまたがる真のグローバルである場合は、TGWが手動で構築する必要があるリージョン間ピアリングを自動化するAWS Cloud WANを検討してください。

1000 VPCを超えるスケーリング: TGW Peering vs. Cloud WAN

単一のTGWの物理的または論理的な限界を超えた場合、あるいは東京とUS-East-1間のレイテンシー要件がクリティカルになった場合、TGW PeeringとAWS Cloud WANのどちらを選択するかを決定する必要があります。TGW Peeringは静的で手動のプロセスです。ピアリングアタッチメントを作成し、両側のルートテーブルを手動で更新します。これは面倒で「ルートの腐敗」を起こしやすいです。

AWS Cloud WANは、Network Function ManagerとCore Network Policy (JSONドキュメント) を使用して、セグメント（ProdやDevなど）がグローバルにどのように相互作用するかを定義します。Fortune 100企業レベルで運用している場合、Cloud WANが2026年の標準です。しかし、ほとんどの企業にとっては、リージョナルTGWハブと2〜3のセカンダリリージョン向けのTGW Peeringの方が、コスト効率が高く、標準のReachability Analyzerツールを使用してトラブルシューティングが容易です。

結論: TechLeagueの評価

2026年にTransit Gatewayなしでマルチアカウントネットワークを構築することは、運用上の破綻を招くレシピです。ただし、TGWは厳格なポリシーフレームワークで囲まれていない限り「dumb」なルーターです。配布にはRAM、分離には複数のルートテーブル、集中検査にはGWLBを使用してください。これ以外の方法では、クラウドサイズのコストがかかるだけのフラットなネットワークになってしまいます。ネットワークチームが大規模なセキュリティと接続性の分離で苦労している場合は、techleague.ioのカスタマイズされたインフラストラクチャ監査をご覧ください。

よくある質問

AZ内でのデータ転送が無料なのだから、VPC Peeringを使えばいいのではないでしょうか？

VPC Peeringはn^2の複雑さの問題を生じさせます。データ処理費用は節約できますが、何百ものルートテーブルやセキュリティグループを更新する管理オーバーヘッドと、推移ルーティングの欠如により、大規模での管理は不可能です。TGWを管理プレーンとして使用し、VPC Peeringは特定の大量データ「エレファントフロー」の2つのVPC間でのみ使用してください。

TGW環境でCIDRの重複をどのように処理すればよいですか？

TGWは、同じルートテーブル内の重複するCIDRをネイティブには処理しません。スポークVPCでPrivate NAT Gatewayを使用して、TGWに到達する前に送信元IPを変換するか、またはより多くのNATインスタンスまたはDNAT/SNATを実行するファイアウォールを含む「Translation VPC」を介してマップする別々のTGWルートテーブルを使用する必要があります。

TGWはマルチキャストをサポートしていますか？

はい、TGWはIGMPマルチキャストをサポートしています。TGW上にマルチキャストドメインを作成し、特定のVPCサブネットを関連付ける必要があります。これは、レガシーの金融アプリケーションや、ユニキャストクラウド環境向けに最新化されていない特定のメディアストリーミングプロトコルにとって不可欠です。

単一のTGWの最大スループットはどれくらいですか？

AWSはTGWが「動的に」スケールすると言っていますが、各VPCアタッチメントはバーストスループットで50Gbpsに制限されています。重要なことに、単一のTCPフローは一般的に10Gbpsに制限されます。2つのVPC間で100Gbpsが必要な場合は、トラフィックが多数の異なる5タプルフローに分散されていることを確認する必要があります。

SD-WAN統合にTGW Connectを使用すべきですか？

もちろんです。TGW Connectアタッチメントを使用すると、TGW経由でGREトンネルを実行でき、SD-WAN仮想アプライアンス（Cisco SD-WANやSilver Peakなど）とTGW間のBGPピアリングを直接可能にします。これは、多数のIPsec VPNの必要性を排除し、ルーティングテーブルを大幅に簡素化します。

Appliance Modeはフロー非対称性の問題をどのように解決しますか？

アタッチメントでAppliance Modeが有効になっている場合、TGWはフローの存続期間中、初期リクエストに使用されたのと同じネットワークインターフェース（したがって同じAZ）を戻りトラフィックにも選択することを保証します。これは、ハンドシェイクの片側しか見ない場合にパケットをドロップするステートフルファイアウォールにとって不可欠です。