DEV Community

Cover image for Cómo implementar AWS Network Firewall en una arquitectura multicuenta utilizando Transit Gateway
Cristhian Becerra
Cristhian Becerra

Posted on • Edited on

Cómo implementar AWS Network Firewall en una arquitectura multicuenta utilizando Transit Gateway

#spanish #aws #networking #cybersecurity

TL;DR: Este artículo te guiará en la implementación de AWS Network Firewall dentro de una arquitectura multicuenta de alta disponibilidad, que abarca tres zonas de disponibilidad, en conjunto con un Transit Gateway para conectar VPCs a través de diferentes cuentas dentro de una estructura de AWS Organizations. La arquitectura sigue un patrón Hub & Spoke, donde la cuenta Hub corresponde a la cuenta de Networking y las cuentas Spoke incluyen los entornos de Desarrollo, QA, Producción y DevOps. 🛡️

Tabla de Contenidos:

Introducción

Cuando en el trabajo me tocó implementar por primera vez AWS Network Firewall, honestamente tenía un poco de temor; pensaba que sería más complejo. Sin embargo, la implementación resulta relativamente sencilla si uno se maneja bien con redes y enrutamiento.

Aun así, mis primeras configuraciones de red para implementar Network Firewall no fueron las mejores ni las más ordenadas, pero eventualmente lo logré: una implementación correcta y organizada de AWS Network Firewall, alineada con las mejores prácticas recomendadas por AWS. 🥳

Y, sinceramente, me gustaría que otros pudieran evitar esos errores al intentar configurar AWS Network Firewall por primera vez, especialmente en lo que respecta al enrutamiento, que para mí fue la parte más compleja, y que así pierdan el temor al servicio y a las redes. Por ello estoy escribiendo este artículo: para compartir cómo debería configurarse correctamente la red y el enrutamiento, o, al menos, la manera en que yo lo hice.

Para dar un poco de contexto, en un entorno multicuenta, AWS Network Firewall cumple un rol importante al proporcionar protección de red centralizada, permitiendo controles de seguridad consistentes e inspección de tráfico a través de todas las cuentas.

Esta implementación adopta un modelo de ingreso centralizado, egreso centralizado e inspección centralizada, asegurando que el tráfico entrante, saliente y entre VPCs sea enrutado de forma segura a través de una única capa de inspección gestionada por la cuenta de Networking.

Por qué implementar AWS Network Firewall

Probablemente ya conozcas varios tipos de firewalls en AWS, como los Grupos de Seguridad (SG), las Listas de Control de Acceso de Red (NACL) y el Firewall de Aplicaciones Web (WAF), y te estés preguntando: ¿por qué necesito otro servicio de firewall más?

Bueno, AWS Network Firewall es un servicio más robusto que surge para resolver un caso de uso distinto. Empecemos por aclarar que AWS WAF solo puede implementarse en servicios específicos de AWS como ALB, API Gateway y CloudFront, pero no de forma abierta en cualquier Elastic Network Interface (ENI).

Por otro lado, los grupos de seguridad y las Network ACLs existen de manera independiente en cada VPC, cada uno con sus propias reglas de seguridad descentralizadas, lo cual puede volverse complicado de gestionar con el tiempo.

Imagina que tienes múltiples VPCs o incluso varias cuentas de AWS, y en todas necesitas aplicar las mismas reglas de firewall, tanto stateless como stateful. No tendría mucho sentido implementar una y otra vez los mismos SG, NACL y WAF en cada VPC o cuenta, ¿cierto? Y aunque lo hicieras, mantener y administrar esas configuraciones sería un caos. 😵

Además, tanto los SG como las NACLs tienen un límite relativamente pequeño en la cantidad de reglas que soportan, y como mencionamos antes, WAF solo funciona con ciertos servicios. Entonces, ¿cómo resolvemos esto?

Aquí es donde entra AWS Network Firewall. Este servicio permite desplegar un firewall en forma de servicio virtual, con sus propias ENIs, hacia las cuales podemos enrutar todo el tráfico entrante y saliente para que sea inspeccionado antes de llegar a su destino final. De este modo, obtenemos todos los beneficios de los firewalls stateless y stateful, desde la capa 3 hasta la capa 7. 🤩

