Private Service Connect overview

MySQL   |  PostgreSQL   |  SQL Server

This page describes concepts associated with Private Service Connect. You can use Private Service Connect for the following purposes:

• Connect to a Cloud SQL instance from multiple VPC networks that belong to different groups, teams, projects, or organizations
• Connect to either a primary instance or any of its read replicas

Private Service Connect endpoint

You can use Private Service Connect endpoints to access Cloud SQL instances privately from your consumer VPC networks. These endpoints are internal IP addresses that are associated with a forwarding rule that references a service attachment of a Cloud SQL instance.

You can either have Cloud SQL create the endpoint for you automatically or you can create the endpoint manually.

To have Cloud SQL create the endpoint automatically, do the following:

1. Create a service connection policy in your VPC networks.

2. Create a Cloud SQL instance with Private Service Connect enabled for the instance and configure the instance to create an endpoint automatically. While creating the instance, specify auto-connection parameters such as VPC networks and projects.

   Cloud SQL locates the service connection policy in these networks and creates a Private Service Connect endpoint that points to the service attachment of the instance.

   After you create the instance and Cloud SQL creates the endpoint, the clients in the corresponding VPC networks can connect to the instance from the endpoint, either through an IP address or a DNS record. This feature to have Cloud SQL create the endpoint automatically is available in Preview.

To create the endpoint manually, do the following:

1. Create a Cloud SQL instance with Private Service Connect enabled for the instance.
2. Get the service attachment URI that you need to create the endpoint manually.

3. Reserve an internal IP address in your VPC network for the endpoint and create an endpoint with that address.

   After you create the instance and Cloud SQL creates the endpoint, the clients in the corresponding VPC networks can connect to the instance from the endpoint, either through an IP address or a DNS record.

Note: To create a Private Service Connect endpoint, you need the compute.networkAdmin role. This role grants full control over the VPC network that initiates a connection to a Cloud SQL instance.

You must create this endpoint in each VPC network where database access is needed. To access the endpoint from any region in that network, you must configure global access for the endpoint.

Service connection policy

A service connection policy lets you authorize a specified service class to create a Private Service Connect connection between VPC networks. As a result, you can provision Private Service Connect endpoints automatically. This is available in Preview.

You can create a maximum of one policy for each service class, region, and VPC network combination. A policy dictates service connectivity automation for that specific combination. When you configure a policy, you select a subnet. The subnet is used to allocate IP addresses for the endpoints that you create through the policy. If multiple service connection policies share the same region, then you can reuse the same subnet for all of the policies.

For example, if you want to use service connectivity automation with two services in three different regions, then create six policies. You can use a minimum of three subnets: one for each region.

After you create a service connection policy, you can only update the policy's subnets and connection limit. If you need to update other fields, then do the following:

1. Remove all connections that use the policy.
2. Delete the policy.
3. Create a new policy.

Service attachment

When you create a Cloud SQL instance and configure the instance to use Private Service Connect, Cloud SQL creates a service attachment for the instance automatically. A service attachment is an attachment point that VPC networks use to access the instance.

You create a Private Service Connect endpoint that the VPC network uses to connect to the service attachment. This enables the network to access the instance.

Each Cloud SQL instance has one service attachment to which the Private Service Connect endpoint can connect through the VPC network. If there are multiple networks, then each network has its own endpoint.

DNS names and records

For instances with Private Service Connect enabled, we recommend that you use the DNS name because different networks can connect to the same instance and Private Service Connect endpoints in each network might have different IP addresses. Additionally, the Cloud SQL Auth Proxy requires DNS names to connect to these instances.

Cloud SQL doesn't create DNS records automatically. Instead, a suggested DNS name is provided from the instance lookup API response. We recommend that you create the DNS record in a private DNS zone in the corresponding VPC network. This provides a consistent way of connecting from different networks.

Allowed Private Service Connect projects

Allowed projects are associated with VPC networks and are specific to each Cloud SQL instance. If an instance isn't contained in any allowed projects, then you can't enable Private Service Connect for the instance.

For these projects, you can create Private Service Connect endpoints for each instance. If a project isn't allowed explicitly, then you can still create an endpoint for the instances in the project, but the endpoint remains in a PENDING state.

Private Service Connect endpoint propagation

Preview

This product is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products are available "as is" and might have limited support. For more information, see the launch stage descriptions.

By default, Private Service Connect connections aren't transitive from peered VPC networks. You must create a Private Service Connect endpoint in each VPC network that needs to connect to your Cloud SQL instance. For example, if you have three VPC networks that have to connect to your instance, then you must create three Private Service Connect endpoints—one endpoint for each VPC network.

However, by propagating Private Service Connect endpoints through the Network Connectivity Center hub, these endpoints can be reachable by any other spoke VPC network in the same hub. The hub provides a centralized connectivity management model to interconnect spoke VPC networks to Private Service Connect endpoints.

The connection propagation feature in Network Connectivity Center benefits the following use case for Private Service Connect deployments:

You can use a common services VPC network to create multiple Private Service Connect endpoints. By adding a single common services VPC network to the Network Connectivity Center hub, all Private Service Connect endpoints in the VPC network become accessible transitively to other spoke VPC networks through the hub. This connectivity eliminates the need to manage each Private Service Connect endpoint in each VPC network individually.

To learn how to use the Network Connectivity Center hub to propagate Private Service Connect endpoints to spoke VPC networks, see the Network Connectivity Center—Private Service Connect propagation codelab.

What's next

• Learn more about private IP.
• Learn more about connecting to an instance using Private Service Connect.