共有 VPC の概要

共有 VPC を使用して、組織は複数のプロジェクトから共通の Virtual Private Cloud(VPC)ネットワークにリソースを接続できるため、そのネットワークの内部 IP を使用して、安全で効率的な相互通信ができます。共有 VPC を使用する場合、プロジェクトをホスト プロジェクトとして指定し、他のサービス プロジェクトをホスト プロジェクトに接続します。ホスト プロジェクトの VPC ネットワークは、共有 VPC ネットワークといいます。サービス プロジェクトの適格リソースは共有 VPC ネットワーク内のサブネットを使用できます。

組織管理者は共有 VPC を使用して、サブネット、ルート、ファイアウォールなどのネットワーク リソースを集中管理しながら、インスタンスの作成や管理などの管理責任をサービス プロジェクト管理者に委任できます。このモデルにより、組織は次のことを実現できます。

  • 最小限の権限でネットワーク管理、監査、アクセス制御のセキュリティのベスト プラクティスを実装する。共有 VPC の管理者は、ネットワークに影響を及ぼす変更をサービス プロジェクト管理者に許可することなく、ネットワークの管理作業を共有 VPC ネットワーク内のネットワーク管理者とセキュリティ管理者に委任できます。サービス プロジェクト管理者に委任するのは、共有 VPC ネットワークを使用するインスタンスの作成と管理だけです。詳細については、管理者と IAM をご覧ください。
  • 管理責任を委任しながら、組織内の複数のサービス プロジェクトに対してネットワーク レベルで一貫したアクセス制御ポリシーを適用する。たとえば、サービス プロジェクト管理者は、プロジェクトの Compute インスタンス管理者として、共有 VPC ホスト プロジェクトで承認されたサブネットを使用するインスタンスの作成や削除ができます。
  • サービス プロジェクトを使用して、予算配分または内部コストセンターを分ける。詳細については、課金をご覧ください。

コンセプト

組織、フォルダ、プロジェクト

共有 VPC は、同じ組織内のプロジェクトに接続します。参加するホスト プロジェクトとサービス プロジェクトは、異なる組織に属することはできません。リンクされたプロジェクトは同一または異なるフォルダに配置できますが、異なるフォルダにある場合、管理者は両方のフォルダに対する共有 VPC 管理者権限を持っている必要があります。組織、フォルダ、プロジェクトの詳細については、Google Cloud リソース階層をご覧ください。

共有 VPC に参加するプロジェクトは、ホスト プロジェクトまたはサービス プロジェクトのいずれかになります。

  • ホスト プロジェクトには 1 つ以上の共有 VPC ネットワークが含まれています。共有 VPC 管理者は、まず、プロジェクトをホスト プロジェクトとして有効化する必要があります。その後、共有 VPC 管理者は 1 つ以上のサービス プロジェクトをそれに接続できます。

  • サービス プロジェクトは、共有 VPC 管理者がホスト プロジェクトに接続したプロジェクトです。接続したプロジェクトには、共有 VPC への参加が許可されます。組織内の異なる部門やチームが別々のサービス プロジェクトを運営管理するのが一般的です。

  • 1 つのプロジェクトを同時にホスト プロジェクトとサービス プロジェクトの両方にすることはできません。このため、サービス プロジェクトを別のサービス プロジェクトのホスト プロジェクトにすることはできません。

  • 複数のホスト プロジェクトを作成して使用することはできますが、各サービス プロジェクトは 1 つのホスト プロジェクトにしか接続できません。詳細については、複数のホスト プロジェクトの例をご覧ください。

わかりやすくするために、共有 VPC に参加していないプロジェクトはスタンドアロン プロジェクトと呼びます。これにより、ホスト プロジェクトとサービス プロジェクトのいずれでもないことが明確にわかります。

ネットワーク

共有 VPC ネットワークは、ホスト プロジェクトで定義された VPC ネットワークであり、サービス プロジェクト内の適格リソース用に集中管理された共有ネットワークとして使用できます。共有 VPC ネットワークは自動モードまたはカスタムモードのいずれかになりますが、レガシー ネットワークはサポートされていません。

