Shared VPC

This page provides an overview of Shared VPC in Google Cloud.Shared VPC allows anorganization toconnect resources from multiple projects to a commonVirtual Private Cloud (VPC) network so that they cancommunicate with each other securely and efficiently by using internal IPaddresses from that network.

When you use Shared VPC,you designate a project as ahost project and attach one or more otherservice projects to it. The VPC networks in the host project are calledShared VPC networks.Eligible resourcesfrom service projects can use subnets in the Shared VPC network.

Shared VPC letsorganizationadministratorsdelegate administrative responsibilities, such as creating and managinginstances, toService Project Admins while maintainingcentralized 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 theadministrators 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 thebilling section for more details.

Shared VPC connects projects within the sameorganization.Linked projects can be in the same or differentfolders, butif they are in different folders the admin must haveShared VPC Admin rights to both folders. Referto the Google Cloudresourcehierarchy formore information about organizations, folders, and projects.

Participating host and service projects cannot belong to differentorganizations. The only exception is during a migration of your projectsfrom one organization to another. During the migration, service projects canbe in a different organization than the host project temporarily. For moreinformation about migrating projects, seeMigratingprojects.

A project that participates in Shared VPC is either ahost project or aservice project:

• A host project contains one or moreShared VPCnetworks. AShared VPC Admin mustfirstenable a project as ahost project. After that, a Shared VPC Admin can attach one or moreservice projects to it.

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

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

• You can create and use multiple host projects; however, each service projectcan only be attached to a single host project. For an illustration, see themultiple host projects example.

• You can create networks, subnets, secondary address ranges, firewall rules,and other network resources in the host project. The host project can thenshare selected subnets, including secondary ranges, with theservice projects. Services running in a service project can useShared VPC to communicate with resources running in the otherservice projects.

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

Astandalone VPC network is an unshared VPCnetwork that exists in either a standalone project or a service project.

Networks

AShared VPC network is aVPCnetwork defined in a host project and made available as acentrally shared network foreligible resources inservice projects. Shared VPC networks can be eitherauto or custommode, butlegacynetworks are not supported.

When a host project is enabled, you have two options for sharing networks:

• You can share all host project subnets. If you select this option, thenany new subnets created in the host project, including subnets in newnetworks, will also be shared.
• You can specify individual subnets to share. If you share subnetsindividually, then only those subnets are shared unless you manually changethe list.

Host and service projects are connected by attachmentsat the project level.Subnets of the Shared VPC networks in the host project are accessible by ServiceProject Admins as described in the next section,administrators andIAM.

Organization policy constraints

Organization policies and IAM permissionsworktogetherto provide different levels of access control. Organization policies enable youto set controls at the organization, folder, or project level.

If you are anorganization policyadministrator,you can specify the following Shared VPC constraints in an organization policy:

• You can limit the set of host projects to which a non-host project or non-hostprojects in a folder or organization can be attached. The constraint applieswhen a Shared VPC Admin attaches a service project with a host project.The constraint doesn't affectexisting attachments.Existing attachments remain intact even if a policy denies new ones. For moreinformation, see theconstraints/compute.restrictSharedVpcHostProjectsconstraint.

• You can specify the Shared VPC subnets that a service project canaccess at the project, folder, or organization level. The constraint applieswhen you create new resources in the specified subnets and doesn't affectexisting resources.Existing resources continue to operate normally intheir subnets even if a policy prevents new resources from being added. For moreinformation, see theconstraints/compute.restrictSharedVpcSubnetworksconstraint.

Administrators and IAM

Shared VPC makes use ofIdentity and Access Management(IAM) roles for delegated administration. The followingroles can be granted toIAMprincipals, such as users, Googlegroups, Google domains, or Google Cloud service accounts. If you needto contact any of these admins, you can look them up in your organization's orproject'sIAM policy. If you don't have therequired permissions, you must contact a network or project administrator inyour organization.

Required administrative roles

Service Project Admins

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

• Project-level permissions: A Service Project Admin can be defined to havepermission to use allsubnets in the hostproject if the Shared VPC Admin grants the role ofcompute.networkUser forthe whole host project to the Service Project Admin. The result is that theService Project Admin has permission to use all subnets in all VPC networks ofthe host project, including subnets and VPC networks added to the host projectin the future.

