Vivek V.

for AWS Heroes

Posted on Jun 27 • Originally published at Medium

I Built a Serverless VPN on Lambda MicroVMs — 12 Builds, 5 Dead Ends, 1 Working Architecture

#lambda #microvm #firecracker #aws

TL;DR

I built a personal VPN using AWS Lambda MicroVMs. Your traffic exits from AWS. When you disconnect, the MicroVM terminates — zero cost, nothing running. When you reconnect, a fresh MicroVM launches in about 20 seconds.

./vpn.sh start   # All Mac traffic now exits from AWS
./vpn.sh stop    # Back to your real IP

Here is what I learned across 12 image builds — dead ends, kernel limitations, and what finally worked.

The Idea

Lambda MicroVMs launched in June 2026 (4 days ago). They are Firecracker VMs with:

Full Linux OS — your own binaries, eBPF, iptables, network namespaces
Suspend/resume — state preserved on snapshot, resumes in ~1s per GB (or terminate for zero ongoing cost)
Hardware-level isolation — every session gets its own sandbox
Per-second billing — ~$0.13/hr for a 2GB ARM64 (Graviton) instance
8-hour max lifetime (active + suspended combined)

I wanted to run a VPN inside one. Connect when I need privacy. Disconnect and pay nothing for compute. Resume instantly when I reconnect.

Took 12 image builds to get there.

What I Tried (and Failed)

Attempt 1: NAT Gateway Replacement (The Original Idea)

This is actually where the project started. I was paying $32/mo for a NAT Gateway and thought: what if a MicroVM running nftables could replace it? Serverless NAT. Pay only when traffic flows.

Why it failed: Lambda MicroVMs cannot act as VPC route targets. Their networking is ingress-only (HTTPS + JWT). Other VPC resources cannot route through a MicroVM. The VPC egress connector gives the MicroVM its own internet access. It does not make it a transit device.

That killed the NAT idea. But it made me think — if I cannot route VPC traffic through it, what about routing my own laptop's traffic through it? That is how Serverless VPN was born.

Attempt 2: VPC Egress Connector

I created a VPC, subnets, security groups, and a network connector. One hour wasted.

MicroVMs have INTERNET_EGRESS by default. The connector is only needed for reaching private VPC resources (RDS, internal NLBs). For a VPN that exits to the public internet, default egress works fine.

Attempt 3: Kernel WireGuard

$ ip link add wg0 type wireguard
Error: Unknown device type.

The MicroVM kernel does not have wireguard.ko. Setting additionalOsCapabilities: ["ALL"] does not help. "ALL capabilities" means Linux capabilities (CAP_NET_ADMIN, etc.). Not kernel modules. The Firecracker kernel is compiled by AWS. You cannot load modules.

Attempt 4: Boringtun (Userspace WireGuard)

Failed to initialize tunnel
error: Socket(Os { code: 19, kind: Uncategorized, message: "No such device" })

Even after mknod /dev/net/tun c 10 200, the kernel has no TUN driver. CONFIG_TUN is not compiled in. The device node exists in the filesystem, but nothing in the kernel backs it.

eBPF works because CONFIG_BPF=y is in the kernel. TUN is not. This is a kernel config choice, not a permissions issue.

Attempt 5: Boringtun Daemonize

BoringTun failed to start

Boringtun forks by default. The Firecracker environment blocks fork() in daemon mode. Fix: --foreground flag. But TUN still does not work, so this was moot.

Always use --foreground for any daemon process in MicroVMs.

What Actually Works

veth + SOCKS5 Proxy

Credit to Aidan Steele (AWS Serverless Hero) who pointed me towards veth pairs. He had already built a Kubernetes cluster across MicroVMs — multiple pods per MicroVM, all using veth + network namespaces. No TUN needed.

The kernel supports veth pairs, network namespaces, iptables, and IP forwarding. Just not TUN.

Final architecture:

Mac → wstunnel (WSS) → MicroVM:8080 → microsocks (SOCKS5) → internet (AWS IP)

No TUN. No WireGuard kernel module. No VPC. Just:

wstunnel — WebSocket tunnel. Wraps TCP in WSS for MicroVM ingress.
microsocks — 20KB SOCKS5 proxy. Routes traffic to the internet.
iptables MASQUERADE — NATs traffic out the MicroVM's eth0.
macOS networksetup — Sets system-wide SOCKS proxy.

The 12-Build Journey

Build	What Changed	Result
v1	Kernel WireGuard	❌ Unknown device type
v2–v4	Fixed S3 access, IAM propagation	❌ Access denied → fixed
v5	Added `additionalOsCapabilities: ALL`	✅ ip_forward works
v6	Added boringtun (pre-built binary)	❌ Binary was HTML 404 page
v7	Multi-stage Docker build	❌ Multi-stage FROM not supported
v8	Single-stage Rust compile	✅ Built, but ENODEV on TUN
v9	ALL caps + microvmHooks enabled	✅ /run hook fires
v10	mknod /dev/net/tun + boringtun --foreground	❌ ENODEV (no CONFIG_TUN)
v11	Better error logging	Confirmed: no TUN driver
v12	Filed AWS support ticket	Waiting on CONFIG_TUN
v13	veth + microsocks + wstunnel	✅ Working

