IP重複は"ランディングVPC"で受け止める ― PrivateLink と Transit Gatewayによるマルチテナント接続基盤の設計

NW-JAWS DAYでの登壇資料です
https://jawsug-nw.connpass.com/event/401646/

1. NW-JAWS DAY 2026-11-14 IP重複は"ランディングVPC"で受け止める 〜PrivateLink と Transit Gatewayによる マルチテナント接続基盤の設計〜 畠山 大治 / 満村 雄二
2. アジェンダ 01 はじめに 02 IP重複への対応方針 03 S2S VPNとDirect Connectの併用 04 PrivateLinkのアイドルタイムアウト 05 設計後の選択肢とまとめ
3. 01 はじめに
4. 自己紹介 名前 畠山 大治（はたはた） 所属 KDDIアイレット株式会社 業務 開発案件のPM 好きなもの・こと 好きなAWSサービス Perfume、サカナクション、音楽、読書、 映画・アニメ、体を動かすこと VPC、CloudFront、Step Functions Japan AWS Top Engineers（2024〜2026） その他活動など AWS Community Builders（since 2024） はたはた @hatake_book Ops-JAWS コアメンバー Toranomon Tech Hub 運営 4
5. プロジェクト背景 • 数十の既存オンプレ拠点と接続し、転送されるデータを受け取るシステムのリプレース • つなぎ方はSite-to-Site VPN と Direct Connectの2種類、既存拠点を徐々に接続していく • 既存の拠点同士はCIDRの重複なし Transit Gateway、Direct Connect Gatewayを組み合わせたよくある構成を検討 拠点A 10.1.0.0/16 拠点B 10.2.0.0/16 拠点C 10.3.0.0/16 システムVPC（10.4.0.0/16） Site-to-Site VPN Site-to-Site VPN Transit Gateway リプレースシステム Direct Connect Direct Connect Gateway 5
6. 詳細設計もひと段落…と思いきや 将来的な拠点増設の際のCIDR重複を考慮して、 AWS側でSNATしてもらえませんか？ （あれ、CIDR重複は考慮しなくていいんじゃ…？） 承知しました、設計を見直します お客様 私 • お客様も私たちも、「現状CIDR重複なし」＝「CIDR重複の考慮なし」と何となく思って しまっていた • とはいえ抜本的な設計修正はプロジェクト全体のスケジュール的に不可能、当初の設計を 大きく変えずにSNATを追加する構成を検討 6
7. 02 IP重複への対応方針
8. IP重複への対応案その1：Private NAT Gateway案 拠点の接続を受けるだけの専用VPC「ランディングVPC」でCIDR重複を受け止めるつつ、 NATをさせる方法を2つ検討 ランディングVPC システムVPC 拠点A Site-to-Site VPN Transit Gateway Private NAT Gateway Transit Gateway リプレースシステム • ランディングVPCの Private NAT Gateway で、拠点のIPを別のIPへ変換する • VPC間の接続にTransit Gatewayを使う場合はTransit Gatewayを2回通る必要がある • VPCピアリングで接続もできるが、いずれにしてもルーティングが複雑になる • NAT Gateway、Transit Gateway アタッチメントの固定費が痛い 8
9. IP重複への対応案その2：PrivateLink案 拠点の接続を受けるだけの専用VPC「ランディングVPC」でCIDR重複を受け止めるつつ、 NATをさせる方法を2つ検討 ランディングVPC システムVPC 拠点A 拠点B • Transit Gateway Interface Endpoint PrivateLink NLB リプレースシステム PrivateLinkはAWS側で透過的な接続をしてくれるのでTransit Gatewayを通るのは1回、 システムVPCにも戻りのルートが要らない • Private NAT Gateway案よりも固定費を抑えることができる、元々考えていた構成からの 修正も比較的小さく抑えられる • 固定費の安さ、構成のシンプルさによりPrivateLink案を採用 9
10. PrivateLink案の詳細 • ランディングVPCと拠点の間のCIDR重複は許容されないため、拠点で利用するCIDRの クラスによってランディングVPCを分ける • 帯域には余裕があるが、ランディングVPCあたりの接続できる拠点数も制限しておく ランディングVPC 172.16.1.0/24 拠点A 10.1.0.0/16 拠点B 10.2.0.0/16 システムVPC Transit Gateway Interface Endpoint ランディングVPC 192.168.1.0/24 拠点C 172.16.1.0/24 拠点D 172.16.2.0/24 この間のCIDR重複OK Transit Gateway PrivateLink リプレースシステム Interface Endpoint この間のCIDR重複OK 10
11. 03 VPNとDirect Connect（DX）の併用
12. 自己紹介 名前 満村 雄二(Mitsuo) 所属 KDDIアイレット株式会社 業務 PM・PL・リードエンジニア 好きなもの・こと 音楽全般、帽子、ドライブ、息子と銭湯に行く 好きなAWSサービス Route53、Athena その他 AWS Community Builders（since 2024） Mitsuo @Chanmitsu_sys 12
13. S2S VPNとDirect Connectは同居可能？ • 同一ランディングVPCにS2S VPNとDirect Connectからの接続を同居させて良いかを検討 • S2S VPNは静的ルートを用いる ランディングVPCにS2S VPNとDirect Connectは同居可能か？ 拠点A 10.1.0.0/16 拠点B 10.2.0.0/16 拠点C 10.3.0.0/16 ランディングVPC Site-to-Site VPN Interface Endpoint Site-to-Site VPN Transit Gateway 同居可能？ Direct Connect Direct Connect Gateway 13
14. Transit GatewayへのDirect Connect接続 • Transit GatewayへのDirect Connect接続にはTransit VIFとDirect Connect Gatewayが必要 • Transit VIFはBGPで経路をやり取りするため、 Direct Connectへの復路は伝播になる • Direct Connect Gatewayアタッチメントは静的ルートの対象外 • 1つのアタッチメントが関連付けれるルートテーブルは1つだけ 拠点A 10.1.0.0/16 ランディングVPC Site-to-Site VPN VPC Attachment 拠点B 10.2.0.0/16 Transit Gateway 経路に応じた Transit Gatewayへ 経路に応じた Transit Gateway Attachmentへ Site-to-Site VPN Direct Connect Gateway 拠点C 10.3.0.0/16 Direct Connect 14
15. ルートの評価順序 静的ルートと伝播ルートが同じルートテーブルに混在した場合 • 第1優先はロンゲストマッチ • 宛先CIDRが完全一致した場合、静的ルートが優先される 静的・動的関係なく、より細かく一致する経路を最優先する 経路の組み合わせ 選ばれる経路 静的 /16 と 伝播 /16 静的 静的 /16 と 伝播 /24 伝播の /24 重複なし それぞれ正しい経路 15
16. 今回のケースでは・・・？ • 往路は allowed prefixesに明記しないと広告されない • とはいえ、重複する経路に変更された場合、ランディングVPCを変更する必要が出る • S2S VPNとオペレーションが異なり、運用への負担が高まる 実運用に適さないネットワーク設計、設定ミスによる影響が大きい ランディングVPC ルートテーブル Endpoint 10.1.0.0/16 → 拠点A（静的） 戻り先 10.1.5.10 10.1.5.0/24 → 拠点X（伝播） 拠点A（VPN） 10.1.0.0/16 本来の戻り先 拠点X（DX） 10.1.5.0/24 を広告 実際の戻り先 16
17. 最終的にはどうした？ • Direct Connectの拠点は1社1VPCとする。 • 想定外の広告が出ても影響を当該拠点自身に限定する • S2S VPNの拠点は1つのランディングVPCに10社まで コスト、通信帯、障害発生時のバランスを取った設計を実施 拠点A 10.1.0.0/16 VPN用ランディングVPC 拠点B 10.2.0.0/16 静的ルート（10社まで） システムVPC DX用ランディングVPC リプレースシステム 拠点X 10.0.0.0/8 伝播（拠点毎） 17
18. 04 アイドルタイムアウト
19. PrivateLinkにおけるアイドル状態の課題 • アイドル状態が350秒に達すると接続情報を削除する • RST、FINフラグを返却しない • クライアント側は次の送信で初めてRSTフラグを受け取る • NLBのTCPアイドルタイムアウトは60〜6000秒で設定可能 • PrivateLink側は350秒で固定 ランディングVPC システムVPC 拠点A 拠点B Transit Gateway Interface Endpoint 350秒でセッションを 破棄 PrivateLink NLB リプレースシステム 19
20. つまり、どういった事が起きる？ • アイドル状態が350秒に達すると接続情報を削除する。 既存のセッションを使ってデータを送信しようとすると、 • RST、FINフラグを返却しない。 「該当するセッションが存在しない」と判断し、 送信元に対してTCP RSTを返却する＝通信を切断する • クライアント側は次の送信で初めてRSTフラグを受け取る。 ↓ • NLBのTCPアイドルタイムアウトは60〜6000秒で設定可能 システムの信頼性低下 トラブルシューティングの負担になってしまう • PrivateLink側は350秒で固定 ランディングVPC システムVPC 拠点A 拠点B Transit Gateway Interface Endpoint 350秒でセッションを 破棄 PrivateLink NLB リプレースシステム 20
21. 最終的にはどうした？ • 350秒未満の間隔でKeepAliveを送ることで対策 ランディングVPC システムVPC 拠点A 拠点B Transit Gateway Interface Endpoint アイドルタイムアウトによる セッション破棄を防止 PrivateLink NLB リプレースシステム 定期的なKeepAliveの送信 21
22. 05 設計後の選択肢とまとめ
23. より良いアーキテクチャにするためには 1 拠点側の回線・機器の冗長化 3 DNSフォワーダー対応 2 Direct Connect / VPN の冗長構成 4 IPAMによるマネージドなIP管理 IPAMにてIPアドレス群を管理 4 ランディングVPC 1 システムVPC Endpoint 拠点 Transit Gateway 予備の機器 PrivateLink 2 受信サーバ Hosted Zone 3 Resolver Inbound Endpoint 23
24. 採用しなかったもの 案 内容 見送った理由 IPAMでの管理 AWSのIPAMで 拠点のCIDRを管理 拠点・機器情報の管理も必要で 二重管理になるため 送信元のIPアドレス変更 重複した拠点側で 送信元のIPを変えてもらう 拠点の作業負荷が大きい /32のルート 送信元のIPだけを /32の経路にする 変更のたびに調整が必要 24
25. これにて一件落着…？ 25
26. アップデート「1:1 NATをサポート！？」 • 2026-10-23に、Transit GatewayでマネージドのNATが使えるようになった • 設計した時点では、この選択肢がなかった 26
27. 1:1 NATを使うとどうなるのか • アタッチメント上のルールで指定したCIDRレンジにNAT可能 • このNATがVPC単位ではなく1対1で可能 • つまり、ランディングVPCとPrivateLinkが不要になる！？ システムVPC（10.4.0.0/16） 拠点A 10.1.0.0/16 → 172.21.0.0/16 CIDRが重複 拠点C 10.1.0.0/16 拠点ごとのNAT CIDRで 同じVPCに収容可能 → 172.22.0.0/16 Transit Gateway 戻りのルートは NAT CIDRで指定 リプレースシステム NAT CIDRの払い出しと管理は必要 Direct Connect(Transit VIF経由)は 広告を止められないため、 別途考慮は必要か？ 27
28. 1:1 NATの注意点 • 設定の変更中は、通信が一時的に落ちることがある • ルール数は1アタッチメントあたり50、全体で1,000（引き上げ不可） • NAT CIDRの重複は同じアタッチメント内しか検査されない 参考：https://aws.amazon.com/about-aws/whats-new/2026/10/aws-transit-gateway-cloud-wan-1-1-nat/ 28
29. もうちょっと早くアップデートが来ていれば・・・・！？笑 近々検証予定 29
30. まとめ • CIDR重複を避けるためにIP重複を受け止めるランディングVPCを設け、PrivateLinkで SNATさせるネットワーク構成を採用 • VPNとDXの併用では、BGP広告と経路の優先順位に注意が要る • PrivateLinkのアイドルタイムアウトは固定のため、キープアライブで対処する必要がある • 今後同じ問題に遭遇する方は、Transit Gatewayの 1 : 1 NAT機能をまずは検討しましょう • CIDR重複が許容されるかどうかは重要な観点、見落とし注意！！ • 今回の構成は設計した時点で選べた手段での判断です、「他にこんな方法あるのでは？」 という意見があればぜひ教えてください！ 30
31. 宣伝 • Ops-JAWS Meetip 44 「2026年Ops系アップデート ＆ 運営LT」を 開催します！ • https://opsjaws.connpass.com/event/411543/ • AWS SAさんによる今年のOps系アプデ振り返りセッション、Ops運営 メンバーによるLTを用意しています 31
32. 参考資料 • 1:1 NAT in AWS Transit Gateway https://docs.aws.amazon.com/vpc/latest/tgw/tgw-nat.html • AWS Transit Gateway and AWS Cloud WAN now support 1:1 NAT https://aws.amazon.com/about-aws/whats-new/2026/10/aws-transit-gateway-cloud-wan-1-1-nat/ • How AWS Transit Gateway works（経路評価順序） https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html • Implementing long-running TCP connections within VPC networking https://aws.amazon.com/blogs/networking-and-content-delivery/implementing-long-running-tcp-connections-within-vpc-networking/ • Introducing NLB TCP configurable idle timeout https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-nlb-tcp-configurable-idle-timeout/ 32