Google Distributed Cloud、エアギャップ環境でパブリック クラウドのようなネットワーキングを実現

※この投稿は米国時間 2026 年 2 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

規制の厳しい業界の組織では、エアギャップ環境の厳格なセキュリティと、クラウドが持つアジリティや柔軟性に対するニーズとのバランスを取ることに苦労することが少なくありません。これに対処するため、Google Distributed Cloud（GDC）エアギャップ 1.15 では、セキュリティ ポスチャーを損なうことなくより直接的な制御と可視性を実現する、新しいネットワーキング機能がプレビュー版で導入されました。また、サブネット管理を簡素化する新しい IPAM 機能も一般提供されました。今回プレビュー版で提供される機能は、Cloud NAT、標準クラスタの接続性の強化、ロードバランサでの高度な HTTP および HTTPS ヘルスチェックです。これらを組み合わせて使うことで、複雑なワークロードを安全な環境で簡単に管理できます。

Cloud NAT でアウトバウンド トラフィックを管理する

GDC エアギャップ用の Cloud NAT は、以前の外向きソリューションに代わるもので、インスタンスと他のネットワークとの通信を、パブリック クラウドの機能と同等に制御できます。Cloud NAT には、以下のような利点があります。

• 構成可能な外向き IP: 外向きトラフィックに複数の外向き IP アドレスを割り当てて管理できるため、通信しているワークロードを正確に特定できます。

• カスタマイズ可能なタイムアウト: さまざまな種類のトラフィックのタイムアウトを調整して、接続のライフサイクルを管理できます。

• きめ細かな制御: 管理者は、外向き IP 用に特定のサブネットを作成できます。一方、アプリケーション オペレーターは、Pod と VM によるトラフィックのルーティング方法を定義できます。

標準クラスタを組織に直接接続する

安全な環境で、分離によりサイロが分断されることがあってはなりません。最新リリースでは、標準クラスタのネットワーキング機能が更新され、セキュリティ境界を厳格に維持しながら組織全体で通信することが可能となり、環境をより効率的に管理できるようになりました。主な更新内容は以下のとおりです。

• Pod の直接通信: 標準クラスタの Pod が、組織のデフォルト VPC 内のワークロードと直接通信できるようになりました。これにより、標準クラスタと共有クラスタの接続が簡素化されます。

• 柔軟なファイアウォール ポリシー: Project Network Policy API と Kubernetes Network Policy API を使用して、Pod やノードを出入りするトラフィックに詳細なルールを設定できます。

• マネージド ロード バランシング: 標準の Kubernetes Service API を使用して内部ロードバランサと外部ロードバランサを作成できます。一方、基盤となる構成は GDC で管理します。

標準クラスタ内の Pod は、直接または ClusterIP を介して他の Pod に接続できるようになりました。インフラ VPC へのトラフィックは引き続きブロックされますが、共有クラスタ ワークロードには GDC 内部ロードバランサを介してトラフィックを送信できます。これにより、アプリケーションは必要なサービスに迅速にアクセスできるようになります。

ロードバランサの HTTP および HTTPS ヘルスチェックで信頼性を向上させる

これまでの L4 ロード バランシングのヘルスチェックでは、基本的な TCP 接続のみをモニタリングし、ポートが開いているかどうかのみを確認していました。このたび、GDC エアギャップのロードバランサが HTTP および HTTPS ヘルスチェックに対応したため、アプリケーションが実際に正しく機能しているかどうかを確認できるようになりました。ステータス コードと応答の内容を確認することで、以下のことが可能になります。

• アプリケーションの健全性の確認: サーバーの電源が入っていることだけでなく、サービスが正しく応答していることを確認します。

• 信頼性の向上: 内部エラーが発生しているアプリケーションのトラフィックを自動的に検出して別経路にルーティングします。

• 可視性の向上: VM ベースのワークロードの健全性に関する、より有益なデータにアクセスし、問題が発生する前にパフォーマンスを管理します。

サブネット グループを使用してサブネット管理を容易にする

従来、子サブネットは 1 つの親サブネットしか参照できませんでした。サブネット グループの導入により、子サブネットは複数の親サブネットを含むサブネット グループを参照できるようになりました。この方法には、以下のような利点があります。

• 変更できないサブネット CIDR の課題を克服: サブネット CIDR の範囲は変更できませんが、サブネット グループを使用すると、新しいサブネットをサブネット グループに加えることで、IP リソースのスケールアップを簡素化できます。単一の親サブネットではなくサブネット グループを参照すると、簡単にスケールアップできます。

• 親サブネットを自動的に特定: サブネット グループを、単一のサブネットとしてではなく、親として参照できるようになりました。サブネット グループをこのように使用すると、利用可能な IP リソースを持つ親サブネットを手動で特定する必要がなくなります。その代わりに、利用可能な IP スペースが十分にあるサブネット グループ内のサブネットが、GDC IPAM により親として自動的に検出されます。

• より小さな CIDR から始めて計画をより容易に: サブネット グループを使用して IP リソースをスケールするということは、新しい親サブネットを作成する際、より小規模で不連続な CIDR から始められるということでもあります。これにより、IP リソースをより効率的に使用できるようになり、計画プロセスがより容易になります。

使ってみる

これらの機能の詳細については、ドキュメントを参照するか、Google Cloud のアカウント担当者にお問い合わせください。

- プロダクト マネージャー、Michael Yitayew

- プロダクト マネージャー、Philip Bai