DEV Community: Cristhian Becerra

Protege tu dominio con DNSSEC en Amazon Route 53: Guía paso a paso

Cristhian Becerra — Tue, 28 Oct 2025 14:54:06 +0000

TL;DR: Este artículo te guiará en la implementación de DNSSEC para tus dominios en Amazon Route 53. Mostraré paso a paso cómo activar DNSSEC en tu zona alojada en Route 53 y cómo establecer la cadena de confianza entre el Domain Registrar (Namecheap) y los Authoritative DNS Providers (Cloudflare y Amazon Route 53), todo ello alineado con el pilar de Seguridad del AWS Well-Architected Framework. 🔐

Tiempo estimado de lectura: 10 minutos
Nivel: 200
Versión en inglés: Secure Your Domain with DNSSEC in Amazon Route 53: A Step-by-Step Guide

Tabla de Contenidos:

Introducción
- Resolución DNS Recursiva
Qué es DNSSEC
Cómo funciona DNSSEC
- Resolución DNS Recursiva con DNSSEC
Por qué implementar DNSSEC
- Envenenamiento de caché sin DNSSEC
- Envenenamiento de caché con DNSSEC habilitado
Qué vas a implementar
Prerrequisitos
Pasos de Implementación
- Configura DNSSEC en Amazon Route 53
- Configura DNSSEC en Cloudflare
- Configura DNSSEC en Namecheap
- Valida la implementación de DNSSEC
Costo de la Implementación
Lecciones Aprendidas
Conclusión
Qué sigue
Recursos oficiales

Introducción

Como todos sabemos, a medida que la tecnología avanza, las amenazas y la cantidad de agentes maliciosos aumentan exponencialmente, por lo que la ciberseguridad se ha convertido en una prioridad cada vez mayor.

El Sistema de Nombres de Dominio (DNS) es una parte esencial de la infraestructura de la web; sin embargo, su diseño original carece de mecanismos de seguridad robustos. En otras palabras, el DNS por sí mismo no es seguro: es susceptible a ataques como DNS Spoofing o DNS Cache Poisoning, en los cuales agentes maliciosos envenenan la caché de los servidores DNS para manipular los registros y la resolución de nombres a su conveniencia, redirigiendo así a los usuarios hacia sitios web maliciosos. 😯

Aquí es donde entra DNSSEC, una extensión del protocolo DNS que protege la integridad y autenticidad de la información transmitida durante una consulta DNS, previniendo de este modo los ataques mencionados anteriormente. ¿Y saben qué es lo mejor de todo? ¡Que es muy sencillo de implementar! 🤩

En este artículo explicaremos qué es DNSSEC, cómo funciona, cuáles son sus beneficios y cómo implementarlo para proteger tus dominios en Amazon Route 53.

Resolución DNS Recursiva

Antes de entrar de lleno en DNSSEC, me gustaría recordarles brevemente cómo funciona la recursividad durante la resolución DNS. Cuando un usuario intenta acceder a un dominio, se envía una consulta DNS al servidor DNS local. Este servidor buscará el registro correspondiente en su caché DNS y, si no lo encuentra, el DNS Resolver iniciará consultas recursivas hacia el Root DNS Server y luego al TLD DNS Server, hasta llegar al Authoritative DNS Provider que contiene el registro solicitado. Finalmente, dicho registro será almacenado en la caché DNS local durante el TTL predeterminado, antes de devolver la dirección IP correspondiente al usuario.

Qué es DNSSEC

DNSSEC (Domain Name System Security Extensions) es un conjunto de extensiones de seguridad para el protocolo DNS que permite verificar que las respuestas DNS provienen de una fuente autenticada y que no han sido alteradas durante la transmisión. Su objetivo principal es prevenir amenazas como el DNS Spoofing o DNS Cache Poisoning y los ataques de tipo man-in-the-middle, que pueden comprometer la seguridad de los usuarios al permitir que los atacantes intercepten o modifiquen los datos en tránsito para manipular la información recibida por los usuarios y redirigir a los usuarios hacia sitios falsos. 🫤

Cuando activamos DNSSEC cada respuesta a una consulta DNS incluye una firma digital basada en criptografía de clave pública, y esta firma puede ser verificada por el resolutor DNS para confirmar la autenticidad e integridad de la información devuelta. 😌

En resumen, DNSSEC ayuda a garantizar que los usuarios accedan al sitio web real que están buscando y no a uno falso. Si bien DNSSEC no protege la privacidad de las consultas con cifrado. dado que esa función corresponde a protocolos como TLS (Transport Layer Security), DNSSEC sí evita que actores maliciosos inserten respuestas manipuladas en las consultas DNS durante el proceso de resolución de nombres.

Hasta ahora todo suena increíble, pero quizá se estén preguntando: ¿Y cómo funciona DNSSEC por detrás? 🤔

Cómo funciona DNSSEC

DNSSEC añade una capa adicional de seguridad mediante validación criptográfica al proceso de resolución de nombres DNS. El funcionamiento de DNSSEC se basa en varios componentes que trabajan en conjunto para establecer una cadena de confianza, entre los cuales se encuentran:

Registros DNSKEY: almacenan las claves públicas utilizadas para verificar las firmas digitales de los registros DNS. Dentro de estos registros se incluyen dos tipos de claves:
- ZSK (Zone Signing Key): se utiliza para firmar los registros dentro de la zona DNS (por ejemplo, A, MX, TXT, etc.).
- KSK (Key Signing Key): se utiliza exclusivamente para firmar la ZSK, y su clave pública se publica en el registro DS en la zona superior.
Registros RRSIG: contienen la firma digital de cada conjunto de registros DNS.
Registro DS: vincula la clave pública del dominio con su zona superior, estableciendo así la cadena de confianza.

Durante la resolución de un nombre de dominio, cuando un usuario intenta acceder a un sitio web, el resolutor recursivo consulta los registros DNS y verifica la firma digital utilizando la clave pública correspondiente. Si la firma es válida, la respuesta se considera confiable y es aceptada. De lo contrario, se asume que la información pudo haber sido alterada y, por lo tanto, se considera peligrosa, bloqueando el acceso. ⛔

Resolución DNS Recursiva con DNSSEC

Ahora les quiero mostrar cómo se ve el proceso de resolución DNS recursiva cuando se implementa DNSSEC, estableciendo una cadena de confianza de extremo a extremo. La resolución recursiva es similar, pero esta vez cada respuesta DNS incluye una DNSKEY para la validación de autenticidad con el dominio superior y un registro DS para la validación con un subdominio. En otras palabras, para cada respuesta DNS, el DNS Resolver valida la DNSKEY recibida contra el registro DS correspondiente en el dominio superior, y solo si la validación es correcta, la respuesta DNS es aceptada por el DNS Resolver.

Por qué implementar DNSSEC

Como he mencionado líneas arriba, DNS por sí solo no es seguro y, por defecto, estamos expuestos a ataques como DNS Spoofing o DNS Cache Poisoning. Sin embargo, estos riesgos pueden mitigarse fácilmente si configuramos DNSSEC en nuestros dominios.

Implementar DNSSEC ofrece varios beneficios importantes:

Protección contra manipulaciones: evita que los atacantes modifiquen o falsifiquen respuestas DNS durante la transmisión.
Mayor nivel de confianza: al verificar la autenticidad de la información, los usuarios pueden estar seguros de que están accediendo al sitio correcto.
Defensa frente a ataques de envenenamiento de caché y redireccionamientos maliciosos.
Mejor reputación para tu marca o proyecto: demostrar un compromiso con la seguridad es un factor clave para mejorar la percepción y la experiencia del usuario.

Envenenamiento de caché sin DNSSEC

Durante un envenenamiento de caché sin DNSSEC, el atacante intercepta la solicitud DNS realizada por el usuario y, antes de que el Authoritative DNS Provider pueda responder, realiza un spoofing enviando rápidamente una respuesta DNS manipulada para inyectar un registro malicioso en el servidor DNS local. Dado que el DNS Resolver no tiene forma de determinar si la respuesta es auténtica, debido al IP address spoofing, el servidor DNS local almacena la respuesta en caché durante el TTL predeterminado, redirigiendo así a los usuarios al sitio web malicioso. Cuando finalmente llega la respuesta legítima del Authoritative DNS Provider, el DNS Resolver la descarta, ya que la consulta DNS ya fue atendida.

Envenenamiento de caché con DNSSEC habilitado

Durante un envenenamiento de caché con DNSSEC habilitado, el atacante intenta inyectar una respuesta DNS manipulada. Sin embargo, el DNS Resolver, esta vez DNSSEC-aware, valida la firma de la respuesta DNS contra la llave pública almacenada en el registro DS del dominio superior. Al no ser válida, la respuesta DNS maliciosa es bloqueada. Por el contrario, la respuesta auténtica del Authoritative DNS Provider contiene una firma válida, por lo que es aceptada y el usuario es dirigido al sitio web legítimo.

En un entorno cada vez más dependiente de la tecnología, proteger la integridad de las comunicaciones DNS es una prioridad para todos. Por ello, es importante que sepas cómo implementar DNSSEC. Además, cuando te muestre lo sencillo que resulta hacerlo, probablemente conviertas su implementación en un estándar para todos tus dominios. 🙌🏻

Qué vas a implementar

Esta guía asume que ya cuentas con una Hosted Zone en Route 53 correctamente configurada para tu dominio. Lo que haremos será implementar DNSSEC sobre dicha Hosted Zone y a lo largo de toda la cadena de confianza.

En mi caso, cuento con los siguientes componentes:

Domain Name Registrar: Namecheap
Authoritative DNS Provider: Cloudflare
Managed DNS Service: Amazon Route 53
Delegated DNS Zone: Amazon Route 53 Hosted Zone

Dentro de la consola de Amazon Route 53, activaremos DNSSEC Signing para la Hosted Zone y estableceremos una cadena de confianza entre Amazon Route 53 y Cloudflare, y luego entre Cloudflare y Namecheap.

Cabe mencionar que, dependiendo de tu caso de uso particular, es posible que no estés utilizando Cloudflare como Authoritative DNS Provider como en mi caso, y que emplees directamente Amazon Route 53. Incluso podrías usar Amazon Route 53 también como Domain Name Registrar, lo que implicaría una cadena de confianza mucho más corta y sencilla al momento de implementar DNSSEC, pero esta guía asume que tu Domain Name Registrar no es Route 53.

Prerrequisitos

Para esta implementación de DNSSEC, se requiere contar con los siguientes prerrequisitos:

Acceso a una cuenta AWS.
Acceso administrativo al Domain Name Registrar (por ejemplo, Namecheap) y ser propietario del dominio.
Acceso administrativo al Authoritative DNS Provider (Cloudflare o Amazon Route 53).
Acceso administrativo a cualquier secondary o delegated Authoritative DNS Provider dentro de la cadena de confianza.
Contar con una Hosted Zone en Amazon Route 53 correctamente configurada y/o delegada.
Permisos IAM en la cuenta AWS para utilizar los servicios Amazon Route 53 y AWS Key Management Service (KMS).

Pasos de Implementación

Las siguientes secciones ofrecen una guía paso a paso para la configuración de DNSSEC, mostrando cómo se integran cada uno de los componentes —Amazon Route 53, Cloudflare y Namecheap— para establecer la cadena de confianza de tu dominio. Primero implementaré la confianza entre Amazon Route 53 y Cloudflare, y luego entre Cloudflare y Namecheap.

Configura DNSSEC en Amazon Route 53

1. Ingresa a la consola de Amazon Route 53.

2. En el listado de Hosted Zones, selecciona la zona alojada a la cual deseas implementar DNSSEC.

3. Dentro de la zona alojada, selecciona la pestaña DNSSEC signing.

4. En la sección DNSSEC signing, haz clic en el botón Enable DNSSEC Signing.

5. Especifica un nombre para la Key-signing key (KSK), por ejemplo: mi_dominio_ksk.

6. Selecciona una Customer managed key (CMK) existente o crea una nueva.

En este ejemplo, se creará una nueva CMK. Para ello, ingresa el nombre deseado para la clave, por ejemplo: dnssec_cmk.

7. Haz clic en Create KSK and enable signing.

Verás el mensaje "Enabling DNSSEC signing for the hosted zone" — este proceso puede tomar algunos minutos.

Una vez que aparezca el mensaje "DNSSEC signing was successfully enabled for the hosted zone", en la pestaña DNSSEC Signing podrás verificar que DNSSEC se encuentra en estado Signing, y que la nueva Key-signing key (KSK) está activa.

8. En la sección DNSSEC Signing, haz clic en el botón View information to create DS Record.

9. En la sección Establish a chain of trust, ubica el apartado Another domain registrar (si aplica) y revisa los valores para Domain name, Key tag, Signing algorithm type, Digest algorithm type, Digest y DS record.

Configura DNSSEC en Cloudflare

1. En Cloudflare, abre el listado de Records del dominio correspondiente y selecciona Add record.

2. Selecciona el tipo de record DS.

En el campo Name, ingresa el subdominio necesario para completar el Domain name, o utiliza @ para el dominio raíz.
Completa los valores correspondientes para Key tag, Signing algorithm type, Digest algorithm type y Digest, utilizando la información obtenida desde Route 53.

3. Guarda el registro.

El contenido del registro DS debe ser idéntico al valor del DS Record generado en Route 53.

Con esto se completa la confianza entre Amazon Route 53 y Cloudflare. A continuación, estableceremos la confianza entre Cloudflare y Namecheap.

4. En Cloudflare, abre los DNS Settings del dominio correspondiente y selecciona Enable DNSSEC.

5. En la pestaña How to enable DNSSEC, revisa los valores para DS record, Digest, Digest type, Algorithm y Key tag.

6. Haz clic en Confirm para habilitar DNSSEC.

Configura DNSSEC en Namecheap

1. En Namecheap, selecciona el dominio correspondiente y dirígete a la pestaña Advanced DNS.

2. En la sección DNSSEC, activa la opción ubicada junto al campo Status para habilitar DNSSEC.

3. Completa el registro DS con los valores de Key tag, Algorithm, Digest Type y Digest obtenidos desde Cloudflare, y guarda los cambios.

El contenido del registro DS debe coincidir con el valor del DS Record de Cloudflare.

4. En Cloudflare, al revisar nuevamente los DNS Settings del dominio, deberías ver el mensaje: "Success! Your domain is protected with DNSSEC".

Con esto, se completa la confianza entre Cloudflare y Namecheap. En este punto, toda la cadena de confianza requerida para configurar DNSSEC en tu Hosted Zone de Amazon Route 53 habrá sido establecida exitosamente.

Valida la implementación de DNSSEC

Como último paso, es importante verificar que la configuración de DNSSEC sea completamente funcional. Para ello, puedes utilizar herramientas en línea como:

Estas herramientas permiten ingresar tu dominio y comprobar si DNSSEC está correctamente habilitado y configurado en toda la cadena de confianza.

A continuación, estoy compartiendo un análisis de DNSSEC Analyzer con un resultado exitoso, el cual demuestra una correcta configuración de DNSSEC desde Namecheap, pasando por Cloudflare, hasta Amazon Route 53.

Costo de la Implementación

La implementación de DNSSEC por parte de Amazon Route 53 no tiene costo, y dado que ya contabas con el dominio, el único gasto asociado sería el correspondiente a la Customer Managed Key (CMK) utilizada para generar la Key Signing Key (KSK).💲

Así que solo se te cobrará por el uso de AWS KMS según la forma en que utilices las claves requeridas para la firma DNSSEC de tus zonas alojadas.

Es importante mencionar que una CMK puede reutilizarse para la firma de múltiples dominios, lo que contribuiría a optimizar costos.

Para más información y detalles específicos sobre los precios, consulta la página de precios de AWS Key Management Service, disponible en la sección final de recursos oficiales.

Lecciones Aprendidas

Si bien la solución es sencilla de implementar y de bajo costo en la factura de AWS, debes tener en cuenta la posible complejidad operativa en entornos donde un dominio utiliza múltiples proveedores de DNS, ya que mantener sincronizadas las claves y los registros DS puede volverse un proceso complejo y, por ende, propenso a errores. 🧐

En otras palabras, DNSSEC conlleva un costo operativo que no necesariamente es económico, pues implica mantenimiento y responsabilidad continua, rotación de claves, verificación periódica y la posible actualización de automatizaciones o scripts CI/CD relacionados con la infraestructura DNS.

Por otro lado, es importante recordar que DNSSEC garantiza autenticidad e integridad, pero no protege contra todos los tipos de ataques. Amenazas como la filtración de datos DNS o la privacidad del usuario requieren el uso de protocolos como DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT).

Finalmente, en mi experiencia, algo común que puede ocurrir es que, aun después de haber configurado correctamente toda la cadena de confianza para implementar DNSSEC, el DNSSEC Analyzer continúe mostrando errores. Esto puede deberse a que algunos registros aún no se han propagado completamente, proceso que puede tardar varias horas. Para verificarlo, accede a dns.google y consulta el registro DS de tu dominio. Revisa la data de la respuesta y confirma que coincida con el registro DS de Route 53; si no coincide, la propagación aún no ha finalizado. ⌛

Conclusión

De manera sencilla y con un costo reducido —aunque sin dejar de considerar los posibles costos operativos—, la implementación de DNSSEC fortalece la infraestructura de la web al ofrecer un sistema de nombres de dominio más seguro y confiable, reduciendo significativamente el riesgo de ataques o modificaciones no autorizadas a las respuestas a consultas DNS durante su transmisión. 🥳

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 aún no cuentas con un dominio propio, puedes adquirir uno en Namecheap, ya que comprar un domain name ahí es, bueno… cheap jaja. Cuéntame en los comentarios qué te pareció esta guía o si descubriste algo interesante durante tu implementación. ✍🏻

Recursos oficiales

Secure Your Domain with DNSSEC in Amazon Route 53: A Step-by-Step Guide

Cristhian Becerra — Tue, 28 Oct 2025 14:53:10 +0000

TL;DR: This article will guide you through implementing DNSSEC for your domains in Amazon Route 53. I’ll show step by step how to enable DNSSEC in your hosted zone in Route 53 and how to establish the chain of trust between the Domain Registrar (Namecheap) and the Authoritative DNS Providers (Cloudflare and Amazon Route 53), all aligned with the Security pillar of the AWS Well-Architected Framework. 🔐

Estimated reading time: 10 minutes
Level: 200
Spanish version: Protege tu dominio con DNSSEC en Amazon Route 53: Guía paso a paso

Introduction
- Recursive DNS Resolution
What is DNSSEC
How DNSSEC Works
- Recursive DNS Resolution with DNSSEC
Why Implement DNSSEC
- DNS Cache Poisoning without DNSSEC
- DNS Cache Poisoning with DNSSEC Enabled
What You Are Going to Implement
Prerequisites
Implementation Steps
- Configure DNSSEC in Amazon Route 53
- Configure DNSSEC in Cloudflare
- Configure DNSSEC in Namecheap
- Validate the DNSSEC Implementation
Implementation Cost
Lessons Learned
Conclusion
What’s Next
Official Resources

Introduction

As we all know, as technology advances, the number of threats and malicious actors increases exponentially, making cybersecurity an ever-growing priority.

The Domain Name System (DNS) is a fundamental part of the web’s infrastructure; however, its original design lacks robust security mechanisms. In other words, DNS by itself is not secure — it’s vulnerable to attacks such as DNS Spoofing or DNS Cache Poisoning, in which malicious actors poison the cache of DNS servers to manipulate records and name resolution to their advantage, redirecting users to malicious websites. 😯

This is where DNSSEC comes in — an extension of the DNS protocol that protects the integrity and authenticity of the information transmitted during a DNS query, thereby preventing the aforementioned attacks. And you know what’s best? It’s actually very easy to implement! 🤩

In this article, we’ll explain what DNSSEC is, how it works, what its benefits are, and how to implement it to protect your domains in Amazon Route 53.

Recursive DNS Resolution

Before diving into DNSSEC, I’d like to briefly remind you how recursion works during DNS resolution. When a user tries to access a domain, a DNS query is sent to the local DNS server. This server will look for the corresponding record in its DNS cache, and if it’s not found, the DNS Resolver will start recursive queries to the Root DNS Server and then to the TLD DNS Server, until it reaches the Authoritative DNS Provider that contains the requested record. Finally, that record will be stored in the local DNS cache for the default TTL before returning the corresponding IP address to the user.

What is DNSSEC

DNSSEC (Domain Name System Security Extensions) is a set of security extensions for the DNS protocol that allows verification that DNS responses come from an authenticated source and have not been altered during transmission. Its main goal is to prevent threats such as DNS Spoofing, DNS Cache Poisoning, and man-in-the-middle attacks, which can compromise user security by allowing attackers to intercept or modify data in transit to manipulate the information received by users and redirect them to fake websites. 🫤

