共有 VPC のプロビジョニング

共有 VPC を使用すると、ホストプロジェクトの VPC ネットワークから、同じ組織内の別のサービスプロジェクトにサブネットをエクスポートできます。サービスプロジェクトのインスタンスは、ホストプロジェクトの共有サブネットでネットワーク接続を得ることができます。このページでは、組織にとって必要ないくつかの管理上の準備など、共有 VPC を設定して使用する方法について説明します。

共有 VPC では、IPv4 のみ（シングルスタック）のサブネットと、IPv4 と IPv6（デュアルスタック）のサブネットの両方をエクスポートできます。

サービスプロジェクトの接続解除または共有 VPC 構成の完全な削除については、共有 VPC のデプロビジョニングをご覧ください。

割り当て、上限、適格なリソース

開始する前に、共有 VPC の概要と IAM の概要を十分に理解しておく必要があります。特に、以下の点に注意してください。

共有 VPC に関係する割り当てと上限を把握しておきます。
共有できるリソースと共有できないリソースについて、よく理解しておきます。
ホストプロジェクトとそれに接続するすべてのサービスプロジェクトで、Compute Engine API と課金が有効になっていることを確認します。

組織の準備

管理者と IAM

組織の準備、共有 VPC ホストプロジェクトの設定、共有 VPC ネットワークの使用には、少なくとも 3 つの管理 Identity and Access Management（IAM）ロールが必要です。各ロールの詳細と、オプションのロールについては、共有 VPC の概要の管理者と IAM のセクションをご覧ください。

組織ポリシーの制約

組織のポリシーの制約により、共有 VPC リソースをプロジェクト、フォルダ、組織レベルで保護できます。以下では、各ポリシーについて説明します。

ホストプロジェクトの誤削除の防止

ホストプロジェクトを誤って削除してしまうと、それに接続されているすべてのサービスプロジェクトが停止します。共有 VPC ホストプロジェクトになるようプロジェクトが構成されている場合は、リーエンと呼ばれる特殊なロックがプロジェクトに適用されます。リーエンが設定されていれば、プロジェクトが誤って削除されることがなくなります。リーエンは、共有 VPC から解除されると、ホストプロジェクトから自動的に削除されます。

orgpolicy.policyAdmin ロールを持つユーザーは、リーエンの削除を次のロールだけに制限する組織レベルのポリシー制約（constraints/compute.restrictXpnProjectLienRemoval）を定義できます。

組織レベルで roles/owner または roles/resourcemanager.lienModifier を持つユーザー
組織レベルで resourcemanager.projects.get と resourcemanager.projects.updateLiens 権限を含むカスタムロールを持つユーザー

これにより、組織レベルの roles/owner ロールや組織レベルの resourcemanager.lienModifier ロールを持たないプロジェクトオーナーが、共有 VPC ホストプロジェクトを誤って削除することを、効果的に防ぐことができます。resourcemanager.lienModifier ロールに関連付けられている権限の詳細については、Resource Manager ドキュメントのプロジェクトにリーエンを適用するをご覧ください。

組織ポリシーは組織内のすべてのプロジェクトに適用されるため、リーエンの削除を制限するには、これらの手順を一度行うだけで済みます。

組織管理者、または orgpolicy.policyAdmin ロールを持つ IAM プリンシパルとして gcloud への認証を行います。ORG_ADMIN は、組織管理者の名前に置き換えます。
```
gcloud auth login ORG_ADMIN
```
次のコマンドの出力を調べて、自分の組織 ID 番号を確認します。
```
gcloud organizations list
```
次のコマンドを実行して、組織に compute.restrictXpnProjectLienRemoval ポリシーを適用します。ORG_ID は、前の手順で確認した番号に置き換えます。
```
gcloud beta resource-manager org-policies enable-enforce \
    --organization ORG_ID compute.restrictXpnProjectLienRemoval
```
組織管理者としてアカウントを保護する作業が完了したら、gcloud からログアウトします。
```
gcloud auth revoke ORG_ADMIN
```

ホストプロジェクトの接続を制限する

デフォルトでは、共有 VPC 管理者は、同じ組織内の任意のホストプロジェクトに非ホストプロジェクトを接続できます。組織のポリシー管理者は、非ホストプロジェクトを接続できるホストプロジェクトを制限できます。また、フォルダまたは組織内の非ホストプロジェクトを接続できるホストプロジェクトも制限できます。詳細については、constraints/compute.restrictSharedVpcHostProjects の制約をご覧ください。

サービスプロジェクトで使用できるホストプロジェクトのサブネットを制限する

デフォルトでは、共有 VPC を構成した後、サービスプロジェクトの IAM プリンシパルは適切な IAM 権限を持つホストプロジェクトのサブネットを使用できます。組織のポリシー管理者は、個々のユーザー権限を管理するだけでなく、ポリシーを設定して特定のプロジェクトからアクセス可能なサブネットのセットを定義できます。また、フォルダや組織内のプロジェクトからアクセス可能なサブネットのセットも定義できます。詳細については、constraints/compute.restrictSharedVpcSubnetworks の制約をご覧ください。

共有 VPC 管理者の指名

組織管理者は、1 人以上の IAM プリンシパルに共有 VPC 管理者とプロジェクト IAM 管理者のロールを付与できます。フォルダレベルで共有 VPC 管理者のロールを持っているユーザーが Google Cloud コンソールから共有 VPC を管理するには、Compute ネットワーク閲覧者ロールまたは compute.subnetworks.list 権限を含む別のロールが必要です。この権限を持たない共有 VPC 管理者は、Google Cloud CLI または API を使用して共有 VPC を管理できます。

プロジェクト IAM 管理者ロールは、個々のサブネットだけでなく、すべてのサブネット（今後作成されるものも含む）を共有する権限を共有 VPC 管理者に付与します。この付与により、プロジェクトレベルではなく、組織レベルまたはフォルダレベルでバインディングが作成されます。そのため、IAM プリンシパルはプロジェクト内だけではなく、組織で定義する必要があります。

コンソール

組織レベルで共有 VPC 管理者ロールを付与するには

Google Cloud コンソールに組織管理者としてログインし、[IAM] ページに移動します。
[IAM] ページに移動
プロジェクトメニューから組織を選択します。
プロジェクトを選択すると、[ロール] メニューに正しいエントリが表示されなくなります。
[追加] をクリックします。
新しいプリンシパルのメールアドレスを入力します。
[ロール] のプルダウンメニューで、[Compute Engine] > [Compute Shared VPC 管理者] を選択します。
注: オプションとして Compute Shared VPC 管理者ロールが表示されていない場合は、組織管理者として Google Cloud コンソールにログインしていないか、組織全体ではなくプロジェクトを選択している可能性があります。
[別のロールを追加] をクリックします。
[ロール] プルダウンで、[Resource Manager] > [プロジェクト IAM 管理者] を選択します。
[保存] をクリックします。

フォルダレベルで共有 VPC 管理者ロールを付与するには

Google Cloud コンソールに組織管理者としてログインし、[IAM] ページに移動します。
[IAM] ページに移動
プロジェクトメニューからフォルダを選択します。
プロジェクトや組織を選択すると、正しいオプションが表示されなくなります。
[追加] をクリックします。
新しいプリンシパルのメールアドレスを入力します。
[ロールを選択] で、[Compute Engine] > [Compute Shared VPC 管理者] を選択します。
[別のロールを追加] をクリックします。
[ロール] プルダウンで、[Resource Manager] > [プロジェクト IAM 管理者] を選択します。
[別のロールを追加] をクリックします。
[ロール] プルダウンで、[Resource Manager] > [Compute ネットワーク閲覧者] を選択します。
[保存] をクリックします。

gcloud

組織管理者として、gcloud で認証します。ORG_ADMIN は、組織管理者の名前に置き換えます。
```
gcloud auth login ORG_ADMIN
```
次のコマンドの出力を調べて、自分の組織 ID 番号を確認します。
```
gcloud organizations list
```
組織レベルで共有 VPC 管理者ロールを割り当てる場合、次の手順を行います。
1. 既存の IAM プリンシパルに共有 VPC 管理者のロールを適用します。ORG_ID は、前の手順で確認した組織 ID 番号に置き換え、EMAIL_ADDRESS は、共有 VPC 管理者のロールを付与するユーザーのメールアドレスに置き換えます。
```
gcloud organizations add-iam-policy-binding ORG_ID \
  --member='user:EMAIL_ADDRESS' \
  --role="roles/compute.xpnAdmin"
```
```
gcloud organizations add-iam-policy-binding ORG_ID \
  --member='user:EMAIL_ADDRESS' \
  --role="roles/resourcemanager.projectIamAdmin"
```

フォルダレベルで共有 VPC 管理者のロールを割り当てる場合の手順は次のとおりです。

このコマンドの出力を調べて、フォルダ ID を確認します。
```
gcloud beta resource-manager folders list --organization=ORG_ID
```

既存の IAM プリンシパルに共有 VPC 管理者のロールを適用します。ORG_ID は、前の手順で確認した組織 ID 番号に置き換え、EMAIL_ADDRESS は、共有 VPC 管理者のロールを付与するユーザーのメールアドレスに置き換えます。