ホスト プロジェクトが有効な場合、既存の VPC ネットワークはすべて共有 VPC ネットワークになります。また、その中で作成された新しいネットワークも自動的に共有 VPC ネットワークになります。このため、1 つのホスト プロジェクトに複数の共有 VPC ネットワークが存在する場合があります。

ホスト プロジェクトとサービス プロジェクトは、プロジェクト レベルのアタッチメントで接続されます。次の管理者と IAM セクションで説明するように、サービス プロジェクト管理者はホスト プロジェクト内の共有 VPC ネットワークのサブネットにアクセスできます。

組織のポリシーの制約

組織のポリシーと IAM 権限は連携して、異なるレベルのアクセス制御を提供します。組織のポリシーを使用すると、組織、フォルダ、プロジェクト レベルで制御設定ができます。

組織のポリシー管理者は、組織のポリシーで次の共有 VPC 制限を指定できます。

  • 非ホスト プロジェクトもしくは、フォルダまたは組織内の非ホスト プロジェクトを接続できるホスト プロジェクトを制限できます。この制約は、共有 VPC 管理者がホスト プロジェクトに、サービス プロジェクトを接続するときに適用されます。この制約は既存の接続には影響しません。ポリシーによって新しい接続が拒否されても、既存の接続はそのまま残ります。詳細については、constraints/compute.restrictSharedVpcHostProject の制約をご覧ください。

  • プロジェクト、フォルダ、組織レベルでサービス プロジェクトがアクセスできる共有 VPC サブネットを制限できます。この制約は、指定のサブネットで新しいリソースを作成する場合に適用され、既存のリソースには影響しません。ポリシーによって新しいリソースが追加できない場合も、既存のリソースは通常どおりサブネット内で動作します。詳細については、constraints/compute.restrictSharedVpcSubnetworks の制約をご覧ください。

管理者と IAM

共有 VPC では、委任管理に Identity and Access Management(IAM)役割を使用します。ユーザー、Google グループ、Google ドメイン、Google Cloud サービス アカウントなど、IAM メンバーに付与できる役割は次のとおりです。これらの管理者に連絡する必要がある場合は、組織またはプロジェクトの IAM ポリシーで検索できます。必要な権限がない場合は、組織内のネットワーク管理者またはプロジェクト管理者に連絡する必要があります。

必要な管理者の役割

管理者(IAM 役割) 目的
組織管理者resourcemanager.organizationAdmin
  • 組織内の IAM メンバー
組織管理者には、組織の resourcemanager.organizationAdmin 役割があります。組織管理者は、プロジェクトの作成と削除に必要な役割と、組織の共有 VPC 管理者役割を付与することで、共有 VPC 管理者を指名します。これらの管理者は組織レベルのポリシーを定義できますが、特定のフォルダとプロジェクトにアクションを実行するには、追加のフォルダとプロジェクトの役割が必要になります。
共有 VPC 管理者
compute.xpnAdmin
resourcemanager.projectIamAdmin
  • 組織内の IAM メンバー、または
  • フォルダ内の IAM メンバー(ベータ版)
共有 VPC 管理者には、組織または 1 つ以上のフォルダに対する共有 VPC 管理者compute.xpnAdminプロジェクト IAM 管理者resourcemanager.projectIamAdmin役割があります。この管理者は共有 VPC の設定に必要なさまざまなタスクを実行します。たとえば、ホスト プロジェクトの有効化や、サービス プロジェクトとホスト プロジェクトの接続を行います。また、共有 VPC ネットワークのサブネットの一部または全体に対するアクセス権をサービス プロジェクト管理者に委任します。通常、特定のホスト プロジェクトの共有 VPC 管理者はそのプロジェクトのオーナーになります。
組織に対する Compute Shared VPC 管理者の役割が割り当てられたユーザーは、組織内のすべてのフォルダに対して役割を持ちます。フォルダに対する役割が割り当てられたユーザーは、指定したフォルダおよびその下にネストされたフォルダに対して役割を持ちます。2 つの異なるフォルダにある複数のプロジェクトをリンクするには、共有 VPC 管理者はそれらの両方のフォルダに対する役割を持っている必要があります。
サービス プロジェクト管理者
compute.networkUser
  • 組織内の IAM メンバー、または
  • ホスト プロジェクト内の IAM メンバー、または
  • ホスト プロジェクトの一部のサブネット内の IAM メンバー
