境界を制する者だけが生き残る：AWS Transit Gatewayによるネットワークの「完全分離」とパフォーマンス最適化
クラウドアーキテクトとして数多のAWS環境を診てきたが、いまだに「なんとなく」で Transit Gateway（TGW）のルートテーブルを設計している現場に出くわす。VPCをアタッチして、デフォルトルートを流し込んで終わり——それでは、真の意味でネットワークを支配しているとは言えない。
TGWは単なる接続ハブではない。それは、L3の境界を制御する巨大な「ソフトウェア定義のルーター」であり、そのPropagation（伝播）とAssociation（関連付け）を掌握することこそが、堅牢なクラウドインフラの要諦だ。今日は、この制御層の奥深く、パケットの行方にまで踏み込んで話をしよう。
1. TGWルートテーブル：制御の「分離」こそがセキュリティの要
ハブ＆スポーク構成において、すべてのトラフィックを一つのルートテーブルで管理するのは自殺行為だ。開発環境のノイズが本番環境のログ基盤を汚染し、最悪の場合、意図せぬ疎通パスがセキュリティ境界を無効化する。
ここで重要になるのが、ルートテーブルの「論理的な分離」だ。
- Association（関連付け）: VPCアタッチメントがどのルートテーブルを「参照」するか。
- Propagation（伝播）: どのVPCのCIDRを、どのルートテーブルに「学習」させるか。
例えば、セキュリティ検査用VPC（Inspection VPC）を介さない通信を許容してはならない環境では、スポーク側のルートテーブルを厳密に分割し、0.0.0.0/0 を検査VPCのアタッチメントにのみ向ける。この際、TGWのルートテーブルを分けることで、誤ってルートを伝播させるリスクを物理的に遮断できる。
2. パケットの行方を追う：RTT削減とヘッダーの最適化
インフラエンジニアの腕の見せ所は、単なる接続性だけではない。マイクロ秒単位の遅延が、高頻度なマイクロサービス間通信では致命的な「死」を招く。
TGWを通過する際、パケットはカプセル化処理を受ける。ここでの最大の敵は、MTUの不一致によるパケット断片化だ。
MTUの最適化によるパフォーマンス向上
多くのエンジニアがデフォルトの 1500 バイトのまま放置しているが、TGWを経由するパケットはオーバーヘッドが発生する。可能であれば、各VPCアタッチメントで MTU 8500 （ジャンボフレーム）を有効化し、TCPのセグメンテーションオフロードと組み合わせるべきだ。
# VPCアタッチメントのMTU設定（CLI例）
# TGWアタッチメント作成時にMTUを指定する。ジャンボフレーム対応でスループットを最大化する。
aws ec2 create-transit-gateway-vpc-attachment \
--transit-gateway-id tgw-0abc123456789def \
--vpc-id vpc-0123456789abcdef \
--subnet-ids subnet-12345678 \
--options '{"ApplianceModeSupport": "enable", "DnsSupport": "enable", "Ipv6Support": "enable", "Mtu": 8500}'TCPバッファチューニングの重要性
TGWを跨ぐ通信では、BDP（Bandwidth Delay Product）を考慮したTCPバッファ設定が欠かせない。Linuxカーネルパラメータの net.core.rmem_max や net.ipv4.tcp_rmem をチューニングし、遅延が発生しやすい環境でもTCPウィンドウサイズが適切に拡張されるようにしておく必要がある。
# /etc/sysctl.conf への追記例
# 高速広帯域ネットワークでのTCPウィンドウサイズを最適化
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 167772163. セキュリティを極める：TLSハンドシェイクの「寄り道」を減らす
セキュリティ検査用VPCをハブにする際、TLSハンドシェイクの遅延は深刻な問題だ。TLS 1.3が普及し、ラウンドトリップ数が削減されたとはいえ、TGWを介して検査用Applianceを通過させる場合、TCPの3ウェイハンドシェイクとTLSハンドシェイクでRTTが倍増する。
ここで検討すべきは、「条件付きルーティング」だ。
すべてのトラフィックを検査するのではなく、TGWルートテーブルの伝播制御を活用し、信頼できる通信（例：同一アカウント内の特定のサービス間通信）は直接通信させ、外部や重要データストアへの通信のみを検査VPCへ流す設計にする。これにより、不要なレイテンシを排除しつつ、セキュリティを担保できる。
4. 現場からの警鐘：陥りやすい脆弱性
私が現場でよく目にする重大なミスは、「TGWルートテーブルの伝播による経路ループ」だ。
特に、Direct ConnectやVPNをTGWに接続している場合、ルートの伝播設定がループを誘発することがある。これを防ぐには、TGWルートテーブルに明示的なルートを静的に書き込み、伝播設定（Propagation）は最小限に絞るのが定石だ。
また、ApplianceModeSupport を無効にしていると、非対称ルーティングによって戻りのパケットが検査用Applianceをバイパスし、ファイアウォールで破棄される現象が発生する。マルチAZで構成する場合は、必ずこの設定を見直してほしい。
# AWS SDK (Boto3) でのアタッチメント設定確認ロジック（抜粋）
import boto3
def check_tgw_attachment_config(attachment_id):
ec2 = boto3.client('ec2')
response = ec2.describe_transit_gateway_vpc_attachments(
TransitGatewayAttachmentIds=[attachment_id]
)
# ApplianceModeがenableになっているかを確認するガードレール
options = response['TransitGatewayVpcAttachments'][0]['Options']
if options['ApplianceModeSupport'] != 'enable':
print(f"Warning: {attachment_id} におけるApplianceModeがオフです。非対称ルーティングに注意してください。")結論：ネットワークを「意図」する
TGWの設計は、単なる接続作業ではない。パケットがどのゲートウェイを通り、どのルートテーブルで評価され、どの程度遅延するのか。そのすべてを脳内でシミュレーションできるエンジニアだけが、極限のパフォーマンスを引き出すことができる。
教科書的な設定を終えた後、パケットキャプチャで遅延要因を特定し、sysctlでバッファを追い込み、論理分離で境界を塞ぐ。この「泥臭い積み重ね」こそが、クラウド時代のネットワークアーキテクトの真の価値であると、私は確信している。
さあ、あなたのTGWルートテーブルを確認してほしい。そこには、意図せぬ接続が潜んでいないだろうか。
コメント