Learn about using private IP

This page provides information about using private IP with Cloud SQL. For step-by-step instructions for configuring a Cloud SQL instance to use private IP, see Configuring private IP.

For Terraform solutions for Cloud SQL networking, see Simplified Cloud Networking Configuration Solutions.

Overview

Configuring a Cloud SQL instance to use private IP requires private services access. Private services access lets you create private connections between your VPC network and the underlying Google service producer's VPC network. Google entities that offer services, such as Cloud SQL, are called service producers. Each Google service creates a subnet in which to provision resources. The subnet's IP address range is typically a /24 CIDR block that is chosen by the service and comes from the allocated IP address range.

Private connections make services reachable without going through the internet or using external IP addresses. For this reason, private IP provides lower network latency than public IP.

You use private services access to connect to Cloud SQL instances:

You can connect to private IP addresses across regions. You can also connect using a Shared VPC between projects.

Allocated IP address ranges

To use Cloud SQL instances in a VPC network with private IP, you need to allocate IP address ranges to set up private services access for this VPC. To organize your Cloud SQL instances, you might want to allocate multiple IP address ranges for the private connection. When you configure a Cloud SQL instance for private IP, you could select both the VPC network and the allocated IP address range.

Allocated range size

Please allocate large enough IP ranges for Cloud SQL and other Google managed services you plan to use, each of them would require dedicated IP blocks from the allocated ranges. The minimum size is a single /24 block (256 addresses), but the recommended size is a /16 block (65,536 addresses).

When you allocate an IP address range, you need to take into consideration the number of instances you plan to create.

Subnet mask Addresses Usable Cloud SQL Instances
/2425650
/23512100
/221024200
/212048400
/204096800

Cloud SQL uses /24 CIDR ranges as a range unit, and each unit can only be used for Cloud SQL instances in a single region. For example, if you create two Cloud SQL instances, but for two different regions, then there must be at least two /24 CIDR ranges.

Additionally, if a project started using Cloud SQL before Apr 1 2021, Postgres instances can't share the same range unit with MySQL and SQL Server instances, and need their own in every region. Newer projects aren't subject to this limitation.

Set up private services access for your network

When you configure private IP connectivity for the first time on a specific VPC network, you need to perform a one-time procedure to set up private services access for Cloud SQL.

After you have established private services access, you can create a Cloud SQL instance configured to use private IP or configure private IP for an existing Cloud SQL instance. See Configuring private IP for step-by-step instructions.

Any time you change an established connection, you need to update vpc-peerings as well.

Requirements for Private IP

To use private IP, your network and application environment must meet the following requirements. In addition, setting up private IP for the first time requires extra IAM permissions.

Application environment requirements

  • If you are connecting from GKE, you must be running GKE 1.8 or higher on a VPC-native cluster.

API and IAM requirements

  • You must enable the Service Networking API for your project.

    • If you are using a Shared VPC network, you also need to enable the Service Networking API for the host project.

  • In order to manage a private services access connection, your user must have the following IAM permissions. If the user doesn't have the required permissions you can get insufficient-permissions errors.
    • compute.networks.list
    • compute.addresses.create
    • compute.addresses.list
    • servicenetworking.services.addPeering

    If you're using a Shared VPC network, you also need to add the same user and assign the same permissions on the host project.

Example

In the following example, the customer VPC network allocated the 10.240.0.0/16 address range for Google services and established a private connection that uses the allocated range. Each Google service (for example, Cloud SQL), creates a subnet from the allocated block to provision new resources in a given region, such as Cloud SQL instances.

Diagram overview of private IP configuration.

  • The private connection is assigned the 10.240.0.0/16 allocated range. From this allocation, Google services can create subnets where new resources are provisioned.
  • On the Google services side of the private connection, Google creates a project for the customer. The project is isolated, meaning no other customers share it and the customer is billed for only the resources the customer provisions.
  • Each Google service creates a subnet in which to provision resources. The subnet's IP address range is typically a /24 CIDR block that is chosen by the service and comes from the allocated IP address range. You can't modify the service producer's subnet. A service provisions new resources in existing regional subnets that were previously created by that service. If a subnet is full, the service creates a new subnet in the same region.
  • VM instances in the customer's network can access service resources in any region if the service supports it. Some services might not support cross-region communication. View the relevant service's documentation for more information.
  • Outbound data transfer costs for cross-regional traffic, where a VM instance communicates with resources in a different region, still apply.
  • The Cloud SQL instance is assigned the IP address 10.240.0.2. In the Customer VPC network, requests with a destination of 10.240.0.2 are routed to the private connection over to the service producer's network. After reaching the service network, the service network contains routes that direct the request to the correct resource.
  • Traffic between VPC networks travels internally within Google's network, not through the public internet.

Network issues

Cloud SQL allocates a /24 subnet from the private services access IP range for each region. For example, placing SQL Server instances in two regions requires that the allocated IP address ranges include at least two available subnets of size /24.

Connections to a Cloud SQL instance using a private IP address are automatically authorized for RFC 1918 address ranges. This way, all private clients can access the database without going through the Cloud SQL Auth Proxy.