gcloud beta resource-manager folders add-iam-policy-binding FOLDER_ID \
   --member='user:EMAIL_ADDRESS' \
   --role="roles/compute.xpnAdmin"

gcloud beta resource-manager folders add-iam-policy-binding FOLDER_ID \
   --member='user:EMAIL_ADDRESS' \
   --role="roles/resourcemanager.projectIamAdmin"

gcloud beta resource-manager folders add-iam-policy-binding FOLDER_ID \
   --member='user:EMAIL_ADDRESS' \
   --role="roles/compute.networkViewer"

アカウントを保護するための作業が完了したら、gcloud コマンドラインツールで組織管理者アカウントトークンを取り消します。
```
gcloud auth revoke ORG_ADMIN
```

API

組織レベルで共有 VPC 管理者ロールを割り当てるには、次の操作を行います。
1. 組織 ID 番号を特定します。
```
POST https://cloudresourcemanager.googleapis.com/v1/organizations
```
2. 既存の組織のポリシーの詳細を記述し、記録します。
```
POST https://cloudresourcemanager.googleapis.com/v1/organizations/ORG_ID:getIamPolicy
```
  ORG_ID は組織の ID に置き換えます。
3. 共有 VPC 管理者ロールを割り当てます。
```
POST https://cloudresourcemanager.googleapis.com/v1/organizations/ORG_ID:setIamPolicy
{
  "bindings": [
    ...copy existing bindings
    {
      "members": [
        "user:EMAIL_ADDRESS"
      ],
      "role": "roles/compute.xpnAdmin"
    },
    {
      "members": [
        "user:EMAIL_ADDRESS"
      ],
      "role": "roles/resourcemanager.projectIamAdmin"
    }
  ],
  "etag": "ETAG",
  "version": 1,
  ...other existing policy details
}
```
  プレースホルダを有効な値に置き換えます。
  - ORG_ID は、共有 VPC 管理者のロールを付与するユーザーが属する組織の ID です。
  - EMAIL_ADDRESS はユーザーのメールアドレスです。
  - ETAG は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
  詳細については、organizations.setIamPolicy メソッドをご覧ください。
フォルダレベルで共有 VPC 管理者ロールを割り当てるには、次のリクエストを使用します。
1. 組織 ID 番号を特定します。
```
POST https://cloudresourcemanager.googleapis.com/v1/organizations
```
2. フォルダ ID を探します。
```
GET https://cloudresourcemanager.googleapis.com/v2/folders?parent=organizations/ORG_ID
```
  ORG_ID は組織の ID に置き換えます。
3. 既存のフォルダポリシーの詳細を記述して、記録します。
```
POST https://cloudresourcemanager.googleapis.com/v2/folders/FOLDER_ID:getIamPolicy
```
  FOLDER_ID は、フォルダの ID に置き換えます。
4. 共有 VPC 管理者ロールを割り当てます。
```
POST https://cloudresourcemanager.googleapis.com/v1/organizations/FOLDER_ID:setIamPolicy
{
  "bindings": [
    ...copy existing bindings
    {
      "members": [
        "user:EMAIL_ADDRESS"
      ],
      "role": "roles/compute.xpnAdmin"
    },
    {
      "members": [
        "user:EMAIL_ADDRESS"
      ],
      "role": "roles/resourcemanager.projectIamAdmin"
    },
    {
      "members": [
        "user:EMAIL_ADDRESS"
      ],
      "role": "roles/compute.networkViewer"
    }
  ],
  "etag": "ETAG",
  "version": 1,
  ...other existing policy details
}
```
  プレースホルダを有効な値に置き換えます。
  - FOLDER_ID は、共有 VPC 管理者のロールを付与するユーザーが属する組織の ID です。
  - EMAIL_ADDRESS はユーザーのメールアドレスです。
  - ETAG は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
  詳細については、folders.setIamPolicy メソッドをご覧ください。

共有 VPC の設定

このセクションのタスクはすべて、共有 VPC 管理者が行う必要があります。

ホストプロジェクトの有効化

共有 VPC 管理者は組織内で、割り当てと上限に従ってプロジェクトを共有 VPC ホストプロジェクトとして指定できます。手順は以下のとおりです。組織のプロジェクト作成者ロールとプロジェクト削除ロール（roles/resourcemanager.projectCreator と roles/resourcemanager.projectDeleter）が付与されている場合、共有 VPC 管理者はプロジェクトの作成や削除を行うこともできます。

ホストプロジェクトを有効にしても、プロジェクトのネットワークリソースがサービスプロジェクトに自動的に共有されることはありません。ホストプロジェクトにサービスプロジェクトを接続して、選択したネットワークとサブネットをサービスプロジェクトと共有する必要があります。

コンソール

共有 VPC 管理者のロールをまだ持っていない場合、このページを Google Cloud コンソールで表示することができません。

フォルダレベルの共有 VPC 管理者のロールを持っている場合は、gcloud beta コマンドまたはベータ版 API を使用する必要があります。

Google Cloud コンソールで [共有 VPC] ページに移動します。
[共有 VPC] ページに移動
共有 VPC 管理者としてログインします。
プロジェクト選択ツールで、共有 VPC ホストプロジェクトとして有効にするプロジェクトを選択します。
[共有 VPC を設定] をクリックします。
次のページの [ホストプロジェクトを有効にする] で、[保存して続行] をクリックします。
[サブネットを選択する] で、次のいずれかを行います。
1. ホストプロジェクトの VPC ネットワーク内の現在と将来のすべてのサブネットを、次の手順で指定するサービスプロジェクトやサービスプロジェクト管理者と共有する必要がある場合、[すべてのサブネットを共有する（プロジェクトレベルの権限）] をクリックします。
2. ホストプロジェクトの VPC ネットワークのサブネットを、サービスプロジェクトやサービスプロジェクト管理者と選択的に共有する必要がある場合、[個々のサブネット（サブネットレベルの権限）] をクリックします。次に、[共有するサブネット] を選択します。
[続行] をクリックします。
その次の画面が表示されます。
[プロジェクト名] で、ホストプロジェクトに接続するサービスプロジェクトを指定します。サービスプロジェクトを接続しても、サービスプロジェクト管理者は定義されません。これは、次の手順で行います。
[ロール別にユーザーを選択する] セクションで、サービスプロジェクト管理者を追加します。これらのユーザーには、共有サブネットの IAM ロール compute.networkUser が付与されます。共有 VPC ホストプロジェクトのサブネットでリソースを作成できるのは、サービスプロジェクト管理者のみです。
[保存] をクリックします。

gcloud

共有 VPC 管理者として gcloud への認証を行います。SHARED_VPC_ADMIN は、共有 VPC 管理者の名前に置き換えます。
```
gcloud auth login SHARED_VPC_ADMIN
```
ホストプロジェクトにする必要のあるプロジェクトに対して、共有 VPC を有効にします。HOST_PROJECT_ID は、プロジェクトの ID に置き換えます。

組織レベルで共有 VPC 管理者のロールを持っている場合
```
gcloud compute shared-vpc enable HOST_PROJECT_ID
```
フォルダレベルで共有 VPC 管理者のロールを持っている場合
```
gcloud beta compute shared-vpc enable HOST_PROJECT_ID
```
組織のホストプロジェクトとしてプロジェクトがリストされていることを確認します。ORG_ID は、組織 ID（gcloud organizations list で確認）に置き換えます。
```
gcloud compute shared-vpc organizations list-host-projects ORG_ID
```
ホストプロジェクトを有効にするだけでよい場合は、gcloud からログアウトして、共有 VPC 管理者アカウントの認証情報を保護できます。それ以外の場合、この手順をスキップして、サービスプロジェクトを接続する手順に進みます。
```
gcloud auth revoke SHARED_VPC_ADMIN
```

API

プロジェクトの共有 VPC を有効にするには、共有 VPC 管理者の権限を持つ認証情報を使用します。
- 組織レベルで共有 VPC 管理者ロールが割り当てられている場合は、v1 API を使用します。
```
POST https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/enableXpnHost
```
- フォルダレベルで共有 VPC 管理者ロールが割り当てられている場合は、ベータ版 API を使用します。
```
POST https://compute.googleapis.com/compute/beta/projects/HOST_PROJECT_ID/enableXpnHost
```
HOST_PROJECT_ID は、共有 VPC ホストプロジェクトにするプロジェクトの ID に置き換えます。

詳細については、projects.enableXpnHost メソッドをご覧ください。
プロジェクトがホストプロジェクトとして表示されていることを確認します。
```
POST https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/listXpnHosts
```
HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID に置き換えます。

詳細については、projects.listXpnHosts メソッドをご覧ください。

Terraform

Terraform リソースを使用して、ホストプロジェクトを有効にできます。

examples/basic_shared_vpc/main.tf

GitHub で表示

resource "google_compute_shared_vpc_host_project" "host" {
  project = var.project # Replace this with your host project ID in quotes
}

Terraform 構成を適用または削除する方法については、Terraform 構成の操作をご覧ください。

サービスプロジェクトの接続

