共有 VPC の概要

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

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

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

コンセプト

組織とプロジェクト

共有 VPC は、同じ組織内のプロジェクトに接続します。参加するホスト プロジェクトとサービス プロジェクトは、異なる組織に属することはできません。組織とプロジェクトの詳細については、GCP のリソース階層をご覧ください。

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

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

  • サービス プロジェクトは、共有 VPC 管理者がホスト プロジェクトに接続したプロジェクトです。このように接続することで、サービス プロジェクトを共有 VPC に参加させることができます。組織内の異なる部門やチームが複数のサービス プロジェクトを処理および管理することはよくあります。

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

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

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

ネットワーク

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

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

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

管理者と IAM

共有 VPC では、委任管理に Identity and Access Management(IAM)役割を使用します。ユーザー、Google グループ、Google ドメインまたは GCP サービス アカウントなど、IAM メンバーに付与できる役割は次のとおりです。

必要な管理者の役割

管理者 目的
組織管理者
  • 組織内の IAM メンバー
組織管理者には、組織の resourcemanager.organizationAdmin 役割があります。組織管理者は、プロジェクトの作成と削除に必要な役割と、組織の共有 VPC 管理者役割を付与することで、共有 VPC 管理者を指名します。これらの管理者は組織レベルのポリシーを定義できますが、特定のフォルダとプロジェクトにアクションを実行するには、追加のフォルダとプロジェクトの役割が必要になります。
共有 VPC 管理者
  • 組織内の IAM メンバー
共有 VPC 管理者には、組織に対する共有 VPC 管理者compute.xpnAdmin)役割があります。この管理者は共有 VPC の設定に必要なさまざまなタスクを実行します。たとえば、ホスト プロジェクトを有効にしたり、サービス プロジェクトとホスト プロジェクトを接続したりします。また、共有 VPC ネットワークのサブネットの一部または全体に対するアクセス権をサービス プロジェクト管理者に委任します。通常、特定のホスト プロジェクトの共有 VPC 管理者はそのプロジェクトのオーナーになります。
サービス プロジェクト管理者
  • サービス プロジェクトの 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 に固有の以下の制限によって管理されます。

項目 制限
ホスト プロジェクトに接続可能なサービス プロジェクトの数 100 この上限を増やす必要がある場合は、GCP セールスチームにお問い合わせください。
共有 VPC ホスト プロジェクトの数 100 この上限を増やすことはできません。
サービス プロジェクトが接続可能なホスト プロジェクトの数 1 この上限を増やすことはできません。

課金

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

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

リソース

適格リソース

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

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

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

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

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

適格でないリソース

サービス プロジェクトでは、App Engine フレキシブル環境のリソースは共有 VPC に参加できません。

IP アドレス

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

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

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

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

内部 DNS

サービス プロジェクトのインスタンスは、内部 IP アドレスだけでなく、次のような内部 DNS の完全修飾名で通信を行うこともできます。ホスト プロジェクトの IP アドレスを参照している場合でも、DNS 名のプロジェクト ID はサービス プロジェクトの ID になります。

  • 内部ゾーン DNS を使用しているインスタンス: [INSTANCE_NAME].[ZONE].c.[SERVICE_PROJECT_ID].internal
  • 内部グローバル DNS を使用しているインスタンス: [INSTANCE_NAME].c.[SERVICE_PROJECT_ID].internal

ここで

  • [INSTANCE_NAME] はインスタンスの名前です。
  • [ZONE] はインスタンスが配置されているゾーンです。
  • [SERVICE_PROJECT_ID] はインスタンスが属するプロジェクトです。

完全修飾ドメイン名(FQDN)の詳細については、内部 DNS をご覧ください。

負荷分散

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

次の表に、3 種類のグローバル ロードバランサのコンポーネントを示します。ほとんどのユースケースでは、負荷分散されているインスタンスがサービス プロジェクトに存在しています。この場合、すべてのロードバランサ コンポーネントがこのプロジェクトに作成されます。参加するインスタンスが共有 VPC ネットワークのサブネットの内部 IP を持っている場合でも、ロードバランサの外部 IP アドレスはサービス プロジェクトから取得されます。

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

次の表に、2 種類のリージョン ロードバランサのコンポーネントを示します。ここでは、内部ロードバランサの転送ルールが共有 VPC ネットワークの共有サブネットを参照し、共有 VPC ネットワーク内でローカル負荷分散を行う方法を説明しています。

ロードバランサ IP アドレス 転送ルール バックエンド コンポーネント
リージョン ネットワーク負荷分散 リージョン外部 IP は、負荷分散されているインスタンスと同じプロジェクトで定義する必要があります。 リージョン転送ルールは、負荷分散されているインスタンスと同じプロジェクトで定義する必要があります。 ターゲット プールは、負荷分散されているインスタンスと同じリージョンの同じプロジェクトに定義する必要があります。ターゲット プールに関連するヘルスチェックも同じプロジェクトに定義する必要があります。
リージョン内部負荷分散 内部 IP は、ホスト プロジェクトまたはサービス プロジェクトのいずれかから取得されます。
  • ロードバランサを共有 VPC ネットワークで使用可能にするには、内部 IP を共有アブネットの IP 範囲から取得します。
  • ロードバランサを 1 つのサービス プロジェクトのローカルにする場合は、内部 IP をそのサービス プロジェクトのサブネットから取得します。
リージョン転送ルールは負荷分散するインスタンスと同じプロジェクトに定義する必要がありますが、ロードバランサが共有 VPC で機能するかどうかは参照先のサブネットが確認します。
  • ロードバランサを共有 VPC ネットワークで使用可能にするには、転送ルールで共有サブネットを参照します。具体的な方法については、共有 VPC プロビジョニングのページで、内部ロードバランサの作成をご覧ください。
  • ロードバランサを 1 つのサービス プロジェクトのローカルにする場合は、転送ルールでそのサービス プロジェクトのサブネットを参照します。
リージョン バックエンド サービスは、負荷分散するインスタンスと同じプロジェクトに定義する必要があります。負荷分散されるインスタンスは、バックエンドとしてバックエンド サービスに接続されたインスタンス グループ内に存在する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトに定義する必要があります。

例とユースケース

基本コンセプト

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

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

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

    • Service Project B のサービス プロジェクト管理者は、共有 VPC ネットワーク内のすべてまたは一部のサブネットにアクセスできるように構成されています。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 EnvironmentProduction 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 つのサブネットがあります。

    • 10.0.1.0/24 Subnetus-west1 リージョン)

    • 10.15.2.0/24 Subnetus-east1 リージョン)

  • Apps Testing サービス プロジェクトでは Instance AT を、Instance AP サービス プロジェクトでは Apps Production を使用します。

    • 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 を介してオンプレミス ネットワークに接続しています。一部のサービスとアプリケーションは GCP にホストされていますが、他のサービスやアプリケーションはオンプレミスで管理されています。

  • 共有 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)を取得します。

      • Service Project B に対するサブネット レベルの権限を持つ 10.15.2.0/24 Subnet のサービス プロジェクト管理者は、このサブネットに 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 ネットワークでファイアウォール ルールを作成して管理します。また、GCP とオンプレミス ネットワーク内のインスタンスのトラフィックを制御します。

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

2 層のウェブサービス

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

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。