Provisioning Shared VPC

Shared VPC allows you to export subnets from a VPC network in a host project to other service projects in the same organization. Instances in the service projects can have network connections in the shared subnets of the host project. This page describes how to set up and use Shared VPC, including some necessary administrative preparation for your organization.

Note: Shared VPC is also referred to as “XPN” in the API and command-line interface.

Quotas, limits, and eligible resources

Please make sure you are familiar with the Shared VPC Overview and the IAM Overview before you begin. Specifically:

• Make note of the quotas and limits that pertain to Shared VPC.

• Be sure to understand which resources can participate and which resources cannot participate.

Prepare your organization

Administrators and IAM

Preparing your organization, setting up Shared VPC host projects, and using Shared VPC networks involves a minimum of three different administrative IAM roles. For more details about each role and information about optional ones, see the administrators and IAM section of the Shared VPC overview.

Administrator	Purpose
Organization Admin	Organization Admins nominate Shared VPC Admins by granting them appropriate project creation and deletion roles, and the compute.xpnAdmin role for the organization. They should also define an organization-level policy to prevent the accidental deletion of Shared VPC host projects.
Shared VPC Admin	Shared VPC Admins enable Shared VPC for projects within an organization, turning them into host projects. They attach service projects to host projects and define Service Project Admins with access to some or all of the subnets in the host project.
Service Project Admin	A Shared VPC Admin defines a Service Project Admin by granting an IAM member the compute.networkUser role to either the whole host project or just some of its subnets. Service Project Admins also maintain ownership and control over resources defined in the service projects, so they must at least have the compute.instanceAdmin role to the corresponding service projects. They may have additional IAM roles to the service projects, such as project owner.

Prevent accidental deletion of host projects

The accidental deletion of a host project would lead to outages in all service projects attached to it. When a project is configured to be a Shared VPC host project, a special lock - called a lien - is placed upon it. As long as the lien is present, it prevents the project from being deleted accidentally. The lien is automatically removed from the host project when it is no longer configured for Shared VPC.

Caution: By default, a project owner can remove a lien from a project, including a Shared VPC host project, unless an organization-level policy is defined to limit lien removal. (Specifically, lien removal requires an IAM member with the resourcemanager.projects.get and resourcemanager.projects.updateLiens permissions on the project.) The project owner for the host project could remove the lien then delete the Shared VPC project. To prevent this from happening, follow the directions in this section.

An Organization Admin or other user with the orgpolicy.policyAdmin role can define an organization-level policy to limit the removal of liens to just organization owners and other users with the resourcemanager.lienModifier role. This effectively prevents a project owner who is not an organization owner and who does not have the resourcemanager.lienModifier role from being able to accidentally delete a Shared VPC host project. For more information about the permissions associated with the resourcemanager.lienModifier role, refer to Placing a lien on a project in the Resource Manager documentation.

Because an organization policy applies to all projects in the organization, you only need to follow these steps once to restrict lien removal.

1. Authenticate to gcloud as an Organization Admin or IAM member with the orgpolicy.policyAdmin role. Replace [ORG_ADMIN] with the name of an Organization Admin:

   gcloud auth login [ORG_ADMIN]
   

2. Determine your organization ID number by looking at the output of this command.

   gcloud organizations list
   

3. Enforce the compute.restrictXpnProjectLienRemoval policy for your organization by running this command. Replace [ORG_ID] with the number you determined from the previous step.

   gcloud beta resource-manager org-policies enable-enforce \
       --organization [ORG_ID] compute.restrictXpnProjectLienRemoval
   

4. Log out of gcloud if you are finished performing tasks as an Organization Admin to protect your account.

   gcloud auth revoke [ORG_ADMIN]
   

Nominate Shared VPC Admins

An Organization Admin can grant one or more IAM members the role of Shared VPC Admin, compute.xpnAdmin. This grant creates a binding at the organization level, not the project level, so the IAM members must be defined in the organization, not just a project therein.

Console

Note: If you do not see the Compute Shared VPC Admin role as an option, you might not be logged in to the Google Cloud Platform Console as an Organization Admin, or you might have selected a project instead of the whole organization.

