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.


When you configure a Cloud SQL instance to use private IP, you use private services access. Private services access is implemented as a VPC peering connection between your VPC network and the underlying Google services VPC network where your Cloud SQL instance resides. Even though multiple ip ranges can be allocated, the IP range used for the private IP will always be done by Google. IP traffic using private services access is never exposed to the public Internet. Therefore, attack vectors are limited. Also, private IP can provide lower network latency than public IP.

You can use private services access to connect to:

  • Cloud SQL resources with access to a VPC network.

  • Cloud SQL resources from external sources over a VPN tunnel or Cloud Interconnect to your VPC network.

You can connect through private IP from any region. You can also connect through Shared VPCs between projects.

The following diagram shows a Compute Engine instance (VM1) in the same GCP project as the Cloud SQL instances configured with private IP (DB1 and DB2). The IP addresses of the Cloud SQL instances are in the range allocated by the private services access. and peered to the VPC network through the private service connection.

Diagram overview of private IP configuration. Described in text above.

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.

Network requirements

When you create a new VPC network, you need to define an allocated IP address range for the network, and create a private service connection. The address range encompasses the IP addresses of your Cloud SQL instances and cannot overlap with any other ranges in the project's VPC networks.

The allocated IP address range ensures that subnet IP ranges and destinations for custom routes in your VPC network do not overlap with address ranges that the private services access connection uses. You can create an allocated IP range manually if you want to control the CIDR block, or you can have Google Cloud create one for you.

Cloud SQL allocates a /24 subnet from the private services access IP range for each combination of region and database type. For example, placing MySQL instances in two regions requires that the allocated IP address range contain at least two available subnets of size /24, and deploying MySQL and PostgreSQL in two regions requires four available subnets of size /24. SQL Server instances may share the same subnet with MySQL instances in a region.

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 Proxy. Non-RFC 1918 address ranges must be configured as authorized networks.

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.

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 this API for the host project.

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

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


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 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.

Overview of setting 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.

Quick reference for Private IP topics

When you manage Cloud SQL instances using private IP, some of the following topics could 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 cannot 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 cannot connect to the private IP of a Cloud SQL instance from a legacy network. Legacy networks do not support VPC network peering or private services access.
Removing a private IP After you configure a Cloud SQL instance to use private IP, you cannot 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 is connected to, causes the instance to be restarted, resulting in a few minutes of downtime.
Static IP addresses The private IP address of the Cloud SQL instance is static; it does not change.
Replicas A replica inherits its private IP status from its primary instance. You cannot configure private IP directly on a replica.
The Cloud SQL Proxy To connect to a Cloud SQL instance using private IP, the Cloud SQL 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 Proxy will default to using the public IP. To ensure it is using private IP, the user needs to pass the -ip_address_types=PRIVATE flag to the Cloud SQL Proxy. Learn more.
VPC Network Peering A connection that uses private services access relies on a VPC Network Peering. However, you do not 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 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 is not supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 are not directly connected, VPC network N2 cannot communicate with VPC network N3 over VPC Network Peering.

Cloud SQL instances in different Google Cloud projects can connect to each other 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