When DNSSEC is enabled, each response to a DNS query includes a digital signature based on public key cryptography, and this signature can be verified by the DNS resolver to confirm the authenticity and integrity of the returned information. 😌

In short, DNSSEC helps ensure that users reach the legitimate website they are looking for, not a fraudulent one. While DNSSEC does not protect the privacy of DNS queries through encryption — since that function belongs to protocols such as TLS (Transport Layer Security) — it does prevent malicious actors from injecting tampered responses into DNS queries during the name resolution process.

So far, everything sounds great — but you might be wondering: how does DNSSEC actually work behind the scenes? 🤔

How DNSSEC Works

DNSSEC adds an additional layer of security through cryptographic validation to the DNS name resolution process. The operation of DNSSEC is based on several components that work together to establish a chain of trust, including:

DNSKEY Records: store the public keys used to verify the digital signatures of DNS records. Within these records, there are two types of keys:
- ZSK (Zone Signing Key): used to sign records within the DNS zone (e.g., A, MX, TXT, etc.).
- KSK (Key Signing Key): used exclusively to sign the ZSK, and its public key is published in the DS record in the parent zone.
RRSIG Records: contain the digital signature for each set of DNS records.
DS Record: links the domain’s public key with its parent zone, thus establishing the chain of trust.

During the resolution of a domain name, when a user tries to access a website, the recursive resolver queries the DNS records and verifies the digital signature using the corresponding public key. If the signature is valid, the response is considered trustworthy and accepted. Otherwise, it is assumed that the information may have been tampered with and is therefore considered unsafe, blocking access. ⛔

Recursive DNS Resolution with DNSSEC

Now I want to show you how the recursive DNS resolution process looks when DNSSEC is implemented, establishing an end-to-end chain of trust. The recursive resolution is similar, but this time each DNS response includes a DNSKEY for authenticity validation with the parent domain and a DS record for validation with a subdomain. In other words, for each DNS response, the DNS Resolver validates the received DNSKEY against the corresponding DS record in the parent domain, and only if the validation succeeds, the DNS response is accepted by the DNS Resolver.

Why Implement DNSSEC

As I mentioned earlier, DNS by itself is not secure, and by default, we are exposed to attacks such as DNS Spoofing or DNS Cache Poisoning. However, these risks can be easily mitigated by configuring DNSSEC on our domains.

Implementing DNSSEC offers several important benefits:

Protection against tampering: prevents attackers from modifying or forging DNS responses during transmission.
Higher level of trust: by verifying the authenticity of information, users can be confident they are accessing the correct site.
Defense against cache poisoning and malicious redirections.
Improved reputation for your brand or project: demonstrating a commitment to security is a key factor in improving user perception and experience.

DNS Cache Poisoning without DNSSEC

During cache poisoning without DNSSEC, the attacker intercepts the DNS query made by the user and, before the Authoritative DNS Provider can respond, performs spoofing by quickly sending a manipulated DNS response to inject a malicious record into the local DNS server. Since the DNS Resolver has no way to determine whether the response is authentic, due to IP address spoofing, the local DNS server caches the response for the default TTL, redirecting users to the malicious website. When the legitimate response from the Authoritative DNS Provider finally arrives, the DNS Resolver discards it because the DNS query has already been resolved.

DNS Cache Poisoning with DNSSEC Enabled

During cache poisoning with DNSSEC enabled, the attacker attempts to inject a manipulated DNS response. However, this time the DNS Resolver, being DNSSEC-aware, validates the signature of the DNS response against the public key stored in the DS record of the parent domain. Since it’s invalid, the malicious DNS response is blocked. In contrast, the legitimate response from the Authoritative DNS Provider contains a valid signature, so it is accepted and the user is directed to the legitimate website.

In an increasingly technology-dependent environment, protecting the integrity of DNS communications is a priority for everyone. That’s why it’s important to understand how to implement DNSSEC. Moreover, once I show you how simple it is to do, you’ll probably make its implementation a standard practice across all your domains. 🙌🏻

What You Are Going to Implement

This guide assumes that you already have a Hosted Zone in Route 53 correctly configured for your domain. What we will do is implement DNSSEC on this Hosted Zone and throughout the entire chain of trust.

In my case, I have the following components:

Domain Name Registrar: Namecheap
Authoritative DNS Provider: Cloudflare
Managed DNS Service: Amazon Route 53
Delegated DNS Zone: Amazon Route 53 Hosted Zone

Within the Amazon Route 53 console, we will enable DNSSEC Signing for the Hosted Zone and establish a chain of trust between Amazon Route 53 and Cloudflare, and then between Cloudflare and Namecheap.

It is worth mentioning that, depending on your particular use case, you may not be using Cloudflare as the Authoritative DNS Provider as in my case, and you might be using Amazon Route 53 directly. You could even use Amazon Route 53 as the Domain Name Registrar as well, which would imply a much shorter and simpler chain of trust when implementing DNSSEC, but this guide assumes that your Domain Name Registrar is not Route 53.

Prerequisites

For this DNSSEC implementation, the following prerequisites are required:

Access to an AWS account.
Administrative access to the Domain Name Registrar (e.g., Namecheap) and ownership of the domain.
Administrative access to the Authoritative DNS Provider (Cloudflare or Amazon Route 53).
Administrative access to any secondary or delegated Authoritative DNS Provider within the chain of trust.
A properly configured and/or delegated Hosted Zone in Amazon Route 53.
IAM permissions in the AWS account to use Amazon Route 53 and AWS Key Management Service (KMS).

Implementation Steps

The following sections provide a step-by-step guide for DNSSEC configuration, showing how each component—Amazon Route 53, Cloudflare, and Namecheap—integrates to establish your domain’s chain of trust. First, I will implement trust between Amazon Route 53 and Cloudflare, and then between Cloudflare and Namecheap.

Configure DNSSEC in Amazon Route 53

1. Log in to the Amazon Route 53 console.

2. In the list of Hosted Zones, select the hosted zone where you want to implement DNSSEC.

3. Within the hosted zone, select the DNSSEC signing tab.

4. In the DNSSEC signing section, click the Enable DNSSEC Signing button.

5. Specify a name for the Key-signing key (KSK), for example: my_domain_ksk.

6. Select an existing Customer managed key (CMK) or create a new one.

In this example, a new CMK will be created. Enter the desired name for the key, for example: dnssec_cmk.

7. Click Create KSK and enable signing.

You will see the message "Enabling DNSSEC signing for the hosted zone" — this process may take a few minutes.

Once the message "DNSSEC signing was successfully enabled for the hosted zone" appears, you can verify in the DNSSEC Signing tab that DNSSEC is in Signing status, and that the new Key-signing key (KSK) is active.

8. In the DNSSEC Signing section, click the View information to create DS Record button.

9. In the Establish a chain of trust section, locate the Another domain registrar area (if applicable) and review the values for Domain name, Key tag, Signing algorithm type, Digest algorithm type, Digest, and DS record.

Configure DNSSEC in Cloudflare

1. In Cloudflare, open the Records list for the corresponding domain and select Add record.

2. Select the record type DS.

In the Name field, enter the necessary subdomain to complete the Domain name, or use @ for the root domain.
Fill in the corresponding values for Key tag, Signing algorithm type, Digest algorithm type, and Digest, using the information obtained from Route 53.

3. Save the record.

The content of the DS record must be identical to the DS Record value generated in Route 53.

This completes the trust between Amazon Route 53 and Cloudflare. Next, we will establish trust between Cloudflare and Namecheap.

4. In Cloudflare, open the DNS Settings for the corresponding domain and select Enable DNSSEC.

5. In the How to enable DNSSEC tab, review the values for DS record, Digest, Digest type, Algorithm, and Key tag.

6. Click Confirm to enable DNSSEC.

Configure DNSSEC in Namecheap

1. In Namecheap, select the corresponding domain and go to the Advanced DNS tab.

2. In the DNSSEC section, enable the option next to the Status field to activate DNSSEC.

3. Complete the DS record with the values for Key tag, Algorithm, Digest Type, and Digest obtained from Cloudflare, and save the changes.

The content of the DS record must match the DS Record value from Cloudflare.

4. In Cloudflare, when reviewing the DNS Settings of the domain again, you should see the message: "Success! Your domain is protected with DNSSEC".

This completes the trust between Cloudflare and Namecheap. At this point, the entire chain of trust required to configure DNSSEC on your Amazon Route 53 Hosted Zone has been successfully established.

Validate the DNSSEC Implementation

As a final step, it is important to verify that the DNSSEC configuration is fully functional. For this, you can use online tools such as:

These tools allow you to enter your domain and check if DNSSEC is properly enabled and configured throughout the chain of trust.

Below, I am sharing a DNSSEC Analyzer report with a successful result, demonstrating a correct DNSSEC configuration from Namecheap, through Cloudflare, to Amazon Route 53.

Implementation Cost

The implementation of DNSSEC by Amazon Route 53 has no cost, and since you already owned the domain, the only associated expense would be for the Customer Managed Key (CMK) used to generate the Key Signing Key (KSK). 💲

So you will only be charged for the use of AWS KMS according to how you use the keys required for DNSSEC signing of your hosted zones.

It is important to mention that a CMK can be reused for signing multiple domains, which helps optimize costs.

For more information and specific pricing details, check the AWS Key Management Service pricing page, available in the official resources section at the end.

Lessons Learned

Although the solution is straightforward to implement and low-cost on the AWS bill, you should consider the possible operational complexity in environments where a domain uses multiple DNS providers, as keeping keys and DS records synchronized can become a complex process and, therefore, prone to errors. 🧐

In other words, DNSSEC carries an operational cost that is not necessarily inexpensive, as it involves ongoing maintenance and responsibility, key rotation, periodic verification, and the possible update of automations or CI/CD scripts related to DNS infrastructure.

On the other hand, it is important to remember that DNSSEC guarantees authenticity and integrity, but does not protect against all types of attacks. Threats such as DNS data exfiltration or user privacy require using protocols like DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT).

Finally, in my experience, a common occurrence is that even after correctly configuring the entire chain of trust to implement DNSSEC, the DNSSEC Analyzer may still show errors. This can happen because some records have not yet fully propagated, a process that can take several hours. To verify, access dns.google and check your domain’s DS record. Review the response data and confirm it matches the Route 53 DS record; if it does not match, propagation is still incomplete. ⌛

Conclusion

In a simple and low-cost manner—although still considering potential operational costs—the implementation of DNSSEC strengthens web infrastructure by providing a more secure and reliable domain name system, significantly reducing the risk of unauthorized attacks or modifications to DNS query responses during transmission. 🥳

What’s Next

In the next section, you’ll find official resources and documentation for the services mentioned, along with some interesting points related to the topics covered — in case you want to keep learning or dive deeper to evaluate whether they truly apply to your use case.

I also invite you to try this implementation in your own AWS account. Remember that if you do not yet have your own domain, you can purchase one from Namecheap, since buying a domain name there is, well… cheap haha. Share in the comments what you thought of this guide or if you discovered something interesting during your implementation. ✍🏻

Official Resources

Protege los orígenes de Amazon CloudFront con funcionalidades de seguridad integradas: Mejores prácticas de AWS

Cristhian Becerra — Sat, 25 Oct 2025 19:49:47 +0000

TL;DR: En este artículo te mostraré cómo y por qué debes proteger los orígenes de Amazon CloudFront usando múltiples funcionalidades de seguridad integradas que he puesto en práctica personalmente, junto con el caso de uso y los beneficios de cada una, para lograr un origen protegido y resiliente, todo ello alineado con los pilares de Seguridad y Fiabilidad del AWS Well-Architected Framework. 🌐

Tiempo estimado de lectura: 15 minutos
Nivel: 200
Versión en inglés: Protect Amazon CloudFront Origins with Built-in Security Features: AWS Best Practices

Tabla de Contenidos:

Introducción
Por qué proteger los orígenes de Amazon CloudFront
Funcionalidades de seguridad integradas de CloudFront
- Restricción del acceso al Application Load Balancer
- Restricción del acceso a un origen de Amazon S3
- Restricción del acceso con orígenes de la VPC
- Listas de prefijos administradas por AWS
- Rangos de direcciones IP de AWS
- Restricción de la distribución geográfica
- Cifrado a nivel de campo
- CloudFront Origin Shield
- AWS WAF Core Protections
- CloudFront Origin Groups
Lecciones Aprendidas
Conclusión
Qué sigue
Recursos oficiales

Introducción

Si has oído hablar de Amazon CloudFront, sabes que es un servicio de Content Delivery Network (CDN) que nos ayuda a distribuir contenido estático y dinámico de forma rápida y confiable. CloudFront entrega el contenido a nuestros usuarios a través de una red global de centros de datos conocidos como ubicaciones de borde. Cuando un usuario solicita contenido que estás sirviendo mediante CloudFront, la solicitud se enruta a la ubicación de borde más cercana al usuario —o a la que proporcione la menor latencia— para que el contenido sea entregado con el mejor rendimiento posible.

Si tu contenido es estático, CloudFront te permite almacenarlo en caché, de modo que las solicitudes se atiendan directamente desde el caché y no lleguen al origen, reduciendo así la carga en este. Por otro lado, si tu contenido es dinámico, no se debe almacenar en caché, pero CloudFront permite enrutar la solicitud del usuario hacia el origen a través de la infraestructura de red global de AWS, optimizando la latencia y el rendimiento. 🤩

Cuando empezamos a familiarizarnos con Amazon CloudFront, es común que no conozcamos las mejores prácticas de seguridad recomendadas y, sin querer, las omitamos, dejando nuestros orígenes desprotegidos o vulnerables. Un error frecuente es no restringir el acceso a los orígenes exclusivamente a CloudFront, lo que puede permitir el acceso directo al origen desde rutas no controladas, ocasionando comportamientos no deseados o brechas de seguridad. Para evitar estos problemas, en este artículo te explicaré por qué es importante proteger los orígenes de Amazon CloudFront, además de presentarte múltiples funcionalidades de seguridad integradas que he puesto en práctica y que están alineadas con las mejores prácticas de AWS.

Por qué proteger los orígenes de Amazon CloudFront

En el mundo actual, la tecnología avanza a un ritmo acelerado, y con ello las amenazas de ciberseguridad crecen exponencialmente. Por esta razón, la seguridad se ha convertido en una prioridad fundamental.

Amazon CloudFront nos permite añadir una capa adicional de protección entre nuestros usuarios y los orígenes, los cuales pueden ser balanceadores, servidores, contenedores, entre otros. En lugar de dirigir a los usuarios directamente hacia los orígenes, los redirigimos a través de CloudFront, que actúa como intermediario para recuperar el contenido solicitado y entregarlo posteriormente al usuario.

Al usar CloudFront para crear una distribución estamos añadiendo una capa adicional a nuestro sistema, aunque inicialmente solo se haya pensado en mejorar el rendimiento y la velocidad, estamos incorporando un nuevo componente a nuestra arquitectura que también debe ser protegido. CloudFront ofrece un conjunto de funcionalidades de seguridad integradas que ayudan a proteger nuestros orígenes. Proporciona una defensa adicional frente a múltiples tipos de ataques, incluidos los ataques DDoS, y se integra directamente con AWS WAF y AWS Shield. 🛡️

Sin embargo, de poco sirve implementar múltiples medidas de seguridad en la distribución de CloudFront si nuestros orígenes no están protegidos o si la comunicación hacia ellos no está restringida exclusivamente a CloudFront. Esto dejaría nuestros orígenes expuestos a amenazas y vulnerabilidades que podrían pasar inadvertidas bajo la falsa percepción de que todo el tráfico pasa únicamente por CloudFront. Por estas razones, proteger los orígenes de Amazon CloudFront es un paso esencial para garantizar la seguridad y la integridad de nuestras aplicaciones.

Funcionalidades de seguridad integradas de CloudFront

En las siguientes secciones te presentaré diversas funcionalidades de seguridad integradas que he puesto en práctica, las cuales están alineadas con las mejores prácticas de AWS y que considero podrían resultarte muy útiles conocer. 🚀

Nota: En la sección de recursos oficiales al final encontrarás toda la documentación de AWS correspondiente a cada una de las funcionalidades mencionadas a continuación.

Restricción del acceso al Application Load Balancer

Cuando utilizas un balanceador de carga público (ALB) como origen de una distribución de Amazon CloudFront, este sigue siendo accesible desde Internet de forma predeterminada, y no únicamente a través de CloudFront. Para restringir el acceso al balanceador público de modo que solo sea posible mediante la distribución de CloudFront, puedes usar un encabezado HTTP personalizado.

En la distribución de CloudFront, para el origen específico que deseas proteger, añade un encabezado HTTP personalizado con un valor secreto, el cual no debe exponerse públicamente. De esta forma, CloudFront incluirá este encabezado en todas las solicitudes que envíe al origen (ALB).

Posteriormente, configura el listener del Application Load Balancer para que únicamente reenvíe las solicitudes a sus targets cuando estas contengan el encabezado HTTP personalizado con el valor secreto especificado. Así, el ALB descartará cualquier solicitud que no contenga dicho encabezado, garantizando que solo el tráfico proveniente de CloudFront sea aceptado.

Te recomiendo renovar el valor secreto del encabezado HTTP personalizado al menos una vez al año, como medida preventiva ante posibles filtraciones de seguridad.

Restricción del acceso a un origen de Amazon S3

Cuando utilizas un bucket de Amazon S3 como origen de una distribución de Amazon CloudFront, este permanece accesible desde Internet de forma predeterminada, y no únicamente a través de CloudFront. Para restringir el acceso a los objetos del bucket de modo que solo sea posible mediante la distribución de CloudFront, puedes utilizar Origin Access Control (OAC).

Origin Access Control (OAC) nos permite proteger los orígenes de S3 y, a diferencia de su predecesor Origin Access Identity (OAI), es compatible con todos los buckets de S3 en todas las regiones de AWS. Además, ofrece soporte para cifrado mediante AWS KMS y permite solicitudes dinámicas (como PUT y DELETE) hacia Amazon S3.

Para implementar Origin Access Control (OAC), en el origen específico que deseas proteger, simplemente crea un nuevo origin access control en lugar de utilizar un origen de acceso público, y actualiza la bucket policy del bucket de S3 añadiendo el statement proporcionado por CloudFront, el cual tiene la siguiente estructura:

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<Bucket Name>/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::<Account ID>:distribution/<Distribution ID>"
                }
            }
        }
    ]
}

Restricción del acceso con orígenes de la VPC

Hasta hace relativamente poco tiempo, CloudFront solo permitía configurar orígenes públicos. Es decir, si se deseaba colocar un balanceador de carga o una instancia EC2 detrás de una distribución de CloudFront, estos debían contar obligatoriamente con un DNS resolvible a una dirección IP pública.

A finales de 2024, AWS introdujo CloudFront Virtual Private Cloud (VPC) Origins, una funcionalidad que permite asignar como orígenes a balanceadores privados o instancias EC2 privadas ubicadas en subredes privadas dentro de una VPC. ¡Ya no es necesario que sean públicos!

Para implementar VPC Origins, simplemente crea un nuevo VPC Origin en CloudFront, especificando el ARN del ELB privado o de la instancia EC2 privada. El grupo de seguridad asociado a estos recursos privados debe seguir permitiendo el acceso desde las direcciones IP de CloudFront.

Si bien podrías permitir acceso entrante desde Internet —dado que no se trata de un recurso público—, si deseas evitar que otros recursos privados dentro de la misma VPC puedan acceder al origen y garantizar que solo CloudFront tenga acceso, lo más recomendable es utilizar prefix lists. Para ello, revisa la siguiente sección.

Listas de prefijos administradas por AWS

Cuando en múltiples grupos de seguridad necesitas permitir acceso a un mismo conjunto de direcciones IP, en lugar de agregar manualmente cada dirección IP en todos los grupos, puedes crear una prefix list. En este caso, hablamos de una lista de prefijos administrada por el cliente, es decir, por nosotros, y sería nuestra responsabilidad mantener actualizada dicha lista de direcciones IP.

Por otro lado, una necesidad común al trabajar con recursos dentro de una VPC es limitar el tráfico entrante o saliente únicamente a ciertos servicios de AWS. Aunque es posible obtener el listado de direcciones IP públicas de cada servicio, estas cambian constantemente, y mantenerlas actualizadas manualmente sería una tarea compleja y propensa a errores. Para ello, AWS ofrece las AWS-managed prefix lists, listas de prefijos administradas y actualizadas automáticamente por AWS, que permiten filtrar las direcciones IP de varios servicios como Amazon CloudFront, Amazon DynamoDB, Amazon S3, entre otros.

Como se mencionó en la sección anterior, si deseamos permitir tráfico hacia nuestros recursos en una VPC únicamente desde las direcciones IP de CloudFront, podemos aprovechar la AWS-managed prefix list correspondiente a Amazon CloudFront. Para ello, basta con especificar la Prefix List (pl) como origen o destino en las reglas del grupo de seguridad.