• Subnet-level permissions: Alternatively, a Service Project Admin can begranted a more restrictive set ofpermissions to use only somesubnets if the Shared VPC Admingrants the role ofcompute.networkUser for those selected subnets to theService Project Admin. A Service Project Admin who only has subnet-levelpermissions is restricted to using only those subnets. After new Shared VPCnetworks or new subnets are added to the host project, a Shared VPC Adminshould review the permission bindings for thecompute.networkUser role toensure that the subnet-level permissions for all Service Project Admins matchthe 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 delegatecertain network administrative tasks to other IAM principals:

Specifications

Quotas and limits

Shared VPC host projects are subject to standardper-projectVPC quotas. Shared VPC networksare subject to theper-network limits andper-instance limits for VPCnetworks. Additionally, the relationships between host and service projects aregoverned bylimits specific to Shared VPC.

Billing

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

• Therates and rules used to calculate billing amountsfor resources in service projects using a Shared VPC network is the same as ifthe resources were located in the host project itself.
• Billing for outbound traffic generated by a resource is attributed to theproject where the resource is defined:
  • Outbound traffic from an instance is attributed to the project containingthe instance. For example, if an instance is created in a service projectbut uses a Shared VPC network, any billing for outbound traffic that itgenerates is attributed to its service project. In this way, you can useShared VPC to organize resources into cost centers for your organization.
  • Costs associated with aload balancer are chargedto the project containing the load balancer components. For more detailsabout load balancing and Shared VPC, seethe load balancingsection.
  • Outbound traffic to VPNs is attributed to the project containing the VPNGateway resource. For example, if a VPN Gateway is created in theShared VPC network, it is contained in the host project. Outboundtraffic through the VPN Gateway — regardless of which serviceproject initiates the outbound data transfer — is attributed to the host project.
  • Costs for traffic from a resource in a Shared VPC service projectthat transfers out through a VLAN attachment are attributed to the project thatowns the VLAN attachment. For more information, seeCloud Interconnectpricing.

Resources

Eligible resources

You can use most Google Cloud products and features in Shared VPCservice projects.

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

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

• Some resources must be re-created in order to use a Shared VPC network. Whena Shared VPC Adminattaches an existing project to a hostproject, that project becomes aservice project, but its existing resources do not automatically use sharednetwork resources. To use a Shared VPC network, a Service Project Admin has tocreate an eligible resource and configure it to use a subnet of a Shared VPCnetwork. For example, an existing instance in a service project cannot bereconfigured to use a Shared VPC network, but a new instance can be created touse available subnets in a Shared VPC network. This limitation applies toprivate zones.

IP addresses

When you create an instance in a service project, the IP versions that youcan configure depend on the host project's subnet configuration.For more information, seeCreate an instance.

Instances in service projects attached to a host project that uses the sameShared VPC network can communicate internally with one another by using either theirinternal IPv4 addresses or their internal or external IPv6 addresses, subjectto applicablefirewall rules.

Service Project Admins can assign any of the following IP address types toresources in a service project:

• Ephemeral IPv4 and IPv6 addresses: An ephemeral IP address can beautomatically assigned to an instance in aservice project. For example, when Service Project Adminscreateinstances,they select the Shared VPC network and anavailable sharedsubnet.For instances with IPv4 addresses, the primary internal IPv4 address comesfrom the range of available IP addresses in the selected shared subnet'sprimary IPv4 address range. For instances with IPv6 addresses, the IPv6address comes from the range of available IP addresses in the selectedshared subnet's IPv6 subnet range.

  Ephemeral IPv4 addresses can also be automatically assigned to internal loadbalancers. For more information, seecreate aninternal passthrough Network Load Balancerorcreate an internal Application Load Balancer.

• Static internal IPv4 and IPv6 addresses: A static internal IPv4 or IPv6 addresscan be reserved in a service project. The internal IPv4 or IPv6 addressobjectmust be created in the same service project as the resource that uses it, eventhough the value of the IP address comes from the available IP addresses ofthe selected shared subnet in a Shared VPC network. For more information,seeReserve static internal IP4 and IPv6 addresseson the "Provision Shared VPC" page.

