Shared VPC overview

Shared VPC allows an
organization to
connect resources from multiple projects to a common
Virtual Private Cloud (VPC) network, so that they can communicate with each other securely
and efficiently using internal IPs from that network. When you use Shared VPC,
you designate a project as a host project and attach one or more other
service projects to it. The VPC networks in the host project are called
Shared VPC networks. Eligible
resources
from service projects can use subnets in the Shared VPC network.

Shared VPC lets organization
administrators
delegate administrative responsibilities, such as creating and managing
instances, to Service Project Admins while maintaining
centralized control over network resources like subnets, routes, and firewalls.
This model allows organizations to do the following:

Implement a security best practice of least privilege for network
administration, auditing, and access control. Shared VPC Admins can delegate
network administration tasks to Network and Security Admins in the Shared VPC
network without allowing Service Project Admins to make network-impacting
changes. Service Project Admins are only given the ability to create and
manage instances that make use of the Shared VPC network. Refer to the
administrators and IAM section for more details.

Apply and enforce consistent access control policies at the network level for
multiple service projects in the organization while delegating administrative
responsibilities. For example, Service Project Admins can
be Compute Instance Admins in their project, creating and deleting instances
that use approved subnets in the Shared VPC host project.

Use service projects to separate budgeting or internal cost centers. Refer to
the billing section for more details.

Note: Shared VPC is also referred to as "XPN" in the API.

Concepts

Organizations, folders, and projects

Shared VPC connects projects within the same
organization.
Participating host and service projects cannot belong to different
organizations. Linked projects can be in the same or different
folders, but
if they are in different folders the admin must have
Shared VPC Admin rights to both folders. Refer
to the Google Cloud resource
hierarchy for
more information about organizations, folders, and projects.

A project that participates in Shared VPC is either a host project or a
service project:

A service project is any project that has been
attached to a host project by a
Shared VPC Admin. This attachment allows it to participate in Shared VPC. It's
a common practice to have multiple service projects operated and administered
by different departments or teams in your organization.

A project cannot be both a host and a service project simultaneously. Thus, a
service project cannot be a host project to further service projects.

You can create and use multiple host projects; however, each service project
can only be attached to a single host project. See the Multiple host projects
example for an illustration.

For clarity, a project that does not participate in Shared VPC is called a
standalone project. This emphasizes that it is neither a host project nor
a service project.

When a host project is enabled, all of its existing VPC
networks become Shared VPC networks, and any new network created in it will
automatically be a Shared VPC network as well. Thus, a single host project can
have more than one Shared VPC network.

Host and service projects are connected by attachments at the project level.
Subnets of the Shared VPC networks in the host project are accessible by Service
Project Admins as described in the next section, administrators and
IAM.

Organization policy constraints

Organization policies and IAM permissions work
together
to provide different levels of access control. Organization policies enable you
to set controls at the organization, folder, or project level.

You can limit the set of host projects to which a non-host project or non-host
projects in a folder or organization can be attached. The constraint applies
when a Shared VPC Admin attaches a service project with a host project.
The constraint doesn't affect existing attachments.
Existing attachments remain intact even if a policy denies new ones. For more
information, see the
constraints/compute.restrictSharedVpcHostProject
constraint.

You can specify the Shared VPC subnets that a service project can
access at the project, folder, or organization level. The constraint applies
when you create new resources in the specified subnets and doesn't affect
existing resources.
Existing resources continue to operate normally in
their subnets even if a policy prevents new resources from being added. For more
information, see the
constraints/compute.restrictSharedVpcSubnetworks
constraint.

Administrators and IAM

Beta

This product or feature is in a pre-release state and might change or have limited support.
For more information, see the product launch
stages.

Shared VPC makes use of Identity and Access Management
(IAM) roles for delegated administration. The following
roles can be granted to IAM
members, such as users, Google
groups, Google domains, or Google Cloud service accounts. If you need
to contact any of these admins, you can look them up in your organization's or
project's IAM policy. If you don't have the
required permissions, you must contact a network or project administrator in
your organization.

