Do You Still Need a VPN If You Use an Identity-Aware Proxy?

The assumption goes like this: once an identity-aware proxy sits in front of the internal apps, the VPN is decoration and the client can go. That holds for one narrow case, an interactive HTTPS application used by a person in a browser, and it quietly fails everywhere else. A proxy authorizes a request against a resource; a VPN admits a client to a network scope, and the two boundaries rarely line up. Before you retire a tunnel, compare the operations your people actually perform, not the product labels on the diagram.

The two gates authorize different things

An application gate decides whether this request, from this identity, may reach this protected resource. Google's Identity-Aware Proxy overview describes exactly that shape: a central authorization layer in front of HTTPS applications, driven by an IAM role. The boundary is the resource, and the unit of access is the request. A routed VPN does something coarser and broader: it admits a client to a defined network scope, after which the application still decides what that client may do.

Neither model implies the other. Passing the gate says nothing about reading a particular record, and being on the network says nothing about being allowed to act.

What the proxy does not cover, and the VPN does

SSH sessions, database clients, message brokers, and internal hostnames that no browser ever opens do not become reachable because a web proxy exists. Each speaks its own protocol, and each needs either its own authenticated path or a network that carries it. That is the gap people discover on the first day of a migration, usually from an on-call engineer holding a laptop that can no longer resolve a hostname.

The reverse gap is just as real. A VPN that admits a client to a subnet does not authenticate the person inside it, and a compromised device on that subnet inherits whatever the network allows. If the requirement is per-request authorization with an auditable identity, routing alone cannot produce it. Most organizations end up running both, and the interesting question is which resources each one is allowed to front.

Client workflow decides more than the architecture diagram

A browser sign-in with a redirect and an occasional MFA challenge is a fine experience for a person clicking a bookmark. A cron job, a CLI, or a build agent has no browser and cannot answer an interactive prompt, so it needs a documented non-interactive path or it needs the tunnel. Discovery of that requirement usually happens after the design is signed off.

Count the clients before counting the applications. One dashboard can serve a hundred people; one database port can block an entire team.

Device posture is not a property of either gate

A VPN client install is not a compliance check, and a browser-based design is not automatically incapable of honoring managed-device policy. Both can integrate with posture signals, and both can be deployed without them. Ask which enforcement exists, who owns the policy, and what happens to a device that fails it, rather than inferring it from the shape of the product.

The same caution applies to access removal. Deleting a group membership in the proxy and revoking a certificate for the tunnel are different operations with different lag, and one of them usually gets forgotten during offboarding.

Find the alternate paths before you retire anything

An unprotected origin behind the proxy, a second hostname that bypasses it, or a broad private route left over from an earlier design will decide which gate is effectively in force. Test a permitted operation and a denied one through the real client, not through the console, and test them from a device that has never been enrolled. The denied case is the one that tells you whether the gate is doing anything at all.

Then write the handoff: enrollment, updates, access removal, and the recovery path for someone locked out at 2 a.m. Removing a prompt or a client application moves responsibility between teams; it does not delete the responsibility.

If you are deciding this week, start from a list of operations rather than a list of products, mark which ones a browser can perform, and let the remainder justify whatever network access survives.