Esta funcionalidad resulta sumamente útil al trabajar con orígenes dentro de una VPC. Sin embargo, si el origen se encuentra On-Premises, ya sea con conectividad híbrida a AWS mediante una Site-to-Site VPN o AWS Direct Connect, o incluso totalmente desconectado de AWS y accesible mediante una dirección IP pública, en ese caso no es posible utilizar prefix lists. Para dichos escenarios, revisa la siguiente sección.

Rangos de direcciones IP de AWS

Como se mencionó en la sección anterior, sí es posible obtener el listado de direcciones IP públicas de cada servicio de AWS. Y si bien, cuando nos encontramos en una VPC podemos aprovechar las prefix lists, cuando trabajamos en entornos On-Premises fuera de AWS nos vemos obligados a utilizar el listado de direcciones IP públicas de AWS.

Para esto, AWS mantiene su listado de direcciones IP públicas actualizado en formato JSON en el archivo ip-ranges.json. Usando las direcciones IP de este listado puedes configurar tu firewall On-Premises. Pero quizá ahora te estés preguntando: ¿cómo mantendré mi firewall actualizado si las direcciones IP de Amazon cambian constantemente?

No te preocupes, Amazon pensó en eso y creó un topic de SNS al cual puedes suscribirte para recibir notificaciones sobre actualizaciones en el archivo ip-ranges.json. El ARN del topic es: arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged. Solo debes suscribirte al topic y desarrollar una pequeña automatización local que procese las notificaciones y actualice las reglas de tu firewall On-Premises según corresponda.

Restricción de la distribución geográfica

Esta sección es simple. Puedes mejorar la seguridad de tu origen configurando restricciones geográficas en tu distribución, siempre y cuando se adapten a tu caso de uso.

Para ello, CloudFront te permite implementar una allow list o block list en tu distribución y especificar todos los países que necesites permitir o bloquear.

Cifrado a nivel de campo

Esta sección aborda un caso de uso particular que ocurre cuando, dentro de la solicitud que realiza el cliente a CloudFront, se incluye un payload con múltiples campos, de los cuales algunos contienen datos sensibles. Los campos con datos sensibles deben ser visibles únicamente para el destino final, mientras que cualquier recurso de red o cómputo intermedio debería ver dichos campos cifrados. Sin embargo, no podemos cifrar toda la solicitud, ya que este caso de uso requiere que los recursos intermedios puedan visualizar sin problemas todos los demás campos con datos no sensibles.

Aquí es donde entra el cifrado a nivel de campo. Supongamos que el cliente envía una solicitud cuyo payload contiene tanto campos con datos no sensibles como campos con datos sensibles, tales como PII, PHI, información confidencial, credenciales, entre otros. Entre CloudFront y el destino final existen múltiples recursos intermedios, y ninguno de ellos debería ser capaz de ver los datos sensibles, aunque sí necesitan poder procesar los campos no sensibles. En este escenario, implementamos el cifrado a nivel de campo proporcionado por CloudFront.

Para implementar el cifrado a nivel de campo, simplemente debemos crear un encryption profile en CloudFront, el cual debe especificar los campos de datos a cifrar y la clave pública que se utilizará para dicho cifrado, previamente almacenada en CloudFront. Por otro lado, el destino final, por ejemplo, un servidor de aplicaciones, debe contar con la clave privada correspondiente y estar configurado para descifrar los campos cifrados. Solo el servidor final posee la clave privada, por lo que, de este modo, se protege la confidencialidad de los datos sensibles frente a los recursos intermedios, sin limitar el procesamiento de los datos no sensibles en una misma solicitud.

CloudFront Origin Shield

Origin Shield es una capa adicional de caché que puede ayudar a reducir la carga en tu origen y, con ello, proteger su disponibilidad. Los principales casos de uso incluyen escenarios con usuarios en distintas regiones geográficas o cuando se trabaja con múltiples CDN.

Origin Shield mejora la tasa de aciertos en caché, disminuye la carga en el origen y optimiza el rendimiento de la red. El flujo de una solicitud en CloudFront sin Origin Shield pasa por las Edge Locations, luego por los Regional Edge Caches y, finalmente, llega al origen. En este caso, múltiples regiones podrían estar consultando el origen de forma innecesaria. Para evitarlo, al activar Origin Shield, se coloca una capa adicional entre los Regional Edge Caches y el origen, de modo que únicamente Origin Shield enviará solicitudes al origen, reduciendo así su carga.

Para usar Origin Shield, dentro de tu distribución selecciona el origen, activa Origin Shield y elige la región de AWS donde deseas desplegarlo.

AWS WAF Core Protections

CloudFront tiene una integración directa con AWS WAF y permite añadir una capa de seguridad básica con un solo clic, lo cual crea en segundo plano un Web ACL con la protección predeterminada que tu aplicación necesita.

La protección predeterminada de WAF para CloudFront incluye defensa frente a vulnerabilidades comunes como las del OWASP Top 10, SQL Injection, Rate Limiting y bloqueo de tráfico proveniente de direcciones IP maliciosas basadas en la inteligencia de amenazas de Amazon. Sin embargo, si lo consideras necesario —y de hecho es lo recomendable—, personaliza tu Web ACL según tus requerimientos y añade las reglas adicionales que estimes convenientes para fortalecer la seguridad de tu origen.

CloudFront Origin Groups

Esta funcionalidad, técnicamente, no constituye una medida de seguridad, sino de resiliencia, pero quiero mencionarla porque la he probado y me parece particularmente interesante.

Como sabrás, CloudFront es un servicio global, pero los orígenes probablemente no lo sean. Es decir, en el evento de una caída regional o de una zona de disponibilidad, la aplicación podría dejar de responder, incluso si la distribución de CloudFront en sí misma no se ve afectada.

Para manejar este tipo de situaciones, CloudFront Origin Groups nos permite configurar una solución de failover de manera sencilla. Solo debemos crear un Origin Group en el cual se especifiquen múltiples orígenes y el criterio de conmutación por error, es decir, los HTTP Status Codes que debe recibir CloudFront para activar el failover hacia otro origen ubicado en una región distinta.

De este modo, CloudFront Origin Groups nos permite mantener una alta disponibilidad ante una falla regional: la misma distribución global sigue activa, simplemente redirigiendo las solicitudes hacia otro origen dentro del grupo, pero ubicado en una región diferente.

Lecciones Aprendidas

Nunca olvides restringir el acceso a los orígenes. En la mayoría de los casos, cuando implementas CloudFront, la distribución debería ser la única con acceso al origen. Por ello, es común implementar todos los mecanismos de defensa en la distribución de CloudFront; sin embargo, si no restringes el acceso al origen, este quedará vulnerable a amenazas que probablemente no habías considerado por haberte enfocado únicamente en proteger la distribución. 😶

Si necesitas implementar AWS WAF para tu aplicación, casi siempre deberías adjuntar el Web ACL a la distribución de CloudFront, en lugar de, por ejemplo, al origen ALB. Siempre tendrá más sentido aplicar WAF a nivel de la distribución, de modo que el tráfico sea filtrado lo más arriba posible, reduciendo así la carga y el costo del procesamiento de datos en el ALB. 😎

Te recomiendo utilizar la georrestricción siempre que sea posible y, por supuesto, cuando aplique a tu caso de uso. En mi experiencia, dependiendo de la región en la que te encuentres, la georrestricción puede ser una de las formas más sencillas de evitar tráfico no deseado de bots de scraping, dado que este tipo de tráfico suele provenir de países específicos. 🤖

Conclusión

Amazon CloudFront cuenta con múltiples funcionalidades de seguridad integradas que nos permiten proteger los orígenes, abarcando desde failover, firewall, georrestricción, capas adicionales de caché, cifrado a nivel de campo y, principalmente, la restricción del acceso al origen. Todo esto nos permite consolidar diversos mecanismos de protección a nivel perimetral en la distribución de CloudFront, reforzando así la postura de seguridad de nuestras aplicaciones mediante una estrategia de defensa en profundidad.

Qué sigue

En la siguiente sección encontrarás los recursos y documentos oficiales de AWS para las funcionalidades de seguridad integradas de Amazon CloudFront mencionadas en este artículo, por si deseas seguir aprendiendo o profundizar para evaluar si realmente aplican a tu caso de uso.

Te invito también a realizar la implementación de estas funcionalidades de seguridad integradas de CloudFront en tu propia cuenta de AWS. Cuéntame en los comentarios qué te pareció este artículo o si descubriste algo interesante sobre alguna característica de Amazon CloudFront durante tu implementación. ✍🏻

Y para mí, un próximo paso será probar la integración de AWS Shield Advanced con CloudFront en un futuro, ya que hasta ahora no he tenido la oportunidad de ver en acción la lógica de mitigación DDoS de AWS Shield aplicada a CloudFront.

Recursos oficiales

Protect Amazon CloudFront Origins with Built-in Security Features: AWS Best Practices

Cristhian Becerra — Sat, 25 Oct 2025 19:48:47 +0000

TL;DR: In this article, I will show you how and why you should protect Amazon CloudFront origins using multiple built-in security features that I have personally implemented, along with the use case and benefits of each, to achieve a protected and resilient origin, all aligned with the Security and Reliability pillars of the AWS Well-Architected Framework. 🌐

Estimated reading time: 15 minutes
Level: 200
Spanish version: Protege los orígenes de Amazon CloudFront con funcionalidades de seguridad integradas: Mejores prácticas de AWS

Introduction
Why Protect Amazon CloudFront Origins
Built-in CloudFront Security Features
- Restrict Access to Application Load Balancers
- Restrict Access to an Amazon S3 Origin
- Restrict Access with VPC Origins
- AWS-Managed Prefix Lists
- AWS IP Address Ranges
- CloudFront Geographic Restrictions
- CloudFront Field-Level Encryption
- CloudFront Origin Shield
- AWS WAF Core Protections
- CloudFront Origin Groups
Lessons Learned
Conclusion
What's Next
Official Resources

Introduction

If you’ve heard of Amazon CloudFront, you know it is a Content Delivery Network (CDN) service that helps us distribute static and dynamic content quickly and reliably. CloudFront delivers content to our users through a global network of data centers known as edge locations. When a user requests content you’re serving via CloudFront, the request is routed to the edge location closest to the user—or the one that provides the lowest latency—so that the content is delivered with the best possible performance.

If your content is static, CloudFront allows you to cache it so that requests are served directly from the cache and do not reach the origin, thus reducing the load on it. On the other hand, if your content is dynamic, it should not be cached, but CloudFront enables routing the user’s request to the origin through AWS’s global network infrastructure, optimizing latency and performance. 🤩

When we start getting familiar with Amazon CloudFront, it’s common not to know the recommended security best practices and inadvertently skip them, leaving our origins unprotected or vulnerable. A frequent mistake is not restricting access to origins exclusively to CloudFront, which can allow direct access to the origin through uncontrolled routes, leading to undesired behavior or security breaches. To prevent these issues, in this article I will explain why it’s important to protect Amazon CloudFront origins, as well as present multiple built-in security features that I have implemented and that align with AWS best practices.

Why Protect Amazon CloudFront Origins

In today’s world, technology advances at a rapid pace, and with it, cybersecurity threats grow exponentially. For this reason, security has become a fundamental priority.

Amazon CloudFront allows us to add an extra layer of protection between our users and the origins, which can be load balancers, servers, containers, among others. Instead of directing users straight to the origins, we redirect them through CloudFront, which acts as an intermediary to retrieve the requested content and then deliver it to the user.

By using CloudFront to create a distribution, we are adding an additional layer to our system. Even if the initial goal was only to improve performance and speed, we are incorporating a new component into our architecture that also needs protection. CloudFront offers a set of built-in security features that help protect our origins. It provides additional defense against multiple types of attacks, including DDoS attacks, and integrates directly with AWS WAF and AWS Shield. 🛡️

However, implementing multiple security measures on the CloudFront distribution is of little use if our origins are not protected or if communication to them is not restricted exclusively to CloudFront. This would leave our origins exposed to threats and vulnerabilities that could go unnoticed under the false perception that all traffic passes solely through CloudFront. For these reasons, protecting Amazon CloudFront origins is an essential step to ensure the security and integrity of our applications.

Built-in CloudFront Security Features

In the following sections, I will present various built-in security features that I have personally implemented, which are aligned with AWS best practices and that I believe you will find very useful to know. 🚀

Note: In the official resources section at the end, you will find all the corresponding AWS documentation for each of the features mentioned below.

Restrict Access to Application Load Balancers

When you use a public load balancer (ALB) as the origin of an Amazon CloudFront distribution, it remains accessible from the Internet by default, not just through CloudFront. To restrict access to the public load balancer so that it is only possible via the CloudFront distribution, you can use a custom HTTP header.

In the CloudFront distribution, for the specific origin you want to protect, add a custom HTTP header with a secret value, which must not be publicly exposed. This way, CloudFront will include this header in all requests it sends to the origin (ALB).

Then, configure the Application Load Balancer listener to only forward requests to its targets when they contain the custom HTTP header with the specified secret value. This ensures that the ALB will discard any request that does not contain this header, guaranteeing that only traffic coming from CloudFront is accepted.

It is recommended to renew the secret value of the custom HTTP header at least once a year as a precaution against potential security leaks.

Restrict Access to an Amazon S3 Origin

When you use an Amazon S3 bucket as the origin of an Amazon CloudFront distribution, it remains accessible from the Internet by default, not just through CloudFront. To restrict access to the bucket objects so that it is only possible via the CloudFront distribution, you can use Origin Access Control (OAC).

Origin Access Control (OAC) allows us to protect S3 origins and, unlike its predecessor Origin Access Identity (OAI), it is compatible with all S3 buckets in all AWS regions. Additionally, it supports encryption via AWS KMS and allows dynamic requests (such as PUT and DELETE) to Amazon S3.

To implement Origin Access Control (OAC), for the specific origin you want to protect, simply create a new origin access control instead of using a public access origin, and update the bucket policy of the S3 bucket by adding the statement provided by CloudFront, which has the following structure:

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<Bucket Name>/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::<Account ID>:distribution/<Distribution ID>"
                }
            }
        }
    ]
}

Restrict Access with VPC Origins

Until recently, CloudFront only allowed configuring public origins. That is, if you wanted to place a load balancer or an EC2 instance behind a CloudFront distribution, these had to have a DNS resolvable to a public IP address.

At the end of 2024, AWS introduced CloudFront Virtual Private Cloud (VPC) Origins, a feature that allows assigning private load balancers or private EC2 instances located in private subnets within a VPC as origins. They no longer need to be public!

To implement VPC Origins, simply create a new VPC Origin in CloudFront, specifying the ARN of the private ELB or the private EC2 instance. The security group associated with these private resources must continue to allow access from CloudFront IP addresses.

Although you could allow incoming access from the Internet —since it is not a public resource— if you want to prevent other private resources within the same VPC from accessing the origin and ensure that only CloudFront has access, it is highly recommended to use prefix lists. See the following section for guidance.

AWS-Managed Prefix Lists

When you need to allow access to the same set of IP addresses across multiple security groups, instead of manually adding each IP address to all groups, you can create a prefix list. In this case, we are talking about a customer-managed prefix list, meaning it is our responsibility to keep the list of IP addresses up to date.

On the other hand, a common need when working with resources inside a VPC is to limit incoming or outgoing traffic only to certain AWS services. Although it is possible to obtain the list of public IP addresses for each service, these change constantly, and maintaining them manually would be complex and error-prone. For this purpose, AWS offers AWS-managed prefix lists, which are automatically maintained and updated by AWS, allowing you to filter IP addresses for various services such as Amazon CloudFront, Amazon DynamoDB, Amazon S3, among others.

As mentioned in the previous section, if we want to allow traffic to our resources in a VPC only from CloudFront IP addresses, we can leverage the AWS-managed prefix list corresponding to Amazon CloudFront. To do this, simply specify the Prefix List (pl) as the source or destination in the security group rules.

This feature is extremely useful when working with origins inside a VPC. However, if the origin is On-Premises, whether with hybrid connectivity to AWS via a Site-to-Site VPN or AWS Direct Connect, or even fully disconnected from AWS and accessible via a public IP address, it is not possible to use prefix lists. For these scenarios, see the following section.

AWS IP Address Ranges

As mentioned in the previous section, it is indeed possible to obtain the list of public IP addresses for each AWS service. While in a VPC we can leverage prefix lists, when working in On-Premises environments outside of AWS, we are required to use the list of AWS public IP addresses.

For this, AWS maintains its list of public IP addresses updated in JSON format in the ip-ranges.json file. Using the IP addresses from this list, you can configure your On-Premises firewall. But you might now be wondering: how will I keep my firewall updated if Amazon’s IP addresses change constantly?

Don’t worry, Amazon thought of that and created an SNS topic you can subscribe to in order to receive notifications about updates to the ip-ranges.json file. The ARN of the topic is: arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged. You just need to subscribe to the topic and develop a small local automation that processes the notifications and updates your On-Premises firewall rules as needed.

CloudFront Geographic Restrictions

This section is simple. You can enhance the security of your origin by configuring geographic restrictions on your distribution, as long as they fit your use case.

To do this, CloudFront allows you to implement an allow list or block list on your distribution and specify all the countries you need to allow or block.

CloudFront Field-Level Encryption

This section covers a specific use case that occurs when, within the request made by the client to CloudFront, a payload is included containing multiple fields, some of which hold sensitive data. Fields with sensitive data should only be visible to the final destination, while any intermediate network or compute resources should see these fields encrypted. However, we cannot encrypt the entire request, as this use case requires that intermediate resources can still view all other non-sensitive fields without issues.

This is where field-level encryption comes into play. Suppose the client sends a request whose payload contains both non-sensitive fields and sensitive fields, such as PII, PHI, confidential information, credentials, among others. Between CloudFront and the final destination, there are multiple intermediate resources, none of which should be able to see the sensitive data, although they still need to process the non-sensitive fields. In this scenario, we implement field-level encryption provided by CloudFront.

To implement field-level encryption, we simply need to create an encryption profile in CloudFront, which should specify the data fields to encrypt and the public key that will be used for such encryption, previously stored in CloudFront. On the other hand, the final destination, for example, an application server, must have the corresponding private key and be configured to decrypt the encrypted fields. Only the final server possesses the private key, thus protecting the confidentiality of sensitive data from intermediate resources without limiting the processing of non-sensitive data in the same request.

CloudFront Origin Shield

Origin Shield is an additional cache layer that can help reduce the load on your origin and, thereby, protect its availability. Primary use cases include scenarios with users across different geographic regions or when working with multiple CDNs.

Origin Shield improves cache hit rates, decreases origin load, and optimizes network performance. The flow of a request in CloudFront without Origin Shield passes through the Edge Locations, then the Regional Edge Caches, and finally reaches the origin. In this case, multiple regions might be querying the origin unnecessarily. To avoid this, by enabling Origin Shield, an additional layer is placed between the Regional Edge Caches and the origin, so that only Origin Shield sends requests to the origin, thus reducing its load.

To use Origin Shield, within your distribution select the origin, enable Origin Shield, and choose the AWS region where you want it deployed.

AWS WAF Core Protections

CloudFront has direct integration with AWS WAF and allows you to add a basic security layer with a single click, which in the background creates a Web ACL with the default protection your application needs.

The default WAF protection for CloudFront includes defense against common vulnerabilities such as those in the OWASP Top 10, SQL injections, rate limiting, and blocking traffic from malicious IP addresses based on Amazon’s threat intelligence. However, if you consider it necessary —and in fact it is recommended— customize your Web ACL according to your requirements and add additional rules you deem appropriate to strengthen your origin’s security.

CloudFront Origin Groups

This feature, technically, is not a security measure, but one of resilience, yet I want to mention it because I have tested it and find it particularly interesting.

As you know, CloudFront is a global service, but the origins probably are not. That is, in the event of a regional outage or an availability zone failure, the application could stop responding, even if the CloudFront distribution itself is unaffected.

To handle these situations, CloudFront Origin Groups allows us to configure a failover solution easily. We only need to create an Origin Group specifying multiple origins and the failover criteria, i.e., the HTTP Status Codes that CloudFront must receive to trigger failover to another origin located in a different region.

In this way, CloudFront Origin Groups allows us to maintain high availability in the event of a regional failure: the same global distribution remains active, simply redirecting requests to another origin within the group, but located in a different region.

Lessons Learned

Never forget to restrict access to origins. In most cases, when you implement CloudFront, the distribution should be the only one with access to the origin. For this reason, it is common to implement all defense mechanisms on the CloudFront distribution; however, if you do not restrict access to the origin, it will remain vulnerable to threats that you probably had not considered because you focused solely on protecting the distribution. 😶