Required administrative roles

Organization Admins have the
resourcemanager.organizationAdmin role for your organization.
They nominate Shared VPC Admins by granting them
appropriate
project creation and deletion roles, and the Shared VPC Admin
role for the organization. These admins can define organization-level
policies, but specific folder and project actions require additional
folder and project roles.

Shared VPC Admin (compute.xpnAdmin and resourcemanager.projectIamAdmin)
• IAM member in the organization, or
• IAM member in a folder (beta)

Shared VPC Admins have the
Compute Shared VPC Admin (compute.xpnAdmin)
and Project IAM Admin
(resourcemanager.projectIamAdmin) roles for
the organization or one or more folders. They perform various tasks
necessary to
set up Shared VPC,
such as enabling host projects, attaching service
projects to host projects, and delegating access to some or all of the
subnets in Shared VPC networks to Service Project Admins. A Shared VPC
Admin for a given host project is typically its project owner as well.
A user assigned the Compute Shared VPC Admin role for the organization has
that role for all folders in the organization. A user assigned the role
for a folder has that role for the given folder and any folders nested
underneath it. A Shared VPC Admin can link projects in two different
folders only if the admin has the role for both folders.

Service Project Admin (compute.networkUser)
• IAM member in the organization, or
• IAM member in a host project, or
• IAM member in some subnets in the host project

Service Project Admins

When defining each Service Project Admin, a Shared VPC Admin can grant
permission to use the whole host project or just some subnets:

Project-level permissions: A Service Project Admin can be defined to have
permission to use all
subnets in the host
project if the Shared VPC Admin grants the role of compute.networkUser for
the whole host project to the Service Project Admin. The result is that the
Service Project Admin has permission to use all subnets in all VPC networks of
the host project, including subnets and VPC networks added to the host project
in the future.

Subnet-level permissions: Alternatively, a Service Project Admin can be
granted a more restrictive set of permissions to use only some
subnets if the Shared VPC Admin
grants the role of compute.networkUser for those selected subnets to the
Service Project Admin. A Service Project Admin who only has subnet-level
permissions is restricted to using only those subnets. After new Shared VPC
networks or new subnets are added to the host project, a Shared VPC Admin
should review the permission bindings for the compute.networkUser role to
ensure that the subnet-level permissions for all Service Project Admins match
the intended configuration.

Network and Security Admins

Shared VPC Admins have full control over the resources in the host project,
including administration of the Shared VPC network. They can optionally delegate
certain network administrative tasks to other IAM members:

Administrator

Purpose

Network Admin
• IAM member in the host project, or
• IAM member in the organization

Shared VPC Admin define a Network Admin by granting an IAM
member the Network Admin (compute.networkAdmin) role to the
host project. Network Admins have full control over all network resources
except for firewall rules and SSL certificates.

Security Admin
• IAM member in the host project, or
• IAM member in the organization

Important: The Network Admin role does not include all of the permissions in
the Network User role. IAM members having only the Network Admin role do not
have permission to use the host project or subnets in its Shared VPC networks.

Billing

Billing for resources that participate in a Shared VPC network is attributed to
the service project where the resource is located, even though the resource uses
the Shared VPC network in the host project.

The rates and rules used to calculate billing amounts
for resources in service projects using a Shared VPC network is the same as if
the resources were located in the host project itself.

Billing for egress traffic generated by a resource is attributed to the
project where the resource is defined:

Egress traffic from an instance is attributed to the project containing
the instance. For example, if an instance is created in a service project
but uses a Shared VPC network, any billing for egress traffic that it
generates is attributed to its service project. In this way, you can use
Shared VPC to organize resources into cost centers for your organization.

