閉域網でのAPI公開の選択肢全部比較！

2026/11現在の選択肢です。

1. 閉域網でのAPI公開の選択肢全部比較！ TGW Policy-Based Routing と PrivateLink Tunnel Endpoint を含めた2026/11現在地 NWJAWS 2026-11
2. 自己紹介 石原 晶子(高野) X: takano0131 雑用系インフラエンジニア / 育休中 / 初心者支部運営 好きなサービス: Transit Gateway フローログ • 2025-2026 Japan All AWS Certifications Engineers • 2026 Japan AWS Top Engineers • AWS Community Builder（Networking and Content Delivery） • 2026 Google Cloud Top Engineer NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 2
3. 宣伝① AWS×生成AI学習ガイド Webサービス開発基礎テクニック （技術の泉シリーズ） AIを使っても AWSなんもわからん人向け 2026/5 発売中！ NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 3
4. 宣伝② 初⼼者⽀部朝活！＃６ 2026/11/20 朝8時〜 東京⽀部＆朝会＆ 初⼼者⽀部 コラボ雑談回！ 27も朝活！ #jawsug_bgnr
5. まずは 今日の登壇の趣旨について 5
6. よくある社内のシステム構成レビューにて 機密情報が含まれるシステムは 社内のみから利用できる 必要があります！ インターネット経由は 危ないが口癖おじさん NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 6
7. よくある社内のシステム構成レビューにて 言い換えると 閉域網 「社内の API は、 で 他の VPC やオンプレ、他クラウドから叩けるようにする」 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 7
8. 選択肢の変遷 2026年に新機能が 2つ加わり現在の選択肢は 7つになっている 定番 2022〜 2024-12 2026-07 2026-09 Transit Gateway Interface Endpoint (PrivateLink) Private API Gateway VPC Lattice Resource Endpoint （PrivateLink） TGW Policy-Based Routing PrivateLink Tunnel Endpoint NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 8
9. 今日の話 現在選べる閉域網の選択肢全部を比較してユースケース別に使う場面を紹介します！ 1 7つの閉域網 API構成 紹介 2 TGW Policy-Based Routing 検証 3 PrivateLink Tunnel Endpoint 検証 4 閉域網API構成比較 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 9
10. 1 7つの閉域網 API構成 紹介 それぞれの向き不向き 10
11. ネットワーク接続とサービス公開 API公開について 2系統に分けられます ネットワーク接続 ネットワーク同士の接続 API以外にも色々通信したいとき サービス公開 APIへの「入口」の設置 決めたものだけの公開 PrivateLink Transit Gateway Interface EP Resource EP Tunnel EP（NEW） + Policy-Based Routing（NEW） AWS内のみならVPC Peeringでも可能 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ Private API GW VPC Lattice 11
12. Transit Gateway VPC が多く オンプレや他クラウドと BGP でつなぐなら TGW 適した用途 VPC A VPC B • API 以外の通信（運用・監視など）の集約 • 相手の実 IP での 制御/監査 注意 Transit Gateway ルートテーブルで制御 オンプレ（ VPN） NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ • CIDR 重複不可 • 両方向到達のため SG / NACL / ルートでの絞り 込み 他クラウド （Interconnect） 12
13. TGW Policy-Based Routing NEW 2026-07 同じ宛先でもフローごとに経路を選べる新機能 適した用途 ポリシーテーブルの例（ pt-spoke） # プロトコル 送信元 ポート 送信先 CIDR 送信先 ポート TGW RT 100 TCP * 10.20.0.0/16 9090 rt-via-vpn 110 TCP 9090 10.20.0.0/16 * rt-via-vpn 120 TCP * 10.20.0.0/16 8080 rt-via-icx 130 TCP 8080 10.20.0.0/16 * rt-via-icx 1000 * * * * rt-default • 検査経路への振り分け • 回線の使い分け（ポートで DX / VPN） 注意 • VPN / TGW Connect アタッチメントへの関連付 けで BGP 広報停止 上から評価 最初に一致したルールの TGW RT を使用 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 13
14. PrivateLink（Interface Endpoint） 1つのサービスを多数のアカウントへ公開するなら Interface EP 利用側（ Consumer） 適した用途 提供側（ Provider） • CIDR が重複した相手への公開 • 公開したいAPIサーバへのみ到達 API サーバ client 注意 Interface EP SG + EP ポリシー NLB 許可プリンシパル + 承認 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ • 提供側の NLB が必須 • 公開はリスナー（ポート）単位 • 送信元は NLB / EP の IP 14
15. PrivateLink（Resource Endpoint） API サーバを NLB なしで個別に公開するなら Resource EP 利用側 VPC client 適した用途 提供側 VPC API サーバ（ IP / DNS 名） • NLB なしでの API サーバの公開 • CIDR が重複した相手への公開 • RDS などの DB も同じ仕組みで公開可能 注意 Resource EP SG NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ Resource Gateway rcfg + RAM 共有 • TCP のみ • リソースごとの Resource Configuration（rcfg）+ Resource Access Manager（RAM）共有 + EP • 送信元は Resource Gateway の IP 15
16. PrivateLink Tunnel Endpoint NEW 2026-09 重複 CIDR のセグメントを丸ごと実 IP のまま使える新機能 適した用途 Resource Configuration（公開範囲）の例 タイプ プロトコル ポート CIDR CIDR TCP-UDP（※UDPはDNSのみ） 1-65535 10.0.10.0/24 • CIDR が重複した相手 • 実 FQDN・複数ポートのままの利用 注意 利用側 + GENEVE Tunnel EP Resource Gateway NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 10.0.10.0/24 丸ごと • 利用側の GENEVE 実装が必須 • 送信元は Resource Gateway の IP 16
17. VPC Lattice API を多数のアカウントへ公開し認可も統一するなら Lattice 適した用途 VPC A サービスネットワーク サービス X • 多数のマイクロサービス（HTTP / gRPC） • IAM Auth Policy での認可の統一 注意 Auth Policy VPC B NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ サービス Y • リスナーは HTTP / HTTPS / TLS のみ（TCP は Resource Configuration） • TGW / DX / VPN 越しはサービスネットワーク EP が必 須 • API から見た送信元は Lattice の IP （169.254.171.0/24 など） 17
18. Private API Gateway 認証やスロットリングなど API 管理機能が要るなら Private API GW 利用側 VPC client 適した用途 提供側アカウント • 数個の API の公開 • WAF・使用量プランの利用 Lambda / VPC Link 注意 execute-api EP API Gateway（Private） パブリック API Private DNS 時は ✕ NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ リソースポリシー aws:SourceVpce • VPCE を許可するリソースポリシーが必須 • Private DNS 有効時は既定のパブリック API に到達不 可 • オンプレからは DX / VPN 経由での EP 到達が必須 • 統合タイムアウト 29 秒（引き上げ可） 18
19. 2 TGW Policy-Based Routing 検証 AWS ⇔ GCP（Site-to-Site VPN + AWS Interconnect - multicloud）で検証 19
20. TGW Policy-Based Routing 検証環境 VPN(インターネット経由 ) と Interconnect(閉域) の2経路を振り分ける マルチクラウド検証 AWS us-east-1 Google Cloud us-east4 S2S VPN（BGP） API VPC 10.10.0.0/16 HA VPN Transit Gateway TGW RT ×4 PT ×2（PBR） Cloud Router gcp-vm 10.20.1.10 DXGW Cross-Cloud Interconnect 1Gbps gcp-vmのAPIを EC2より打鍵 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 20
21. TGW Policy-Based Routing 検証環境 VPN(インターネット経由 ) と Interconnect(閉域) の2経路を振り分ける マルチクラウド検証 AWS us-east-1 Google Cloud us-east4 S2S VPN（BGP） API VPC 10.10.0.0/16 HA VPN Transit Gateway TGW RT ×4 PT ×2（PBR） gcp-vmのAPIを EC2より打鍵 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 送信元 送信先 ポート CIDR Cross-Cloud * 10.20.0.0/16 Interconnect 1Gbps # DXGW 100 プロトコル 110 TCP 9090 120 TCP 130 1000 TCP Cloud Router 送信先 ポート gcp-vm 10.20.1.10 TGW RT 9090 rt-via-vpn 10.20.0.0/16 * rt-via-vpn * 10.20.0.0/16 8080 rt-via-icx TCP 8080 10.20.0.0/16 * rt-via-icx * * * * rt-default 21
22. (結果)ポート単位の経路の振り分け 想定通り 9090ポート は VPN から 8080ポート・他ポート は Interconnect から出ていった ※ DXGWを優先するため Default ＝ Interconnect TGW フローログの様子 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 22
23. 注意点① 応答パケットへのルール適用 TGW PBR は往路と復路を別々に判定するので応答の行き先も設計する Interconnect 作成前 rt-via-icx が空のまま 8080 を Interconnect 側へ振り分けた ① 要求（宛先ポート 8080） ② 応答（送信元ポート 8080） vpn-gcp の TGW RT rt-edge api-vpc のポリシーテーブル pt-spoke 送信先 CIDR アタッチ メント # 10.10.0.0/16 api-vpc ✓ api-vpc へ届く 送信元 ポート 送信先 CIDR 送信先 ポート TGW RT 100 * 10.20.0.0/16 9090 rt-via-vpn 110 9090 10.20.0.0/16 * rt-via-vpn 120 * 10.20.0.0/16 8080 rt-via-icx 130 8080 10.20.0.0/16 * rt-via-icx （ルートなし） 1000 * * * rt-default ✗ no-route で破棄 TGW RT rt-via-icx 送信先 CIDR アタッチ メント 16:46:49 [vpn-gcp] 10.20.1.10:35348 -> 10.10.1.10:8080 ingress ← 要求 16:47:06 [api-vpc] 10.10.1.10:8080 -> 10.20.1.10:35348 noroute=2 ← 応答 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 23
24. 注意点② 何もしないポリシーのVPN関連付け BGP の広報が停止する エントリ 関連付け ルール 1000 0.0.0.0/0 → rt-edge ／ 関連付け先 VPN アタッチメント NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 24
25. 注意点② 何もしないポリシーのVPN関連付け 通信は両方向とも止まるのに BGP の状態監視では気付けない Before • GCP 側から 10.10.0.0/16 が消失 • BGP は Established のまま • AWS 側は GCP の経路を受 信し続ける状態 After（約 4.5 分後） PEER bgp-aws-1 STATE Established LEARNED 0 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 25
26. 注意点③ DXとInterconnectでの広報継続 同じポリシーでも付ける先で結果が逆になる • DXGW は allowed prefixes(許可されたプリフィックス ) で広報が決まる +0s VPN learned=1 / ICX routes=10.10.0.0/16 +332s VPN learned=1 / ICX routes=10.10.0.0/16 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ ← 残る 26
27. 注意点④ マルチクラウドの経路非対称 GCP側からは TGW PBRの制御は効かずに BGP学習経路になる • AWS → GCP は Interconnect（閉域）を優先 • GCP → AWS は VPN（インターネット経由）を優先 VPNはローカル接続になるため、GCPの仕様によりVPNが選ばれた NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 27
28. 3 PrivateLink Tunnel Endpoint 検証 東京・CIDR が完全に重複した 2 VPC（10.0.0.0/16）で検証 28
29. 検証環境 CIDR を完全に重複させた 2つの VPC をつないだ 利用側 VPC 10.0.0.0/16 tester 10.0.10.50 decoy 10.0.10.20 提供側 VPC 10.0.0.0/16 CIDR rcfg（公開範囲） 10.0.10.0/24 後で 10.0.20.0/24 を追加 api-a 10.0.10.10 api-b 10.0.10.20 GENEVE UDP 6081 api-c 10.0.10.30（後から追加） Tunnel EP 10.0.100.48 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ Resource Gateway db 10.0.20.30（初めは範囲外） 29
30. (結果)提供側だけでの公開範囲の制御 想定通りサーバ追加は作業なしで届き rcfg の CIDR を戻すと約 30 秒で届かなくなった サーバ追加 → 設定変更なしで到達 rcfg の CIDR を縮小 → 約 30 秒で到達不可 • Interface EP は TG・リスナーの追加 • Resource EP は rcfg + RAM + EP の追加 • Tunnel EP は範囲内なら作業不要 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 30
31. 提供側が2つのときの名前解決 想定通り同じ DNSでもトンネル A は 10.0.10.10 B は 10.0.10.20 と答えが分かれた 利用側 VPC 10.0.0.0/16 提供側 A 10.0.0.0/16 PHZ corp.internal whoami → 10.0.10.10 クライアント (netns) クライアント A Tunnel EP A Tunnel EP B NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 名前 答え クライアントA トンネル A whoami.corp.internal 10.0.10.10 クライアントB トンネル B whoami.corp.internal 10.0.10.20 クライアントA トンネル A api-a.b-only.internal NXDOMAIN トンネルなし 10.0.0.2 whoami.corp.internal NXDOMAIN 提供側 B 10.0.0.0/16 PHZ corp.internal whoami → 10.0.10.20 PHZ b-only.internal (netns) クライアント B 経路 • 利用側の VPC の DNS は不使用 • トンネル選びは利用側の責任 • 同じゾーン名は末尾で振り分け不可 31
32. 注意点⑤ アプリの通信はTCPのみ rcfg を TCP-UDP にしても UDP と ICMP は提供側に届かない rcfg のプロトコルは TCP-UDP のまま 3 種類を送った 送ったもの 提供側のフローログ 結果 ドキュメントの記載 TCP 8080 / 9090 ACCEPT ✓ 届く • GENEVE の中の UDP は DNS の 問い合わせだけ UDP 9999 0件 ✗ 届かない • アプリの通信は TCP ICMP（ping） 0件 ✗ 届かない UDP の API と ping での疎通確認には使えない NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 32
33. 注意点⑥ 利用側のGENEVE実装 利用側は GENEVE を扱う仕組みを自分で用意して運用する • VNI=0 で中身は IP パケット（0x0800）を UDP 6081 で運ぶ • 性能・AZ 障害時の切り替え・MTU の設計が 必要 • 検証で作ったリレーは付録A3 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 利用側 VPC のフローログ（ UDP 6081 だけ） 33
34. 注意点⑦ 提供側から見た送信元 提供側からは利用側の実 IP ではなく RGW の IP に見える 利用側 2 つ（どちらも tester 10.0.10.50）から提供側 A の api-a を 5 回ずつ 利用側 利用側の IP API が見た送信元 IP 利用側 1 10.0.10.50 10.0.100.131 利用側 2 10.0.10.50 10.0.100.235 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ • どちらも同じ RGW の ENI の IP • 同じ EP からは毎回同じ IP • EP との対応はドキュメントに記載 なし 34
35. 注意点⑧ 公開範囲の変更の影響 1つのrcfg を使用している場合、変更は全部の利用側に同時に影響する 提供側 A の rcfg を 10.0.20.0/24 だけに縮めて元に戻した rcfg 縮める前 利用側 1 利用側 2 OK OK 縮めた後 NG（03:02:38〜） NG（03:02:52〜） 戻した後 OK（03:05 ごろ） OK（03:05 ごろ） • 15 秒差で両方 NG • 約 2.5 分後に両方復旧 • 1 つの rcfg では利用側ごとに分 けられない rcfg を利用側ごとに分けると片方だけ範囲を変えられることが可能 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 35
36. 4 閉域網API構成比較 作り / 運用 / 速度 / 要件別の選択 36
37. 比較① 作りの違い 公開系は CIDR が重複しても使えて公開したものにしか届かない TGW TGW + PBR Interface EP Resource EP VPC Lattice Private API GW Tunnel EP L3 L3 5-tuple L4 L4 L7 / TLS L7（REST） L3 公開する単位 API サーバ API サーバ NLB の リスナー API サーバ 1台 サービス API CIDR 内の サーバ CIDR の重複 不可 不可 可 可 可 可 可 接続の向き 両方向に届く 両方向に届く 利用側 発のみ 利用側 発のみ 利用側 発のみ 利用側 発のみ 利用側 発のみ 実 IP 実 IP NLB / EP の IP RGW の IP Lattice の IP API GW で 終端 RGW の IP 利用側からの 名前解決 実 FQDN PHZ 共有 実 FQDN PHZ 共有 EP の DNS 名 EP の DNS 名 サービスの DNS 名 execute-api の DNS 名 実 FQDN 提供側 PHZ 独自のドメイン名 — — 提供側で設定 利用側は自動 提供側で設定 利用側は自動 CNAME を 手で作成 利用側で PHZ を作成 — レイヤ 利用側 IP の見え方 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 37
38. 比較② 運用の違い 細かく制御するなら L7 系 増設の手間を減らすなら TGW か Tunnel EP TGW TGW + PBR Interface EP Resource EP VPC Lattice Private API GW Tunnel EP SG / NACL SG / NACL SG + EP ポリシー SG + RAM IAM Auth Policy IAM / オーソライザー SG + RAM + CIDR オンプレ・他クラウド ◎ BGP DX は BGP VPN 静的※ DX / VPN 経由で EP DX / VPN 経由で EP SN EP DX / VPN 経由で EP EP + GENEVE API サーバ増設時 作業なし 作業なし TG に登録 rcfg を追加 ターゲット 登録 統合を追加 範囲内なら 作業なし 月額 API サーバ 1 台 約 $75 約 $75 約 $33 約 $16 約 $21 約 $36 約 $16 月額 API サーバ 10 台 約 $75 約 $75 約 $33 約 $148 約 $21 約 $36 約 $16 アクセス制御 試算 us-east-1・2 AZ・利用側 1 VPC・月 730 時間・100 GB・100 万リクエスト（10 台は同じ API の後ろに置く） ただしResource EPは1台ずつ公開する構成 NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 38
39. 通信速度の実測（us-east-1 同一AZ） 最速は TGW 系で PBR を挟んでも遅くならない TCP 接続確立 p50（ms・短いほど良い） 経路 1 フロー Gbps 8 並列 Gbps HTTP p50 ms 同じ VPC（基準） 0.06 同じ VPC / Peering 9.5 24.8 0.3〜0.4 VPC Peering 0.06 TGW / TGW + PBR 4.9 24.8 1.1〜1.4 Interface / Resource EP 4.9 24.8 2.5〜3.5 VPC Lattice（HTTP） 1.2※ — 4.5 — — 31 1.8※ 1.7 3.0 TGW 0.70 TGW + PBR 0.74 Private API GW VPC Lattice 1.21 Tunnel EP（自作リレー） Private API GW 1.76 Interface EP 1.78 Tunnel EP※ Resource EP NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ • VPC をまたぐ 1 フローは約 5 Gbps • 8 並列ならどれも約 25 Gbps 2.25 2.87 ※ Lattice は 1GiB の HTTP 転送 ※ Tunnel EP はリレーがボトルネックになる 参考値 39
40. 最後に まとめ 40
41. 選び方 3つの質問で 7つの選択肢は 1〜2個に絞れる 1 2 3 ネットワーク接続か サービス公開か CIDR 重複の 有無 規模と 認可の要件 迷ったら比較①②で外せない観点の行の黄色いセルの列を選ぶ NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 41
42. 要件別の選択 サービス公開のみ API が数個 管理機能が欲しい Private API GW / Interface EP 多数のアカウントに HTTP の API 認可も統一 VPC Lattice API サーバ 1 台を NLB なしで公開 Resource EP セグメント丸ごと・CIDR が重複・安価 Tunnel EP ネットワーク接続要・速さを求める 数十 VPC + オンプレ / 他クラウド（BGP） さらにフローで経路を分けたい NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ TGW TGW + PBR 42
43. ご清聴ありがとうございました！
44. 付録A1 関連付け切り替えの罠 切り替えスクリプトには再試行と待ちを入れる ルートテーブル 関連付け 解除 （表示上は外れた） ポリシーテーブル関連付け → IncorrectState 再試行 • 解除の直後は 表示上は外れていても関連付けが拒否されることがある • その間アタッチメントは何にも関連付いておらず 約 4〜5 分で広報が止まる • ポリシーテーブルを付けると Association に TransitGatewayPolicyTableId が入る • 切り替え直後の約 30 秒はポートによって挙動が混在する NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 44
45. 付録A2 TGWの経路の優先順位（実測） TGW は DXGW を GCP は VPN を優先し両側で逆になる • 同じ 10.20.0.0/16 を VPN と DXGW の両方から伝播 • rt-default では DXGW（direct-connect-gateway）が選ばれた $ aws ec2 search-transit-gateway-routes (rt-default) 10.10.0.0/16 propagated active vpc 10.20.0.0/16 propagated active direct-connect-gateway NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 45
46. 付録A3 検証のコツ 利用側のGENEVE実装 Linux 標準の geneve では使えずリレーを自作する必要がある • VNI=0 で中身は IP パケット（0x0800）を UDP 6081 で運ぶ リレーのログ（中身の IP パケットが見える） NWJAWS 2026-11 | 閉域網でのAPI公開の選択肢全部比較！ 46