サービスプロジェクトの管理者が共有 VPC を使用するには、サービスプロジェクトがホストプロジェクトに接続されている必要があります。共有 VPC 管理者は、以下の手順で接続を完了する必要があります。

サービスプロジェクトは 1 つのホストプロジェクトにのみ接続できますが、ホストプロジェクトは複数のサービスプロジェクトの接続をサポートしています。詳細については、VPC 割り当てページの共有 VPC に固有の上限をご覧ください。

コンソール

共有 VPC 管理者として Google Cloud コンソールにログインします。
Google Cloud コンソールで [共有 VPC] ページに移動します。
[共有 VPC] ページに移動
[接続されたプロジェクト] タブをクリックします。
[接続されたプロジェクト] タブで、[プロジェクトを接続] ボタンをクリックします。
[プロジェクト名] セクションで、接続するサービスプロジェクトのチェックボックスをオンにします。サービスプロジェクトを接続しても、サービスプロジェクト管理者は定義されません。これは、次の手順で行います。
[VPC ネットワークの権限] セクションで、compute.networkUser ロールを付与するプリンシパルのロールを選択します。IAM プリンシパルには、VPC ネットワーク共有モードに基づいて、ホストプロジェクト全体またはホストプロジェクト内の特定のサブネットに対するネットワークユーザーのロールが付与されます。これらのプリンシパルは、それぞれのサービスプロジェクトのサービスプロジェクト管理者と呼ばれます。
[VPC ネットワーク共有モード] セクションで、次のいずれかを選択します。
1. ホストプロジェクトの VPC ネットワーク内の現在と将来のすべてのサブネットを、すべてのサービスプロジェクトやサービスプロジェクト管理者と共有するには、[すべてのサブネットを共有する（プロジェクトレベルの権限）] をクリックします。
2. ホストプロジェクトの VPC ネットワークのサブネットを、サービスプロジェクトやサービスプロジェクト管理者と選択的に共有する必要がある場合、[個々のサブネット（サブネットレベルの権限）] をクリックします。次に、[共有するサブネット] を選択します。
[保存] をクリックします。

gcloud

まだ共有 VPC 管理者として gcloud の認証を行っていない場合は、認証を行います。SHARED_VPC_ADMIN は、共有 VPC 管理者の名前に置き換えます。
```
gcloud auth login SHARED_VPC_ADMIN
```
以前に有効にしたホストプロジェクトにサービスプロジェクトを接続します。SERVICE_PROJECT_ID はサービスプロジェクトのプロジェクト ID に置き換え、HOST_PROJECT_ID はホストプロジェクトのプロジェクト ID に置き換えます。

組織レベルで共有 VPC 管理者のロールを持っている場合
```
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID \
    --host-project HOST_PROJECT_ID
```
フォルダレベルで共有 VPC 管理者のロールを持っている場合
```
gcloud beta compute shared-vpc associated-projects add SERVICE_PROJECT_ID \
    --host-project HOST_PROJECT_ID
```
サービスプロジェクトが接続されていることを確認します。
```
gcloud compute shared-vpc get-host-project SERVICE_PROJECT_ID
```
必要に応じて、ホストプロジェクトに接続されているサービスプロジェクトの一覧を表示できます。
```
gcloud compute shared-vpc list-associated-resources HOST_PROJECT_ID
```
サービスプロジェクトを接続するだけでよい場合、gcloud からログアウトして、共有 VPC 管理者アカウントの認証情報を保護できます。それ以外の場合、この手順をスキップして、すべてのサブネットまたは一部のサブネットのみに対してサービスプロジェクト管理者を定義します。
```
gcloud auth revoke SHARED_VPC_ADMIN
```

API

サービスプロジェクトを共有 VPC ホストプロジェクトに接続します。
- 組織レベルで共有 VPC 管理者ロールが割り当てられている場合は、v1 API を使用します。
```
POST https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/enableXpnResource
{
"xpnResource": {
  "id": "SERVICE_PROJECT"
}
}
```
- フォルダレベルで共有 VPC 管理者ロールが割り当てられている場合は、ベータ版 API を使用します。
```
POST https://compute.googleapis.com/compute/beta/projects/HOST_PROJECT_ID/enableXpnResource
{
"xpnResource": {
  "id": "SERVICE_PROJECT"
}
}
```
プレースホルダを有効な値に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID です。
- SERVICE_PROJECT は、接続するサービスプロジェクトの ID です。
詳細については、projects.enableXpnResource メソッドをご覧ください。
サービスプロジェクトがホストプロジェクトに接続していることを確認します。
```
GET https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/getXpnResources
```
プレースホルダを有効な値に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID です。
詳細については、projects.getXpnResources メソッドをご覧ください。

Terraform

Terraform リソースを使用して、サービスプロジェクトを接続できます。

examples/basic_shared_vpc/main.tf

GitHub で表示

resource "google_compute_shared_vpc_service_project" "service1" {
  host_project    = google_compute_shared_vpc_host_project.host.project
  service_project = var.service_project # Replace this with your service project ID in quotes
}

Terraform 構成を適用または削除する方法については、Terraform 構成の操作をご覧ください。

すべてのサブネットのサービスプロジェクト管理者

共有 VPC 管理者は、サービスプロジェクトの IAM プリンシパルをサービスプロジェクト管理者に割り当て、ホストプロジェクト内のすべてのサブネットへのアクセスを許可できます。この種のサービスプロジェクト管理者には、ホストプロジェクト全体に対する compute.networkUser のロールが付与されます。つまり、現在ホストプロジェクトに定義されているサブネットだけでなく、今後作成されるサブネットにもアクセスできます。

ホストプロジェクトで compute.networkUser ロールを持つユーザーは、接続されたサービスプロジェクト内のすべてのサブネットを表示できます。

コンソール

コンソールで、サービスプロジェクトの IAM プリンシパルをサービスプロジェクト管理者として定義し、ホストプロジェクトのすべてのサブネットにアクセスできるようにするには、サービスプロジェクトの接続セクションをご覧ください。

gcloud

この手順には、ホストプロジェクト内のすべてのサブネットに対するアクセス権を持つサービスプロジェクト管理者としてサービスプロジェクトから IAM プリンシパルを定義する方法が含まれています。この手順を行うには、事前にホストプロジェクトを有効にして、ホストプロジェクトにサービスプロジェクトを接続しておく必要があります。

まだ共有 VPC 管理者として gcloud の認証を行っていない場合は、認証を行います。SHARED_VPC_ADMIN は、共有 VPC 管理者の名前に置き換えます。
```
gcloud auth login SHARED_VPC_ADMIN
```
サービスプロジェクト内の IAM プリンシパルをサービスプロジェクト管理者にするポリシーバインディングを作成します。HOST_PROJECT_ID は、ホストプロジェクトのプロジェクト ID に置き換え、SERVICE_PROJECT_ADMIN は、サービスプロジェクト管理者になるユーザーのメールアドレスに置き換えます。
```
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
--member "user:SERVICE_PROJECT_ADMIN" \
--role "roles/compute.networkUser"
```
次のように --member 引数の形式を変更することで、さまざまな種類のプリンシパルを指定できます。
- group: を使用して、Google グループをプリンシパルとして指定します（メールアドレスを使用）。
- domain: を使用して、Google ドメインをプリンシパルとして指定します。
- serviceAccount: を使用してサービスアカウントを指定します。このユースケースの詳細については、サービスプロジェクト管理者としてのサービスアカウントをご覧ください。
定義する必要のある他の各サービスプロジェクト管理者に対して、前の手順を繰り返します。
サービスプロジェクト管理者の定義が完了している場合は、gcloud からログアウトして、共有 VPC 管理者アカウントの認証情報を保護できます。
```
gcloud auth revoke SHARED_VPC_ADMIN
```

API

既存のプロジェクトポリシーの詳細を記述し、記録します。既存のポリシーと etag 値が必要です。
```
POST https://cloudresourcemanager.googleapis.com/v2/projects/HOST_PROJECT_ID:getIamPolicy
```
HOST_PROJECT_ID は、共有 VPC ネットワークを含むホストプロジェクトの ID に置き換えます。
サービスプロジェクトの IAM プリンシパルをサービスプロジェクト管理者に指定するポリシーバインディングを作成します。
```
POST https://cloudresourcemanager.googleapis.com/v1/projects/HOST_PROJECT_ID:setIamPolicy
{
  "bindings": [
    ...copy existing bindings
    {
      "members": [
        PRINCIPAL,
        ...additional principals
      ],
      "role": "roles/compute.networkUser"
    },
  ],
  "etag": "ETAG",
  "version": 1,
  ...other existing policy details
}
```
プレースホルダを有効な値に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むホストプロジェクトの ID です。
- PRINCIPAL は、ユーザー、グループ、ドメイン、サービスアカウントなどのロールが関連付けられている ID です。詳細については、Resource Manager のドキュメントで members フィールドの説明をご覧ください。
- ETAG は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
詳細については、projects.setIamPolicy メソッドをご覧ください。

一部のサブネットのサービスプロジェクト管理者

