このドキュメントは、Cross-Cloud Network の設計ガイドシリーズの一部です。
このシリーズは、次のパートで構成されています。
- 分散アプリケーション向けの Cross-Cloud Network
- Cross-Cloud Network の分散アプリケーションのネットワーク セグメンテーションと接続（このドキュメント）
- Cross-Cloud Network の分散アプリケーションのネットワーク セキュリティ
このパートでは、設計の基礎となるネットワーク セグメンテーションの構造と接続性について説明します。このドキュメントでは、次の選択を行うフェーズについて説明します。
- 全体のネットワーク セグメンテーションとプロジェクト構造。
- ワークロードの配置場所。
- 接続、ルーティング、暗号化の設計など、プロジェクトを外部のオンプレミス ネットワークや他のクラウド プロバイダ ネットワークに接続する方法。
- VPC ネットワークが内部で相互に接続される方法。
- サービス到達可能性と DNS の設定方法など、Google Cloud VPC サブネットが相互に接続され、他のネットワークに接続される方法。
ネットワーク セグメンテーションとプロジェクト構造
計画フェーズでは、次のいずれかのプロジェクト構造を選択する必要があります。
- 統合されたインフラストラクチャ ホスト プロジェクト。1 つのインフラストラクチャ ホスト プロジェクトを使用して、すべてのアプリケーションのネットワーク リソースを管理します。
- セグメント化されたホスト プロジェクト。インフラストラクチャ ホスト プロジェクトのほかに、アプリケーションごとに異なるホスト プロジェクトを使用します。
計画フェーズでは、ワークロード環境の管理ドメインも決定することをおすすめします。最小権限の原則に基づいてインフラストラクチャ管理者とデベロッパーの権限の範囲を設定します。また、アプリケーション プロジェクト別にアプリケーション リソースの範囲を設定します。インフラストラクチャ管理者はリソース共有の接続を確立する必要があるため、インフラストラクチャ リソースはインフラストラクチャ プロジェクト内で処理される場合があります。たとえば、共有のインフラストラクチャ リソースへの接続を確立するため、インフラストラクチャ管理者はインフラストラクチャ プロジェクトを使用して共有リソースを処理できます。また、開発チームと本番環境チームがワークロードの管理に別々のプロジェクトを使用する場合もあります。デベロッパーは、インフラストラクチャ プロジェクトのインフラストラクチャ リソースを使用して、ワークロードのリソース、サービス、ロード バランシング、DNS ルーティング ポリシーを作成し、管理します。
また、最初に実装する VPC ネットワークの数と、それらをリソース階層にどのように編成するかも決定する必要があります。リソース階層の選択方法の詳細については、Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。VPC ネットワークの数を選択する方法の詳細については、複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。
Cross-Cloud Network の場合、次の VPC を使用することをおすすめします。
- 異なるアプリケーションのリソースをホストする 1 つ以上のアプリケーション VPC。
- すべての外部接続が処理されるトランジット VPC。
- オプションの中央サービス VPC。公開サービスへのプライベート アクセスのデプロイを統合するために使用できます。
次の図は、前述の VPC の推奨構造を視覚的に表したものです。図に示す VPC 構造は、後のセクションで説明するように、統合された構造またはセグメント化された構造で使用できます。ここで示す図には、VPC ネットワーク間の接続を示していません。
統合されたインフラストラクチャ ホスト プロジェクト
統合されたインフラストラクチャ ホスト プロジェクトを使用すると、サブネット、ピアリング、ロードバランサなど、すべてのネットワーク リソースを管理できます。
インフラストラクチャ ホスト プロジェクトには、組織の構造に合わせて、対応するアプリケーション サービス プロジェクトを含む複数のアプリケーション共有 VPC を作成できます。複数のアプリケーション サービス プロジェクトを使用してリソース管理を委任します。すべてのアプリケーション VPC のすべてのネットワーキングの料金は、統合されたインフラストラクチャ ホスト プロジェクトに請求されます。
このプロジェクト構造の場合、多くのアプリケーション サービス プロジェクトでは、共有するアプリケーション VPC の数が少なくなります。
次の図は、統合されたインフラストラクチャ ホスト プロジェクトと、前述の複数のアプリケーション サービス プロジェクトを示しています。この図には、すべてのプロジェクト間の接続は示されていません。
分割されたホスト プロジェクト
このパターンでは、アプリケーションのグループごとに独自のアプリケーション ホスト プロジェクトと VPC が存在します。ホスト プロジェクトには複数のアプリケーション サービス プロジェクトを関連付けることができます。ネットワーク サービスの料金は、インフラストラクチャ ホスト プロジェクトとアプリケーション ホスト プロジェクトの間で分割されます。インフラストラクチャの料金は、インフラストラクチャ ホスト プロジェクトに請求されます。また、アプリケーションのネットワーク料金はそれぞれのアプリケーション ホスト プロジェクトに請求されます。
次の図は、前述の複数のホスト プロジェクトと複数のアプリケーション サービス プロジェクトを視覚的に表したものです。この図には、すべてのプロジェクト間の接続は示されていません。
ワークロードの配置
どの接続方法を選択するのかは、ワークロードのリージョン ロケーションによって異なります。ワークロードの配置に関するガイダンスについては、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。接続のロケーションを選択する前に、ワークロードの配置場所を決める必要があります。
外部接続とハイブリッド接続
このセクションでは、次の接続パスの要件と推奨事項について説明します。
- 他のクラウド プロバイダへのプライベート接続
- オンプレミス データセンターへのプライベート接続
- ワークロードのインターネット接続（特にアウトバウンド接続）
Cross-Cloud Network では、複数のクラウド ネットワークまたはオンプレミス ネットワークの相互接続が行われます。外部ネットワークは、異なる組織で所有され、管理されていることがあります。これらのネットワークは、1 つ以上のネットワーク間インターフェース（NNI）で物理的に接続されています。NNI の組み合わせは、パフォーマンス、復元力、プライバシー、セキュリティに合わせて、設計、プロビジョニング、構成を行う要があります。
モジュール性、再利用性、セキュリティ NVA の挿入機能を実現にするため、外部接続とルーティングはトランジット VPC に配置する必要があります。この VPC は、他の VPC の共有接続サービスとして機能します。ドメイン間の復元性、フェイルオーバー、パスの設定に関するルーティング ポリシーは、トランジット VPC で 1 回構成するだけで、他の VPC ネットワークで利用できます。
NNI と外部接続の設計は、後で内部接続と VPC ネットワークに使用されます。
次の図は、VPC ネットワーク ピアリング、Network Connectivity Center、または HA VPN で接続されている VPC の共有接続サービスとして機能するトランジット VPC を示しています。
他のクラウド プロバイダへのプライベート接続
他のクラウド サービス プロバイダ（CSP）のネットワークで実行されているサービスを Google Cloud ネットワークに接続する場合は、インターネット経由での接続またはプライベート接続を利用できますが、プライベート接続を使用することをおすすめします。
接続方法を決める際には、スループット、プライバシー、コスト、運用可能性を考慮する必要があります。
プライバシーを強化しながらスループットを最大にしたい場合は、クラウド ネットワーク間を高速接続で直接接続します。直接接続の場合、途中で物理的なネットワーク機器を経由する必要ありません。その場合、Cross-Cloud Interconnect を使用することをおすすめします。このプロダクトでは、このような直接接続だけでなく、MACsec 暗号化、リンクあたり最大 100 Gbps のスループット レートが提供されます。
Cross-Cloud Interconnect を使用できない場合は、コロケーション施設を介して Dedicated Interconnect または Partner Interconnect を使用します。
他の CSP に接続するロケーションは、ターゲット リージョンへの近接性に基づいて選択します。ロケーションを選択する際は、次のことを忘れないでください。
- ロケーションのリストを確認する。
- Cross-Cloud Interconnect の場合は、Google Cloud と CSP の両方で利用可能なロケーションのリストを確認してください（利用可能かどうかはクラウド プロバイダによって異なります）。
- Dedicated Interconnect または Partner Interconnect の場合は、コロケーション施設の低レイテンシ ロケーションを選択します。
- 各 CSP で、特定のポイント オブ プレゼンス（POP）エッジとそれに関連するリージョン間のレイテンシを評価する。
クロスクラウド接続の信頼性を最大限に高めるには、本番環境のワークロードに 99.99% の稼働率 SLA をサポートする構成をおすすめします。詳細については、Cross-Cloud Interconnect の高可用性、Dedicated Interconnect で 99.99% の可用性を実現する、Partner Interconnect で 99.99% の可用性を実現するをご覧ください。
異なる CSP 間で高帯域幅を必要としない場合は、VPN トンネルを使用できます。これは、分散アプリケーションで帯域幅の使用量が増えたときに Cross-Cloud Interconnect にアップグレードする場合に役立ちます。VPN トンネルでも 99.99% の SLA を達成できます。詳細については、HA VPN トポロジをご覧ください。
オンプレミス データセンターへのプライベート接続
プライベート データセンターへの接続には、次のいずれかのハイブリッド接続オプションを使用できます。
- Dedicated Interconnect
- Partner Interconnect
- HA VPN
これらの接続のルーティングに関する考慮事項は、他のクラウド プロバイダへのプライベート接続と同じです。
次の図は、オンプレミス ネットワークへの接続と、オンプレミス ルーターがピアリング ポリシーを介して Cloud Router に接続する方法を示しています。
外部ネットワークを使用したドメイン間ルーティング
ネットワーク間の復元力とスループットを高めるには、ネットワークを複数のパスで接続します。
ネットワーク ドメイン間でトラフィックが転送されるときに、ステートフルなセキュリティ デバイスでトラフィックを検査する必要があります。そのため、ドメイン間の境界でフローの対称性が必要になります。
複数のリージョン間でデータを転送するネットワークの場合、ネットワークによって費用とサービス品質レベルが大きく異なることがあります。また、こうした違いにより、使用するネットワークの優先度が変わる可能性もあります。
リージョン間の転送、トラフィックの対称性、スループット、復元性の要件を満たすように、ドメイン間ルーティング ポリシーを設定します。
ドメイン間ルーティング ポリシーの構成は、各ドメインのエッジで使用できる機能によって異なります。これは、異なるリージョンにまたがる自律システムと IP アドレス指定（サブネット化）の観点から隣接するドメインがどのように構成されているかによっても異なります。エッジデバイスでプレフィックスの上限を超えることなくスケーラビリティを向上させるには、IP アドレス指定プランにより、各リージョンとドメインの組み合わせで集約されるプレフィックスを少なくすることをおすすめします。
リージョン間のルーティングを設計する際は、次の点を考慮してください。
- Google Cloud VPC ネットワークと Cloud Router は、グローバル クロスリージョン ルーティングをサポートしています。他の CSP には、リージョン VPC と Border Gateway Protocol（BGP）スコープが設定されている場合があります。詳しくは、他の CSP のドキュメントをご覧ください。
- Cloud Router は、地域の近接性に基づいて事前に定義されたパスの設定でルートを自動的にアドバタイズします。このルーティング動作は、VPC に構成されている動的ルーティング モードによって異なります。必要なルーティング動作にするために、これらの設定のオーバーライドが必要になる場合があります。
- サポートされる BGP と Bidirectional Forwarding Detection（BFD）機能はどの CSP でも同じというわけではありません。また、BGP セッションを確立するで説明されているように、Google の Cloud Router には特別なルートポリシー機能もあります。
- ルート優先度の指定に使用している BGP タイブレーク属性が CSP によって異なる場合もあります。詳しくは、CSP のドキュメントをご覧ください。
シングル リージョンのドメイン間ルーティング
まず、シングル リージョンのドメイン間ルーティングから始めて、その結果に基づいてマルチ リージョン接続のドメイン間ルーティングを構築することをおすすめします。
Cloud Interconnect を使用する設計では、同じリージョンに存在し、エッジ アベイラビリティ ドメインが異なる接続ロケーションが 2 つ以上必要です。
この重複接続をアクティブ / アクティブで構成するのか、アクティブ / パッシブで構成するのかを決めます。
- アクティブ / アクティブでは、等価コスト マルチパス（ECMP）ルーティングを使用して両方のパスの帯域幅を集約し、ドメイン間トラフィックに同時に使用します。Cloud Interconnect では、LACP 集約リンクを使用して、パスあたり最大 200 Gbps の集約帯域幅を実現することもできます。
- アクティブ / パッシブでは、1 つのリンクをスタンバイ状態にし、アクティブ リンクが中断された場合にのみトラフィックを処理します。
リージョン内のリンクには、アクティブ / アクティブの設計をおすすめします。ただし、ステートフルなセキュリティ機能を使用するオンプレミス ネットワーキング トポロジでは、アクティブ / パッシブ設計が必要になることがあります。
Cloud Router は複数のゾーンにわたってインスタンス化されるため、単一の要素よりも高い復元力を提供します。次の図は、復元力のある接続がリージョン内の単一の Cloud Router に集約される様子を示しています。この設計では、Dedicated Interconnect で 99.9% の可用性を実現するのガイドラインに従って、1 つの大都市圏内で 99.9% の可用性を保証する SLA をサポートできます。
次の図は、1 つのリージョン内のマネージド Cloud Router サービスに冗長接続された 2 つのオンプレミス ルーターを示しています。
マルチリージョンのドメイン間ルーティング
バックアップ接続を実現するため、ネットワークは複数の地理的領域でピアリングできます。複数のリージョンのネットワークを接続することで、可用性 SLA を 99.99% に引き上げることができます。
次の図は、99.99% SLA のアーキテクチャを示しています。2 つの異なるロケーションにあるオンプレミス ルーターが、2 つの異なるリージョンにあるマネージド Cloud Router サービスに冗長接続されています。
マルチ リージョン ルーティングの設計では、復元力のほかに、フローの対称性も実現する必要があります。設計では、リージョン間の通信に使用する優先ネットワークも指定する必要があります。これは、ホットポテト ルーティングとコールドポテト ルーティングで行うことができます。1 つのドメインのコールドポテト ルーティングと、ピアドメインのホットポテト ルーティングをペアにします。コールドポテト ドメインには、グローバル VPC ルーティング機能を提供する Google Cloud ネットワーク ドメインを使用することをおすすめします。
フローの称性は必ずしも必須ではありませんが、これがあると、ステートフルなセキュリティ関数で問題が発生する可能性があります。
次の図は、ホット ポテト ルーティングとコールド ポテト ルーティングを使用して、リージョン間トランジット ネットワークを指定する方法を示しています。この場合、プレフィックス X と Y からのトラフィックは、宛先に最も近いリージョンに到達するまで送信元のネットワーク内に留まります（コールドポテト ルーティング）。プレフィックス A と B からのトラフィックは、送信元リージョンの別のネットワークに切り替わり、別のネットワークを経由して宛先に送信されます（ホットポテト ルーティング）。
ドメイン間トラフィックの暗号化
特に明記されていない限り、異なる CSP 間、または Google Cloud とオンプレミス データセンター間の Cloud Interconnect 接続ではトラフィックは暗号化されません。このトラフィックの暗号化が必要な場合は、次の機能を使用します。
- Cloud Interconnect の MACsec: ルーターと Google のエッジルーター間の Cloud Interconnect 接続を介して転送されるトラフィックを暗号化します。詳細については、Cloud Interconnect の MACsec の概要をご覧ください。
- Cloud Interconnect を介した HA VPN: 複数の HA VPN トンネルを使用することで、基盤となる Cloud Interconnect 接続の帯域幅を最大限活用できます。HA VPN トンネルは IPsec で暗号化され、Cloud Interconnect 接続を介してデプロイされます。この接続は MACsec で暗号化される場合もあります。この構成では、Cloud Interconnect 接続は HA VPN トラフィックのみを許可するように構成されています。詳細については、Cloud Interconnect を介した HA VPN の概要をご覧ください。
ワークロードのインターネット接続
双方向（インバウンドとアウトバウンド）のインターネット接続の場合、返信トラフィックは、元のリクエストの方向と逆向きにステートフルに送信されると想定されています。
一般に、インバウンドのインターネット接続を提供する機能はアウトバウンドのインターネット接続を提供する機能とは別ですが、両方向の接続を同時に提供する外部 IP アドレスは例外です。
インバウンドのインターネット接続
インバウンドのインターネット接続は、主にクラウドでホストされているサービスにパブリック エンドポイントを提供するために使用されます。たとえば、Google Cloud でホストされているウェブ アプリケーション サーバーやゲームサーバーへのインターネット接続などです。
インバウンドのインターネット接続を提供する主な機能は、Google の Cloud Load Balancing プロダクトです。
どのタイプの Cloud Load Balancing にも、VPC の特別なリターンパスを使用するのかユーザー定義のプロキシ サブネットを使用するかに関係なく、インターネット ソースに返されるトラフィック用に独自のパスが用意されています。一般に、VPC の設計は、インバウンドのインターネット接続を提供する機能とは無関係です。
アウトバウンドのインターネット接続
アウトバウンドのインターネット接続（最初のリクエストがワークロードからインターネット宛に発信される場合）の例としては、サードパーティの API にアクセスするワークロード、ソフトウェア パッケージとアップデートのダウンロード、インターネット上の Webhook エンドポイントへのプッシュ通知の送信などがあります。
アウトバウンド接続には、プライベート VM のインターネット接続の構築で説明している Google Cloud の組み込みオプションを使用できます。また、ネットワーク セキュリティで説明しているように、一元化された NGFW NVA を使用することもできます。
アウトバウンドのインターネット接続を提供するメインパスは、VPC ルーティング テーブルのデフォルトのインターネット ゲートウェイの宛先です。これは通常、Google VPC のデフォルト ルートです。外部 IP と Cloud NAT（Google Cloud のマネージド NAT サービス）の両方で、VPC のデフォルト インターネット ゲートウェイを指すルートが必要です。そのため、デフォルト ルートをオーバーライドする VPC ルーティング設計では、他の手段でアウトバウンド接続を提供する必要があります。詳細については、Cloud Router の概要をご覧ください。
アウトバウンド接続を保護するため、Google Cloud では、Cloud Next Generation Firewall と Secure Web Proxy の両方を提供し、HTTP と HTTPS の URL をより詳細にフィルタリングします。ただし、いずれの場合も、トラフィックはデフォルト ルートを経由してデフォルトのインターネット ゲートウェイに送信されるか、VPC ルーティング テーブルのカスタム デフォルト ルートを経由します。
独自の IP の使用
インターネット接続には、Google 所有の IPv4 アドレスを使用できます。また、お客様所有 IP アドレス（BYOIP）を使用して、組織が所有する IPv4 スペースを使用することもできます。インターネット経由で転送可能な IP アドレスを必要とするほとんどの Google Cloud プロダクトは、代わりに BYOIP 範囲を使用します。
IP スペースを独占的に使用することで、IP スペースの評価を管理することもできます。BYOIP は接続の移植性を高め、IP アドレスの費用も節約できます。
内部接続と VPC ネットワーキング
外部接続とハイブリッド接続サービスを構成すると、トランジット VPC のリソースは外部ネットワークに到達できます。次のステップでは、この接続を他の VPC でホストされているリソースで利用できるようにします。
次の図は、外部接続を有効にした方法に関係なく、VPC の一般的な構造を示しています。これは、外部接続を終端し、すべてのリージョンで Cloud Router をホストするトランジット VPC を示しています。各 Cloud Router は、各リージョンの NNI を介して外部ピアからルートを受け取ります。アプリケーション VPC はトランジット VPC に接続されているため、外部接続を共有できます。また、トランジット VPC はスポーク VPC のハブとして機能します。スポーク VPC は、アプリケーション、サービス、またはその両方をホストできます。
また、トランジット VPC で DNS 転送とピアリングを構成します。詳しくは、DNS インフラストラクチャの設計をご覧ください。
パフォーマンスと組み込みのクラウド ネットワーキング サービスを向上させるには、HA VPN ではなく、Cross-Cloud Network または VPC ネットワーク ピアリングを使用して VPC を相互接続することをおすすめします。
Private Service Connect エンドポイントと限定公開サービス アクセス フロントエンドは、VPC ネットワーク ピアリングまたは Cross-Cloud Network 経由でアクセスできません。この制限を回避するには、VPC 間の接続に HA VPN を使用することをおすすめします。VPC 間の接続に HA VPN を使用すると、スループットが低下し、運用上のオーバーヘッドが増加する可能性があるため、一元化されたサービスを設計することで、HA VPN デプロイの範囲を縮小できます。
また、サービス エンドポイントの前に内部プロキシ ネットワーク ロードバランサを配置して、公開されたサービス エンドポイントに対する一時的な接続を VPC 間に実装することもできます。この方法にはいくつかの制限があります。詳しくは、ロード バランシングを使用した Network Connectivity Center スポークとの接続をご覧ください。
以降のセクションでは、ベース IP 接続と API エンドポイントのデプロイをサポートするハイブリッド接続の設計について説明します。
集中型サービスのための VPC 間の接続
公開されたサービス エンドポイントを中央サービス VPC にデプロイできる場合は、アプリケーション VPC を VPC ネットワーク ピアリング経由でハブ（トランジット VPC）に接続し、中央サービス VPC を HA VPN 経由でハブに接続することをおすすめします。
この設計では、トランジット VPC がハブであり、プライベート サービス エンドポイントの転送ルールを中央サービス VPC にデプロイします。中央サービス VPC を共有 VPC ネットワークにし、サービス プロジェクトの管理者が共有ネットワークでサービス エンドポイントを作成できるようにします。
この設計は、次の 2 つの接続タイプを組み合わせたものです。
- VPC ネットワーク ピアリング: ハブ VPC とアプリケーション VPC 間の接続を提供します。
- HA VPN の VPC 間接続: ハブへの中央サービス VPC の一時的な接続を提供します。
これらの接続タイプのデプロイに関する詳細なガイダンスと構成ブループリントについては、ハブアンドスポーク ネットワーク アーキテクチャをご覧ください。
これらのアーキテクチャを組み合わせる際は、次の点を考慮してください。
- VPC ピアサブネットの動的ルーティングへの再分配（HA VPN とハイブリッドへの再分配）
- マルチリージョン ルーティングに関する考慮事項
- VPC ピアリングへの動的ルートの伝播（HA VPN とハイブリッドから）
次の図は、HA VPN を使用してトランジット VPC に接続された中央サービス VPC と、VPC ネットワーク ピアリングを使用してトランジット VPC に接続されたアプリケーション VPC を示しています。
上記の図に示す構造には、次のコンポーネントが含まれています。
- ユーザーの場所: ネットワーク機器があるデータセンターまたはリモート オフィス。この例では、この場所が外部ネットワークを使用して接続されていることを前提としています。
- メトロ: 1 つ以上の Cloud Interconnect エッジ アベイラビリティ ドメインを含む大都市圏。Cloud Interconnect は、このような大都市圏の他のネットワークに接続します。
- ハブ プロジェクト: 他の VPC ネットワークのハブとして機能する VPC ネットワークを 1 つ以上ホストするプロジェクト。
- トランジット VPC: オンプレミスや他の CSP からの接続を受け入れ、他の VPC からオンプレミスや CSP ネットワークへのトランジット パスとして機能するハブ プロジェクト内の VPC ネットワーク。
- アプリホスト プロジェクトと VPC: さまざまなアプリケーションをホストするプロジェクトと VPC ネットワーク。
- サービス VPC: アプリケーション VPC ネットワーク内のアプリケーションが必要とするサービスへのアクセスを集中的にホストする VPC ネットワーク。
- マネージド サービス VPC: 他のエンティティによって提供および管理されるサービス。VPC ネットワークで実行されているアプリケーションからアクセスできます。
ハブアンドスポーク設計では、アプリケーション VPC が相互に通信する必要がある場合に、アプリケーション VPC をスポークとして Network Connectivity Center ハブに接続できます。この方法では、Network Connectivity Center ハブ内のすべての VPC 間の接続が確立されます。通信のサブグループは、複数の Network Connectivity Center ハブを使用して作成できます。特定のハブ内のエンドポイント間で必要な通信の制限は、ファイアウォール ポリシーを使用して実現できます。
ロード バランシングを使用した Network Connectivity Center スポーク VPC との接続
このパターンでは、Network Connectivity Center ハブにすべての VPC をスポークとして含め、最大 250 個の相互接続された VPC を配置できます。Network Connectivity Center ハブは、Network Connectivity Center ハブにスポークとして登録されている VPC ネットワーク間でフルメッシュ データプレーン接続を作成する、管理プレーンのコンストラクトです。このパターンでは、エニーツーエニー接続が提供され、任意の VPC にマネージド サービスをデプロイできるため、中央サービスと分散サービスのどちらを使用するかを決定する必要がなくなります。
推移性の制限を回避するため、マネージド サービスとハイブリッド接続には内部プロキシ ネットワーク ロードバランサを介してアクセスします。East-West 接続のワークロード セキュリティには、Cloud Next Generation Firewall を使用できます。このパターンでは Inter-VPC NAT を使用することもできます。
このパターンにはいくつかの制限があるため、このパターンを採用する前に考慮する必要があります。
- このパターンでは、境界ファイアウォールに NVA を使用できません。境界ファイアウォールは外部ネットワークに残しておく必要があります。
- 外部ネットワークとの間でサポートされるのは TCP トラフィックのみです。この制限は、外部ネットワークへの接続が内部プロキシ ネットワーク ロードバランサを介して実行されるために発生します。
- 公開サービスには、プロキシ ロードバランサに追加のフロントエンドがあります。この追加のフロントエンドにより、DNS に追加されるレコードが増加するため、スプリット DNS ルックアップを必要とします。
- レイヤ 4 サービスでは、新しいサービスごとに新しい内部プロキシ ネットワーク ロードバランサが必要です。接続に必要なプロトコルに応じて、異なるロードバランサが必要になる場合があります。
- ロード バランシングの割り当ては、VPC ネットワークごとに制限されています。これは重要な考慮事項です。レイヤ 4 サービスでは、宛先サービスごとに新しい内部プロキシ ネットワーク ロードバランサが必要になります。
- 選択する高可用性とクロスリージョン フェイルオーバーの設計オプションは、要件によって異なります。
- ハイブリッド境界を越える暗号化されたトラフィックは、証明書管理の調整に影響します。
上記の考慮事項が管理可能で妥協できる場合、または環境に関係ない場合は、このパターンを優先オプションとして使用することをおすすめします。
次の図は、Cloud Interconnect 接続の管理プレーンとして Network Connectivity Center ハイブリッド ハブを示しています。また、アプリケーションとサービス VPC スポークを接続する Network Connectivity Center VPC ハブも表示されています。
推移性のためのプロキシ ロード バランシング
次のものは、Network Connectivity Center スポーク VPC 間で到達できません。
- Private Service Connect サービス エンドポイントとマネージド サービスのフロントエンド
- ハイブリッド接続（Cloud Interconnect または HA VPN）の背後にあるネットワーク。動的ルートは Cross-Cloud Network 経由で伝播されません。
これらの推移の制限は、非推移リソースをハイブリッド ネットワーク エンドポイント グループ（NEG）として処理する内部プロキシ ネットワーク ロードバランサをデプロイすることで回避できます。内部プロキシ ネットワーク ロードバランサは、サービス フロントエンドの前にデプロイできます。また、ハイブリッド接続を介して到達可能なエンドポイントの前にもデプロイできます。内部プロキシ ネットワーク ロードバランサのフロントエンドは、Cross-Cloud Network スポーク VPC 全体に伝播される VPC サブネットにデプロイされます。内部プロキシ ネットワーク ロードバランサは、非推移的リソースの Cross-Cloud Network を介してネットワーク到達性を実現します。外部ホストとサービス、Private Service Connect エンドポイント、限定公開サービスがネットワークにアクセスする場合、バックエンドはハイブリッド NEG として構成する必要があります。Private Service Connect バックエンドは、NEG がハイブリッドである必要がない唯一のモデルです。
DNS インフラストラクチャの設計
ハイブリッド環境では、Cloud DNS または外部（オンプレミスまたは CSP）プロバイダが DNS ルックアップを処理できます。外部 DNS サーバーは外部 DNS ゾーンに対して権威があり、Cloud DNS は Google Cloud ゾーンに対して権威があります。Google Cloud と外部ネットワークの間で DNS 転送を双方向で有効にし、DNS 解決トラフィックを許可するようにファイアウォールを設定する必要があります。
中央サービス VPC に共有 VPC を使用する場合、異なるアプリケーション サービス プロジェクトの管理者が独自のサービスをインスタンス化できるように、DNS ゾーンのプロジェクト間バインディングを使用します。プロジェクト間のバインディングを使用すると、DNS 名前空間を分割してサービス プロジェクト管理者に委任できます。
外部ネットワークが Google Cloud を介して他の外部ネットワークと通信しているトランジットの場合、リクエストを相互に直接転送するように外部 DNS ゾーンを構成する必要があります。Google Cross-Cloud Network は DNS リクエストとレスポンスの接続を完了しますが、Google Cloud DNS は外部ネットワークのゾーン間で DNS 解決トラフィックを転送します。Cross-Cloud Network で適用されるファイアウォール ルールでは、外部ネットワーク間の DNS 解決トラフィックを許可する必要があります。
次の図は、この設計ガイドで提案されているハブアンドスポーク VPC 接続構成で使用できる DNS 設計を示しています。
上の図は、設計フローの次のステップを示しています。
- オンプレミス DNS
オンプレミス DNS ゾーンに対して権威を持つオンプレミス DNS サーバーを構成します。Cloud DNS インバウンド転送 IP アドレスをターゲットとして、Google Cloud DNS 名用に DNS 転送を構成します。この IP アドレスは、ハブ VPC 内のインバウンド サーバー ポリシー構成に従って作成されます。この構成により、オンプレミス ネットワークで Google Cloud DNS 名を解決できます。 - トランジット VPC - DNS 下り（外向き）プロキシ
Cloud Router を使用して、Google DNS 下り（外向き）プロキシ範囲35.199.192.0/19をオンプレミス ネットワークにアドバタイズします。Google からオンプレミスへのアウトバウンド DNS リクエストは、この IP アドレス範囲を送信元とします。 - トランジット VPC - Cloud DNS
- オンプレミスからのインバウンド DNS リクエスト用にインバウンド サーバー ポリシーを構成します。
- オンプレミス DNS サーバーをターゲットとするオンプレミス DNS 名用に Cloud DNS 転送ゾーンを構成します。
- サービス VPC - Cloud DNS
- アプリ ホスト プロジェクト - Cloud DNS
- オンプレミス DNS 名用にアプリ DNS ピアリング ゾーンを構成し、ハブ VPC をピア ネットワークとして設定します。オンプレミス ホストの DNS 解決はハブ VPC 経由で実行されます。
- アプリ ホスト プロジェクトでアプリ DNS 限定公開ゾーンを構成し、アプリケーション VPC、サービス共有 VPC、ハブ VPC をこのゾーンに接続します。この構成により、すべてのホスト（オンプレミスとすべてのサービス プロジェクト内のホスト）がアプリの DNS 名を解決できるようになります。
詳細については、スポーク VPC ネットワークに接続されたハブ VPC ネットワークを使用するハイブリッド アーキテクチャをご覧ください。
次のステップ
- Cross-Cloud Network アプリケーションのネットワーク セキュリティを設計する。
- この設計ガイドで使用する Google Cloud プロダクトの詳細を確認する。
- ファイアウォール NVA のデプロイについて、Google Cloud で一元化されたネットワーク アプライアンスを確認する。
- Cloud アーキテクチャ センターで、その他のリファレンス アーキテクチャ、設計ガイド、ベスト プラクティスを確認する。
寄稿者
作成者:
- Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
- Ghaleb Al-habian | ネットワーク スペシャリスト
- Deepak Michael | ネットワーキング スペシャリスト カスタマー エンジニア
- Osvaldo Costa | ネットワーキング スペシャリスト カスタマー エンジニア
- Jonathan Almaleh | スタッフ テクニカル ソリューション コンサルタント
その他の寄稿者:
- Zach Seils | ネットワーキング スペシャリスト
- Christopher Abraham | ネットワーキング スペシャリスト カスタマー エンジニア
- Emanuele Mazza | ネットワーキング プロダクト スペシャリスト
- Aurélien Legrand | 戦略的クラウド エンジニア
- Eric Yu | ネットワーキング スペシャリスト カスタマー エンジニア
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- Marwan Al Shawi | パートナー カスタマー エンジニア
- Ammett Williams | デベロッパー リレーションズ エンジニア