Networking on an AWS landing zone (Part 2)

En el último artículo dedicado a la construcción de una landing zone corporativa sobre AWS, se mencionaba como, debido a la complejidad que presentaba el escrito acerca del Networking, se había decidido dividir el mismo en dos partes, una primera enfocada en el diseño de la solución y esta segunda en los distintos flujos de tráfico existentes.

Sobra decir que haber leído previamente el post citado se vuelve imprescindible, ya que se referenciarán muchos conceptos allí descritos.

Network Traffic

Esta sección describe el roadtrip de una petición y cómo se relaciona con los distintos elementos que componen el diseño de solución de red, para todos los flujos de tráfico de datos posibles.

Public Ingress

El tráfico público o proveniente de Internet, únicamente puede interactuar con los aplicativos desplegados en la nube a través de la VPC de Ingress, cumpliendo así con la premisa de disponer un modelo centralizado de red que garantice el cumplimiento de las best practises en materia de seguridad, en parte, gracias a que todo el transito de datos es analizado tanto por el AWS WAF como por el AWS Network Firewall.

Así, una petición desde Internet recorre el siguiente camino antes de alcanzar el sistema final, en este caso, una instancia EC2:

1. En primera instancia, la petición viaja desde Internet hacia el AWS WAF ubicado delante del AWS CloudFront, para proteger los aplicativos frente a ataques DDOS, cross-site request forgery, cross-site scripting (XSS), file inclusion, o SQL injection.
2. Si la solicitud no ha sido bloqueada por el WAF, es trasladada hasta el CloudFront con la intención de mejorar el rendimiento/experiencia de los usuarios, absorber posibles ataques DDOS y aplicar medidas de seguridad on-edge, como por ejemplo, la validación de integridad del JWT, si el caso de uso lo requiriera.
3. Si la petición tampoco ha sido bloqueada por el CloudFront, viaja hasta el Internet Gateway (IGW), elemento que permite la comunicación entre una VPC e Internet. Recordar que en AWS se considera que una subnet es pública siempre y cuando esté asociada con un IGW mediante la tabla de rutas, de lo contrario, se considera privada.
4. Desde el IGW la solicitud es trasladada hasta el aplicación load balancer (ALB) ubicado en la subnet pública de la VPC de Ingress, que a su vez se encarga de enrutarla hasta el balanceador de la instancia EC2 ubicada en la cuenta de Workload. Antes de ello, y si el caso de uso lo requiere, puede integrase con Cognito para gestionar la autenticación y autorización del usuario externo.
5. Si la petición ha superado con éxito el proceso de autenticación y autorización del ALB, viaja hasta el Elastic Network Interface (ENI) del Transit Gateway, la interfaz de red que permite conectar una VPC con el Transit Gateway (TGW). Recordar que el Transit Gateway es ese elemento que actúa a modo de enrutador entre las VPC, así como con las redes on-premise, sin que el tráfico sea expuesto de forma pública por Internet.
6. Desde el TGW attachment la solicitud es redirigida directamente hasta el TGW.
7. El TGW enruta la petición hasta el ENI del TGW de la VPC de inspección, para que pueda ser analizada por el firewall allí ubicado.
8. Desde el TGW attachment la solicitud viaja hasta el AWS Network Firewall para filtrar el tráfico que no provenga de servicios AWS o direcciones IP conocidas, limitar los dominios a los que pueden acceder los aplicativos, llevar a cabo una inspección profunda de los paquetes de red o emplear técnicas de detección de amenazas con protocolos stateful como HTTPS, entre otros muchos ejemplos.
9. Si la petición no ha sido bloqueada por el firewall, el TGW attachment la redirige directamente hasta el TGW.
10. El TGW enruta la solicitud hasta el ENI del TGW de la VPC en la que se aloja la carga de trabajo, para que pueda ser trasladada al sistema final.
11. Desde el TGW attachment la peticion viaja hasta el Network Load Balancer (NLB) encargado de distribuir el tráfico entre las distintas instancias de la EC2. En este caso, el balanceador debe ser obligatoriamente de tipo NLB, ya que es el único que proporciona IPs estáticas a las que el ALB ubicado en la VPC de Ingress puede apuntar. No, un ALB no puede apuntar a un NLB ubicado en otra cuenta como target group y tampoco puede emplear un DNS como dirección de destino.
12. Finalmente, el NLB enruta la solicitud hasta la instancia EC2 correspondiente.