共有 VPC 管理者は、IAM メンバーに、ホスト プロジェクト全体または共有 VPC ネットワーク内の一部のサブネットのいずれかに対するネットワーク ユーザーcompute.networkUser)役割を付与することで、サービス プロジェクト管理者を定義します。また、サービス プロジェクト管理者はサービス プロジェクトに定義されているリソース全体に対する所有権を持ち、管理を行うため、対応するサービス プロジェクトに対するインスタンス管理者compute.instanceAdmin)役割を持つ必要があります。プロジェクト オーナーなど、サービス プロジェクトに対するその他の IAM 役割を持つこともできます。

サービス プロジェクト管理者

サービス プロジェクト管理者を定義するときに、共有 VPC 管理者は、ホスト プロジェクト全体または一部のサブネットを使用する権限を付与できます。

  • プロジェクト レベルの権限: 共有 VPC 管理者がホスト プロジェクト全体に対する compute.networkUser の役割をサービス プロジェクト管理者に付与した場合、ホスト プロジェクト内のすべてのサブネットを使用する権限を持つようにサービス プロジェクト管理者を定義できます。その結果、サービス プロジェクト管理者は、ホスト プロジェクトに新たに追加されるサブネットや VPC ネットワークを含め、ホスト プロジェクトのすべての VPC ネットワークのすべてのサブネットを使用できます。

  • サブネット レベルの権限: 共有 VPC 管理者が、一部のサブネットの compute.networkUser の役割をサービス プロジェクト管理者に付与した場合、より制限された、一部のサブネットだけを使用する権限をサービス プロジェクト管理者に付与できます。サブネット レベルの権限のみを持つサービス プロジェクト管理者は、サブネットのみを使用するように制限されています。ホスト プロジェクトに新しい共有 VPC ネットワークまたは新しいサブネットが追加された後、共有 VPC 管理者は compute.networkUser 役割の権限付与の状況を確認し、すべてのサービス プロジェクト管理者のサブネット レベルの権限が意図した構成と一致するようにする必要があります。

ネットワーク管理者とセキュリティ管理者

共有 VPC 管理者は、共有 VPC ネットワークの管理を含め、ホスト プロジェクト内のリソースを完全に制御できます。特定のネットワーク管理タスクを他の IAM メンバーに委任することもできます。

管理者 目的
ネットワーク管理者
  • ホスト プロジェクト内の IAM メンバー、または
  • 組織内の IAM メンバー
共有 VPC 管理者は、ホスト プロジェクトに対するネットワーク管理者compute.networkAdmin)役割を IAM メンバーに付与することで、ネットワーク管理者を定義します。ネットワーク管理者は、ファイアウォール ルールと SSL 証明書を除く、すべてのネットワーク リソースを完全に制御できます。
セキュリティ管理者
  • ホスト プロジェクト内の IAM メンバー、または
  • 組織内の IAM メンバー
共有 VPC 管理者は、ホスト プロジェクトに対するセキュリティ管理者compute.securityAdmin)役割を IAM メンバーに付与することで、セキュリティ管理者を定義できます。セキュリティ管理者は、ファイアウォール ルールと SSL 証明書を管理します。

仕様

割り当てと上限

共有 VPC ホスト プロジェクトには、標準のプロジェクトごとの VPC 割り当てが適用されます。共有 VPC ネットワークには、ネットワークごとの制限と、VPC ネットワークに対するインスタンスごとの制限が適用されます。さらに、ホスト プロジェクトとサービス プロジェクトの間の関係は、共有 VPC への固有の制限によって管理されます。

課金