Y si bien como alternativa podrías desplegar tu propio appliance de seguridad —o uno de terceros— detrás de un Gateway Load Balancer para realizar la inspección, la diferencia es que, en ese caso, tú serías responsable de gestionarlo completamente, mientras que AWS Network Firewall es un servicio totalmente gestionado por AWS y ofrece muchas funcionalidades interesantes.

En resumen, los grupos de seguridad y las NACLs pueden ser suficientes a pequeña escala, con un par de VPCs, pero a medida que creces y comienzas a manejar múltiples VPCs y cuentas AWS, querrás —o incluso necesitarás— centralizar la inspección de red. Y es precisamente por eso que deberías aprender a implementar AWS Network Firewall.

Aquí te dejo una tabla comparativa entre los distintos tipos de firewalls en AWS, para que puedas entender mejor las diferencias entre ellos.

Security Group Network ACL WAF AWS Network Firewall
Protección en Nivel de instancia EC2 Nivel de subred Nivel de endpoint (ALB, CloudFront, etc.) Nivel de VPC, basado en rutas
Con estado o sin estado Con estado Sin estado Sin estado Ambos
Capa OSI Capa 3/4 Capa 3/4 Capa 7 Capas 3–7
Características Filtrado por IP, puerto y protocolo Filtrado por IP, puerto y protocolo Filtrado a nivel de aplicación Reglas sin estado/ACL de Capa 3, reglas con estado de Capa 4, IPS/IDS en Capa 7, filtrado FQDN, detección de protocolo, listas grandes de IP permitidas/bloqueadas
Flujos Todo el tráfico de entrada/salida a nivel de instancia Todo el tráfico de entrada/salida a nivel de subred Solo tráfico de entrada desde internet hacia API Gateway, ALB o CloudFront Todo el tráfico de entrada/salida en el perímetro de la VPC (por ejemplo, IGW, VGW, DX, VPN, VPC–VPC)

Qué vas a construir

Como mencioné antes, la implementación no es particularmente complicada, pero sí requiere una buena base en redes y enrutamiento. Cuando esta guía dice “Crea un Transit Gateway”, se asume que ya sabes cómo hacerlo. Y si bien esta guía no incluye infraestructura como código lista para desplegar, sí ofrece un listado paso a paso adecuado para este nivel. Lo más importante es que incluye la configuración de enrutamiento, que en mi experiencia es la parte más complicada. 😉

Esta implementación consta de cinco componentes que vas a construir:

  • AWS Transit Gateway compartido mediante AWS RAM y conectado a todas las VPC.
  • VPC de ingreso con Internet Gateway para la conectividad de entrada centralizada.
  • VPC de inspección con AWS Network Firewall desplegado en alta disponibilidad, usando el tipo de attachment VPC o TGW para la inspección centralizada.
  • VPC de egreso con NAT Gateways en alta disponibilidad para la conectividad de salida centralizada.
  • VPCs de carga de trabajo para los entornos de Desarrollo, QA, Producción y DevOps.

No te preocupes si por ahora aún no puedes visualizar la solución completa. En la sección de pasos de implementación encontrarás diagramas de arquitectura para cada uno de estos cinco componentes, además del diagrama final de la solución completa.

Prerrequisitos

Para esta implementación, se recomienda contar con múltiples cuentas de AWS y con los permisos adecuados en cada una de ellas.

Si aún no dispones de múltiples cuentas, puedes crearlas mediante AWS Organizations y acceder a ellas utilizando IAM Identity Center, en lugar de usuarios individuales de IAM, si lo prefieres.

En caso de no tener acceso a varias cuentas de AWS, puedes realizar el despliegue de todas las VPC dentro de una misma cuenta; en ese caso, simplemente deberás omitir el paso de compartir el Transit Gateway mediante AWS RAM.

Necesitarás permisos sobre Amazon VPC, AWS Transit Gateway, AWS RAM, AWS Network Firewall y, de forma opcional, sobre CloudWatch Logs, EC2 y Session Manager, entre otros, para poder ejecutar las acciones descritas en esta guía.

El despliegue lo realizaré en la región N. Virginia (us-east-1), y el siguiente diagrama refleja cómo luce mi estructura multicuenta al inicio: una cuenta destinada a los recursos de red (Hub) y cuatro cuentas para las cargas de trabajo (Spoke).

AWS Organization Accounts

Pasos de Implementación

Las siguientes secciones proporcionan un recorrido paso a paso del proceso de configuración de la red, mostrando cómo cada componente, incluyendo el Transit Gateway, VPCs compartidas, VPCs de carga de trabajo y AWS Network Firewall, se integra para crear una base segura y escalable para la conectividad y la inspección entre cuentas.