Private Ingress

El tráfico privado proveniente de la infraestructura on-premise se comunica directamente con el Transit Gateway, para interactuar con los aplicativos desplegados en la nube, sin necesidad de pasar por la VPC de Ingress, cumpliendo así con la premisa de disponer un modelo centralizado de red que garantice el cumplimiento de las best practises en materia de seguridad, en parte, gracias a que todo el transito de datos es analizado por el AWS Network Firewall.

Así, una petición desde on-premise recorre el siguiente camino antes de alcanzar el sistema final, en este caso, una instancia EC2:

1. En primera instancia, la petición viaja desde la infraestructura on-premise de la compañía, hasta el AWS Direct Connect Gateway ubicado en Amazon, a través de un cable de fibra óptica Ethernet estándar, logrando así una conexión directa, privada y bidireccional entre ambos sistemas, sin que el tráfico fluya a través de los proveedores de servicios de Internet.
2. Desde el AWS Direct Connect Gateway la solicitud es redirigida hasta el Transit Gateway (TGW), ese elemento que actúa a modo de enrutador entre las VPC, así como con las redes on-premise, sin que el tráfico sea expuesto de forma pública por Internet.
3. El TGW enruta la petición hasta el ENI del TGW de la VPC de inspección, para que pueda ser analizada por el firewall allí ubicado.
4. Desde el TGW attachment la solicitud viaja hasta el AWS Network Firewall para filtrar el tráfico que no provenga de servicios AWS o direcciones IP conocidas, limitar los dominios a los que pueden acceder los aplicativos, llevar a cabo una inspección profunda de los paquetes de red o emplear técnicas de detección de amenazas con protocolos stateful como HTTPS, entre otros muchos ejemplos.
5. Si la petición no ha sido bloqueada por el firewall, el TGW attachment la redirige directamente hasta el TGW.
6. El TGW enruta la solicitud hasta el ENI del TGW de la VPC en la que se aloja la carga de trabajo, para que pueda ser trasladada al sistema final.
7. Desde el TGW attachment la petición viaja hasta el Network Load Balancer (NLB) encargado de distribuir el tráfico entre las distintas instancias de la EC2. En este caso, el balanceador debe ser obligatoriamente de tipo NLB, ya que es el único que proporciona IPs estáticas a las que el ALB ubicado en la VPC de Ingress puede apuntar. No, un ALB no puede apuntar a un NLB ubicado en otra cuenta como target group y tampoco puede emplear un DNS como dirección de destino.
8. Finalmente, el NLB enruta la solicitud hasta la instancia EC2 correspondiente.

VPC to VPC

Al igual que el tráfico proveniente de la infraestructura on-premise, el tráfico privado entre VPCs alojadas en distintas cuentas se lleva a cabo directamente a través del Transit Gateway, sin necesidad de pasar por la VPC de Ingress o Egress. Como no podía ser de otra forma, todo el transito de datos es analizado por el AWS Network Firewall.

Así, una petición entre VPCs alojadas en dos cuentas distintas recorre el siguiente camino antes de alcanzar el sistema final, en este caso, una instancia EC2:

1. En primera instancia, la petición viaja desde el aplicativo ubicado en una de las cuentas de Workload hasta él hasta el Elastic Network Interface (ENI) del Transit Gateway, la interfaz de red que permite conectar una VPC con el Transit Gateway (TGW). Recordar que el Transit Gateway es ese elemento que actúa a modo de enrutador entre las VPC, así como con las redes on-premise, sin que el tráfico sea expuesto de forma pública por Internet.
2. Desde el TGW attachment la solicitud es redirigida directamente hasta el TGW.
3. El TGW enruta la petición hasta el ENI del TGW de la VPC de inspección, para que pueda ser analizada por el firewall allí ubicado.
4. Desde el TGW attachment la solicitud viaja hasta el AWS Network Firewall para filtrar el tráfico que no provenga de servicios AWS o direcciones IP conocidas, limitar los dominios a los que pueden acceder los aplicativos, llevar a cabo una inspección profunda de los paquetes de red o emplear técnicas de detección de amenazas con protocolos stateful como HTTPS, entre otros muchos ejemplos.
5. Si la petición no ha sido bloqueada por el firewall, el TGW attachment la redirige directamente hasta el TGW.
6. El TGW enruta la solicitud hasta el ENI del TGW de la VPC en la que se aloja la carga de trabajo, para que pueda ser trasladada al sistema final.
7. Desde el TGW attachment la petición viaja hasta el Network Load Balancer (NLB) encargado de distribuir el tráfico entre las distintas instancias de la EC2. En este caso, el balanceador debe ser obligatoriamente de tipo NLB, ya que es el único que proporciona IPs estáticas a las que el ALB ubicado en la VPC de Ingress puede apuntar. No, un ALB no puede apuntar a un NLB ubicado en otra cuenta como target group y tampoco puede emplear un DNS como dirección de destino.
8. Finalmente, el NLB enruta la solicitud hasta la instancia EC2 correspondiente.