共有 VPC ネットワークに参加しているリソースの使用料金は、リソースが配置されているサービス プロジェクトに対して課金されます。これは、リソースがホスト プロジェクトの共有 VPC ネットワークを使用している場合も同様です。

  • 共有 VPC ネットワークを使用するサービス プロジェクトのリソースの料金計算には、リソースがホスト プロジェクトにある場合と同じ料金体系とルールが適用されます。
  • リソースによって生成された下り(外向き)トラフィックの料金は、リソースが定義されているプロジェクトに課金されます。
    • インスタンスからの下り(外向き)トラフィックの料金は、インスタンスを含むプロジェクトに課金されます。たとえば、サービス プロジェクトで作成されたインスタンスが共有 VPC ネットワークを使用している場合、生成される下り(外向き)トラフィックの料金はこのサービス プロジェクトに課金されます。このように、共有 VPC を使用すると、組織のコストセンターにリソースをまとめることができます。
    • ロードバランサに関連するコストは、ロードバランサ コンポーネントを含むプロジェクトに課金されます。負荷分散と共有 VPC の詳細については、負荷分散のセクションをご覧ください。
    • VPN への下り(外向き)トラフィックの料金は、VPN ゲートウェイ リソースを含むプロジェクトに課金されます。たとえば、VPN ゲートウェイを共有 VPC ネットワークに作成した場合、このゲートウェイはホスト プロジェクトに含まれます。どのサービス プロジェクトが下り(外向き)トラフィックを開始したかにかかわらず、VPN ゲートウェイを通過する下り(外向き)トラフィックの料金はホスト プロジェクトに課金されます。

リソース

適格リソース

共有 VPC に参加可能なサービス プロジェクトのリソースは次のとおりです。ただし、制限事項がいくつかあります。

その他の適格リソースについては、関連するプロダクトのドキュメントを参照してください。

適格リソースに対する制限事項

共有 VPC に参加資格のあるリソースには、次の制限事項があります。

  • 共有 VPC ネットワークの使用は必須ではありません。たとえば、インスタンス管理者は、VPC ネットワークを使用するインスタンスをサービス プロジェクトに作成できます。サービス プロジェクトで定義されたネットワークは共有されません。

  • 共有 VPC ネットワークを使用するには、一部のリソースを再作成する必要があります。共有 VPC 管理者が既存のプロジェクトをホスト プロジェクトに接続すると、そのプロジェクトはサービス プロジェクトになりますが、既存のリソースは共有ネットワーク リソースを自動的に使用しません。共有 VPC ネットワークを使用するには、サービス プロジェクト管理者が適格リソースを作成し、共有 VPC ネットワークのサブネットを使用するように構成する必要があります。たとえば、共有 VPC ネットワークを使用するようにサービス プロジェクトの既存インスタンスを構成しなおすことはできませんが、新しいインスタンスを作成して共有 VPC ネットワーク内のサブネットを使用することはできます。この制限は非公開ゾーンに適用されます。

適格でないリソース

Deployment Manager で管理できるリソースは、単一プロジェクト内のリソースのみであるため、共有 VPC のシナリオで使用するには特定の設定を行う必要があります。詳細については、Deployment Manager による共有 VPC の作成をご覧ください。

IP アドレス

同じ共有 VPC ネットワークを使用してホスト プロジェクトに接続されたサービス プロジェクト内のインスタンスは、該当するファイアウォール ルールに従い、エフェメラル内部 IP アドレスまたは予約済みの静的内部 IP アドレスを使用して相互に通信できます。

エフェメラル内部 IP アドレスは、サービス プロジェクトのインスタンスに自動的に割り当てることができます。たとえば、サービス プロジェクト管理者はインスタンスを作成するときに、ゾーン、共有 VPC ネットワーク、使用可能なサブネットを選択します。IP アドレスは、選択した共有サブネットで使用可能な IP アドレス範囲から使用されます。

また、サービス プロジェクト管理者は、静的内部 IP アドレスを予約することもできます。IP アドレスの値が共有 VPC ネットワークで選択された共有サブネットの IP 範囲から使用されている場合でも、IP アドレス オブジェクトは、このオブジェクトを使用するインスタンスと同じサービス プロジェクトで作成する必要があります。詳細については、共有 VPC のプロビジョニングのページで静的内部 IP の予約をご覧ください。

