【要約】Transit Gateway の新機能「ポリシーベースルーティング」の使い時を考えてみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
ネットワーク設計において、宛先IPが同一の通信に対して経路を細かく制御できない課題がある。従来のTGWでは、宛先IPのみでルートを決定するため、以下の問題に直面していた。
- ・サブネット単位で経路を変えるには、VPC自体を分割してアタッチメントを分ける必要があった。
- ・全通信を検査VPCへ集約すると、Firewallの処理コストやデータ処理料金が増大する。
- ・Direct ConnectとVPNを併用する場合、通信種別（基幹系とバックアップ系）による回線の使い分けが困難であった。
// Approach
AWSは、パケットの属性に基づきルートテーブルを切り替えるPBRを導入した。パケットの属性を詳細に参照することで、以下の手法による制御を実現する。
- ・送信元/宛先CIDR、ポート、プロトコルの5要素を組み合わせたマッチングを行う。
- ・ポリシーテーブルに順序付きルールを定義し、最初にマッチしたルールを適用する。
- ・特定のサブネットや、特定のポート（例：rsyncの873番）を条件に、異なるルートテーブルへ振り分ける。
- ・アタッチメントにポリシーテーブルを関連付け、動的なルーティングを実現する。
// Result
PBRの活用により、ネットワーク構成の柔軟性とコスト効率が向上する。具体的な成果は以下の通りである。
- ・VPCを分割せずに、サブネット単位での高度なルーティング制御が可能になる。
- ・検査不要な大容量通信を直接転送し、Firewallの処理コストを削減できる。
- ・基幹通信をDirect Connectへ、バックアップ通信をVPNへ振り分け、帯域の競合を回避できる。
Senior Engineer Insight
> ネットワーク設計の自由度が飛躍的に高まる機能だ。特に、セキュリティ検査のコスト最適化や、ハイブリッド環境での帯域制御において強力な武器となる。しかし、ルール番号による順序制御や、VPNにおけるBGP広告停止といった特有の挙動には注意が必要だ。設計ミスが通信断に直結するため、運用フェーズではポリシーの可視化と厳格な変更管理が不可欠となるだろう。