If you need to implement AWS WAF for your application, you should almost always attach the Web ACL to the CloudFront distribution, rather than, for example, to the ALB origin. It always makes more sense to apply WAF at the distribution level so that traffic is filtered as high up as possible, thus reducing the load and cost of data processing on the ALB. 😎

I recommend using georestriction whenever possible and, of course, when it applies to your use case. In my experience, depending on your region, georestriction can be one of the simplest ways to prevent undesired traffic from scraping bots, since this type of traffic usually originates from specific countries. 🤖

Conclusion

Amazon CloudFront includes multiple built-in security features that allow us to protect origins, covering failover, firewall, georestriction, additional caching layers, field-level encryption, and most importantly, origin access restriction. All of this allows us to consolidate various perimeter-level protection mechanisms in the CloudFront distribution, thereby strengthening the security posture of our applications through a defense-in-depth strategy.

What’s Next

In the next section, you will find official AWS resources and documentation for the built-in security features of Amazon CloudFront mentioned in this article, in case you want to continue learning or dive deeper to evaluate if they really apply to your use case.

I also invite you to implement these built-in CloudFront security features in your own AWS account. Share in the comments what you thought of this article or if you discovered something interesting about any Amazon CloudFront feature during your implementation. ✍🏻

For me, a next step will be to test the integration of AWS Shield Advanced with CloudFront in the future, as I have not yet had the opportunity to see AWS Shield’s DDoS mitigation logic applied to CloudFront in action.

Official Resources

Protege tu aplicación web On-Premises con AWS WAF: Guía paso a paso

Cristhian Becerra — Fri, 24 Oct 2025 03:15:24 +0000

TL;DR: Este artículo te guiará en la implementación de AWS WAF para tus aplicaciones web alojadas en servidores On-Premises. Mostraré paso a paso cómo crear los certificados SSL/TLS, desplegar una distribución de CloudFront protegida por WAF y configurar el enrutamiento DNS necesario para esta implementación, todo ello alineado con el pilar de Seguridad del AWS Well-Architected Framework. 🧱

Tiempo estimado de lectura: 15 minutos
Nivel: 300
Versión en inglés: Protect Your On-Premises Web Application with AWS WAF: A Step-by-Step Guide

Tabla de Contenidos:

Introducción
Por qué implementar AWS WAF en una aplicación web On-Premises
Qué vas a implementar
Prerrequisitos
Pasos de Implementación
- Crea los certificados SSL/TLS
- Crea la distribución de CloudFront
- Configura el enrutamiento DNS
- Restringe el acceso al servidor On-Premises
Estructura de costos
- Estimación de costos mensual
Lecciones aprendidas
Conclusión
Qué sigue
Recursos oficiales

Introducción

Si has oído hablar de AWS WAF, probablemente sepas que es un servicio de firewall de capa 7 que permite asociar un Web Application Firewall directamente a recursos de AWS como Application Load Balancer, API Gateway, CloudFront Distributions, entre otros. Sin embargo, no puede asociarse directamente a una instancia EC2, a direcciones IP específicas o a una interfaz de red ENI en particular; únicamente puede vincularse a determinados servicios de AWS.

Un día recibí la solicitud de un cliente que deseaba implementar AWS WAF para una aplicación web alojada en un servidor On-Premises expuesto mediante una dirección IP pública. El cliente aclaró que no planeaban migrar el servidor a la nube; el servidor permanecería On-Premises, pero necesitaban contar con la protección de WAF y querían saber si era posible hacerlo desde AWS. 🤔

Con un poco de creatividad, se me ocurrió una solución: desplegar una distribución de CloudFront protegida con AWS WAF, cuyo origen sería el servidor On-Premises. Tras generar algunos certificados SSL/TLS, modificar un par de registros DNS y ajustar ligeramente la configuración de la aplicación local, logré implementar esta solución con excelentes resultados y un cliente completamente satisfecho. 😎

En este artículo te explicaré por qué deberías implementar AWS WAF en tu aplicación web On-Premises, cómo lo hice yo y cómo podrías hacerlo tú.

Por qué implementar AWS WAF en una aplicación web On-Premises

Si tienes una aplicación web On-Premises y necesitas protegerla con un Web Application Firewall (WAF), pero no deseas desplegar y administrar manualmente una solución WAF local, una excelente alternativa es implementar AWS WAF.

AWS WAF es un servicio completamente gestionado por Amazon Web Services, lo que significa que tú solo necesitas definir qué reglas aplicar y a qué recurso proteger. El servicio incluye managed rules que analizan el tráfico en busca de patrones de vulnerabilidades comunes, y AWS se encarga de mantener y actualizar dichas reglas por ti. Además, puedes crear reglas personalizadas, ya sean stateful o stateless, permitir o bloquear conjuntos de direcciones IP, aplicar restricciones geográficas, crear reglas basadas en expresiones regulares (regex), entre muchas otras opciones. 🤩

Con AWS WAF, puedes ofrecer a tu aplicación web On-Premises la protección de un firewall moderno sin necesidad de aprovisionar ni administrar manualmente una infraestructura WAF local. Y si el tiempo es un factor crítico, la configuración de AWS WAF probablemente sea mucho más rápida que cualquier otra alternativa tradicional. 😏

Ya sea que busques fortalecer la seguridad de tus aplicaciones web o cumplir con requisitos de compliance, es importante que sepas cómo implementar AWS WAF en una aplicación web On-Premises.

Qué vas a implementar

Esta guía asume que cuentas con un servidor On-Premises que aloja una aplicación web expuesta en el puerto 443, con una dirección IP pública protegida por HTTPS mediante un certificado SSL/TLS, y accesible desde un dominio (por ejemplo, www) a través de un registro DNS tipo A.

Partiendo de este punto de inicio, realizaremos lo siguiente:

Crear dos certificados SSL/TLS: uno para configurar en CloudFront y otro para instalar en el servidor On-Premises.
Instalar el certificado SSL/TLS correspondiente en el servidor On-Premises.
Crear una distribución CloudFront, configurada con su certificado SSL/TLS correspondiente, cuyo origen será un dominio que apunte al servidor On-Premises.
Configurar un registro DNS tipo CNAME para dirigir todo el tráfico del dominio hacia CloudFront.
Configurar un registro DNS tipo A para dirigir el tráfico desde CloudFront hacia el servidor On-Premises.
Configurar la aplicación On-Premises para aceptar únicamente tráfico proveniente de CloudFront.

Al finalizar esta implementación, contaremos con una cadena de resolución y redirección similar al siguiente flujo:

Dominio: www.midominio.com
DNS de la distribución de CloudFront
Distribución CloudFront protegida por AWS WAF
Dominio: origen.midominio.com
Dirección IP pública del servidor On-Premises

Prerrequisitos

Para esta implementación de AWS WAF, se requiere contar con los siguientes prerrequisitos:

Acceso a una cuenta de AWS.
Permisos IAM en la cuenta de AWS para utilizar los servicios Amazon CloudFront, AWS WAF, Amazon Route 53 y AWS ACM.
Acceso administrativo al Authoritative DNS Provider (Cloudflare o Amazon Route 53).
Acceso a un servidor On-Premises que aloje una aplicación web expuesta en el puerto 443, con una dirección IP pública.
- Acceso para la creación de certificados SSL/TLS emitidos por una Certificate Authority (CA) pública, por ejemplo, la misma CA que emitió el certificado actualmente instalado en el servidor On-Premises.
- Permisos para instalar el certificado en el servidor On-Premises.
- Permisos para editar la configuración de la aplicación On-Premises.

Pasos de Implementación

Las siguientes secciones ofrecen una guía paso a paso para la implementación de AWS WAF en un servidor On-Premises, mostrando cómo se integran cada uno de los componentes, tales como los certificados SSL/TLS de ACM y de una CA pública, los registros DNS de Amazon Route 53, la distribución de CloudFront y la ACL web de AWS WAF, con el fin de implementar WAF en nuestra aplicación web On-Premises y garantizar que todo el tráfico sea enrutado de forma segura a través de AWS.

Crea los certificados SSL/TLS

Crea e instala el certificado para el servidor On-Premises

Para iniciar con esta implementación, necesitamos crear un nuevo certificado para el servidor On-Premises. Como se mencionó anteriormente, se asume que la comunicación hacia tu servidor ya estaba protegida mediante HTTPS, utilizando un certificado SSL/TLS instalado previamente para el hostname principal, por ejemplo, www.midominio.com.

1. Siguiendo el mismo método que utilizaste originalmente para generar el certificado previo con una CA pública, adquiere ahora un certificado válido para origen.midominio.com, ya sea con la misma CA pública o con otra de tu preferencia.

2. Luego, realiza la instalación del nuevo certificado SSL/TLS en la misma ruta donde se encontraba el certificado previo. Asegúrate de que la instalación se haya completado correctamente.

3. Para validar que la instalación del certificado sea correcta, puedes utilizar herramientas en línea como sslshopper.com o sslchecker.com para verificar el hostname origen.midominio.com. El certificado debe ser válido para dicho hostname y no estar expirado.

Crea el certificado para CloudFront

1. En la consola de AWS, navega al servicio AWS Certificate Manager y haz clic en el botón Request a Certificate.

2. En la sección Certificate Type, asegúrate de que Request a public certificate esté seleccionado y haz clic en Next.

3. En la sección Domain names, ingresa tu dominio principal, por ejemplo, www.midominio.com. En la sección Validation method, asegúrate de que DNS validation esté seleccionado y haz clic en Request.

Nota: ¿viste la sección Allow export? Es una funcionalidad relativamente nueva en AWS, y permite exportar certificados públicos emitidos por Amazon, incluyendo su llave privada, para que puedas instalarlos donde desees, por ejemplo, en un servidor On-Premises. Es decir, en el paso anterior, en lugar de usar otra CA pública, también podríamos haber utilizado AWS Certificate Manager para obtener el certificado destinado a nuestro servidor On-Premises. 😮

4. El certificado ha sido creado, pero se encuentra en un estado de validación pendiente. Para que ACM pueda verificar que realmente somos los propietarios del dominio especificado en el certificado, debemos crear un registro CNAME en el Authoritative DNS Provider.

En mi caso, estoy utilizando Amazon Route 53 para gestionar mi dominio, por lo que simplemente puedo hacer clic en el botón Create records in Route 53.
Si gestionas tu dominio en otro Authoritative DNS Provider, entonces deberás crear manualmente el registro CNAME utilizando el CNAME name y el CNAME value que se detallan en la sección Domains.

5. Finalmente, el certificado de AWS Certificate Manager debería pasar del estado Pending validation al estado Issued. Con esto confirmamos que el certificado se ha emitido correctamente en ACM.

Crea la distribución de CloudFront

1. En la consola de AWS, navega al servicio Amazon CloudFront y haz clic en el botón Create a CloudFront distribution.

2. En la sección Distribution options, completa el campo Distribution name y, para este caso de uso, asegúrate de que el Distribution type seleccionado sea Single website or app.

3. En la sección Custom domain:

Si el dominio en cuestión está siendo gestionado por Amazon Route 53 dentro de la misma cuenta de AWS donde estás creando la distribución de CloudFront, añade el dominio y haz clic en Check Domain.
Si gestionas ese dominio en otro Authoritative DNS Provider o en Route 53 de otra cuenta AWS, no te preocupes, podrás añadir el custom domain en un paso posterior.

4. Haz clic en Next.

5. En la sección Origin type, dado que nuestro origen es un servidor On-Premises, selecciona Other.

6. En la sección Origin, especifica origen.midominio.com como Custom origin y deja vacío el campo Origin path.

7. En la sección Settings:

En Origin settings, personaliza los parámetros si lo deseas o utiliza la configuración recomendada.
En Cache settings, selecciona Customize cache settings y, para Origin request policy, elige AllViewer. Si lo deseas, personaliza otros parámetros.

8. Haz clic en Next.

9. En la sección Enable Security, selecciona Enable security protections. Si aplica a tu caso de uso, activa SQL protection y Rate limiting. Esto creará una ACL web de AWS WAF con protección básica y la asociará a la distribución de CloudFront.

10. Haz clic en Next.

11. Como se mencionó en el paso 3, si el dominio está gestionado por Route 53 en la misma cuenta de AWS y lo especificaste previamente, en la sección Get TLS certificate se intentará encontrar automáticamente un certificado de ACM válido para dicho dominio. En mi caso, se encontró exitosamente el certificado que creé anteriormente.

Si el dominio está siendo gestionado en otro Authoritative DNS Provider o en Route 53 de otra cuenta AWS, no te preocupes, podrás añadir el certificado TLS en un paso posterior.

12. Haz clic en Next.

13. Revisa los detalles de la distribución y haz clic en Create distribution.

14. La distribución de CloudFront comenzará a desplegarse. En la columna Last modified, podrás ver que se encuentra en estado Deploying.

15. Como se mencionó en los pasos 3 y 11, si gestionas tu dominio en otro Authoritative DNS Provider o en Route 53 de otra cuenta AWS, dirígete a la sección Settings y haz clic en Edit.

16. En la sección General, especifica tu dominio en Alternate domain name (CNAME) y selecciona el certificado de ACM creado previamente en Custom SSL certificate. Luego, haz clic en Save changes.

17. Una vez la distribución haya terminado de desplegarse, en Last modified podrás ver el timestamp completo de la última modificación. Si el Alternate domain name y el Custom SSL certificate están configurados correctamente, habrás completado exitosamente la creación y configuración de la distribución de CloudFront.

18. Copia el Distribution domain name.

Configura el enrutamiento DNS

En mi caso, estoy gestionando mi dominio con Amazon Route 53, pero tú puedes crear estos registros DNS en el Authoritative DNS Provider que estés utilizando.

Crea el registro CNAME

1. Si el dominio en cuestión está siendo gestionado por Amazon Route 53 dentro de la misma cuenta de AWS donde estás creando la distribución de CloudFront, aprovecha y crea un registro DNS de tipo Alias, apuntando tu dominio principal www.midominio.com hacia la distribución de CloudFront.

2. Si el dominio está siendo gestionado en otro Authoritative DNS Provider o en Route 53 de otra cuenta AWS, crea un registro DNS de tipo CNAME, apuntando tu dominio principal www.midominio.com al Distribution domain name de CloudFront.

Crea el registro A

3. Crea un registro DNS de tipo A apuntando tu nuevo subdominio origen.midominio.com a la dirección IP pública de tu servidor On-Premises.

Con esto, habrás completado la configuración DNS necesaria. Sin embargo, aún no hemos terminado: si intentas acceder ahora a tu servidor mediante www.midominio.com y origen.midominio.com, ambos intentos serán exitosos, pero hay un detalle importante — origen.midominio.com no está protegido por WAF y, por ende, sigue siendo vulnerable. Mitigaremos este riesgo en el siguiente paso.

¿Cómo puedes darte cuenta fácilmente de si www.midominio.com y origen.midominio.com están protegidos por WAF o no? Yo utilizo una extensión de Google Chrome llamada Wappalyzer, que permite identificar las tecnologías empleadas en cualquier sitio web. Por ejemplo, al probar mis dominios, Wappalyzer detectó que el dominio www utiliza Amazon CloudFront como CDN y Amazon Web Services como PaaS, mientras que el dominio origen no utiliza ninguno de estos servicios. Esto confirma que el tráfico hacia el dominio origen no pasa por CloudFront y, por lo tanto, no es inspeccionado por AWS WAF. ⚠️

Restringe el acceso al servidor On-Premises

Ahora debemos restringir el acceso al servidor On-Premises de tal manera que solo el tráfico que pase por CloudFront —y que haya sido inspeccionado por AWS WAF— sea aceptado por el servidor.

Para ello, tenemos dos opciones:

Hacer que CloudFront envíe un encabezado HTTP personalizado adicional con un valor secreto al origen, y que este último solo acepte el tráfico que contenga dicho encabezado con el valor secreto correcto.
Configurar el firewall del servidor On-Premises para que únicamente acepte tráfico proveniente de las direcciones IP de CloudFront especificadas en el archivo ip-ranges.json.

Dado que la segunda opción potencialmente implicaría actualizar las reglas del firewall On-Premises cada vez que Amazon modifique el archivo ip-ranges.json, me inclino más por la primera alternativa, que de hecho es la opción recomendada por Amazon cuando se requiere restringir el acceso a un Application Load Balancer.

1. En la consola de AWS, selecciona la distribución de CloudFront. En la pestaña Origins, selecciona el origen configurado y haz clic en Edit.

2. En la sección Settings, dentro de Add custom header, haz clic en Add header y añade un encabezado HTTP personalizado. El valor de este encabezado debe ser secreto y no debe exponerse públicamente. Guarda los cambios.

Ahora CloudFront añadirá este encabezado HTTP en todas las solicitudes que envíe al origen.

3. Finalmente, configura el servidor web On-Premises para que acepte solicitudes únicamente si contienen el encabezado HTTP personalizado de CloudFront con el valor secreto correcto.

Con esto hemos completado la implementación de AWS WAF para una aplicación web On-Premises mediante CloudFront, restringiendo el acceso por otros medios y garantizando que todo el tráfico hacia el servidor On-Premises sea inspeccionado de forma segura. 🔍

Estructura de costos

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

Amazon CloudFront (distribución, Price Class “Use all edge locations”)
- Costo por salida de datos hacia Internet (primera capa): ~ USD 0,085 por GB para Estados Unidos/México/Canadá/Europa.
- Costo por solicitudes HTTP/HTTPS: para USA se cita ~ USD 0,01 por cada 10 000 solicitudes (~ USD 0,000001 por solicitud) según guía reciente.
- Nota: Hay un nivel gratuito de 1 TB de salida + 10 millones de solicitudes/mes para CloudFront.
AWS WAF (Web ACL asociada a CloudFront)
- Costo de Web ACL: USD 5/mes por Web ACL.
- Costo por regla dentro de la Web ACL: USD 1/mes por regla.
- Costo por solicitudes inspeccionadas: USD 0,60 por cada millón de solicitudes.
Amazon Route 53 (Zona alojada + registros)
- Costo por hosted zone pública: USD 0,50/mes para las primeras 25 hosted zones.
- Costo adicional por registros (si se tienen más de 10 000 por zona): USD 0,0015/mes por registro adicional.
- Costo de consultas DNS estándar: ~ USD 0,40 por millón de consultas (primer 1 B de consultas).
AWS Certificate Manager (ACM Certificate para FQDN)
- Si es un certificado público gestionado por ACM, el uso con servicios integrados (como CloudFront) no tiene costo adicional.
- Si fuese un certificado exportable o wildcard habría tarifas, pero en este caso un FQDN usando CloudFront → costo estimado = USD 0/mes.

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

Estimación de costos mensual

Tomando como referencia mi implementación con los siguientes supuestos:

Región us-east-1
Datos salientes (egress) desde CloudFront: 1 000 GB/mes
Solicitudes al CloudFront: 10 millones de solicitudes/mes
Una Web ACL en AWS WAF, asociada a la distribución
Una hosted zone en Route 53 con un registro A + un registro CNAME
Un certificado ACM para un FQDN
No otras reglas avanzadas, no certificado wildcard, no consultas DNS masivas.

Cálculos:

CloudFront — datos de salida
- 1 000 GB × USD 0,085/GB = USD 85,00/mes
CloudFront — solicitudes
- 10 millones de solicitudes → (10 000 000 / 10 000) × USD 0,01 = 1 000 × USD 0,01 = USD 10,00/mes
WAF — Web ACL
- USD 5,00/mes (una Web ACL)
WAF — reglas
- Suponiendo solo 1 regla para simplificar → USD 1,00/mes
WAF — solicitudes inspeccionadas
- 10 millones de solicitudes × (USD 0,60 por millón) = 10 × USD 0,60 = USD 6,00/mes
Route 53 — hosted zone
- USD 0,50/mes (una zona pública)
Route 53 — registros
- Solo 2 registros (A + CNAME) → ninguno adicional sobre el umbral → USD 0,00 extra
Route 53 — consultas DNS
- Suponiendo un uso modesto (por ejemplo, ~100 000 consultas) → 0,1 millones × USD 0,40 = USD 0,04 (aproximadamente). Para simplicidad redondeamos a ≈ USD 0,05/mes
ACM — certificado público integrado
- USD 0,00/mes

Total estimado:

Componente	Costo estimado mensual (USD)
CloudFront — datos de salida	85,00
CloudFront — solicitudes	10,00
WAF — Web ACL	5,00
WAF — reglas	1,00
WAF — solicitudes inspeccionadas	6,00
Route 53 — hosted zone	0,50
Route 53 — registros	0,00
Route 53 — consultas DNS	0,05
ACM — certificado	0,00
Total estimado	~ USD 107,55

Lecciones aprendidas

