Reach Remote Targets: one client into GCP, AWS and Azure — no cloud SDKseric

Every cloud has solved the same problem in its own way: let a verified person reach a server that has no public IP and no open ports. Google has Identity-Aware Proxy. AWS has Session Manager (SSM) and EC2 Instance Connect Endpoint (EICE). Azure has Bastion. They're all genuinely good, and they all share the same catch at the front end: a different CLI to install, a different login to perform, a different tunnel command to babysit, and a different set of quirks when it goes wrong.

Reach's Remote Targets collapse that. A target is just a named server you click Connect on; behind the scenes Reach opens the right identity-aware tunnel for whichever cloud it lives in — and it does so by speaking each cloud's protocol natively, with no cloud SDK or CLI bundled into the client.

The backends

A target is backed by one of five things, and only the config for that backend is populated:

• gcp-iap — Google IAP. The client opens the IAP TCP tunnel directly to a project / zone / instance / interface / port.
• aws-ssm — AWS Session Manager. Reach runs the Session Manager data channel itself — smux over the Message Gateway Service WebSocket — to reach an instance by ID, in a region, on a port. No session-manager-plugin.
• aws-eice — EC2 Instance Connect Endpoint. A tunnel to an instance_id via an endpoint_id, signed and opened directly.
• azure-bastion — Azure Bastion, reaching a target_resource_id through a named bastion in a resource group and subscription.
• reach-relay — Reach's own relay, for the machines none of the clouds can see: the on-prem server, the box in the office cupboard, a contractor's agreed device.

Each target also carries a proto — rdp, ssh or tcp — and a local port. That's the clean part of the design: once a tunnel is up, it's just a local port, and the launching logic (write the .rdp and open mstsc, open a terminal, or hand you localhost:port for anything else) is identical across every backend. The cloud-specific code stops at "I have a tunnel"; everything above it is shared.

Why hand-rolled, no SDKs

Bundling four cloud SDKs (and their transitive dependency trees) into a desktop tray is how you end up with a 200 MB binary that takes a security review a month to approve. Each of these tunnels is, underneath, a reasonably small protocol: a signed request, a WebSocket or a TCP channel, and a framing layer. Reach implements them directly in Go — the AWS SigV4 signing, the SSM smux framing, the IAP tunnel handshake — so the client stays small, auditable, and free of the cloud vendors' own CLI update treadmill. It also means one connection UX and one audit trail across all of them, rather than four tools each logging somewhere different.

Dashboard-managed, so staff don't touch any of this

Targets are synced from the dashboard — GET /api/reach/targets returns the set, versioned, and the client just renders it. An admin defines "Accounts DB (prod)" once, with its backend and config; everyone who's entitled to it sees a server they can click Connect on. Nobody on staff installs gcloud, learns an aws ssm start-session incantation, or pastes a resource ID. The messy per-cloud config lives in one place, managed by the person who should manage it.

The honest notes

• Cloud-native targets use that cloud's identity. An IAP-backed or SSM-backed connection is still authorised by your Google / AWS / Azure identity — which is usually exactly what a shop already standardised on that cloud wants. The "give a contractor access without adding them to your directory" trick applies to reach-relay targets, not the cloud-native ones. Reach is honest about which is which.
• Each backend needs its IAM set up. Reach carries the connection; it doesn't grant the permission. The GCP instance still needs its firewall open to the IAP range and the user bound to the right role; the AWS instance needs the SSM agent and an instance profile; and so on. A subtle one worth knowing on GCP: resource.name IAM conditions do not gate IAP TCP tunnels — you have to gate on destination.ip/destination.port, or the tunnel authorises when you didn't expect it to.
• It's for your servers. Targets are destinations an admin has deliberately provisioned. This is zero-trust access to a managed fleet, not ad-hoc discovery of random hosts.

The pitch is the same one each cloud makes for its own proxy — reach a server with no public IP, gated by identity — but told once, across all of them, from a client that a non-engineer can actually use. IAP for the Google box, SSM or EICE for the AWS box, Bastion for the Azure box, Reach's relay for everything else — and the same Connect button for all four.

Remote Targets are part of TYO Reach. Start here.