Introducción
Los equipos de seguridad y DevOps que utilizan AWS Network Firewall enfrentaban un desafío: el forward proxy, introducido en noviembre de 2025 como producto independiente, requería una política de seguridad separada. Esto complicaba la gestión centralizada, obligando a mantener reglas duplicadas para el firewall transparente y el proxy explícito. Ahora, AWS resuelve este problema al reintegrar el forward proxy como una funcionalidad nativa de Network Firewall, unificando las políticas y simplificando la administración.
La cambio permite usar una única política de seguridad para ambas modalidades (transparent firewall y forward proxy), reduciendo la complejidad operativa y mejorando la coherencia en los controles de seguridad. Esta evolución es especialmente relevante para entornos con Amazon EKS y Amazon ECS, donde el filtrado basado en atributos de contenedores ya estaba disponible para el firewall transparente y ahora se extiende al proxy.
Qué ocurrió
AWS anunció la disponibilidad en public preview del forward proxy como funcionalidad integrada en AWS Network Firewall. La novedad clave es que ahora puede configurarse usando la misma política de seguridad existente, sin necesidad de mantener una política separada como ocurría en la versión inicial del producto.
La implementación se realiza en un nuevo modo de despliegue llamado no-source-preservation, donde el firewall actúa como proxy explícito. Este modo es incompatible con el source-preservation (usado en firewall transparente), pero permite aprovechar todas las capacidades existentes de Network Firewall, incluyendo:
- Grupos de reglas gestionados (managed rule groups)
- Defensa activa contra amenazas (active threat defense)
- Filtrado por Geo-IP
- Filtrado de URLs y categorías de dominios
- Reglas basadas en atributos de contenedores para EKS y ECS
La preview está disponible inicialmente en la región US East (Ohio) y no tiene costo adicional durante esta fase.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de Seguridad, cette cambio reduce la fragmentación de políticas, permitiendo aplicar controles consistentes para el tráfico saliente (proxy) y el tráfico que pasa a través del VPC (firewall transparente). Esto es crítico para estrategias de zero trust, donde cada flujo de datos debe ser inspeccionado, independientemente de su origen o destino.
Los equipos de DevOps e Infraestructura se benefician de una simplificación operativa. Ya no es necesario mantener dos instancias de Network Firewall (una para firewall transparente y otra para proxy) ni sincronizar reglas entre ellas. Además, la integración con atributos de contenedores facilita el filtrado granular en entornos de Kubernetes (EKS) y contenedores (ECS). Por ejemplo, pueden aplicarse reglas específicas para pods con etiquetas como environment=production o team=backend.
En el plano Cloud, esta funcionalidad es útil para arquitecturas que requieren:
- Control centralizado del tráfico saliente hacia internet (evitando el egress filtering distribuido en NAT gateways)
- Inspección de tráfico hacia servicios externos (Saas, APIs de terceros)
- Prevención de exfiltración de datos y inyección de malware en conexiones salientes
El impacto en la latencia es mínimo (AWS no proporciona cifras exactas en el anuncio), pero debe evaluarse en entornos con requisitos estrictos de performance, especialmente si se habilitan inspections profundas (como TLS).
Detalles técnicos
Modo no-source-preservation
El forward proxy se implementa en un nuevo modo de despliegue llamado no-source-preservation. En este modo:
- El firewall modifica la IP de origen del tráfico saliente, reemplazándola por la IP de la interfaz del firewall.
- El tráfico de retorno va al firewall, que lo reenvía al cliente original (comportamiento típico de un proxy).
- No es compatible con el modo source-preservation (usado en firewall transparente), ya que este último preserva la IP original.
Configuración de la política
La política de seguridad puede usarse para ambas funcionalidades (firewall transparente y forward proxy). Incluye:
- Stateful rule groups: Reglas basadas en IP, puerto, protocolo y estado de la conexión.
- Stateless rule groups: Reglas basadas en IP y puerto (sin tracking de estado).
- Managed rule groups: Reglas predefinidas para threats comunes (ej:
AWS managed rules common rule setv2). - Active threat defense: Listas de bloqueo generadas por AWS para dominios y IPs maliciosos (actualizadas automáticamente).
- Geo-IP filtering: Bloqueo o permisos basados en país de origen/destino.
- URL and domain category filtering: Control de acceso a categorías como «social media», «gambling», etc. (usando las listas de AWS).
- Container attribute-based rules: Reglas que coinciden con atributes de contenedores en EKS/ECS (ej:
kubernetes.namespace=default,ecs.cluster=my-cluster).
Despliegue
Para habilitar el forward proxy, se crea un nuevo Firewall Endpoint con el modo no-source-preservation y se asocia a la misma política usada para el firewall transparente. Ejemplo usando AWS CLI:
# Crear el firewall endpoint en modo no-source-preservation
aws network-firewall create-firewall \
--firewall-name my-forward-proxy \
--firewall-policy-arn arn:aws:network-firewall:us-east-2:123456789012:firewall-policy/my-policy \
--vpc-id vpc-12345678 \
--subnet-mapping SubnetId=subnet-12345678,SubnetId=subnet-87654321 \
--firewall-policy-change-protection-disabled
# Asociar el endpoint a un route (ej: para redirigir tráfico saliente)
aws ec2 create-route \
--route-table-id rtb-12345678 \
--destination-cidr-block 0.0.0.0/0 \
--vpc-endpoint-id vpce-12345678Limitaciones en la preview
- Disponible solo en US East (Ohio).
- No soporta TLS inspection (el tráfico HTTPS se inspecta solo como clear text después del handshake).
- El tamaño máximo de la política es de 10,000 rules (límite existente para Network Firewall).
- No compatible con VPC Endpoint Policies (para acceder a servicios AWS privados).
Qué deberían hacer los administradores y equipos técnicos
- Evaluar la unificación de políticas:
– Consolidar reglas duplicadas entre el firewall transparente y el proxy independiente (si lo estaban usando).
- Probar en entorno no productivo:
– Configurar un route que redirija el tráfico saliente de un subnet de prueba al firewall.
– Validar que:
– El tráfico HTTP/S es inspeccionado correctamente.
– Las reglas basadas en dominios, Geo-IP y atributos de contenedores funcionan como se espera.
– Las aplicaciones cliente manejan correctamente la respuesta del proxy (sin depender de la IP original).
- Planificar la migración:
# Crear nuevo firewall endpoint con la política unificada
aws network-firewall create-firewall --firewall-name new-forward-proxy --firewall-policy-arn arn:aws:network-firewall:us-east-2:123456789012:firewall-policy/unified-policy ...
# Actualizar routes para apuntar al nuevo endpoint
aws ec2 replace-route --route-table-id rtb-12345678 --destination-cidr-block 0.0.0.0/0 --vpc-endpoint-id vpce-new12345678
# Eliminar el firewall standalone (tras validación)
aws network-firewall delete-firewall --firewall-arn arn:aws:network-firewall:us-east-2:123456789012:firewall/old-forward-proxy
– Si usaban NAT gateways para filtrado saliente, evaluar reemplazarlo con el forward proxy para centralizar la seguridad.
- Monitorear y ajustar:
Flow Full Alerts para registrar todos los flujos).– Revisar las métricas de AWS Network Firewall en CloudWatch (ej: DropCount, AlertCount) para detectar bloqueos no esperados.
– Ajustar las reglas según el tráfico real (usar managed rule groups para threats comunes).
- Considerar limitaciones:
– Para regiones distintas a US East (Ohio), esperar la disponibilidad general.
Conclusión
La reintegración del forward proxy en AWS Network Firewall es un paso importante hacia la simplificación de la seguridad de red en AWS. Al unificar las políticas para firewall transparente y proxy explícito, AWS addressa un punto de fricción que afectaba a equipos que buscaban controles centralizados. La funcionalidad es especialmente valiosa para entornos con EKS/ECS, donde el filtrado basado en atributos de contenedores ahora se aplica de manera consistente a todo el tráfico.
Aunque la preview tiene limitaciones (región única, sin TLS inspection), la propuesto de valor es clara: menos complejidad operativa y mayor coherencia en los controles de seguridad. Los equipos deberían evaluar la funcionalidad en entornos de prueba y planificar la migración si su casode uso se beneficia de esta unificación.
Fuentes
- https://aws.amazon.com/about-aws/whats-new/2026/08/aws-network-firewall-forward-proxy-preview/