Configura el Transit Gateway

  1. Crea un Transit Gateway con configuración predeterminada.

  2. Crea dos tablas de enrutamiento de Transit Gateway:

    • tgw-default-association-rtb
    • tgw-default-propagation-rtb

  3. Modifica el Transit Gateway y asigna:

    • tgw-default-association-rtb como la Tabla de Enrutamiento de Asociación Predeterminada
    • tgw-default-propagation-rtb como la Tabla de Enrutamiento de Propagación Predeterminada

  4. En AWS RAM, crea un Resource Share con:

    • El Transit Gateway recién creado como el Shared resource
    • Las cuentas Spoke como los Shared principals

  5. (Opcional) Crea un TGW Flow Log para el Transit Gateway para monitorear y registrar el tráfico que fluye a través de él.

Transit Gateway

Notas para la Creación de Subred y Selección de Zona de Disponibilidad:

  • Creación de Subred de Conectividad: Cuando creas una VPC que tendrá conectividad con el Transit Gateway (TGW), se recomienda crear una subred /28 exclusivamente para alojar las Interfaces de Red Elásticas (ENIs) desplegadas por TGW. Esto sigue las mejores prácticas para una gestión eficiente de recursos.

  • Selección de AZ: Elige el mismo ID de Zona de Disponibilidad (AZ), en lugar del nombre de AZ, para evitar cargos por tráfico entre zonas. Por ejemplo, en este caso, estamos usando use1-az1, use1-az2, use1-az4. Es importante notar que us-east-1a y us-east-1b son alias únicos para cada cuenta de AWS. Para asegurarte de que despliegas tus recursos en la misma AZ, usa IDs de AZ en lugar de alias.

  • Soporte de Network Firewall: AWS Network Firewall no es soportado en us1-az3, por lo que elegimos usar use1-az4 en su lugar.

  • Identificación de AZ: Se recomienda añadir el ID de AZ en la etiqueta de nombre de la subred, tabla de enrutamiento y cualquier network appliance asociada para una fácil identificación y gestión.

Construye la VPC de Ingreso

  1. Crea una VPC (por ejemplo, nombrada VPC de ingreso, CIDR 10.20.0.0/20) con:

    • 3 subredes públicas (por ejemplo, /22)
    • 3 subredes privadas para conectividad TGW (/28)
    • 1 Internet Gateway

  2. Crea un Transit Gateway attachment entre el Transit Gateway y la VPC de Ingreso, seleccionando los IDs de Subred de las 3 subredes de conectividad TGW.

  3. Configura la Tabla de Enrutamiento de Subred de Conectividad TGW (esta tabla de enrutamiento solo tendrá una ruta local):

    • ingress-vpc-tgw-connectivity-rtb

      Destino Objetivo Descripción
      10.20.0.0/20 local VPC de Ingreso

  4. Configura la Tabla de Enrutamiento de Subred Pública (esta tabla de enrutamiento necesita una ruta 0.0.0.0/0 al Internet Gateway y rutas a los CIDRs de las VPCs Spoke para ir a través del attachment TGW):

    • ingress-vpc-public-rtb

      Destino Objetivo Descripción
      10.20.0.0/20 local VPC de Ingreso
      10.21.0.0/16 tgw VPC de Desarrollo
      10.22.0.0/16 tgw VPC de QA
      10.23.0.0/16 tgw VPC de Producción
      10.24.0.0/16 tgw VPC de DevOps
      0.0.0.0/0 igw Acceso a Internet

  5. Opcional: Crea un VPC Flow Log para la VPC para monitorear y registrar el tráfico que fluye a través de la VPC de Ingreso.

VPC de Ingreso

