このガイドでは、Google Cloud を使用した Virtual Private Cloud（VPC）の設計に役立つベスト プラクティスと一般的なエンタープライズ アーキテクチャを紹介します。このガイドは、Google Cloud ネットワーキングのコンセプトに精通したクラウド ネットワーク アーキテクトとシステム アーキテクトを対象としています。
一般原則と最初のステップ
意思決定者、タイムライン、事前作業を特定する
VPC ネットワーク設計の第一歩として、関係者の要件を確実に満たすために必要な意思決定者、タイムライン、事前作業を特定します。
関係者には、アプリケーション所有者、セキュリティ アーキテクト、ソリューション アーキテクト、運用マネージャーなどがいます。プロジェクト、事業部門、組織全体の VPC ネットワークを計画するかどうかによって、関係者の顔触れが変わる可能性があります。
事前作業の一環として、VPC ネットワーク設計に関するコンセプトや用語をチームに周知してください。次のようなドキュメントが役に立ちます。
VPC ネットワーク設計を早期に検討する
Google Cloud での組織の設定を設計する初期段階で VPC ネットワーク設計を行います。ネットワークのセグメント化の方法やワークロードの場所などの基本事項を後で変更する必要がある場合、組織に影響を及ぼす可能性があります。
VPC ネットワーク構成が異なると、ルーティング、規模、セキュリティに大きく影響する可能性があります。慎重に計画し、具体的な考慮事項を十分に理解することが、ワークロードの増加に対応できる堅牢なアーキテクチャの土台の構築につながります。
簡潔さを心掛ける
管理が容易で信頼性が高く理解しやすいアーキテクチャを実現するには、VPC ネットワーク トポロジの設計を簡潔にすることが最善の方法です。
明確な命名規則を使用する
シンプルで直感的で一貫性のある命名規則を使用します。そうすれば、管理者とエンドユーザーは各リソースの用途と配置先を把握して、他のリソースと明確に区別できるようになります。
長い用語について、一般的に受け入れられている略語を使用すれば簡略化できます。使い慣れた用語を必要に応じて使用すれば、読みやすさが向上します。
命名規則の制定にあたっては、次に示す例を参考にしてください。
- 会社名: Acme Company:
acmeco - ビジネス ユニット: 人事部:
hr - アプリケーション コード: 給与システム:
comp - リージョン コード: northamerica-northeast1:
na-ne1、europe-west1:eu-we1 - 環境コード:
dev、test、uat、stage、prod
この例では、人事部の給与システムの開発環境名は acmeco-hr-comp-eu-we1-dev です。
その他の一般的なネットワーキング リソースについては、次のようなパターンを検討してください。
VPC ネットワーク
構文:{company name}-{description(App or BU)-label}-{environment-label}-{seq#}
例:acmeco-hr-dev-vpc-1サブネット
構文:{company-name}-{description(App or BU)-label}-{region/zone-label}
例:acmeco-hr-na-ne1-dev-subnetファイアウォール ルール
構文:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
例:acmeco-hr-internet-internal-tcp-80-allow-ruleIP ルート
構文:{priority}-{VPC-label}-{tag}-{next hop}
例:1000-acmeco-hr-dev-vpc-1-int-gw
アドレスとサブネット
カスタムモードの VPC ネットワークを使用する
最初のプロジェクトはデフォルト ネットワークから始めます。これは、default という名前の自動モードの VPC ネットワークです。自動モードのネットワークは、予測可能な一連の RFC 1918 アドレス範囲を使用して、サブネットとそれに対応するサブネット ルートを自動的に作成します（それらのプライマリ IP 範囲は各 Google Cloud リージョンの /20 CIDR です）。default ネットワークには、いくつかの事前設定ファイアウォール ルールも自動的に含まれます。
自動モードのネットワークは初期の試験運用には役立ちますが、ほとんどの本番環境にはカスタムモードの VPC ネットワークが適しています。
以下の理由から、企業では最初からカスタムモードの VPC ネットワークを使用することをおすすめします。
- カスタムモードの VPC ネットワークの方が既存の IP アドレス管理方式との統合に適しています。自動モードのネットワークはすべて同一の内部 IP 範囲のセットを使用するため、オンプレミスの企業ネットワークに接続すると、自動モードの IP 範囲は重複することがあります。
- サブネットが同一のプライマリ IP 範囲を使用するため、VPC ネットワーク ピアリングを使用して 2 つの自動モードの VPC ネットワークを接続することはできません。
- 自動モードのサブネットはすべてネットワークと同じ名前になります。カスタムモードのサブネット用に一意でわかりやすい名前を選択することで、VPC ネットワークの把握と保守が容易になります。
- 新しい Google Cloud リージョンが導入されると、自動モード VPC ネットワークはそのリージョンで新しいサブネットを自動的に取得します。カスタムモードの VPC ネットワークは、指定した場合にのみ新しいサブネットを取得します。これは、主権と IP アドレス管理の両方の理由から重要となる場合があります。
リソースがない場合は、default ネットワークを削除できます。VPC ネットワークに依存するすべてのリソース（仮想マシン（VM）インスタンスを含む）を削除するまで、VPC ネットワークを削除することはできません。
自動モードとカスタムモードの VPC ネットワークの違いの詳細については、VPC ネットワークの概要をご覧ください。
アドレス範囲の大きい少数のサブネットにアプリケーションをグループ化する
エンタープライズ ネットワークは、従来よりさまざまな理由で多数の小さいアドレス範囲に分割されてきました。たとえば、アプリケーションを特定、分離するためや、ブロードキャスト ドメインを小さくするためなどです。
しかし Google では、運用するリージョン内で、同じ種類のアプリケーションをアドレス範囲が広く管理しやすい少数のサブネットにグループ化することをおすすめします。
サブネット マスクを使用する他のネットワーキング環境と異なり、Google Cloud はソフトウェア定義ネットワーキング（SDN）方式を使用して、グローバル VPC ネットワーク内のすべての VM 間でフルメッシュのネットワーク到達性を提供します。サブネットの数はルーティングの動作に影響しません。
サービス アカウントかネットワーク タグを使用すれば、特定のルーティング ポリシーやファイアウォール ルールを適用できます。Google Cloud の ID は、サブネット IP アドレスだけに基づくものではありません。
VPC 機能の中には、Cloud NAT、限定公開の Google アクセス、VPC フローログ、エイリアス IP 範囲などのように、サブネットごとに構成されるものもあります。これらの機能のきめ細かい制御が必要な場合は、追加のサブネットを使用してください。
単一 VPC ネットワークと共有 VPC
共通の要件を持つリソースは単一 VPC ネットワークから始める。
複数の作業グループの管理には共有 VPC を使用する。
サブネット レベルでネットワーク ユーザーロールを付与する。
リソースに複数のネットワーク インターフェースが必要な場合は、単一のホスト プロジェクトを使用する。
リソース要件が単一プロジェクトの割り当てを超える場合は、複数のホスト プロジェクトを使用する。
VPC ごとに個別の管理ポリシーが必要な場合は、複数のホスト プロジェクトを使用する。
共通の要件を持つリソースは単一 VPC ネットワークから始める
多くの単純なユースケースでは、単一 VPC ネットワークによって必要な機能を提供できます。また、複雑な代替手段よりも作成、保守、把握が容易です。最初は、共通の要件と特性を持つリソースを単一の VPC ネットワークにグループ化することで、起こりうる問題の防衛線として VPC ネットワーク境界を設定できます。
この構成の例については、単一プロジェクト、単一 VPC ネットワークのリファレンス アーキテクチャをご覧ください。
スケーリング、ネットワーク セキュリティ、財政的な考慮事項、運用要件、Identity and Access Management（IAM）などの要因により、追加の VPC ネットワークの作成が必要になることもあります。
複数の作業グループの管理には共有 VPC を使用する
組織内に複数のチームがある場合、共有 VPC は、単一 VPC ネットワークのシンプルなアーキテクチャを複数の作業グループに拡張するための効果的なツールになります。最も単純なアプローチは、単一の共有 VPC ネットワークに単一の共有 VPC ホスト プロジェクトをデプロイしてから、チーム サービス プロジェクトをホスト プロジェクト ネットワークに接続することです。
この構成では、すべてのネットワーキング リソースに対するネットワーク ポリシーと制御が集中化され、管理が容易になります。サービス プロジェクト部門は、ネットワーク以外のリソースを構成および管理する一方で、組織内のさまざまなチームの責任を明確に分離できます。
プロジェクト内のリソースは、内部 IP アドレスにより、プロジェクト境界を越えて安全かつ効率的にやり取りできます。サブネット、ルート、ファイアウォールなどの共有ネットワーク リソースをホスト プロジェクトから集中管理できるため、プロジェクト間で一貫したネットワーク ポリシーを適用できます。
この構成の例については、単一ホスト プロジェクト、複数サービス プロジェクト、単一共有 VPC のリファレンス アーキテクチャをご覧ください。
サブネット レベルでネットワーク ユーザーロールを付与する
集中化された共有 VPC の管理者は、サブネット レベル（きめ細かいサービス プロジェクト承認用）またはホスト プロジェクト レベル（すべてのサブネット用）で、IAM メンバーにネットワーク ユーザー（networkUser）ロールを付与できます。
最小特権の原則に従って、サブネット レベルでネットワーク ユーザーロールを関連ユーザー、サービス アカウント、またはグループに付与することをおすすめします。
サブネットはリージョン単位であるため、このきめ細かい制御を使用して、各サービス プロジェクトがリソースのデプロイに使用できるリージョンを指定できます。
共有 VPC アーキテクチャでは、組織内で複数の共有 VPC ホスト プロジェクトを柔軟にデプロイできます。各共有 VPC ホスト プロジェクトは、単一または複数の共有 VPC ネットワークに対応できます。この構成では、異なる環境で異なるポリシー項目を容易に適用できます。
詳細については、ネットワーキングにおける IAM 役割をご覧ください。
リソースに複数のネットワーク インターフェースが必要な場合は、単一のホスト プロジェクトを使用する
サービス プロジェクトでリソースを複数の独立した VPC ネットワークにデプロイする必要がある場合（VM インスタンスで複数のネットワーク インターフェースを使用する場合など）、ホスト プロジェクトにはサービスを提供するすべての VPC ネットワークが含まれている必要があります。これは、サービス プロジェクトは 1 つのホスト プロジェクトにしか接続できないためです。
リソース要件が単一プロジェクトの割り当てを超える場合は、複数のホスト プロジェクトを使用する
すべての VPC ネットワークが必要とする合計リソースをプロジェクトの割り当て内で満たすことができない場合は、複数の共有 VPC ネットワークを持つ単一のホスト プロジェクトではなく、ホスト プロジェクトごとに単一の共有 VPC ネットワークを持つ複数のホスト プロジェクトを含むアーキテクチャを使用します。このアーキテクチャでは、スケール要件を評価することが重要です。単一ホスト プロジェクトを使用するには、ホスト プロジェクトに複数の VPC ネットワークが必要で、プロジェクト レベルで割り当てが適用されるためです。
この構成の例については、複数ホスト プロジェクト、複数サービス プロジェクト、複数共有 VPC のリファレンス アーキテクチャをご覧ください。
VPC ネットワークごとに個別の管理ポリシーが必要な場合は、複数のホスト プロジェクトを使用する
各プロジェクトには固有の割り当てがあるため、すべての VPC ネットワークに個別の共有 VPC ホスト プロジェクトを使用して、合計リソースをスケーリングします。これにより、各 VPC ネットワークはネットワーキングとセキュリティ管理用に個別の IAM 権限を持つことが可能になります。IAM 権限はプロジェクト レベルでも実装されるからです。たとえば、2 つの VPC ネットワーク（VPC ネットワーク A と VPC ネットワーク B）を同じホスト プロジェクトにデプロイした場合、両方の VPC ネットワークにネットワーク管理者（networkAdmin）ロールが適用されます。
複数の VPC ネットワークを作成するかどうかを決定する
プロジェクトごとに単一 VPC ネットワークを作成し、VPC ネットワーク割り当てをプロジェクトにマッピングする。
共通の VPC ネットワークで共有サービスを使用して、自律型チームごとに VPC ネットワークを作成する。
独立した IAM 制御を行う場合は、プロジェクトごとに VPC ネットワークを作成する。
センシティブ データを固有の VPC ネットワークに分離する。
プロジェクトごとに単一 VPC ネットワークを作成し、VPC ネットワーク割り当てをプロジェクトにマッピングする
割り当ては、プロジェクト レベルまたはネットワーク レベルで適用される制約です。すべてのリソースには、予期しないリソースの使用を防ぐための初期デフォルト割り当てがあります。ただし、さまざまな要因によって割り当ての増加が必要になる場合があります。ほとんどのリソースでは、追加の割り当てを要求できます。
デフォルトの VPC リソース割り当てを超えることが予想される場合は、プロジェクトごとに単一 VPC ネットワークを作成することをおすすめします。そうすれば、プロジェクト レベルの割り当ての増加を各 VPC ネットワークにマッピングできるので、同じプロジェクト内の VPC の組み合わせにマッピングするより簡単です。
システム リソース全体を保護するために、上限が設計されています。通常、上限は簡単に引き上げることはできませんが、Google Cloud サポートとセールスチームが利用者と協力して一部の上限を引き上げることはできます。
現在の値を確認するには、VPC リソースの割り当てと制限をご覧ください。
Google サポートはスケーリングの上限を上げることはできますが、スケーリング要件を満たすために複数の VPC ネットワークを何度も作成しなければならないことがあります。VPC ネットワークが上限を超えてスケーリングする必要がある場合は、Google Cloud のセールスチームおよびサポートチームと相談して、要件を満たす最適な方法を検討してください。
共通の VPC ネットワークで共有サービスを使用して、自律型チームごとに VPC ネットワークを作成する
大規模なエンタープライズ デプロイメントでは、複数の自律型チームが存在し、各チームがそれぞれの VPC ネットワークを完全に制御しなければならない場合があります。この要件を満たすには、共通の VPC ネットワーク内の共有サービス（分析ツール、CI/CD パイプラインとビルドマシン、DNS / ディレクトリ サービスなど）を備えた VPC ネットワークをビジネス ユニットごとに作成します。共有サービス用の共通の VPC ネットワークの作成ついて詳しくは、共有サービスのセクションをご覧ください。
独立した IAM 制御を行う場合は、プロジェクトごとに VPC ネットワークを作成する
VPC ネットワークはプロジェクト レベルのリソースであり、プロジェクト レベルの IAM（Identity and Access Management）制御機能を備えています。次の役割を使用できます。
networkAdminsecurityAdminnetworkUsernetworkViewer
デフォルトでは、IAM 制御はプロジェクト レベルでデプロイされ、各 IAM 役割はプロジェクト内のすべての VPC ネットワークに適用されます。
VPC ネットワークごとに独立した IAM 制御を行う必要がある場合は、プロジェクトごとに VPC ネットワークを作成します。
VM インスタンス、ディスク、イメージなどの特定の Compute Engine リソースを対象とする IAM ロールが必要な場合は、Compute Engine リソースの IAM ポリシーを使用します。
センシティブ データを固有の VPC ネットワークに分離する
コンプライアンスに取り組んでいる企業、センシティブ データを扱う企業、HIPAA や PCI-DSS などのコンプライアンス基準に従う規制対象データを扱う企業では、厳格なセキュリティ対策が必要になります。セキュリティを強化し、コンプライアンスの証明を容易にする方法の 1 つは、そうしたデータを扱う環境をそれぞれ固有の VPC ネットワークに分離することです。
複数の VPC ネットワークの接続
コスト、パフォーマンス、セキュリティのニーズを満たす VPC 接続方法を選択する。
リソース制限を超えない場合は VPC ネットワーク ピアリングを使用する。
限定公開 IP アドレス通信が不要な場合は外部ルーティングを使用する。
ピアリングの合計上限を超えそうな場合は Cloud VPN を使用して VPC ネットワークを接続する。
Cloud Interconnect を使用し、オンプレミス デバイスを介して VPC ネットワーク間のトラフィックを制御する。
マルチ NIC 仮想アプライアンスを使用し、クラウド デバイスを介して VPC ネットワーク間のトラフィックを制御する。
複数の VPC ネットワークが共通リソースにアクセスする必要があるが相互にアクセスする必要がない場合は、共有サービス VPC を作成する。
コスト、パフォーマンス、セキュリティのニーズを満たす VPC 接続方式を選択する
複数の VPC ネットワークの実装を決定したら、次のステップではそれらの VPC ネットワークを接続します。VPC ネットワークは Google の Andromeda SDN 内の独立したテナント スペースですが、ネットワーク間の通信を実現する方法は複数あります。以降のセクションでは、VPC 接続方式を選択するためのおすすめの方法を紹介します。
次の表は、各方式のメリットとデメリットをまとめたものです。それ以降のセクションでは、VPC 接続方式を選択するためのおすすめの方法を示します。
| メリット | デメリット | |
|---|---|---|
| VPC ネットワーク ピアリング |
|
|
| 外部ルーティング（パブリック IP または NAT ゲートウェイ） |
|
|
| Cloud VPN |
|
|
| Cloud Interconnect - Dedicated または Partner |
|
|
| 複数ネットワーク インターフェース（マルチ NIC） |
|
|
リソース制限を超えない場合は VPC ネットワーク ピアリングを使用する
VPC ネットワークを接続する必要があるが単一共有 VPC を使用できない場合は、すべての直接接続ピアに必要なリソースの合計が VM インスタンス、ピアリング接続数、内部転送ルールの上限を超えない限り、VPC ネットワーク ピアリングを使用することをおすすめします。
VPC ネットワーク ピアリングでは、2 つの VPC ネットワークが同じプロジェクトまたは同じ組織に属しているかどうかにかかわらず、Google の SDN を介して内部的に相互接続できます。VPC ネットワーク ピアリングは各ピア間の制御プレーンとフロー伝播を統合して、すべての VM が同じ VPC ネットワーク内にあるかのような転送特性を実現します。VPC ネットワークがピアリングされると、すべてのサブネット、エイリアス IP 範囲、内部転送ルールがアクセス可能になり、各 VPC ネットワークは固有の分散ファイアウォールを維持します。VPC ネットワーク ピアリングは推移的ではありません。
VPC ネットワーク接続で VPC ネットワーク ピアリングをおすすめする理由は次のとおりです。
- ゲートウェイのボトルネックがない。トラフィックは、VM が同じ VPC ネットワーク内にあるかのようにピア間で転送されます。
- 追加料金が請求されない。料金は、VM が同じ VPC ネットワークにある場合と同様です。
限定公開 IP アドレス通信が不要な場合は外部ルーティングを使用する
限定公開 IP アドレス通信が不要な場合は、外部 IP アドレスまたは NAT ゲートウェイによる外部ルーティングを使用できます。
VPC ネットワークがデプロイされると、Google のデフォルト インターネット ゲートウェイへのルートは優先度 1000 でプロビジョニングされます。このルートが存在し、かつ VM に外部 IP アドレスが割り当てられていれば、VM は Google のインターネット ゲートウェイ経由で下り（外向き）トラフィックを送信できます。また、Google の多数の一般公開されたロード バランシング サービスのいずれかの背後でサービスをデプロイして、サービスを外部に提供することもできます。
外部アドレス指定された VM は、リージョンおよびネットワーク サービス階層にかかわらず、Google のバックボーンを介して互いに限定公開で通信します。Google Cloud ファイアウォール ルールを使用して、VM への外部からの上り（内向き）トラフィックを制御します。
外部ルーティングはスケーリングに適していますが、一般公開ルーティングがコストに与える影響を理解することが重要です。詳細については、ネットワーク料金のドキュメントをご覧ください。
ピアリングの合計上限を超えそうな場合は Cloud VPN を使用して VPC ネットワークを接続する
HA VPN は、エンドポイントのセット間で IPsec トンネルを作成することで、VPC ネットワークを接続するマネージド サービスを提供します。カスタムのルート アドバタイズで Cloud Router を構成する場合は、このドキュメントで後述するように、VPC ネットワークとハブアンドスポーク トポロジ全体で推移的なルーティングを有効にできます。Network Connectivity Center を使用すると、Cloud VPN のドキュメントで説明されているように、HA VPN トンネルをオンプレミス ネットワーク間のトランジット ネットワークとして使用できます。
Cloud VPN は大規模な MTU をサポートしていません。詳細については、MTU に関する考慮事項をご覧ください。
Cloud Interconnect を使用し、オンプレミス デバイスを介して VPC ネットワーク間のトラフィックを制御する
Cloud Interconnect により、オンプレミス ネットワークが、可用性が高くレイテンシの低い接続を通じて Google のネットワークまで拡張されます。Dedicated Interconnect を使用して Google に直接接続することも、Partner Interconnect を使用して、サポートされているサービス プロバイダを介して Google に接続することもできます。
Dedicated Interconnect は、Google とコロケーション プロバイダまたはオンプレミスのロケーションの間で高速 L2 サービスを提供します。これにより、オンプレミスのルーティング装置を使用して VPC ネットワーク間のルーティングを行い、既存のオンプレミスのセキュリティおよび検査サービスを使用して VPC ネットワーク間のすべてのトラフィックをフィルタリングできます。2 つの VPC ネットワーク間のすべてのトラフィックでは、オンプレミス システムを経由する追加のラウンド トリップのために、追加のレイテンシが発生します。
Partner Interconnect では、Dedicated Interconnect と同様の機能を利用するだけでなく、L3 のプロバイダと直接ピア接続してプロバイダに VPC ネットワーク間のルーティングを行わせることもできます。これにより、NAT デバイスや VPN トンネルなしで、オンプレミス ネットワークと Google Cloud VPC ネットワークにまたがる内部 IP アドレスにアクセスできます。
複数のネットワーク インターフェースを持つ VM により Google Cloud で多くのエンタープライズ セキュリティ アプライアンスを使用できるため、Cloud Interconnect を使用して VPC ネットワーク間でトラフィックをルーティングする必要はありませんが、企業ポリシーのためにすべてのトラフィックがオンプレミス アプライアンスを経由する必要があるケースがまれにあります。
仮想アプライアンスを使用し、クラウド デバイスを介して VPC ネットワーク間のトラフィックを制御する
複数ネットワーク インターフェースを持つ VM は、VPC ネットワーク間の通信をブリッジすることができるので、VPC 間で追加のセキュリティやサービスが必要となる VPC でよく使用されます。
VM には、接続先の VPC ネットワークごとにインターフェースが 1 つだけ許可されます。VM を複数の VPC ネットワークにデプロイするには、VM の接続先の各 VPC に対して適切な IAM 権限を持っている必要があります。
マルチ NIC VM をデプロイする場合は、次の点に注意してください。
- マルチ NIC VM が持つことができるインターフェースは最大 8 個です。
- インターフェースのサブネット IP 範囲は重複してはいけません。
複数の VPC ネットワークが共通リソースにアクセスする必要があるが相互にアクセスする必要がない場合は、共有サービス VPC を作成する
VPC ネットワークは、フルメッシュのグローバルなネットワーク到達性を提供します。このため、同じ VPC ネットワーク内に存在する共有サービスと継続的インテグレーション パイプラインは、本質的に到達可能な接続性については特に考慮する必要はありません。共有 VPC ではこのコンセプトが拡張され、他のサービスまたは消費者への接続を提供しつつ、共有サービスを分離されたプロジェクトに配置できるようになっています。
共有サービスへの接続には、Private Service Connect、VPC ネットワーク ピアリング、Cloud VPN という方法があります。なんらかの理由でこれらを使用できない場合は、Private Service Connect を使用します。リソースの合計制限を超えず、各サービスにエンドポイントを設定したくない場合は、VPC ネットワーク ピアリングを使用して共有サービス VPC ネットワークに接続できます。また、Cloud VPN を使用して、ピアリング グループの上限を超える共有サービス VPC ネットワークを接続することもできます。
Private Service Connect を使用すると、コンシューマー ネットワーク内に特別なエンドポイントを作成することで、あるネットワークでホストされているサービスを別のネットワーク内の VM で使用可能にできます。その後、Private Service Connect の構成により、2 つのネットワーク間でそのサービスへのトラフィックがチャネル化されます。
ユーザーは、VPC ネットワークからの離脱や、外部 IP アドレスの使用をすることなく、独自の内部 IP アドレスを使用してサービスにアクセスできます。トラフィックが Google Cloud の外に出ることはありません。Private Service Connect は、コンシューマーとプロデューサーの間にサービス指向のアクセスを提供し、サービスへのアクセスをきめ細かく制御します。
VPC ネットワーク ピアリング モデルでは、各 VPC ネットワークが共通の共有サービス VPC ネットワークとピアリング関係を形成して、ネットワーク到達性を確保します。VPC ネットワーク ピアリングでは、すべてのピアの合計リソース使用量にスケーリング上限が適用されるため、スケーリングについて配慮されます。
VPC ネットワーク ピアリングは、限定公開サービス アクセスおよび Service Networking API と組み合わせて使用することもできます。Service Networking API を使用すると、提供するサービスを同じ組織または別の組織のお客様にご利用いただくことができますが、VPC ネットワーク ピアリングで接続される IP アドレス範囲をお客様に選択していただくことになります。
Cloud VPN もその一つです。Cloud VPN はマネージド IPSec トンネルを介してネットワーク到達性を確立するので、VPC ネットワーク ピアリングのような合計使用量の制限はありません。Cloud VPN では接続に VPN ゲートウェイが使用され、IPSec ピアの合計リソース使用量は考慮されません。Cloud VPN のデメリットとしては、コストの増加（VPN トンネルと外向きトラフィック）、トンネルの維持に必要な管理オーバーヘッド、IPSec のパフォーマンス オーバーヘッドがあります。
ハイブリッド設計: オンプレミス環境の接続
ハイブリッド接続が必要であることを確認し、帯域幅、パフォーマンス、セキュリティの要件を満たすソリューションを選択したら、ソリューションを VPC 設計に統合する方法を検討します。
共有 VPC を使用すると、各プロジェクトで同じソリューションを複製する必要性が軽減されます。たとえば、Cloud Interconnect ソリューションを共有 VPC に統合すると、リージョンやサービス プロジェクトに関係なく、すべての VM が Cloud Interconnect 接続にアクセスできるようになります。
動的ルーティング
動的ルーティングは、HA VPN、Classic VPN、Dedicated Interconnect、Partner Interconnect など、すべての相互接続ソリューションで利用できます。動的ルーティングでは、Google の Cloud Router を Border Gateway Protocol（BGP）スピーカーとして使用し、動的な外部 BGP（eBGP）ルーティングを行います。
Cloud Router はデータプレーンには存在せず、SDN にルートを作成するだけです。
動的ルーティングはタグを使用せず、Cloud Router は学習した接頭辞を再アドバタイズしません。
各 VPC ネットワークで、Cloud Router の 2 つのモード（リージョナルまたはグローバル）のいずれかを有効にできます。リージョナル ルーティングを選択した場合、Cloud Router は、Cloud Router がデプロイされたリージョン内で共存するサブネットのみをアドバタイズします。一方、グローバル ルーティングを選択した場合は、リージョンに関係なく所定の VPC ネットワークのすべてのサブネットをアドバタイズしますが、リージョン外でアドバタイズおよび学習されたルートにペナルティを付けます。これにより、常にローカル相互接続が優先されることでリージョン内の対称性が維持され、リージョン間のペナルティ メトリック（MED）が 200 + TTL ミリ秒だけ加算されます。
静的ルーティング
静的ルーティングは Classic VPN でのみ使用できます。静的ルーティングでは、Cloud VPN トンネルを指すネクストホップ ルートを設定できます。
デフォルトでは、静的ルートはリージョンに関係なく、ネットワーク内のすべての VM に適用されます。静的ルーティングでは、ネットワーク管理者はルートの作成時にターゲットに設定できるインスタンス タグを使用して、ルートを適用する VM を選択して設定できます。
静的ルートは、互いに同じルート優先度で、VPC ネットワーク内にグローバルに適用されます。したがって、複数のリージョンに、同じ優先度を持つ同じ接頭辞へのトンネルが複数ある場合、VM はすべてのトンネルで 5 タプルのハッシュベース ECMP を使用します。この設定を最適化するため、各リージョンのインスタンス タグを参照し、それに応じて優先ルートを作成することで、優先的なリージョン内ルートを作成できます。
発信（下り）トラフィックが Google のデフォルト インターネット ゲートウェイを通過しないようにする場合は、すべてのトラフィックをトンネル経由でオンプレミスに返送するための優先的なデフォルトの静的ルートを設定します。
接続 VPC ネットワークを使用して、ハブアンドスポーク アーキテクチャを複数の VPC ネットワークでスケーリングする
ハブアンドスポーク アーキテクチャを複数の VPC ネットワークでスケーリングする必要がある場合は、専用 VPC ネットワークで集中型ハイブリッド接続を構成し、カスタム アドバタイズ ルートを使用して他のプロジェクトにピア接続します。そうすれば、静的ルートまたは動的に学習されたルートをピア VPC ネットワークにエクスポートして、集中型構成と VPC 設計へのスケーリングを実現できます。
これは、個々の VPC ネットワークごとに VPN トンネルまたは VLAN アタッチメントを使用する従来のハイブリッド接続デプロイメントとは対照的です。
次の図は、VPC ネットワーク ピアリング カスタムルートを使用した集中型ハイブリッド接続を示しています。
ネットワーク セキュリティ
明確なセキュリティ目標を決定する。
外部アクセスを制限する
機密データのサービス境界を定義する。
可能であれば Google Cloud ネイティブのファイアウォール ルールでトラフィックを管理する。
可能であれば少数の広範なファイアウォール ルールセットを使用する。
可能であればサービス アカウントを使用して VM を分離する。
タグを使用するときは自動化を使用してセキュリティ ポリシーをモニタリングする。
追加のツールを利用してアプリを安全に保護する。
Google Cloud では、データセンターの物理的な安全対策、独自のセキュリティ ハードウェア、研究者で構成される専任チームなど、堅牢なセキュリティでインフラストラクチャとサービス全体を保護しています。しかし、Google Cloud リソースの保護にはお客様の協力が不可欠です。アプリとデータが確実に保護されるように、適切な対策を講じるようお願いいたします。
明確なセキュリティ目標を決定する
クラウド ネイティブまたはクラウド対応のセキュリティ管理対策を評価する前に、すべての関係者がプロダクトの基本要素として同意する一連の明確なセキュリティ目標を決定します。これらの目標では、達成可能性、文書化、イテレーションを重視し、開発全体を通して参照および改善できるようにする必要があります。
外部アクセスを制限する
VPC ネットワークを使用する Google Cloud リソースを作成する際は、リソースを配置するネットワークとサブネットを選択します。リソースには、サブネットに関連付けられた IP 範囲の中から内部 IP アドレスが割り当てられます。VPC ネットワーク内のリソースは、ファイアウォール ルールの許可があれば、内部 IP アドレスによって相互に通信できます。
インターネットへのアクセスは、必要なリソースにのみ許可する必要があります。Private Service Connect または限定公開の Google アクセスを使用すると、プライベートの内部 IP アドレスしかないリソースでも多くの Google API やサービスにアクセスできます。このプライベート アクセスにより、公共のインターネットから隔離された状態で、主要な Google サービスや Google Cloud サービスを利用できます。
また、組織のポリシーを使用して、外部 IP アドレスを使用できるリソースをさらに制限します。
ただし、インターネット アクセスをブロックする前に、VM インスタンスへの影響を検討してください。インターネット アクセスをブロックすると、データ漏洩のリスクを削減できる一方で、ソフトウェアの更新やサードパーティの API とサービスに必要な正当なトラフィックもブロックされる可能性があります。インターネット アクセスがない場合は、Cloud VPN トンネル、Cloud Interconnect 接続、または Identity-Aware Proxy を介して接続されたオンプレミス ネットワーク経由でのみ VM インスタンスにアクセスできます。Cloud NAT を使用すれば、仮想マシンは、一般公開される上り（内向き）接続を公開することなく、特定の重要なトラフィックのためにインターネットへの下り（外向き）接続を起動できます。
センシティブ データのサービス境界を定義する
センシティブ データを含むワークロードの場合は、VPC Service Controls を使用して、VPC リソースと Google 管理サービスの周囲にサービス境界を構成し、境界を越えるデータの移動を制御します。VPC Service Controls を使用すると、プロジェクトとオンプレミス ネットワークを 1 つの境界にグループ化し、この境界により Google 管理サービスを介したデータアクセスを防止できます。サービス境界に異なる組織のプロジェクトを含めることはできませんが、境界ブリッジを使用すれば、異なるサービス境界内のプロジェクトとサービスの通信を許可できます。
可能であれば Google Cloud ネイティブのファイアウォール ルールでトラフィックを管理する
Google Cloud VPC には、水平スケーリングが可能な L3/L4 ステートフル ファイアウォールがあり、各 VM に分散方式で適用されます。このファイアウォールは、階層型ファイアウォール ポリシー、グローバルおよびリージョンごとのネットワーク ファイアウォール ポリシー、VPC ファイアウォール ルールを使用して構成されます。詳細については、Cloud Firewall の概要をご覧ください。
Google Cloud Marketplace にはサードパーティ ソリューションの大規模なエコシステムがあり、情報漏洩やアプリの悪用や権限昇格攻撃の防止、既知および未知の脅威の検出、URL フィルタリングの適用などの高度なセキュリティを提供する VM を利用できます。また、単一ベンダーにクラウド サービス プロバイダとオンプレミス環境にまたがるポリシーを実装させることも、運用上のメリットになります。
トラフィックは通常、同じ優先度（5 タプルのハッシュでトラフィックを分散するため）または異なる優先度（冗長パスを作成するため）でルートを指定することにより、複数の VM にルーティングされます。たとえば、次の図は Dev-subnet への複数のパスを示しています。
ほとんどのソリューションでは、複数のネットワーク インターフェースを持つ VM が必要になります。VM は VPC ネットワークごとに複数のインターフェースを持つことができないため、マルチ NIC VM を作成する場合は、各インターフェースを個別の VPC ネットワークに接続する必要があります。
サードパーティ ソリューションを VPC ネットワークにデプロイする場合は、次の理由から規模も重要な考慮事項になります。
- 制限: ほとんどの VM ベースのアプライアンスはデータパスに挿入する必要があります。このためには、同じプロジェクト内にある複数の VPC ネットワークを橋渡しする、複数ネットワーク インターフェースを持つ VM が必要です。VPC リソースの割り当てはプロジェクト レベルで設定されるため、すべての VPC ネットワークにまたがる必要な合計リソースが制限される可能性があります。
- パフォーマンス: VPC ネットワークの完全な水平スケーラビリティ属性に VM ベースのチョークポイントを導入することは、クラウドの設計方法に悪影響を及ぼします。これを軽減するには、複数のネットワーク仮想アプライアンス（NVA）を内部パススルー ネットワーク ロードバランサの背後にあるマネージド インスタンス グループに配置します。
大規模であることが要件となるアーキテクチャのこうした要素に対応するには、セキュリティ制御をエンドポイントに設定します。まずは、VM を強化し、Google Cloud ファイアウォール ルールを使用します。この戦略では、複数ネットワーク インターフェースを持つ VM を通じて、VPC ネットワークの転送アーキテクチャを変更しないホストベースのエンドポイント検査エージェントを導入することもできます。
この構成の他の例については、VPC ネットワーク間のステートフル L7 ファイアウォールのリファレンス アーキテクチャをご覧ください。
可能であれば少数の広範なファイアウォール ルールセットを使用します
任意の VM にプログラムできるのは、特定の数のルールのみです。多数のルールを 1 つの複雑なルール定義にまとめることができます。たとえば、VPC ネットワーク内のすべての VM で明示的に 10 個の上り TCP ポートを許可する必要がある場合、2 つの選択肢があります。つまり、10 個の個別のルールを作成してそれぞれで 1 つのポートを定義するか、10 個すべてのポートを含む単一のルールを定義するかです。10 個のポートすべてを含む単一のルールを定義する方が効率的です。
VPC ネットワーク全体に適用する汎用のルールセットを作成してから、ターゲットを使用する VM の小規模なグループに特定のルールセットを適用します。つまり、まずは広範なルールを定義し、必要に応じて対象を絞ったルールを定義します。
- VPC ネットワーク内のすべての VM に共通するファイアウォール ルールを適用します。
- サービス インスタンス グループやサブネットなどの複数の VM のグループにファイアウォール ルールを適用します。
- NAT ゲートウェイや踏み台インスタンスなどの個々の VM にファイアウォール ルールを適用します。
可能であればサービス アカウントを使用して VM を分離する
多くの組織では、環境によって、VPC ネットワーク内の VM のサブセットに特定のルールを適用しなければならない場合があります。このような場合に採用できる一般的なアプローチは 2 つあります。それは、サブネット分離とターゲット フィルタリングです。
サブネット分離
サブネット分離では、サブネットは Google Cloud ファイアウォール ルールが適用されるセキュリティ境界を形成します。このアプローチは、オンプレミス ネットワーキング構成で、IP アドレスとネットワーク プレースメントが VM ID の一部を構成する場合によく使用されます。
特定のサブネット上の VM を識別するには、それらのインスタンスに一意のタグ、ネットワーク タグ、サービス アカウントを適用します。そうすれば、サブネット内の VM（関連付けられたネットワーク タグまたはサービス アカウントを持つもの）にのみ適用されるファイアウォール ルールを作成できます。たとえば、同じサブネット内の VM 間のすべての通信を許可するファイアウォール ルールを作成するには、[ファイアウォール ルール] ページで次のルール構成を使用します。
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: subnet-1
- ソースフィルタ: サブネット
- サブネット: サブネットを名前で選択します（例: subnet-1）。
ターゲット フィルタリング
ターゲット フィルタリングでは、すべての VM が同じサブネット上に存在するか、または任意のサブネットのセットの一部になります。このアプローチでは、サブネット メンバーはファイアウォール ルールのインスタンス ID の一部とはみなされません。代わりに、ネットワーク タグまたはサービス アカウントを使用して、同じサブネット内の VM 間のアクセスを制限できます。同じファイアウォール ルールを使用する VM の各グループには、同じネットワーク タグが適用されます。
わかりやすい例として、すべてのインスタンスが同じサブネットにデプロイされている 3 層（ウェブ、アプリ、データベース）アプリケーションを考えてみましょう。ウェブ階層はエンドユーザーおよびアプリ階層と通信でき、アプリ階層はデータベース階層と通信できますが、これら以外の階層間通信は許可されません。ウェブ階層を実行するインスタンスには web というネットワーク タグがあり、アプリ階層を実行するインスタンスには app というネットワーク タグがあります。また、データベース階層を実行するインスタンスには db というネットワーク タグがあります。
このアプローチを実装するファイアウォール ルールは、次のとおりです。
| ルール 1: エンドユーザー → ウェブ階層を許可 | ターゲット: 指定されたターゲットタグ ターゲットタグ: web ソースフィルタ: IP の範囲 ソース IP の範囲: 0.0.0.0/0 |
| ルール 2: ウェブ階層 → アプリ階層を許可 | ターゲット: 指定されたターゲットタグ ターゲットタグ: app ソースフィルタ: ソースタグ ソースタグ: web |
| ルール 3: アプリ階層 → データベース階層を許可 | ターゲット: 指定されたターゲットタグ ターゲットタグ: db ソースフィルタ: ソースタグ ソースタグ: app |
ターゲット フィルタリングではこのようにネットワーク タグを使用できますが、可能であればタグまたはサービス アカウントを使用することをおすすめします。ターゲットタグはアクセス制御の対象でないため、instanceAdmin ロールを持つユーザーによって VM の処理中に変更される可能性があります。一方、サービス アカウントはアクセス制御の対象です。つまり、特定のユーザーに明示的にサービス アカウントの使用を許可する必要があります。サービス アカウントはインスタンスごとに 1 つしか割り当てられませんが、複数のタグを使用できます。また、VM に割り当てられたサービス アカウントは、VM の停止中にしか変更できません。
タグを使用するときは自動化を使用してセキュリティ ポリシーをモニタリングする
タグを使用する場合は、インスタンス管理者がタグを変更できることを忘れないでください。これは、セキュリティ ポリシーの回避を可能にします。したがって、本番環境でタグを使用する場合は、タグに対する IAM ガバナンスの欠如を克服するために自動化フレームワークを使用してください。
追加のツールを利用してアプリを安全に保護する
ファイアウォール ルールだけでなく、次のような追加ツールを使用してアプリを安全に保護します。
- 高可用性とプロトコルの正規化をサポートする Google Cloud のグローバルな HTTP(S) ロードバランサを使用します。
- Google Cloud Armor と HTTP(S) ロードバランサを統合して、DDoS 防御とネットワーク エッジでの IP アドレスのブロックまたは許可を可能にします。
- Identity-Aware Proxy（IAP）を使用して、ユーザーの ID とリクエストのコンテキストを確認し、ユーザーにアクセスを許可するかどうか判断します。これにより、アプリへのアクセスを制御します。
- Security Command Center を使用して、セキュリティ分析、異常検出、脆弱性検出のための単一のインターフェースを提供します。
ネットワーク サービス: NAT と DNS
Cloud NAT で固定外部 IP アドレスを使用する
VM の範囲からの固定外部 IP アドレスが必要な場合は、Cloud NAT を使用します。たとえば、特定の外部 IP アドレスからのリクエストをサードパーティが許可する場合は、固定の発信 IP アドレスが必要になります。Cloud NAT を使用すると、アウトバウンド通信に使用されるリージョンごとに少数の NAT IP を持つことができます。
ただし、Cloud NAT を使用する場合、VM インスタンスは固有の外部 IP アドレスなしでインターネットを介して通信することもできます。Google Cloud ファイアウォール ルールはステートフルです。したがって、ソースとターゲットまたはターゲットと宛先の間で接続が許可されると、接続がアクティブである限り、どちらの方向へのトラフィックも許可されます。つまり、ファイアウォール ルールは、セッションの確立後は双方向通信を許可します。
名前解決に限定公開 DNS ゾーンを使用する
Cloud DNS の限定公開ゾーンを使用すると、内部 IP アドレスにより、VPC ネットワーク内の DNS でサービスを解決できます。このマッピングは外部に公開されません。
スプリット ホライズン DNS を使用すると、外部からではなく VPC ネットワーク内からサービスを異なる IP アドレスにマッピングできます。たとえば、一般公開インターネットからのネットワーク負荷分散を通してサービスを公開する一方で、VPC ネットワーク内から同じ DNS 名で同じサービスを提供する内部負荷分散を設定できます。
Google 管理サービスの API アクセス
可能な限りデフォルト インターネット ゲートウェイを使用する。
デフォルト ルートを変更する必要がある場合は、Google API の明示的なルートを追加する。
Google API を使用するインスタンスを同じサブネットにデプロイする。
可能な限りデフォルト インターネット ゲートウェイを使用する
VPC ネットワーク内のリソースから Google API へのアクセスは、デフォルト インターネット ゲートウェイのネクストホップに従います。ネクストホップ ゲートウェイという名前にもかかわらず、インスタンスから Google API へのトラフィック パスは Google のネットワーク内に残ります。
デフォルトでは、外部 IP アドレスを持つインスタンスのみが Google API およびサービスと通信できます。外部 IP アドレスを持たないインスタンスからのアクセスが必要な場合は、Private Service Connect エンドポイントを設定するか、サブネットごとに限定公開の Google アクセス機能を使用します。これにより Google API の通信速度が低下することはありません。
Google Kubernetes Engine（GKE）は、ノードがデプロイされているサブネット上で限定公開の Google アクセスを自動的に有効にします。外部 IP アドレスを持たないこうしたサブネット上のすべてのノードは、Google が管理するサービスにアクセスできます。
デフォルト ルートを変更する必要がある場合は、Google API の明示的なルートを追加する
デフォルト ルートを変更する必要がある場合は、Google API の宛先 IP 範囲に明示的なルートを追加します。
デフォルト ルート（0.0.0.0/0）がデフォルト インターネット ゲートウェイのネクストホップを使用しない環境では、Google API で使用される宛先 IP アドレス範囲の明示的なルートを構成します。明示的なルートのネクストホップは、デフォルト インターネット ゲートウェイに設定します。このシナリオは、オンプレミス デバイスからのすべてのトラフィックを検査する必要がある場合などに使用します。
Google API を使用するインスタンスを同じサブネットにデプロイする
Google API およびサービスへのアクセスを必要とするインスタンスを同じサブネットにデプロイし、外部 IP アドレスを持たないインスタンスに対して限定公開の Google アクセスを有効にします。または、Private Service Connect エンドポイントを設定します。
限定公開の Google アクセスを使用してオンプレミス環境から Google API にアクセスする場合は、オンプレミス ホスト用の限定公開の Google アクセスの構成を使用して、プライベート IP アドレス範囲で一部の Google サービスにアクセスします。このサービスが提供する IP アドレスではアクセスできない Google API も存在するため、この機能を有効にする前にサポート対象のサービスを確認してください。この機能を有効にすると、DNS ビューの構成など、追加の DNS 構成が必要になることがあります。
Private Service Connect エンドポイントを使用してオンプレミス環境から Google API にアクセスする場合は、オンプレミス ホストからエンドポイントにアクセスするで詳細をご確認ください。
ロギング、モニタリング、可視性
特定のユースケースと注意が必要なユーザーのロギングを調整する。
長時間接続する VPC ネットワークのログ集計間隔を長くする。
VPC フローログのサンプリングを使用してボリュームを削減する。
IP とポートのデータのみが必要な場合は追加のメタデータを削除する。
特定のユースケースと注意が必要なユーザーのロギングを調整する
VPC フローログは、ネットワーク モニタリング、フォレンジック、リアルタイム セキュリティ分析、費用の最適化に利用できます。VPC フローログは、サブネット レベルで有効または無効にできます。VPC フローログをサブネットで有効にすると、そのサブネット内のすべての VM インスタンスからデータが収集されます。
こうしたログには、VM インスタンスが送受信するネットワーク フローのサンプルが記録されます。ロギングのユースケースは、どのサブネットでどれくらいの期間ロギングが必要かを決定するのに役立ちます。
フローログは、Compute Engine VM から接続ごとに 5 秒間隔で集計され、リアルタイムでエクスポートされます。Cloud Logging でフローログを表示し、Cloud Logging のエクスポートがサポートする任意の宛先にエクスポートできます。
Logging のログ取り込みページでは、プロジェクト内のログのボリュームを追跡し、すべてのログ取り込みを無効にしたり、不要なログエントリを除外（破棄）したりできます。これにより、ログの料金を最小限に抑えて毎月の割り当てを超えないようにすることが可能です。
ログは運用とセキュリティの両面で重要な役割を果たしますが、ログを確認してアクションを起こさない限り役に立ちません。注意が必要なユーザーのログを調整することは、VPC ネットワークの運用とセキュリティで実績を確保するのに役立ちます。
詳細については、VPC フローログの使用をご覧ください。
長時間接続する VPC ネットワークのログ集計間隔を長くする
長時間接続する VPC ネットワークでは、生成されるログの数を大幅に減らして迅速かつ容易に分析を行えるように、ログ集計間隔を 15 分に設定します。
ログ集計間隔を長くするとよいワークフローの例は、ネットワーク モニタリングです。このワークフローには次のようなタスクが含まれます。
- ネットワーク診断を実行する
- VM とアプリケーションでフローログをフィルタリングし、トラフィックの変化を把握する
- トラフィックの増加を分析してキャパシティを予測する
VPC フローログのサンプリングを使用してボリュームを削減する
VPC フローログのサンプリングを使用して VPC フローログのボリュームを削減します。その場合も、低レベルのサンプルと集計ビューは引き続き閲覧できます。
サンプリングを使用してボリュームを削減するワークフローの例として、ネットワーク使用量の把握とネットワーク トラフィック費用の最適化があります。このワークフローには次のようなタスクが含まれます。
- リージョンおよびゾーン間のトラフィックの見積もり
- インターネット上の特定の国へのトラフィックの見積もり
- トラフィック使用量が特に多いプロセスの特定
IP とポートのデータのみが必要な場合は追加のメタデータを削除する
IP アドレスとポートのみを監視するセキュリティ ユースケースでは、追加のメタデータを削除して、Cloud Logging で消費されるデータの量を減らします。
メタデータを削除するとよいワークフローの例は、ネットワーク フォレンジックです。このワークフローには次のようなタスクが含まれます。
- どの IP が、いつ、どの相手と通信したかを特定する
- ネットワーク フローを分析して、不正アクセスされた IP アドレスを発見する
リファレンス アーキテクチャ
このセクションでは、このドキュメントのおすすめの方法に対応するいくつかのアーキテクチャについて説明します。
単一プロジェクト、単一 VPC ネットワーク
この最初のリファレンス アーキテクチャは、可用性の高いアーキテクチャを複数のリージョンにデプロイするために必要なすべてのコンポーネントを含み、サブネット レベルの分離とオンプレミス データセンターへの 99.99% の SLA 接続を備えています。
単一ホスト プロジェクト、複数サービス プロジェクト、単一共有 VPC
このアーキテクチャは、最初のリファレンス アーキテクチャに基づいて構築されます。共有 VPC ホスト プロジェクトと複数のサービス プロジェクトにより、管理者はインスタンスの作成や管理などの管理責任をサービス プロジェクト管理者に委任しつつ、サブネット、ルート、ファイアウォールなどのネットワーク リソースを集中管理できます。
複数ホスト プロジェクト、複数サービス プロジェクト、複数共有 VPC
次の図は、VPC 分離のアーキテクチャを示しています。これは、prod を他のプロジェクトから分離した高可用性設計です。監査要件（PCI など）、環境間の割り当ての考慮事項、論理的な分離のためのもう 1 つのレイヤなど、VPC の分離を検討する理由はたくさんあります。ロケーションごとに必要な相互接続は 2 つだけ（冗長性のため）ですが、それらから複数の VPC ネットワークまたはリージョンへの相互接続を複数追加できます。
分離を行った場合、プロキシ、認証、ディレクトリ サービスなどのコアサービスを配置する場所の決定に応じて、レプリケーションが必要になることもあります。共有サービス VPC ネットワークは、このレプリケーションを回避するために役立ちます。また、VPC ネットワーク ピアリングを介してそうしたサービスを他の VPC ネットワークと共有する一方で、同時に管理とデプロイを集中化できます。
VPC ネットワーク間のステートフル L7 ファイアウォール
このアーキテクチャには、VPC ネットワーク間のマルチ NIC ブリッジとして機能する L7 次世代ファイアウォール（NEGW）アプライアンスによってブリッジされる複数の VPC ネットワークがあります。
検査用として L7 NGFW の外部で終端するハイブリッド相互接続とインターネット ベースの接続を終端する信頼性の低い外部 VPC ネットワークが導入されています。この設計には多くのバリエーションがありますが、トラフィックが信頼できる VPC ネットワークに到達する前に、ファイアウォールを通過するトラフィックをフィルタリングすることが重要な原則となります。
この設計では、VM ベースの NGFW を挿入するプロジェクト内に各 VPC ネットワークが存在する必要があります。割り当てはプロジェクト レベルで適用されるため、すべての VPC リソースの合計を考慮する必要があります。
次のステップ
- VPC の詳細な解説とベスト プラクティス（Cloud NEXT '18 の動画）
- ハイブリッドおよびマルチクラウドのネットワーク トポロジ
- Google Cloud アーキテクチャ フレームワークでのネットワーク設計のベスト プラクティス
- Compute Engine のリージョン選択に関するベスト プラクティス
- データセンター プロフェッショナルのための Google Cloud: ネットワーキング
- Virtual Private Cloud のドキュメント
- ネットワークの概要
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。