🧠 Introducción
En un reciente Architecture Review con un cliente de servicios financieros en LATAM, llegamos al slide de seguridad de red y pasó algo que ya he visto varias veces.
El equipo tenía desplegado AWS Network Firewall en un hub de inspección centralizado. Arquitectura hub-spoke con TGW. Todo correctamente diseñado en papel.
El problema: el cliente tenía requerimientos de compliance que exigían las firmas de amenazas propietarias de su vendor de seguridad — Palo Alto Networks, con el que ya operaban on-premises con Panorama como single pane of glass.
Network Firewall no podía satisfacer ese requerimiento. Habían construido la arquitectura entera sobre el servicio equivocado.
La pregunta que nadie había respondido al inicio del proyecto fue la más simple:
"¿Necesitamos el firewall de AWS o necesitamos nuestro firewall en AWS?"
Esa diferencia lo cambia todo.
🚀 Preámbulo: dos servicios que resuelven problemas distintos
Antes de comparar, es necesario entender que Network Firewall y GWLB no son alternativas equivalentes. Son herramientas que operan en capas diferentes del problema de inspección de tráfico.
AWS Network Firewall es un firewall gestionado nativo. AWS opera el motor de inspección; nosotros operamos las reglas. Stateful, stateless, Suricata-compatible, con IPS/IDS integrado.
AWS Gateway Load Balancer es infraestructura de distribución de tráfico. No inspecciona nada por sí solo. Su trabajo es dirigir tráfico hacia appliances de terceros (Palo Alto VM-Series, Fortinet FortiGate, Check Point CloudGuard) de forma transparente, escalable y con preservación de sesión.
Un dato técnico que pocos conocen: AWS Network Firewall ya usa internamente Gateway Load Balancer para proveer escalabilidad elástica en su propio endpoint. Esto significa que cuando elegimos Network Firewall, estamos usando GWLB — pero con el motor de inspección de AWS incluido y abstraído.
La pregunta real entonces no es "¿cuál es mejor?" sino:
¿Quién opera el motor de inspección y quién controla las firmas de amenazas?
⚙️ Cómo intercepta el tráfico cada uno — la diferencia arquitectónica real
Antes de la decisión, necesitamos entender el mecanismo de intercepción. Son fundamentalmente distintos.
AWS Network Firewall — flujo de tráfico:
VPC spoke
└── TGW (attachment)
└── Inspection VPC
└── Firewall Subnet
└── Network Firewall Endpoint (ENI tipo gateway_load_balancer_endpoint)
└── Motor Suricata (gestionado por AWS)
└── Retorna tráfico inspeccionado
El endpoint de Network Firewall actúa como bump-in-the-wire: el tráfico entra, se inspecciona contra las reglas Suricata/stateful configuradas, y sale hacia su destino. Vemos las reglas y los logs. AWS opera el motor.
GWLB + Appliance de tercero — flujo de tráfico:
VPC spoke
└── TGW (attachment)
└── Security VPC
└── GWLB Endpoint (GWLBE, vía PrivateLink)
└── GWLB (encapsulación GENEVE port 6081)
└── Target Group → Appliance EC2 (Palo Alto / Fortinet / etc.)
└── Inspección + retorno al GWLB
└── GWLB reenvía tráfico a destino
El punto técnico crítico: GWLB usa encapsulación GENEVE para enviar el paquete original intacto al appliance, preservando la 5-tupla original. El appliance inspecciona, toma decisión, y devuelve el paquete al GWLB que lo reenvía al destino. El tráfico es transparente para origen y destino — ninguno sabe que fue inspeccionado.
Esto tiene una implicación operativa importante: el appliance debe soportar GENEVE (port 6081) para integrarse con GWLB. Palo Alto VM-Series, Fortinet FortiGate y Check Point CloudGuard lo soportan. Si el vendor de seguridad de la organización no lo soporta, GWLB no es viable sin cambios en el appliance.
📊 La tabla de decisión — criterios objetivos
Esta es la tabla que debería existir en todo Architecture Review que involucre inspección de tráfico en AWS:
| Criterio | AWS Network Firewall | GWLB + Appliance tercero |
|---|---|---|
| Operación del motor | AWS (managed) | Nosotros (EC2 + licencia vendor) |
| Firmas de amenazas | AWS Managed Rules + Suricata community | Propietarias del vendor (Palo Alto, Fortinet) |
| Single pane of glass con on-prem | ❌ No | ✅ Sí (Panorama, FortiManager) |
| TLS inspection | ✅ Sí (Advanced Inspection, sin cargo extra de data processing desde feb 2026, en 13 regiones) | ✅ Sí (depende del appliance) |
| Escalabilidad | Automática (managed) | Auto Scaling Group manual |
| Costo base (us-east-1, por AZ) | $0.395/hora endpoint + $0.065/GB | $0.014/hora GWLB + $0.004/GLCU-hora + licencia EC2 + vendor |
| Overhead operativo | Bajo | Alto (parches, licencias, HA del appliance) |
| Tiempo hasta producción | Horas | Días/semanas |
| Compliance con requerimientos vendor-specific | ❌ Limitado | ✅ Total |
| Multi-VPC con un solo firewall | ✅ Hasta 50 VPCs por AZ (secondary endpoints) | ✅ Con GWLBE por VPC |
💸 Trade-off de costos — los números que importan
Escenario típico: hub de inspección centralizado, 3 AZs, 10 TB/mes de tráfico inspeccionado
AWS Network Firewall:
Endpoints: 3 AZs × $0.395/hora × 730 horas = $865/mes
Tráfico: 10,000 GB × $0.065/GB = $650/mes
──────────────────────────────────────────────────────
Total mensual aproximado: ~$1,515/mes
GWLB + Palo Alto VM-Series (estimado):
GWLB: 3 AZs × $0.014/hora × 730h = $31/mes
GLCUs: variable según tráfico ~ $50/mes
EC2 (PA): 3× m5.2xlarge (~$0.384/h) ~ $842/mes
Licencia: Palo Alto BYOL o marketplace ~ $500–1,500/mes
──────────────────────────────────────────────────────
Total mensual aproximado: ~$1,400–2,400/mes
Conclusión del análisis de costos: Network Firewall es más predecible y generalmente más barato en arquitecturas medianas. GWLB se justifica cuando el costo de la licencia del vendor ya está amortizado (BYOL desde on-premises) o cuando las capacidades del vendor son un requerimiento no negociable.
Un dato relevante publicado en febrero de 2026: AWS Network Firewall eliminó los cargos adicionales de data processing para Advanced Inspection TLS (vigente en 13 regiones, incluyendo São Paulo) y extendió los descuentos de NAT Gateway encadenado a los secondary endpoints, esta última mejora sin restricción regional. Eso mejora significativamente el TCO de Network Firewall en arquitecturas multi-VPC con inspección TLS activa.
🔧 Patrón 1 — Network Firewall en hub-spoke con TGW
Este es el patrón de referencia para organizaciones AWS-native sin dependencia de vendor externo.
VPC Spoke A ──┐
VPC Spoke B ──┤── TGW ──── Inspection VPC
VPC Spoke C ──┘ └── Firewall Subnet (1 por AZ)
└── Network Firewall Endpoint
└── Suricata Rules + Stateful
Nota de costos: en este patrón el tráfico inter-spoke atraviesa
el TGW dos veces — una hacia la Inspection VPC y otra hacia el spoke
destino. Consideremos ese doble cargo de $0.02/GB en el modelo de costos
para tráfico Este-Oeste de alto volumen.
Cuándo es el patrón correcto:
- Organización AWS-first sin equipos de seguridad que operen vendors externos
- Necesitamos inspección rápida sin overhead operativo de licencias y parches
- Requerimiento de TLS inspection: sin cargo extra de data processing desde feb 2026, en 13 regiones.
- Dev/test environments donde el costo de un appliance no se justifica
- Startups y scale-ups que no tienen on-premises con firewall vendor establecido
Lo que necesitamos configurar en el TGW:
- Route tables separadas: pre-inspection (tráfico entra al firewall) y post-inspection (tráfico sale al destino)
- Appliance mode en el TGW attachment para preservar simetría de flujo
- Network Firewall policy con al menos: stateless rules para tráfico conocido + stateful rules para inspección profunda
Desde noviembre de 2025, Network Firewall soporta flexible cost allocation vía TGW native attachments, permitiendo distribuir los costos de inspección a las cuentas de las aplicaciones según uso real. Para un ambiente multi-cuenta enterprise, esto resuelve el problema de chargeback interno sin soluciones custom.
Esto requiere migrar a TGW native attachment, que reemplaza la Inspection VPC dedicada por una conexión directa del firewall al TGW. Esto no es una capacidad adicional sobre el diseño de arriba, es un patrón de despliegue distinto.
🔧 Patrón 2 — GWLB con appliance de tercero en hub centralizado
Este es el patrón para organizaciones con dependencia de vendor o requerimientos de compliance que Network Firewall no cubre.
VPC Spoke A ──┐
VPC Spoke B ──┤── TGW ──── Security VPC
VPC Spoke C ──┘ └── GWLBE (centralizado por AZ, vía PrivateLink)
└── GWLB (encapsulación GENEVE port 6081)
└── Auto Scaling Group
└── Palo Alto VM-Series
└── Panorama (gestión centralizada)
Cuándo es el patrón correcto:
- Organización con Palo Alto/Fortinet/CheckPoint on-premises y Panorama/FortiManager como consola unificada
- Requerimientos de compliance que exigen firmas propietarias de vendor certificado (PCI-DSS nivel 1, HIPAA con auditorías de vendor específico)
- Necesitamos capacidades que Network Firewall no tiene: sandbox de malware, DLP a nivel de appliance, URL categorization propietaria
- Migración desde on-premises donde el vendor ya tiene contexto de políticas históricas
Consideración operativa crítica: con GWLB somos responsables de la HA del appliance. Necesitamos:
- Auto Scaling Group con health checks configurados para el appliance
- Appliance mode en TGW para simetría de flujo (sin esto, flows bidireccionales pueden ir a instancias distintas y romper inspección stateful)
- Proceso de parches del OS del appliance sin interrumpir tráfico
- Gestión de licencias y renovaciones del vendor
🧠 El árbol de decisión — nivel arquitecto
¿Necesitamos firmas propietarias de un vendor específico?
│
├── SÍ → ¿Ese vendor tiene appliance compatible con GENEVE/GWLB?
│ ├── SÍ → GWLB + Appliance (Palo Alto, Fortinet, CheckPoint)
│ └── NO → Evaluamos Palo Alto Cloud NGFW (marketplace)
│ o rediscutimos el requerimiento con el equipo de seguridad
│
└── NO → ¿Tenemos equipo para operar, parchear y licenciar appliances?
│
├── SÍ → Evaluamos ambas opciones según TCO
│
└── NO → AWS Network Firewall
│
└── ¿Necesitamos TLS inspection?
├── SÍ → Network Firewall + Advanced Inspection
│ (sin cargo extra desde feb 2026, vigente en 13 regiones, incluyendo São Paulo)
└── NO → Network Firewall standard
⚠️ Antipatrones consolidados
❌ "Necesitamos firewall" sin definir qué tipo: la decisión de vendor vs. managed se toma en la semana 1, no en la semana 8 cuando ya está construida la arquitectura.
❌ Network Firewall para reemplazar un vendor con el que ya tenemos contrato y Panorama: vamos a operar dos consolas de seguridad distintas sin ganancia técnica real.
❌ GWLB sin appliance mode en TGW: flows bidireccionales pueden llegar a instancias distintas del appliance. Inspección stateful rota silenciosamente.
❌ Un solo endpoint de Network Firewall para múltiples AZs: si el endpoint falla, el tráfico de esas AZs pierde inspección. Siempre desplegamos un endpoint por AZ en producción.
❌ GWLB en dev/test con appliance de producción: el costo del appliance (EC2 + licencia) en entornos non-prod es difícil de justificar. Network Firewall en dev/test + GWLB en producción es el patrón híbrido más común y más económico.
🔧 Conclusión
La pregunta correcta en un Architecture Review no es:
"¿Usamos Network Firewall o GWLB?"
Es:
"¿Quién controla el motor de inspección y quién gestiona las firmas de amenazas — AWS o nuestro vendor de seguridad?"
Si la respuesta es AWS: Network Firewall es el camino más directo, más predecible en costos y con menor overhead operativo.
Si la respuesta es el vendor de seguridad existente de la organización: GWLB es la infraestructura que permite llevar ese vendor a AWS sin cambiar el modelo operativo de seguridad.
Ambos son correctos. El error es elegir uno sin haber respondido esa pregunta primero.
Happy learning on AWS 🚀
Top comments (0)