Construye la VPC de Inspección

  1. Crea una VPC (por ejemplo, nombrada VPC de inspección, CIDR 10.20.16.0/20) con:

    • 3 subredes privadas para Network Firewall (por ejemplo, /22)
    • 3 subredes privadas para conectividad TGW (/28)

  2. Crea un Transit Gateway attachment entre el Transit Gateway y la VPC de Inspección, seleccionando los IDs de Subred de las 3 subredes de conectividad TGW. Habilita Appliance Mode Support.

    • Nota: Habilitar Appliance Mode en el attachment del Transit Gateway asegura que todo el tráfico de una sesión fluya a través del mismo firewall en la misma Zona de Disponibilidad, previniendo que el tráfico entre AZ sea inspeccionado por el firewall. Esta configuración es importante para mantener una inspección de tráfico consistente y mejorar el rendimiento en arquitecturas multi-AZ.

  3. Edita manualmente las Tablas de Enrutamiento del Transit Gateway:

    • Remueve la propagación del attachment de la VPC de Inspección en la Tabla de Enrutamiento de Propagación Predeterminada del TGW.
    • Remueve la asociación del attachment de la VPC de Inspección en la Tabla de Enrutamiento de Asociación Predeterminada del TGW.
    • Asocia la Tabla de Enrutamiento de Propagación Predeterminada del TGW con el Attachment de la VPC de Inspección.
    • En la Tabla de Enrutamiento de Asociación Predeterminada del TGW, crea una ruta estática a 0.0.0.0/0 hacia el Attachment de la VPC de Inspección.

  4. En la consola de AWS Network Firewall:

    • Elige Crear firewall.
    • En Describir firewall: Añade un nombre y (opcionalmente) una descripción.
    • En Tipo de asociación: Elige VPC y selecciona la VPC de Inspección.
    • En Subredes del Firewall: Selecciona las 3 subredes privadas (no las subredes de conectividad).
    • En Asociar Política de Firewall: Elige Crear y asociar una política de firewall vacía y especifica un nuevo nombre de política de firewall.
    • Crea el firewall; esto tomará unos minutos.

  5. Configura las Tablas de Enrutamiento de Subred de Conectividad TGW (una por AZ). En cada tabla de enrutamiento, añade una ruta a su correspondiente endpoint de VPC de AWS Network Firewall (de tipo Gateway Load Balancer Endpoint) por AZ:

    • inspection-vpc-tgw-connectivity-rtb-use1-az1

      Destino Objetivo Descripción
      10.20.16.0/20 local VPC de Inspección
      0.0.0.0/0 nfw-use1-az1 Endpoint de firewall para use1-az1

    • inspection-vpc-tgw-connectivity-rtb-use1-az2

      Destino Objetivo Descripción
      10.20.16.0/20 local VPC de Inspección
      0.0.0.0/0 nfw-use1-az2 Endpoint de firewall para use1-az2

    • inspection-vpc-tgw-connectivity-rtb-use1-az4

      Destino Objetivo Descripción
      10.20.16.0/20 local VPC de Inspección
      0.0.0.0/0 nfw-use1-az4 Endpoint de firewall para use1-az4

  6. Configura la Tabla de Enrutamiento de Subred Privada (esta tabla de enrutamiento necesita una ruta 0.0.0.0/0 al attachment del Transit Gateway):

    • inspection-vpc-private-rtb

      Destino Objetivo Descripción
      10.20.16.0/20 local VPC de Inspección
      0.0.0.0/0 tgw Transit Gateway

  7. Opcional: Crea un VPC Flow Log para la VPC para monitorear y registrar el tráfico que fluye a través de la VPC de Inspección.

VPC de Inspección

Después de haber implementado en múltiples ocasiones la VPC de Inspección, AWS finalmente lanzó una nueva funcionalidad para AWS Network Firewall: el Transit Gateway Firewall Attachment. Con esta característica, el firewall se conecta directamente al Transit Gateway, eliminando la necesidad de contar con una VPC de inspección. ¿Te interesa? Revisa la sección Bonus más abajo. 😀

