Show HN: lambda-nat-proxy – Serverless proxy using Lambda and UDP NAT punching
github.comRevisited an old experiment of mine (https://github.com/dan-v/awslambdaproxy): can AWS Lambda functions work as network proxies? This time using UDP NAT hole punching + QUIC tunnels.
Client discovers public IP via STUN, writes session data to S3, which triggers a Lambda. Both endpoints punch UDP holes through their NATs, then establish a QUIC connection for encrypted traffic forwarding. Probably gets pretty costly if you’re running a lot of data through it. Now if you could implement a Tailscale DERP server in a lambda that would be pretty amazing: https://tailscale.com/kb/1232/derp-servers I did toy around with Tailscale initially trying to get it to spin up as an exit node but wasn't able to get that functional. I did manage to get Tailscale Funnel to work as the tunnel mechanism to Lambda, but unfortunately the performance was really poor. Alternatively, you could make a Nix flake that can generate an immutable microVM image based on Solo5, running a MirageOS unikernel that implements NAT traversal with UDP hole punching and relay fallback. This image can be deployed to Fly.io as a lightweight, autoscaling Firecracker VM with per-second billing. It boots in milliseconds and costs far less than Lambda. Any reason to use lambda vs this cloud-agnostic approach? Maybe I am missing something. I guess per second vs per 100ms billing, but I can't imagine it ends up being cheaper with Lambda. Absolutely - there are plenty of more cost-effective, cloud-agnostic ways to build something like this. This is just an experiment to explore Lambda networking and push it beyond its intended use cases. Sure, I think it's an awesome effort. Just trying to think of an agnostic approach that's more efficient. I honestly thought this post was satire for at least 30 seconds. I'm not trying to disparage the attempt, just thinking of a way to make it's end goal more agnostic and efficient. Very interesting concept. I’d love some cheap and “throw away” method of setting up tunnels with minimal onus on the exit nodes. Looks cool but how much does it cost? Like most things with AWS, it’s tricky to pin down exactly - and it’ll probably cost more than you’d expect once you factor in Lambda invocations, GB-seconds of execution time, S3 request fees, and especially data‐transfer charges. 10x the original cost it's trying to avoid probably