共有 VPC 管理者は、サービスプロジェクトの IAM プリンシパルをサービスプロジェクト管理者に割り当て、ホストプロジェクトの一部のサブネットのみにアクセスを許可できます。このオプションを使用すると、ホストプロジェクト内の一部のサブネットのみに対する compute.networkUser ロールをサービスプロジェクト管理者に付与することで、管理者をさらに詳細に定義できます。

ホストプロジェクトで compute.networkUser ロールを持つユーザーは、接続されたサービスプロジェクト内のすべてのサブネットを表示できます。

コンソール

コンソールで、サービスプロジェクトの IAM プリンシパルをサービスプロジェクト管理者として定義し、ホストプロジェクトの一部のサブネットにのみアクセスできるようにするには、サービスプロジェクトの接続をご覧ください。

gcloud

この手順には、ホストプロジェクト内の一部のサブネットのみに対するアクセス権を持つサービスプロジェクト管理者としてサービスプロジェクトから IAM プリンシパルを定義する方法が含まれています。管理者を定義するには、事前にホストプロジェクトを有効にして、ホストプロジェクトにサービスプロジェクトを接続しておく必要があります。

まだ共有 VPC 管理者として gcloud の認証を行っていない場合は、認証を行います。SHARED_VPC_ADMIN は、共有 VPC 管理者の名前に置き換えます。
```
gcloud auth login SHARED_VPC_ADMIN
```
サービスプロジェクト管理者がアクセスする必要のあるホストプロジェクト内のサブネットを選択します。現在の IAM ポリシーを JSON 形式で取得します。SUBNET_NAME は、ホストプロジェクト内のサブネットの名前に置き換え、HOST_PROJECT_ID は、ホストプロジェクトのプロジェクト ID に置き換えます。
```
gcloud beta compute networks subnets get-iam-policy SUBNET_NAME \
    --region SUBNET_REGION \
    --project HOST_PROJECT_ID \
    --format json
```
前の手順で得た JSON 出力をコピーし、任意のファイルに保存します。わかりやすくするため、ここでは subnet-policy.json という名前のファイルに出力を保存します。
subnet-policy.json ファイルを変更します。サービスプロジェクト管理者にし、サブネットへのアクセスを許可する IAM プリンシパルを追加します。各 SERVICE_PROJECT_ADMIN は、サービスプロジェクトの IAM ユーザーのメールアドレスに置き換えます。
```
{
  "bindings": [
  {
     "members": [
           "user:[SERVICE_PROJECT_ADMIN]",
           "user:[SERVICE_PROJECT_ADMIN]"
        ],
        "role": "roles/compute.networkUser"
  }
  ],
  "etag": "[ETAG_STRING]"
}
```
次のようにして、ポリシーには、さまざまな種類の IAM プリンシパル（ユーザー以外）を指定できます。
- user: を group: に変更して、Google グループをプリンシパルとして指定します（メールアドレスを使用）。
- user: を domain: に変更して、Google ドメインをプリンシパルとして指定します。
- serviceAccount: を使用してサービスアカウントを指定します。このユースケースの詳細については、サービスプロジェクト管理者としてのサービスアカウントをご覧ください。

subnet-policy.json ファイルの内容を使用して、サブネットのポリシーバインディングを更新します。

gcloud beta compute networks subnets set-iam-policy SUBNET_NAME subnet-policy.json \
    --region SUBNET_REGION \
    --project HOST_PROJECT_ID

サービスプロジェクト管理者の定義が完了している場合は、gcloud からログアウトして、共有 VPC 管理者アカウントの認証情報を保護できます。
```
gcloud auth revoke SHARED_VPC_ADMIN
```

API

既存のサブネットポリシーの詳細を記述し、記録します。既存のポリシーと etag 値が必要です。
```
GET https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/regions/SUBNET_REGION/subnetworks/SUBNET_NAME/getIamPolicy
```
プレースホルダを有効な値に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むホストプロジェクトの ID です。
- SUBNET_NAME は、共有するサブネットの名前です。
- SUBNET_REGION は、サブネットが配置されているリージョンです。
サブネットポリシーを更新して、ホストプロジェクトのサブネットに対するアクセス権をサービスプロジェクト管理者に付与します。
```
POST https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/regions/SUBNET_REGION/subnetworks/SUBNET_NAME/setIamPolicy
{
  "bindings": [
    ...copy existing bindings
    {
      "members": [
        PRINCIPAL,
        ...additional principals
      ],
      "role": "roles/compute.networkUser"
    },
  ],
  "etag": "ETAG",
  "version": 1,
  ...other existing policy details
}
```
プレースホルダを有効な値に置き換えます。
- ETAG は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むホストプロジェクトの ID です。
- PRINCIPAL は、ユーザー、グループ、ドメイン、サービスアカウントなどのロールが関連付けられている ID です。詳細については、Resource Manager のドキュメントで members フィールドの説明をご覧ください。
- SUBNET_NAME は、共有するサブネットの名前です。
- SUBNET_REGION は、サブネットが配置されているリージョンです。
詳細については、subnetworks.setIamPolicy メソッドをご覧ください。

サービスプロジェクト管理者としてのサービスアカウント

共有 VPC 管理者は、サービスプロジェクト管理者として、サービスプロジェクトからサービスアカウントを定義することもできます。このセクションでは、サービスプロジェクト管理者として 2 種類のサービスアカウントを定義する方法を説明します。

次の形式のユーザー管理サービスアカウント: USER_ID@SERVICE_PROJECT_ID.iam.gserviceaccount.com
次の形式の Google API サービスアカウント: SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com

サービスプロジェクト管理者ロール（compute.networkUser）は、ホストプロジェクトのすべてのサブネットか、一部のサブネットのみに対して付与されます。ただし、このセクションではわかりやすくするために、ホストプロジェクトのすべてのサブネットに対するサービスプロジェクト管理者として、2 種類のサービスアカウントを定義する方法を説明します。

サービスプロジェクト管理者としてのユーザー管理サービスアカウント

ここでは、共有 VPC ホストプロジェクトのすべてのサブネットに対するサービスプロジェクト管理者としてユーザー管理サービスアカウントを定義する方法について説明します。

コンソール

共有 VPC 管理者として Google Cloud コンソールにログインします。
Google Cloud コンソールで [設定] ページに移動します。
[設定] ページに移動
プロジェクトを、サービスプロジェクト管理者として定義する必要のあるサービスアカウントを含むサービスプロジェクトに変更します。
サービスプロジェクトのプロジェクト ID をコピーします。説明をわかりやすくするため、この手順ではサービスプロジェクト ID を SERVICE_PROJECT_ID と示しています。
プロジェクトを共有 VPC ホストプロジェクトに変更します。
Google Cloud コンソールで [IAM] ページに移動します。
[IAM] ページに移動
[追加] をクリックします。
[プリンシパル] フィールドに SERVICE_ACCOUNT_NAME@SERVICE_PROJECT_ID.iam.gserviceaccount.com を追加します。SERVICE_ACCOUNT_NAME は、サービスアカウントの名前に置き換えます。
[ロール] メニューから、[Compute Engine] > [Compute ネットワークユーザー] を選択します。
[追加] をクリックします。

gcloud

まだ共有 VPC 管理者として gcloud の認証を行っていない場合は、認証を行います。SHARED_VPC_ADMIN は、共有 VPC 管理者の名前に置き換えます。
```
gcloud auth login SHARED_VPC_ADMIN
```
サービスプロジェクトのプロジェクト ID が不明な場合、組織内のすべてのプロジェクトを一覧表示すると確認できます。この一覧には、それぞれのプロジェクト ID が示されています。
```
gcloud projects list
```
サービスアカウントをサービスプロジェクト管理者にするポリシーバインディングを作成します。HOST_PROJECT_ID は、ホストプロジェクトのプロジェクト ID に置き換え、SERVICE_ACCOUNT_NAME は、サービスアカウントの名前に置き換え、SERVICE_PROJECT_ID は、サービスプロジェクト ID に置き換えます。
```
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_NAME@SERVICE_PROJECT_ID.iam.gserviceaccount.com" \
    --role "roles/compute.networkUser"
```

API

既存のプロジェクトポリシーの詳細を記述し、記録します。既存のポリシーと etag 値が必要です。
```
POST https://cloudresourcemanager.googleapis.com/v2/projects/HOST_PROJECT_ID:getIamPolicy
```
HOST_PROJECT_ID は、共有 VPC ネットワークを含むホストプロジェクトの ID に置き換えます。
サービスアカウントをサービスプロジェクト管理者として指定するポリシーバインドを作成します。
```
POST https://cloudresourcemanager.googleapis.com/v1/projects/HOST_PROJECT_ID:setIamPolicy
{
  "bindings": [
    ...copy existing bindings
    {
      "members": [
        "serviceAccount:SERVICE_ACCOUNT_NAME@SERVICE_PROJECT_ID.iam.gserviceaccount.com",
        ...include additional service accounts
      ],
      "role": "roles/compute.networkUser"
    },
  ],
  "etag": "ETAG",
  "version": 1,
  ...other existing policy details
}
```
プレースホルダを有効な値に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むホストプロジェクトの ID です。
- SERVICE_ACCOUNT_NAME はサービスアカウントの名前です。
- SERVICE_PROJECT_ID は、サービスアカウントを含むサービスプロジェクトの ID です。
- ETAG は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
詳細については、projects.setIamPolicy メソッドをご覧ください。