1. Log into the Google Cloud Platform Console as an Organization Admin, then go to the IAM page.
   Go to the IAM page
2. From the project menu, select your organization.
   If you select a project, you will not see the correct entries in the Roles menu.
3. Click Add.
4. Enter the email addresses of the Members.
5. Under Roles, select Compute Engine > Compute Shared VPC Admin.
6. Click Add.

gcloud

1. Authenticate to gcloud as an Organization Admin. Replace [ORG_ADMIN] with the name of an Organization Admin:

   gcloud auth login [ORG_ADMIN]
   

2. Determine your organization ID number by looking at the output of this command.

   gcloud organizations list
   

3. Apply Shared VPC Admin role to an existing IAM member. Replace [ORG_ID] with the organization ID number from the previous step, and [EMAIL_ADDRESS] with the email address of the user to whom you are granting the Shared VPC Admin role.

   gcloud organizations add-iam-policy-binding [ORG_ID] \
       --member 'user:[EMAIL_ADDRESS]' \
       --role "roles/compute.xpnAdmin"
   

4. Log out of gcloud when you are finished performing tasks as an Organization Admin to protect your account.

   gcloud auth revoke [ORG_ADMIN]
   

Setting up Shared VPC

All tasks in this section must be performed by a Shared VPC Admin.

Enable a host project

Within an organization, Shared VPC Admins can designate projects as Shared VPC host projects, subject to quotas and limits, by following this procedure. Shared VPC Admins can also create and delete projects if they have the resourcemanager.projectCreator and resourcemanager.projectDeleter roles for your organization.

Note: The Compute Engine API must be enabled for the project becoming the Shared VPC host project and for any service projects that will attach to it. For more information, please refer to the Compute Engine API documentation.

Caution: Shared VPC host projects are protected with a lien to prevent accidental project deletion. This lien remains in effect as long as the project is a host project; however, the lien can be manually removed. We recommend that an Organization Admin define an organization-level policy to limit the users who can manually remove liens.

Console

1. Go to the Shared VPC page in the Google Cloud Platform Console.
   Go to the Shared VPC page
2. Log in as a Shared VPC Admin.
3. Select the project you want to enable as a Shared VPC host project from the project picker.
4. Click Set up Shared VPC.
5. On the next page, click Save & continue under Enable host project.
6. Under Select subnets, do one of the following:
   1. Click Share all subnets (project-level permissions) if you need to share all current and future subnets in the VPC networks of the host project with service projects and Service Project Admins specified in the next steps.
   2. Click Individual subnets (subnet-level permissions) if you need to selectively share subnets from the VPC networks of the host project with service projects and Service Project Admins. Then, select Subnets to share.
7. Click Continue.
   The next screen is displayed.
8. In Project names, specify the service projects to attach to the host project. Note that attaching service projects does not define any Service Project Admins; that is done in the next step.
9. In the Select users by role section, add Service Project Admins. These users will be grated the IAM role of compute.networkUser for the shared subnets. Only Service Project Admins can create resources in the subnets of the Shared VPC host project.
10. Click Save.

gcloud

Note: These steps simply designate a project as a Shared VPC host project. Unlike the Console directions, no service projects are attached to the host project, and no Service Project Admins are defined. After you complete these steps, you can attach service projects.

1. Authenticate to gcloud as a Shared VPC Admin. Replace [SHARED_VPC_ADMIN] with the name of the Shared VPC Admin:

   gcloud auth login [SHARED_VPC_ADMIN]
   

2. Enable Shared VPC for the project that you need to become a host project. Replace [HOST_PROJECT_ID] with the ID of the project.

   gcloud compute shared-vpc enable [HOST_PROJECT_ID]
   

3. Confirm that the project is listed as a host project for your organization. Replace [ORG_ID] with your organization ID (determined by gcloud organizations list).

   gcloud compute shared-vpc organizations list-host-projects [ORG_ID]
   

