Transit Gatewayの深淵へ：大規模ハブ＆スポークにおける「目に見えないボトルネック」の攻略法
クラウドアーキテクチャの設計において、AWS Transit Gateway（以下TGW）はもはや空気のような存在だ。しかし、この「空気」が汚染された時、あるいは流れが滞った時、あなたのアプリケーションは静かに、しかし確実に死を迎える。
本稿では、教科書的な「VPCを繋ぐ」というレベルを超え、パケットがTGWというブラックボックスを通過する際に何が起きているのか、そして大規模環境でパフォーマンスとセキュリティを極限まで引き出すための「現場の知恵」を紐解く。
1. TGWの内部挙動とRTTの真実
多くのインフラエンジニアは、TGWを単なる「仮想ルーター」と捉えている。だが、実体はAWSの巨大なSDN（Software Defined Network）基盤の上に構築された、分散型のマルチテナント・ゲートウェイだ。
パケットがTGWを経由する際、ソースVPCからTGWのアタッチメントへ、そしてルーティングテーブルを参照してデスティネーションVPCへと転送される。ここで無視できないのが「ジッター」と「RTTの微増」だ。
TCPバッファとウィンドウサイズの最適化
TGWを介した通信では、物理的なホップ数以上に「TCPウィンドウサイズ」のチューニングがスループットを左右する。デフォルトのLinuxカーネルパラメータでは、高レイテンシかつ帯域の広いTGW経由のコネクションにおいて、帯域幅遅延積（BDP）を埋めきれないケースが多い。
# sysctl.confへの追記例：BDPを考慮したTCPバッファの拡大
# 10Gbps帯域を想定し、最大受信/送信バッファを16MBまで引き上げる
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 変更を反映
sysctl -pこの設定により、TGWを跨ぐ長距離の通信においても、TCPのフロー制御がボトルネックにならず、パイプラインをフルに活用できる。
2. ルーティングドメインの罠とセキュリティ設計
TGWのルーティングテーブルを分ける「ルーティングドメイン」は、セキュリティの要だ。しかし、設計の複雑化はしばしば設定ミスを招く。
特に注意すべきは、Propagation（伝播）とStatic Routeの優先順位である。TGWのルーティングアルゴリズムにおいて、最も優先されるのは「最も具体的なルート（最長一致）」だが、これが複雑なスポーク群の中で競合すると、パケットは意図しない「ブラックホール」へ吸い込まれる。
セキュリティの最適化：TGWと検査VPCの構成
セキュリティチームから「全トラフィックを検査せよ」と要求されたとき、単に全VPCをTGWに繋ぐだけでは不十分だ。我々は「Inspection VPC」をハブに配置し、TGWのルートテーブルを操作することで、強制的にトラフィックをFW/IPSへ迂回させる必要がある。
この際、MTUサイズには細心の注意を払うこと。TGWはJumbo Frames（MTU 8500）をサポートしているが、FWを挟むとパケットが断片化（Fragmentation）され、CPU負荷とレイテンシが劇的に増大する。
# インターフェースのMTUを確認し、必要に応じて9001へ引き上げる
# パケットの断片化を避けるため、エンドポイント間のMTUを統一する
ip link set dev eth0 mtu 90013. 暗号化とオーバーヘッドの均衡
通信経路にオンプレミスが含まれる場合、AWS Direct Connect（DX）とVPN（IPsec）のハイブリッド構成をとるのが定石だ。ここで課題となるのが、IPsecのオーバーヘッドによる「パケットの肥大化」だ。
IPsecのヘッダーおよび暗号化プロトコルによるオーバーヘッドは、標準的なMTU 1500のパケットを圧迫し、結果としてMSS（Maximum Segment Size）調整が必要となる。
- MSS Clampingの実施:
TCPの3ウェイハンドシェイク中に、MSS値を小さく書き換えることで、断片化を未然に防ぐ。
# iptablesを用いたMSSクランピングの強制
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 13604. 現場のSREが教える「見えない脆弱性」の回避策
最後に、TGW環境における最も危険な脆弱性の一つが「ルートリーク」だ。スポークVPCから意図せず内部のルート情報が漏洩し、本来通信すべきでない環境同士が疎通可能になる事故が後を絶たない。
- 自動化によるガードレール:
TGWのルートテーブル変更は、Terraform等のIaCで管理し、terraform planの段階で「意図しないルートテーブルの重複」を検知するCI/CDパイプラインを構築すること。
- VPC Flow Logsによる異常検知:
TGWのAttachmentレベルでFlow Logsを有効にし、REJECTされたパケットの傾向をAthenaで分析せよ。特定のスポークから未知のIPレンジへの探索的な通信は、侵害の初期兆候である可能性が高い。
結論：ネットワークは「生き物」である
TGWは強力な武器だが、それを使いこなすにはカーネルのTCPスタックからクラウドのSDNレイヤーまで、パケットの旅路を可視化する能力が不可欠だ。
インフラアーキテクトとして、設計図を書くだけで満足してはいけない。実際にパケットがどのルートを辿り、どのOSバッファで待機し、どのMTUで断片化されているのか。その「手触り」を理解した者だけが、真にスケーラブルで堅牢なネットワークを構築できるのである。
さあ、今すぐあなたのVPCのMTUとTCP Windowを確認してほしい。そこには、まだ改善の余地が眠っているはずだ。
コメント