サービスプロジェクト管理者としての Google API サービスアカウント

ここでは、共有 VPC ホストプロジェクトのすべてのサブネットに対するサービスプロジェクト管理者として、Google API サービスアカウントを定義する方法を説明します。共有 VPC で使用されるマネージドインスタンスグループに対して、Google API サービスアカウントをサービスプロジェクト管理者にする必要があります。インスタンスの作成のようなタスクは、この種のサービスアカウントによって実行されるからです。この関係の詳細については、マネージドインスタンスグループと IAM をご覧ください。

コンソール

共有 VPC 管理者として Google Cloud コンソールにログインします。
Google Cloud コンソールで [設定] ページに移動します。
[設定] ページに移動
プロジェクトを、サービスプロジェクト管理者として定義する必要のあるサービスアカウントを含むサービスプロジェクトに変更します。
サービスプロジェクトの [プロジェクト番号] をコピーします。説明をわかりやすくするため、この手順ではサービスプロジェクト番号を SERVICE_PROJECT_NUMBER と示しています。
プロジェクトを共有 VPC ホストプロジェクトに変更します。
Google Cloud コンソールで [IAM] ページに移動します。
[IAM] ページに移動
[追加] をクリックします。
SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com を [メンバー] フィールドに追加します。
[ロール] メニューから、[Compute Engine] > [Compute ネットワークユーザー] を選択します。
[追加] をクリックします。

gcloud

まだ共有 VPC 管理者として gcloud の認証を行っていない場合は、認証を行います。SHARED_VPC_ADMIN は、共有 VPC 管理者の名前に置き換えます。
```
gcloud auth login SHARED_VPC_ADMIN
```
サービスプロジェクトのプロジェクト番号を確認します。説明をわかりやすくするため、この手順ではサービスプロジェクト番号を SERVICE_PROJECT_NUMBER と示しています。SERVICE_PROJECT_ID は、サービスプロジェクトのプロジェクト ID に置き換えます。
```
gcloud projects describe SERVICE_PROJECT_ID --format='get(projectNumber)'
```
- サービスプロジェクトのプロジェクト ID が不明な場合、組織内のすべてのプロジェクトを一覧表示すると確認できます。このリストには、それぞれのプロジェクト番号が示されています。
```
gcloud projects list
```
サービスアカウントをサービスプロジェクト管理者にするポリシーバインディングを作成します。HOST_PROJECT_ID は、ホストプロジェクトのプロジェクト ID に置き換え、SERVICE_PROJECT_NUMBER は、サービスプロジェクト番号に置き換えます。
```
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member "serviceAccount:SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com" \
    --role "roles/compute.networkUser"
```

API

既存のプロジェクトポリシーの詳細を記述し、記録します。既存のポリシーと etag 値が必要です。
```
POST https://cloudresourcemanager.googleapis.com/v2/projects/HOST_PROJECT_ID:getIamPolicy
```
HOST_PROJECT_ID は、共有 VPC ネットワークを含むホストプロジェクトの ID に置き換えます。
プロジェクトのリストを取得して、プロジェクト番号を探します。
```
GET https://cloudresourcemanager.googleapis.com/v1/projects?filter=projectId="SERVICE_PROJECT_ID"
```
SERVICE_PROJECT_ID は、サービスアカウントが配置されているサービスプロジェクトの ID に置き換えます。
サービスアカウントをサービスプロジェクト管理者として指定するポリシーバインドを作成します。
```
POST https://cloudresourcemanager.googleapis.com/v1/projects/HOST_PROJECT_ID:setIamPolicy
{
  "bindings": [
    ...copy existing bindings
    {
      "members": [
        "serviceAccount:SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com"
      ],
      "role": "roles/compute.networkUser"
    },
  ],
  "etag": "ETAG",
  "version": 1,
  ...other existing policy details
}
```
プレースホルダを有効な値に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むホストプロジェクトの ID です。
- SERVICE_PROJECT_NUMBER は、サービスアカウントを含むサービスプロジェクトの番号です。
- ETAG は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
詳細については、projects.setIamPolicy メソッドをご覧ください。

共有 VPC の使用

共有 VPC 管理者がホストプロジェクトの有効化、それに対する必要なサービスプロジェクトの接続、ホストプロジェクトサブネットのすべてまたは一部に対するサービスプロジェクト管理者の定義という各タスクを完了すると、サービスプロジェクト管理者がホストプロジェクトのサブネットを使用して、サービスプロジェクト内にインスタンス、テンプレート、内部ロードバランサを作成できるようになります。

このセクションのすべてのタスクは、サービスプロジェクト管理者が行う必要があります。

共有 VPC 管理者がサービスプロジェクト管理者に付与できるのは、ホストプロジェクト全体または一部のサブネットのみに対する compute.networkUser ロールのみです。サービスプロジェクト管理者は、各サービスプロジェクトを管理するために必要なその他のロールも持つ必要があります。たとえば、サービスプロジェクト管理者をプロジェクトオーナーにすることも、プロジェクトに対して少なくとも compute.instanceAdmin ロールを持つようにすることもできます。

使用可能なサブネットの一覧表示

サービスプロジェクト管理者は、次の手順に従って、自分に権限が付与されているサブネットを一覧表示できます。

コンソール

Google Cloud コンソールで [共有 VPC] ページに移動します。
[共有 VPC] ページに移動

gcloud

まだサービスプロジェクト管理者として gcloud の認証を行っていない場合は、認証を行います。SERVICE_PROJECT_ADMIN は、サービスプロジェクト管理者の名前に置き換えます。
```
gcloud auth login SERVICE_PROJECT_ADMIN
```

次のコマンドを実行します。HOST_PROJECT_ID は、共有 VPC ホストプロジェクトのプロジェクト ID に置き換えます。

gcloud compute networks subnets list-usable --project HOST_PROJECT_ID

次の例では、project-1 ホストプロジェクトで使用可能なサブネットの一覧を取得します。

$ gcloud compute networks subnets list-usable --project project-1

PROJECT    REGION       NETWORK  SUBNET    RANGE          SECONDARY_RANGES
project-1  us-west1     net-1    subnet-1  10.138.0.0/20
project-1  us-central1  net-1    subnet-2  10.128.0.0/20  r-1 192.168.2.0/24
                                                          r-2 192.168.3.0/24
project-1  us-east1     net-1    subnet-3  10.142.0.0/20

詳細については、SDK のドキュメントの list-usage コマンドをご覧ください。

API

ホストプロジェクトで使用可能なサブネットを一覧で表示します。サービスプロジェクト管理者としてリクエストを行います。

GET https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/aggregated/subnetworks/listUsable

HOST_PROJECT_ID は、共有 VPC ネットワークを含むホストプロジェクトの ID に置き換えます。

詳細については、subnetworks.listUsable メソッドをご覧ください。

静的内部 IPv4 アドレスの予約

サービスプロジェクト管理者は、共有 VPC ネットワークのサブネットに内部 IPv4 アドレスを予約できます。IPv4 アドレス構成オブジェクトはサービスプロジェクト内で作成されますが、その値は選択した共有サブネットで使用可能なアドレス範囲から取得されます。

gcloud

まだサービスプロジェクト管理者として gcloud の認証を行っていない場合は、認証を行います。SERVICE_PROJECT_ADMIN は、サービスプロジェクト管理者の名前に置き換えます。
```
gcloud auth login SERVICE_PROJECT_ADMIN
```

次のコマンドを実行します。HOST_PROJECT_ID は、共有 VPC ホストプロジェクトのプロジェクト ID に置き換えます。

gcloud compute addresses create IP_ADDR_NAME \
--project SERVICE_PROJECT_ID \
--subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \
--region=REGION

次のように置き換えます。

IP_ADDR_NAME は、IPv4 アドレスオブジェクトの名前に置き換えます。
SERVICE_PROJECT_ID は、サービスプロジェクトの ID に置き換えます。
HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID に置き換えます。
REGION は、共有サブネットが含まれているリージョンに置き換えます。
SUBNET は、共有サブネットの名前に置き換えます。

IP アドレスの作成の詳細は、SDK のドキュメントに記載されています。

API

サービスプロジェクト管理者として静的内部 IPv4 アドレスを予約します。

POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/regions/REGION/addresses
{
  "name": "ADDRESS_NAME",
  "subnetwork": "projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME",
  "addressType": "INTERNAL"
}

プレースホルダを有効な値に置き換えます。

ADDRESS_NAME は予約済み内部 IP アドレスの名前です。
HOST_PROJECT_ID は、共有 VPC ネットワークを含むプロジェクトの ID です。
REGION は、予約済み IPv4 アドレスを配置するリージョンと、共有サブネットが存在するリージョンです。
SERVICE_PROJECT_ID は、IPv4 アドレスを予約するサービスプロジェクトの ID です。
SUBNET_NAME は共有サブネットの名前です。

詳細については、addresses.insert メソッドをご覧ください。

