人脈

Last reviewed 2023-12-20 UTC

ネットワーキングは、リソースが Google Cloud 組織内で、およびクラウド環境とオンプレミス環境の間で通信するために不可欠です。このセクションでは、VPC ネットワーク、IP アドレス空間、DNS、ファイアウォール ポリシー、オンプレミス環境への接続に関するブループリントの構造について説明します。

ネットワーク トポロジ

ブループリント リポジトリには、ネットワーク トポロジ向けに次のオプションが用意されています。

  • 環境ごとに個別の共有 VPC ネットワークを使用し、複数の環境間での直接のネットワーク トラフィックを許可しない。
  • ハブ ネットワークを追加して Google Cloud の各環境を接続するハブ ���ンド スポーク モデルを使用し、複数の環境間でのネットワーク トラフィックをネットワーク仮想アプライアンス（NVA）で制御する。

複数の環境間でネットワークを直接接続しない場合は、デュアル共有 VPC ネットワーク トポロジを選択します。環境内のすべてのサーバーへのダイレクト ネットワーク パスを必要とする既存のツールを使用する場合など、NVA によってフィルタされる環境間のネットワーク接続を許可するには、ハブ アンド スポーク ネットワーク トポロジを選択します。

共有 VPC では責任を明確に分離できるため、どちらのトポロジでも共有 VPC を主要なネットワーク構成として使用します。ネットワーク管理者は、一元管理されたホスト プロジェクトでネットワーク リソースを管理します。ワークロード チームは、独自のアプリケーション リソースをデプロイして、ホスト プロジェクトに接続されたサービス プロジェクトでネットワーク リソースを消費します。

どちらのトポロジにも、各 VPC ネットワークのベース バージョンと制限付きバージョンが含まれています。ベース VPC ネットワークはセンシティブ データを含まないリソースに使用し、制限付き VPC ネットワークは VPC Service Controls を必要とするセンシティブ データを含むリソースに使用します。VPC Service Controls を実装する方法について詳しくは、VPC Service Controls でリソースを保護するをご覧ください。

デュアル共有 VPC ネットワーク トポロジ

Google Cloud 上の開発環境、非本番環境、本番環境のネットワークを隔離する必要がある場合は、デュアル共有 VPC ネットワーク トポロジをおすすめします。このトポロジでは、環境ごとに個別の共有 VPC ネットワークを使用します。各環境はさらにベース共有 VPC ネットワークと制限付き共有 VPC ネットワークに分割されます。

次の図は、デュアル共有 VPC ネットワーク トポロジを示しています。

ブループリントの VPC ネットワーク。

この図は、デュアル共有 VPC トポロジの次の重要なコンセプトを表しています。

  • 各環境（本番環境、非本番環境、開発環境）には、ベース ネットワーク用および制限付きネットワーク用にそれぞれ 1 つずつの共有 VPC ネットワークがあります。この図には本番環境のみが示されていますが、環境ごとに同じパターンが繰り返されます。
  • 各共有 VPC ネットワークには 2 つのサブネットがあり、各サブネットは異なるリージョンにあります。
  • オンプレミス リソースとの接続は、各共有 VPC ネットワークの Dedicated Interconnect インスタンスに対応する 4 つの VLAN アタッチメント経由で有効になりますが、これには 4 つの Cloud Router サービス（冗長性を確保するために各リージョンに 2 つ）が使用されます。詳細については、オンプレミス環境�� Google Cloud 間のハイブリッド接続をご覧ください。

設計上、このトポロジではネットワーク トラフィックが複数の環境間で直接流れることはありません。ネットワーク トラフィックが複数の環境間で直接流れるようにする必要がある場合は、そのネットワーク パスを許可するために追加の手順を実施する必要があります。たとえば、ある VPC ネットワークから別の VPC ネットワークにサービスを公開する Private Service Connect エンドポイントを構成できます。あるいは、ある Google Cloud 環境からオンプレミス環境にトラフィックが流れ、その後で別の Google Cloud 環境に流れるようにオンプレミス ネットワークを構成することもできます。

ハブ アンド スポーク ネットワーク トポロジ

複数の環境のリソースへのダイレクト ネットワーク パスを必要とするリソースを Google Cloud にデプロイする場合は、ハブ アンド スポーク ネットワーク トポロジをおすすめします。