4. If you only needed to enable a host project, you can log out of gcloud to protect your Shared VPC Admin account credentials. Otherwise, skip this step and continue with the steps to attach service projects.

   gcloud auth revoke [SHARED_VPC_ADMIN]
   

Attach service projects

A service project must attach to a host project before its Service Project Admins can use the Shared VPC. A Shared VPC Admin must perform the following steps to complete the attachment.

A service project can only attach to one host project, but a host project supports multiple service project attachments. Refer to quotas and limits on the Shared VPC overview page for details.

Note: The Compute Engine API must be enabled for service projects that you plan to attach to a host project.

Console

Note: If you used the Console to enable a host project, you already attached one or more service projects to it. The following directions detail how to modify the configuration of an existing host project.

1. Log into the Google Cloud Platform Console as a Shared VPC Admin.
2. Go to the Shared VPC page in the Google Cloud Platform Console.
   Go to the Shared VPC page
3. Click the Attached projects tab.
4. Under the Attached projects tab, click the Attach projects button.
5. Check the boxes for the service projects to attach in the Project names section. Note that attaching service projects does not define any Service Project Admins; that is done in the next step.
6. In the VPC network permissions section, select Service Project Admins. Selected users will be grated the IAM role of compute.networkUser for the shared subnets. Only Service Project Admins can create resources in the subnets of the Shared VPC host project.
7. In the VPC network sharing mode section, select one of the following:
   1. Click Share all subnets (project-level permissions) to share all current and future subnets in VPC networks of the host project with all service projects and Service Project Admins.
   2. Click Individual subnets (subnet-level permissions) if you need to selectively share subnets from VPC networks of the host project with service projects and Service Project Admins. Then, select Subnets to share.
8. Click Save.

gcloud

Note: These steps only cover attaching a service project to a host project. You must first have enabled a host project.

1. If you have not already, authenticate to gcloud as a Shared VPC Admin. Replace [SHARED_VPC_ADMIN] with the name of the Shared VPC Admin:

   gcloud auth login [SHARED_VPC_ADMIN]
   

2. Attach a service project to a previously-enabled host project. Replace [SERVICE_PROJECT_ID] with the project ID for the service project and [HOST_PROJECT_ID] with the project ID for the host project.

   gcloud compute shared-vpc associated-projects add [SERVICE_PROJECT_ID] \
       --host-project [HOST_PROJECT_ID]
   

3. Confirm that the service project has been attached.

   gcloud compute shared-vpc get-host-project [SERVICE_PROJECT_ID]
   

4. Optionally, you can list the service projects that are attached to the host project:

   gcloud compute shared-vpc list-associated-resources [HOST_PROJECT_ID]
   

5. If you only needed to attach a service project, you can log out of gcloud to protect your Shared VPC Admin account credentials. Otherwise, skip this step and define Service Project Admins for all subnets or for just some subnets.

   gcloud auth revoke [SHARED_VPC_ADMIN]
   

Service Project Admins for all subnets

A Shared VPC Admin can define an IAM member from a service project as a Service Project Admin with access to all subnets in the host project. Service Project Admins of this type are granted the role of compute.networkUser for the whole host project. This means that they have access to all currently defined and future subnets in the host project.

Console

To define an IAM member from a service project as Service Project Admin with access to all subnets in a host project using the GCP Console, see the attach service projects section.

gcloud

These steps cover defining an IAM member from a service project as a Service Project Admin with access to all subnets in a host project. Before you can perform these steps, you must have enabled a host project and attached the service project to the host project.

1. If you have not already, authenticate to gcloud as a Shared VPC Admin. Replace [SHARED_VPC_ADMIN] with the name of the Shared VPC Admin:

   gcloud auth login [SHARED_VPC_ADMIN]
   

2. Create a policy binding to make an IAM member from the service project a Service Project Admin. Replace [HOST_PROJECT_ID] with the project ID for the host project and [SERVICE_PROJECT_ADMIN] with the email address of the Service Project Admin user.

   gcloud projects add-iam-policy-binding [HOST_PROJECT_ID] \
   --member "user:[SERVICE_PROJECT_ADMIN]" \
   --role "roles/compute.networkUser"
   

   You can specify different types of members by changing the format of the --member argument:

   • Use group: to specify a Google group (by email address) as a member.
   • Use domain: to specify a Google domain as a member.
   • Use serviceAccount: to specify a service account. Refer to Service Accounts as Service Project Admins for more information for this use case.

