What are you using instead of bastion hosts for private AWS access?

A client-based Zero Trust setup can give engineers access to private addresses without exposing SSH to the internet. In the design described here, endpoint clients connect through in-network connectors, while Transit Gateway provides routing between VPCs. Identity policies can limit which private ranges each person can reach, and access can be revoked through the identity layer rather than by changing security group rules.

Test split-tunnel behavior carefully before rollout. Overlapping private address ranges on corporate networks and in VPCs can make route selection messy. I’d also validate the Transit Gateway route tables and propagation across shared accounts in a small environment first, since those details depend on the organization’s setup.

If the access is only to AWS instances, Session Manager is worth evaluating before adding another network access layer. It avoids opening inbound SSH and can use IAM permissions for access control. The catch is fit: teams that need ordinary SSH workflows or have tools that expect direct network access may find it less convenient, and the instance needs to be set up for it.

I wouldn’t treat either choice as automatically better. The deciding questions are what users need to reach, how much of the workflow depends on SSH, and whether you want to manage access through AWS permissions or identity policies for a broader private network.

There’s also a middle ground: keep SSH for the teams that genuinely need it, but tie access to an identity provider and keep the machines private. That can suit workflows where users need machine-level access without giving everyone broad access to whole subnets.

For internal APIs and other non-SSH resources, compare that separately with a network-level access solution. The best fit may differ by resource rather than forcing every team into one access method.