ホスト プロジェクトで定義された外部 IP アドレスは、そのプロジェクト内のリソースでのみ使用できます。サービス プロジェクトでは使用できません。サービス プロジェクトでは独自の外部 IP アドレスを使用できます。たとえば、サービス プロジェクトのインスタンスは、同じサービス プロジェクトで定義された外部 IP アドレスを使用する必要があります。これは、インスタンスがホスト プロジェクトの共有 VPC ネットワークの内部 IP アドレスを使用する場合も同様です。

内部 DNS

同じサービス プロジェクト内の VM は、Google Cloud が自動的に作成する内部 DNS 名を使用して相互に接続できます。こうした DNS 名では、名前がホスト プロジェクト内の内部 IP アドレスを指している場合でも、VM が作成されたサービス プロジェクトのプロジェクト ID を使用します。詳細な説明については、内部 DNS のドキュメントの内部 DNS 名と共有 VPC をご覧ください。

Cloud DNS の限定公開ゾーン

共有 VPC ネットワークで Cloud DNS の限定公開ゾーンを使用できます。ホスト プロジェクトで限定公開ゾーンを作成し、共有 VPC ネットワークに対してゾーンへのアクセスを承認する必要があります。

負荷分散

共有 VPC は負荷分散と組み合わせて使用できます。すべての負荷分散コンポーネントは同じプロジェクト内に存在する必要があります。つまり、すべてがホスト プロジェクト内にあるか、すべてがサービス プロジェクト内にある必要があります。ホスト プロジェクトに一部のロードバランサ コンポーネントを作成し、接続されたサービス プロジェクトに他のコンポーネントを作成する操作はサポートされていません。ただし、サービス プロジェクト内で内部 TCP/UDP ロードバランサの内部転送ルールを作成する場合、サービス プロジェクトが接続されているホスト プロジェクト内の共有サブネットを参照します。詳細については、共有 VPC のプロビジョニングのページで内部 TCP/UDP ロードバランサの作成をご覧ください。

次のテーブルは、HTTP(S) 負荷分散、SSL プロキシ負荷分散、TCP プロキシ負荷分散のコンポーネントをまとめたものです。ほとんどの場合、バックエンド インスタンスはサービス プロジェクトで作成します。この場合、すべてのロードバランサ コンポーネントがそのプロジェクトに作成されます。ホスト プロジェクトでバックエンド インスタンスを作成することもできます。その場合は、すべてのロードバランサ コンポーネントがホスト プロジェクトに存在する必要があります。

ロードバランサ IP アドレス 転送ルール その他のフロントエンド コンポーネント バックエンド コンポーネント
HTTP(S) 負荷分散 外部 IP アドレスは、負荷分散されているインスタンスと同じプロジェクト(サービス プロジェクト)で定義する必要があります。 外部転送ルールは、バックエンド インスタンスと同じプロジェクト(サービス プロジェクト)で定義する必要があります。 ターゲット HTTP プロキシまたはターゲット HTTPS プロキシと関連 URL マップは、バックエンド インスタンスと同じプロジェクトで定義する必要があります。 グローバル バックエンド サービスは、バックエンド インスタンスと同じプロジェクトで定義する必要があります。これらのインスタンスは、バックエンドとしてバックエンド サービスに接続されたインスタンス グループ内に存在する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトに定義する必要があります。
SSL プロキシ負荷分散 ターゲット SSL プロキシは、バックエンド インスタンスと同じプロジェクトで定義する必要があります。
TCP プロキシ負荷分散 ターゲット TCP プロキシは、バックエンド インスタンスと同じプロジェクトで定義する必要があります。

次のテーブルは、ネットワーク負荷分散のコンポーネントをまとめたものです。

IP アドレス 転送ルール バックエンド コンポーネント
リージョン外部 IP は、負荷分散されているインスタンスと同じプロジェクトで定義する必要があります。 リージョン外部転送ルールは、ターゲット プールのインスタンスと同じプロジェクト(サービス プロジェクト)で定義する必要があります。 ターゲット プールは、ターゲット プールのインスタンスと同じリージョンの同じプロジェクトで定義する必要があります。ターゲット プールに関連するヘルスチェックも同じプロジェクトで定義する必要があります。

