Honestly, you'd do better scripting the aws cli to update the sec group with your IP address, which is how we've handled WfH for server SSH/plesk/SQL access.

It's like half a dozen lines of bash, I'll see if I've got it on my home pc.

SSM Port Forwarding and Tailscale are your friend. I'm using a mixture of both with most staff WFH now and their home IP addresses not being static.

Tailscale especially is an amazing product though I've only had it running at work and home for around a month. All that said, a simple script as you pointed out is also great :)

What’s fun is when those IPs remain in the rulesets even after they’re no longer used or needed - and the residential DHCP changes and now someone else has a direct line.

Or it points to an AWS IP that eventually gets handed back and recycled …

And that's where you both implement and act on security policies to mitigate and avoid this based on the threat model you're up against.

That's a cool idea! Never dawned on me to do that.

If you’re already ssh-ing to the database, why not tunnel the db connection over ssh?

It would probably be less effort than updating security rules each time

Ssh tunnels are so badass. I’ve heard of people performing encrypted db replication through them between data centers

I’ve witnessed somebody piping dd over an ssh tunnel to write blocks from one machine directly to another. Highly NOT recommended but still one of the neatest things I’ve seen. It worked.

That sort of thing can be used for making disk images. Restoring them would be the only way to verify them as checking the md5sum of the file is not possible without a reference backup and if you have a reference backup why would you be using dd through a pipe lol. Definitely a cool trick though.

Sounds like a neat party trick! (At least, if you've got a really stable connection.) Did they do an md5sum afterward, or how did they know it worked?

Fair question. I used to do that always. But now, if I'm logged into a bunch of services, AWS, mail, etc in the browser, I don't want to switch my IP address to test something for fear of getting bounced or locked out. Especially if I'm in a rush to fix something.

In that case you'd only have a different IP if you hit the localhost port of that tunneled connection, not everything on your computer. Unless you set up your browser and mail to proxy through that port there wouldn't be any issue with "switching IPs".

This isn't what happens - you do a port forward and you access your services through localhost:port. Nothing else goes through the tunnel. Endpoint services see the ec2 ip. There is no IP "switching" or risk of getting banned.

But if your ec2 service has security group access to multiple things it's extremely useful because you can hit localhost:xxxx for postgres, localhost:yyyy for elasticsearch, etc.

This wouldn't be efficient in my case. I'm testing a frontend that's served on localhost:80 and connects to a local backend also on localhost:80 that makes DB calls to some remote database on 3306. I'd have to modify the backend code to connect through the proxy port every time I wanted to test it. As it is the backend code on my computer is a mirror of the production environment. Normally if I tunnel I have it set up to forward everything through the tunnel except localhost.

In this case you'd simply do the tunnel for 3306:3306.

Your frontend and backend code would run locally and connect to MySQL through the proxy. You wouldn't have to change any backend configuration.

Plus this. I use ssh tunneling with private keys to access my Mariadb or MySQL instances.