Public Egress

Las cargas de trabajo ubicadas en la nube, únicamente pueden interactuar con servicios externos alojados en Internet a través de la VPC de Egress, cumpliendo así con la premisa de disponer un modelo centralizado de red que garantice el cumplimiento de las best practises en materia de seguridad, en parte, gracias a que todo el transito de datos es analizado por el AWS Network Firewall.

Así, una petición de una carga de trabajo alojada en una VPC de Workload, en este caso, una instancia EC2, recorre el siguiente camino antes de alcanzar un sistema final de Internet:

1. En primera instancia, la solicitud viaja desde el aplicativo ubicado en una de las cuentas de Workload hasta él hasta el Elastic Network Interface (ENI) del Transit Gateway, la interfaz de red que permite conectar una VPC con el Transit Gateway (TGW). Recordar que el Transit Gateway es ese elemento que actúa a modo de enrutador entre las VPC, así como con las redes on-premise, sin que el tráfico sea expuesto de forma pública por Internet.
2. Desde el TGW attachment la petición es redirigida directamente hasta el TGW.
3. El TGW enruta la solicitud hasta el ENI del TGW de la VPC de inspección, para que pueda ser analizada por el firewall allí ubicado.
4. Desde el TGW attachment la petición viaja hasta el AWS Network Firewall para filtrar el tráfico que no provenga de servicios AWS o direcciones IP conocidas, limitar los dominios a los que pueden acceder los aplicativos, llevar a cabo una inspección profunda de los paquetes de red o emplear técnicas de detección de amenazas con protocolos stateful como HTTPS, entre otros muchos ejemplos.
5. Si la solicitud no ha sido bloqueada por el firewall, el TGW attachment la redirige directamente hasta el TGW.
6. El TGW enruta la petición hasta el ENI del TGW de la VPC de Egress, para que pueda salir hacia Internet.
7. Desde el TGW attachment la solicitud viaja hasta el NAT Gateway (NGW), servicio de traducción de direcciones de red (NAT) que permite salir a Internet, pasando por el correspondiente Internet Gateway, sin que los servicios externos pueden iniciar libremente una conexión con ellos.
8. El NGW traslada la petición hasta el Internet Gateway (IGW), elemento que permite la comunicación entre una VPC e Internet.
9. Finalmente, el IGW enruta la solicitud hasta el sistema final alojado en Internet.

Private Egress

Las cargas de trabajo ubicadas en la nube, pueden interactuar con los servicios internos alojados en la infraestructura on-premise a través del AWS Direct Connect, sin necesidad de pasar por la VPC de Egress. Como no podía ser de otra forma, todo el transito de datos es analizado por el AWS Network Firewall.

Así, una petición de una carga de trabajo alojada en una VPC de Workload, en este caso, una instancia EC2, recorre el siguiente camino antes de alcanzar un sistema final de alojado en la infraestructura on-premise:

1. En primera instancia, la solicitud viaja desde el aplicativo ubicado en una de las cuentas de Workload hasta él hasta el Elastic Network Interface (ENI) del Transit Gateway, la interfaz de red que permite conectar una VPC con el Transit Gateway (TGW). Recordar que el Transit Gateway es ese elemento que actúa a modo de enrutador entre las VPC, así como con las redes on-premise, sin que el tráfico sea expuesto de forma pública por Internet.
2. Desde el TGW attachment la petición es redirigida directamente hasta el TGW.
3. El TGW enruta la solicitud hasta el ENI del TGW de la VPC de inspección, para que pueda ser analizada por el firewall allí ubicado.
4. Desde el TGW attachment la petición viaja hasta el AWS Network Firewall para filtrar el tráfico que no provenga de servicios AWS o direcciones IP conocidas, limitar los dominios a los que pueden acceder los aplicativos, llevar a cabo una inspección profunda de los paquetes de red o emplear técnicas de detección de amenazas con protocolos stateful como HTTPS, entre otros muchos ejemplos.
5. Si la solicitud no ha sido bloqueada por el firewall, el TGW attachment la redirige directamente hasta el TGW.
6. El TGW enruta la petición hasta el AWS Direct Connect Gateway, que esta directamente comunicado con la infraestructura on-premise a través de un cable de fibra óptica Ethernet estándar, logrando así una conexión directa, privada y bidireccional entre ambos sistemas, sin que el tráfico fluya a través de los proveedores de servicios de Internet.
7. Finalmente, él AWS Direct Connect redirige la solicitud hasta el si.

