Cloud SQL Auth Proxy vs a Direct VPN Route to the Database
The Auth Proxy and a direct VPN route solve different halves of the same problem. Compare connector authorization, ports and database login first.
There are two sane ways to reach a private Cloud SQL instance from a laptop on the VPN. One is a direct connection to the instance's private address over the route you already have. The other is the Cloud SQL Auth Proxy, which listens on loopback and opens the connection to Cloud SQL itself. They are less competing products than different answers to who holds the credential and who holds the route. Choosing badly usually surfaces as an authorization error that reads like a network error.
Here is the comparison I would put in front of a team, followed by the checks that actually decide it.
Two paths to the same instance
The direct path uses the private-services-access route from your network into the project's VPC. Your client speaks PostgreSQL to the instance's private address, and the connection lives or dies on routing, firewall rules and database credentials.
The proxy path uses the same route but adds a local process. The proxy authenticates to Google's API with your application default credentials, opens a connection to the instance over the connector, and exposes a loopback port your client treats as PostgreSQL. Two hops become three, and the middle one carries IAM authorization. The VPN route is still yours to maintain, and the proxy never treats it as a substitute for that check.
What each path actually authorizes
The distinction that matters most is what each option can authorize for you:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
The proxy's IAM check and the database login are separate gates, and passing one does not open the other. A team that enables the proxy and assumes the application account is now unnecessary will spend an afternoon on password failures that have nothing to do with networking.
Ports and routes, side by side
The proxy needs outbound TCP 443 for the API and TCP 3307 for the instance connection, both described in Google's Auth Proxy overview. Your VPN route covers the second; the first normally leaves through the ordinary path.
A direct connection needs the instance's PostgreSQL port reachable across the private route, which is a different firewall conversation. If your network team only permits 443 outbound from client subnets, the proxy fits without a rule change and the direct path does not. That single fact decides the choice more often than any architectural preference.
Neither path requires the instance to have a public address, and neither one justifies adding one.
Where the proxy does not help
The proxy does not fix a missing route. If the private-services-access route is absent, or the VPN does not carry it, the connector fails while the local listener still sits there listening, which is the confusing part.
It also does not protect the leg between your application and the proxy. On one laptop that leg is loopback and fine. If you bind the listener to a wildcard address so a colleague can reach it, you have built an unauthenticated database gateway and called it a convenience. Keep it on loopback and let the colleague obtain their own credential.
And it does not make Private Service Connect and private services access interchangeable. A PSC instance needs its own DNS arrangement and the --psc invocation rather than the --private-ip form.
Choosing, then verifying either way
Choose the proxy when you want IAM in the path, short-lived credentials and no inbound firewall change.
Choose the direct route when a supported client already holds strong database credentials and the network team is comfortable opening the port. Either way, verify with a real query rather than a successful connection: connect, run one read against a known table, and check what the server sees for your session.
After a VPN reconnect, treat an expired credential, a missing private route and a database login rejection as three different failures. Only one of them is a networking problem, and only one should ever lead to changing a firewall rule.