ハブ アンド スポーク トポロジではデュアル共有 VPC トポロジに含まれるいくつかのコンセプトを使用しますが、ハブ ネットワークを追加するためにトポロジを変更します。次の図は、ハブ アンド スポーク トポロジを示しています。

VPC ピアリングに基づくハブ アンド スポーク接続を使用する場合の example.com VPC ネットワーク構造

この図は、ハブ アンド スポーク ネットワーク トポロジの次の重要なコンセプトを表しています。

  • このモデルはハブ ネットワークを追加し、開発環境、非本番環境、本番環境の各ネットワーク（スポーク）は VPC ネットワーク ピアリングを介してハブ ネットワークに接続されます。また、割り当て上限の超過が予想される場合は、代わりに HA VPN ゲートウェイを使用できます。
  • オンプレミス ネットワークへの接続は、ハブ ネットワーク経由でのみ許可されます。すべてのスポーク ネットワークはハブ ネットワーク内の共有リソースと通信でき、このパスを使用してオンプレミス ネットワークに接続できます。
  • ハブ ネットワークには、内部ネットワーク ロードバランサ インスタンスの背後に冗長構成でデプロイされた各リージョンの NVA が含まれています。この NVA は、スポーク ネットワーク間のトラフィックの通信を許可または拒否するゲートウェイとして機能します。
  • ハブ ネットワークは、他のすべてのネットワークへの接続を必要とするツールもホストします。たとえば、一般的な環境の構成管理用のツールを VM インスタンスにデプロイできます。
  • ハブ アンド スポーク モデルは、各ネットワークのベース バージョンと制限付きバージョンで複製されます。

スポーク間のトラフィックを有効にするため、ブループリントはネットワーク間のゲートウェイとして機能するハブ共有 VPC ネットワークに NVA をデプロイします。ルートは、カスタムルート交換によってハブからスポーク VPC ネットワークへ交換されます。このシナリオでは VPC ネットワーク ピアリングは推移的ではなく、スポーク VPC ネットワークは相互に直接データを交換できないため、スポーク間の接続は NVA を介してルーティングする必要があります。スポーク間のトラフィックを選択的に許可するよう、仮想アプライアンスを構成する必要があります。

プロジェクトのデプロイ パターン

ワークロードの新しいプロジェクトを作成するときは、このプロジェクトのリソースを既存のネットワークに接続する方法を決定する必要があります。次の表では、ブループリントで使用されるプロジェクトをデプロイするパターンについて説明します。

パターン 説明 使用例
共有のベース プロジェクト

これらのプロジェクトは、ベース共有 VPC ホスト プロジェクトに対するサービス プロジェクトとして構成されます。

プロジェクト内のリソースに次の条件がある場合は、このパターンを使用します。

  • オンプレミス環境または同じ共有 VPC トポロジ内のリソースへのネットワーク接続が必要。
  • プライベート仮想 IP アドレスに含まれる Google サービスへのネットワーク パスが必要。
  • VPC Service Controls を必要としない。
 example_base_shared_vpc_project.tf
共有の制限付きプロジェクト

これらのプロジェクトは、制限付き共有 VPC ホスト プロジェクトに対するサービス プロジェクトとして構成されます。

プロジェクト内のリソースに次の条件がある場合は、このパターンを使用します。

  • オンプレミス環境または同じ共有 VPC トポロジ内のリソースへのネットワーク接続が必要。
  • 制限付き仮想 IP アドレスに含まれる Google サービスへのネットワーク パスが必要。
  • VPC Service Controls が必要。
 example_restricted_shared_vpc_project.tf
フローティング プロジェクト

フローティング プロジェクトは、トポロジ内の他の VPC ネットワークには接続されていません。

プロジェクト内のリソースに次の条件がある場合は、このパターンを使用します。

  • オンプレミス環境または共有 VPC トポロジ内のリソースへのフルメッシュ接続を必要としない。
  • VPC ネットワークを必要としない、またはメインの VPC ネットワーク トポロジとは無関係にこのプロジェクトの VPC ネットワークを管理する（すでに使用されている範囲と競合する IP アドレス範囲を使用する場合など）。

