Google Cloudのネットワーク設計をシンプルにする2つの新機能 ― Ambient NetworkingとHybrid Subnets


Google Cloudのネットワークは、使う範囲が広がるほど考えることも増えていきます。

GKEやCloud Runで複数のサービスを動かせば、サービス同士をどうつなぎ、どこまで通信を許すかを決めることになります。オンプレミスからGoogle Cloudへシステムを移すときは、IPアドレスの変更が重い作業になりがちです。

Google Cloud Next '26では、この別々の悩みに対する新しい選択肢として、Ambient NetworkingとHybrid Subnetsが紹介されました。

名前が並んで出てくるので同じ仕組みに見えますが、別ものです。前者はクラウド上のサービス間接続、後者はオンプレミスからの移行を対象にしています。

この記事では設定方法ではなく、それぞれ何が楽になるのかに絞って見ていきます。

著者：佐藤 浩
所属：ソリューション事業本部 インフラ事業部 インフラ イノベーション部
公開日：2026年9月18日

1. 2つの機能は別の問題を解決する

先に、扱う場所の違いをはっきりさせておきます。

Ambient Networkingが相手にするのは、Google Kubernetes Engine（GKE）やCloud Runで動くサービス同士の通信です。サービスを細かく分けるほど、相手をどう見つけ、どこまで許可し、どう振り分けるかを決める場所が増えていきます。

Hybrid Subnetsが相手にするのは、オンプレミスとGoogle Cloudをまたぐ移行時のIPアドレスです。いま使っているアドレスを変えずに、少しずつ移していけるようにします。

左はGKEやCloud Runで動くサービス同士の接続を扱うAmbient Networking、右はオンプレミスからGoogle Cloudへの移行を扱うHybrid Subnets。下部に解決する問題は別、と示した図。

図1　2つの機能は解決する場所が違う

どちらもネットワークをシンプルにする方向ですが、効く場所が違います。片方を入れればもう片方の悩みも消える、という関係ではありません。

同じ発表の中で並んで紹介されたこと、名前だけでは対象が読み取りにくいことから、まとめて理解してしまいがちです。最初にここを分けておくと、後の判断が楽になります。

2. Ambient Networkingでサービス間接続をシンプルにする

アプリケーションを複数のサービスに分けると、その間をつなぐ仕組みも増えます。

これまでのサービスメッシュでは、各ワークロードの隣にsidecar proxyを置く構成がよく使われてきました。細かい制御ができる代わりに、プロキシの分だけリソースを使い、バージョンや設定の管理も付いてきます。

左はサービスごとにsidecarが付き接続線が絡み合っている従来の構成、右はサービスの下に共通データプレーンが1本あり接続がそこにまとまっている構成。下部に各サービスが持つから基盤が持つへ、と示した図。

図2　サービス間接続の仕組みを基盤側へ寄せる

Ambient Networkingは、GKEとCloud Run向けの統合データプレーンとして、サービス発見、ゼロトラストのアクセス制御、トラフィック制御をまとめて提供するものです。公式の説明では、sidecar proxyを置かずにこれらを扱えること、GKEのL4メッシュ機能でリソース使用量を最大10分の1まで減らせることが挙げられています。

言葉を置き換えると、通信先をどう見つけるか、通信してよい相手かをどう確かめるか、通信をどう振り分けるか、の3つです。サービスが増えるほど、この3つをどこで面倒を見るかが効いてきます。

気をつけたいのは、これで設計がいらなくなるわけではない点です。どのサービスがどこへ通信してよいかを決める作業は残ります。変わるのは、その仕組みを各アプリケーションが個別に抱えるのか、プラットフォーム側へ寄せるのか、という置き場所です。

現時点ではプレビューで、GKEクラスタ側に有効化するための設定が用意されています。

3. Service Bindingsで「接続」を意識しすぎない

Ambient Networkingを土台にした機能として、Service Bindingsも発表されています。

考え方は単純です。サービスAからサービスBを使いたいときに、アドレスや経路の細かい話を毎回持ち出すのではなく、「このサービスから、このサービスを使う」という関係そのものを設定します。

ネットワーク担当者だけでなく、アプリケーションを書く人にも分かる形へ近づける方向です。

ただし、Cloud Run向けの公式ブログでは「coming soon」と書かれています。使える機能として計画へ組み込むのは、提供状況を確かめてからにしてください。