3. Repeat the previous step for each additional Service Project Admin you need to define.

4. If you are finished defining Service Project Admins, you can log out of gcloud to protect your Shared VPC Admin account credentials.

   gcloud auth revoke [SHARED_VPC_ADMIN]
   

Service Project Admins for some subnets

A Shared VPC Admin can define an IAM member from a service project as a Service Project Admin with access to only some of the subnets in the host project. This option provides a more granular means to define Service Project Admins by granting them the compute.networkUser role for only some subnets in the host project.

Console

To define an IAM member from a service project as Service Project Admin with access to only some subnets in a host project using the GCP Console, see the attach service projects section.

gcloud

These steps cover defining IAM members from a service project as Service Project Admins with access to only some subnets in a host project. Before you can define them, you must have enabled a host project and attached the service project to the host project.

1. If you have not already, authenticate to gcloud as a Shared VPC Admin. Replace [SHARED_VPC_ADMIN] with the name of the Shared VPC Admin:

   gcloud auth login [SHARED_VPC_ADMIN]
   

2. Choose the subnet in the host project to which the Service Project Admins should have access. Get its current IAM policy in JSON format. Replace [SUBNET_NAME] with the name of the subnet in the host project and [HOST_PROJECT_ID] with the project ID for the host project.

   gcloud beta compute networks subnets get-iam-policy [SUBNET_NAME] \
       --project [HOST_PROJECT_ID] \
       --format json
   

3. Copy the JSON output from the previous step and save it to a file. For instructional clarity, these steps save it to a file named subnet-policy.json.

4. Modify the subnet-policy.json file, adding the IAM members who will become Service Project Admins with access to the subnet. Replace each [SERVICE_PROJECT_ADMIN] with the email address of an IAM user from the service project.

   {
     "bindings": [
     {
        "members": [
              "user:[SERVICE_PROJECT_ADMIN]",
              "user:[SERVICE_PROJECT_ADMIN]"
           ],
           "role": "roles/compute.networkUser"
     }
     ],
     "etag": "[ETAG_STRING]"
   }
   

   Note that you can specify different types of IAM members (other than users) in the policy:

   • Switch user: with group: to specify a Google group (by email address) as a member.
   • Switch user: with domain: to specify a Google domain as a member.
   • Use serviceAccount: to specify a service account. Refer to Service Accounts as Service Project Admins for more information for this use case.

5. Update the policy binding for the subnet using the contents of the subnet-policy.json file.

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

6. If you are finished defining Service Project Admins, you can log out of gcloud to protect your Shared VPC Admin account credentials.

   gcloud auth revoke [SHARED_VPC_ADMIN]
   

Service Accounts as Service Project Admins

A Shared VPC Admin can also define service accounts from service projects as Service Project Admins. This section illustrates how to define two different types of service accounts as Service Project Admins:

• User-managed service accounts having this format: [USER_ID]@[SERVICE_PROJECT_ID].iam.gserviceaccount.com

• The Google APIs service account having this format: [SERVICE_PROJECT_NUMBER]@cloudservices.gserviceaccount.com

Like other IAM members, the role for Service Project Admin (compute.networkUser) can be granted for all subnets or only some subnets of the host project. However, for instructional simplicity, this section only illustrates how to define each of the two service account types as Service Project Admins for all subnets of the host project.

User-managed service accounts as Service Project Admins

These directions describe how to define a user-managed service account as a Service Project Admin for all subnets of the Shared VPC host project.

Console

1. Log into the Google Cloud Platform Console as a Shared VPC Admin.
2. Go to the Settings page in the Google Cloud Platform Console.
   Go to the Settings page