Construye la VPC de Egreso

  1. Crea una VPC (por ejemplo, nombrada VPC de egreso, CIDR 10.20.32.0/20) con:

    • 3 subredes públicas (por ejemplo, /22)
    • 3 subredes privadas para conectividad TGW (/28)
    • 1 Internet Gateway
    • 1 NAT Gateway por AZ para alta disponibilidad

  2. Crea un Transit Gateway attachment entre el Transit Gateway y la VPC de Egreso, seleccionando los IDs de Subred de las 3 subredes de conectividad TGW.

  3. Edita manualmente las Tablas de Enrutamiento del Transit Gateway:

    • En la Tabla de Enrutamiento de Propagación Predeterminada del TGW, crea una ruta estática a 0.0.0.0/0 hacia el Attachment de la VPC de Egreso.

  4. Configura las Tablas de Enrutamiento de Subred de Conectividad TGW (crea una tabla de enrutamiento por AZ, y en cada tabla añade una ruta 0.0.0.0/0 a su correspondiente NAT Gateway):

    • egress-vpc-tgw-connectivity-rtb-use1-az1

      Destino Objetivo Descripción
      10.20.32.0/20 local VPC de Egreso
      0.0.0.0/0 natgw-use1-az1 NAT para use1-az1

    • egress-vpc-tgw-connectivity-rtb-use1-az2

      Destino Objetivo Descripción
      10.20.32.0/20 local VPC de Egreso
      0.0.0.0/0 natgw-use1-az2 NAT para use1-az2

    • egress-vpc-tgw-connectivity-rtb-use1-az4

      Destino Objetivo Descripción
      10.20.32.0/20 local VPC de Egreso
      0.0.0.0/0 natgw-use1-az4 NAT para use1-az4

  5. Configura la Tabla de Enrutamiento de Subred Pública (esta tabla de enrutamiento necesita una ruta 0.0.0.0/0 al Internet Gateway y rutas a los CIDRs de las VPCs Spoke para ir a través del attachment TGW):

    • egress-vpc-public-rtb

      Destino Objetivo Descripción
      10.20.32.0/20 local VPC de Egreso
      10.21.0.0/16 tgw VPC de Desarrollo
      10.22.0.0/16 tgw VPC de QA
      10.23.0.0/16 tgw VPC de Producción
      10.24.0.0/16 tgw VPC de DevOps
      0.0.0.0/0 igw Acceso a Internet

  6. Opcional: Crea un VPC Flow Log para la VPC para monitorear y registrar el tráfico que fluye a través de la VPC de Egreso.

VPC de Egreso

Construye las VPCs de Carga de Trabajo

  1. Crea una VPC (por ejemplo, nombrada VPC de desarrollo, CIDR 10.21.0.0/16) con:

    • 3 subredes privadas para cargas de trabajo (por ejemplo, /20)
    • 3 subredes privadas para conectividad TGW (/28)

  2. Crea un Transit Gateway attachment entre el Transit Gateway y la VPC, seleccionando los IDs de Subred de las 3 subredes de conectividad TGW.

  3. Configura la Tabla de Enrutamiento de Subred de Conectividad TGW — esta tabla de enrutamiento solo tendrá una ruta local:

    • development-vpc-tgw-connectivity-rtb

      Destino Objetivo Descripción
      10.21.0.0/16 local VPC de Desarrollo

  4. Configura la Tabla de Enrutamiento de Subred Privada — añade una ruta 0.0.0.0/0 al attachment del Transit Gateway:

    • development-vpc-private-rtb

      Destino Objetivo Descripción
      10.21.0.0/16 local VPC de Desarrollo
      0.0.0.0/0 tgw Transit Gateway

  5. Opcional: Crea un VPC Flow Log para la VPC para monitorear y registrar el tráfico que fluye a través de la VPC de Carga de Trabajo.

VPC de Carga de Trabajo

Este es el diagrama correspondiente a la VPC de Desarrollo, pero, como mencioné anteriormente, cuento con cuatro cuentas destinadas a cargas de trabajo. Por ello, repetí este mismo paso para la VPC de QA (CIDR 10.22.0.0/16), la VPC de Producción (CIDR 10.23.0.0/16) y la VPC de DevOps (CIDR 10.24.0.0/16).

Configura AWS Network Firewall

Este artículo se enfoca principalmente en configurar la Arquitectura base de red y el enrutamiento necesario para usar Network Firewall. Pero a un alto nivel, AWS Network Firewall es un servicio gestionado que te permite proteger tu red filtrando el tráfico hacia y desde tus VPCs. Proporciona un firewall stateful y un sistema de detección y prevención de intrusiones que puede ser desplegado en línea con tu tráfico de red, inspeccionando y filtrando paquetes en tiempo real.

  1. En el Firewall, habilita el registro de Alerta y Flujo, y configura CloudWatch como el destino de los logs creando los grupos de logs necesarios.
  2. Opcional: Edita la Política de Firewall previamente creada para:
    • Añadir grupos de reglas gestionados por AWS
    • Crear y añadir grupos de reglas stateless
    • Crear y añadir grupos de reglas stateful

Revisa la Arquitectura Final

