Transit Gateway の新機能「ポリシーベースルーティング」の使い時を考えてみた

本記事は「2026 Japan AWS Jr. Champions 真夏のQiitaリレー」の8日目の記事となります。
過去の投稿（リンク集）は以下からご覧ください。

私は2日目ぶりの2回目の投稿になります。前回の記事もぜひご覧ください！

はじめに

2026年7月30日、AWS Transit Gateway（TGW）のポリシーベースルーティング (PBR) が一般提供開始されました。宛先IPアドレスだけでなく、送信元IP・ポート・プロトコルを組み合わせて参照するルートテーブルを決められるようになった機能です。

本記事では、PBRの概要を整理するとともに、どのようなユースケースで活用できるのかを考えていきます。

新機能の概要

PBRは、パケットの属性を見て「どのルートテーブルを使うか」を切り替えることができる機能です。
これまではルートテーブルに「この宛先はこのアタッチメントへ」とだけ書いておき、届いたパケットの宛先で引くシンプルな仕組みのみ可能でしたが、ポリシーテーブルを利用することで、送信元CIDR・宛先CIDR・送信元ポート・宛先ポート・プロトコルを組み合わせて転送先を決めることができるようになりました。

ポリシーテーブルの中身は順序付きのルールの集合で、それぞれのルールが「どんなパケットにマッチするか」と「マッチしたらどのルートテーブルを使うか」の組み合わせになっています。作ったポリシーテーブルをアタッチメントに関連付けると、そのアタッチメントに届いた通信がルールで振り分けられるようになります。

ポリシーテーブルの仕組み

マッチ条件に使えるのは、送信元CIDR・宛先CIDR・送信元ポート・宛先ポート・プロトコルの5つです。すべて任意項目で、省略すると * (Any) 扱いになります。

ポート指定が有効なのはTCPとUDPだけで、ICMPv4やGREではポートは自動的にAnyになります。

ルールはルール番号の昇順に評価され、最初にマッチしたルールが適用されて評価は終了します。ロンゲストマッチではないため、具体的なルールを小さい番号に置く必要があります。どのルールにもマッチしなかったパケットは破棄されます。（暗黙のdeny）

また、1つのアタッチメントに関連付けられるのは、ポリシーテーブルかルートテーブルのどちらか一方だけです。既にルートテーブルが関連付けられているアタッチメントにポリシーテーブルを関連付けようとするとリクエストが失敗するので、先に既存の関連付けを解除する必要があります。

PBRが不要なケース

まずはPBRの利用には適していない場合を整理してみます。

宛先IPだけで経路を分けられる場合

従来のTGWルートテーブルで事足りるので、PBRは必要ないです。（それはそう）

目的が通信の遮断である場合

どのルールにもマッチしないパケットは破棄される、暗黙のdenyの挙動のため、通信の遮断も実現できるかと思います。
ただし、通信の遮断そのものが目的であれば、PBRではなくセキュリティグループやネットワークACL、Network Firewallなど、通信制御を目的とした仕組みを利用する方が適切です。
意図を持った遮断は遮断のための機能に書き、PBRによる遮断はあくまで設定漏れを検知するための挙動として捉えるのがいいと思います。

Cloud WANピアリングアタッチメント

Transit GatewayとCloud WANのピアリングアタッチメントでは、カスタマーエントリによるPBRがサポートされていません。このアタッチメント上のトラフィックは、システム管理エントリだけで制御されます。

ポリシーテーブルには、自分で書くカスタマー管理エントリと、AWSが自動で作成するシステム管理エントリの2つがあります。Cloud WANのセグメント分離のような機能を使うと後者が自動的に現れます。
ただ、他の接続タイプで使用するために、同じポリシーテーブルに顧客エントリを追加することは可能です。

PBRが活躍するケース

続いて、この新機能を採用したい状況を考えてみます。

同じ宛先でも、送信元CIDRによって経路を変えたいとき

同じVPCからの通信であっても、送信元CIDRごとに異なる経路へ振り分けたいケースです。

例えば、業務VPC 10.0.0.0/16 から共有サービスVPC 10.100.0.0/16 にアクセスする構成で、監査対象のデータを扱うサブネット 10.0.16.0/20 からの通信だけは検査を通したい、それ以外は直接届けたい、とします。宛先が同じなので、従来の宛先ベースのルートテーブルではこの2つを区別できないため、VPCを分割してアタッチメント単位でルートテーブルを分ける必要がありました。