Terraform

Terraform データブロックを使用して、ホストサブネット情報を指定できます。Terraform リソースを使用して、静的内部 IPv4 アドレスを予約します。オプションの address 引数を省略すると、使用可能な IPv4 アドレスが選択され、予約されます。

ホストサブネット情報を指定します。

examples/basic_shared_vpc/main.tf

GitHub で表示

data "google_compute_subnetwork" "subnet" {
  name    = "my-subnet-123"
  project = var.project
  region  = "us-central1"
}

ホストプロジェクトのサブネットの IPv4 アドレスを予約して、サービスプロジェクトで使用します。

examples/basic_shared_vpc/main.tf

GitHub で表示

resource "google_compute_address" "internal" {
  project      = var.service_project
  region       = "us-central1"
  name         = "int-ip"
  address_type = "INTERNAL"
  address      = "10.0.0.8"
  subnetwork   = data.google_compute_subnetwork.subnet.self_link
}

Terraform 構成を適用または削除する方法については、Terraform 構成の操作をご覧ください。

インスタンスの作成

共有 VPC を使用してインスタンスを作成するときは、次の点に注意してください。

インスタンスを作成する標準的なプロセスには、ゾーン、ネットワーク、サブネットの選択が含まれます。選択したサブネットと選択したゾーンの両方が同じリージョン内に存在する必要があります。サービスプロジェクト管理者が共有 VPC ネットワークのサブネットを使用してインスタンスを作成する場合、そのインスタンス用に選択されたゾーンは、選択したサブネットと同じリージョン内に存在する必要があります。
- 予約された静的内部 IPv4 アドレスを持つインスタンスを作成する場合、その静的 IPv4 アドレスが作成された時点で、サブネット（およびリージョン）は選択済みとなっています。ここでは、静的内部 IPv4 アドレスを持つインスタンスを作成する gcloud の例について説明します。
サービスプロジェクト管理者は、権限が付与されているサブネットを使用する場合に限り、インスタンスを作成できます。使用可能なサブネットを確認するには、使用可能なサブネットの一覧表示をご覧ください。
Google Cloud は、共有 VPC ネットワークのサブネットにインスタンスを作成するリクエストを受信すると、リクエストを送信した IAM プリンシパルがその共有サブネットを使用する権限を持っているかどうかを確認します。チェックが失敗した場合、インスタンスは作成されず、Google Cloud は権限エラーを返します。共有 VPC 管理者に連絡してください。
デュアルスタックのサブネットでインスタンスを作成している場合は、デュアルスタックインスタンスを作成できます。デュアルスタックサブネットは、カスタムモード VPC ネットワークでのみサポートされます。サブネットの IPv6 アクセスタイプによって、VM に割り当てられた IPv6 アドレスが、内部 IPv6 アドレスか外部 IPv6 アドレスかが決まります。

共有サブネットでデュアルスタックインスタンスを作成するには、Google Cloud CLI または API を使用します。コンソールで共有サブネットにデュアルスタックインスタンスを作成することはできません。

コンソール

Google Cloud Console の [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動
[作成] をクリックします。
インスタンスの名前を指定します。
[管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックします。
[ネットワーキング] をクリックします。
[ネットワークインターフェース] で default ネットワークをクリックします。
[共有ネットワーク] ラジオボタンをクリックします。
インスタンスを作成する共有サブネットを選択します。
インスタンスに必要な他のパラメータを指定します。
[作成] をクリックします。

gcloud

共有 VPC ネットワークの共有サブネット内にある内部エフェメラル IPv4 アドレスでインスタンスを作成するには、次のようにします。
```
gcloud compute instances create INSTANCE_NAME \
--project SERVICE_PROJECT_ID
--subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \
--zone ZONE
```
次のように置き換えます。
- INSTANCE_NAME は、インスタンスの名前に置き換えます。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID に置き換えます。
- REGION は、共有サブネットが含まれているリージョンに置き換えます。
- SUBNET は、共有サブネットの名前に置き換えます。
- ZONE は、指定されたリージョン内のゾーン
共有 VPC ネットワーク内の予約済み静的内部 IPv4 アドレスを使用してインスタンスを作成するには、次のようにします。
1. ホストプロジェクトで静的内部 IPv4 アドレスを予約します。
2. インスタンスを作成します。
```
gcloud compute instances create INSTANCE_NAME \
--project SERVICE_PROJECT_ID \
--private-network-ip IP_ADDR_NAME \
--zone ZONE
--subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET
```
  次のように置き換えます。
  - INSTANCE_NAME は、インスタンスの名前に置き換えます。
  - SERVICE_PROJECT_ID は、サービスプロジェクトの ID に置き換えます。
  - HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID に置き換えます。
  - IP_ADDR_NAME は、静的 IP アドレスの名前に置き換えます。
  - ZONE は、IP_ADDR_NAME と同じリージョン内のゾーンに置き換えます。
  - SUBNET は、静的内部 IPv4 アドレスに関連付けられている共有サブネットの名前に置き換えます。
エフェメラル内部 IPv4 アドレスとエフェメラル IPv6 アドレスを持つインスタンスを作成するには、次のようにします。
```
gcloud compute instances create INSTANCE_NAME \
--project SERVICE_PROJECT_ID \
--stack-type IPV4_IPV6 \
--subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \
--zone ZONE
```
次のように置き換えます。
- INSTANCE_NAME は、インスタンスの名前に置き換えます。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID に置き換えます。
- REGION は、共有サブネットが含まれているリージョンに置き換えます。
- SUBNET は、共有サブネットの名前に置き換えます。
- ZONE は、指定されたリージョン内のゾーン

API

エフェメラル内部 IPv4 アドレスを持つインスタンスを作成するには、サブネットのみを指定します。
```
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/zones/ZONE/instances
{
  "machineType": "MACHINE_TYPE",
  "name": "INSTANCE_NAME",
  "networkInterfaces": [
    {
      "subnetwork": "projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME"
    }
  ],
  "disks": [
    {
      "boot": true,
      "initializeParams": {
        "sourceImage": "SOURCE_IMAGE"
      }
    }
  ]
}
```
プレースホルダを有効な値に置き換えます。
- INSTANCE_NAME はインスタンス名です。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むプロジェクトの ID です。
- MACHINE_TYPE はインスタンスのマシンタイプです。
- REGION は、共有サブネットを含むリージョンです。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID です。
- SOURCE_IMAGE は、インスタンスのイメージです。
- SUBNET は共有サブネットの名前です。
- ZONE は、指定されたリージョンのゾーンです。
詳細については、instances.insert メソッドをご覧ください。
予約済み内部 IPv4 アドレスを持つインスタンスを作成するには、サブネットと予約済み IPv4 アドレスの名前を指定します。
```
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/zones/ZONE/instances
{
  "machineType": "MACHINE_TYPE",
  "name": "INSTANCE_NAME",
  "networkInterfaces": [
    {
      "subnetwork": "projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME",
      "networkIP": "projects/SERVICE_PROJECT_ID/regions/REGION/addresses/ADDRESS_NAME"
    }
  ],
  "disks": [
    {
      "boot": true,
      "initializeParams": {
        "sourceImage": "SOURCE_IMAGE"
      }
    }
  ]
}
```
プレースホルダを有効な値に置き換えます。
- ADDRESS_NAME は予約済み内部 IPv4 アドレスの名前です。
- INSTANCE_NAME はインスタンス名です。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むプロジェクトの ID です。
- MACHINE_TYPE はインスタンスのマシンタイプです。
- REGION は、共有サブネットを含むリージョンです。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID です。
- SOURCE_IMAGE は、インスタンスのイメージです。
- SUBNET は共有サブネットの名前です。
- ZONE は、指定されたリージョンのゾーンです。
詳細については、instances.insert メソッドをご覧ください。
エフェメラル内部 IPv4 アドレスとエフェメラル IPv6 アドレスを持つインスタンスを作成するには、サブネットとスタックタイプを指定します。
```
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/zones/ZONE/instances
{
  "machineType": "MACHINE_TYPE",
  "name": "INSTANCE_NAME",
  "networkInterfaces": [
    {
      "subnetwork": "projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME",
      "stackType": "IPv4_IPv6"
    }
  ],
  "disks": [
    {
      "boot": true,
      "initializeParams": {
        "sourceImage": "SOURCE_IMAGE"
      }
    }
  ]
}
```
プレースホルダを有効な値に置き換えます。
- INSTANCE_NAME はインスタンス名です。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むプロジェクトの ID です。
- MACHINE_TYPE はインスタンスのマシンタイプです。
- REGION は、共有サブネットを含むリージョンです。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID です。
- SOURCE_IMAGE は、インスタンスのイメージです。
- SUBNET は共有サブネットの名前です。
- ZONE は、指定されたリージョンのゾーンです。
詳細については、instances.insert メソッドをご覧ください。

Terraform

Terraform データブロックを使用して、ホストサブネット情報を指定できます。次に、Terraform リソースを使用して、サービスプロジェクトに VM インスタンスを作成します。

ホストサブネット情報を指定します。

examples/basic_shared_vpc/main.tf

GitHub で表示

data "google_compute_subnetwork" "subnet" {
  name    = "my-subnet-123"
  project = var.project
  region  = "us-central1"
}

ホストプロジェクトの共有サブネットからエフェメラル IPv4 アドレスを使用して、サービスプロジェクトに VM インスタンスを作成します。

examples/basic_shared_vpc/main.tf

GitHub で表示

resource "google_compute_instance" "ephemeral_ip" {
  project      = var.service_project
  zone         = "us-central1-a"
  name         = "my-vm"
  machine_type = "e2-medium"
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-9"
    }
  }
  network_interface {
    subnetwork = data.google_compute_subnetwork.subnet.self_link
  }
}