En mi experiencia, al crear los certificados, especifica el FQDN exacto que utilizarás. No emplees wildcard a menos que realmente lo necesites, ya que los certificados wildcard suelen tener un costo significativamente mayor y, en la mayoría de los casos, no se aprovechan al 100%. 💰

La protección de WAF que implementé para CloudFront en esta guía incluye defensa frente a vulnerabilidades comunes como las del OWASP Top 10, SQL injections, rate limiting, y bloqueo de tráfico proveniente de direcciones IP maliciosas basadas en la inteligencia de amenazas de Amazon. Sin embargo, si lo consideras necesario —y de hecho es lo recomendado—, personaliza tu ACL web según tus requerimientos y añade las reglas adicionales que estimes convenientes para proteger tu servidor On-Premises.

Por favor, asegúrate de restringir el acceso al servidor On-Premises únicamente a través de CloudFront, ya que, de lo contrario, el servidor permanecerá expuesto, sin inspección ni protección por parte de WAF, y por tanto vulnerable a ataques por otras rutas de acceso. 🥲

Te recomiendo renovar el valor secreto del encabezado HTTP personalizado de CloudFront al menos una vez al año, como medida preventiva ante posibles filtraciones de seguridad. ⏱️

Conclusión

En conclusión, aunque tengamos una aplicación web alojada en un servidor On-Premises que no podamos migrar a la nube, de forma sencilla el servicio gestionado AWS WAF nos permite implementar el firewall que necesitamos en forma de una ACL web con las reglas adecuadas, ya sea utilizando reglas administradas por Amazon o creando reglas personalizadas según nuestro caso de uso.

De esta manera, podemos inspeccionar y filtrar todo el tráfico entrante hacia nuestro servidor On-Premises, garantizando que únicamente el tráfico analizado por AWS WAF sea procesado, fortaleciendo así la postura de seguridad de la aplicación. 🥳

Qué sigue

Te invito también a realizar esta implementación en tu propia cuenta de AWS. Cuéntame en los comentarios qué te pareció esta guía o si descubriste algo interesante durante tu implementación. ✍🏻

Recursos oficiales

Protect Your On-Premises Web Application with AWS WAF: A Step-by-Step Guide

Cristhian Becerra — Fri, 24 Oct 2025 03:15:22 +0000

TL;DR: This article will guide you through implementing AWS WAF for your web applications hosted on On-Premises servers. I’ll show step by step how to create SSL/TLS certificates, deploy a CloudFront distribution protected by WAF, and configure the necessary DNS routing for this implementation, all aligned with the Security pillar of the AWS Well-Architected Framework. 🧱

Estimated reading time: 15 minutes
Level: 300
Spanish version: Protege tu aplicación web On-Premises con AWS WAF: Guía paso a paso

Introduction
Why Implement AWS WAF in an On-Premises Web Application
What You Are Going to Implement
Prerequisites
Implementation Steps
- Create the SSL/TLS Certificates
- Create the CloudFront Distribution
- Configure DNS Routing
- Restrict Access to the On-Premises Server
Cost Structure
- Monthly Cost Estimate
Lessons Learned
Conclusion
What’s Next
Official Resources

Introduction

If you’ve heard about AWS WAF, you probably know that it’s a layer 7 firewall service that allows you to associate a Web Application Firewall directly with AWS resources such as Application Load Balancer, API Gateway, CloudFront Distributions, among others. However, it cannot be directly associated with an EC2 instance, specific IP addresses, or a particular ENI network interface; it can only be linked to certain AWS services.

One day I received a request from a client who wanted to implement AWS WAF for a web application hosted on an On-Premises server exposed through a public IP address. The client clarified that they did not plan to migrate the server to the cloud; the server would remain On-Premises, but they needed WAF protection and wanted to know if it was possible to achieve this from AWS. 🤔

With a bit of creativity, I came up with a solution: deploying a CloudFront distribution protected by AWS WAF, with the origin being the On-Premises server. After generating a few SSL/TLS certificates, modifying a couple of DNS records, and slightly adjusting the configuration of the local application, I managed to implement this solution with excellent results and a completely satisfied client. 😎

In this article, I’ll explain why you should implement AWS WAF for your On-Premises web application, how I did it, and how you could do it too.

Why Implement AWS WAF in an On-Premises Web Application

If you have an On-Premises web application and need to protect it with a Web Application Firewall (WAF) but don’t want to deploy and manage a local WAF solution manually, an excellent alternative is to implement AWS WAF.

AWS WAF is a fully managed service by Amazon Web Services, which means you only need to define which rules to apply and which resource to protect. The service includes managed rules that analyze traffic for patterns of common vulnerabilities, and AWS takes care of maintaining and updating those rules for you. In addition, you can create custom rules, whether stateful or stateless, allow or block sets of IP addresses, apply geographical restrictions, create rules based on regular expressions (regex), among many other options. 🤩

With AWS WAF, you can provide your On-Premises web application with the protection of a modern firewall without the need to provision or manually manage a local WAF infrastructure. And if time is a critical factor, configuring AWS WAF is likely to be much faster than any other traditional alternative. 😏

Whether you’re looking to strengthen the security of your web applications or comply with regulatory requirements, it’s important to know how to implement AWS WAF in an On-Premises web application.

What You Are Going to Implement

This guide assumes that you have an On-Premises server hosting a web application exposed on port 443, with a public IP address protected by HTTPS through an SSL/TLS certificate, and accessible from a domain (for example, www) via a DNS A record.

Starting from this point, we will perform the following:

Create two SSL/TLS certificates: one to configure in CloudFront and another to install on the On-Premises server.
Install the corresponding SSL/TLS certificate on the On-Premises server.
Create a CloudFront distribution, configured with its corresponding SSL/TLS certificate, whose origin will be a domain pointing to the On-Premises server.
Configure a DNS CNAME record to route all domain traffic to CloudFront.
Configure an DNS A record to route traffic from CloudFront to the On-Premises server.
Configure the On-Premises application to accept traffic only from CloudFront.

By the end of this implementation, we will have a resolution and redirection chain similar to the following flow:

Domain: www.mydomain.com
DNS of the CloudFront distribution
CloudFront distribution protected by AWS WAF
Domain: origin.mydomain.com
Public IP address of the On-Premises server

Prerequisites

For this AWS WAF implementation, the following prerequisites are required:

Access to an AWS account.
IAM permissions in the AWS account to use Amazon CloudFront, AWS WAF, Amazon Route 53, and AWS ACM.
Administrative access to the Authoritative DNS Provider (Cloudflare or Amazon Route 53).
Access to an On-Premises server that hosts a web application exposed on port 443, with a public IP address.
- Access to create SSL/TLS certificates issued by a public Certificate Authority (CA), for example, the same CA that issued the certificate currently installed on the On-Premises server.
- Permissions to install the certificate on the On-Premises server.
- Permissions to edit the configuration of the On-Premises application.

Implementation Steps

The following sections provide a step-by-step guide for implementing AWS WAF on an On-Premises server, showing how each of the components integrates, such as the SSL/TLS certificates from ACM and a public CA, the DNS records in Amazon Route 53, the CloudFront distribution and the AWS WAF web ACL, in order to implement WAF on our On-Premises web application and ensure that all traffic is routed securely through AWS.

Create the SSL/TLS Certificates

Create and install the certificate for the On-Premises server

To begin this implementation, we need to create a new certificate for the On-Premises server. As mentioned earlier, it is assumed that communication to your server was already protected via HTTPS, using an SSL/TLS certificate previously installed for the main hostname, for example, www.mydomain.com.

1. Following the same method you originally used to generate the previous certificate with a public CA, now obtain a valid certificate for origin.mydomain.com, either with the same public CA or another one of your choice.

2. Then, install the new SSL/TLS certificate in the same path where the previous certificate was located. Make sure the installation has been completed successfully.

3. To validate that the certificate installation is correct, you can use online tools such as sslshopper.com or sslchecker.com to verify the hostname origin.mydomain.com. The certificate must be valid for that hostname and not expired.

Create the certificate for CloudFront

1. In the AWS console, navigate to the AWS Certificate Manager service and click the Request a Certificate button.

2. In the Certificate Type section, make sure Request a public certificate is selected and click Next.

3. In the Domain names section, enter your main domain, for example, www.mydomain.com. In the Validation method section, make sure DNS validation is selected and click Request.

Note: Did you see the Allow export section? It’s a relatively new feature in AWS that allows exporting public certificates issued by Amazon, including their private key, so you can install them wherever you want — for example, on an On-Premises server. This means that in the previous step, instead of using another public CA, we could have also used AWS Certificate Manager to obtain the certificate intended for our On-Premises server. 😮

4. The certificate has been created but is in a pending validation state. For ACM to verify that we truly own the domain specified in the certificate, we must create a CNAME record in the Authoritative DNS Provider.

In my case, I’m using Amazon Route 53 to manage my domain, so I can simply click the Create records in Route 53 button.
If you manage your domain in another Authoritative DNS Provider, then you must manually create the CNAME record using the CNAME name and CNAME value listed in the Domains section.

5. Finally, the AWS Certificate Manager certificate should move from the Pending validation state to the Issued state. This confirms that the certificate has been successfully issued in ACM.

Create the CloudFront Distribution

1. In the AWS console, navigate to the Amazon CloudFront service and click the Create a CloudFront distribution button.

2. In the Distribution options section, fill in the Distribution name field and, for this use case, make sure the Distribution type selected is Single website or app.

3. In the Custom domain section:

If the domain in question is being managed by Amazon Route 53 within the same AWS account where you are creating the CloudFront distribution, add the domain and click Check Domain.
If you manage that domain in another Authoritative DNS Provider or in Route 53 under a different AWS account, don’t worry — you’ll be able to add the custom domain in a later step.

4. Click Next.

5. In the Origin type section, since our origin is an On-Premises server, select Other.

6. In the Origin section, specify origin.mydomain.com as the Custom origin and leave the Origin path field empty.

7. In the Settings section:

Under Origin settings, customize the parameters if you wish, or use the recommended configuration.
Under Cache settings, select Customize cache settings, and for Origin request policy, choose AllViewer. Customize other parameters if you wish.

8. Click Next.

9. In the Enable Security section, select Enable security protections. If it applies to your use case, enable SQL protection and Rate limiting. This will create an AWS WAF web ACL with basic protection and associate it with the CloudFront distribution.

10. Click Next.

11. As mentioned in step 3, if the domain is managed by Route 53 in the same AWS account and you previously specified it, the Get TLS certificate section will automatically attempt to find a valid ACM certificate for that domain. In my case, it successfully found the certificate I created earlier.

If the domain is being managed by another Authoritative DNS Provider or in Route 53 under a different AWS account, don’t worry — you’ll be able to add the TLS certificate in a later step.

12. Click Next.

13. Review the distribution details and click Create distribution.

14. The CloudFront distribution will begin deploying. In the Last modified column, you’ll see that it’s in the Deploying state.

15. As mentioned in steps 3 and 11, if you manage your domain in another Authoritative DNS Provider or in Route 53 under a different AWS account, go to the Settings section and click Edit.

16. In the General section, specify your domain in Alternate domain name (CNAME) and select the ACM certificate you created earlier under Custom SSL certificate. Then click Save changes.

17. Once the distribution has finished deploying, under Last modified you’ll see the full timestamp of the latest modification. If the Alternate domain name and Custom SSL certificate are correctly configured, you’ve successfully completed the creation and setup of your CloudFront distribution.

18. Copy the Distribution domain name.

Configure DNS Routing

In my case, I’m managing my domain with Amazon Route 53, but you can create these DNS records in whichever Authoritative DNS Provider you’re using.

Create the CNAME record

1. If the domain in question is managed by Amazon Route 53 within the same AWS account where you’re creating the CloudFront distribution, take advantage and create a DNS record of type Alias, pointing your main domain www.mydomain.com to the CloudFront distribution.

2. If the domain is managed in another Authoritative DNS Provider or in Route 53 from another AWS account, create a DNS CNAME record, pointing your main domain www.mydomain.com to the Distribution domain name of CloudFront.

Create the A record

3. Create a DNS A record pointing your new subdomain origin.mydomain.com to the public IP address of your On-Premises server.

With this, you’ll have completed the necessary DNS configuration. However, we’re not done yet: if you try to access your server now via www.mydomain.com and origin.mydomain.com, both attempts will succeed, but there’s an important detail — origin.mydomain.com is not protected by WAF and therefore remains vulnerable. We’ll mitigate this risk in the next step.

How can you easily tell whether www.mydomain.com and origin.mydomain.com are protected by WAF or not? I use a Google Chrome extension called Wappalyzer, which allows you to identify the technologies used on any website. For example, when testing my domains, Wappalyzer detected that the www domain uses Amazon CloudFront as a CDN and Amazon Web Services as PaaS, while the origin domain uses neither of these services. This confirms that traffic to the origin domain does not pass through CloudFront and therefore is not inspected by AWS WAF. ⚠️

Restrict Access to the On-Premises Server

Now we need to restrict access to the On-Premises server so that only traffic that passes through CloudFront — and has been inspected by AWS WAF — is accepted by the server.

To achieve this, we have two options:

Have CloudFront send an additional custom HTTP header with a secret value to the origin, and configure the origin to only accept traffic that contains this header with the correct secret value.
Configure the On-Premises server firewall to accept traffic only from CloudFront IP ranges specified in the ip-ranges.json file.

Since the second option would potentially require updating the On-Premises firewall rules every time Amazon modifies the ip-ranges.json file, I lean toward the first alternative, which is actually Amazon’s recommended option when you need to restrict access to an Application Load Balancer.

1. In the AWS console, select the CloudFront distribution. In the Origins tab, select the configured origin and click Edit.

2. In the Settings section, under Add custom header, click Add header and add a custom HTTP header. The value of this header must be secret and not publicly exposed. Save the changes.

Now CloudFront will add this HTTP header to all requests it sends to the origin.

3. Finally, configure the On-Premises web server to only accept requests that contain the custom HTTP header from CloudFront with the correct secret value.

With this, we’ve completed the implementation of AWS WAF for an On-Premises web application through CloudFront, restricting access through other means and ensuring that all traffic to the On-Premises server is securely inspected. 🔍

Cost Structure

The costs to consider in this implementation are as follows:

Amazon CloudFront (distribution, Price Class “Use all edge locations”)
- Data transfer out to the Internet (first tier): ~ USD 0.085 per GB for United States/Mexico/Canada/Europe.
- HTTP/HTTPS request cost: for the USA it’s quoted at ~ USD 0.01 per 10,000 requests (~ USD 0.000001 per request) according to a recent guide.
- Note: There’s a free tier of 1 TB of data transfer out + 10 million requests/month for CloudFront.
AWS WAF (Web ACL associated with CloudFront)
- Web ACL cost: USD 5/month per Web ACL.
- Cost per rule inside the Web ACL: USD 1/month per rule.
- Cost per inspected request: USD 0.60 per million requests.
Amazon Route 53 (Hosted Zone + records)
- Cost per public hosted zone: USD 0.50/month for the first 25 hosted zones.
- Additional cost per record (if you have more than 10,000 per zone): USD 0.0015/month per additional record.
- Standard DNS query cost: ~ USD 0.40 per million queries (first 1B queries).
AWS Certificate Manager (ACM Certificate for FQDN)
- If it’s a public certificate managed by ACM, usage with integrated services (such as CloudFront) has no additional cost.
- If it were an exportable or wildcard certificate, there would be fees, but in this case a single FQDN using CloudFront → estimated cost = USD 0/month.

It’s worth mentioning that the prices listed correspond to October 2025. 💲

Monthly Cost Estimate

Using my implementation as a reference with the following assumptions:

Region us-east-1
Outbound data (egress) from CloudFront: 1,000 GB/month
Requests to CloudFront: 10 million requests/month
One Web ACL in AWS WAF associated with the distribution
One hosted zone in Route 53 with one A record + one CNAME record
One ACM certificate for one FQDN
No advanced rules, no wildcard certificate, no massive DNS queries.

Calculations:

CloudFront — data transfer out
- 1,000 GB × USD 0.085/GB = USD 85.00/month
CloudFront — requests
- 10 million requests → (10,000,000 / 10,000) × USD 0.01 = 1,000 × USD 0.01 = USD 10.00/month
WAF — Web ACL
- USD 5.00/month (one Web ACL)
WAF — rules
- Assuming only 1 rule for simplicity → USD 1.00/month
WAF — inspected requests
- 10 million requests × (USD 0.60 per million) = 10 × USD 0.60 = USD 6.00/month
Route 53 — hosted zone
- USD 0.50/month (one public zone)
Route 53 — records
- Only 2 records (A + CNAME) → none above threshold → USD 0.00 extra
Route 53 — DNS queries
- Assuming modest use (for example, ~100,000 queries) → 0.1 million × USD 0.40 = USD 0.04 (approximately). For simplicity, rounded to ≈ USD 0.05/month
ACM — integrated public certificate
- USD 0.00/month

Estimated Total:

Component	Estimated Monthly Cost (USD)
CloudFront — data transfer out	85.00
CloudFront — requests	10.00
WAF — Web ACL	5.00
WAF — rules	1.00
WAF — inspected requests	6.00
Route 53 — hosted zone	0.50
Route 53 — records	0.00
Route 53 — DNS queries	0.05
ACM — certificate	0.00
Estimated Total	~ USD 107.55

Lessons Learned

In my experience, when creating certificates, specify the exact FQDN you will use. Do not use wildcards unless you truly need them, as wildcard certificates tend to be significantly more expensive and, in most cases, are not fully utilized. 💰

The WAF protection I implemented for CloudFront in this guide includes defense against common vulnerabilities such as those listed in the OWASP Top 10, SQL injections, rate limiting, and blocking traffic from malicious IP addresses based on Amazon’s threat intelligence. However, if you deem it necessary—and in fact, it is recommended—customize your web ACL according to your requirements and add any additional rules you consider appropriate to protect your On-Premises server.

Please make sure to restrict access to the On-Premises server exclusively through CloudFront; otherwise, the server will remain exposed, without inspection or protection by WAF, and therefore vulnerable to attacks through other access paths. 🥲

I recommend renewing the secret value of the custom CloudFront HTTP header at least once a year as a preventive measure against potential security leaks. ⏱️

Conclusion

In conclusion, even if we have a web application hosted on an On-Premises server that we cannot migrate to the cloud, the managed service AWS WAF allows us to easily implement the firewall we need in the form of a web ACL with the appropriate rules, whether by using managed rules provided by Amazon or by creating custom rules tailored to our use case.

This way, we can inspect and filter all incoming traffic to our On-Premises server, ensuring that only traffic analyzed by AWS WAF is processed, thus strengthening the security posture of the application. 🥳

What’s Next

In the following section, you will find the official resources and documentation for the mentioned services, along with some interesting points related to the discussed topics, in case you want to continue learning or explore further to determine if they apply to your use case.

I also invite you to implement this solution in your own AWS account. Let me know in the comments what you thought of this guide or if you discovered something interesting during your implementation. ✍🏻

Official Resources

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

Cristhian Becerra — Mon, 13 Oct 2025 23:15:50 +0000

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. 🛡️

Tiempo estimado de lectura: 20 minutos
Nivel: 300
Versión en inglés: How to Implement AWS Network Firewall in a Multi-Account Architecture Using Transit Gateway

Tabla de Contenidos:

Introducción
Por qué implementar AWS Network Firewall
Qué vas a construir
Prerrequisitos
Pasos de Implementación
- Configura el Transit Gateway
- Construye la VPC de Ingreso
- Construye la VPC de Inspección
- Construye la VPC de Egreso
- Construye las VPCs de Carga de Trabajo
- Configura AWS Network Firewall
Revisa la Arquitectura Final
- Valida Conectividad e Inspección de Tráfico
Bonus: Attachment de Transit Gateway de Network Firewall
Estructura de costos
- Estimación de costos mensual
Lecciones Aprendidas
Conclusión
Qué sigue
Recursos oficiales

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).

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

Crea un Transit Gateway con configuración predeterminada.
Crea dos tablas de enrutamiento de Transit Gateway:
- tgw-default-association-rtb
- tgw-default-propagation-rtb
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
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
(Opcional) Crea un TGW Flow Log para el Transit Gateway para monitorear y registrar el tráfico que fluye a través de él.

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

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
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.
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

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

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.

Construye la VPC de Inspección

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)
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.
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.
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.
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
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
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.

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

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

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

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

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

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
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.
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.
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

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

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.

Construye las VPCs de Carga de Trabajo

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)
Crea un Transit Gateway attachment entre el Transit Gateway y la VPC, seleccionando los IDs de Subred de las 3 subredes de conectividad TGW.
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
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
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.

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

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

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.

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.
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.

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

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

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

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.

¿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

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.
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.
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".

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.
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.
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
La Tabla de Enrutamiento de Propagación Predeterminada del Transit Gateway permanecerá sin cambios en este escenario.

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

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

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.

Recursos oficiales

