AWSとココが違う！Google Cloudでの宛先NATとNW制御

AWSとココが違う！ Google Cloudでの宛先NATとNW制御 2026年5月31日 (検証実施時期：2024年8-10月) 株式会社エヌアイデイ ICTデザイン事業部ANA部第2課 Copyright(c)2026 NID All Rights Reserved 1

参加メンバー＆検証年月 ICTデザイン事業部ANA部第2課 A.F. ICTデザイン事業部ANA部第2課 N.Y. (1年目 ※検証当時) (1年目 ※検証当時) ※2024年08月～10月検証実施 2

目次 １．導入 (GCPNEXとは、検証目的/内容) ２．技術要素 (NCC、PSC、Cloud Load Balancing) ３．検証手順/結果 ４．まとめ ※本資料に登場する会社名・製品・サービス名、ロゴマークなどは該当する各社の商号・商標または登録商標です。 3

1-1.導入 GCPNEXとは 概要 GCPNEX(※1)とは、Google Cloud Platform(※2)社外接続基盤として、他社Google Cloud環境やSaaS環境を収容するための、Google Cloud上に構築するネットワーク基盤 である。今回の検証にてサービス立ち上げのシミュレーションを兼ね仮のサービスとして構築する。 (※1)GCPNEXはGoogle Cloud Platform infrastructure for External Serviceの造語 (※2)Google Cloud Platformは過去の名称であり、現在(2026年)はGoogle Cloudと名称が統一されている。 4

1-2.導入 検証目的/内容 目的 Google Cloudの活用を進めていくうえで、他社Google Cloud環境や他対外接続先とのネ ットワーク接続を容易に行うためのネットワーク接続サービスが必要となることが予見される。 NIDでは、AWSにおいてはすでに対外接続ネットワークハブとしての構成パターンを確立できて いることから、同様の要件をGoogle Cloud環境でも実現できることを検証する。 内容 現在AWS対外接続ネットワークハブには複数の接続パターンが存在するが、今回は最も基本 となる2つの接続パターン(※1)についてGoogle Cloud環境で検証を行う。 (※1)ハブとなるNWサービスに外部Google Cloud環境を他のサービスを介さず直接収容する接続方式①と、宛先NATを実現するための 接続方式②を検証。②については、Private IPアドレスで通信をする制約上、外部Google Cloud環境側で自社側が指定するIPアドレス を利用することができない場合に採用する接続方式。 5

2-1.技術要素 NCC 正式名称：Network Connectivity Center 機能：オンプレミス、Google Cloud、その他クラウドネットワークとの接続をスポークという単位 で一元管理することができる。 AWSのTransit Gatewayに類似したGoogle Cloudのサービス スポークとして登録できるリソース： ①VPCネットワーク ②VPNトンネル ③VLANアタッチメント ④Routerアプライアンス 6

2-1.技術要素 NCC 利用例： 引用元：https://cloud.google.com/network-connectivity-center#use-cases 7

• https://cloud.google.com/network-connectivity-center#use-cases

2-1.技術要素 NCC AWS Transit Gatewayとの類似点/相違点 類似点： ①複数のネットワークを接続し、一元管理することができる。 ②VPCの他にハイブリットクラウド実現のためのVPN接続や専用線接続もリソースとして登録が可能。 相違点： AWS Transit Gatewayと異なり、ルートテーブルは全てのリソースで共有している。 AWS Transit Gatewayはルートテーブルにアタッチメントを紐づけることで複雑なルート制御を行うことができるが、 NCCはルートテーブルが全てのリソースで共有されるため一部のリソース間のみの通信を許可する等のルート制御は行えな い。 8

2-2.技術要素 PSC 正式名称：Private Service Connect 機能：サービス利用者がVPCネットワーク内からマネージドサービスにプライベート接続でアクセスをす ることを可能にする。 AWSのPrivateLinkに類似したGoogle Cloudのサービス 使用できるサービスの種類： ①Googleの公開サービス ②PSCパートナーが提供するサードパーティの公開サービス ③組織内の公開サービス 今回の検証では③のサービスへのアクセスとなる。 9

2-2.技術要素 PSC 仕組み図： 参照：https://cloud.google.com/vpc/docs/private-service-connect?hl=ja 10

• https://cloud.google.com/vpc/docs/private-service-connect?hl=ja

2-2.技術要素 PSC 仕組み： Consumer VPCにあるClientsから、Producer VPCにあるServiceにアクセスするには PSC EndpointにアクセスすることでServiceにアクセスすることができる。このサービスによる宛 先NATの実現により、Clientsから見た場合、PSCエンドポイントがServiceであるかのように 認識する。 (PSCエンドポイントを意識する必要がない。) 11