Egress traffic to VPNs is attributed to the project containing the VPN
Gateway resource. For example, if a VPN Gateway is created in the
Shared VPC network, it is contained in the host project. Egress
traffic through the VPN Gateway — regardless of which service
project initiates the egress — is attributed to the host project.

Costs for egress traffic from an interconnect attachment (VLAN) in a
Shared VPC service project, which travels through an
Cloud Interconnect connection in a host project, are attributed
to the host project.

Resources

Eligible resources

The following service project resources can participate in Shared VPC
subject to certain practical limitations:

Memorystore for Redis: Refer to Memorystore for Redis
Networking for more information.

For other eligible resources, check the related product's documentation.

Practical limitations for eligible resources

The following limitations apply to resources that are eligible for participation
in a Shared VPC scenario:

Use of a Shared VPC network is not mandatory. For example, instance admins
can create instances in the service project that use a VPC network in that
project. Networks defined in service projects are not shared.

Some resources must be re-created in order to use a Shared VPC network. When
a Shared VPC Admin attaches an existing project to a host
project, that project becomes a
service project, but its existing resources do not automatically use shared
network resources. To use a Shared VPC network, a Service Project Admin has to
create an eligible resource and configure it to use a subnet of a Shared VPC
network. For example, an existing instance in a service project cannot be
reconfigured to use a Shared VPC network, but a new instance can be created to
use available subnets in a Shared VPC network. This limitation applies to
private zones.

IP addresses

Instances in service projects attached to a host project using the same
Shared VPC network can communicate with one another using either ephemeral or
reserved static internal IP addresses, subject to applicable firewall
rules.

An ephemeral internal IP address can be automatically assigned to an instance in
a service project. For example, when Service Project Admins create
instances,
they select a zone, the Shared VPC network, and an available
subnet. The IP
address comes from the range of available IP addresses in the selected shared
subnet.

Alternatively, a Service Project Admin can choose to reserve a static internal
IP address. The IP address object itself must be created in the same service
project as the instance that will use it, even though the value of the IP
address will come from the range of available IPs in a selected shared subnet of
the Shared VPC network. Refer to reserving a static internal
IP on the
Provisioning Shared VPC page for more information.

External IP addresses defined in the host project are only usable by resources
in that project. They are not available for use in service projects. Service
projects can maintain their own set of external IP addresses. For example, an
instance in a service project must use an external IP address defined in that
same service project. This is the case even if the instance uses an internal IP
address from a Shared VPC network in the host project.

Internal DNS

VMs in the same service project can reach each other using the internal DNS
names that Google Cloud creates automatically. These DNS names use the
project ID of the service project where the VMs are created, even though the
names point to internal IP addresses in the host project. For a complete
explanation, see Internal DNS names and Shared VPC
in the Internal DNS documentation.

Cloud DNS private zones

You can use Cloud DNS private zones in a Shared VPC network. You must
create your private zone in the host project and authorize access to the zone
for the Shared VPC network.

Load balancing

Shared VPC can be used in conjunction with load
balancing. All load balancing
components must exist in the same project, either all in a host project or all
in a service project. Creating some load balancer components in a host project
and others in an attached service project is not supported. However, when
you create the internal forwarding rule for an internal TCP/UDP load balancer in
a service project, you reference a shared subnet in the host project to which
the service project is attached. Refer to creating an internal TCP/UDP load
balancer
on the Provisioning Shared VPC page for more information.

The following table summarizes components for HTTP(S), SSL Proxy, and TCP Proxy
Load Balancing. In most cases, you create the backend instances in a service
project. In this case, all load balancer components are created in that project.
It's also possible to create the backend instances in the host project; in that
case, all load balancer components would need to be in the host project.

A
global backend service must be defined in the same project as the
backend instances. These instances must be in
instance groups attached to the backend service as backends. Health
checks associated with backend services must be defined in the same
project as the backend service as well.

The
target pool must be defined in the same project and same region where the
instances in the target pool exist. Health checks associated with the
target pool must be defined in the same project as well.

