Self-hosting a NAT Gateway

Original Article ↗ Hacker News Discussion ↗

Cost and AWS NAT Gateway vs self-hosted

  • Many argue AWS NAT Gateway is “ridiculously expensive,” especially per‑GB traffic, compared to running a small EC2 NAT instance (iptables/nftables, Debian, OpenWrt, OPNsense, fck‑nat, etc.).
  • Some note AWS’ official NAT AMIs are based on very old Amazon Linux; others confirm the same configuration works fine on modern distros like Debian or Rocky Linux.
  • One claim: attaching an Elastic IP to a NAT instance causes hairpinning through AWS public infrastructure and adds regional data transfer charges; others are skeptical and ask for documentation.

Operational tradeoffs & business context

  • Pro‑cloud side: managed NAT is “set and forget,” publishes metrics, and avoids hiring specialists or owning lifecycle/patching, PCI, and hardware retirement. For many businesses, saving engineering focus and launching faster is worth higher recurring cost.
  • Pro‑self‑hosting side: for high‑traffic workloads, the per‑GB savings are “massive,” turning a big variable cost into a small fixed one. Some emphasize that basic Linux networking is easy enough that paying AWS premiums feels wasteful.

NAT, firewalls, and security misconceptions

  • Multiple comments stress: NAT is not a firewall. The protection comes from stateful filtering, not address translation. You can have NAT without real isolation and firewalls without NAT.
  • Concern that conflating NAT with security has made people afraid of IPv6, thinking RFC1918 space is “safe” by itself. Others reply that typical home routers already behave as stateful firewalls for both v4 and v6.

IPv6 vs IPv4 and “do away with NAT”

  • Some want NAT gone entirely, arguing IPv6 + firewalls (or AWS egress‑only IPv6 gateways) can eliminate NAT fees and hacks like port forwarding and split‑horizon DNS.
  • Others counter: IPv4 is still dominant, many AWS services and external platforms lack full IPv6 support, and ISP practices (dynamic prefixes, limited /64s, even IPv6‑behind‑NAT) complicate pure‑IPv6 designs.
  • Aesthetic/usability objections to IPv6 syntax come up; several replies note that humans should be using DNS anyway.

Skills, culture, and AI

  • One thread laments that modern developers avoid networking/sysadmin as “hard,” relying on managed services instead, and worries about long‑term expertise.
  • Others respond that specialization is rational; devs can and do choose not to learn low‑level Linux/networking, and AI tools may both lower the bar for self‑hosting and filter out less capable practitioners.

Alternative setups & tips

  • Suggestions include: DIY EC2 NAT instances with IP forwarding and iptables; turning off source/dest check; avoiding EIPs unless needed; using VPS + SSH/OpenVPN tunnels with Nginx; or using Tailscale/headscale.
  • One commenter warns that simple NAT recipes don’t address kernel hardening (ICMP redirects, source routing, rp_filter, syncookies, etc.) and recommends security review before production use.