This page provides information about using private IPwith Cloud SQL. For step-by-step instructions for configuring aCloud SQL instance to use private IP,seeConfiguring private IP.

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

Overview

Configuring a Cloud SQL instance to use private IP requiresprivate services access. Private services accesslets you create private connections between yourVPC network andtheunderlying Google Cloud service producer's VPC network. Google Cloud entities thatoffer services, such as Cloud SQL, are calledservice producers.Each Google Cloud service creates a subnet in which to provision resources. Thesubnet's IP address range is typically a /24 CIDR block that is chosen by theservice and comes from the allocated IP address range.

Private connections make services reachable without going through the internetor using external IP addresses. For this reason, private IP provides lowernetwork latency than public IP.

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

• From internal sources with access to your VPC network.

• From external sources over aVPN tunnel,areverse SSH tunnel,or aCloud Interconnect to your VPC network.

You can connect to private IP addresses across regions. You can also connectusing aShared VPC between projects.

Allocated IP address ranges

To use Cloud SQL instances in a VPC network with private IP, you need toallocate IP address ranges to set upprivate services access for this VPC.To organize your Cloud SQL instances, you might want to allocate multiple IP address rangesfor the private connection. When you configure a Cloud SQL instance forprivate 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 otherGoogle Cloud managed services you plan to use, each of them would require dedicated IPblocks 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 youallocate an IP address range, you need to take into consideration thenumber of instances you plan to create.

Subnet mask	Addresses	Usable Cloud SQL Instances
/24	256	50
/23	512	100
/22	1024	200
/21	2048	400
/20	4096	800

Cloud SQL uses /24 CIDR ranges as a range unit, and each unit can only beused for Cloud SQL instances in a single region. For example, if you create twoCloud 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, Postgresinstances 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 thislimitation.

Set up private services access for your network

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

After you have established private services access, you can create aCloud SQL instance configured to use private IP or configure private IPfor an existing Cloud SQL instance. SeeConfiguring private IP for step-by-stepinstructions.

Any time you change an established connection, you need toupdatevpc-peerings as well.

Requirements for Private IP

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

Application environment requirements

• If you are connecting from GKE, you must be runningGKE 1.8 or higher on aVPC-native cluster.

API and IAM requirements

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

If you are using aShared 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 aShared 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 the10.240.0.0/16 address range for Google Cloud services and established a privateconnection that uses the allocated range. Each Google Cloud service (for example,Cloud SQL), creates a subnet from the allocated block to provision newresources in a given region, such as Cloud SQL instances.

• The private connection is assigned the10.240.0.0/16 allocated range. Fromthis allocation, Google Cloud services can create subnets where new resources areprovisioned.
• On the Google Cloud services side of the private connection, Google Cloud creates aproject for the customer. The project is isolated, meaning no other customersshare it and the customer is billed for only the resources the customerprovisions.
• Each Google Cloud service creates a subnet in which to provision resources. Thesubnet's IP address range is typically a/24 CIDR block that is chosen bythe service and comes from the allocated IP address range. You can't modifythe service producer's subnet. A service provisions new resources in existingregional subnets that were previously created by that service. If a subnet isfull, the service creates a new subnet in the same region.
• VM instances in the customer's network can access service resources in anyregion if the service supports it. Some services might not supportcross-region communication. View therelevant service's documentation for more information.
• Outbound data transfer costs forcross-regional traffic, where a VM instance communicates with resources in adifferent region, still apply.
• The Cloud SQL instance is assigned the IP address10.240.0.2. Inthe Customer VPC network, requests with a destination of10.240.0.2 arerouted to the private connection over to the service producer's network. Afterreaching the service network, the service network contains routes that directthe request to the correct resource.
• Traffic between VPC networks travels internally within Google Cloud'snetwork, not through the public internet.

Network issues

Cloud SQL allocates a /24 subnet from the private services access IP rangefor each region. For example, placing PostgreSQL instances in two regionsrequires that the allocated IP address ranges include at least two availablesubnets of size /24.

Connections to a Cloud SQL instance using a private IP address areautomatically authorized forRFC 1918address ranges. This way, all private clients can access the databasewithout going through the Cloud SQL Auth Proxy.