For the load balancer to be available in a Shared VPC network,
the Google Cloud internal IP address object must be defined
in the same service project where the backend VMs are located, and
it must reference a subnet in the desired Shared VPC network in the host
project. The address itself comes from the primary IP range of the
referenced subnet.

If you create an internal IP address object in a service project
that references a subnet in a VPC network in the service
project itself, your internal TCP/UDP load balancer will be local to
that network, not any Shared VPC network.

For the load balancer to be available in a Shared VPC network,
the internal forwarding rule must be defined in the same service
project where the backend VMs are located, and it must reference
the same subnet (in the Shared VPC network) that the associated
internal IP address references.

If you create an internal forwarding rule in a service project
that references a subnet in a VPC network in the service
project itself, your internal TCP/UDP load balancer will be local to
that network, not any Shared VPC network.

Examples and use cases

Basic concepts

A Shared VPC Admin for the organization has created a host project and
attached two service projects to it:

Service Project Admins in Service Project A can be configured to access
all or some of the subnets in the Shared VPC network. A Service Project
Admin with at least subnet-level permissions to the 10.0.1.0/24 Subnet
has created Instance A in a zone of the us-west1 region. This instance
receives its internal IP address, 10.0.1.3, from the 10.0.1.0/24 CIDR
block.

Service Project Admins in Service Project B can be configured to access
all or some of the subnets in the Shared VPC network. A Service Project
Admin with at least subnet-level permissions to the 10.15.2.0/24 Subnet
has created Instance B in a zone of the us-east1 region. This instance
receives its internal IP address, 10.15.2.4, from the 10.15.2.0/24
CIDR block.

The Standalone Project does not participate in the Shared VPC at all; it is
neither a host nor a service project. Standalone instances are created by
IAM members who have at least the compute.InstanceAdmin role for the project.

Multiple host projects

The following example demonstrates how Shared VPC can be used to build separate
testing and production environments. For this case, an organization has decided
to use two separate host projects, a Test Environment and a Production
Environment.

Multiple host projects (click to enlarge)

A Shared VPC Admin for the organization has created two host projects and
attached two service projects to them as follows:

The Apps Testing and Mobile Testing service projects are attached to
the Test Environment host project. Service Project Admins in each may be
configured to access all or some of the subnets in the Testing Network.

The Apps Production and Mobile Production service projects are
attached to the Production Environment host project. Service Project
Admins in each may be configured to access all or some of the subnets in
the Production Network.

Both host projects have one Shared VPC network with subnets configured
to use the same CIDR ranges. In both the Testing Network and Production
Network, the two subnets are:

10.0.1.0/24 Subnet in the us-west1 region

10.15.2.0/24 Subnet in the us-east1 region

Consider Instance AT in the Apps Testing service project and Instance AP
in the Apps Production service project:

Service Project Admins can create instances like them provided they have
at least subnet-level permissions to the 10.0.1.0/24 Subnet.

Notice that both instances use the IP address 10.0.1.3. This is
acceptable because each instance exists in a service project attached to
a unique host project containing its own Shared VPC network. Both the
testing and production networks have been purposefully configured in
the same way.

Instances using the 10.0.1.0/24 Subnet must be located in a zone in the
same region as the subnet, even though the subnet and instances are
defined in separate projects. Because the 10.0.1.0/24 Subnet is located
in the us-west1 region, Service Project Admins who create instances
using that subnet must choose a zone in the same region, such as
us-west1-a.

Hybrid cloud scenario

The following example demonstrates how Shared VPC can be used in a hybrid
environment.

Hybrid cloud (click to enlarge)

For this example, an organization has a created a single host
project with a single Shared VPC network. The Shared VPC network is connected
via Cloud VPN to an on-premises network. Some
services and applications are hosted in Google Cloud while others are
kept on-premises:

A Shared VPC Admin enabled the host project and connected three service
projects to it: Service Project A, Service Project B, and Service Project
C.