ホストプロジェクトの共有サブネットから予約された静的 IPv4 アドレスを使用して、サービスプロジェクトに VM インスタンスを作成します。

examples/basic_shared_vpc/main.tf

GitHub で表示

resource "google_compute_instance" "reserved_ip" {
  project      = var.service_project
  zone         = "us-central1-a"
  name         = google_compute_address.internal.self_link
  machine_type = "e2-medium"
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-9"
    }
  }
  network_interface {
    subnetwork = data.google_compute_subnetwork.subnet.self_link
    network_ip = "int-ip"
  }
}

Terraform 構成を適用または削除する方法については、Terraform 構成の操作をご覧ください。

インスタンステンプレートを作成する

共有 VPC を使用してインスタンステンプレートを作成する場合は、次の点に注意してください。

インスタンステンプレートを作成するプロセスには、ネットワークとサブネットの選択が含まれます。
- カスタムモードの共有 VPC ネットワークで使用するために作成されたテンプレートで、ネットワークとサブネットの両方を指定する必要があります。
- 自動モードの共有 VPC ネットワークで使用するために作成されたテンプレートでは、後でサブネットを選択することもできます。このような場合、サブネットは、テンプレートを使用するいずれかのマネージドインスタンスグループと同じリージョンで自動的に選択されます（定義上、自動モードのネットワークはリージョンごとにサブネットを 1 つずつ持ちます）。
IAM プリンシパルがインスタンステンプレートを作成したときに、Google Cloud は、プリンシパルが指定されたサブネットを使用できるかどうかを確認する権限チェックを実行しません。この権限チェックは、テンプレートを使用しているマネージドインスタンスグループがリクエストされるまで延期されます。
デュアルスタックのサブネットでテンプレートを作成している場合は、デュアルスタックインスタンスのテンプレートを作成できます。デュアルスタックサブネットは、カスタムモード VPC ネットワークでのみサポートされます。サブネットの IPv6 アクセスタイプによって、VM に割り当てられた IPv6 アドレスが、内部 IPv6 アドレスか外部 IPv6 アドレスかが決まります。

共有サブネットでデュアルスタックインスタンステンプレートを作成するには、Google Cloud CLI または API を使用します。コンソールで共有サブネットにデュアルスタックインスタンスのテンプレートを作成することはできません。

コンソール

