Trust the person, not a borrowed IP
An outsourced IT team supported a client whose Windows servers run on Google Cloud. Those servers only trust one whitelisted IP, so staff first signed into an Amazon WorkSpaces desktop that had one, then opened RDP from there — a remote desktop inside a remote desktop. It was secure, but the latency hurt their work all day. TYO Reach replaced the relay with one-click Google Identity-Aware Proxy access.
A whitelisted IP meant routing through a second desktop
The client's Windows servers on Google Cloud only accept RDP from a known, whitelisted IP address — a sensible control. But the outsourced staff who needed to connect don't carry that address on their own networks.
The servers trust one IP, and only that IP
RDP into the client's servers is locked to a single whitelisted address. Anyone connecting from somewhere else is refused — which is exactly the point, right up until the people who need access are somewhere else.
The workaround: an Amazon WorkSpaces relay
To inherit a trusted address, staff signed into an Amazon WorkSpaces desktop that had a static, whitelisted IP, then opened RDP to the client's server from inside that session. The WorkSpaces desktop existed only to hold the right IP.
A remote desktop inside a remote desktop
That stacked two streamed sessions on top of each other — the WorkSpaces desktop, then the RDP session running inside it. Every keystroke and screen redraw paid the latency of both. The staff felt it all day, and it showed in their work.
Throwing bandwidth at it doesn't fix a hop
The slowness wasn't a bandwidth problem — it was an extra machine in the path. More bandwidth can't remove a hop that only exists to borrow an IP address.
Authenticate the people, not a borrowed IP
Both sides already live in Google: the servers are on Google Cloud, and every staffer has a Google Workspace account. That's all you need to remove the relay entirely.
Google Identity-Aware Proxy, direct
Instead of borrowing an IP, each staffer authenticates with their own Google Workspace account. Google's Identity-Aware Proxy (IAP) checks they're allowed and opens a tunnel straight to the server. No whitelisted IP to inherit, no desktop in the middle.
One click in Reach
Staff open the Reach tray, click the machine, and sign in with Google the first time. RDP launches automatically. No gcloud, no tunnel commands, no config files — the kind of thing non-technical staff can actually use every day.
One hop, native RDP
With the WorkSpaces relay gone, there's a single tunnel from the staffer's laptop to the server, running native RDP rather than a desktop streamed inside another desktop. The latency the team felt disappears.
Google enforces access; Reach is never in the path
Google's IAM, MFA, and Context-Aware Access grant and revoke every connection. Traffic goes user to Google IAP to server — it never passes through Reach's servers, so there's no third party in the data path and no Reach data allowance consumed.
Why this is at least as secure as the whitelisted IP
Per-person identity, instant revoke
Access is tied to each staffer's Google identity, not a shared address. Remove one IAM binding and that person loses access immediately, with nothing left on their machine — versus a whitelisted IP that any WorkSpaces session inherited equally.
Least privilege per instance
Scope the IAP tunnel role to a single VM for a contractor rather than the whole project, so access is exactly as broad as it needs to be and no broader.
Audited on both sides
IAP connections appear in the client's Google Cloud audit logs, and Reach can record a per-connection audit trail of its own. Who connected to what, and when, is visible.
Nothing exposed to the internet
No public IP and no bastion host. The RDP port is reachable only from Google's IAP range, only by the identities you name — the port stays invisible to everyone else.
A one-time change, per server
Allow Google IAP to reach the RDP port
Add an ingress firewall rule permitting Google's IAP source range
(35.235.240.0/20) to the server on TCP 3389 (RDP). That range is the only source that
can reach the port.
Grant each staffer the IAP tunnel role
Give each person's Google account (or a Google group) the IAP-secured Tunnel User role
(roles/iap.tunnelResourceAccessor) — scoped to the whole project, or to a single
instance for contractors.
Keep the OS login as it is
IAP controls the tunnel; the server still checks the Windows username and password on login. That's unchanged and separate from the IAP grant.
Add the server as a Reach target
In the Reach dashboard, add a Remote target with backend gcp-iap (project, zone,
instance, port 3389, protocol RDP). It syncs to every staffer's Reach client
automatically.
Not just this one client
Any relay-for-an-IP setup
If your team reaches an IP-locked server by first logging into another machine that holds a trusted address — WorkSpaces, an office PC, a jump box — that machine is very likely the latency you're feeling. Reach removes the need for it.
Cross-org outsourcing on Google
When both the servers (Google Cloud) and the people (Google Workspace) already live in Google, IAP authenticates users directly with no new identity system to run.
Scoped, revocable contractor access
Give external staff access to specific VMs, tied to their own identity, revocable in one step — without a shared VPN credential or a standing whitelisted address.
AWS and Azure servers too
The same one-click approach covers AWS EC2 (via SSM Session Manager or EC2 Instance Connect Endpoint) and Azure VMs (via Bastion). See Connecting to AWS instances and Connecting to Azure VMs.
Case study FAQ
Did this replace Amazon WorkSpaces entirely?
For this access path, yes — staff connect straight to the server through Google IAP instead of routing through a WorkSpaces desktop first. WorkSpaces can still be used for anything else it was serving; it's just no longer the way in to these servers.
Is Google IAP really free?
IAP has no per-use fee. You pay only for the VM and the network egress you already pay for. Reach's one-click client and audit trail sit on top, on a Team plan.
Is this as secure as the whitelisted IP was?
It's more granular. Access is tied to each person's Google identity and enforced by Google's IAM, MFA, and Context-Aware Access, and it's revoked instantly by removing a single IAM binding. A shared whitelisted IP, by contrast, was inherited equally by any session on the relay machine.
Does the traffic go through Reach's servers?
No. The path is user to Google IAP to the server. Reach provides the one-click client and an optional audit trail — it is never in the data path, and the connection isn't counted against any Reach data allowance.
What does the end user actually do?
Install the Reach client, click the machine in the tray, and sign in with Google the first time. RDP opens automatically. Later connects are one click while the Google sign-in is cached. No keys, no CLI, nothing to configure.