技術記事 2026/8/13

Transit Gatewayがパケット属性で経路を選べるようになった — ポリシーテーブルのルール順序と暗黙のdenyが設計の要点

2026年7月30日、AWS Transit GatewayのPolicy-Based Routing（PBR）がGAしました。送信元・宛先IP、ポート、プロトコルでトラフィックを分類し転送先ルートテーブルを選ぶ仕組みと、first-match-wins・暗黙のdeny・BGP広報停止といった設計上の制約を公式ドキュメントに沿って整理します。

#AWS Transit Gateway
#ネットワーク設計
#AWS Network Firewall
#マルチアカウント
#セキュリティ

マルチアカウント・マルチVPC環境では、「同じ宛先へ向かう通信でも、送信元や用途によって経路を変えたい」という要件が出てきます。特定のサブネットからの通信だけをファイアウォールへ寄せる、といった要求です。2026年7月30日、AWSは AWS Transit Gateway の Policy-Based Routing（PBR、ポリシーベースルーティング）の一般提供（GA） を発表しました。送信元・宛先のIPアドレス、ポート、プロトコルといったパケット属性でトラフィックを分類し、転送に使うルートテーブルを選べます。本記事では、Transit Gatewayのルーティングが何を基準に動いてきたかを整理したうえで、ポリシーテーブルの評価順序と設計・移行で押さえる制約を公式ドキュメントに沿って解説します。

前提: Transit Gatewayのルーティングは宛先IPだけを見ていた

すでにTransit Gatewayを本番運用している方は、この節は読み飛ばして差し支えありません。

AWS Transit Gateway（以下TGW）は、VPC同士やオンプレミスとの通信を集約するリージョン単位の仮想ルータです。公式ドキュメントによれば、TGWのルーティングはレイヤー3で動作し、宛先IPアドレスにもとづいて次のホップとなるアタッチメント（TGWに接続したVPC・VPN・Direct Connectゲートウェイなどの接続口）へパケットを送ります。

経路の管理にはTGWルートテーブルを使います。**関連付け（association）は「そのアタッチメントがどのルートテーブルで経路を引くか」で、1つのアタッチメントにつき1つだけです。一方の伝播（propagation）**は経路情報を配る先で、複数指定できます。ルートの評価も宛先ベースで、最も具体的な（プレフィックス長の長い）ルートが優先されます。

つまり従来、同じ宛先へ向かう2つの通信を、送信元やポートの違いで別経路に振り分ける手段はありませんでした。分けたい場合は送信元をアタッチメント単位で分割するしかありませんでした。

従来のセキュリティ検査構成と、その粒度の限界

TGWで検査経路を強制する定番構成は、共有サービスVPC（検査VPC）にファイアウォールやアプライアンスを置き、業務VPCのアタッチメントに関連付けたルートテーブルへ 0.0.0.0/0 の静的ルートを引いて検査VPCへ寄せる形です。ステートフルなアプライアンスでは、往復のトラフィックが同じアベイラビリティゾーンに届くよう検査VPC側でアプライアンスモードを有効にします。2026年7月時点では、AWS Network Firewall をTGWに直接ぶら下げるネットワークファンクションアタッチメントもあり、検査VPC自体が不要な選択肢も増えています。

ただし、いずれの構成でも判断材料は宛先IPのままです。「業務VPC全体を検査に通す」か「宛先CIDRで分ける」かの二択になり、送信元サブネットやポート単位で検査の有無を切り替えるには、アプライアンス側のルールに委ねるかアタッチメントを増やす必要がありました。PBRはこの選別をTGW自身に持たせる機能です。

何が変わったか — ポリシーテーブルによる分類

従来方式とPBRの比較図。左は宛先IPだけで転送先を決めるルートテーブル、右はポリシーテーブルが送信元CIDR・ポート・プロトコルで分類し検査用と通常のルートテーブルを選び分けるPBR — 図1: 宛先IPのみのルート探索（従来）と、パケット属性でルートテーブルを選ぶPBR

PBRの設定単位は**ポリシーテーブル（policy table）**です。ポリシーテーブルは順序付きのルールの集合で、各ルールは次の2つを持ちます。

マッチ条件 — 送信元CIDR、宛先CIDR、プロトコル、送信元ポート範囲、宛先ポート範囲。すべて任意項目で、省略したフィールドは Any（*）として扱われます。
ターゲットルートテーブル — 条件に一致したトラフィックの転送に使うTGWルートテーブル。

ポリシーテーブルはアタッチメントに関連付けて使い、そのアタッチメントの標準のルートテーブルを置き換えます。関連付けられるのはポリシーテーブルかルートテーブルのどちらか一方で、両方は指定できません。

評価はルール番号の昇順・最初の一致で確定する

ポリシーテーブルの評価順を示す図。システム管理エントリを先に評価し、次に顧客管理エントリを番号の昇順で評価して最初の一致で確定、一致しなければ暗黙のdenyで破棄される — 図2: システム管理エントリ→顧客管理エントリ（昇順）→暗黙のdeny という評価の流れ

