Ask HN: How do you manage cloud access for your team without a VPN?

1 points by binoycyber ↗ HN
Running a small team and trying to figure out how others handle this.

The two options I keep seeing are VPNs — which work but add meaningful overhead for a 5-25 person team — or security groups with static IP whitelisting, which breaks the moment someone travels or works remotely.

Curious how others have solved this in practice:

- Are you running a VPN? If so, which one and how painful is it to manage? - Static IPs per employee? - Something else entirely?

Context: I'm building in this space and want to understand real-world approaches before assuming my solution is the right one.

3 comments

[ 2.8 ms ] story [ 18.3 ms ] thread
Sso is not an solution?
Static IP whitelisting is a nightmare in practice -- we ran it for about 8 months and the support burden was basically someone's part-time job. Every time someone's hotel or coffee shop rotated IPs, they'd open a ticket. We moved to AWS SSM Session Manager a couple years back and haven't touched a bastion since. No open ports, no SSH keys to rotate, and `aws ssm start-session --target i-xxxxxxx` just works from anywhere as long as they have valid IAM creds. CloudTrail picks up the session automatically, which was a side benefit we hadn't even planned for.

IAM Identity Center (was just called SSO before the rename) with a short session duration -- we do 8-hour max with MFA at login -- handles the traveling employee case cleanly. They re-authenticate, no ticket. Overhead compared to running a VPN server you have to patch is basically zero.

The one thing that bit us: we kept a bastion sitting around "just in case" for way too long before we cleaned it up. It was live for almost a year after we didn't need it anymore. What's the main access pattern you're trying to solve -- DB access, SSH to EC2, or something different?

We are trying to address the Backend applications that are not required to be publicly accessible for everyone except the employees/contractors. Things like internal dashboards, UAT testing environments, etc.

The target audience is the ones who have no AWS credentials but should access an application hosted in one of the CSP-hosted environments.