Configuring Private Services Access

Private services access is a private connection between your VPC network and a network owned by Google or a third party. Google or the third party, entities who are offering services, are also known as service producers. The private connection enables VM instances in your VPC network and the services that you access to communicate exclusively by using internal (RFC 1918) IP addresses. VM instances don't need Internet access or external IP addresses to reach services through private services access.

Private services access allows access to certain Google Cloud services. For details about this and other private access options, see Private Access Options for Services.

To create a private connection, you must allocate an IP address range in your VPC network and then create a private connection to a service.

Private connections are a one-to-one relationship between your VPC network and a service producer. If a single service producer offers multiple services, you only need one private connection for all of the producer's services.

Before you begin

To establish a private connection, complete the following perquisites:

  • Verify that the service is available for private services access.
  • Create a GCP project or choose an existing one. To learn how to create a GCP project, see Creating and Managing Projects.
  • Activate the ServiceNetworking API in your project. When you do, a service account is added to your project that allows Service Networking to manage the private connections on your behalf.
  • You must have an existing VPC network that you will use to connect to the service producer's network. VM instances must use this VPC network to connect to services over a private connection.
  • Install the Cloud SDK if you want to run the gcloud command-line examples in this guide.

Permissions

Project owners, editors, and IAM members with the Network Admin role can create allocated IP address ranges and manage private connections.

For more information on roles, read the VPC IAM roles documentation.

Creating allocated IP address ranges

Before you create a private connection, you must allocate an IP address range to be used by the service producer's VPC network. This ensures that there's no IP address collision between your VPC network and the service producer's network.

When you allocate a range in your VPC network, that range is ineligible for subnets (primary and secondary ranges) and destinations of custom static routes.

You create a single allocated range for each service producer. A single service producer can offer multiple services, so make the allocated range large enough to support all of the services that you'll use. To use Google services, you must create an allocated range that has a minimum size of a single /16 block (65,536 addresses). For Google services, it's recommended that you name the allocated range by using the following format: google-managed-services-[your network name]. This is the same format that Google services use to create allocated ranges on your behalf. By following this convention, you can prevent yourself or other users from inadvertently creating multiple allocated ranges for Google. If someone or another service tries to create another allocated range, the creation fails because they would have the same name.

Before you allocate an IP address range, consider the following constraints:

  • Select a range that doesn't overlap with existing allocated ranges, subnets, or custom static routes. No two ranges can overlap.
  • If you're using an auto mode VPC network, you can't create an allocated range that matches or overlaps with 10.128.0.0/9. This range is for automatically created subnets.
  • Select a CIDR block that large enough to meet your current and future needs. If you later find that the range isn't sufficient in size, expand the range if possible. Although you can assign multiple allocations to a single service producer, Google enforces a quota on the number of IP address ranges that you can allocate, not the size (netmask) of each range.
  • Don't reuse the same allocated range for multiple service producers. Although it's possible, doing so can lead to IP address overlap. Each service producer has visibility only into their network and can't know which IP addresses other service producers are using.
  • You can only assign one CIDR block to an allocated range when you create the allocation. If you need to expand the IP address range, you can't add more blocks to an allocation. Instead, you can create another allocation or recreate the existing one by using a larger block that encompasses the new and existing ranges.

gcloud

Create an allocated range in your VPC network.

  • To specify an address range and a prefix length (subnet mask), use the addresses and prefix-length flags. For example, to allocate the CIDR block 192.168.0.0/16, specify 192.168.0.0 for the address and 16 for the prefix length.

    gcloud beta compute addresses create [RESERVED_RANGE_NAME] \
        --global \
        --purpose=VPC_PEERING \
        --addresses=192.168.0.0 \
        --prefix-length=16 \
        --description=[DESCRIPTION] \
        --network=[VPC_NETWORK] \
    

  • To specify just a prefix length (subnet mask), just use the prefix-lenth flag. When you omit the address range, GCP automatically selects an unused address range in your VPC network. The following example selects an unused IP address range with a 16 bit prefix length.

    gcloud beta compute addresses create [RESERVED_RANGE_NAME] \
        --global \
        --purpose=VPC_PEERING \
        --prefix-length=16 \
        --description=[DESCRIPTION] \
        --network=[VPC_NETWORK] \
    

Replace the following placeholders with relevant values:

  • [RESERVED_RANGE_NAME] is a name for the allocated range, such as my-allocated-range.
  • [DESCRIPTION] a description for the range, such as allocated for my-service.
  • [VPC_NETWORK] the name of your VPC network, such as my-vpc-network.

The following example, creates a private connection to Google so that the VM instances in the my-network VPC network can use private services access to reach Google services that support it.