フローティング プロジェクトの VPC ネットワークをメインの VPC ネットワーク トポロジと切り離したまま、ネットワーク間に限られた数のエンドポイントを公開するといったシナリオが考えられます。その場合は、Private Service Connect を使用してサービスを公開し、ネットワーク全体を公開することなく、VPC ネットワーク間で個々のエンドポイントへのネットワーク アクセスを共有します。

 example_floating_project.tf
ピアリング プロジェクト

ピアリング プロジェクトは独自の VPC ネットワークを作成し、トポロジ内の他の VPC ネットワークにピアリングします。

プロジェクト内のリソースに次の条件がある場合は、このパターンを使用します。

  • 直接ピアリングされた VPC ネットワーク内のネットワーク接続が必要だが、オンプレミス環境または他の VPC ネットワークへの推移的接続を必要としない。
  • このプロジェクトの VPC ネットワークをメインのネットワーク トポロジから独立して管理する必要がある。

ピアリング プロジェクトを作成する場合は、競合しない IP アドレス範囲を割り振り、ピアリング グループの割り当てを計画する必要があります。

 example_peering_project.tf

IP アドレスの割り振り

このセクションでは、ブループリント アーキテクチャで IP アドレスの範囲を割り振る方法について説明します。既存のハイブリッド環境で使用できる IP アドレスに基づいて、使用する特定の IP アドレス範囲の変更が必要になる場合があります。

次の表は、ブループリントに割り振られる IP アドレス空間の内訳を示しています。ハブ環境は、ハブ アンド スポーク トポロジにのみ適用されます。

用途 VPC タイプ リージョン ハブ環境 開発環境 非本番環境 本番環境
プライマリ サブネット範囲 ベース リージョン 1 10.0.0.0/18 10.0.64.0/18 10.0.128.0/18 10.0.192.0/18
リージョン 2 10.1.0.0/18 10.1.64.0/18 10.1.128.0/18 10.1.192.0/18
未割り当て 10.{2-7}.0.0/18 10.{2-7}.64.0/18 10.{2-7}.128.0/18 10.{2-7}.192.0/18
制限付き リージョン 1 10.8.0.0/18 10.8.64.0/18 10.8.128.0/18 10.8.192.0/18
リージョン 2 10.9.0.0/18 10.9.64.0/18 10.9.128.0/18 10.9.192.0/18
未割り当て 10.{10-15}.0.0/18 10.{10-15}.64.0/18 10.{10-15}.128.0/18 10.{10-15}.192.0/18
プライベート サービス アクセス ベース グローバル 10.16.0.0/21 10.16.8.0/21 10.16.16.0/21 10.16.24.0/21
制限付き グローバル 10.16.32.0/21 10.16.40.0/21 10.16.48.0/21 10.16.56.0/21
Private Service Connect エンドポイント ベース グローバル 10.17.0.1/32 10.17.0.2/32 10.17.0.3/32 10.17.0.4/32
制限付き グローバル 10.17.0.5/32 10.17.0.6/32 10.17.0.7/32 10.17.0.8/32
プロキシ専用サブネット ベース リージョン 1 10.18.0.0/23 10.18.2.0/23 10.18.4.0/23 10.18.6.0/23
リージョン 2 10.19.0.0/23 10.19.2.0/23 10.19.4.0/23 10.19.6.0/23
未割り当て 10.{20-25}.0.0/23 10.{20-25}.2.0/23 10.{20-25}.4.0/23 10.{20-25}.6.0/23
制限付き リージョン 1 10.26.0.0/23 10.26.2.0/23 10.26.4.0/23 10.26.6.0/23
リージョン 2 10.27.0.0/23 10.27.2.0/23 10.27.4.0/23 10.27.6.0/23
未割り当て 10.{28-33}.0.0/23 10.{28-33}.2.0/23 10.{28-33}.4.0/23 10.{28-33}.6.0/23
セカンダリ サブネット範囲 ベース リージョン 1 100.64.0.0/18 100.64.64.0/18 100.64.128.0/18 100.64.192.0/18
リージョン 2 100.65.0.0/18 100.65.64.0/18 100.65.128.0/18 100.65.192.0/18
未割り当て 100.{66-71}.0.0/18 100.{66-71}.64.0/18 100.{66-71}.128.0/18 100.{66-71}.192.0/18
制限付き リージョン 1 100.72.0.0/18 100.72.64.0/18 100.72.128.0/18 100.72.192.0/18
リージョン 2 100.73.0.0/18 100.73.64.0/18 100.73.128.0/18 100.73.192.0/18
未割り当て 100.{74-79}.0.0/18 100.{74-79}.64.0/18 100.{74-79}.128.0/18 100.{74-79}.192.0/18

