Google IAP vs a bastion host
A bastion host is a hardened VM with a public IP that you SSH or RDP into first, then hop from to everything else. IAP TCP forwarding does the "first hop" as a Google-managed service gated by identity. For most Google Cloud estates IAP is the better default; this page sets out why, and the handful of cases where a bastion still earns its keep.
1. Side by side
| Bastion host | IAP TCP forwarding | |
|---|---|---|
| Exposed surface | A public IP with port 22/3389 open to the internet (or to an allowlist) | No public IP anywhere; only IAP's 35.235.240.0/20 may reach the port |
| Who is allowed in | Whoever has a key/password on the bastion, plus firewall allowlists | IAM identities with roles/iap.tunnelResourceAccessor, optionally per instance / per port / per access level |
| Revoking a leaver | Remove keys from the bastion and every target; rotate shared secrets | Remove one IAM binding (or one group membership) |
| MFA | Whatever you bolt on (PAM modules, Duo…) | Google sign-in with your Workspace MFA policy |
| Patching and hardening | Yours — OS updates, sshd config, fail2ban, monitoring | Google's — there is no VM to patch |
| Audit | sshd logs on the bastion, if you ship them somewhere | Cloud Audit Logs with principal, caller IP and granted/denied |
| Cost | The bastion VM (24×7), its disk, its public IP, and the time to run it | No charge for IAP; egress you'd pay anyway |
| Bulk transfers | Fine — it's a full VM | Not intended for bulk data; may be rate-limited |
| Idle behaviour | Session lasts as long as you like | Disconnected after one hour idle |
| Latency | Two hops (you → bastion → target), each a full SSH/RDP session if you nest desktops | One tunnel to the target VM |
2. Where IAP wins
Attack surface. The most common bastion failure is the boring one — an old sshd, a leaked key, a too-wide allowlist. With IAP the port is never reachable from the internet, so brute-force traffic simply doesn't arrive.
Offboarding. On a bastion, access is a pile of authorized_keys files and shared passwords. With IAP it's an IAM binding; put people in a Google Group and offboarding is a group removal.
Operations. A bastion is a production server you must patch, monitor and back up forever. IAP is a checkbox in a firewall rule plus a role.
Latency for interactive work. Teams often reach IP-locked servers by first opening a desktop inside another desktop. Removing that hop is the difference the staff notice daily — see the case study of an outsourced IT team that replaced an Amazon WorkSpaces relay with IAP.
3. Where a bastion still makes sense
- Bulk data movement. IAP TCP forwarding "isn't intended for bulk transfer of data". If the jump host is really a file-transfer box, keep it — or use Cloud Storage.
- Non-Google identities with no federation. IAP needs a Google Account, Workforce Identity Federation or Identity Platform identity. If you can't federate a partner's users, a bastion with its own auth may be simpler.
- Protocols that misbehave over a per-port tunnel. Anything that opens dynamic secondary connections is easier from a host inside the VPC.
- Long-running unattended sessions. IAP's one-hour idle timeout is fine for humans with keep-alives, awkward for a fire-and-forget job — run it under tmux on the target instead.
- Tooling that expects a jump host (some legacy runbooks, some appliance vendors).
Even then, put the bastion itself behind IAP and drop its public IP: you keep the staging box but lose the exposed port.
4. The hybrid most teams end up with
- Every VM: no external IP; firewall allows
35.235.240.0/20on 22/3389 only. - Admins:
roles/iap.tunnelResourceAccessorproject-wide via a group; OS Login withosAdminLogin. - Contractors: the role per instance, ideally with a
destination.portcondition. - A single hardened "tools" VM, reachable only through IAP, for the rare bulk job.
Common questions
Is IAP more secure than a bastion with a strict IP allowlist?
The allowlist protects the port from strangers; IAP protects it from everyone except named identities, and logs each attempt. An allowlisted IP is also shared by everyone behind it, which is exactly the weakness a per-identity model removes.
Does IAP cost more than running a bastion?
No — IAP for Google Cloud-hosted resources has no charge, while a bastion is a VM you pay for around the clock plus the engineering time to keep it hardened.
Can I keep my existing SSH keys?
Yes. IAP gates the tunnel; the OS login is unchanged unless you switch to OS Login.
What about AWS and Azure?
The equivalents are AWS Systems Manager Session Manager / EC2 Instance Connect Endpoint and Azure Bastion — see Connecting to AWS instances and Connecting to Azure VMs.