【ついに来た！】AWS Client VPN が Transit Gateway とネイティブ統合！中間VPC不要・ソースIP保持で運用負荷が激減！

AWS Client VPN が AWS Transit Gateway (TGW) とのネイティブな統合機能をサポートしました。これにより、Client VPN エンドポイントを TGW に直接アタッチ可能となり、複数の VPC やオンプレミスネットワークへの集中アクセスを簡素化できます。また、これまで必要だった中間 VPC の構築・管理が不要になるほか、クライアントのソースIPアドレスがエンドツーエンドで保持されるようになり、セキュリティ監査やトラブルシューティングの可視性が劇的に向上しました。

🛠️ もう「中間VPC」に悩まされない！運用とセキュリティが劇的に変わるアップデート

これまで Client VPN を複数の VPC やオンプレミスに繋ぐ際、**「中間VPCを立てて管理するのが面倒すぎる…」「NATによるソースIP消失がセキュリティ監査で致命的…」**という現場の痛みを抱えていたエンジニアは多いはずです。今回のアップデートは、まさにその課題に対する決定打と言的な進化です。

✅ ここが「神」アップデートなポイント

1. 構成のシンプル化: 中間VPCを排除できるため、管理コストとNAT Gateway等のリソースコストを削減できます。
2. IP可視性の復活: SNATによるIP変換が廃止され、クライアントの実際のIPが保持されるため、TGW フローログで「誰がどこへアクセスしたか」が明確に追跡可能になります。

🇯🇵 日本国内の利用状況

最新のリージョン状況を確認したところ、東京リージョン (ap-northeast-1) および大阪リージョン (ap-northeast-3) の両方で利用可能であることが確認できました。日本のプロジェクトですぐに導入検討可能です。

⚠️ 実務でハマらないための「重要注意点」

ここが非常に重要です。なんとなく使い始めると通信が通りません。以下の制約を必ず押さえておいてください：

• セキュリティグループ認可の制限: TGW統合時は、セキュリティグループベースの認可が使用できません。ネットワークベースのルールのみを使用してください。
• ルート管理の完全手動化: TGWからの自動ルート伝播は行われません。宛先へのルートは手動で定義する必要があります。
• 戻りルートの設定: 接続先の各VPC側で、Client VPN の CIDR 宛てのトラフィックを TGW に戻すためのルート設定が必須です。
• アソシエーションの排他利用: 「VPCサブネットアソシエーション」と「Transit Gatewayアソシエーション」は、一つのエンドポイント内で混在できません。どちらか一方のみを選んで作成してください。

🚀 次に何をすべきか？

既存の Client VPN 構成が中間VPCを経由しているなら、コスト削減と運用簡素化のために**「TGW直接アタッチ」への移行検証**を強くおすすめします。まずは開発環境で、セキュリティグループではなくネットワークベースのルールで構成を組めるか、ポリシーの設計から見直してみてください。

参照した公式ドキュメント: AWS Client VPN Documentation – Transit Gateway Integration