AWSとココが違う！Google Cloudでの宛先NATとNW制御
このエンジニアブログでは、Google Cloud上で社外接続基盤を構築する際に必要となる宛先NATとNW制御について、AWSとの違いを含めて検証内容を整理します。
今回の検証は、今後の案件での実運用に向け、事前にナレッジを蓄積することを目的として、社内の若手メンバー（当時1年目）が2024年8月～10月にかけて実施しました。
はじめに
今回はサービス立ち上げのシミュレーションを兼ね、「GCPNEX」と称した仮サービスを構築し、検証をおこないました。GCPNEXは、Google Cloud社外接続基盤として、他社Google Cloud環境やSaaS環境を収容するための、Google Cloud上に構築するネットワーク基盤を指します。
※本記事はスライドの記載内容をもとに、検証の要点を簡潔にまとめています。詳細な検証内容や技術的な説明は埋め込みのスライド本文をご参照ください。
検証の目的
今後Google Cloudの活用を進めていくうえで、他社Google Cloud環境や他対外接続先とのネットワーク接続を容易におこなうためのネットワーク接続サービスが必要となることが予見されます。
エヌアイデイでは、AWSにおいてはすでに対外接続ネットワークハブとしての構成パターンを確立できていることから、同様の要件をGoogle Cloud環境でも実現するための検証をおこないました。
本検証におけるおもな技術要素
NCC（Network Connectivity Center）
オンプレミス、Google Cloud、その他クラウドネットワークとの接続をスポークという単位で一元管理できます。AWSのTransit Gatewayに類似したGoogle Cloudのサービスです。
AWS Transit Gatewayとの類似点：
複数のネットワークを接続し、一元管理することができる。VPCの他にハイブリットクラウド実現のためのVPN接続や専用線接続もリソースとして登録が可能。AWS Transit Gatewayとの相違点：
ルートテーブルはすべてのリソースで共有されるため、一部のリソース間のみの通信を許可するなどのルート制御はおこなえない。
PSC（Private Service Connect）
サービス利用者がVPCネットワーク内からマネージドサービスにプライベート接続でアクセスできるようにします。AWSのPrivateLinkに類似したGoogle Cloudのサービスです。
PrivateLinkとの類似点：
宛先NATの実現が可能。サービスの公開が必要となる。PrivateLinkとの相違点：
PSCはサービスアタッチメントの作成が必要であり、一つのサービスにつき一つのサービスアタッチメントを作成し、専用サブネットも必要となる。
Cloud Load Balancing（CLB）
Google Cloudにおけるロードバランサのサービスです。Google CloudはAWSよりもロードバランサの種類が多く、AWSのNetwork Load Balancer（NLB）と比較した場合、おもにバックエンド・ターゲットグループの指定方法が異なっています。
検証内容
現在、AWS対外接続ネットワークハブには複数の接続パターンが存在しますが、今回は最も基本となる二つの接続パターンについて、Google Cloud環境で検証をおこないました。
接続パターン①
他社サービスのAWS環境を収容する際に、自社で払い出したネットワークアドレスが利用可能な場合に利用する接続パターンです。
AWSにおいては、NWハブの役割を担うTransit Gatewayと同一リージョンにあるすべてのAWSアカウントを自社/他社を問わずに収容することが可能です。
AWSでの構成イメージ
今回はGoogle Cloud において、NWハブの役割を担うNCCを利用し、NCCに直接他アカウントのVPCの収容を試みました。
Google Cloudでの構成図
接続パターン②
他社サービスのAWS環境を収容する際に、自社が払い出したネットワークアドレスを他社環境で利用できない場合(※1)に選択する接続パターンです。
AWSにおいては、VPC ピアリングによる接続のため接続先リージョンの制約がなく、自社/他社を問わずすべてのAWSアカウントの収容が可能です。
(※1)自社が払い出したネットワークアドレス(プライベートIPアドレス)をすでに他社環境で利用している場合など
AWSでの構成イメージ
Google Cloudでの構成図
検証結果
接続パターン①（NCCで直接収容）の検証結果
結果として、NCCを利用してオンプレミスを想定した環境から接続先に接続することは可能でした。ただし、VPC以外のリソースをNCCに接続する場合はフルメッシュ接続の構成以外に対応していないため、柔軟なルート制御をおこないたい場合はRouterアプライアンスを構築する必要がありました。
また、以下の懸念点があげられました。
NCCのルートテーブルはユーザー側でカスタマイズできないため、通信制御はVPCのFWでおこなう必要があり、自社側で一元管理できない
柔軟なルート制御にはRouterアプライアンスが必要となり、維持・管理コストが高くなる
接続パターン②（PSCで宛先NAT）の検証結果
結果として、接続先にCLBを作成するよう依頼することで宛先NATの実現自体は可能でしたが、宛先がGoogle Cloud環境のVM（※1）に限定されるため、オンプレミスや他社クラウド環境への通信はマネージドサービスのみでは実現できませんでした。
また、以下の懸念点があげられました。
CLBのバックエンドの仕様により、相手側にCLBを作成してもらう必要があり、こちら側でCLBを管理することができない
CLBのバックエンドにはGoogle Cloudのインスタンスグループのみ指定可能であるため、接続先から自社への通信は自社Google Cloud環境内のバックエンドVMのデータのみ確認でき、自社の他システムへの通信はマネージドサービスのみでは実現不可（バックエンドVMに転送ルールやプロキシ設定を別途おこなう場合は、理論上は通信可能）。
（※1）仮想マシンの略。本システムの収容先はGoogle Cloud環境のVPCなどもあり、VMに限定される利用用途は要件を完全に満たすことができない（柔軟性に欠ける）ため、実現不可と判断しました。
まとめ
今回のサービス検証・シミュレーションにより、Google Cloud環境でネットワーク基盤を構築する際のノウハウを蓄積できました。
Google Cloudはシンプルな構成であれば簡単に構築できますが、現在AWS対外接続ネットワークハブでおこなっているような複雑な設定に関しては実現が難しい状況でした。一方で、NCCは2021年にリリースされたサービスであり、今後のアップデートによっては複雑な設定にも対応できるようになる可能性は十分にあると考えられます。
今後の検証項目として、VMにIP Forwardの設定やプロキシの設定を入れることにより、CLBを相手側に作成させず宛先NATを実現する方式などを検討しています。
※本資料に登場する会社名・製品・サービス名、ロゴマークなどは該当する各社の商号・商標または登録商標です。