上記の表は、IP アドレス範囲の割り振りに関する次のコンセプトを表しています。

  • IP アドレスの割り振りは、ベース共有 VPC、制限付き共有 VPC、リージョン、環境の組み合わせごとに範囲が細分化されています。
  • 一部のリソースはグローバルであり、リージョンごとの細分化を必要としません。
  • デフォルトでは、リージョン リソースの場合、ブループリントは 2 つのリージョンにデプロイされます。さらに、未使用の IP アドレス範囲があるため、6 つのリージョンに拡張できます。
  • ハブ ネットワークはハブ アンド スポーク ネットワーク トポロジでのみ使用されますが、開発環境、非本番環境、本番環境は両方のネットワーク トポロジで使用されます。

次の表は、各タイプの IP アドレス範囲がどのように使用されるかを示しています。

用途 説明
プライマリ サブネット範囲 VPC ネットワークにデプロイするリソース（仮想マシン インスタンスなど）は、これらの範囲の内部 IP アドレスを使用します。
プライベート サービス アクセス Cloud SQL などの一部の Google Cloud サービスでは、プライベート サービス アクセス用のサブネット範囲を事前に割り振る必要があります。ブループリントは共有 VPC ネットワークごとに /21 範囲をグローバルに予約し、プライベート サービス アクセスを必要とするサービスに IP アドレスを割り振ります。プライベート サービス アクセスを使用するサービスを作成する場合は、予約された /21 範囲から /24 リージョン サブネットを割り振ります。
Private Service Connect このブループリントは VPC ネットワークごとに Private Service Connect エンドポイントをプロビジョニングして、Google Cloud APIs と通信します。このエンドポイントを使用すると、VPC ネットワーク内のリソースはインターネットへのアウトバウンド トラフィックや一般公開されているインターネット範囲に依存することなく、Google Cloud APIs にアクセスできるようになります。
プロキシベースのロードバランサ 一部のタイプのアプリケーション ロードバランサでは、プロキシ専用サブネットを事前に割り振る必要があります。ブループリントでは、この範囲を必要とするアプリケーション ロードバランサはデプロイされませんが、範囲を事前に割り振ることで、特定のロードバランサ リソースを有効にするため新しいサブネット範囲をリクエストする必要がある場合に、ワークロードに対する負担を軽減できます。
セカンダリ サブネット範囲 コンテナベースのワークロードなどの一部のユースケースでは、セカンダリ範囲が必要です。このブループリントは、RFC 6598 IP アドレス空間からの範囲をセカンダリ範囲に割り振ります。

一元管理の DNS 設定

Google Cloud とオンプレミス環境間の DNS 解決には、2 つの権威 DNS システムを使用するハイブリッド アプローチをおすすめします。このアプローチでは、Cloud DNS が Google Cloud 環境の権威 DNS 解決を処理し、既存のオンプレミス DNS サーバーがオンプレミス リソースの権威 DNS 解決を処理します。オンプレミス環境と Google Cloud 環境では、リクエストの転送を通じて環境間の DNS ルックアップが行われます。

次の図は、このブループリントで使用される複数の VPC ネットワークにまたがる DNS トポロジを示しています。

ブループリントの Cloud DNS 設定。