DNS resolution

Esta sección describe el roadtrip de una petición y cómo se relaciona con los distintos elementos que componen el diseño de solución de red, para la resolución de un nombre de dominio, ya sea publico o privado.

Antes de comenzar, un pequeño recordatorio. En el modelo de red planteado, la cuenta de Networking alberga un dominio principal por entorno, mientras que el resto de cuentas disponen de su propio subdominio en el que gestionar de forma aislada y autónoma las entradas o récords necesarias.

Ahora bien, con el objetivo de que aplicativos de un mismo entorno puedan invocarse entre si mediante nombres de dominios ajenos a su cuenta, todos los subdominios son compartidos con la cuenta de Networking (pero no viceversa), de forma que las cargas de trabajo pueden consultar este punto centralizado para obtener la dirección IP final.

Inbound resolution

El tráfico para la resolución de nombres de dominio proveniente de la infraestructura on-premise interactua con el Route53 Inbound Resolver ubicado en la VPC de DNS, cumpliendo así con la premisa de disponer un modelo centralizado de red que garantice el cumplimiento de las best practises en materia de seguridad, en parte, gracias a que todo el transito de datos es analizado por el AWS Network Firewall.

Así, una petición desde on-premise para la resolución de un nombre de dominio privado creado en AWS recorre el siguiente camino:

1. En primera instancia, la petición viaja desde la infraestructura on-premise de la compañía, hasta el AWS Direct Connect Gateway ubicado en Amazon, a través de un cable de fibra óptica Ethernet estándar, logrando así una conexión directa, privada y bidireccional entre ambos sistemas, sin que el tráfico fluya a través de los proveedores de servicios de Internet.
2. Desde el AWS Direct Connect Gateway la solicitud es redirigida hasta el Transit Gateway (TGW), ese elemento que actúa a modo de enrutador entre las VPC, así como con las redes on-premise, sin que el tráfico sea expuesto de forma pública por Internet.
3. El TGW enruta la petición hasta el ENI del TGW de la VPC de inspección, para que pueda ser analizada por el firewall allí ubicado.
4. Desde el TGW attachment la solicitud viaja hasta el AWS Network Firewall para filtrar el tráfico que no provenga de servicios AWS o direcciones IP conocidas, limitar los dominios a los que pueden acceder los aplicativos, llevar a cabo una inspección profunda de los paquetes de red o emplear técnicas de detección de amenazas con protocolos stateful como HTTPS, entre otros muchos ejemplos.
5. Si la petición no ha sido bloqueada por el firewall, el TGW attachment la redirige directamente hasta el TGW.
6. El TGW enruta la solicitud hasta el ENI del TGW de la VPC de DNS para resolver el nombre del dominio.
7. Desde el TGW attachment la petición viaja hasta el Route53 Inbound Resolver, servicio capaz de resolver, valga la redundancia, aquellos nombres de dominio relativos a los Private Hosted Zones (PHZ) asociados a la VPC. De nuevo, recordad que todas las cuentas comparten su PHZ con la VPC de DNS.
8. El Route53 Inbound Resolver redirige la solicitud al Route53 Resolver asociado a la VPC, no sin antes pasar por el R53 Resolver DNS Firewall para filtrar las consultas de DNS a dominios potencialmente maliciosos, habilitando únicamente las llamadas a aquellos dominios de confianza.
9. Si la petición no ha sido bloqueada por el firewall, es trasladada directamente hasta el Route53 Resolver, elemento desplegado automáticamente junto a cada VPC para responder a todas aquellas consultas de DNS con nombres de dominio locales a la VPC y registros existentes en la PHZ asociada.
10. Finalmente, el Route53 Resolver accede a la PHZ correspondiente para retornar las direcciones IP asociadas al dominio.