次のテーブルは、内部 TCP/UDP 負荷分散のコンポーネントをまとめたものです。例については、共有 VPC のプロビジョニングのページで内部 TCP/UDP ロードバランサの作成をご覧ください。

IP アドレス 転送ルール バックエンド コンポーネント
内部 IP アドレス オブジェクトは、負荷分散されている VM と同じプロジェクトで定義する必要があります。

共有 VPC ネットワークでロードバランサを使用できるようにするには、Google Cloud 内部 IP アドレス オブジェクトは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要がありますさらに、ホスト プロジェクト内の目的の共有 VPC ネットワーク内のサブネットを参照する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。

サービス プロジェクト内で VPC ネットワークのサブネットを参照する内部 IP アドレス オブジェクトを作成すると、内部 TCP/UDP ロードバランサは、共有 VPC ネットワークではなくそのネットワークに対しローカルになります。
内部転送ルールは、負荷分散される VM と同じプロジェクトで定義する必要があります。

共有 VPC ネットワークでロードバランサを使用できるようにするには、内部転送ルールは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要がありますさらに、関連付けられている内部 IP アドレスが参照する同じサブネット(共有 VPC ネットワーク内)を参照する必要があります。

サービス プロジェクト内で VPC ネットワークのサブネットを参照する内部転送ルールを作成すると、内部 TCP/UDP ロードバランサは、共有 VPC ネットワークではなくそのネットワークに対しローカルになります。
共有 VPC のシナリオでは、バックエンド VM はサービス プロジェクト内にあります。そのサービス プロジェクトでは、リージョン内部のバックエンド サービスとヘルスチェックを定義する必要があります。

例とユースケース

基本コンセプト

次の例は、単純な共有 VPC のシナリオを示しています。

基本コンセプト(クリックして拡大)
基本コンセプト(クリックして拡大)
  • 組織の共有 VPC 管理者がホスト プロジェクトを作成し、このプロジェクトに 2 つのサービス プロジェクトが接続しています。

    • 共有 VPC ネットワークのすべてまたは一部のサブネットにアクセスできるように Service Project A 内のサービス プロジェクト管理者を構成できます。10.0.1.0/24 Subnet に対するサブネット レベル以上の権限を持つサービス プロジェクト管理者が、us-west1 リージョンのゾーンに Instance A を作成しています。このインスタンスは 10.0.1.0/24 CIDR ブロックから内部 IP アドレス 10.0.1.3 を取得します。

    • 共有 VPC ネットワークのすべてまたは一部のサブネットにアクセスできるように Service Project B 内のサービス プロジェクト管理者を構成できます。10.15.2.0/24 Subnet に対するサブネット レベル以上の権限を持つサービス プロジェクト管理者が、us-east1 リージョンのゾーンに Instance B を作成しています。このインスタンスは 10.15.2.0/24 CIDR ブロックから内部 IP アドレス 10.15.2.4 を取得します。

  • スタンドアロン プロジェクトは、共有 VPC に参加しません。ホスト プロジェクトにもサービス プロジェクトにもなりません。スタンドアロン インスタンスは、プロジェクトに対して compute.InstanceAdmin 以上の役割を持つ IAM メンバーによって作成されます。

複数のホスト プロジェクト

次の例は、共有 VPC を使用してテスト環境と本番環境を別々に構築する方法を示しています。この例では、Test Environment と Production Environment という 2 つのホスト プロジェクトを使用します。