La arquitectura desplegada sigue un modelo de inspección centralizada usando AWS Transit Gateway y AWS Network Firewall para controlar y monitorear el tráfico entre VPCs compartidas y de carga de trabajo.

  1. La Tabla de Enrutamiento de Asociación Predeterminada del Transit Gateway debería verse así:

    • tgw-default-association-rtb

      CIDR Attachment Tipo de Recurso Tipo de Ruta
      0.0.0.0/0 AWS Network Firewall Firewall Estático

  2. La Tabla de Enrutamiento de Propagación Predeterminada del Transit Gateway debería verse así:

    • tgw-default-propagation-rtb

      CIDR Attachment Tipo de Recurso Tipo de Ruta
      10.21.0.0/16 VPC de Desarrollo VPC Propagado
      10.22.0.0/16 VPC de QA VPC Propagado
      10.23.0.0/16 VPC de Producción VPC Propagado
      10.24.0.0/16 VPC de DevOps VPC Propagado
      10.20.0.0/20 VPC de Ingreso VPC Propagado
      10.20.32.0/20 VPC de Egreso VPC Propagado
      0.0.0.0/0 VPC de Egreso VPC Estático

  3. Si las tablas de enrutamiento no aparecen como se esperaba, desasocia y remueve cualquier asociación o propagación incorrecta, luego reasocia y repropaga los attachments con las tablas de enrutamiento apropiadas hasta que las tablas reflejen la configuración correcta.

El siguiente diagrama de arquitectura ilustra la configuración multicuenta final, donde el tráfico de las cuentas spoke (Desarrollo, QA, Producción y DevOps) es enrutado a través de la capa de inspección centralizada en la cuenta Networking.

Arquitectura Desplegada

¿El diagrama no se ve con buena resolución? No te preocupes, puedes descargar el diagrama de arquitectura en formato PDF para verlo en mayor detalle. 🔍

Valida Conectividad e Inspección de Tráfico

  1. Opcionalmente, despliega instancias EC2 en las VPCs de Carga de Trabajo en subredes privadas de carga de trabajo a través de diferentes cuentas.

    • Conecta usando Session Manager e intenta hacer ping entre las IPs privadas de las instancias.
    • Asegúrate de que los grupos de seguridad permitan ICMP entrante y HTTPS saliente (443) a Internet (para Session Manager).
    • Los pings deberían ser exitosos.

  2. Opcionalmente, despliega una VPN de cliente como OpenVPN o WireGuard en una instancia EC2 en una subred pública en la VPC de Ingreso.

    • Conecta a través de la VPN e intenta hacer ping a las IPs privadas de las instancias EC2 en las VPCs de Carga de Trabajo.
    • Asegúrate de que los grupos de seguridad permitan ICMP entrante.
    • Los pings deberían ser exitosos.

  3. Revisa los Grupos de Logs de CloudWatch para verificar los logs de Firewall de tipo Flujo. Deberías ver que todo el tráfico de prueba está pasando exitosamente a través del Network Firewall.

    • El Grupo de Logs de tipo Alerta debería estar vacío por ahora, ya que la Política de Firewall no ha sido configurada aún o el tráfico de prueba no coincide con ninguna regla de alerta.

Bonus: Attachment de Transit Gateway de Network Firewall

Durante re:Inforce 2025, AWS anunció la nueva característica de Attachment de Transit Gateway de Network Firewall, que reemplaza el patrón tradicional de “VPC de Inspección”, simplificando la implementación y mejorando la visibilidad del tráfico.

En lugar del paso "4. Crear VPC de Inspección", harías "4. Crear Attachment de Transit Gateway de Network Firewall".

  1. En la consola de AWS Network Firewall:

    1. Selecciona Crear firewall.
    2. En Describir firewall: Añade un nombre y descripción para el firewall (opcional).
    3. En Tipo de Attachment: Elige Transit Gateway y selecciona el Transit Gateway.
    4. En Zonas de Disponibilidad: Selecciona las 3 Zonas de Disponibilidad con las que has estado trabajando.
    5. En Asociar Política de Firewall: Selecciona Crear y asociar una política de firewall vacía y especifica un nuevo nombre para la política de firewall.
    6. Crea el Firewall; tardará unos minutos.

  2. Edita manualmente las Tablas de Enrutamiento de Transit Gateway:

    1. Remueve la propagación del attachment de Network Firewall TGW en la Tabla de Enrutamiento de Propagación Predeterminada del TGW.
    2. Remueve la asociación del attachment de Network Firewall TGW en la Tabla de Enrutamiento de Asociación Predeterminada del TGW.
    3. Asocia la Tabla de Enrutamiento de Propagación Predeterminada del TGW con el attachment de Network Firewall TGW.
    4. En la Tabla de Enrutamiento de Asociación Predeterminada del TGW, crea una ruta estática a 0.0.0.0/0 hacia el nuevo attachment de Network Firewall TGW.

  3. La Tabla de Enrutamiento de Asociación Predeterminada del Transit Gateway se verá así:

    • tgw-default-association-rtb

      CIDR Attachment Tipo de Recurso Tipo de Ruta
      0.0.0.0/0 AWS Network Firewall Firewall Estático

  4. La Tabla de Enrutamiento de Propagación Predeterminada del Transit Gateway permanecerá sin cambios en este escenario.

