Cloud SQL is GCP’s managed relational database service for Postgres, MySQL, and SQL Server. It’s a great service for teams, businesses, or companies that don’t have the operational capacity yet to fully manage their own clusters. However, connecting to a Cloud SQL cluster isn’t the most straightforward thing in the world if you’re aiming for a secure yet still simple approach. Here’s how we did it at PhotoSolve.
The requirements
Our Cloud SQL clusters will be accessed by three different entities:
- Applications running on Compute Engine (VM)
- Applications running on Cloud Run
- Engineers who may need to query data for debugging, analysis, etc.
PhotoSolve is a company that’s still maturing in terms of customers and the team. Our engineering team consists of 5 people where the platform and infrastructure is mostly managed by me and the rest of the team including me is focused on shipping, developing, and iterating the product. This means we need our approach in connecting to our databases need to:
- Be as simple as possible so our team can use it with little to no friction
- Have the least infrastructure provisioned to reduce operational workload and cost
Aside from this, we want to make sure that connections to the database is always from trusted sources over encryption.
At this point, you’re probably thinking:
“This sounds like a job for private IP addresses and a company VPN. What’s the problem?”
We did too. But let’s explore how this works for each of our connecting entities.
First Approach: Private VPC connectivity and Company VPN for engineers
Connecting from a compute engine instance
This is pretty much a no-brainer. If your Cloud SQL cluster authorizes traffic coming from the private network or subnet your compute engine instance is in, all you have to do is set the database host to the cluster’s private IP address. Simple, straightforward, no hassle.