2-2.技術要素 PSC PrivateLinkとの類似点/相違点 類似点： ①宛先NATの実現が可能 ②サービスの公開が必要となる。 相違点： PSCはサービスアタッチメントの作成が必要 サービスアタッチメントは、サービス公開の際に必要となり、１つのサービスにつき１つのサービスアタッチメントを作 成する必要がある。なお、サービスアタッチメントの作成には、サービスアタッチメント専用のサブネットを作成する必 要がある。 12

2-3.技術要素 Cloud Load Balancing AWS Network Load Balancerとの違い 主な違いとしては、バックエンド・ターゲットグループの指定方法である。 ①AWSのNLBのターゲットグループはIPアドレスベースで指定を行うが、 CLBのバックエンドはVM単位での指定となる。 ②NLBは異なるネットワークのIPアドレスを指定することができる。一方 で、CLBは異なるVPCにあるVMを指定することはできない。 ③NLBはIPアドレスベースの指定になるので、VPCではなくても、ルート が確立されていれば選択が可能。一方で、CLBはGoogle Cloud CLBと同じVPCに属しているVMのみ指定できる。 13

3-1. パターン①概要 他社サービスのAWS環境を収容する際に利用する主力パターンであり、NWハブサービスと他 アカウントのVPCを直接収容する。 自社で払い出したネットワークアドレスを利用できる場合に利用する。 AWSにおいては、NWハブの役割を担うTransit Gatewayと同一リージョンにある自社他社 問わずすべてのAWSアカウントを収容することが可能。 Google Cloudでも同様にNWハブの役割を担う、NCCを利用し、NCCに直接他アカウント のVPCを収容する。 AWSでの構成イメージ Transit Gateway 他社AWS環境 14

3-2. パターン①構成図 NCC 自社側 自社管理 VPC VPC Region VPC VPC Region Region Subnet(10.0.0.0/24) 接続先B 接続先A Subnet(10.0.1.0/24) Region Subnet(10.0.2.0/2 Subnet(10.0.3.0/2 4) 4) VPN 10.0.0.2 10.0.1.3 10.0.2.2 10.0.3.2 15

3-3. パターン①構築 VPC/サブネットパラメータ 16

3-3. パターン①構築 VMパラメータ 17

3-3. パターン①構築 Cloud VPN Gatewayパラメータ オンプレミス想定VPN Gateway GCP側VPN Gateway 18

3-3. パターン①構築 CloudRouterパラメータ 19

3-3. パターン①構築 NCCパラメータ ポリシーモードは以下の2種類から選択できるが、 VPC以外のリソースをスポークとして登録するには「メッシュト ポロジ」を選択する必要がある。 ・メッシュトポロジ ・スタートポロジ 20

3-3. パターン①構築 接続確認 前提：各VPCのFWは0.0.0.0/0でicmpを許可している。 観点：NCCによる接続の実現可否を確認する。 オンプレ(※1)想定VM→接続先Aへの疎通確認 オンプレ想定VM→接続先Bへの疎通確認 (※1)オンプレミスの略称 接続先A→オンプレ想定VMへの疎通確認 接続先A→接続先Bへの疎通確認 オンプレ想定VM 10.0.0.2 接続先A 10.0.2.2 接続先B 10.0.3.2 接続先B→オンプレ想定VMへの疎通確認 接続先B→接続先Aへの疎通確認 21

3-3. パターン①構築 接続確認 前提：接続先A,BのFWはオンプレ想定VMからのicmpを許可している。 観点：FW設定による通信の制限可否を確認する。 オンプレ想定VMは接続先A,Bと疎通でき、接続先A,B間の通信は拒否する。 オンプレ想定VM→接続先Aへの疎通確認 オンプレ想定VM→接続先Bへの疎通確認 接続先A→オンプレ想定VMへの疎通確認 接続先A→接続先Bへの疎通確認 オンプレ想定VM 10.0.0.2 接続先A 10.0.2.2 接続先B 10.0.3.2 接続先B→オンプレ想定VMへの疎通確認 接続先B→接続先Aへの疎通確認 22

3-4. パターン①検証結果 検証結果 NCCを利用してオンプレミスを想定した環境から接続先に接続することは可能。 ただしVPC以外のリソースをNCCに接続する場合はフルメッシュ接続の構成以外対応していないため、 柔軟なルート制御を行いたい場合は利用例のようにRouterアプライアンスを構築する必要がある。 懸念点 ①NCCのルートテーブルはユーザ側でカスタマイズすることができないため、通信制御はVPCのFWで行う必要があり、 自社側で一元管理できない。 ②検証結果に記載したとおり、柔軟なルート制御を行うにはRouterアプライアンスを構築する必要があるため、 維持・管理コストが高くなる。 23

