Remote Developer Access to a Google Cloud VPC: Pick the Path

A developer needs one SSH session, a database port, or broad access to a dozen private services, and every one of those requests looks like the same question. It is not. The destinations, the protocols and the identities involved decide which Google Cloud access path fits, and choosing the widest one by default creates work you did not need to own.

Write down the destinations and protocols

List the private addresses, ports and protocols the work actually needs, then mark which identities must be authenticated separately. A database port and a private DNS zone are different requirements, and a UDP service rules out one of the options below entirely. A written list also shows what you are not granting. That is the part reviewers ask about.

Do this before opening a listener. The list becomes the acceptance test later, and it is the only reliable way to tell a narrow tunnel from a broad one that happens to work.

IAP for a few TCP services

Identity-Aware Proxy TCP forwarding gives an authenticated tunnel to eligible VM resources without exposing the service to the internet. The everyday form is gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, and a single port can be forwarded locally with gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Three things must line up: the caller needs the IAP tunnel accessor role, the firewall must admit the IAP source range, and the destination must be reachable on the instance. Authorization to create the tunnel is not a database credential, an SSH login or an RDP session, so keep the application authentication where it belongs.

IAP TCP forwarding is not a layer-three VPN. It carries TCP to a selected destination, not arbitrary IP traffic or UDP, and it is a poor fit when an application needs private DNS across many services.

A remote-access VPN for broader reachability

When several destinations, protocols or private DNS zones are required, an explicitly managed remote-access VPN on a VM or supported appliance is the better shape. That deployment is separate from Google managed Cloud VPN: you own the client identity enrollment, the software updates, the client routes and the VPC return routes.

Plan the whole list, not just the public listener. Include the tunnel pool, the VPC route back to it, forwarding controls, DNS resolution and per-service access policy. A VPN that connects but cannot resolve internal names fails the developer workflow just as completely as one that never connects.

Cloud VPN is a site gateway, not a laptop profile

Google Cloud VPN connects peer gateways over IPsec, and its FAQ separates that site-to-site role from client-to-gateway access. Creating a tunnel does not produce a profile an employee imports on a laptop. The distinction matters when someone asks for a Cloud VPN profile. The answer is a different product.

What a gateway does well is give the machines behind an office network a route into the VPC. It does not authenticate each employee or grant application permissions, so those policies stay at the network and application layers where they can be enforced per identity.

Verify and record

Test the narrowest destination first, then the one that requires DNS, then a destination that must remain denied. Run each test from the same client that will use the path in production, because a working test from an administrator workstation proves little about a developer laptop with a different network.

Record the chosen model, the destinations it covers, the identities it authenticates and the failure behavior when the path is unavailable. That record is what prevents the next request from silently widening the tunnel instead of adding one destination to a documented design.