3. Change the project to the service project containing the service account that needs to be defined as a Service Project Admin.
4. Copy the Project number of the service project. For instructional clarity, this procedure refers to the service project number as [SERVICE_PROJECT_NUMBER].
5. Change the project to the Shared VPC host project.
6. Go to the IAM page in the Google Cloud Platform Console.
   Go to the IAM page
7. Click Add.
8. Add [SERVICE_ACCOUNT_NAME]@[SERVICE_PROJECT_NUMBER].iam.gserviceaccount.com to the Members field, replacing [SERVICE_ACCOUNT_NAME] with the name of the service account.
9. Select Compute Engine > Compute Network User from the Roles menu.
10. Click Add.

gcloud

1. If you have not already, authenticate to gcloud as a Shared VPC Admin. Replace [SHARED_VPC_ADMIN] with the name of the Shared VPC Admin:

   gcloud auth login [SHARED_VPC_ADMIN]
   

2. Determine the project number for the service project. For instructional clarity, this procedure refers to the service project number as [SERVICE_PROJECT_NUMBER]. Replace [SERVICE_PROJECT_ID] with the project ID for the service project.

   gcloud projects describe [SERVICE_PROJECT_ID] --format='get(projectNumber)'
   

   • If you don't know the project ID for the service project, you can list all projects in your organization. This list shows the project number for each.

     gcloud projects list
     

3. Create a policy binding to make the service account a Service Project Admin. Replace [HOST_PROJECT_ID] with the project ID for the host project,[SERVICE_ACCOUNT_NAME] with the name of the service account, and [SERVICE_PROJECT_NUMBER] with the service project number.

   gcloud projects add-iam-policy-binding [HOST_PROJECT_ID] \
       --member "user:[SERVICE_ACCOUNT_NAME]@[SERVICE_PROJECT_NUMBER].iam.gserviceaccount.com" \
       --role "roles/compute.networkUser"
   

Google APIs service account as a Service Project Admin

These directions describe how to define the Google APIs service account as a Service Project Admin for all subnets of the Shared VPC host project. Making the Google APIs service account a Service Project Admin is a requirement for managed instance groups used with Shared VPC because tasks like instance creation are performed by this type of service account. Refer to Managed Instance Groups and IAM for more information about this relationship.

Console

1. Log into the Google Cloud Platform Console as a Shared VPC Admin.
2. Go to the Settings page in the Google Cloud Platform Console.
   Go to the Settings page
3. Change the project to the service project containing the service account that needs to be defined as a Service Project Admin.
4. Copy the Project number of the service project. For instructional clarity, this procedure refers to the service project number as [SERVICE_PROJECT_NUMBER].
5. Change the project to the Shared VPC host project.
6. Go to the IAM page in the Google Cloud Platform Console.
   Go to the IAM page
7. Click Add.
8. Add [SERVICE_PROJECT_NUMBER]@cloudservices.gserviceaccount.com to the Members field.
9. Select Compute Engine > Compute Network User from the Roles menu.
10. Click Add.

gcloud

1. If you have not already, authenticate to gcloud as a Shared VPC Admin. Replace [SHARED_VPC_ADMIN] with the name of the Shared VPC Admin:

   gcloud auth login [SHARED_VPC_ADMIN]
   

2. Determine the project number for the service project. For instructional clarity, this procedure refers to the service project number as [SERVICE_PROJECT_NUMBER]. Replace [SERVICE_PROJECT_ID] with the project ID for the service project.

   gcloud projects describe [SERVICE_PROJECT_ID] --format='get(projectNumber)'
   

   • If you don't know the project ID for the service project, you can list all projects in your organization. This list shows the project number for each.

     gcloud projects list
     

3. Create a policy binding to make the service account a Service Project Admin. Replace [HOST_PROJECT_ID] with the project ID for the host project and [SERVICE_PROJECT_NUMBER] with the service project number.

   gcloud projects add-iam-policy-binding [HOST_PROJECT_ID] \
       --member "serviceAccount:[SERVICE_PROJECT_NUMBER]@cloudservices.gserviceaccount.com" \
       --role "roles/compute.networkUser"
   

Using Shared VPC