How to Implement AWS Network Firewall in a Multi-Account Architecture Using Transit Gateway

Cristhian Becerra — Mon, 13 Oct 2025 23:15:46 +0000

TL;DR: This article will guide you through the implementation of AWS Network Firewall in a multi-account, highly available architecture (spanning 3 Availability Zones) in conjunction with a Transit Gateway to connect VPCs across different accounts within an AWS Organizations structure. The architecture follows a Hub & Spoke pattern, where the Hub Account is the Networking account, and the Spoke accounts include Development, QA, Production, and DevOps. 🛡️

Estimated reading time: 20 minutes
Level: 300
Spanish version: Cómo implementar AWS Network Firewall en una arquitectura multicuenta utilizando Transit Gateway

Introduction
Why Implement AWS Network Firewall
What You're Going to Build
Prerequisites
Implementation Steps
- Set Up the Transit Gateway
- Build the Ingress VPC
- Build the Inspection VPC
- Build the Egress VPC
- Build the Workload VPCs
- Configure the AWS Network Firewall
Review the Final Architecture
- Validate Connectivity and Traffic Inspection
Bonus: Network Firewall Transit Gateway Attachment
Cost Structure
- Monthly Cost Estimate
Lessons Learned
Conclusion
What's Next
Official Resources

Introduction

When I had to implement AWS Network Firewall for the first time at work, I’ll be honest — I was a bit nervous. I thought it would be more complex. However, the implementation turned out to be relatively straightforward if you’re comfortable with networking and routing.

Even so, my initial network configurations for deploying Network Firewall were neither the best nor the most organized, but eventually, I got there — a proper and well-structured implementation of AWS Network Firewall, aligned with AWS’s recommended best practices. 🥳

And honestly, I’d like others to avoid making the same mistakes when setting up AWS Network Firewall for the first time — especially when it comes to routing, which was the most challenging part for me — and to lose the fear of the service and networking in general. That’s why I’m writing this article: to share how to properly configure the network and routing, or at least, how I did it myself.

To give a bit of context, in a multi-account environment, AWS Network Firewall plays an important role by providing centralized network protection, enabling consistent security controls and traffic inspection across all accounts.

This implementation follows a model of centralized ingress, centralized egress, and centralized inspection, ensuring that inbound, outbound, and inter-VPC traffic is securely routed through a single inspection layer managed by the Networking account.

Why Implement AWS Network Firewall

You probably already know about several types of firewalls in AWS, such as Security Groups (SGs), Network Access Control Lists (NACLs), and the Web Application Firewall (WAF) — and you might be wondering: why do I need yet another firewall service?

Well, AWS Network Firewall is a more robust service designed to solve a different use case. Let’s start by clarifying that AWS WAF can only be deployed on specific AWS services like ALB, API Gateway, and CloudFront, but not openly on any Elastic Network Interface (ENI).

On the other hand, Security Groups and Network ACLs exist independently within each VPC, each with its own decentralized security rules, which can become increasingly difficult to manage over time.

Imagine you have multiple VPCs, or even several AWS accounts, and you need to apply the same stateless and stateful firewall rules across all of them. It wouldn’t make much sense to repeatedly deploy the same SGs, NACLs, and WAFs in every VPC or account, right? And even if you did, maintaining and managing those configurations would quickly become chaotic. 😵

Moreover, both SGs and NACLs have a relatively small limit on the number of rules they support, and as mentioned earlier, WAF only works with specific services. So, how do we solve this?

That’s where AWS Network Firewall comes in. This service allows you to deploy a firewall in the form of a virtual service, with its own ENIs, where you can route all inbound and outbound traffic to be inspected before reaching its final destination. This gives you all the benefits of stateless and stateful firewalls, from Layer 3 to Layer 7. 🤩

And while, as an alternative, you could deploy your own security appliance —or a third-party one— behind a Gateway Load Balancer for inspection, the difference is that, in that case, you would be fully responsible for managing it, whereas AWS Network Firewall is a fully managed AWS service that offers many valuable features.

In summary, Security Groups and NACLs may be sufficient at a small scale, with just a few VPCs, but as your environment grows and you start managing multiple VPCs and AWS accounts, you’ll want —or even need— to centralize your network inspection. And that’s exactly why you should learn how to implement AWS Network Firewall.

Here’s a comparison table between the different types of firewalls in AWS, to help you better understand the differences among them.

	Security Group	Network ACL	WAF	AWS Network Firewall
Protection at	EC2 instance level	Subnet level	Endpoint level (ALB, CloudFront, etc.)	VPC level based on routes
Stateful or Stateless	Stateful	Stateless	Stateless	Both
OSI layer	Layer 3/4	Layer 3/4	Layer 7	Layer 3–7
Features	IP, Port, Protocol filtering	IP, Port, Protocol filtering	Application layer filtering	Stateless/ACL L3 rules, stateful/L4 rules, IPS–IDS/L7 rules, FQDN filtering, Protocol detection, Large IP lists
Flows	All ingress/egress flows at instance level	All ingress/egress flows at subnet level	Ingress only from internet to API Gateway, ALB, CloudFront	All ingress/egress flows at perimeter of VPC (e.g., IGW, VGW, DX, VPN, VPC–VPC)

What You’re Going to Build

As I mentioned earlier, the implementation is not particularly complex, but it does require a solid foundation in networking and routing. When this guide says “Create a Transit Gateway,” it assumes you already know how to do that. And while this guide does not include ready-to-deploy Infrastructure as Code, it does provide a detailed step-by-step list appropriate for this level. Most importantly, it covers the routing configuration — which, in my experience, is the most challenging part. 😉

This implementation consists of five components you’ll be building:

AWS Transit Gateway shared through AWS RAM and connected to all VPCs.
Ingress VPC with an Internet Gateway for centralized inbound connectivity.
Inspection VPC with AWS Network Firewall deployed in high availability, using the VPC or TGW attachment type for centralized inspection.
Egress VPC with NAT Gateways in high availability for centralized outbound connectivity.
Workload VPCs for Development, QA, Production, and DevOps environments.

Don’t worry if you can’t fully visualize the solution yet. In the implementation steps section, you’ll find architecture diagrams for each of these five components, as well as the final diagram of the complete solution.

Prerequisites

For this implementation, it’s recommended to have multiple AWS accounts and the appropriate permissions in each of them.

If you don’t yet have multiple accounts, you can create them using AWS Organizations and access them through IAM Identity Center instead of individual IAM users, if you prefer.

If you don’t have access to multiple AWS accounts, you can deploy all the VPCs within a single account; in that case, you should simply skip the step of sharing the Transit Gateway through AWS RAM.

You’ll need permissions for Amazon VPC, AWS Transit Gateway, AWS RAM, AWS Network Firewall, and optionally CloudWatch Logs, EC2, and Session Manager, among others, to perform the actions described in this guide.

I’ll be deploying in the N. Virginia (us-east-1) region, and the following diagram shows what my multi-account structure looks like at the beginning: one account dedicated to network resources (Hub) and four accounts for workloads (Spoke).

Implementation Steps

The following sections provide a step-by-step walkthrough of the network setup process, showing how each component, including the Transit Gateway, shared VPCs, workload VPCs, and AWS Network Firewall, integrates to create a secure and scalable foundation for inter-account connectivity and inspection.

Set Up the Transit Gateway

Create a Transit Gateway with default settings.
Create two transit gateway route tables:
- tgw-default-association-rtb
- tgw-default-propagation-rtb
Modify the Transit Gateway and assign:
- tgw-default-association-rtb as the Default Association Route Table
- tgw-default-propagation-rtb as the Default Propagation Route Table
In AWS RAM, create a Resource Share with:
- The newly created Transit Gateway as the Shared resource
- The Spoke accounts as the Shared principals
(Optional) Create a TGW Flow Log for the Transit Gateway to monitor and log the traffic flowing through it.

Notes for Subnet Creation and Availability Zone Selection:

Connectivity Subnet Creation: When creating a VPC that will have connectivity with the Transit Gateway (TGW), it is recommended to create a /28 subnet exclusively to host the Elastic Network Interfaces (ENIs) deployed by TGW. This follows best practices for efficient resource management.
AZ Selection: Choose the same Availability Zone (AZ) ID, rather than the AZ name, to avoid charges for inter-zone traffic. For example, in this case, we are using use1-az1, use1-az2, use1-az4. It's important to note that us-east-1a and us-east-1b are unique aliases for each AWS account. To ensure that you deploy your resources in the same AZ, use AZ IDs instead of aliases.
Network Firewall Support: AWS Network Firewall is not supported in us1-az3, which is why we chose to use use1-az4 instead.
AZ Identification: It is recommended to add the AZ ID in the name tag of the subnet and associated route table, and any associated network appliances for easy identification and management.

Build the Ingress VPC

Create a VPC (e.g., named ingress VPC, CIDR 10.20.0.0/20) with:
- 3 public subnets (e.g., /22)
- 3 private subnets for TGW connectivity (/28)
- 1 Internet Gateway
Create a Transit Gateway attachment between the Transit Gateway and the Ingress VPC, selecting the Subnet IDs of the 3 TGW connectivity subnets.
Configure the TGW Connectivity Subnet Route Table (this route table will only have a local route):
- ingress-vpc-tgw-connectivity-rtb
  
  Destination Target Description
  
  10.20.0.0/20 local Ingress VPC

Configure the Public Subnet Route Table (this route table needs a 0.0.0.0/0 route to the Internet Gateway and routes to the CIDRs of the Spoke VPCs to go through the TGW attachment):

ingress-vpc-public-rtb

Destination	Target	Description
`10.20.0.0/20`	`local`	Ingress VPC
`10.21.0.0/16`	`tgw`	Development VPC
`10.22.0.0/16`	`tgw`	QA VPC
`10.23.0.0/16`	`tgw`	Production VPC
`10.24.0.0/16`	`tgw`	DevOps VPC
`0.0.0.0/0`	`igw`	Internet access

Optional: Create a VPC Flow Log for the VPC to monitor and log the traffic flowing through the Ingress VPC.

Build the Inspection VPC

Create a VPC (e.g., named inspection VPC, CIDR 10.20.16.0/20) with:
- 3 private subnets for Network Firewall (e.g., /22)
- 3 private subnets for TGW connectivity (/28)
Create a Transit Gateway attachment between the Transit Gateway and the Inspection VPC, selecting the Subnet IDs of the 3 TGW connectivity subnets. Enable Appliance Mode Support.
- Note: Enabling Appliance Mode on the Transit Gateway attachment ensures that all traffic from a session flows through the same firewall in the same Availability Zone, preventing inter-AZ traffic from being inspected by the firewall. This setting is important to maintain consistent traffic inspection and improve performance in multi-AZ architectures.
Manually edit the Transit Gateway Route Tables:
- Remove the propagation of the Inspection VPC attachment in the TGW Default Propagation Route Table.
- Remove the association of the Inspection VPC attachment in the TGW Default Association Route Table.
- Associate the TGW Default Propagation Route Table with the Inspection VPC Attachment.
- In the TGW Default Association Route Table, create a static route to 0.0.0.0/0 towards the Inspection VPC Attachment.
In the AWS Network Firewall console:
- Choose Create firewall.
- In Describe firewall: Add a name and (optionally) a description.
- In Attachment Type: Choose VPC and select the Inspection VPC.
- In Firewall subnets: Select the 3 private subnets (not the connectivity subnets).
- In Associate Firewall Policy: Choose Create and associate an empty firewall policy and specify a new firewall policy name.
- Create the firewall; this will take a few minutes.
Configure the TGW Connectivity Subnet Route Tables (one per AZ). In each route table, add a route to its corresponding AWS Network Firewall VPC endpoint (of type Gateway Load Balancer Endpoint) per AZ:
- inspection-vpc-tgw-connectivity-rtb-use1-az1
  
  Destination Target Description
  
  10.20.16.0/20 local Inspection VPC
  
  0.0.0.0/0 nfw-use1-az1 Firewall endpoint for use1-az1
- inspection-vpc-tgw-connectivity-rtb-use1-az2
  
  Destination Target Description
  
  10.20.16.0/20 local Inspection VPC
  
  0.0.0.0/0 nfw-use1-az2 Firewall endpoint for use1-az2
- inspection-vpc-tgw-connectivity-rtb-use1-az4
  
  Destination Target Description
  
  10.20.16.0/20 local Inspection VPC
  
  0.0.0.0/0 nfw-use1-az4 Firewall endpoint for use1-az4
Configure the Private Subnet Route Table (this route table needs a 0.0.0.0/0 route to the Transit Gateway attachment):
- inspection-vpc-private-rtb
  
  Destination Target Description
  
  10.20.16.0/20 local Inspection VPC
  
  0.0.0.0/0 tgw Transit Gateway
Optional: Create a VPC Flow Log for the VPC to monitor and log the traffic flowing through the Inspection VPC.

Destination	Target	Description
`10.20.16.0/20`	`local`	Inspection VPC
`0.0.0.0/0`	`nfw-use1-az1`	Firewall endpoint for use1-az1

Destination	Target	Description
`10.20.16.0/20`	`local`	Inspection VPC
`0.0.0.0/0`	`nfw-use1-az2`	Firewall endpoint for use1-az2

Destination	Target	Description
`10.20.16.0/20`	`local`	Inspection VPC
`0.0.0.0/0`	`nfw-use1-az4`	Firewall endpoint for use1-az4

Destination	Target	Description
`10.20.16.0/20`	`local`	Inspection VPC
`0.0.0.0/0`	`tgw`	Transit Gateway

After having implemented the Inspection VPC multiple times, AWS finally released a new feature for AWS Network Firewall: the Transit Gateway Firewall Attachment. With this feature, the firewall connects directly to the Transit Gateway, removing the need for an Inspection VPC. Interested? Check out the Bonus section below. 😀

Build the Egress VPC

Create a VPC (e.g., named egress VPC, CIDR 10.20.32.0/20) with:
- 3 public subnets (e.g., /22)
- 3 private subnets for TGW connectivity (/28)
- 1 Internet Gateway
- 1 NAT Gateway per AZ for high availability
Create a Transit Gateway attachment between the Transit Gateway and the Egress VPC, selecting the Subnet IDs of the 3 TGW connectivity subnets.
Manually edit the Transit Gateway Route Tables:
- In the TGW Default Propagation Route Table, create a static route to 0.0.0.0/0 towards the Egress VPC Attachment.
Configure the TGW Connectivity Subnet Route Tables (create one route table per AZ, and in each table add a 0.0.0.0/0 route to its corresponding NAT Gateway):
- egress-vpc-tgw-connectivity-rtb-use1-az1
  
  Destination Target Description
  
  10.20.32.0/20 local Egress VPC
  
  0.0.0.0/0 natgw-use1-az1 NAT for use1-az1
- egress-vpc-tgw-connectivity-rtb-use1-az2
  
  Destination Target Description
  
  10.20.32.0/20 local Egress VPC
  
  0.0.0.0/0 natgw-use1-az2 NAT for use1-az2
- egress-vpc-tgw-connectivity-rtb-use1-az4
  
  Destination Target Description
  
  10.20.32.0/20 local Egress VPC
  
  0.0.0.0/0 natgw-use1-az4 NAT for use1-az4

Configure the Public Subnet Route Table (this route table needs a 0.0.0.0/0 route to the Internet Gateway and routes to the CIDRs of the Spoke VPCs to go through the TGW attachment):

egress-vpc-public-rtb

Destination	Target	Description
`10.20.32.0/20`	`local`	Egress VPC
`10.21.0.0/16`	`tgw`	Development VPC
`10.22.0.0/16`	`tgw`	QA VPC
`10.23.0.0/16`	`tgw`	Production VPC
`10.24.0.0/16`	`tgw`	DevOps VPC
`0.0.0.0/0`	`igw`	Internet access

Optional: Create a VPC Flow Log for the VPC to monitor and log the traffic flowing through the Egress VPC.

Build the Workload VPCs

Create a VPC (e.g., named development VPC, CIDR 10.21.0.0/16) with:
- 3 private subnets for workloads (e.g., /20)
- 3 private subnets for TGW connectivity (/28)
Create a Transit Gateway attachment between the Transit Gateway and the VPC, selecting the Subnet IDs of the 3 TGW connectivity subnets.
Configure the TGW Connectivity Subnet Route Table — this route table will only have a local route:
- development-vpc-tgw-connectivity-rtb
  
  Destination Target Description
  
  10.21.0.0/16 local Development VPC
Configure the Private Subnet Route Table — add a 0.0.0.0/0 route to the Transit Gateway attachment:
- development-vpc-private-rtb
  
  Destination Target Description
  
  10.21.0.0/16 local Development VPC
  
  0.0.0.0/0 tgw Transit Gateway
Optional: Create a VPC Flow Log for the VPC to monitor and log the traffic flowing through the Workload VPC.

Destination	Target	Description
`10.21.0.0/16`	`local`	Development VPC

Destination	Target	Description
`10.21.0.0/16`	`local`	Development VPC
`0.0.0.0/0`	`tgw`	Transit Gateway

This is the diagram corresponding to the Development VPC, but as I mentioned earlier, I have four accounts dedicated to workloads. Therefore, I repeated this same step for the QA VPC (CIDR 10.22.0.0/16), the Production VPC (CIDR 10.23.0.0/16), and the DevOps VPC (CIDR 10.24.0.0/16).

Configure the AWS Network Firewall

This article primarily focuses on configuring the base network architecture and the routing required to use Network Firewall. But at a high level, AWS Network Firewall is a managed service that allows you to protect your network by filtering traffic to and from your VPCs. It provides a stateful firewall and intrusion detection and prevention system that can be deployed inline with your network traffic, inspecting and filtering packets in real time.

In the Firewall, enable Alert and Flow logging, and configure CloudWatch as the log destination by creating the necessary log groups.
Optional: Edit the previously created empty Firewall Policy to:
- Add AWS Managed rule groups
- Create and add Stateless rule groups
- Create and add Stateful rule groups

Review the Final Architecture

The deployed architecture follows a centralized inspection model using AWS Transit Gateway and AWS Network Firewall to control and monitor traffic between shared and workload VPCs.

The Transit Gateway Default Association Route Table should look like this:
- tgw-default-association-rtb
  
  CIDR Attachment Resource Type Route Type
  
  0.0.0.0/0 Inspection VPC VPC Static

CIDR	Attachment	Resource Type	Route Type
`0.0.0.0/0`	Inspection VPC	VPC	Static

The Transit Gateway Default Propagation Route Table should look like this:

tgw-default-propagation-rtb

CIDR	Attachment	Resource Type	Route Type
`10.21.0.0/16`	Development VPC	VPC	Propagated
`10.22.0.0/16`	QA VPC	VPC	Propagated
`10.23.0.0/16`	Production VPC	VPC	Propagated
`10.24.0.0/16`	DevOps VPC	VPC	Propagated
`10.20.0.0/20`	Ingress VPC	VPC	Propagated
`10.20.32.0/20`	Egress VPC	VPC	Propagated
`0.0.0.0/0`	Egress VPC	VPC	Static

If the route tables do not appear as expected, detach and remove any incorrect associations or propagations, then re-associate and re-propagate the attachments with the appropriate route tables until the tables reflect the correct configuration.

The following architecture diagram illustrates the final multi-account setup, where traffic from the spoke accounts (Development, QA, Production, and DevOps) is routed through the centralized inspection layer in the Networking account.

Is the diagram not displaying in high resolution? No worries — you can download the architecture diagram in PDF format to view it in more detail. 🔍

Validate Connectivity and Traffic Inspection

Optionally, deploy EC2 instances in the Workload VPCs in private workload subnets across different accounts.
- Connect using Session Manager and try to ping between the private IPs of the instances.
- Ensure the security groups allow inbound ICMP and outbound HTTPS (443) to the internet (for Session Manager).
- The pings should be successful.
Optionally, deploy a client VPN such as OpenVPN or WireGuard on an EC2 instance in a public subnet in the Ingress VPC.
- Connect through the VPN and try to ping the private IPs of the EC2 instances in the Workload VPCs.
- Ensure the security groups allow inbound ICMP.
- The pings should be successful.
Check the CloudWatch Log Groups to verify the Flow type Firewall logs. You should see that all test traffic is successfully passing through the Network Firewall.
- The Alert type Log Group should be empty for now, since the Firewall Policy has not been configured yet or the test traffic does not match any alert rules.

Bonus: Network Firewall Transit Gateway Attachment

During re:Inforce 2025, AWS announced the new Network Firewall Transit Gateway Attachment feature, which replaces the traditional “Inspection VPC” pattern, simplifying deployment and improving traffic visibility.

Instead of step "4. Create Inspection VPC", you would do "4. Create Network Firewall Transit Gateway Attachment".

