There are many ways to connect to a Cloud SQL instance with a private IP address, when the source device and the Cloud SQL instance are in the same VPC network. If the source is not in Google Cloud or not in the same Google Cloud project, however, you will have to configure the connectivity differently.
Suppose you have implemented a Hub-and-Spoke network architecture in Google Cloud in order to achieve network-level isolation of resources by deploying the resources in separate VPC networks. To enable the resources in these VPC networks to use shared services (CI/CD tools, centralized configuration management, firewalls) or to ensure centralised access to the cloud from your on-premises network, you can connect each spoke VPC to a central hub VPC as shown below.
In such a network architecture, when you need to reach your Cloud SQL instance with a private IP address from the CI/CD tool to perform DB upgrades and deployments or if your developers need to access the database from their office network for analysis and troubleshooting, VPC peering will not suffice.
Why VPC peering is NOT an option
Google Cloud VPC Network Peering connects two Virtual Private Cloud (VPC) networks that allows resources in each network to communicate with each other: All subnets can communicate using internal IPv4 addresses. Dual-stack subnets will also be able to communicate using internal or external IPv6 addresses.
- Connectivity that uses only internal addresses provides lower latency than connectivity that uses external addresses
- Service owners do not need to have their services exposed to the (public) Internet and the risks associated with it.
VPC peering is point-to-point connectivity, and it does not support transitive routing. For example, if you have a VPC peering connection between VPC A and VPC B and between VPC A and VPC C, an instance in VPC B cannot travel through VPC A to reach VPC C. In order to route packets between VPC B and VPC C, you are required to create a direct VPC peering connection.
Cloud SQL Private IP access is set up through peering between the Google Cloud Project and your project using Private Service Connect.
So, the Cloud SQL instance created in one project cannot be connected to another project privately by way of VPC peering. You must use private services access to connect to the Cloud SQL instances:
- From internal sources with access to your VPC network
- From external sources over a VPN tunnel, a reverse SSH tunnel, or a Cloud Interconnect to your VPC network.
The solution: Cloud VPN
Cloud VPN securely connects your peer network to your Virtual Private Cloud (VPC) network through an IPsec VPN connection. Traffic travelling between the two networks is encrypted by one VPN gateway and then decrypted by the other VPN gateway. This action protects your data as it travels over the Internet. You can also connect two instances of Cloud VPN to each other.
You can connect two VPC networks as long as the primary and secondary subnet IP address ranges in each network do not overlap.
The Cloud VPN resolves the limitations that come with the VPC peering – Transitivity.
Key Points:
- According to Google, the VPN connection between the GCP Projects will not use an external Internet connection. Because it’s between the VPCs, the GCP internal Internet connection is used
- The traffic over VPN connections is encrypted
- Provides up to 99.99% SLA
- Replacing the VPC peering with Cloud VPN involves an additional expense that must be factored in.
