App Engine Can Reach Your VPN Database: What Must Match

The claim that App Engine Standard cannot reach a private database over Cloud VPN is a leftover from an earlier generation of the platform. Standard instances do not get a VPC-native address the way some other runtimes do, but they can send egress through a Serverless VPC Access connector that lives in your network. Once that path exists, Cloud VPN and the remote firewall see connector traffic like any other source. What fails is rarely the capability itself. It is one of three settings that never got aligned.

Where the old answer came from

Before connectors existed, the practical answer really was that Standard could only talk to public endpoints, and teams moved to a proxy VM or a different runtime to get around it. The platform changed and the folklore did not. A lot of advice online still reflects the era when there was no egress option at all.

The correction is narrower than it sounds. Standard can reach the private network, but only through a supported egress integration, and only for the destinations that integration actually captures.

Pick the egress path first

A connector attached to the service is what puts its traffic into the VPC. The connector documentation lists the regional prerequisite and the egress settings; the connector must exist in the service's region and be usable by the deploying identity.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only sends private destinations into the VPC and leaves everything else on the normal internet path, which is usually what a database connection needs. all-traffic pushes outbound traffic through the VPC broadly, so ordinary internet calls inherit the VPC's NAT and firewall posture too.

Editing the file locally changes nothing until you deploy. A running version keeps the configuration it was created with.

The source address is the connector, not your laptop

This is where most of the debugging time goes. The remote VPN gateway and the database firewall need to admit the connector's allocated range inside the VPC, not your office address and not the service's public egress address. Look that range up in the console before writing a single rule.

Two more places have to agree. The VPC route table needs a route to the remote database network, and the remote side needs a return route for the connector range. If the tunnel uses traffic selectors, confirm that the connector range sits inside the negotiated scope. A route that exists only in the remote-to-local direction is a common miss, and it passes pings while never completing a TCP handshake.

A tunnel that only admits a VM subnet will drop connector packets without a useful error message, which is why the database timeout looks like a credentials problem.

DNS travels a different path

A private database hostname has to resolve inside the network the connector reaches, through Cloud DNS peering or a forwarding zone that the VPC can use. Resolving it on your workstation proves nothing about the deployed service, because your laptop is not using that resolver.

If the name resolves to a public address from inside the VPC, you are about to debug the wrong firewall.

URL Fetch does not use the connector

The egress setting covers the runtime's normal outbound sockets, and the legacy URL Fetch service is not part of that path. A request issued through urlfetch ignores the connector no matter what the configuration says. When the failing call sits inside an older library that still uses URL Fetch, the fix is to move that call onto the standard HTTP client.

For a database driver this is rarely the issue, but it is the classic reason one endpoint works and another does not from the same service.

Verify with one narrow query

Deploy, then run a single permitted database operation from the deployed version while watching the remote side. The source address logged by the database or the VPN gateway should be the connector's. If it is not, the request never entered the VPC and no amount of tunnel configuration will fix it. Compare it against the range you looked up in the console; a mismatch usually means a second connector is serving the version.

A successful query from a VM inside the VPC establishes the route exists. It does not establish that the service chose it.