4. Hybrid Subnetsは移行時のIP変更を減らす

ここからは移行の話です。

オンプレミスからGoogle Cloudへ移すとき、思ったより重くなるのがIPアドレスの変更です。アプリケーションの設定ファイルだけでなく、ファイアウォールのルール、接続先の許可リスト、監視の設定、他システムからの参照など、アドレスはあちこちに書かれています。全部を洗い出して同時に切り替えるのは、それだけで大きな仕事になります。

Hybrid Subnetsは、オンプレミス側とVPC側で同じCIDRを共有できるようにします。VPCのサブネットでhybrid subnet routingを有効にすると、そのアドレス帯のうちクラウド側に存在しないアドレス宛のパケットは、オンプレミス側へ送られます。

オンプレミスとGoogle Cloud VPCが同じCIDRを共有し、3台のVMがステップ1では3台ともオンプレミス、ステップ2では1台がクラウド、ステップ3では3台ともクラウドへ移る様子を示した図。下部にIPを変えずに移せる、と示している。

図3　同じCIDRを保ったまま少しずつ移行する

たとえば同じアドレス帯で動く3台のうち1台だけをCompute Engine（GCE）へ移し、残り2台はオンプレミスに置いたままにする。この状態でも、内部IPアドレスのまま両側が通信できます。移したVMのアドレスは、Cloud Routerの広報へ順に足していく形です。

一度に全部を切り替えず、同じアドレスのまま少しずつ移せる。ここがHybrid Subnetsの効きどころです。切り戻しの判断もしやすくなります。まとめて移した後に問題が出るより、1台ずつ確かめながら進める方が影響を抑えられます。

移行が終わったら、hybrid subnet routingを無効にして通常のルーティングへ戻します。移行の期間だけ使う仕組み、という点も押さえておくとよいと思います。

5. Hybrid Subnetsだけで接続できるわけではない

誤解しやすいところなので、具体的に書いておきます。

Hybrid Subnetsは、オンプレミスとGoogle Cloudをつなぐ回線ではありません。

接続はCloud VPNなど、同じCIDRの共有はHybrid Subnets、VMの移動は移行ツールと、3つの役割がプラス記号で並んでいる図。下部に3つそろって成り立つ、と示している。

図4　接続、同じCIDR、移行はそれぞれ別の役割

先にHA VPNのトンネル、またはDedicated / Partner InterconnectのVLANアタッチメントで両者をつないでおくことが前提です。Cloud Routerも要ります。しかも、これらとhybrid subnet routingを有効にするサブネットは同じリージョンに置く、という条件が付きます。

VMそのものを運ぶ手段も別に用意します。Migrate to Virtual Machinesのドキュメントにも、Hybrid Subnetsを使った段階移行の手順が載っています。

つまりHybrid Subnetsは、移行の期間中だけ同じCIDRを両側で扱えるようにするネットワーク側の仕組みです。回線と移行の手段と組み合わせて、はじめて成立します。

6. どちらも「複雑さを置く場所」を変える

2つを並べてみます。

Ambient Networkingは、サービス間接続の仕組みを各アプリケーションからプラットフォーム側へ移します。アプリケーションを書く人が、通信の作り込みを毎回抱えずに済む方向です。

Hybrid Subnetsは、移行のときだけ発生するIPアドレス変更という負担を、そもそも起こさないようにします。

解決する問題は別ですが、向いている方向は似ています。ネットワークの細かい部分を、使う側が毎回すべて把握しなくてもよい形へ寄せていく。この点は共通しています。

7. まとめ

Google Cloudのネットワーク設計を、新しい機能ですべて置き換える話ではありません。

Ambient Networkingは、GKEやCloud Runで動くサービス同士の通信を整理する選択肢です。プレビュー段階なので、まずは試して確かめる位置付けになります。

Hybrid Subnetsは、オンプレミスからの移行でIPアドレス変更を減らす選択肢です。VPCのリリースノートでは2026年4月にGAとなっています。

どちらを見るかは、今の構成のどこが重いかで決まります。サービス間の通信設定が積み上がっているのか、それとも移行のたびにアドレスの棚卸しで止まるのか。複雑になっている場所を先に見つけて、そこに効く仕組みを選ぶ。順番としては、こちらが先です。

参考情報