3-5. パターン②概要 他社サービスのAWS環境を収容する際に利用する主力パターン。 自社が払い出したネットワークアドレスが他社環境で利用できない場合(※1)に選択する。 VPC ピアリングによる接続のため接続先リージョンの制約はなく、自社他社問わずすべてのAWSアカ ウントの収容が可能。 AWSでの構成イメージ Transit Gateway VPC(自社環境) VPC(自社環境) PrivateLink Endpoint NLB NLB PrivateLink Endpoint 他社AWS環境 (※1)自社が払い出したネットワークアドレス(プライベートIPアドレス)を既に他社環境で利用している場合などが他社環境で利用できないケースに該当する。

3-6. パターン②構成図 自社側 自社管理 接続先 25

3-7. パターン②構築 VPC/サブネットパラメータ リソース名 CIDR tc209-subnet11 10.0.2.0/24 tc209-subnet12 10.0.1.0/24 FWルールに関しては、バックエンドVMがあるVPCにはヘルスチェックを許可するルールを追加。 26

3-7. パターン②構築 VMパラメータ インスタンス名 IPアドレス tc209-instance10-test 10.0.1.50 tc209-instance12-test 10.0.1.50 27

3-7. パターン②構築 CLBパラメータ リソース名 対象VM tc209-instancegroup12 tc209-instance12-test 28

3-7. パターン②構築 NCCハブパラメータ NCCハブの作成時のPSC接 続の伝播をオンにする必要が ある。 29

3-7. パターン②構築 NCCスポークパラメータ 30

3-7. パターン②構築 PSC公開サービスパラメータ 右記キャプチャからNATが適用できて いることが確認できる。 なお、サブネットはサービスアタッチメン ト専用のサブネットで設定している。 31

3-7. パターン②構築 PSCエンドポイントパラメータ エンドポイントのIPを確認した結果、 エンドポイントが位置しているサブネッ トが想定とおりであることを確認。 32

3-7. パターン②構築 apacheファイル内容変更 通信が実際にできているのかを確認 するために、バックエンドVMにある、 Apacheのindex.htmlファイルの title部分を編集 33

3-7. パターン②構築 接続確認 ｃ ANA側想定のVPCに立ててあるVM から、PSCのエンドポイントのIPでを指 定し、curlコマンドで接続を確認した。 先ほど編集したtitleの部分が出力さ れたので、接続はできていることが判 明した。 34

3-8. パターン②検証結果 検証結果 接続先にCLBを作成を依頼することで宛先NATの実現自体は可能だが、宛先がGoogle Cloud 環境のVM(※1)に限定されるため、オンプレミスや他社クラウド環境への通信はマネージドサービスのみ では不可能。 懸念点 ①CLBのバックエンドの仕様により、相手側にCLBを作成してもらうため、こちら側がCLBを管理することはできない。 ②CLBのバックエンドにはGoogle Cloudのインスタンスグループのみが指定可能であるため、接続先から自社への通信の際に、接続先は自社のGoogle Cloud環境内のバックエンドVMのデータのみが確認でき、自社の他システムへの通信はマネジメントサービスのみでは不可能。 →バックエンドVMに転送ルールやプロキシの設定を別途行うことで理論上は通信可能となる。 (※1)VMは仮想マシン(Virtual Machine)の略。また、本システムの収容先はGoogle Cloud環境のVPCなどもあり、VMに限定される利用用途は要件を完全に満たすことができない(柔軟性に欠ける)ため、 不可能と判断。 35

4-1. まとめ 所感 ● 今回のサービス検証・シミュレーションによりGCPNEX(仮称)というサービスを立ち上げる際の勘 所・制約について組織のノウハウとして蓄積することができた。 ● Google CloudはAWSとは違い、シンプルな構成であれば簡単に構築等はできるものの、現 在AWS対外接続ネットワークハブで行っているような複雑な設定に関しては、実現が難しい。 ● NCCについては2021年にリリースされたサービスであり、今後のアップデートによっては、複雑な 設定にも対応できるようになる可能性は十分にあると考えられる。 ● 今後の検証項目として、VMにIP Forwardの設定やプロキシの設定を入れることにより、CLB を相手側に作成させずとも、宛先NATの実現可否などの検証を実施することが、今後 GCPNEXを商用サービスとして構築し、提供する場合は必要となる。 36