• Static external IPv4 addresses: External IPv4 address objects defined inthe host project can be used by resources ineither that host project orany attached service project. Service projects can also use their own externalIPv4 address objects. For example, an instance in a service project can usea regional external IPv4 address defined in either its service project or inthe host project.

• Static external IPv6 addresses: A Service Project Admin can also chooseto reserve a static external IPv6 address. The external IPv6 addressobject must be created in the same service project as the resource that usesit, even though the value of the IP address comes from the available IPv6addresses of the selected shared subnet in a Shared VPC network.For more information, seeReserve a static external IPv6 addresson theProvision Shared VPC page.

Internal DNS

VMs in the same service project can reach each other using the internal DNSnames that Google Cloud creates automatically. These DNS names use theproject ID of theservice project where the VMs are created, even though thenames point to internal IP addresses in the host project. For a completeexplanation, seeInternal DNS names and Shared VPCin theInternal DNS documentation.

Cloud DNS private zones

You can use Cloud DNS private zones in a Shared VPC network.You can create your private zone in the host project and authorize access tothe zone for the Shared VPC network or set up the zone in a serviceproject usingcross-project binding.

Load balancing

Shared VPC can be used in conjunction withCloud Load Balancing. In mostcases, you create the backend instances in a service project. In that case, allload balancer components are created in that project. While it's possible tocreate backend instances in the host project, such a setup is not well suitedfor typical Shared VPC deployments since it does not separate networkadministration and service development responsibilities.

Use the links in the following table to learn more about supportedShared VPC architectures for each type of load balancer.

Examples and use cases

Basic concepts

Figure 1 shows a simple Shared VPC scenario:

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

  • Service Project Admins inService project A can be configured to accessall or some of the subnets in the Shared VPC network. A Service ProjectAdmin with at least subnet-level permissions to the10.0.1.0/24 subnethas createdInstance A in a zone of theus-west1 region. This instancereceives its internal IP address,10.0.1.3, from the10.0.1.0/24 CIDRblock.

  • Service Project Admins inService project B can be configured to accessall or some of the subnets in the Shared VPC network. A Service ProjectAdmin with at least subnet-level permissions to the10.15.2.0/24 subnethas createdInstance B in a zone of theus-east1 region. This instancereceives its internal IP address,10.15.2.4, from the10.15.2.0/24CIDR block.

• TheStandalone Project does not participate in the Shared VPC at all; it isneither a host nor a service project. Standalone instances are created byIAM principals who have at least thecompute.InstanceAdmin role for the project.

Multiple host projects

Figure 2 shows how Shared VPC can be used to build separatetesting and production environments. For this case, an organization has decidedto use two separate host projects, aTest Environment and aProductionEnvironment.

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

  • TheApps testing andMobile testing service projects are attached totheTest environment host project. Service Project Admins in eachproject can be configured to access all or some of the subnets in theTesting network.

  • TheApps production andMobile production service projects areattached to theProduction environment host project. Service ProjectAdmins in each project can be configured to access all or some of thesubnets in theProduction network.

• Both host projects have one Shared VPC network with subnets configuredto use the same CIDR ranges. In both theTesting network andProductionnetwork, the two subnets are:

  • 10.0.1.0/24 subnet in theus-west1 region

  • 10.15.2.0/24 subnet in theus-east1 region

• ConsiderInstance AT in theApps testing service project andInstance APin theApps production service project:

  • Service Project Admins can create instances like them provided they haveat least subnet-level permissions to the10.0.1.0/24 subnet.

  • Notice that both instances use the IP address10.0.1.3. This isacceptable because each instance exists in a service project attached toa unique host project containing its own Shared VPC network. Both thetesting and production networks have been purposefully configured inthe same way.

  • Instances using the10.0.1.0/24 subnet must be located in a zone in thesame region as the subnet, even though the subnet and instances aredefined in separate projects. Because the10.0.1.0/24 subnet is locatedin theus-west1 region, Service Project Admins who create instancesusing that subnet must choose a zone in the same region, such asus-west1-a.

Hybrid cloud scenario

