Private, secure, and seamless connectivity to Cloud SQL using Private Service Connect

Private connectivity is critical for organizations to secure data access and meet regulatory requirements — particularly if their applications access an operational database. Traditionally, organizations have relied on VPC Network Peering leveraging private services access, but that can be cumbersome at scale. And for more demanding environments, there’s Private Service Connect, which helps customers simplify and streamline private connectivity at scale, providing enhanced security controls, better IP space management, and flexible network topologies. 

This week at Google Cloud Next, we announced that Private Service Connect is now fully integrated with Cloud SQL, Google Cloud’s fully managed database service for PostgreSQL, MySQL, and SQL Server. With high availability (99.99% SLA), high performance, and rich data-protection capabilities, Cloud SQL is a popular choice for customers that run their business-critical applications on Compute Engine, Google Kubernetes Engine (GKE), Cloud Run, or on-premises. Integration with Private Service Connect makes it easier for these applications to securely connect to Cloud SQL without sacrificing on flexibility, scalability or security. Private Service Connect for Cloud SQL for SQL Server is now generally available, in addition to pre-existing support for MySQL and PostgreSQL.

Benefits of Private Service Connect with Cloud SQL

You can expect to find the following benefits from using Private Service Connect with Cloud SQL:

• Private Service Connect makes it easy to connect to Cloud SQL from multiple consumer VPC networks that belong to different groups, teams, projects, or organizations.

• Private Service Connect makes it easier to manage the IP space since you only need one IP address to access a Cloud SQL instance from the VPC. Because you choose this IP from your VPC, it’s like you access Cloud SQL as if it were a local target.

• Cloud SQL on Private Service Connect allows a single instance to manifest in different VPCs with different endpoints. This makes multi-tenanted deployments (e.g., SaaS applications) easier to manage and more secure.

• Private Service Connect simplifies connecting to primary instances, same-region read replicas, and cross-region read replicas in Cloud SQL.

Configuring Private Service Connect with Cloud SQL

Now let’s look into the details of configuring Private Service Connect with Cloud SQL:

1. Create a Cloud SQL instance

Create a Cloud SQL Instance with Private Service Connect enabled. 

2. Create a Private Service Connect endpoint

Create a Private Service Connect Endpoint within your VPC to connect to Cloud SQL instance. You can choose an IP address for the endpoint from your VPC. While creating the endpoint, use the service attachment URI from the instance created in step #1. You can also allowlist specific projects within the VPC that can connect to Cloud SQL instance via Private Service Connect.

3. Connect to a Cloud SQL instance

Once the Private Service Connect endpoint is created, you are ready to connect to the Cloud SQL instance. You can connect by using an internal IP address, a DNS record, the Cloud SQL Auth Proxy, or the Cloud SQL Language Connectors.

Refer to the documentation for details of all the above steps along with code samples. 

Deployment patterns

Now let’s look at different deployment patterns that Private Service Connect enables for Cloud SQL.

1. Connecting from single VPC to Cloud SQL

If you have all your applications in a single VPC, then you can connect to the Cloud SQL instance using a single Private Service Connect endpoint within that VPC. If it’s a shared VPC, then you can control the list of projects that can connect. For example, let’s say you have both the production project and test project in the same VPC and you want to restrict access to production Cloud SQL instances to only the production project. You can do so by allowlisting only the production project.

2. Connecting from multiple VPCs to Cloud SQL

If you have your applications in multiple VPCs and you want those applications to connect simultaneously to Cloud SQL, it is easy to do so using Private Service Connect. You just need to create a separate Private Service Connect endpoint within each VPC.

3. Connecting to Cloud SQL read replica instances

In Cloud SQL you can create same-region read replicas to scale the read throughput and you can create cross-region read replicas for either disaster recovery or to reduce the read-latency for applications in different regions. It’s easier to connect privately to those read replicas using Private Service Connect. Since each read replica is considered a separate Cloud SQL instance, you need to create a new Private Service Connect endpoint for each read replica and connect to it from your applications.

4. Connecting from on-premises to Cloud SQL and connecting from a different region to Cloud SQL

If an application hosted on-premises wants to connect to a Cloud SQL instance, then you can use Cloud Interconnect or VPN to reach the VPC that has the Private Service Connect endpoint for the Cloud SQL instance. You can also connect from an application in one region to the Private Service Connect endpoint in a different region within the same VPC using Private Service Connect global access.

Benefits of Private Service Connect over Private Service Access

Cloud SQL on Private Service Connect provides better security controls and ease of operations compared to traditional VPC network peering-based connectivity options such as Private Service Access. 

• In Private Service Access, it’s cumbersome to have multiple VPCs simultaneously access a single Cloud SQL instance since you need to use VPN, Cloud Interconnect, or intermediate proxy (SOCKS5). Private Service Connect makes it easier since you can create separate Private Service Connect endpoints within each VPC. 

• Private IP address space is limited and address space management is complex when using Private Service Access since you need to reserve an entire subnet range for Cloud SQL instances in each region. Private Service Connect brings a massive reduction in IP space usage, as you need to reserve only one IP address for each Private Service Connect endpoint that is mapped to the Cloud SQL instance.

• When using Private Service Access, you need to allowlist an entire subnet range beforehand when setting egress firewall rules, which can be overly permissive and an operational burden. With Private Service Connect, you can set granular firewall rules, which is better from a security perspective. 

• When using Private Service Access, VPC Peering quotas can create challenges for deployment at scale. This is not an issue with Private Service Connect, as peering quotas don’t apply.

Conclusion

In conclusion, Private Service Connect with Cloud SQL offers strong security, ease of use, simplicity of operations, and seamless scalability. Click here for documentation on step-by-step instructions of using Private Service Connect with Cloud SQL. Click here to learn more about Cloud SQL.