この図は、ブループリントによってデプロイされる DNS 設計の次のコンポーネントを表しています。

  • 共通フォルダ内の DNS ハブ プロジェクトは、オンプレミス環境と Google Cloud 環境間の DNS 交換の中心となります。DNS 転送には、ネットワーク トポロジですでに構成されているものと同じ Dedicated Interconnect インスタンスと Cloud Router を使用します。
    • デュアル共有 VPC トポロジの場合、DNS ハブは本番環境のベース共有 VPC ネットワークを使用します。
    • ハブ アンド スポーク トポロジの場合、DNS ハブはハブのベース共有 VPC ネットワークを使用します。
  • 各共有 VPC ネットワーク内のサーバーは、各共有 VPC ホスト プロジェクトの Cloud DNS と DNS ハブの間で構成された DNS 転送を通じて他の共有 VPC ネットワークからの DNS レコードを解決できます。
  • オンプレミス サーバーは、オンプレミス サーバーからのクエリを許可する DNS サーバー ポリシーを使用して Google Cloud 環境の DNS レコードを解決できます。このブループリントは、DNS ハブ内のインバウンド サーバー ポリシーを構成して IP アドレスを割り振り、オンプレミス DNS サーバーはこれらのアドレスにリクエストを��送します。Google Cloud へのすべての DNS リクエストは、まず DNS ハブに到達し、次に DNS ピアからのレコードが解決されます。
  • Google Cloud のサーバーは、オンプレミス サーバーにクエリを送信する転送ゾーンを使用して、オンプレミス環境の DNS レコードを解決できます。オンプレミス環境へのすべての DNS リクエストは、DNS ハブから送信されます。DNS リクエストの送信元は 35.199.192.0/19 です。

ファイアウォール ポリシー

Google Cloud には、複数のタイプのファイアウォール ポリシーがあります。階層型ファイアウォール ポリシーは組織レベルまたはフォルダレベルで適用され、階層内のすべてのリソースにわたってファイアウォール ポリシールールを一貫して継承します。また、VPC ネットワークごとにネットワーク ファイアウォール ポリシーを構成できます。このブループリントは、これらのファイアウォール ポリシーを組み合わせて、階層型ファイアウォール ポリシーを使用してすべての環境に共通の設定を適用し、ネットワーク ファイアウォール ポリシーを使用して個々の VPC ネットワークごとにより具体的な設定を適用します。

このブループリントは、以前の VPC ファイアウォール ルールを使用しません。ファイアウォール ポリシーのみを使用し、以前の VPC ファイアウォール ルールと併用しないことをおすすめします。

階層型ファイアウォール ポリシー

このブループリントは、単一の階層型ファイアウォール ポリシーを定義し、そのポリシーを本番環境、非本番環境、開発環境、ブートストラップ、共通の各フォルダに適用します。この階層型ファイアウォール ポリシーにはすべての環境に幅広く適用する必要があるルールが含まれており、きめ細かいルールの評価は個々の環境のネットワーク ファイアウォール ポリシーに委任されます。

次の表は、ブループリントによってデプロイされる階層型ファイアウォール ポリシールールを示しています。

ルールの説明 トラフィックの方向 フィルタ（IPv4 範囲） プロトコルとポート アクション
RFC 1918 からのインバウンド トラフィックの評価を階層の下位レベルに委任します。 Ingress

192.168.0.0/16、10.0.0.0/8、172.16.0.0/12

 all Go to next
RFC 1918 へのアウトバウンド トラフィックの評価を階層の下位レベルに委任します。 Egress

192.168.0.0/16、10.0.0.0/8、172.16.0.0/12

 all Go to next
TCP 転送用の IAP Ingress

35.235.240.0/20

 tcp:22,3390 Allow
Windows Server の有効化 Egress

35.190.247.13/32

 tcp:1688 Allow
Cloud Load Balancing のヘルスチェック Ingress

130.211.0.0/22、35.191.0.0/16、209.85.152.0/22、209.85.204.0/22

 tcp:80,443 Allow

ネットワーク ファイアウォール ポリシー

このブループリントは、ネットワークごとにネットワーク ファイアウォール ポリシーを構成します。各ネットワーク ファイアウォール ポリシーには、Google Cloud サービスへのアクセスを許可し、他のすべての IP アドレスへの下り（��向き）トラフィックを拒否する最低限のルールセットがあります。

ハブ アンド スポーク モデルでは、ネットワーク ファイアウォール ポリシーにスポーク間の通信を許可する追加のルールが含まれています。ネットワーク ファイアウォール ポリシーは、あるスポークからハブまたは別のスポークへのアウトバウンド トラフィックを許可し、ハブ ネットワーク内の NVA からのインバウンド トラフィックを許可します。