Once a Shared VPC Admin completes the tasks of enabling a host project, attaching the necessary service projects to it, and defining Service Project Admins for all or some of the host project subnets, the Service Project Admins can create instances, templates, and internal load balancers in the service projects using the subnets of the host project.

All tasks in this section must be performed by a Service Project Admin.

It's important to note that a Shared VPC Admin only grants the Service Project Admins the compute.networkUser role (to either the whole host project or just some of its subnets). Service Project Admins should also have other roles necessary to administer their respective service projects. For example, a Service Project Admin could also be a project owner or should at least have the compute.instanceAdmin role for the project.

Caution: The compute.networkUser and compute.networkAdmin roles have different permission sets. The compute.networkUser role includes permissions that are not available in the compute.networkAdmin role. An IAM member having the compute.networkAdmin role for an organization or project but lacking the compute.networkUser role for the host project or at least one of the subnets in the host project is not a Service Project Admin.

Listing available subnets

Service Project Admins can list the subnets to which they have been given permission by following these steps.

Console

Go to the Shared VPC page in the Google Cloud Platform Console.
Go to the Shared VPC page

gcloud

1. If you have not already, authenticate to gcloud as a Service Project Admin. Replace [SERVICE_PROJECT_ADMIN] with the name of the Service Project Admin:

   gcloud auth login [SERVICE_PROJECT_ADMIN]
   

2. Run the following command, replacing [HOST_PROJECT_ID] with the project ID of the Shared VPC host project:

   gcloud alpha compute networks subnets list-usable --project [HOST_PROJECT_ID]
   

Reserving a static internal IP

Service Project Admins can reserve an internal IP address in a subnet of a Shared VPC network. Note that the IP address configuration object is created in the service project, while its value comes from the range of available addresses in the chosen shared subnet.

gcloud

1. If you have not already, authenticate to gcloud as a Service Project Admin. Replace [SERVICE_PROJECT_ADMIN] with the name of the Service Project Admin:

   gcloud auth login [SERVICE_PROJECT_ADMIN]
   

2. Run the following command, replacing [HOST_PROJECT_ID] with the project ID of the Shared VPC host project:

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

Where you would replace the following:

• [IP_ADDR_NAME] with a name for the IP address object
• [SERVICE_PROJECT_ID] with the ID of the service project
• [HOST_PROJECT_ID] with the ID of the Shared VPC host project
• [REGION] with the region containing the shared subnet
• [SUBNET] with the name of the shared subnet

Additional details for creating IP addresses are published in the SDK documentation.

Creating an instance

Keep the following in mind when creating an instance using Shared VPC:

• The standard process for creating an instance involves selecting a zone, a network, and a subnet. Both the selected subnet and the selected zone must be in the same region. When a Service Project Admin creates an instance using a subnet from a Shared VPC network, the zone selected for that instance must be one in the same region as the selected subnet.

  • When creating an instance with a reserved static internal IP address, the subnet (and region) were already selected when the static IP address was created. A gcloud example for creating an instance with a static internal IP address is given in this section.

• Service Project Admins can only create instances using subnets to which they have been granted permission. See listing available subnets to determine which subnets are available.

• When GCP receives a request to create an instance in a subnet of a Shared VPC network, it checks to see if the IAM member making the request has permission to use that shared subnet. If the check fails, the instance will not be created, and GCP will return a permissions error. Contact the Shared VPC Admin for assistance.

Console

1. Go to the VM instances page in the Google Cloud Platform Console.
   Go to the VM instances page
2. Click Create.
3. Specify a Name for the instance.
4. Click Management, disk, networking, SSH keys.
5. Click Networking.
6. Click the Networks shared with me radio button.
7. Select the Shared subnet where you want to create the instance.
8. Specify any other necessary parameters for the instance.
9. Click Create.

gcloud