In the AWS Network Firewall console:
1. Select Create firewall.
2. In Describe firewall: Add a Firewall name and description (optional).
3. In Attachment Type: Choose Transit Gateway and select the Transit Gateway.
4. In Availability Zones: Select the 3 Availability Zones you have been working with.
5. In Associate Firewall Policy: Select Create and associate an empty firewall policy and specify a new firewall policy name.
6. Create the Firewall; it will take a few minutes.
Manually edit the Transit Gateway Route Tables:
1. Remove the propagation of the Network Firewall TGW attachment in the TGW Default Propagation Route Table.
2. Remove the association of the Network Firewall TGW attachment in the TGW Default Association Route Table.
3. Associate the TGW Default Propagation Route Table with the Network Firewall TGW Attachment.
4. In the TGW Default Association Route Table, create a static route to 0.0.0.0/0 towards the new Network Firewall TGW Attachment.
The Transit Gateway Default Association Route Table will look as follows:
- tgw-default-association-rtb
  
  CIDR Attachment Resource Type Route Type
  
  0.0.0.0/0 AWS Network Firewall Firewall Static
The Transit Gateway Default Propagation Route Table will remain unchanged in this scenario.

CIDR	Attachment	Resource Type	Route Type
`0.0.0.0/0`	AWS Network Firewall	Firewall	Static

Cost Structure

The costs to consider in this implementation are as follows:

AWS Transit Gateway (TGW)
- Hourly cost per VPC attachment: ~ USD 0.05 per hour for each attachment.
- Data processing cost: ~ USD 0.02 per GB processed.
AWS Network Firewall (NFW)
- Hourly cost per endpoint (active): ~ USD 0.395 per hour in the U.S.
- Data processing cost: ~ USD 0.065 per GB of inspected traffic.
NAT Gateway (NATGW)
- Hourly cost: ~ USD 0.045 per NAT Gateway
- Data processing cost: ~ USD 0.045 per GB of data passing through the NAT Gateway
Data Transfer (egress / inter-AZ / inter-region, etc.)
- Internet egress: standard egress rates (~ USD 0.09/GB for the first volumes, etc.)
- Cross-Availability Zone transfer (cross-AZ): ~ USD 0.01/GB
- Other transfer charges apply depending on source and destination.

It’s worth mentioning that the prices listed correspond to October 2025.💲

Monthly Cost Estimate

Based on my implementation and assuming minimal traffic, the cost structure would include the following components:

7 Transit Gateway attachments
3 NAT Gateways for high availability
3 Network Firewall endpoints for high availability
Modest inspection and outbound traffic, say 500 GB/month (as a starting point)

Calculations:

Transit Gateway — attachments
- 7 attachments × USD 0.05/hour = USD 0.35/hour
- Monthly hours (~ 24 × 30 = 720 h) → 0.35 × 720 = USD 252/month
Transit Gateway — data processing
- Assuming all 500 GB go through TGW: 500 × 0.02 = USD 10/month
Network Firewall — endpoints
- 3 endpoints × USD 0.395/hour = USD 1.185/hour
- 1.185 × 720 hours = USD 853.20/month
Network Firewall — data processing
- 500 GB × USD 0.065 = USD 32.50/month
NAT Gateways — hourly
- 3 NATGWs × USD 0.045/hour = USD 0.135/hour
- 0.135 × 720 = USD 97.20/month
NAT Gateways — data processing
- Assuming 200 GB out of the 500 GB go to the Internet
- 200 GB × USD 0.045 = USD 9.00/month
Data transfer (egress, etc.)
- Assuming 200 GB go to the Internet
- 200 × USD 0.09 = USD 18.00/month
- Also, assume 100 GB cross-AZ → 100 × USD 0.01 = USD 1.00/month

Estimated Total:

Component	Estimated Monthly Cost (USD)
TGW — attachments	252.00
TGW — data processing	10.00
NFW — endpoints	853.20
NFW — data processing	32.50
NAT — hourly	97.20
NAT — data processing	9.00
Data transfer (egress + cross-AZ)	19.00
Estimated Total	~ USD 1,272.90

Lessons Learned

You probably just saw the cost estimate and got a little scared, right? Don’t worry — this is also due to the cost of high availability. In my example, I used 3 AZs, but your use case might not require that much availability for AWS Network Firewall, and you could deploy it in just 1 or 2 AZs since, in any case, an AZ failure is quite unlikely. 😎

If you decide to reduce the number of AZs, you should keep two important considerations in mind. The first is the Appliance Mode, mentioned earlier, which becomes especially relevant to avoid asymmetric traffic if resources are not evenly distributed across all AZs. Additionally, you should clearly understand the concepts of Fail Open and Fail Closed, which basically define the default action if all AZs where Network Firewall is deployed were to fail (which is unlikely, but could happen if you use only one AZ). Fail Open means that if Network Firewall fails, all uninspected traffic will pass freely, whereas Fail Closed means that if it fails, no traffic will pass. It’s important to evaluate the trade-off between security and availability in these scenarios and make the right decision.

On the other hand, another way to control Network Firewall costs is to enable only the necessary rules. It might be tempting to add all AWS Managed Rule Groups, but remember that each one has a cost, consumes capacity units, and not all may actually apply to your use case.

Keep in mind that the most important part of implementing AWS Network Firewall — besides blocking traffic — is that it provides actionable information and insights. In other words, the findings, metrics, and logs shouldn’t remain unused. Integrate Network Firewall with AWS Security Hub to gain high-value insights and perform remediations, or even automate them through an event-driven approach using Amazon EventBridge, AWS Lambda, or other services.

Conclusion

In conclusion, implementing AWS Network Firewall in a multi-account architecture with Transit Gateway provides a robust, scalable, and secure network infrastructure. By following the steps outlined in this article, you can effectively deploy and configure Network Firewall to protect your VPCs across different accounts within an AWS Organizations structure. The Hub & Spoke pattern, combined with the high availability of 3 Availability Zones, ensures that your network is resilient and capable of handling various traffic patterns and security requirements. Additionally, the use of VPC Flow Logs and Network Firewall logging allows for detailed monitoring and analysis of network traffic, enabling you to identify and respond to potential security threats promptly.

What’s Next

I also invite you to try this implementation in your own AWS account. Remember that if you don’t have multiple accounts, you can deploy all the VPCs within a single account and still experiment with AWS Network Firewall. Let me know in the comments what you thought of this guide or if you discovered something interesting during your implementation. ✍🏻

Although I hadn’t mentioned it before, I implemented this entire multi-account architecture using Terraform. However, the infrastructure-as-code is currently highly customized to the specific needs of the client for whom it was deployed. Later on, I’ll be modularizing and generalizing this code for different scenarios, with the goal of being able to share it with the community.

Before I go, I want to highlight the great potential of this centralized architecture based on AWS Transit Gateway. Building upon this design, we could extend it by adding a VPN connection to an on-premises corporate data center; deploying an application in a workload VPC on an EC2 instance internally exposed through a Network Load Balancer (NLB); and placing a public Application Load Balancer (ALB) in the Ingress VPC, which points to the private IP addresses of the NLB, allowing clients to access the service through the ALB’s public DNS. The following diagram illustrates, in a simple and summarized way, this possible design extension.

Official Resources

Opciones de conectividad privada de Amazon VPC: VPC Peering vs Transit Gateway vs PrivateLink

Cristhian Becerra — Sun, 12 Oct 2025 23:51:45 +0000

TL;DR: En el mundo de la computación en la nube, garantizar una comunicación segura y eficiente entre varios recursos es primordial. Amazon Web Services (AWS) ofrece varias opciones para la conectividad privada dentro y entre Nubes Privadas Virtuales (VPCs). Este artículo explora tres métodos principales: VPC Peering, AWS Transit Gateway y AWS PrivateLink. Cada método tiene sus características únicas, beneficios y casos de uso, por lo que es esencial comprender sus diferencias para elegir la solución adecuada para tus necesidades. 🙌🏻

Tiempo estimado de lectura: 15 minutos
Nivel: 200
Versión en inglés: Amazon VPC private connectivity options: VPC Peering vs Transit Gateway vs PrivateLink

Tabla de Contenidos:

Introducción
Por qué importa conocer las opciones de conectividad privada de Amazon VPC
VPC Peering
- Características clave de VPC Peering
- Limitaciones de VPC Peering
- Escenarios no válidos para VPC Peering
- Conexión VPC Peering con múltiples VPCs
AWS Transit Gateway
- Características clave de Transit Gateway
- Por qué usar Transit Gateway
- Transit Gateway con múltiples VPCs
- Transit Gateway con conexión local
- Emparejamiento de Transit Gateway entre regiones de AWS
- Consideraciones importantes para Transit Gateway
- VPC Peering vs Transit Gateway
AWS PrivateLink
- Por qué usar VPC Endpoints
- Descripción general de VPC Endpoints y PrivateLink
- VPC Endpoints impulsados por PrivateLink
- Consideraciones importantes para VPC PrivateLink
- AWS PrivateLink vs VPC Peering
Lecciones Aprendidas
Conclusión
Qué sigue
Recursos oficiales

Introducción

Si tienes dos instancias EC2 en distintas Amazon VPC, probablemente no deberían estar comunicándose mediante direcciones IP públicas. En ese caso, deberías usar VPC Peering para establecer una comunicación privada entre las VPC.

Eventualmente, cuando tu infraestructura crezca y tengas muchas VPC con la necesidad de conectarlas entre sí, la cantidad de conexiones de emparejamiento aumentará considerablemente, al igual que el esfuerzo requerido para gestionarlas. Es ahí cuando se considera usar AWS Transit Gateway para implementar un diseño Hub & Spoke más sencillo de gestionar a esa escala.

Eso parecería resolver el problema de la interconectividad privada, pero tanto VPC Peering como Transit Gateway establecen un túnel completo de comunicación bidireccional, permitiendo que cualquier ENI en la VPC A pueda comunicarse con cualquier ENI en la VPC B. Para algunos, eso podría no parecer muy seguro.

En ese punto aparece PrivateLink, que permite exponer únicamente endpoints específicos de la VPC B, de modo que la VPC A los consuma de forma unidireccional, sin permitir tráfico indiscriminado entre VPCs. Esto es particularmente importante cuando las VPC pertenecen a distintos propietarios.

¿Entonces qué? ¿Así de simple es el criterio para escoger entre estos tres servicios de AWS? Digamos que esa es la idea básica, pero es un poco más complejo que eso. En este artículo exploraremos las características clave de cada servicio y comparaciones detalladas entre ellos que probablemente te resulten útiles. 🚀

Por qué importa conocer las opciones de conectividad privada de Amazon VPC

La mayor parte de nuestro tráfico en la nube probablemente no debería pasar a través de Internet. Sin embargo, este suele ser el comportamiento predeterminado cuando comenzamos con AWS: exponemos todo mediante una dirección IP pública y consumimos endpoints públicos a través de un Internet Gateway.

Pero dirigir todo el tráfico por Internet no solo te expone desde el punto de vista de seguridad, sino que también puede implicar costos más altos que una opción privada y segura. ¿Qué? ¿Más seguridad a menor costo? Así es. 🤯

AWS ofrece varias opciones que permiten lograr esto. Por ejemplo, los Gateway Endpoints, mediante los cuales tus recursos en una VPC pueden comunicarse con servicios como Amazon S3 o Amazon DynamoDB sin costos por transferencia de datos. He visto casos de clientes cuyas instancias EC2 realizaban millones de solicitudes a S3 al mes, y créeme, el costo por transferencia de datos hacia Internet no es nada barato. Con una implementación increíblemente simple como la de los Gateway Endpoints, podrían haberse ahorrado miles de dólares en su factura de AWS.

Ahora bien, el enfoque de este artículo no son los Gateway Endpoints, sino revisar otras opciones de conectividad algo más avanzadas que te permitirán obtener beneficios principalmente en el ámbito de la seguridad y las conexiones privadas. Algunas de ellas son más seguras y privadas que otras, dependiendo siempre de tu caso de uso.

Pero mi punto es que, si no conoces estos servicios de AWS, junto con sus beneficios y limitaciones, podrías no realizar correctamente el análisis de trade-offs y terminar tomando una decisión equivocada al escoger el servicio más adecuado para tu caso. Por eso es importante conocer las opciones de conectividad privada de Amazon VPC.

VPC Peering

VPC Peering permite conectar dos VPCs de forma privada utilizando la red de AWS, haciéndolas comportarse como si estuvieran en la misma red. Esta conexión se puede establecer entre VPCs en la misma región de AWS o en regiones diferentes. Además, VPC Peering permite conexiones entre VPCs propiedad de diferentes cuentas de AWS.

Características clave de VPC Peering

Conectividad privada: Permite la comunicación privada entre VPCs.
Multirregional y multicuenta: Admite VPCs en diferentes regiones y cuentas.
CIDR no superpuestos: Las VPCs deben tener bloques CIDR no superpuestos.
Actualizaciones de la tabla de rutas: Requiere actualizar las tablas de rutas en las subredes de cada VPC para garantizar que las instancias puedan comunicarse.

Limitaciones de VPC Peering

Superposición de CIDR: Las VPCs no deben tener bloques CIDR superpuestos.
No transitivo: Las conexiones VPC Peering no son transitivas; cada VPC que necesita comunicarse debe tener una conexión de emparejamiento directa.
Una sola conexión por par de VPC: Solo se puede establecer una conexión VPC peering entre dos VPCs.
Límite de conexión: Máximo de 125 conexiones VPC peering por VPC.

Escenarios no válidos para VPC Peering

Conexión VPN o Direct Connect a la red local.
Acceso a Internet a través de un Internet Gateway de una VPC emparejada.
Acceso a Internet a través del NAT Gateway de una VPC emparejada.
Acceso a S3/DynamoDB a través de un VPC Gateway endpoint.

Conexión VPC Peering con múltiples VPCs

Cuando múltiples VPCs necesitan comunicarse entre sí utilizando el emparejamiento, debe crear una full mesh de conexiones de emparejamiento. Esto se vuelve rápidamente complejo a medida que aumenta el número de VPCs.

Esta arquitectura ya comienza a tener demasiadas conexiones de emparejamiento que gestionar, ¿cierto? Creo que ya empiezo a notar el Full Mess — perdón, Full Mesh — en la red. Será mejor pasar al siguiente servicio: AWS Transit Gateway. 😂

AWS Transit Gateway

Transit Gateway permite a los clientes interconectar miles de VPCs y redes locales en un modelo de hub-and-spoke. Simplifica la gestión de la red centralizando la conectividad.

Características clave de Transit Gateway

Attachments: Admite attachments para VPCs, conexiones de emparejamiento con otras Transit Gateways, VPNs, Direct Connect Gateways y dispositivos de red de terceros.
Características: Incluye soporte para multidifusión, MTU, modo de dispositivo, consideración de AZ y TGW Sharing.
Arquitecturas: Admite arquitecturas como inspección centralizada de tráfico, egreso centralizado y servicios compartidos.

Por qué usar Transit Gateway

Escalabilidad: Admite hasta 5000 attachments.
Conectividad híbrida: Permite la conectividad híbrida a través de VPN y Direct Connect.
Gestión simplificada: Reduce la complejidad en la gestión de múltiples conexiones VPC.

Transit Gateway con múltiples VPCs

Un Transit Gateway actúa como un enrutador central para todas las VPCs conectadas, simplificando drásticamente la gestión de la conectividad. Cada VPC solo necesita una sola conexión al TGW.

Transit Gateway con conexión local

Transit Gateway se integra con AWS Site-to-Site VPN y AWS Direct Connect para extender tu red privada a AWS de forma segura.

Emparejamiento de Transit Gateway entre regiones de AWS

Transit Gateway admite emparejamiento entre regiones, lo que le permite construir una red privada global entre regiones de AWS sin exponer el tráfico a Internet.

Consideraciones importantes para Transit Gateway

Resolución de DNS: Admite la resolución de DNS para todas las VPCs conectadas al TGW.
Compartir con RAM: Se puede compartir utilizando Resource Access Manager (RAM) entre cuentas de AWS.
Facturación: Se factura por hora, por attachment, con cargos por procesamiento de datos.
Ancho de banda: Admite hasta 50 Gbps de ancho de banda total de VPN con ECMP.
MTU: Admite una MTU de 8500 bytes para el tráfico entre VPCs y 1500 bytes para las conexiones VPN.

VPC Peering vs Transit Gateway

Característica	VPC Peering	Transit Gateway
Arquitectura	Conexión uno a uno – Full mesh	Hub and Spoke con múltiples attachments
Conectividad híbrida	No soportado	Soportado a través de VPN y Direct Connect
Complejidad	Simple para menos VPCs, Complejo a medida que aumenta el número	Simple para cualquier número de VPCs y conectividad de red híbrida
Escalabilidad	125 conexiones de emparejamiento por VPC	5000 attachments por TGW
Latencia	Más baja	Salto adicional
Ancho de banda	Sin límite	50 Gbps por attachment
Referencia de grupo de seguridad	Soportado	Soportado (solo reglas de entrada)
Conectividad de subred	Para todas las subredes a través de AZs	Solo subredes dentro de la misma AZ en la que se crea el attachment TGW
Enrutamiento transitivo	No soportado	Soportado
TCO	Más bajo – Solo costo de transferencia de datos	Costo por attachment + costo de transferencia de datos

Muy bonito todo, pero recuerda que ninguno de estos dos servicios soluciona el problema de las VPC con CIDRs superpuestos. Además, ambos establecen un túnel bidireccional muy amplio entre VPCs, y cuando conozcas el siguiente servicio, AWS PrivateLink, lo pensarás dos veces antes de elegir de inmediato uno de estos servicios para tu conectividad privada. 🧐

AWS PrivateLink

AWS PrivateLink, junto con los endpoints de VPC, permite conexiones seguras y privadas entre tu VPC y los servicios de AWS soportados, incluidos aquellos alojados por otros clientes o socios de AWS.

Por qué usar VPC Endpoints

Comunicación privada: Permite una comunicación segura entre tu VPC y los servicios de AWS sin usar Internet.
Superficie de ataque reducida: Elimina la necesidad de Internet Gateways, dispositivos NAT o VPN, minimizando la exposición.
Amplio soporte de servicios: Funciona con servicios nativos de AWS, servicios de socios y aquellos alojados por otros clientes de AWS.
Exposición controlada: Permite exponer únicamente aplicaciones o endpoints específicos, en lugar de toda la red.
Compatibilidad con CIDRs superpuestos: Soluciona el dilema de la conectividad privada entre VPCs que usan rangos de direcciones IP superpuestos.

Sin VPC Endpoints y PrivateLink

Sin PrivateLink, tu tráfico a los servicios de AWS viaja por Internet público, aunque ambos recursos residen en AWS. Esto introduce latencia adicional, exposición de seguridad y dependencia de la ruta de Internet.

Con VPC Endpoints y PrivateLink

Con PrivateLink, tu VPC (consumidora) se conecta de forma privada a servicios de AWS o de terceros (proveedores) a través de ENIs locales (Interfaces de Red Elásticas), asegurando que el tráfico permanezca dentro de la red troncal de AWS.

Descripción general de VPC Endpoints y PrivateLink

Proporcionan conectividad de red privada entre VPCs y servicios de AWS.
Eliminan la necesidad de puertas Internet Gateways o NAT Gateways.
Los endpoints son redundantes, escalables horizontalmente y altamente disponibles.
Gateway endpoint: Acceso solo a Amazon S3 y DynamoDB.
Interface endpoint: Acceso a servicios entre cuentas u otras VPCs.
Otros tipos de endpoints: Gateway Load Balancer, Resource y Service-Network.

VPC Endpoints impulsados por PrivateLink

Interface endpoint: Para acceder a servicios implementados en otras VPCs y cuentas de AWS.
Resource endpoint: Para recursos específicos.
Service-Network endpoint: Para redes de servicios de VPC Lattice.
Soporte para IPv4 e IPv6: Soporte de NAT y tráfico UDP.

Consideraciones importantes para VPC PrivateLink

Direcciones IP locales: Los endpoints de VPC crean direcciones IP locales usando ENI.
Soporte de superposición de CIDR: Puede conectar servicios dentro de VPCs con bloques CIDR superpuestos.
Alta disponibilidad: Cree endpoints de VPC en múltiples Zonas de Disponibilidad.
Grupos de seguridad: Utiliza grupos de seguridad – reglas de entrada.
Soporte de tráfico: Admite tráfico IPv4 e IPv6 sobre TCP y UDP.
Acceso desde otras redes: Puede accederse desde otras redes como VPCs emparejadas, Transit Gateway, VPN o Direct Connect.

Comunicación entre VPCs con CIDRs superpuestos

PrivateLink permite la comunicación entre VPCs que usan bloques CIDR superpuestos sin requerir cambios de enrutamiento.

Endpoint de VPC con grupo de seguridad

Los endpoints de PrivateLink están asociados con ENIs y protegidos por reglas de entrada de grupos de seguridad para un acceso controlado.