Note: You must configure all the Non-RFC 1918 IP address ranges asauthorized networks of the Cloud SQL for PostgreSQL instances. Alternatively, you can connect to your instance using theCloud SQL Auth Proxy client.

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

Security

Traffic over private services access is provided with a certain levelof encryption. For more information, seeGoogle Cloud's virtual network encryption and authentication.

TheCloud SQL Auth Proxy can be configured to connect using Private IPand provides authentication using IAM credentials and end to end encryptionusing a rotating SSL/TLS certificate.

If your security requirements mandate self-managed SSL/TLS certificates thatyou manage, see the instructions inConfiguring SSL/TLS.

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

Multiple VPC Connectivity

Cloud SQL supports private IP addresses throughprivate service access.When you create a Cloud SQL instance, Cloud SQL creates the instancewithin its own virtual private cloud (VPC), calledthe Cloud SQL VPC. Enabling private IP requiressetting up a peering connectionbetween the Cloud SQL VPC and your VPC network. This allowsresources in your VPC network toaccess the internal IP addresses of your Cloud SQL resources inthe Cloud SQL VPC network.

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

To mitigate this limitation and connect your Cloud SQL instanceto multiple VPCs using private IP addresses, you can use the followingconnection 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, seeConnect your instance to multiple VPCs.

Quick reference for Private IP topics

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

Topic	Discussion
Shared VPC networks	You can create Cloud SQL instances with private IP addresses in aShared VPC network.However, you can't assign a private IP address in a Shared VPC networkto anexisting 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 fromalegacy network.Legacy networks don't support VPC network peering or private servicesaccess.
Removing a private IP	After you configure a Cloud SQL instance to use private IP, youcan'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 thesame Cloud SQL instance. Neither connection method affectsthe other.
Existing Cloud SQL instances	You can configure an instance to use private IP at instance creationtime. You can also configure an existing instance to use private IP.Configuring an existing instance to use private IP, or changing the network it'sconnected to, causes the instance to be restarted, resulting in a few minutesof 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	Areplicainherits its private IP status from its primary instance.You can't configure private IP directly on a replica. If you're connecting to areplica using a private IP address, you don'tneed to create an additional VPC private connection for the replica as it'salso inherited from the primary instance.
The Cloud SQL Auth Proxy	To connect to a Cloud SQL instance using private IP, the Cloud SQL Auth Proxymust be on a resource with access to the same VPC network as theinstance. If the instance has both IP types enabled, the Cloud SQL Auth Proxy defaults tousing the public IP. To ensure it's using private IP, you need to passthe-ip_address_types=PRIVATE flag to the Cloud SQL Auth Proxy.Learn more.
Serverless VPC Access	To connect from a serverless source, such asApp Engine standard environment,Cloud Run,orCloud Run functions,your application or function connects directly to your instance throughServerless VPC Access without the Cloud SQL Auth Proxy.
VPC Network Peering	A connection that uses private services access relies onVPC Network Peering. However, you don't create the VPC Network Peeringexplicitly, because the peering is internal to Google Cloud. After youcreate the private services access connection, you can see its underlyingVPC Network Peering on theVPC Network Peering page in theGoogle Cloud console, but don't delete it unless you want toremove the private connection. Learn moreabout VPC Network Peering. Important: Deleting the underlyingVPC Network Peering for a private services access connection removes privateconnectivity for all resources that are using it and all services it'sconnected to.
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 theOverview of VPC Service Controls. Also review theCloud SQL limitations when using VPC Service Controls. To use VPC Service Controls with Cloud SQL, seeConfiguring 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 bythe project in which they reside. Additionally, Cloud SQL instances canneither be moved between projects, nor can they be moved between networks hostedby different projects.

What's next

• See how toconfigure private IP.
• Learn more aboutprivate services access.
• See how toconfigure private services access for Cloud SQL instances.
• Learn more aboutCloud VPN.
• Learn more aboutVPC networks.
• Learn more aboutVPC Network Peering.
• Learn more aboutShared VPC.
• Learn more aboutCloud SQL Auth Proxy.