• To create an instance with an ephemeral internal IP address in a shared subnet of a Shared VPC network:

  gcloud compute instances create [INSTANCE_NAME] \
  --project [SERVICE_PROJECT_ID] \
  --subnet projects/[HOST_PROJECT_ID]/regions/[REGION]/subnetworks/[SUBNET] \
  --zone [ZONE]
  

  Where you would replace the following:

  • [INSTANCE_NAME] with the name of the instance
  • [SERVICE_PROJECT_ID] with the ID of the service project
  • [HOST_PROJECT_ID] with the ID of the Shared VPC host project
  • [REGION] with the region containing the shared subnet
  • [SUBNET] with the name of the shared subnet
  • [ZONE] with a zone in the specified region

• To create an instance with a reserved static internal IP address in a Shared VPC network:

  1. Reserve a static internal IP address.

  2. Create the instance:

     gcloud compute instances create [INSTANCE_NAME] \
     --project [SERVICE_PROJECT_ID] \
     --private-network-ip [IP_ADDR_NAME] \
     --zone [ZONE]
     

     Where you would replace the following:

     • [INSTANCE_NAME] with the name of the instance
     • [SERVICE_PROJECT_ID] with the ID of the service project
     • [HOST_PROJECT_ID] with the ID of the Shared VPC host project
     • [IP_ADDR_NAME] with the name of the static IP. Choosing a static internal IP implies specifying a subnet and region.
     • [ZONE] with a zone in the same region as [IP_ADDR_NAME]

Creating an instance template

Keep the following in mind when creating an instance template using Shared VPC:

• The process for creating an instance template involves selecting a network and a subnet.

• Templates created for use in a custom mode Shared VPC network must specify both the network and a subnet.

• Templates created for use in an auto mode Shared VPC network may optionally defer selecting a subnet. In these cases, a subnet will be automatically selected in the same region as any managed instance group that uses the template. (Auto mode networks have a subnet in every region by definition.)

• When an IAM member creates an instance template, GCP does not perform a permissions check to see if the member can use the specified subnet. This permissions check is always deferred to when a managed instance group using the template is requested.

Console

1. Go to the Instance templates page in the Google Cloud Platform Console.
   Go to the Instance templates page
2. Click Create instance template.
3. Specify a Name for the instance template.
4. Click Management, disk, networking, SSH keys.
5. Click Networking.
6. Click the Networks shared with me radio button.
7. Select the Shared subnet where you want to create the instance template.
8. Specify any other necessary parameters for the instance template.
9. Click Create.

gcloud

• To create an instance template for use in any automatically-created subnet of an auto mode Shared VPC network:

  gcloud compute instance-templates create [TEMPLATE_NAME] \
  --project [SERVICE_PROJECT_ID] \
  --network projects/[HOST_PROJECT_ID]/global/networks/[NETWORK]
  

  Where you would replace the following:

  • [TEMPLATE_NAME] with the name of the template
  • [SERVICE_PROJECT_ID] with the ID of the service project
  • [HOST_PROJECT_ID] with the ID of the Shared VPC host project
  • [NETWORK] with the name of the Shared VPC network

• To create an instance template for a manually-created subnet in a Shared VPC network (either auto or custom mode):

  gcloud compute instance-templates create [TEMPLATE_NAME] \
  --project [SERVICE_PROJECT_ID] \
  --region [REGION] \
  --subnet projects/[HOST_PROJECT_ID]/regions/[REGION]/subnetworks/[SUBNET]
  

  Where you would replace the following:

  • [TEMPLATE_NAME] with the name of the template
  • [SERVICE_PROJECT_ID] with the ID of the service project
  • [HOST_PROJECT_ID] with the ID of the Shared VPC host project
  • [REGION] with the region containing the shared subnet
  • [SUBNET] with the name of the shared subnet

Creating a managed instance group

Keep the following in mind when creating a managed instance group using Shared VPC:

• Managed instance groups used with Shared VPC require making the Google APIs service account a Service Project Admin because tasks like automatic instance creation via autoscaling are performed by that service account.

• The standard process for creating a managed instance group involves selecting a zone or region, depending on the group type, and an instance template. (Network and subnet details are tied to the instance template.) Eligible instance templates are restricted to those that reference subnets in the same region used by the managed instance group.