Google Cloud コンソールで [インスタンステンプレート] ページに移動します。
[インスタンステンプレート] ページに移動
[インスタンステンプレートを作成] をクリックします。
インスタンステンプレートの名前を指定します。
[管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックします。
[ネットワーキング] をクリックします。
[ネットワークインターフェース] で default ネットワークをクリックします。
[共有ネットワーク] ラジオボタンをクリックします。
インスタンステンプレートを作成する共有サブネットを選択します。
インスタンステンプレートに必要な他のパラメータを指定します。
[作成] をクリックします。

gcloud

自動モードの共有 VPC ネットワークの自動的に作成されたサブネットで使用するように IPv4-専用インスタンステンプレートを作成するには:
```
gcloud compute instance-templates create TEMPLATE_NAME \
--project SERVICE_PROJECT_ID \
--network projects/HOST_PROJECT_ID/global/networks/NETWORK
```
次のように置き換えます。
- TEMPLATE_NAME は、テンプレートの名前に置き換えます。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID に置き換えます。
- NETWORK は、共有 VPC ネットワークの名前に置き換えます。
共有 VPC ネットワーク（自動モードまたはカスタムモードのいずれか）で、手動で作成されたサブネット用に IPv4 専用インスタンステンプレートを作成するには:
```
gcloud compute instance-templates create TEMPLATE_NAME \
--project SERVICE_PROJECT_ID \
--region REGION \
--subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET
```
次のように置き換えます。
- TEMPLATE_NAME は、テンプレートの名前に置き換えます。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID に置き換えます。
- REGION は、共有サブネットが含まれているリージョンに置き換えます。
- SUBNET は、共有サブネットの名前
カスタムモードの共有 VPC ネットワークのサブネットを使用するデュアルスタックインスタンステンプレートを作成するには:
```
gcloud compute instance-templates create TEMPLATE_NAME \
--project SERVICE_PROJECT_ID \
--stack-type IPV4_IPV6 \
--region REGION \
--subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET
```
次のように置き換えます。
- TEMPLATE_NAME は、テンプレートの名前に置き換えます。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID に置き換えます。
- REGION は、共有サブネットが含まれているリージョンに置き換えます。
- SUBNET は、共有サブネットの名前に置き換えます。

API

自動モードの共有 VPC ネットワークで自動生成のサブネットを使用する IPv4 専用インスタンステンプレートを作成するには、VPC ネットワークを指定します。
```
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/global/instanceTemplates
{
"properties": {
  "networkInterfaces": [
    {
      "network": "projects/HOST_PROJECT_ID/global/networks/NETWORK"
    }
  ]
...
}
```
プレースホルダを有効な値に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むプロジェクトの ID です。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID です。
- NETWORK は、共有 VPC ネットワークの名前です。
詳細については、instanceTemplates.insert メソッドをご覧ください。
共有 VPC ネットワーク（自動モードまたはカスタムモード）で手動で作成したサブネットを使用する IPv4 専用インスタンステンプレートを作成するには、サブネットを指定します。
```
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/global/instanceTemplates
{
"properties": {
  "networkInterfaces": [
    {
      "subnetwork": "projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME"
    }
  ]
...
}
```
プレースホルダを有効な値に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むプロジェクトの ID です。
- REGION は、共有サブネットを含むリージョンです。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID です。
- SUBNET_NAME は共有サブネットの名前です。
詳細については、instanceTemplates.insert メソッドをご覧ください。
カスタムモードの共有 VPC ネットワークのサブネットを使用するデュアルスタックインスタンステンプレートを作成するには、サブネットとスタックの種類を指定します。
```
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/global/instanceTemplates
{
"properties": {
  "networkInterfaces": [
    {
      "subnetwork": "projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME",
      "stackType": "IPV4_IPV6"
    }
  ]
...
}
```
プレースホルダを有効な値に置き換えます。
- HOST_PROJECT_ID は、共有 VPC ネットワークを含むプロジェクトの ID です。
- REGION は、共有サブネットを含むリージョンです。
- SERVICE_PROJECT_ID は、サービスプロジェクトの ID です。
- SUBNET_NAME は共有サブネットの名前です。
詳細については、instanceTemplates.insert メソッドをご覧ください。

Terraform

Terraform データブロックを使用して、ホストサブネット情報を指定できます。次に、Terraform リソースを使用して VM インスタンステンプレートを作成します。VM の IPv4 アドレスは、ホストプロジェクトの共有サブネットから取得されます。

サブネットは、VM インスタンスが作成されるリージョンと同じリージョンに存在する必要があります。

ホストサブネット情報を指定します。

examples/basic_shared_vpc/main.tf

GitHub で表示

data "google_compute_subnetwork" "subnet" {
  name    = "my-subnet-123"
  project = var.project
  region  = "us-central1"
}

サービスプロジェクトに VM インスタンステンプレートを作成します。

examples/basic_shared_vpc/main.tf

GitHub で表示

resource "google_compute_instance_template" "default" {
  project      = var.service_project
  name         = "appserver-template"
  description  = "This template is used to create app server instances."
  machine_type = "n1-standard-1"
  disk {
    source_image = "debian-cloud/debian-9"
  }
  network_interface {
    subnetwork = data.google_compute_subnetwork.subnet.self_link
  }
}

Terraform 構成を適用または削除する方法については、Terraform 構成の操作をご覧ください。

マネージドインスタンスグループを作成する

共有 VPC を使用してマネージドインスタンスグループを作成するときは、次の点に注意してください。

共有 VPC で使用されるマネージドインスタンスグループでは、Google API サービスアカウントをサービスプロジェクト管理者にする必要があります。これは、自動スケーリングを使用した自動インスタンス作成のようなタスクが、そのサービスアカウントによって行われるためです。
マネージドインスタンスグループを作成する標準的なプロセスには、グループの種類とインスタンステンプレートに応じた、ゾーンやリージョンの選択が含まれます（ネットワークとサブネットの詳細は、インスタンステンプレートに関連付けられています）。適格なインスタンステンプレートは、マネージドインスタンスグループによって使用されているリージョンと同じリージョン内のサブネットを参照しているテンプレートに限定されます。
サービスプロジェクト管理者が作成できるのは、権限が付与されているサブネットをメンバーインスタンスが使用するマネージドインスタンスグループのみです。ネットワークとサブネットの詳細はインスタンステンプレートに関連付けられているため、サービスプロジェクト管理者が使用できるのは、使用が許可されているサブネットを参照しているテンプレートのみです。
Google Cloud は、マネージドインスタンスグループの作成リクエストを受信すると、リクエストを送信した IAM プリンシパルがインスタンステンプレートで指定されたサブネット（グループと同じリージョン）で使用する権限を持っているかどうかを確認します。チェックが失敗した場合、マネージドインスタンスグループは作成されず、Google Cloud はエラー Required 'compute.subnetworks.use' permission for 'projects/SUBNET_NAME を返します。

使用可能なサブネットを一覧表示して使用可能なサブネットをチェックし、共有 VPC 管理者に連絡して、追加のアクセス権が必要かどうか確認してください。詳細については、サービスプロジェクト管理者としてのサービスアカウントをご覧ください。

詳細については、Compute Engine のドキュメントでマネージドインスタンスのグループを作成するをご覧ください。

HTTP(S) ロードバランサを作成する

共有 VPC ネットワーク内で HTTP(S) ロードバランシングを構成するには、多くの方法があります。デプロイの種類に関係なく、ロードバランサのすべてのコンポーネントを同じ組織と同じ共有 VPC ネットワークに配置する必要があります。

サポートされている共有 VPC アーキテクチャの詳細については、以下をご覧ください。

内部 TCP / UDP ロードバランサの作成

次の例では、共有 VPC ネットワークで内部 TCP / UDP ロードバランサを作成する際の考慮事項について説明します。サービスプロジェクト管理者は、ホストプロジェクトでアクセス権のあるサブネットを使用する内部 TCP / UDP ロードバランサを作成できます。ロードバランサの内部転送ルールはサービスプロジェクトで定義されますが、サブネット参照はホストプロジェクトの共有 VPC ネットワーク内のサブネットを参照します。

共有 VPC 環境で内部 TCP / UDP ロードバランサを作成する前に、共有 VPC アーキテクチャをご覧ください。

コンソール

Google Cloud コンソールの [ロードバランシング] ページに移動します。
[ロードバランシング] ページに移動
内部 TCP / UDP ロードバランサを作成して、次の調整を行います。[フロントエンドサービスの構成] セクションに移動し、[サブネット] メニューの [他のプロジェクトで共有されるネットワーク] セクションから必要な共有 VPC サブネットを選択します。
ロードバランサの作成を完了します。

gcloud

内部転送ルールを作成する場合は、--subnet フラグを使用してホストプロジェクトのサブネットを指定します。

gcloud compute forwarding-rules create FR_NAME \
    --project SERVICE_PROJECT_ID \
    --load-balancing-scheme internal \
    --region REGION \
    --ip-protocol IP_PROTOCOL \
    --ports PORT,PORT,... \
    --backend-service BACKEND_SERVICE_NAME \
    --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \
    --address INTERNAL_IP

次のように置き換えます。

FR_NAME は、転送ルールの名前に置き換えます。
SERVICE_PROJECT_ID は、サービスプロジェクトの ID に置き換えます。
REGION は、共有サブネットが含まれているリージョンに置き換えます。
IP_PROTOCOL は、ロードバランサのバックエンドサービスのプロトコルに合わせて TCP または UDP のいずれかに置き換えます。
PORT は、ロードバランサの数値ポートまたはポートのリストに置き換えます。
BACKEND_SERVICE_NAME は、バックエンドサービスの名前（内部 TCP / UDP ロードバランサの作成の一般的な手順で作成済み）に置き換えます。
HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID に置き換えます。
SUBNET は、共有サブネットの名前に置き換えます。
INTERNAL_IP は、共有サブネット内の内部 IP アドレス（指定しなかった場合、使用可能なアドレスが選択されます）に置き換えます。

gcloud compute forwarding-rules create で使用可能なオプションの詳細については、こちらのページをご覧ください。

API

内部転送ルールを作成し、ホストプロジェクトのサブネットを指定します。

POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/regions/REGION/forwardingRules
{
  "name": "FR_NAME",
  "IPAddress": "IP_ADDRESS",
  "IPProtocol": "PROTOCOL",
  "ports": [ "PORT", ... ],
  "loadBalancingScheme": "INTERNAL",
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET",
  "network": "https://www.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME",
  "backendService": "https://www.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/regions/us-west1/backendServices/BE_NAME",
  "networkTier": "PREMIUM"
}

プレースホルダを有効な値に置き換えます。

BE_NAME は、バックエンドサービスの名前（内部 TCP / UDP ロードバランサの作成の一般的な手順で作成済み）です。
FR_NAME は転送ルールの名前です。
HOST_PROJECT_ID は、共有 VPC ホストプロジェクトの ID です。
IP_ADDRESS は、共有サブネットの内部 IP アドレスです。
IP_PROTOCOL は、ロードバランサのバックエンドサービスのプロトコルに合わせて TCP または UDP のいずれかです。
PORT は、ロードバランサの数値ポートまたはポートのリストです。
REGION は、共有サブネットを含むリージョンです。
SERVICE_PROJECT_ID は、サービスプロジェクトの ID です。
SUBNET は共有サブネットの名前です。

詳細については、forwardingRules.insert メソッドをご覧ください。

Terraform

Terraform データブロックを使用して、ホストサブネットとホストネットワークを指定できます。次に、Terraform リソースを使用して転送ルールを作成します。

ホストネットワークを指定します。

examples/basic_shared_vpc/main.tf

GitHub で表示

data "google_compute_network" "network" {
  name    = "my-network-123"
  project = var.project
}

ホストサブネット情報を指定します。

examples/basic_shared_vpc/main.tf

GitHub で表示

data "google_compute_subnetwork" "subnet" {
  name    = "my-subnet-123"
  project = var.project
  region  = "us-central1"
}

サービスプロジェクトで、ホストプロジェクトのネットワークとサブネットに転送ルールを作成します。

examples/basic_shared_vpc/main.tf

GitHub で表示

resource "google_compute_forwarding_rule" "default" {
  project               = var.service_project
  name                  = "l4-ilb-forwarding-rule"
  backend_service       = google_compute_region_backend_service.default.id
  region                = "europe-west1"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL"
  all_ports             = true
  allow_global_access   = true
  network               = data.google_compute_network.network.self_link
  subnetwork            = data.google_compute_subnetwork.subnet.self_link
}

Terraform 構成を適用または削除する方法については、Terraform 構成の操作をご覧ください。

次のステップ

共有 VPC の詳細について、共有 VPC の概要を参照する。
共有 VPC を使用した Kubernetes Engine クラスタの設定手順を共有 VPC を使用したクラスタの設定で確認する。
Cloud Run、Cloud Functions、App Engine スタンダード環境から共有 VPC ネットワークへのアクセスを設定する方法を確認する。
共有 VPC 設定の削除手順を共有 VPC のデプロビジョニングで確認する。

共有 VPC のプロビジョニング

割り当て、上限、適格なリソース

組織の準備

管理者と IAM

組織ポリシーの制約

ホスト プロジェクトの誤削除の防止

ホスト プロジェクトの接続を制限する

サービス プロジェクトで使用できるホスト プロジェクトのサブネットを制限する

共有 VPC 管理者の指名

コンソール

gcloud

API

共有 VPC の設定

ホスト プロジェクトの有効化

コンソール

gcloud

API

Terraform

サービス プロジェクトの接続

コンソール

gcloud

API

Terraform

すべてのサブネットのサービス プロジェクト管理者

コンソール

gcloud

API

一部のサブネットのサービス プロジェクト管理者

コンソール

gcloud

API

サービス プロジェクト管理者としてのサービス アカウント

サービス プロジェクト管理者としてのユーザー管理サービス アカウント

コンソール

gcloud

API

サービス プロジェクト管理者としての Google API サービス アカウント

コンソール

gcloud

API

共有 VPC の使用

使用可能なサブネットの一覧表示

コンソール

gcloud

API

静的内部 IPv4 アドレスの予約

gcloud

API

Terraform

インスタンスの作成

コンソール

gcloud

API

Terraform

インスタンス テンプレートを作成する

コンソール

gcloud

API

Terraform

マネージド インスタンス グループを作成する

HTTP(S) ロードバランサを作成する

内部 TCP / UDP ロードバランサの作成

コンソール

gcloud

API

Terraform

次のステップ

ホストプロジェクトの誤削除の防止

ホストプロジェクトの接続を制限する

サービスプロジェクトで使用できるホストプロジェクトのサブネットを制限する

ホストプロジェクトの有効化

サービスプロジェクトの接続

すべてのサブネットのサービスプロジェクト管理者

一部のサブネットのサービスプロジェクト管理者

サービスプロジェクト管理者としてのサービスアカウント

サービスプロジェクト管理者としてのユーザー管理サービスアカウント

サービスプロジェクト管理者としての Google API サービスアカウント

インスタンステンプレートを作成する

マネージドインスタンスグループを作成する