共有 VPC

このページでは、Google Cloud の共有 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 つのホスト プロジェクトにしか接続できません。図については、複数のホスト プロジェクトの例をご覧ください。

  • ホスト プロジェクト内には、ネットワーク、サブネット、セカンダリ アドレス範囲、ファイアウォール ルールなどのネットワーク リソースを作成できます。ホスト プロジェクトは、選択したサブネット（セカンダリ範囲を含む）をサービス プロジェクトと共有できます。サービス プロジェクト内で実行されるサービスは、共有 VPC を使用して他のサービス プロジェクト内で実行中のリソースと通信できます。

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

スタンドアロン VPC ネットワークは、スタンドアロン プロジェクトまたはサービス プロジェクトに存在する、共有されていない VPC ネットワークです。

ネットワーク

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

ホスト プロジェクトを有効にすると、次の 2 つの方法でネットワークを共有できます。

  • すべてのホスト プロジェクトのサブネットを共有する方法。この方法を選択した場合は、ホスト プロジェクトに作成されるすべての新しいサブネット（新しいネットワークのサブネットを含む）も共有されます。
  • 共有するサブネットを個別に指定する方法。サブネットを個別に共有する場合は、手動でリストを変更しない限り、選択したサブネットのみが共有されます。

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

組織ポリシーの制約

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

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

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

  • サービス プロジェクトがプロジェクト、フォルダ、組織のレベルでアクセスできる共有 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 ゲートウェイを通過するアウトバウンド トラフィックの料金はホスト プロジェクトに課金されます。
    • VLAN アタッチメントを通過する共有 VPC サービス プロジェクトのリソースから転送されるトラフィックの料金は、VLAN アタッチメントを所有するプロジェクトに課金されます。詳しくは、Cloud Interconnect の料金をご覧ください。

リソース

適格リソース

共有 VPC サービス プロジェクトで、ほとんどの Google Cloud プロダクトと機能を使用できます。

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

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

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

IP アドレス

サービス プロジェクトでインスタンスを作成する場合、ホスト プロジェクトのサブネット構成に応じて、シングルスタック（IPv4 のみ）インスタンスまたはデュアルスタック（IPv4 と IPv6）インスタンスとして構成します。詳細については、インスタンスの作成をご覧ください。

同じ共有 VPC ネットワークを使用するホスト プロジェクトに接続されたサービス プロジェクト内のインスタンスは、内部 IPv4 アドレス、または使用可能なファイアウォール ルールに応じて内部または外部 IPv6 アドレスを使用して内部的に相互に通信できます。

サービス プロジェクト管理者は、サービス プロジェクトのリソースに次の IP アドレスタイプを割り当てることができます。

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

    エフェメラル IPv4 アドレスは、内部ロードバランサに自動的に割り当てることもできます。詳細については、内部パススルー ネットワーク ロードバランサを作成するまたは内部アプリケーション ロードバランサを作成するをご覧ください。

  • 静的内部 IPv4 アドレスと IPv6 アドレス: サービス プロジェクトで静的内部 IPv4 アドレスまたは IPv6 アドレスを予約できます。内部 IPv4 または IPv6 アドレス オブジェクトは、それを使用するリソースと同じサービス プロジェクトで作成する必要があります。共有 VPC ネットワーク内の選択された共有サブネットの使用可能な IP アドレスから IP アドレスの値が取得されている場合でも同様です。詳細については、「共有 VPC をプロビジョニングする」の静的内部 IP4 アドレスと IPv6 アドレスを予約をご覧ください。

  • 静的外部 IPv4 アドレス: ホスト プロジェクトで定義された外部 IPv4 アドレス オブジェクトは、ホスト プロジェクトまたは接続されたサービス プロジェクトのいずれかのリソースで使用できます。サービス プロジェクトでは、独自の外部 IPv4 アドレス オブジェクトを使用することもできます。たとえば、サービス プロジェクトのインスタンスは、サービス プロジェクトまたはホスト プロジェクトで定義されているリージョン外部 IPv4 アドレスを使用できます。

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

内部 DNS

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

Cloud DNS の限定公開ゾーン

共有 VPC ネットワークで Cloud DNS の限定公開ゾーンを使用できます。ホスト プロジェクトで限定公開ゾーンを作成し、共有 VPC ネットワークに対してゾーンへのアクセスを承認できます。また、プロジェクト間のバインディングを使用してサービス プロジェクトでゾーンを設定することもできます。

ロード バランシング

共有 VPC は Cloud Load Balancing と組み合わせて使用できます。ほとんどの場合、バックエンド インスタンスはサービス プロジェクトで作成します。この場合、すべてのロードバランサのコンポーネントは、そのプロジェクトに作成されます。ホスト プロジェクトでバックエンド インスタンスを作成することは可能ですが、そのような設定は、ネットワーク管理とサービス開発の責任を分離しないため、一般的な共有 VPC デプロイには適していません。

次の表のリンクを使用して、各タイプのロードバランサでサポートされている共有 VPC アーキテクチャの詳細を確認してください。

ロードバランサの種類 リンク
外部アプリケーション ロードバランサ 共有 VPC アーキテクチャ
内部アプリケーション ロードバランサ 共有 VPC アーキテクチャ
外部プロキシ ネットワーク ロードバランサ 共有 VPC アーキテクチャ
内部プロキシ ネットワーク ロードバランサ 共有 VPC アーキテクチャ
内部パススルー ネットワーク ロードバランサ 共有 VPC アーキテクチャ
外部パススルー ネットワーク ロードバランサ 共有 VPC アーキテクチャ

例とユースケース

基本概念

図 1 に、シンプルな共有 VPC のシナリオを示します。

図 1. 共有 VPC ネットワークを持つホスト プロジェクトは 2 つのサービス プロジェクトの内部接続を提供しますが、スタンドアロン プロジェクトは共有 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 プリンシパルによって作成されます。

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

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

図 2. テスト環境のホスト プロジェクトと本番環境のホスト プロジェクトは、共有 VPC を使用して個別の本番環境とテスト環境を作成します（クリックして拡大）。

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

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

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

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

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

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

  • Apps testing サービス プロジェクトの Instance AT と Apps 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 subnet は us-west1 に配置されているため、このサブネットを使用してインスタンスを作成するサービス プロジェクト管理者は、同じリージョン（us-west1-a など）のゾーンを選択する必要があります。

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

図 3 に、ハイブリッド環境で共有 VPC を使用する方法を示します。

図 3. 共有 VPC ネットワークは、オンプレミス ネットワークと 3 つのサービス プロジェクトに接続しています（クリックして拡大）。

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

  • 共有 VPC 管理者がホスト プロジェクトを有効にし、このプロジェクトに Service project A、Service project B、Service 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 subnet に Instance 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 層のウェブサービス

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

図 4. この 2 層のウェブサービスでは、外部に公開されているコンポーネントと内部サービスが共通の共有 VPC ネットワークに接続され、異なるチームによって管理されます（クリックして拡大）。

共有 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 管理者は、ネットワーク管理作業をネットワーク管理者やセキュリティ管理者に委任することもできます。

次のステップ