Attachment de Transit Gateway de Network Firewall

Estructura de costos

Los costos que deben considerarse en esta implementación son los siguientes:

  • AWS Transit Gateway (TGW)
    • Costo por hora por attachment de VPC: ~ USD 0,05 por hora por cada attachment.
    • Costo por procesamiento de datos: ~ USD 0,02 por GB procesado.
  • AWS Network Firewall (NFW)
    • Costo por hora por endpoint (activo): ~ USD 0,395 por hora en EE. UU.
    • Costo por procesamiento de datos: ~ USD 0,065 por GB de tráfico inspeccionado.
  • NAT Gateway (NATGW)
    • Costo por hora: ~ USD 0,045 por NAT Gateway
    • Costo por GB procesado: ~ USD 0,045 por GB de datos que pasa por el NAT Gateway
  • Transferencia de datos (Data Transfer / egress / inter-AZ / inter-región, etc.)
    • Salida hacia Internet: tasas estándar de egress (~ USD 0,09/GB para los primeros volúmenes etc.)
    • Transferencia cruzada de zona de disponibilidad (cross-AZ): ~ USD 0,01/GB
    • Otras tarifas de transferencia aplican según origen-destino.

Cabe mencionar que los precios indicados corresponden a octubre de 2025.💲

Estimación de costos mensual

Tomando como referencia mi implementación y considerando un tráfico mínimo, la estructura de costos incluiría los siguientes componentes:

  • 7 Transit Gateway attachments
  • 3 NAT Gateways para alta disponibilidad
  • 3 endpoints de Network Firewall para alta disponibilidad
  • Tráfico de inspección y salida modesta, digamos 500 GB/mes (como punto de partida)

Cálculos:

  • Transit Gateway — attachments
    • 7 attachments × USD 0,05/hora = USD 0,35/hora
    • Horas mes (~ 24 × 30 = 720 h) → 0,35 × 720 = USD 252/mes
  • Transit Gateway — procesamiento de datos
    • Supongamos que de esos 500 GB, todo pasa por TGW: 500 × 0,02 = USD 10/mes
  • Network Firewall — endpoints
    • 3 endpoints × USD 0,395/hora = USD 1,185/hora
    • 1,185 × 720 horas = USD 853,20/mes
  • Network Firewall — procesamiento de datos
    • 500 GB × USD 0,065 = USD 32,50/mes
  • NAT Gateways — horas
    • 3 NATGWs × USD 0,045/hora = USD 0,135/hora
    • 0,135 × 720 = USD 97,20/mes
  • NAT Gateways — procesamiento de datos
    • Si asumimos que de esos 500 GB, por ejemplo, 200 GB salen hacia Internet
    • 200 GB × USD 0,045 = USD 9,00/mes
  • Transferencia de datos (egress etc.)
    • Si asumimos que de esos 500 GB, por ejemplo, 200 GB salen hacia Internet
    • 200 × USD 0,09 = USD 18,00/mes
    • Además, supón 100 GB cross-AZ → 100 × USD 0,01 = USD 1,00/mes

Total estimado:

Componente Costo estimado mensual (USD)
TGW — attachments 252,00
TGW — procesamiento datos 10,00
NFW — endpoints 853,20
NFW — procesamiento datos 32,50
NAT — horas 97,20
NAT — procesamiento de datos 9,00
Transferencia de datos (egress + cross-AZ) 19,00
Total estimado ~ USD 1,272,90

Lecciones Aprendidas