複数のホスト プロジェクト(クリックして拡大)
複数のホスト プロジェクト(クリックして拡大)
  • 組織の共有 VPC 管理者が 2 つのホスト プロジェクトを作成し、これらのプロジェクトに 2 つのサービス プロジェクトが接続しています。

    • Apps TestingMobile Testing サービス プロジェクトが Test Environment ホスト プロジェクトに接続しています。サービス プロジェクト管理者は、Testing Network のサブネットのすべてまたは一部にアクセスできるように構成されています。

    • Apps ProductionMobile Production サービス プロジェクトが Production Environment ホスト プロジェクトに接続しています。サービス プロジェクト管理者は、Production Network のサブネットのすべてまたは一部にアクセスできるように構成されています。

  • 両方のホスト プロジェクトには 1 つの共有 VPC ネットワークがあり、同じ CIDR 範囲を使用するようにサブネットが構成されています。Testing NetworkProduction Network の両方に次の 2 つのサブネットがあります。

    • us-west1 リージョンの 10.0.1.0/24 Subnet

    • us-east1 リージョンの 10.15.2.0/24 Subnet

  • Apps Testing サービス プロジェクトの Instance ATApps Production サービス プロジェクトの Instance AP を考慮してください。

    • 10.0.1.0/24 Subnet に対してサブネット レベル以上の権限があれば、サービス プロジェクト管理者はインスタンスを作成できます。

    • どちらのインスタンスも IP アドレス 10.0.1.3 を使用しています。各インスタンスが存在するサービス プロジェクトが、独自の共有 VPC ネットワークを含む一意のホスト プロジェクトに接続しているため、これは問題ありません。テスト環境と本番環境のネットワークを意図的に同じ方法で構成しています。

    • 10.0.1.0/24 Subnet を使用するインスタンスの場合、サブネットとインスタンスが別のプロジェクトで定義されていても、サブネットと同じリージョンのゾーンに配置する必要があります。10.0.1.0/24 Subnetus-west1 に配置されているため、このサブネットを使用してインスタンスを作成するサービス プロジェクト管理者は、同じリージョン(us-west1-a など)のゾーンを選択する必要があります。

ハイブリッド クラウドのシナリオ

次の例は、共有 VPC をハイブリッド環境で使用する方法を示しています。

ハイブリッド クラウド(クリックして拡大)
ハイブリッド クラウド(クリックして拡大)

この例では、単一の共有 VPC ネットワークを持つ単一のホスト プロジェクトを作成しています。共有 VPC ネットワークは、Cloud VPN を介してオンプレミス ネットワークに接続しています。一部のサービスとアプリケーションは Google Cloud にホストされていますが、他のサービスやアプリケーションはオンプレミスで管理されています。

  • 共有 VPC 管理者がホスト プロジェクトを有効にし、このプロジェクトに Service Project AService Project BService Project C の 3 つのサービス プロジェクトを接続しています。

    • それぞれのサービス プロジェクトを別々のチームで管理できます。1 つのプロジェクトのサービス プロジェクト管理者が他のサービス プロジェクトに対する権限を持たないように、IAM 権限が構成されています。

    • 共有 VPC 管理者は、必要なサービス プロジェクト管理者にサブネット レベルまたはプロジェクト レベルの権限を付与しています。サービス プロジェクト管理者は、共有 VPC ネットワークを使用するインスタンスを作成できます。

      • 10.0.1.0/24 Subnet に対するサブネット レベルの権限を持つ Service Project A のサービス プロジェクト管理者は、このサブネットに Instance A を作成できます。us-west1 リージョンに 10.0.1.0/24 Subnet が含まれるため、サービス プロジェクト管理者はこのリージョンのゾーンをインスタンスに選択する必要があります。Instance A は、10.0.1.0/24 Subnet の IP アドレス範囲から未使用の IP アドレス(10.0.1.3)を取得します。

      • 10.15.2.0/24 Subnet に対するサブネット レベルの権限を持つ Service Project B のサービス プロジェクト管理者は、このサブネットに Instance B を作成できます。us-east1 リージョンに 10.15.2.0/24 Subnet が含まれるため、サービス プロジェクト管理者はこのリージョンのゾーンをインスタンスに選択する必要があります。Instance B は、10.15.2.0/24 Subnet の IP アドレス範囲から未使用の IP アドレス(10.15.2.4)を取得します。

      • ホスト プロジェクト全体に対するプロジェクト レベルの権限を持つ Service Project C のサービス プロジェクト管理者は、ホスト プロジェクト内の任意の VPC ネットワークのサブネットにインスタンスを作成できます。たとえば、サービス プロジェクト管理者は 10.7.1.0/24 SubnetInstance C を作成し、サブネットのリージョンに合わせて us-east1 リージョンのゾーンを選択できます。Instance C は、10.7.1.0/24 Subnet の IP アドレス範囲から未使用の IP アドレス(10.7.1.50)を取得します。

    • サービス プロジェクトごとに課金されます。

    • 各プロジェクトのサービス プロジェクト管理者は、リソースの作成と管理を担当します。

  • 共有 VPC 管理者は、共有 VPC ネットワークのネットワーク管理者とセキュリティ管理者である他の IAM メンバーにネットワーク管理作業を委任しています。

    • ネットワーク管理者は Cloud VPN ゲートウェイを作成し、インターネット経由でオンプレミス ゲートウェイに接続する VPN トンネルを構成しました。同じ us-east1 リージョン内に対応する Cloud Router が構成されているため、Cloud VPN はオンプレミス側とルートを交換し、受信します。

    • VPC の動的ルーティング モードがグローバルの場合、Cloud Router は学習されたルートを VPC ネットワーク内のすべてのサブネットのオンプレミス ネットワークに適用し、すべての VPC サブネットへのルートをオンプレミス側と共有します。

    • セキュリティ管理者は、VPC ネットワークにファイアウォール ルールを作成して管理することで、Google Cloud とオンプレミス ネットワーク内のインスタンス間のトラフィックを制御します。

    • サービス プロジェクトのインスタンスにはファイアウォール ルールが適用されます。これらのインスタンスは、社内に配置されたデータベースやディレクトリ サーバーなどの内部サービスと通信するように構成できます。

