This continues the Reach series. Earlier we showed how Reach gets you into a Google Cloud server through Google's Identity-Aware Proxy — no jump box, no public IP, no command line. This post is about doing the same thing across every cloud at once.

Here's the shape of a real small business, as opposed to a tidy diagram: there's a server on Google Cloud, something running on AWS, maybe an Azure box a supplier set up, and — almost always — a server in the office cupboard that never left. Four places, and historically four different ways in. A jump box with a public IP on one. A command-line tool and a tunnel on another. A web portal on the third. And for the one in the cupboard, the old "open a port and hope."

Every one of those is either a standing target on the internet or a support call waiting to happen. Reach's Remote Targets replace the lot with a single idea: a server is just something you pick in the app and click Connect on, and Reach opens the right secure path to it — whichever cloud it's in — gated by who you are.

No jump box per cloud

Each cloud has a proper, identity-based way to reach a server without giving it a public IP — Google has IAP, AWS has its Session Manager and Instance Connect, Azure has Bastion. They're good, and they're also four separate things to learn and run. Reach speaks all of them, so you get the benefit of each cloud's own secure door without your staff ever touching a cloud console or a command line:

  • Google Cloud box → reached through Google IAP.
  • AWS box → reached through AWS's own Session Manager or Instance Connect.
  • Azure box → reached through Azure Bastion.
  • The server in the cupboard → reached through Reach's own secure relay, because no cloud can see it.

Same app, same Connect button, four very different machines. No public IP on any of them. No jump box sitting on the internet for someone to hammer.

Someone sets it up once; everyone else just clicks

The fiddly part — which project, which region, which resource — is set up once, by whoever manages your systems, in the Reach dashboard. From then on your staff see a plain list of servers they're allowed to reach and click Connect. The bookkeeper doesn't install gcloud. The office manager doesn't learn an AWS command. The contractor doesn't get handed a resource ID. The complexity stays with the one person who should own it.

Why identity beats a jump box

A jump box trusts a location — anyone who gets to that address is trusted, and a leaked jump box is a skeleton key to everything behind it. Remote Targets trust a person — the server only accepts a connection that carries a verified identity, and every session is attributable to someone. For a business with staff, contractors and the occasional outsourced admin coming and going, that's the model you actually want: revoking someone is a change to their access, not a rewrite of a firewall rule.

It's worth saying how this sits next to the identity tools you may already pay for. Something like Duo or Practice Protect secures your staff's logins to apps. That's valuable, but it stops at the login screen — it doesn't get anyone safely onto a server. Remote Targets are about exactly that last part: reaching the machine itself, safely, by identity.

One honest note

For the cloud servers, access is still carried under your Google, AWS or Azure identity — which is usually right where a business that standardised on a cloud wants it to stay. The trick of giving a contractor access without adding them to your company directory applies to the servers reached over Reach's own relay (like that one in the cupboard), not the cloud-backed ones. We'd rather tell you that plainly than pretend it's magic.

The short version: IAP for the Google box, AWS's own door for the AWS box, Bastion for the Azure box, Reach for everything else — and one Connect button for all of it. Stop running a jump box in every cloud.

Remote Targets are part of TYO Reach. Start here.