トラフィックがポリシーテーブルを関連付けたアタッチメントに届くと、次の順で評価されます。

システム管理エントリ — AWS Cloud WAN のセグメント分離などのためAWSが自動で作成・維持するエントリ。利用者は変更も削除もできず、ルール番号は * と表示されます。顧客管理エントリより先に評価されます。
顧客管理エントリ — 利用者が定義するルール。ルール番号の昇順に評価され、最初に一致したルールのターゲットルートテーブルが適用されます（first-match-wins）。一致した時点で後続は評価されません。番号は1〜50,000の範囲です。
暗黙のdeny — どのエントリにも一致しなかったトラフィックは破棄されます。

公式ドキュメントには、機微なワークロードのサブネットだけをファイアウォールに寄せる例が載っています。

ルール番号	送信元CIDR	宛先CIDR	プロトコル	ポート	ターゲットルートテーブル
100	10.1.10.0/24	Any	Any	Any	`tgw-rtb-firewall`
200	Any	Any	Any	Any	`tgw-rtb-default`

10.1.10.0/24 からの通信はルール100に一致して検査用ルートテーブルで転送され、それ以外はルール200に落ちて通常のルートテーブルを使います。検査を終えてTGWへ戻ったトラフィックは、検査VPCのアタッチメントに関連付けられたルートテーブル上で、通常どおり宛先ベースで転送されます。

設定はマネジメントコンソール、AWS CLI、AWS SDKから行えます。CLIの場合は create-transit-gateway-policy-table でテーブルを作り、下記のようにエントリを追加したうえで、associate-transit-gateway-policy-table でアタッチメントに関連付けます。

aws ec2 create-transit-gateway-policy-table-entry \
    --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
    --policy-rule-number 100 \
    --policy-rule '{"SourceCidrBlock": "10.1.10.0/24"}' \
    --target-route-table-id tgw-rtb-firewall

PBRはすべてのTGWでデフォルトで有効で、オプトイン操作はありません。提供範囲はTGWが利用できるすべての商用AWSリージョンで、標準のTransit Gateway料金以外の追加料金は発生しません（いずれも2026年7月時点の公式発表）。

実務で使うときの注意点

catch-allルールを置かないと黙って落ちます。 暗黙のdenyがあるため、空のポリシーテーブルを関連付けたアタッチメントは入ってくるパケットをすべて破棄します。空のルートテーブルと同じ挙動です。末尾に「すべてAny」のルールを置くかどうかは、フェイルクローズにするかフェイルオープンにするかの設計判断になります。破棄の発生は CloudWatch の PacketDropCountNoPolicy メトリクスで確認できます。

ルール順序の誤りは検査の素通りとして現れます。 広いルールを小さい番号に置くと、後ろにある具体的なルールが影に入って評価されません。公式は番号を10刻み・100刻みで空けて採番し、狭い条件ほど小さい番号に置くことを推奨しています。移行時は GetTransitGatewayPolicyTableEntries でシステム管理エントリを含む全エントリを取得し、実トラフィックを流す前に順序を確認します。

BGPの経路広報が止まるアタッチメントがあります。 2026年7月時点の制限として、ポリシーテーブルを関連付けたSite-to-Site VPNおよびConnectアタッチメントに対して、TGWは経路を一切広報しなくなります。Direct Connectは広報内容がDirect Connectゲートウェイ関連付けの許可プレフィックスリストで決まるため、関連付けに関わらず継続します。TGWからのBGP広報に依存した設計では事前確認が要ります。

そのほかの制約。 ポート範囲が評価されるのはプロトコルがTCP（6）またはUDP（17）のときだけで、ICMPv4（1）・GRE（47）・Any（*）では自動的にAnyになります（APIに渡すとバリデーションエラーです）。ルートテーブルが関連付けられているアタッチメントは、解除しないとポリシーテーブルを付けられません。ターゲットとして参照されているルートテーブルは削除できません。TGW-to-Cloud WANピアリングアタッチメントでは顧客管理エントリが使えません。クォータはTGWあたりポリシーテーブル20（調整不可）、顧客管理エントリ合計200（引き上げ申請可）です。

まとめ

本記事のポイントを3つに整理します。

PBRは、宛先IPだけだったTGWの転送判断に、送信元CIDR・ポート・プロトコルという分類軸を追加します。 ポリシーテーブルはアタッチメントの標準のルートテーブルを置き換え、追加料金はありません。
評価はシステム管理エントリが先、次に顧客管理エントリを番号の昇順で見て、最初の一致で確定します。 広いルールを小さい番号に置くと具体的なルールが評価されず、検査の素通りにつながります。
どれにも一致しないトラフィックは破棄されます。 catch-allルールの有無がそのまま通信可否になるため、PacketDropCountNoPolicy を監視対象に入れておく必要があります。