2 層のウェブサービス

次の例は、最小特権の原則を維持しながら共有 VPC を使用して管理責任を委任する方法を示しています。この例では、組織に 2 つの層に分かれているウェブサービスがあり、それぞれの層を別のチームで管理しています。階層 1(Tier 1)は、HTTP(S) ロードバランサの背後にある外部公開のコンポーネントを表します。階層 2(Tier 2)は階層 1(Tier 1)が依存する内部サービスを表し、内部 TCP/UDP ロードバランサを使用して負荷分散を行っています。

2 層のウェブサービス(クリックして拡大)
2 層のウェブサービス(クリックして拡大)

共有 VPC を使用すると、ウェブサービスの各層を異なるプロジェクトにマッピングできるため、共通の VPC ネットワークを共有しながら、これらの層を別々のチームで管理できます。

  • 各層のリソース(インスタンスやロードバランサ コンポーネントなど)は、別々のチームで管理されるサービス プロジェクトに配置されます。

  • 共有 VPC 管理者は、各層のサービス プロジェクトをホスト プロジェクトに接続しています。共有 VPC 管理者はホスト プロジェクトの有効化も行っています。

    • それぞれのチームは、該当するサービス プロジェクトのサービス プロジェクト管理者として、ウェブサービスの各層を管理できます。

    • サービス プロジェクトごとに課金されます。

    • 各プロジェクトのサービス プロジェクト管理者は、リソースの作成と管理を担当します。

  • ネットワークのアクセス制御は次のようになります。

    • 層 1(Tier 1)のみで作業する IAM メンバーは Tier 1 Service Project のサービス プロジェクト管理者であり、10.0.1.0/24 Subnet に対してのみサブネット レベルの権限が付与されています。この例では、サービス プロジェクト管理者がサブネット内に 3 つの Tier 1 Instances を作成しています。

    • 層 2(Tier 2)のみで作業する IAM メンバーは Tier 2 Service Project のサービス プロジェクト管理者であり、10.0.2.0/24 Subnet に対してのみサブネット レベルの権限が付与されています。この例では、他のサービス プロジェクト管理者がこのサブネット内に 3 つの Tier 2 Instances を作成し、内部ロードバランサの転送ルールでそのサブネットで使用可能な範囲の IP アドレスを使用しています。

    • ウェブサービス全体を管理する IAM メンバーは、両方のサービス プロジェクトのサービス プロジェクト管理者であり、ホスト プロジェクトに対するプロジェクト レベルの権限を持っているため、ここで定義されているサブネットを使用できます。

    • 共有 VPC 管理者は、ネットワーク管理作業をネットワーク管理者やセキュリティ管理者に委任することもできます。

次のステップ