Probablemente acabas de ver el estimado de costos y te hayas asustado un poco, ¿cierto? Tranquilo, esto también se debe al costo de la alta disponibilidad. En mi ejemplo utilicé 3 AZs, pero quizá tu caso de uso no requiera tanta disponibilidad para AWS Network Firewall y podrías desplegarlo en solo 1 o 2 AZs, ya que, de todos modos, la caída de una AZ es bastante improbable. 😎

Si decides reducir la cantidad de AZs, debes tener en cuenta dos consideraciones importantes. La primera es el Appliance Mode, mencionado anteriormente, que resulta especialmente relevante para evitar tráfico asimétrico si los recursos no estuvieran distribuidos uniformemente en todas las AZs. Además, debes comprender claramente los conceptos de Fail Open y Fail Closed, que básicamente definen la acción predeterminada si se cayeran todas las AZs donde está desplegado Network Firewall (lo cual es improbable, pero podría ocurrir si decides usar una sola AZ). Fail Open indica que, si Network Firewall falla, todo el tráfico no inspeccionado pasará libremente; mientras que Fail Closed indica que, si falla, ningún tráfico podrá pasar. Es importante evaluar el trade-off entre seguridad y disponibilidad ante estos escenarios y tomar la decisión adecuada.

Por otro lado, otra forma de controlar los costos de Network Firewall es activar únicamente las reglas necesarias. Puede parecer tentador añadir todos los AWS Managed Rule Groups, pero recuerda que cada uno tiene un costo, consume unidades de capacidad y quizá no todas apliquen realmente a tu caso de uso.

Recuerda que la parte más importante al implementar AWS Network Firewall, además de bloquear tráfico, es que te proporcione información y insights accionables. Es decir, los hallazgos, métricas y logs no deben quedarse como información sin uso. Integra Network Firewall con AWS Security Hub para obtener insights de alto valor y poder realizar remediaciones, o incluso automatizarlas mediante un enfoque basado en eventos con Amazon EventBridge, AWS Lambda u otros servicios.

Conclusión

En conclusión, implementar AWS Network Firewall en una arquitectura multicuenta con Transit Gateway proporciona una infraestructura de red robusta, escalable y segura. Siguiendo los pasos descritos en este artículo, puedes implementar y configurar efectivamente Network Firewall para proteger tus VPCs a través de diferentes cuentas dentro de una estructura de AWS Organizations. El patrón Hub & Spoke, combinado con la alta disponibilidad de 3 Zonas de Disponibilidad, asegura que tu red sea resiliente y capaz de manejar varios patrones de tráfico y requisitos de seguridad. Además, el uso de VPC Flow Logs y el registro de Network Firewall permite un monitoreo y análisis detallado del tráfico de red, permitiéndote identificar y responder a posibles amenazas de seguridad con prontitud.

Qué sigue

En la siguiente sección encontrarás los recursos y documentos oficiales de los servicios mencionados, junto con algunos puntos interesantes relacionados con los temas tratados, por si deseas seguir aprendiendo o profundizar para evaluar si realmente aplican a tu caso de uso.

Te invito también a realizar esta implementación en tu propia cuenta de AWS. Recuerda que, si no dispones de múltiples cuentas, puedes desplegar todas las VPC en una sola y experimentar igualmente con AWS Network Firewall. Cuéntame en los comentarios qué te pareció esta guía o si descubriste algo interesante durante tu implementación. ✍🏻

Si bien no lo había mencionado antes, implementé toda esta arquitectura multicuenta utilizando Terraform. Sin embargo, el código de infraestructura como código está actualmente muy adaptado a las necesidades específicas del cliente para el cual fue desplegado. Más adelante estaré modularizando y generalizando este código para distintos escenarios, con el objetivo de poder compartirlo con la comunidad.

Antes de irme, quiero destacar el gran potencial de esta arquitectura centralizada basada en AWS Transit Gateway. A partir de este diseño, podríamos ampliarlo añadiendo una conexión VPN hacia un data center corporativo on-premises; en las VPC de carga de trabajo, desplegar una aplicación en una instancia EC2 expuesta internamente mediante un Network Load Balancer (NLB); y en la VPC de Ingreso, colocar un Application Load Balancer (ALB) público que apunte a las direcciones IP privadas del NLB, permitiendo que los clientes accedan al servicio a través del DNS público del ALB. El siguiente diagrama ilustra, de manera sencilla y resumida, esta posible extensión del diseño.

Extensión del diseño de Transit Gateway

Recursos oficiales

Top comments (0)