Cloud SQL doesn't learn Non-RFC 1918 subnet routes from your VPC by default. You need to update the network peering to Cloud SQL to export any Non-RFC 1918 routes.

Security

Traffic over private services access is provided with a certain level of encryption. For more information, see Google Cloud's virtual network encryption and authentication.

The Cloud SQL Auth Proxy can be configured to connect using Private IP and provides authentication using IAM credentials and end to end encryption using a rotating SSL/TLS certificate.

If your security requirements mandate self-managed SSL/TLS certificates that you manage, see the instructions in Configuring SSL/TLS.

Creating one VPC network for each instance with a private IP address provides better network isolation than putting all instances in the "default" VPC network.

Multiple VPC Connectivity

Cloud SQL supports private IP addresses through private service access. When you create a Cloud SQL instance, Cloud SQL creates the instance within its own virtual private cloud (VPC), called the Cloud SQL VPC. Enabling private IP requires setting up a peering connection between the Cloud SQL VPC and your VPC network. This allows resources in your VPC network to access the internal IP addresses of your Cloud SQL resources in the Cloud SQL VPC network.

Using VPC Network Peering, Cloud SQL implements private service access internally, which allows internal IP addresses to connect across two VPC networks regardless of whether they belong to the same project or organization. However, since VPC Network Peering isn't transitive, it only broadcasts routes between the two VPCs that are directly peered. If you have an additional VPC, it won't be able to access your Cloud SQL resources using the connection set up with your original VPC.

To mitigate this limitation and connect your Cloud SQL instance to multiple VPCs using private IP addresses, you can use the following connection options:

  • Connect using custom advertised routes
  • Connect using an intermediate proxy (SOCKS5)
  • Connect using Cloud SQL Auth Proxy as a service

For more information how to connect multiple VPCs, see Connect your instance to multiple VPCs.

Quick reference for Private IP topics

When you manage Cloud SQL instances using private IP, some of the following topics might be of interest:

Topic Discussion
Shared VPC networks You can create Cloud SQL instances with private IP addresses in a Shared VPC network. However, you can't assign a private IP address in a Shared VPC network to an existing Cloud SQL instance.
Regions You can connect through private IP across regions.
Legacy networks You can't connect to the private IP of a Cloud SQL instance from a legacy network. Legacy networks don't support VPC network peering or private services access.
Removing a private IP After you configure a Cloud SQL instance to use private IP, you can't remove the private IP capability from that instance.
Public and private IP You can use both public IP and private IP to connect to the same Cloud SQL instance. Neither connection method affects the other.
Existing Cloud SQL instances You can configure an instance to use private IP at instance creation time. You can also configure an existing instance to use private IP. Configuring an existing instance to use private IP, or changing the network it's connected to, causes the instance to be restarted, resulting in a few minutes of downtime.
Static IP addresses For public and private IP addresses, the incoming address of the Cloud SQL instance is static; it doesn't change. The outgoing address isn't always static, except for outgoing public IP addresses of external server replicas which are always static.
Replicas A replica inherits its private IP status from its primary instance. You can't configure private IP directly on a replica. If you're connecting to a replica using a private IP address, you don't need to create an additional VPC private connection for the replica as it's also inherited from the primary instance.
The Cloud SQL Auth Proxy To connect to a Cloud SQL instance using private IP, the Cloud SQL Auth Proxy must be on a resource with access to the same VPC network as the instance. If the instance has both IP types enabled, the Cloud SQL Auth Proxy defaults to using the public IP. To ensure it's using private IP, you need to pass the -ip_address_types=PRIVATE flag to the Cloud SQL Auth Proxy. Learn more.
Serverless VPC Access To connect from a serverless source, such as App Engine standard environment, Cloud Run, or Cloud Run functions, your application or function connects directly to your instance through Serverless VPC Access without the Cloud SQL Auth Proxy.
VPC Network Peering A connection that uses private services access relies on VPC Network Peering. However, you don't create the VPC Network Peering explicitly, because the peering is internal to Google Cloud. After you create the private services access connection, you can see its underlying VPC Network Peering on the VPC Network Peering page in the Google Cloud console, but don't delete it unless you want to remove the private connection.

Learn more about VPC Network Peering.
VPC Service Controls VPC Service Controls improve your ability to mitigate the risk of data exfiltration. With VPC Service Controls, you create perimeters around the Cloud SQL instance. VPC Service Controls restrict access to resources within the perimeter from the outside. Only clients and resources within the perimeter can interact with one another. For more information, see the Overview of VPC Service Controls. Also review the Cloud SQL limitations when using VPC Service Controls. To use VPC Service Controls with Cloud SQL, see Configuring VPC Service Controls.
Transitive peering Only directly peered networks can communicate. Transitive peering isn't supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 aren't directly connected, VPC network N2 can't communicate with VPC network N3 over VPC Network Peering.

Clients in one project can connect to Cloud SQL instances in multiple projects using Shared VPC networks.
Moving Cloud SQL instances Cloud SQL instances can only be moved between networks owned by the project in which they reside. Additionally, Cloud SQL instances can neither be moved between projects, nor can they be moved between networks hosted by different projects.

What's next