Outbound resolution

Las cargas de trabajo ubicadas en la nube resuelven aquellos nombres de dominio albergados en la infraestructura on-premise, mediante el Route53 Outbound Resolver ubicado en la VPC de DNS, cumpliendo así con la premisa de disponer un modelo centralizado de red que garantice el cumplimiento de las best practises en materia de seguridad, en parte, gracias a que todo el transito de datos es analizado por el AWS Network Firewall.

Así, una petición para la resolución de un nombre de dominio privado creado en la infraestructura on-premise, desde una carga de trabajo alojada en una VPC de Workload, en este caso, una instancia EC2, recorre el siguiente camino:

1. En primera instancia, la solicitud viaja desde el aplicativo ubicado en la cuenta de Workload hasta el Route53 Resolver asociado a la VPC, no sin antes pasar por el R53 Resolver DNS Firewall para filtrar las consultas de DNS a dominios potencialmente maliciosos, habilitando únicamente las peticiones a aquellos dominios de confianza.
2. Si la petición no ha sido bloqueada por el firewall, es trasladada directamente hasta el Route53 Resolver, elemento desplegado automáticamente junto a cada VPC para responder a todas aquellas consultas de DNS con nombres de dominio locales a la VPC y registros existentes en la PHZ asociada.
3. El Route53 Resolver no dispone de dicho registro, por lo que delega la solicitud en el R53 Inbound Resolver ubicado en la VPC de DNS. Así, la solicitud viaja de nuevo desde el aplicativo ubicado en la cuenta de Workload hasta él hasta el Elastic Network Interface (ENI) del Transit Gateway, la interfaz de red que permite conectar una VPC con el Transit Gateway (TGW). Recordar que el Transit Gateway es ese elemento que actúa a modo de enrutador entre las VPC, así como con las redes on-premise, sin que el tráfico sea expuesto de forma pública por Internet.
4. Desde el TGW attachment la petición viaja directamente hasta el TGW.
5. El TGW enruta la solicitud hasta el ENI del TGW de la VPC de inspección, para que pueda ser analizada por el firewall allí ubicado.
6. Desde el TGW attachment la petición viaja hasta el AWS Network Firewall para filtrar el tráfico que no provenga de servicios AWS o direcciones IP conocidas, limitar los dominios a los que pueden acceder los aplicativos, llevar a cabo una inspección profunda de los paquetes de red o emplear técnicas de detección de amenazas con protocolos stateful como HTTPS, entre otros muchos ejemplos.
7. Si la solicitud no ha sido bloqueada por el firewall, el TGW attachment la redirige directamente hasta el TGW.
8. El TGW enruta la petición hasta el ENI del TGW de la VPC de DNS para resolver el nombre del dominio.
9. Desde el TGW attachment la solicitud viaja hasta el Route53 Outbound Resolver, servicio diseñado para que los servidores DNS de AWS puedan delegar todas aquellas consultas relacionadas con los dominios alojados en las instalaciones on-premise.
10. Desde el Route53 Outbound Resolver la petición viaja directamente hasta el TGW.
11. El TGW enruta la solicitud hasta el AWS Direct Connect Gateway, que esta directamente comunicado con la infraestructura on-premise a través de un cable de fibra óptica Ethernet estándar, logrando así una conexión directa, privada y bidireccional entre ambos sistemas, sin que el tráfico fluya a través de los proveedores de servicios de Internet.
12. Finalmente, él AWS Direct Connect redirige la petición hasta el servidor de DNS alojado en la infraestructura on-premise.

VPC to VPC resolution

Las cargas de trabajo ubicadas en la nube resuelven aquellos nombres de dominio albergados en otras cuentas de AWS, mediante el Route53 Inbound Resolver ubicado en la VPC de DNS, cumpliendo así con la premisa de disponer un modelo centralizado de red que garantice el cumplimiento de las best practises en materia de seguridad, en parte, gracias a que todo el transito de datos es analizado por el AWS Network Firewall.

Así, una petición para la resolución de un nombre de dominio privado creado en una cuenta de AWS, desde una carga de trabajo alojada en una VPC de Workload de otra cuenta de AWS, en este caso, una instancia EC2, recorre el siguiente camino:

1. En primera instancia, la solicitud viaja desde el aplicativo ubicado en la cuenta de Workload hasta el Route53 Resolver asociado a la VPC, no si antes pasar por el R53 Resolver DNS Firewall para filtrar las consultas de DNS a dominios potencialmente maliciosos, habilitando únicamente las peticiones a aquellos dominios de confianza.
2. Si la petición no ha sido bloqueada por el firewall, es trasladada directamente hasta el Route53 Resolver, elemento desplegado automáticamente junto a cada VPC para responder a todas aquellas consultas de DNS con nombres de dominio locales a la VPC y registros existentes en la PHZ asociada.
3. El Route53 Resolver no dispone de dicho registro, por lo que delega la solicitud en el R53 Inbound Resolver ubicado en la VPC de DNS. Así, la petición viaja de nuevo desde el aplicativo ubicado en la cuenta de Workload hasta él hasta el Elastic Network Interface (ENI) del Transit Gateway, la interfaz de red que permite conectar una VPC con el Transit Gateway (TGW). Recordar que el Transit Gateway es ese elemento que actúa a modo de enrutador entre las VPC, así como con las redes on-premise, sin que el tráfico sea expuesto de forma pública por Internet.
4. Desde el TGW attachment la solicitud viaja directamente hasta el TGW.
5. El TGW enruta la petición hasta el ENI del TGW de la VPC de inspección, para que pueda ser analizada por el firewall allí ubicado.
6. Desde el TGW attachment la solicitud viaja hasta el AWS Network Firewall para filtrar el tráfico que no provenga de servicios AWS o direcciones IP conocidas, limitar los dominios a los que pueden acceder los aplicativos, llevar a cabo una inspección profunda de los paquetes de red o emplear técnicas de detección de amenazas con protocolos stateful como HTTPS, entre otros muchos ejemplos.
7. Si la petición no ha sido bloqueada por el firewall, el TGW attachment la redirige directamente hasta el TGW.
8. El TGW enruta la solicitud hasta el ENI del TGW de la VPC de DNS para resolver el nombre del dominio.
9. Desde el TGW attachment la petición viaja hasta el Route53 Outbound Resolver, servicio diseñado para que los servidores DNS de AWS puedan delegar todas aquellas consultas relacionadas con los dominios alojados en las instalaciones on-premise, pero que también puede ser empleado para resolver los dominios creados en otras cuentas.
10. Para ello, el Route53 Outbound Resolver redirige la solicitud al Route53 Inbound Resolver, servicio que es capaz de resolver, valga la redundancia, aquellos nombres de dominio relativos a los Private Hosted Zones (PHZ) asociados a la VPC. De nuevo, recordad que todas las cuentas comparten su PHZ con la VPC de DNS.
11. El Route53 Inbound Resolver traslada la petición al Route53 Resolver asociado a la VPC, no si antes pasar por el R53 Resolver DNS Firewall para filtrar las consultas de DNS a dominios potencialmente maliciosos, habilitando únicamente las llamadas a aquellos dominios de confianza.
12. Si la solicitud no ha sido bloqueada por el firewall, es trasladada directamente hasta el Route53 Resolver, elemento desplegado automáticamente junto a cada VPC para responder a todas aquellas consultas de DNS con nombres de dominio locales a la VPC y registros existentes en la PHZ asociada.
13. Finalmente, el Route53 Resolver accede a la PHZ correspondiente para retornar las direcciones IP asociadas al dominio.

Conclusiones

En conclusión, se han descrito todos los flujos de tráfico posibles para el diseño de solución de red centralizado presentado en el artículo anterior, mostrando paso a paso el camino que recorrer cada petición y como se relacionada con los distintos elementos.

Como siempre, estad atentos a futuros escritos en los que se detallarán en profundidad los diseños técnicos pendientes, como el logging centralizado o single sign-on, entre otros.

Referencias

Se recomienda encarecidamente leer los siguientes artículos que han servido de base para el escrito:

1. https://aws.amazon.com/blogs/mt/extending-your-control-tower-network-security-with-aws-route-53-dns-firewall/
2. https://aws.amazon.com/blogs/networking-and-content-delivery/dynamic-whole-site-delivery-with-amazon-cloudfront/
3. https://aws.amazon.com/blogs/networking-and-content-delivery/deploy-centralized-traffic-filtering-using-aws-network-firewall/
4. https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/
5. https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall-with-vpc-routing-enhancements/
6. https://aws.amazon.com/blogs/security/simplify-dns-management-in-a-multiaccount-environment-with-route-53-resolver/
7. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html
8. https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html