Gotchas

1. update-microvm-image Strips Settings

additionalOsCapabilities and hooks are lost when you call update-microvm-image. Always create a fresh image with a new name.

2. API Version Prefixes

Lambda MicroVMs: /2025-09-09/ (service: lambda)
Network Connectors: /2026-04-04/ (service: lambda-core)
Both use the same host: lambda.us-east-1.amazonaws.com

3. boto3 Does Not Have the Service Model

Lambda Python 3.12 runtime ships boto3 that does not know lambda-microvms. Use SigV4-signed raw HTTP or update the CLI.

4. Do Not Setup Networking in /ready Hook

/ready runs during image build. Networking capabilities may not be fully available. Only do filesystem ops. Real networking goes in /run hook.

5. ALL Capabilities ≠ Kernel Modules

additionalOsCapabilities: ["ALL"] grants Linux capabilities. It does NOT:

Load kernel modules
Enable CONFIG_TUN or CONFIG_WIREGUARD

It DOES enable: sysctl, iptables, ip link (veth/bridge), eBPF, network namespaces.

6. Hooks Must Be Set at Image Creation

--hooks '{"microvmHooks":{"run":"ENABLED","runTimeoutInSeconds":60}}'

If you forget this, /run never fires and your VPN never starts.

7. wstunnel Version Compatibility

Server v10.1.0 and client v10.5.5 may crash. Match versions exactly.

8. 8-Hour Max Lifetime

MicroVM terminates after 8 hours (active + suspended combined). Run ./vpn.sh start again when it expires.

9. Token Expiry (60 min max)

Auth tokens expire. The WebSocket connection persists after initial auth, but reconnection needs a fresh token.

The Final Stack

./vpn.sh start
    ↓
aws lambda-microvms run-microvm (image: serverless-vpn-v13)
    ↓
MicroVM launches from snapshot (~20s)
    ↓
/run hook fires:
  - Creates veth pair + network namespace
  - Enables ip_forward
  - iptables MASQUERADE
  - Starts microsocks (SOCKS5 on :1080)
  - Starts wstunnel server (WSS on :8080)
    ↓
wstunnel client on Mac connects via WSS
    ↓
networksetup -setsocksfirewallproxy Wi-Fi 127.0.0.1 1081
    ↓
ALL TCP TRAFFIC → SOCKS5 → WSS → MicroVM → AWS IP

Cost

State	Cost
Connected (browsing)	~$0.13/hr (2GB ARM64 MicroVM)
Disconnected (terminated)	$0 — nothing running, no storage
Each session start	~20s cold start from snapshot
Data transfer out	$0.09/GB (standard AWS egress)
Typical month (2hr/day)	~$8 AWS costs + $5 software
Light usage (1hr/day)	~$5 AWS costs + $5 software

The MicroVM can burst up to 4x baseline (8GB/4vCPU) during peak usage at peak rates.

How to Deploy

Option 1: Subscribe on AWS Marketplace (10 minutes)

The full stack is available on AWS Marketplace with a 7-day free trial. One-click CloudFormation deploy, no servers to manage.

→ Serverless VPN on AWS Marketplace

Option 2: Build It Yourself (under 1 hour)

This blog documents every gotcha I hit. Point Kiro or any AI coding agent at this post plus the Lambda MicroVM Skill and it will scaffold the stack. The gotchas above are what take weeks to discover on your own.

You need:

AWS CLI v2.27+ (brew upgrade awscli — required for lambda-microvms commands)
wstunnel (brew install wstunnel)
AWS account with Lambda MicroVM access (us-east-1, us-east-2, us-west-2, eu-west-1, ap-northeast-1)

Multi-Region

# Run setup once per region (builds the MicroVM image there)
REGION=ap-northeast-1 ./vpn.sh setup  # One-time per region
REGION=ap-northeast-1 ./vpn.sh start  # Tokyo

REGION=eu-west-1 ./vpn.sh setup
REGION=eu-west-1 ./vpn.sh start       # Ireland

Your IP appears from that country. Each region requires a one-time setup (image build is regional). Available in us-east-1, us-east-2, us-west-2, eu-west-1, and ap-northeast-1.

Good to Know

Session VPN, not 24/7 — designed for work sessions, not always-on. Use for privacy during active browsing.
SOCKS5 proxy — routes TCP traffic (web, APIs). Does not tunnel UDP or raw IP (gaming, VoIP) like a full WireGuard VPN.
Runs on Graviton (ARM64) — Amazon Linux 2023 base.
macOS and Linux — Windows supported via WSL2.
Your own instance — dedicated MicroVM in your AWS account. No shared servers. No traffic logging.
CloudTrail auditable — all operations logged in your account.

What's Next

CONFIG_TUN support — I have filed an AWS support ticket requesting TUN/TAP in the Firecracker guest kernel. If AWS adds it, microsocks gets swapped for WireGuard (proper full-tunnel VPN with UDP support).
UDP tunneling — currently SOCKS5 handles TCP only. WireGuard would fix this.
Auto-token refresh — re-auth before 60-min expiry for long sessions.

DEV Community