ですが、PBRを利用すれば、1つのアタッチメントに来た通信を送信元CIDRで振り分けられます。VPCを分割せずに、サブネット単位で参照先ルートテーブルを変更することが可能になります。

ポートやプロトコルで経路を分けたいとき

PBRを利用すれば、送信元・宛先が同じでも、ポートやプロトコルが異なる場合に経路を分けることも可能です。

検査を通すかどうかで分ける

例えば下図のように、検査用VPCをTGWに接続し、VPC間通信をまとめて検査する構成を考えます。
TGWのルートテーブルで対象の通信を検査VPCへ向けることで、Network Firewallやサードパーティ製Firewallを経由させ、一か所で通信を検査できます。
設計はシンプルですが、対象となる通信をすべて検査VPCへ集約するため、通信量が増えるほどFirewallのデータ処理料金や、必要となる処理性能も大きくなります。

ですが実際には、バックアップ転送やログ集約のような、大容量だけれど検査の必要性が低い通信も中にはあると思います。PBRを使えば、こうした通信の条件だけを書いて直接送信できます。

ルール番号	送信元CIDR	宛先CIDR	プロトコル	送信元ポート	宛先ポート	ターゲットルートテーブル
100	10.0.0.0/16	10.100.0.0/16	TCP	All	873	tgw-rtb-direct
900	0.0.0.0/0	0.0.0.0/0	All	All	All	tgw-rtb-inspection

どの回線から出すかで分ける

例えば、Direct Connect（DX）とSite-to-Site VPNを併用している環境で、同じオンプレミス拠点宛の通信を、通信の種類によって異なる回線へ振り分けたいケースです。

DXとSite-to-Site VPNを併用する代表的な構成の一つが、DXをプライマリ、VPNをバックアップとする構成です。
DXは専用線による安定した通信が可能ですが、単一のDX接続だけでは、回線や接続機器などの障害によってオンプレミスとの接続が失われる可能性があります。そのため、より低コストなバックアップ経路としてSite-to-Site VPNを組み合わせる構成があります。

TGWにDXとSite-to-Site VPNの両方から同じオンプレミスCIDRが伝播されている場合、通常はDirect Connect Gatewayから伝播されたルートが優先されます。そのため、平常時の通信はDXを利用し、DX側の経路が利用できなくなった場合にVPNへ切り替える、という構成になります。

例えばAWSからオンプレミスへ大容量のバックアップデータを転送するケースがある場合、DXの帯域には上限があるため、大容量のバックアップ転送と基幹システムの通信が同じDXを利用すると、両者で帯域を共有することになります。

従来のTGWルーティングでは、基本的に宛先IPアドレスをもとに経路が決定されます。同じオンプレミスCIDR宛の通信であれば、ポートやプロトコルを条件として経路を使い分けることはできませんでしたが、PBRを利用すれば、基幹システムの通信はDX側の経路を持つルートテーブルへ、バックアップ転送に使用する通信はVPN側の経路を持つルートテーブルへ振り分けるという構成が可能になります。

大容量通信をVPN側へ逃がすことで、DXの帯域を基幹システムなど優先度の高い通信のために確保する、といった使い方ができます。

ルール番号	送信元CIDR	宛先CIDR	プロトコル	送信元ポート	宛先ポート	ターゲットルートテーブル
100	10.0.0.0/16	192.168.0.0/16	TCP	All	1521	tgw-rtb-dx
200	10.0.0.0/16	192.168.0.0/16	TCP	All	873	tgw-rtb-vpn

ここで1つ注意点があります。Site-to-Site VPNアタッチメントにPBRのポリシーテーブルを関連付けると、TGWからオンプレミスへのBGPルート広告が停止します。
そのため、オンプレ側がBGPでAWSへの経路を学習している場合は、PBR導入前にルーティングへの影響を確認する必要があります。
なお、Direct Connectでは経路広告は継続されます。

おわりに

ポリシーベースルーティング（PBR）についてまとめてみました。
これまで通信経路の制約のためにVPCを分割する必要があったところが、PBRのおかげで必要なくなるケースもあるかと思います。
今後何か構築する際に、このようなケースに直面したら活用してみたいです。

Jr. ChampionsによるQiitaリレーはまだまだ続きます！
明日以降の投稿もお楽しみに！！