Acceso desde otras redes

Los endpoints de PrivateLink se pueden acceder desde redes externas como VPCs emparejadas, Transit Gateway, VPN y Direct Connect.

AWS PrivateLink vs VPC Peering

VPC Peering: Útil para muchos recursos que se comunican entre VPCs emparejadas.
PrivateLink: Ideal para permitir el acceso a una sola aplicación alojada en tu VPC sin emparejar las VPCs.
Superposición de CIDR: No se puede crear un emparejamiento de VPC con CIDRs superpuestos, pero PrivateLink lo admite.
Límites de conexión: Máximo de 125 conexiones de emparejamiento; sin límite en las conexiones de PrivateLink.
Origen del tráfico: El emparejamiento de VPC permite el origen de tráfico bidireccional; PrivateLink permite solo que el consumidor origine el tráfico.

Lecciones Aprendidas

En este trabajo vivirás haciendo análisis de trade-offs de manera constante. A veces, un solo servicio no será la solución perfecta para tu problema; necesitarás combinarlos o incluso ponerte creativo. 🤔

Para mí, lo más importante que me gustaría que te lleves de estas lecciones aprendidas es la importancia del costo en el análisis de trade-offs, y que, para evitar sorpresas a final de mes, nunca te olvides de los precios de cada servicio.

Porque sí, Transit Gateway puede ser una excelente opción para gestionar múltiples conexiones a gran escala, pero también implica un costo considerable por cada attachment y por cada gigabyte de tráfico procesado, mientras que VPC Peering es prácticamente gratuito.

De igual forma, podrías inclinarte por usar PrivateLink para que tus instancias EC2 consuman todos los servicios de AWS mediante endpoints privados, pero recuerda que cada endpoint tiene un costo fijo, además del costo por procesamiento de datos. Quizá te convenga usarlo solo para servicios como AWS Secrets Manager o AWS KMS, pero no necesariamente para Amazon S3 o Amazon CloudWatch, especialmente si no manejas información sensible.

Un comentario adicional: Como se mencionó anteriormente, Transit Gateway resulta útil en múltiples patrones de arquitectura centralizados, entre los cuales se encuentra el patrón de servicios compartidos. Este patrón se refiere a que, si múltiples VPC necesitan un endpoint de PrivateLink, puede que no sea la mejor idea crearlo en cada VPC, sino implementarlo en una VPC de servicios compartidos, desde la cual los consumidores accedan al endpoint de forma centralizada.

Conclusión

Elegir la opción de conectividad privada adecuada en AWS depende de sus requisitos específicos, incluyendo el número de VPCs, la necesidad de conectividad híbrida y la complejidad de tu arquitectura de red. VPC Peering es ideal para conexiones simples y directas entre un número limitado de VPCs. Transit Gateway ofrece escalabilidad y gestión simplificada para redes más grandes y complejas. AWS PrivateLink proporciona conexiones seguras y privadas a los servicios de AWS y otras VPCs, especialmente útil para el acceso a aplicaciones específicas sin el emparejamiento completo de VPC. Comprender estas opciones te ayudará a diseñar una arquitectura de red robusta, segura y eficiente en AWS.

Qué sigue

En la siguiente sección dejaré los recursos y documentos oficiales de los servicios mencionados, junto con algunos puntos interesantes sobre los temas que he tratado, por si te interesa continuar aprendiendo sobre ellos o profundizar para determinar si realmente aplican a tu caso de uso.

También te invito a desplegar y probar estos tres servicios en tu cuenta de AWS y dejarme en los comentarios qué te parecieron. Y si ya los conoces, cuéntame en los comentarios qué trade-off particular te llevó a escoger entre un servicio y otro, o qué característica descubriste que cambió radicalmente tu percepción sobre alguno de ellos. ✍🏻

Quizá has oído hablar de Amazon VPC Lattice, un servicio relativamente nuevo en comparación con los otros mencionados en este artículo, pero que está ganando cada vez más adopción como una de las opciones más modernas para la conectividad privada en Amazon VPC. Te invito a echarle un vistazo; pronto estaré probándolo y escribiendo un artículo al respecto.

Recursos oficiales

Amazon VPC private connectivity options: VPC Peering vs Transit Gateway vs PrivateLink

Cristhian Becerra — Sun, 12 Oct 2025 23:51:41 +0000

TL;DR: In the world of cloud computing, ensuring secure and efficient communication between various resources is paramount. Amazon Web Services (AWS) offers several options for private connectivity within and between Virtual Private Clouds (VPCs). This article explores three primary methods: VPC Peering, AWS Transit Gateway, and AWS PrivateLink. Each method has its unique features, benefits, and use cases, making it essential to understand their differences to choose the right solution for your needs. 🙌🏻

Estimated reading time: 15 minutes
Level: 200
Spanish version: Opciones de conectividad privada de Amazon VPC: VPC Peering vs Transit Gateway vs PrivateLink

Introduction
Why It Matters to Understand Amazon VPC Private Connectivity Options
VPC Peering
- Key Features of VPC Peering
- VPC Peering Limitations
- Invalid Scenarios for VPC Peering
- VPC Peering Connection with Multiple VPCs
AWS Transit Gateway
- Key Features of Transit Gateway
- Why Use Transit Gateway
- Transit Gateway with Multiple VPCs
- Transit Gateway with On-Premises Connection
- Transit Gateway Peering Across AWS Regions
- Important Considerations for Transit Gateway
- VPC Peering vs Transit Gateway
AWS PrivateLink
- Why Use VPC Endpoints
- VPC Endpoints and PrivateLink Overview
- VPC Endpoints Powered by PrivateLink
- Important Considerations for VPC PrivateLink
- AWS PrivateLink vs VPC Peering
Lessons Learned
Conclusion
What’s Next
Official Resources

Introduction

If you have two EC2 instances in different Amazon VPCs, they probably shouldn’t be communicating through public IP addresses. In that case, you should use VPC Peering to establish private communication between the VPCs.

Eventually, as your infrastructure grows and you have many VPCs that need to connect with each other, the number of peering connections will increase significantly, along with the effort required to manage them. That’s when you might consider using AWS Transit Gateway to implement a Hub & Spoke design that’s easier to manage at scale.

That might seem to solve the private interconnectivity problem, but both VPC Peering and Transit Gateway establish a full bidirectional communication tunnel, allowing any ENI in VPC A to communicate with any ENI in VPC B. For some, that might not seem very secure.

At that point, PrivateLink comes into play. It allows you to expose only specific endpoints from VPC B, so that VPC A can consume them in a unidirectional way, without allowing unrestricted traffic between VPCs. This is particularly important when the VPCs belong to different owners.

So what now? Is that really all there is to choosing between these three AWS services? Let’s say that’s the basic idea, but it’s a bit more complex than that. In this article, we’ll explore the key features of each service and provide detailed comparisons that you’ll likely find useful. 🚀

Why It Matters to Understand Amazon VPC Private Connectivity Options

Most of our traffic in the cloud probably shouldn’t be going through the Internet. However, this is often the default behavior when we first start with AWS: we expose everything through a public IP address and consume public endpoints via an Internet Gateway.

But routing all your traffic through the Internet not only exposes you from a security standpoint, it can also lead to higher costs compared to a private and secure option. What? More security at a lower cost? That’s right. 🤯

AWS offers several options that make this possible. For example, Gateway Endpoints allow your VPC resources to communicate with services like Amazon S3 or Amazon DynamoDB without data transfer costs. I’ve seen cases where customers had EC2 instances making millions of requests to S3 per month, and believe me, data transfer costs to the Internet aren’t cheap. With an incredibly simple implementation like Gateway Endpoints, they could have saved thousands of dollars on their AWS bill.

Now, the focus of this article isn’t on Gateway Endpoints, but rather on other, more advanced connectivity options that bring benefits mainly in the areas of security and private connections. Some of them are more secure and private than others, it always depends on your use case.

But my point is this: if you don’t know these AWS services, along with their benefits and limitations, you might fail to properly analyze the trade-offs and end up making the wrong decision when choosing the most suitable service for your case. That’s why it’s important to understand the private connectivity options available in Amazon VPC.

VPC Peering

VPC Peering allows you to connect two VPCs privately using AWS’s network, making them behave as if they were in the same network. This connection can be established between VPCs in the same AWS region or across different regions. Additionally, VPC Peering supports connections between VPCs owned by different AWS accounts.

Key Features of VPC Peering

Private Connectivity: Enables private communication between VPCs.
Cross-Region and Cross-Account: Supports VPCs in different regions and accounts.
Non-Overlapping CIDRs: VPCs must have non-overlapping CIDR blocks.
Route Table Updates: Requires updating route tables in each VPC’s subnets to ensure instances can communicate.

VPC Peering Limitations

CIDR Overlap: VPCs must not have overlapping CIDR blocks.
Non-Transitive: VPC Peering connections are not transitive; each VPC that needs to communicate must have a direct peering connection.
Single Connection per VPC Pair: Only one VPC peering connection can be established between two VPCs.
Connection Limit: Maximum of 125 VPC peering connections per VPC.

Invalid Scenarios for VPC Peering

VPN or Direct Connect connection to on-premises network.
Internet access through a peered VPC’s internet gateway.
Internet access through a peered VPC’s NAT Gateway.
Access to S3/DynamoDB through a VPC Gateway endpoint.

VPC Peering Connection with Multiple VPCs

When multiple VPCs need to communicate with each other using peering, you must create a full mesh of peering connections. This quickly becomes complex as the number of VPCs grows.

This architecture is already starting to have too many peering connections to manage, right? I think I’m beginning to notice the Full Mess — sorry, Full Mesh — in the network. It’s better to move on to the next service: AWS Transit Gateway. 😂

AWS Transit Gateway

Transit Gateway allows customers to interconnect thousands of VPCs and on-premises networks in a hub-and-spoke model. It simplifies network management by centralizing connectivity.

Key Features of Transit Gateway

Attachments: Supports attachments for VPCs, peering connections with other Transit Gateways, VPNs, Direct Connect Gateways, and third-party network appliances.
Features: Includes multicast support, MTU, appliance mode, AZ consideration, and TGW Sharing.
Architectures: Supports architectures like centralized traffic inspection, centralized egress and shared services.

Why Use Transit Gateway

Scalability: Supports up to 5000 attachments.
Hybrid Connectivity: Enables hybrid connectivity via VPN and Direct Connect.
Simplified Management: Reduces complexity in managing multiple VPC connections.

Transit Gateway with Multiple VPCs

A Transit Gateway acts as a central router for all connected VPCs, drastically simplifying connectivity management. Each VPC only needs a single attachment to the TGW.

Transit Gateway with On-Premises Connection

Transit Gateway integrates with AWS Site-to-Site VPN and *AWS Direct Connect * to extend your private network into AWS securely.

Transit Gateway Peering Across AWS Regions

Transit Gateway supports inter-region peering, allowing you to build a global private network between AWS regions without exposing traffic to the internet.

Important Considerations for Transit Gateway

DNS Resolution: Supports DNS resolution for all VPCs attached to the TGW.
RAM Sharing: Can be shared using Resource Access Manager (RAM) across AWS accounts.
Billing: Billed per hour, per attachment, with data processing charges.
Bandwidth: Supports up to 50 Gbps total VPN bandwidth with ECMP.
MTU: Supports an MTU of 8500 bytes for traffic between VPCs and 1500 bytes for VPN connections.

VPC Peering vs Transit Gateway

Feature	VPC Peering	Transit Gateway
Architecture	One-to-One connection – Full Mesh	Hub and Spoke with multiple attachments
Hybrid Connectivity	Not supported	Supported via VPN and Direct Connect
Complexity	Simple for fewer VPCs, Complex as number increases	Simple for any number of VPCs and hybrid network connectivity
Scale	125 peering connections per VPC	5000 attachments per TGW
Latency	Lowest	Additional Hop
Bandwidth	No limit	50 Gbps per attachment
Security Group Reference	Supported	Supported (Inbound rules only)
Subnet Connectivity	For all subnets across AZs	Only subnets within the same AZ in which TGW attachment is created
Transitive Routing	Not supported	Supported
TCO	Lowest – Only Data transfer cost	Per attachment cost + Data transfer cost

All very nice, but remember that neither of these two services solves the problem of VPCs with overlapping CIDRs. In addition, both establish a very broad bidirectional tunnel between VPCs, and once you get to know the next service, AWS PrivateLink, you’ll think twice before immediately choosing one of these services for your private connectivity. 🧐

AWS PrivateLink

AWS PrivateLink, in conjunction with VPC endpoints, enables secure and private connections between your VPC and supported AWS services, including those hosted by other AWS customers or partners.

Why Use VPC Endpoints

Private Communication: Enables secure communication between your VPC and AWS services without using the internet.
Reduced Attack Surface: Removes the need for Internet Gateways, NAT devices, or VPNs, minimizing exposure.
Broad Service Support: Works with AWS native services, partner services, and those hosted by other AWS customers.
Controlled exposure: Allows you to expose only specific applications or endpoints instead of the entire network.
Overlapping CIDR compatibility: Solves the dilemma of private connectivity between VPCs that use overlapping IP address ranges.

Without VPC Endpoints and PrivateLink

Without PrivateLink, your traffic to AWS services travels over the public internet, even though both resources reside in AWS. This introduces additional latency, security exposure, and reliance on internet routing.

With VPC Endpoints and PrivateLink

With PrivateLink, your VPC connects privately to AWS or third-party services via local ENIs (Elastic Network Interfaces), ensuring traffic stays within the AWS network backbone.

VPC Endpoints and PrivateLink Overview

Provide private network connectivity between VPCs and AWS services.
Eliminate the need for Internet Gateways or NAT Gateways.
Endpoints are redundant, horizontally scaled, and highly available.
Gateway Endpoint: Access Amazon S3 and DynamoDB only.
Interface Endpoint: Access services across accounts or other VPCs.
Other endpoint types: Gateway Load Balancer, Resource, and Service-Network.

VPC Endpoints Powered by PrivateLink

Interface Endpoint: For accessing services deployed in other VPCs and AWS accounts.
Resource Endpoint: For specific resources.
Service-Network Endpoint: For VPC Lattice service networks.
Support for IPv4 and IPv6: NAT and UDP traffic support.

Important Considerations for VPC PrivateLink

Local IP Addresses: VPC endpoints create local IP addresses using ENI.
Overlapping CIDR Support: Can connect services inside VPCs with overlapping CIDR blocks.
High Availability: Create VPC endpoints across multiple Availability Zones.
Security Groups: Uses Security Groups – inbound rules.
Traffic Support: Supports IPv4 and IPv6 traffic over TCP and UDP.
Access from Other Networks: Can be accessed from other networks like Peered VPCs, Transit Gateway, VPN, or Direct Connect.

VPC communication with overlapping CIDRs

PrivateLink enables communication between VPCs that use overlapping CIDR blocks without requiring routing changes.

VPC endpoint with security group

PrivateLink endpoints are associated with ENIs and protected by security group inbound rules for controlled access.

Access from Other Networks

PrivateLink endpoints can be accessed from external networks such as Peered VPCs, Transit Gateway, VPN, and Direct Connect.

AWS PrivateLink vs VPC Peering

VPC Peering: Useful for many resources communicating between peered VPCs.
PrivateLink: Ideal for allowing access to a single application hosted in your VPC without peering the VPCs.
CIDR Overlap: VPC peering cannot be created with overlapping CIDRs, but PrivateLink supports it.
Connection Limits: Maximum of 125 peering connections; no limit on PrivateLink connections.
Traffic Origin: VPC peering enables bidirectional traffic origin; PrivateLink allows only the consumer to originate traffic.

Lessons Learned

In this line of work, you’ll constantly be performing trade-off analyses. Sometimes, a single service won’t be the perfect solution to your problem; you’ll need to combine them or even get a bit creative. 🤔

For me, the most important takeaway from these lessons is the importance of cost in your trade-off analysis — and that, to avoid surprises at the end of the month, you should always keep service pricing in mind.

Because yes, Transit Gateway can be an excellent option for managing multiple large-scale connections, but it also comes with a considerable cost for each attachment and every gigabyte of processed traffic, while VPC Peering is practically free.

Likewise, you might lean toward using PrivateLink so your EC2 instances can consume all AWS services through private endpoints, but remember that each endpoint has a fixed cost plus a data processing charge. It might make sense to use it only for services like AWS Secrets Manager or AWS KMS, but not necessarily for Amazon S3 or Amazon CloudWatch, especially if you’re not handling sensitive data.

One additional comment: as mentioned earlier, Transit Gateway is useful for multiple centralized architecture patterns, one of which is the shared services pattern. This refers to situations where multiple VPCs need access to a PrivateLink endpoint. In such cases, it might not be the best idea to create the same endpoint in each VPC. Instead, you can implement it in a shared services VPC, allowing all consumers to access the endpoint from there in a centralized way.

Conclusion

Choosing the right private connectivity option in AWS depends on your specific requirements, including the number of VPCs, the need for hybrid connectivity, and the complexity of your network architecture. VPC Peering is ideal for simple, direct connections between a limited number of VPCs. Transit Gateway offers scalability and simplified management for larger, more complex networks. AWS PrivateLink provides secure, private connections to AWS services and other VPCs, especially useful for specific application access without full VPC peering. Understanding these options helps you design a robust, secure, and efficient network architecture on AWS.

What’s Next

In the next section, I’ll include the official resources and documentation for the services mentioned, along with some interesting points about the topics I’ve covered — in case you’re interested in continuing to learn about them or diving deeper to determine whether they truly apply to your use case.

I also invite you to deploy and test these three services in your own AWS account and let me know in the comments what you thought of them. And if you’re already familiar with them, share in the comments which specific trade-off led you to choose one service over another, or which feature you discovered that completely changed your perception of a particular service. ✍🏻

You may have heard of Amazon VPC Lattice, a relatively new service compared to the others mentioned in this article, but one that’s quickly gaining adoption as one of the most modern options for private connectivity in Amazon VPC. I encourage you to check it out — I’ll be testing it soon and writing an article about it.

DEV Community: Cristhian Becerra

Protege tu dominio con DNSSEC en Amazon Route 53: Guía paso a paso

Tabla de Contenidos:

Introducción

Resolución DNS Recursiva

Qué es DNSSEC

Cómo funciona DNSSEC

Resolución DNS Recursiva con DNSSEC

Por qué implementar DNSSEC

Envenenamiento de caché sin DNSSEC

Envenenamiento de caché con DNSSEC habilitado

Qué vas a implementar

Prerrequisitos

Pasos de Implementación

Configura DNSSEC en Amazon Route 53

Configura DNSSEC en Cloudflare

Configura DNSSEC en Namecheap

Valida la implementación de DNSSEC

Costo de la Implementación

Lecciones Aprendidas

Conclusión

Qué sigue

Recursos oficiales

Secure Your Domain with DNSSEC in Amazon Route 53: A Step-by-Step Guide

Table of Contents:

Introduction

Recursive DNS Resolution

What is DNSSEC

How DNSSEC Works

Recursive DNS Resolution with DNSSEC

Why Implement DNSSEC

DNS Cache Poisoning without DNSSEC

DNS Cache Poisoning with DNSSEC Enabled

What You Are Going to Implement

Prerequisites

Implementation Steps

Configure DNSSEC in Amazon Route 53

Configure DNSSEC in Cloudflare

Configure DNSSEC in Namecheap

Validate the DNSSEC Implementation

Implementation Cost

Lessons Learned

Conclusion

What’s Next

Official Resources

Protege los orígenes de Amazon CloudFront con funcionalidades de seguridad integradas: Mejores prácticas de AWS

Tabla de Contenidos:

Introducción

Por qué proteger los orígenes de Amazon CloudFront

Funcionalidades de seguridad integradas de CloudFront

Restricción del acceso al Application Load Balancer

Restricción del acceso a un origen de Amazon S3

Restricción del acceso con orígenes de la VPC

Listas de prefijos administradas por AWS

Rangos de direcciones IP de AWS

Restricción de la distribución geográfica

Cifrado a nivel de campo

CloudFront Origin Shield

AWS WAF Core Protections

CloudFront Origin Groups

Lecciones Aprendidas

Conclusión

Qué sigue

Recursos oficiales

Protect Amazon CloudFront Origins with Built-in Security Features: AWS Best Practices

Table of Contents:

Introduction

Why Protect Amazon CloudFront Origins

Built-in CloudFront Security Features

Restrict Access to Application Load Balancers

Restrict Access to an Amazon S3 Origin

Restrict Access with VPC Origins

AWS-Managed Prefix Lists

AWS IP Address Ranges

CloudFront Geographic Restrictions

CloudFront Field-Level Encryption

CloudFront Origin Shield

AWS WAF Core Protections

CloudFront Origin Groups

Lessons Learned