smackeyacky

Yeah, so I'm not great at reading documentation I don't think anybody really enjoys reading documentation, most of just want to to "git 'er dun". In that spirit, skipping over paragraphs of florid tech writing and jumping straight to the code snippets is usually enough. Not in this case though TL;DR; Lambdas moved to your VPC must be in a private subnet (i.e. no internet gateway) Lambdas must use a NAT gateway to have internet access Your NAT gateway must be attached to a public subnet i.e. one that has a an internet gateway, not your private subnet where the Lambdas will live Your private subnet must have a default route to the NAT gateway in the public subnet NAT gateways cost money, $40+ / month at the time of writing. Don't forget to fix your security groups and use endpoints if you can for AWS services The overly florid explanation I have been trying for some time to completely nail down public access to my AWS resources but on

No matter where you go, there you are If you're like me, you travel occasionally. Access to your office from home, or from an airport lounge, or from a hotel room is paramount to being productive for most of us now. While I had a fairly simple Tailscale setup that got me into my test machines in the office, what I really wanted was to integrate my AWS production VPC into that system. It's surprisingly simple. Tailscale AWS instructions What do you want to do that for? In the "before tailscale" times, if I needed to test against the production AWS resources or connect dBeaver for database maintenance, I would edit the security group to add my IP address, do my testing, edit the security group to remove myself. This is as error prone as it sounds. I quite often forgot to remove my IP address from the allowed addresses, a major potential security risk when you are travelling. Tailscale has an extremely nifty way to get around it: if you run up a small ec2 ins