次の表は、ブループリントの各 VPC ネットワークにデプロ��されるグローバル ネットワーク ファイアウォール ポリシーのルールを示しています。

ルールの説明 トラフィックの方向 フィルタ プロトコルとポート
Google Cloud APIs へのアウトバウンド トラフィックを許可します。 Egress 個々のネットワークごとに構成される Private Service Connect エンドポイント。Google Cloud APIs へのプライベート アクセスをご覧ください。 tcp:443
他のルールと一致しないアウトバウンド トラフィックを拒否します。 Egress すべて all

あるスポークから別のスポークへのアウトバウンド トラフィックを許可します（ハブ アンド スポーク モデルのみ）。

 Egress ハブ アンド スポーク トポロジで使用するすべての IP アドレスの合計。スポーク VPC から送信されるトラフィックは、まずハブ ネットワーク内の NVA にルーティングされます。 all

ハブ ネットワーク内の NVA からスポークへのインバウンド トラフィックを許可します（ハブ アンド スポーク モデルのみ）。

 Ingress ハブ ネットワーク内の NVA から送信されるトラフィック。 all

このブループリントを初めてデプロイするときは、VPC ネットワーク内の VM インスタンスは Google Cloud サービスと通信できますが、同じ VPC ネットワーク内の他のインフラストラクチャ リソースとは通信できません。VM インスタンスの通信を許可するには、ネットワーク ファイアウォール ポリシーとタグに、VM インスタンスの通信を明示的に許可するルールを追加する必要があります。タグは VM インスタンスに追加され、それらのタグに対してトラフィックが評価されます。タグには IAM コントロールが備わっているため、タグを一元的に定義して、その使用を他のチームに委任することもできます。

次の図は、カスタムタグとネットワーク ファイアウォール ポリシールールを追加して、ワークロードが VPC ネットワーク内で通信できるようにする方法の例を示しています。

example.com のファイアウォール ルール。

この図は、この例の次のコンセプトを表しています。

  • ネットワーク ファイアウォール ポリシーには、すべての送信元からのアウトバウンド トラフィックを優先値 65530 で拒否する Rule 1 が含まれています。
  • ネットワーク ファイアウォール ポリシーには、service=frontend タグを持つインスタンスから service=backend タグを持つインスタンスへのインバウンド トラフィックを優先値 999 で許可する Rule 2 が含まれています。
  • トラフィックが Rule 2 で許可されているタグと一致するため、instance-2 VM は instance-1 からのトラフィックを受信できます。優先値に基づいて、Rule 1 が評価される前に Rule 2 と照合されるからです。
  • instance-3 VM はトラフィックを受信できません。そのトラフィックと一致するファイアウォール ポリシールールは Rule 1 のみであるため、instance-1 からのアウトバウンド トラフィックは拒否されます。

Google Cloud APIs へのプライベート アクセス

VPC ネットワークまたはオンプレミス環境のリソースが Google Cloud サービスにアクセスできるようにするには、パブリック API エンドポイントへのアウトバウンド インターネット トラフィックではなく、プライベート接続をおすすめします。このブループリントは、すべてのサブネットで限定公開の Google アクセスを構成し、Private Service Connect で内部エンドポイントを作成して、Google Cloud サービスと通信します。これらのコントロールを組み合わせることで、インターネットのアウトバウンド トラフィックや一般公開されたインターネット範囲を使用することなく、Google Cloud サービスへのプライベート パスを許可できます。

このブループリントは、どのネットワークでどのサービスにアクセスできるかを区別するために、API バンドルを使用して Private Service Connect エンドポイントを構成します。ベース ネットワークは all-apis バンドルを使用して、すべての Google サービスにアクセスできます。制限付きネットワークは vpcsc バンドルを使用して、VPC Service Controls をサポートする限定されたサービスのセットにアクセスできます。