• Service Project Admins can only create managed instance groups whose member instances use subnets to which they have been granted permission. Because the network and subnet details are tied to the instance template, Service Project Admins can only use templates that reference subnets that they are authorized to use.

• When GCP receives a request to create a managed instance group, it checks to see if the IAM member making the request has permission to use the subnet (in the same region as the group) specified in the instance template. If the check fails, the managed instance group will not be created, and GCP will return a permissions error. List available subnets to determine which ones can be used, and contact the Shared VPC Admin for assistance.

Console

1. Go to the Instance groups page in the Google Cloud Platform Console.
   Go to the Instance groups page
2. Click Create instance group.
3. Specify a Name for the instance group.
4. In the Location section, choose to create a zonal or regional (multi-zone) group.
5. Select a Zone or Region as appropriate.
6. If creating a zonal group, under Group type, ensure Managed instance group is selected. Regional instance groups must be managed instance groups.
7. Under Instance template, select an instance template defined for the Shared VPC network. Available templates must have been defined for a subnet in the same region as the one chosen for the instance group.
8. Specify options for Autoscaling; otherwise, specify the Number of instances.
9. Specify options for Autohealing.
10. Click Create.

gcloud

Service Project Admins can create a managed instance group using gcloud if they have permission to use the shared subnet specified in the instance template:

gcloud compute instance-groups managed create [INSTANCE_GROUP_NAME] \
    --project [SERVICE_PROJECT_ID] \
    --template [INSTANCE_TEMPLATE_NAME] \
    --size [NUMBER_OF_INSTANCES] \
    --zone [ZONE]

Where you would replace the following:

• [INSTANCE_GROUP_NAME] with the name of the instance group
• [SERVICE_PROJECT_ID] with the ID of the service project
• [INSTANCE_TEMPLATE_NAME] with the name of the instance template
• [NUMBER_OF_INSTANCES] with the number of instances to create in the group
• [ZONE] with a zone in the same region as the subnet (defined in the instance template)

To create a regional instance group, replace the --zone parameter with the --region parameter and specify a region (which must be the same as the region used by the subnet defined in the instance template).

For details on how to configure autoscaling and autohealing, refer to the SDK documentation.

Creating an internal load balancer

The following procedure illustrates how to create an internal load balancer whose forwarding rule uses a subnet in the Shared VPC host project. Note that the forwarding rule itself is still defined in the service project, and that the subnet reference is only used by internal fowarding rules.

Before you create an internal load balancer in a host project, you may want to review the following:

• The general procedure for creating an internal load balancer

• Special notes for creating an internal load balancer with Shared VPC. Note that you can only create an internal load balancer in a subnet of the host project. For all other types of load balancers, you must create their resources entirely within the service projects where the backend instances reside.

Console

1. Go to the Load balancing page in the Google Cloud Platform Console.
   Go to the Load balancing page

2. Follow the general procedure to create an internal load balancer, making the following adjustment:

   • In the Configure frontend services section, select the Shared VPC subnet you need from the Networks shared by other projects section of the Subnet menu.

3. Finish creating the internal load balancer.

gcloud

Service Project Admins can create an internal load balancer in a subnet of the host project to which they have access. Follow the general procedure to create an internal load balancer, but specify a subnet of the Shared VPC with the --subnet argument when you create the forwarding rule.

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]

Where you would replace the following:

• [FR_NAME] with the name of the forwarding rule
• [SERVICE_PROJECT_ID] with the ID of the service project
• [REGION] with the region containing the shared subnet
• [IP_PROTOCOL] with the IP protocol to use; the default is TCP
• [PORT] with the numeric port or list of ports for the load balancer
• [BACKEND_SERVICE_NAME] with the name of the Backend Service (created already as part of the general procedure for creating an internal load balancer)
• [HOST_PROJECT_ID] with the ID of the Shared VPC host project
• [SUBNET] with the name of the shared subnet
• [INTERNAL_IP] with an internal IP address in the shared subnet (if unspecified, an available one will be selected)

Refer to this page for more options to use with gcloud compute forwarding-rules create.

What's next

• See Deprovisioning Shared VPC for instructions on deleting a Shared VPC setup.