Figure 3 shows how Shared VPC can be used in a hybridenvironment.

For this example, an organization has a created a single hostproject with a single Shared VPC network. The Shared VPC network is connectedby usingCloud VPN to an on-premises network. Someservices and applications are hosted in Google Cloud while others arekept on-premises:

• A Shared VPC Admin enabled the host project and connected three serviceprojects to it:Service project A,Service project B, andService projectC.

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

  • The Shared VPC Admin has granted subnet-level or project-level permissionsto the necessary Service Project Admins so they cancreateinstancesthat use the Shared VPC network:

    • A Service Project Admin forService project A who has subnet-levelpermissions to the10.0.1.0/24 subnet can createInstance A in it.The Service Project Admin has to choose a zone in theus-west1region for the instance, because that is the region that contains the10.0.1.0/24 subnet.Instance A receives its IP address,10.0.1.3, from the range of free IP addresses in the10.0.1.0/24subnet.

    • A Service Project Admin forService project B who has subnet-levelpermissions to the10.15.2.0/24 subnet can createInstance B init. The Service Project Admin has to choose a zone in theus-east1region for the instance, because that is the region that contains the10.15.2.0/24 subnet.Instance B receives its IP address,10.15.2.4, from the range of free IP addresses in10.15.2.0/24subnet.

    • A Service Project Admin forService project C who has project-levelpermissions to the whole host project can create instances in any ofthe subnets in any of the VPC networks in the host project. Forexample, the Service Project Admin can createInstance C in the10.7.1.0/24 subnet, choosing a zone in theus-east1 region tomatch the region for the subnet.Instance C receives its IP address,10.7.1.50, from the range of free IP addresses in the10.7.1.0/24Subnet.

  • The Service Project Admins in each project are responsible forcreatingand managing resources.

• A Shared VPC Admin has delegated network administration tasks to other IAMprincipals who areNetwork and Security Admins forthe Shared VPC network.

  • A Network Admin has created a Cloud VPN gateway and configured a VPNtunnel through the internet to an on-premises gateway. The Cloud VPNexchanges and receives routes with its on-premises counterpart because acorresponding Cloud Router in the sameus-east1 regionhas beenconfigured.

  • If thedynamicrouting mode of the VPC isglobal, the Cloud Router applies the learned routes to the on-premisesnetwork in all subnets in the VPC network, and it shares routes to all ofthe VPC subnets with its on-premises counterpart.

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

  • Subject to applicable firewall rules, instances in the service projectscan be configured to communicate with internal services, such as databaseor directory servers located on-premises.

Two-tier web service

Figure 4 demonstrates how Shared VPC can be employed to delegateadministrative responsibilities and maintain the principle of least privilege.For this case, an organization has a web service that is separated into twotiers, and different teams manage each tier. Tier 1 represents theexternally facing component, behind anHTTP(S) loadbalancer. Tier 2 represents an internalservice upon which Tier 1 relies, and it is balanced using aninternal TCP/UDPload balancer.

Shared VPC lets you map each tier of the web service to different projectsso that they can be managed by different teams while sharing a common VPCnetwork:

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

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

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

  • The Service Project Admins in each project are responsible forcreatingand managing resources.

• Network access control is delineated as follows:

  • IAM principals who only work on Tier 1 are Service Project Admins for theTier 1 service project and are granted subnet-level permissions for onlythe10.0.1.0/24 subnet. In this example, one such Service Project Adminhas created threeTier 1 instances in that subnet.

  • IAM principals who only work on Tier 2 are Service Project Admins for theTier 2 service project and are granted subnet-level permissions for justthe10.0.2.0/24 subnet. In this example, another Service Project Adminhas created threeTier 2 instances in that subnet along with an internalload balancer whose forwarding rule uses an IP address from the rangeavailable in that subnet.

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

  • Optionally, a Shared VPC Admin can delegate network administration taskstoNetwork and Security Admins.

What's next

• To set up Shared VPC, seeProvisioning Shared VPC.
• To set up Kubernetes Engine clusters with Shared VPC, seeSetting up clusters with Shared VPC.
• To delete a Shared VPC setup, seeDeprovisioning Shared VPC.