オンプレミス環境内のホストからアクセスする場合は、次の表に示すようにエンドポイントごとにカスタム FQDN の規則を使用することをおすすめします。このブループリントは、異なる API バンドルのセットにアクセスするように構成された VPC ネットワークごとに一意の Private Service Connect エンドポイントを使用します。したがって、正しい API エンドポイントを使用してオンプレミス環境から VPC ネットワークにサービス トラフィックをルーティングする方法を検討する必要があります。また、VPC Service Controls を使用している場合は、Google Cloud サービスへのトラフィックが目的の境界内のエンドポイントに到達できるようにする必要があります。これらのエンドポイントへのアクセスを許可するよう DNS、ファイアウォール、ルーターのオンプレミスの制御を構成し、適切なエンドポイントを使用するようオンプレミス ホストを構成します。詳細については、エンドポイントから Google API にアクセスするをご覧ください。

次の表は、ネットワークごとに作成される Private Service Connect エンドポイントを示しています。

VPC 環境 API バンドル Private Service Connect エンドポイントの IP アドレス カスタム FQDN
ベース 共通 all-apis 10.17.0.1/32 c.private.googleapis.com
開発 all-apis 10.17.0.2/32 d.private.googleapis.com
非本番 all-apis 10.17.0.3/32 n.private.googleapis.com
本番 all-apis 10.17.0.4/32 p.private.googleapis.com
制限付き 共通 vpcsc 10.17.0.5/32 c.restricted.googleapis.com
開発 vpcsc 10.17.0.6/32 d.restricted.googleapis.com
非本番 vpcsc 10.17.0.7/32 n.restricted.googleapis.com
本番 vpcsc 10.17.0.8/32 p.restricted.googleapis.com

Google Cloud サービスのトラフィックで正しいエンドポイントへの DNS ルックアップが行われるようにするため、このブループリントは VPC ネットワークごとにプライベート DNS ゾーンを構成します。次の表は、これらのプライベート DNS ゾーンを示しています。

プライベート ゾーン名 DNS 名 レコードタイプ データ
googleapis.com. *.googleapis.com. CNAME private.googleapis.com.（ベース ネットワークの場合）または restricted.googleapis.com.（制限付きネットワークの場合）
private.googleapis.com（ベース ネットワークの場合）または restricted.googleapis.com（制限付きネットワークの場合） A 該当する VPC ネットワークの Private Service Connect エンドポイントの IP アドレス。
gcr.io. *.gcr.io CNAME gcr.io.
gcr.io A 該当する VPC ネットワークの Private Service Connect エンドポイントの IP アドレス。
pkg.dev. *.pkg.dev. CNAME pkg.dev.
pkg.dev. A 該当する VPC ネットワークの Private Service Connect エンドポイントの IP アドレス。

このブループリントには、これらの Private Service Connect エンドポイントが一貫して使用されるようにする追加の構成があります。各共有 VPC ネットワークでは、次のルールも適用されます。

  • すべてのソースから TCP:443 上の Private Service Connect エンドポイントの IP アドレスへのアウトバウンド トラフィックを許可するネットワーク ファイアウォール ポリシールール。
  • 0.0.0.0/0 へのアウトバウンド トラフィックを拒否するネットワーク ファイアウォール ポリシールール。これには、Google Cloud サービスへのアクセスに使用されるデフォルト ドメインが含まれます。

インターネット接続

このブループリントでは、VPC ネットワークとインターネット間のインバウンドまたはアウトバウンドのトラフィックは許可されません。インターネット接続が必要なワークロードの場合は、必要なアクセスパスを設計するために追加の手順を踏む必要があります。

インターネットへのアウトバウンド トラフィックを必要とするワークロードの場合は、Cloud NAT 経由でアウトバウンド トラフィックを管理して、未承諾のインバウンド接続なしでアウトバウンド トラフィックを許可することをおすすめします。または、より細やかな制御のため Secure Web Proxy 経由で信頼できるウェブサービスへのアウトバウンド トラフィックのみを許可することをおすすめします。

インターネットからのインバウンド トラフィックを必要とするワークロードの場合は、DDoS 対��と WAF 対策を活用できるように、Cloud Load Balancing と Google Cloud Armor を使用してワークロードを設計することをおすすめします。

VM 上の外部 IP アドレスを使用して、インターネットと VM 間の直接接続を許可するワークロードを設計することはおすすめしません。

オンプレミス環境と Google Cloud 間のハイブリッド接続

オンプレミス環境と Google Cloud 間の接続を確立するため、Dedicated Interconnect を使用してセキュリティと信頼性を最大化することをおすすめします。Dedicated Interconnect 接続は、オンプレミス ネットワークと Google Cloud 間の直接リンクです。

