S4 NAT vs fck-nat: una comparación honesta para reemplazar tu NAT Gateway
Si llegaste a esta página, ya conoces el problema: un NAT Gateway administrado cobra aproximadamente $32/mes por AZ más $0.045 por cada GB que procesa, y en egress-heavy workloads la línea de procesamiento de datos supera rápidamente todo lo demás. Las NAT instances solucionan eso, y fck-nat es el proyecto open-source que volvió a hacerlas respetables.
Empecemos por la parte que una vendor page rara vez dice en voz alta.
Cuándo deberías usar simplemente fck-nat
fck-nat es gratuito, se mantiene activamente (2.2k+ GitHub stars), incluye AMIs arm64/x86 listas para usar en Amazon Linux 2023 y cuenta con módulos sólidos de CDK y Terraform. En una t4g.nano cuesta alrededor de $3/mes y puede empujar varios Gbit/s de burst NAT traffic.
Usa fck-nat cuando:
- El entorno es dev, staging o personal. Si unos minutos de egress downtime son una molestia y no un incidente, la opción gratuita gana.
- El costo es el único criterio. S4 NAT cobra una tarifa de software por hora además de la instance. Nunca le ganará a lo gratuito en precio, y no vamos a fingir lo contrario.
- Te sientes cómodo con community support. El maintainer y la comunidad de fck-nat responden bien, y para configuraciones estándar eso suele ser suficiente.
Dónde S4 NAT justifica su tarifa
S4 NAT es una NAT instance comercial vendida a través de AWS Marketplace: la misma idea que fck-nat (EC2 estándar, kernel nftables, sin per-GB fee), pero con ejecución y garantías diferentes. Las diferencias que importan:
Failover al que puedes ponerle un número. La historia de high-availability de fck-nat es un Auto Scaling Group que reemplaza una instance fallida: recuperación en el orden de minutos. S4 NAT ejecuta un active/standby pair con heartbeat; el standby reescribe tus route tables mediante ec2:ReplaceRoute, normalmente en under 10 seconds. Esto se validó en 170+ failover drills consecutivos con EC2 real a lo largo de varias versiones, con metodología y números publicados en el validation report del repo.
Una egress IP estable durante el failover. Con per-instance addressing (el modelo de fck-nat y el valor por defecto de S4 NAT), tu egress public IP cambia cuando el NAT hace failover, lo cual es un problema si un socio la tiene en allowlist. El modo opcional StableEgressIp de S4 NAT mantiene una shared Elastic IP en el nodo que posee las rutas. En nuestro drill run publicado, un client que muestreaba su egress IP cada segundo vio la shared IP todo el tiempo, con una peor ventana de fallback observada de 2 seconds; además, el fallback va a la EIP propia de la instance en lugar de descartar traffic.
NAT64 integrado. Las IPv6-only subnets pueden llegar al IPv4 internet (RFC 6146, integrated translator). fck-nat no ofrece NAT64.
Un XDP fast path cuando importan los pps. Incluido en la AMI, desactivado por defecto y habilitado con una sola línea de config. Medido en network-optimized instances en aproximadamente 2× the packets-per-second per CPU core frente al standard kernel path.
Compras y responsabilidad. Marketplace billing cae en tu AWS invoice existente (sin nuevo vendor onboarding), y al otro lado hay una empresa con support contact y un validation report publicado. Relacionado, algo incómodo, pero real: varios equipos nos dijeron que no pudieron pasar por security review o por un procurement document una herramienta con “fck” en el nombre. Si esa es tu organización, ninguna lista de funcionalidades importa.
Comparación lado a lado
| fck-nat | S4 NAT | |
|---|---|---|
| Precio | Gratis (solo instance cost) | Tarifa de software por hora + instance |
| Tarifa de procesamiento de datos | Ninguna | Ninguna |
| Failover | ASG replacement (minutos) | Active/standby, <10s (170+ drills) |
| egress IP estable durante failover | No | Modo opcional StableEgressIp |
| NAT64 | No | Sí (RFC 6146) |
| XDP fast path | No | Opcional, ~2x pps/core medido |
| Support | Community | Commercial ([email protected]) |
| Procurement | Self-managed OSS | AWS Marketplace, AWS invoice |
La decisión en cinco minutos
- Dev/staging, o downtime tolerance medida en minutos → fck-nat. Es bueno. Úsalo.
- Production egress donde los socios ponen tu IP en allowlist, el failover debe ser de segundos y no minutos, o necesitas servir IPv6-only subnets → S4 NAT.
- Si no estás seguro → empieza con fck-nat y vuelve a evaluarlo cuando llegue el primer postmortem de “the NAT was down for four minutes” o el primer allowlist rotation ticket.
Ambos productos superan al NAT Gateway administrado en costo para egress-heavy workloads por un orden de magnitud. La diferencia honesta es qué estás comprando además del packet path: comportamiento de failover medido, una egress IP constante y alguien responsable cuando son las 3 a.m.
S4 NAT está disponible en AWS Marketplace. Validation methodology, drill harness y el report completo se incluyen en el product repository.