gcloud beta compute addresses create google-managed-services-my-network \
    --global \
    --purpose=VPC_PEERING \
    --prefix-length=16 \
    --description="peering range for Google" \
    --network=my-network \
    --project=my-project

Creating a private connection

After you create an allocated range, you can create a private connection to a service producer. The private connection establishes a VPC Network Peering connection between your VPC network and the service producer's network. Because of this implementation, VPC Network Peering quotas and limits apply.

For each VPC network, create a private connection to each service producer. When you do, use a unique allocation for each service producer. This practice helps you manage your network settings, such as routes and firewall rules, for each service producer.

If you are using Shared VPC, specify the correct host project and Shared VPC network in the host project. VM instances in service projects that use the Shared VPC network can use the private connection to reach the service producer's service.

gcloud

  1. Create a private connection.

    gcloud beta services vpc-peerings connect \
        --service=servicenetworking.googleapis.com \
        --ranges=[RESERVED_RANGE_NAME] \
        --network=[VPC_NETWORK] \
        --project=[PROJECT_ID]
    

    • [RESERVED_RANGE_NAME] is the name of one or more allocated ranges.
    • [VPC_NETWORK] is the name of your VPC network.
    • [PROJECT_ID] is the ID of the project that contains your VPC network.

    The command initiates a long-running operation, returning an operation name.

  2. Check whether the operation was successful.

    gcloud beta services vpc-peerings operations describe \
        --name=[OPERATION_NAME]
    

    Replace [OPERATION_NAME] with the operation name that was returned from the previous step.

You can specify more than one allocated range when you create a private connection. However, you can't modify the assigned allocations after the connection is created. Instead, you must recreate the connection. For example, if a range has been exhausted, you can recreate the connection and specify additional allocated ranges. The service will use IP addresses from all of the provided ranges in the order that you specified.

Listing private connections

After you create a private connection, you can list it to check that it exists. The list also shows the list of allocated ranges that are associated with each connection. For example, if you don't remember which allocated range you assigned to a connection, view the list to find out.

gcloud

List private connections in your VPC network.

gcloud beta services vpc-peerings list \
    --network=[VPC_NETWORK] \
    --project=[PROJECT_ID]

Replace [VPC_NETWORK] and [PROJECT_ID] with the name of your VPC network and the it's project ID.

Removing private connections

To remove a private connection, delete the VPC Network Peering session.

When you delete the VPC Network Peering session, you VPC network is disconnected from the service producer's VPC network. Existing resources in both networks remain but lose private services access. You can re-establish connectivity by creating a private connection again.

Deleting an allocation

Before you delete an allocated IP address range, check that you have removed all private connections that are using it. If you don't, connected service producers won't be able to provision new resources if they require additional subnets.

gcloud

Delete the allocation by specifying the name of your allocation.

gcloud compute addresses delete [NAME]

Troubleshooting

How much of my allocation is being used?

When you create a private connection with a service producer, you allocate an IP address range for them to use. If you use multiple services from a service producer, each service will reserve a chunk of IP addresses from that allocated range. You can check which services are using which IP addresses so that, for example, you can see which services are using large blocks of IP addresses and avoid IP address exhaustion.

To view which service is using a particular IP address range:

  1. List your private connections.
  2. Find the peering connection name that connects you to the relevant service producer.
  3. List the routes for your VPC network.
  4. Find the routes with a next hop that match the peering connection name. The destination range of the routes indicates which IP addresses each service is using.

IP address range exhaustion or deletion

For a given private connection, if you exhaust your allocated IP address space, you can expand the existing allocation. The expanded allocation must be a contiguous IP address range that includes the existing range.

To expand an existing allocation:

  1. List your private connections and record the name of the allocated range you need to expand.
  2. Delete the existing allocated range.
  3. Create a new allocated range by using the same name as the deleted range. Specify an IP address range that includes the deleted IP address range. That way existing peered resources that are using the old allocated range can continue to use the same IP addresses without colliding with resources in your VPC network. For example, if the previous allocated range was 192.168.0.0/24, create a new allocated range for 192.168.0.0/16.

If you can't expand your existing allocation, you can add a new allocated range to the private connection. This method requires you to recreate the connection for each VPC network and causes disruptions in connectivity to the service.

To add allocated ranges to an existing private connection:

  1. List your private connections and record the names of the allocated ranges assigned to the private connection.
  2. Create a new allocated range. This range doesn't have to be contiguous with existing allocated ranges.
  3. Remove the exiting private connection.
  4. Create a new connection, specifying the recorded and the newly allocated ranges.
Was this page helpful? Let us know how we did:

Send feedback about...