次の図は、オンプレミス環境と Google Virtual Private Cloud ネットワーク間のハイブリッド接続を示しています。

ハイブリッド接続の構造。

この図は、Dedicated Interconnect で 99.99% の可用性を実現するパターンを構成する次のコンポーネントを表しています。

  • ある大都市圏（メトロ）に 2 つ、別の大都市圏に 2 つの接続で構成された 4 つの Dedicated Interconnect 接続。各メトロ内では、コロケーション施設内に 2 つの異なるゾーンがあります。
  • 接続は 2 つのペアに分割され、各ペアは別々のオンプレミス データセンターに接続されます。
  • VLAN アタッチメントは、共有 VPC トポロジに接続している Cloud Router に各 Dedicated Interconnect インスタンスを接続するために使用されます。
  • 各共有 VPC ネットワークには 4 つの Cloud Router（リージョンごとに 2 つ）があり、動的ルーティング モードは global に設定されています。これにより、すべての Cloud Router はリージョンに関係なくすべてのサブネットを通知できます。

グローバル動的ルーティングを使用すると、Cloud Router は VPC ネットワーク内のすべてのサブネットへのルートをアドバタイズします。Cloud Router は、ローカル サブネット（Cloud Router のリージョン内にあるサブネット）と比較して優先度が低いリモート サブネット（Cloud Router のリージョン外のサブネット）にルートをアドバタイズします。必要に応じて、Cloud Router の BGP セッションを構成するときに、アドバタイズされたプレフィックスと優先度を変更できます。

Google Cloud からオンプレミス環境へのトラフィックは、クラウド リソースに最も近い Cloud Router を使用します。単一リージョン内では、オンプレミス ネットワークへの複数のルートに同じ Multi-Exit Discriminator（MED）値があり、Google Cloud は等価コスト マルチパス（ECMP）ルーティングを使用して、考えられるすべてのルート間でアウトバウンド トラフィックを分散します。

オンプレミス構成の変更

オンプレミス環境と Google Cloud 間の接続を構成するには、オンプレミス環境で追加の変更を構成する必要があります。このブループリントの Terraform コードにより Google Cloud リソースが自動的に構成されますが、オンプレミス ネットワーク リソースは変更されません。

オンプレミス環境から Google Cloud へのハイブリッド接続のコンポーネントの一部は、ブループリントによって自動的に有効になります。これには次のようなものがあります。

  • Cloud DNS は、DNS 設定で説明されているように、すべての共有 VPC ネットワーク間で 1 つのハブに DNS 転送されるように構成されます。Cloud DNS サーバー ポリシーは、インバウンド フォワーダーの IP アドレスを使用して構成されます。
  • Cloud Router は、すべてのサブネットのルートと、Private Service Connect エンドポイントで使用される IP アドレスのカスタムルートをエクスポートするように構成されています。

ハイブリッド接続を有効にするには、次の追加手順を行う必要があります。

  1. Dedicated Interconnect 接続を注文します。
  2. IP アドレス空間の割り振りで定義された内部 IP アドレス空間へのアウトバウンド トラフィックを許可するよう、オンプレミス ルーターとファイアウォールを構成します。
  3. ブループリントによってすでに構成されたインバウンド フォワーダーの IP アドレスに、Google Cloud にバインドされた DNS ルックアップを転送するようオンプレミス DNS サーバーを構成します。
  4. Cloud DNS 転送ゾーン（35.199.192.0/19）からの DNS クエリを受け入れるよう、オンプレミスの DNS サーバー、ファイアウォール、ルーターを構成します。
  5. Cloud APIs へのプライベート アクセスで定義された IP アドレスを使用してオンプレミス ホストから Google Cloud サービスへのクエリに応答するよう、オンプレミス DNS サーバーを構成します。
  6. Dedicated Interconnect 接続を介した転送データの暗号化では、Cloud Interconnect の MACsec を構成するか、IPsec 暗号化用に Cloud Interconnect を介した HA VPN を構成します。

詳細については、オンプレミス ホストの限定公開の Google アクセスを構成するをご覧ください。

次のステップ

  • 検出制御（このシリーズの次のドキュメント）を確認する。