Separate teams can manage each of the service projects. IAM permissions
have been configured such that a Service Project Admin for one project has
no permissions to the other service projects.

The Shared VPC Admin has granted subnet-level or project-level permissions
to the necessary Service Project Admins so they can create
instances
that use the Shared VPC network:

A Service Project Admin for Service Project A who has subnet-level
permissions to the 10.0.1.0/24 Subnet can create Instance A in it.
The Service Project Admin has to choose a zone in the us-west1
region for the instance, because that is the region that contains the
10.0.1.0/24 Subnet. Instance A receives its IP address,
10.0.1.3, from the range of free IP addresses in 10.0.1.0/24
Subnet.

A Service Project Admin for Service Project B who has subnet-level
permissions to the 10.15.2.0/24 Subnet can create Instance B in
it. The Service Project Admin has to choose a zone in the us-east1
region for the instance, because that is the region that contains the
10.15.2.0/24 Subnet. Instance B receives its IP address,
10.15.2.4, from the range of free IP addresses in 10.15.2.0/24
Subnet.

A Service Project Admin for Service Project C who has project-level
permissions to the whole host project can create instances in any of
the subnets in any of the VPC networks in the host project. For
example, the Service Project Admin can create Instance C in the
10.7.1.0/24 Subnet, choosing a zone in the us-east1 region to
match the region for the subnet. Instance C receives its IP address,
10.7.1.50, from the range of free IP addresses in 10.7.1.0/24
Subnet.

A Shared VPC Admin has delegated network administration tasks to other IAM
members who are Network and Security Admins for
the Shared VPC network.

A Network Admin has created a Cloud VPN gateway and configured a VPN
tunnel through the Internet to an on-premises gateway. The Cloud VPN
exchanges and receives routes with its on-premises counterpart because a
corresponding Cloud Router in the same us-east1 region has been
configured.

If the dynamic
routing mode of the VPC is
global, the Cloud Router applies the learned routes to the on-premises
network in all subnets in the VPC network, and it shares routes to all of
the VPC subnets with its on-premises counterpart.

Security Admins create and manage firewall rules in the Shared VPC network
to control traffic among instances in Google Cloud and the
on-premises network.

Subject to applicable firewall rules, instances in the service projects
can be configured to communicate with internal services, such as database
or directory servers located on-premises.

Two-tier web service

The following example demonstrates how Shared VPC can be employed to delegate
administrative responsibilities and maintain the principle of least privilege.
For this case, an organization has a web service that is separated into two
tiers, and different teams manage each tier. Tier 1 represents the
externally-facing component, behind an HTTP(S) load
balancer. Tier 2 represents an internal
service upon which Tier 1 relies, and it is balanced using an internal TCP/UDP
load balancer.

Two-tier web service (click to enlarge)

Shared VPC allows you to map each tier of the web service to different projects
so that they can be managed by different teams while sharing a common VPC
network:

Resources, such as instances and load balancer components, for each tier are
placed in individual service projects managed by different teams.

Each tier service project has been attached to the host project by a
Shared VPC Admin. The Shared VPC Admin also enabled the host project.

Separate teams can manage each tier of the web service by virtue of being
a Service Project Admin in the appropriate service project.

IAM members who only work on Tier 1 are Service Project Admins for the
Tier 1 Service Project and are granted subnet-level permissions for just
the 10.0.1.0/24 Subnet. In this example, one such Service Project Admin
has created three Tier 1 Instances in that subnet.

IAM members who only work on Tier 2 are Service Project Admins for the
Tier 2 Service Project and are granted subnet-level permissions for just
the 10.0.2.0/24 Subnet. In this example, another Service Project Admin
has created three Tier 2 Instances in that subnet along with an internal
load balancer whose forwarding rule uses an IP address from the range
available in that subnet.

IAM members who oversee the whole web service are Service Project Admins
in both service projects, and they have project-level permissions to the
host project so they can use any subnet defined in it.