Networking on an AWS landing zone (Part 1)

Seguimos con la serie de artículos dedicados a la construcción de una landing zone corporativa sobre AWS, y tras un primer escrito de introducción, seguido de un texto enfocado en el accounting, le llega el turno al networking. La cosa se pone interesante.

Nota: Debido a la densidad del tópico, se ha decidido dividir el mismo en dos artículos, el primero enfocado en el diseño de la solución y el segundo en los distintos flujos de tráfico.

Network account

Si se ha seguido al pie de la letra el modelo de cuentas previamente descrito, debería existir una cuenta por entorno encargada de centralizar la entrada, inspección, enrutado y salida de todo el tráfico de AWS.

La idea es aglutinar todo el tráfico de red, ya sea norte/sur, este/oeste, público o privado, para que pueda ser correctamente tratado, lo que incluye el análisis de amenazas vía firewall, la resolución de DNS interna y externa vía Route53, el enrutado entre cuentas vía Transit Gateway o la conexión con los sistemas on-premise vía AWS Direct Connect, entre otros.

Este modelo de solución no solo simplifica de forma notoria el trabajo del equipo de Networking, al centralizar todas los aspectos relacionados con la red en un único espacio de trabajo, sino que también permite que el personal encargado del desarrollo de los aplicativos pueda olvidarse de estos aspectos, siendo completamente transparente para ellos.

Ahora bien, organizaciones con un elevado volumen de tráfico podrían requerir una mayor segregación de cuentas, no solo por entorno, o un modelo de solución distribuido, para no alcanzar los limites físicos de los elementos de infraestructura, si bien este escrito no abarca esta segunda propuesta.

Solution Overview

El siguiente diagrama de arquitectura muestra un diseño de solución centralizado que da respuesta a las necesidades previamente descritas.

Lo primero que salta a la vista es que la cuenta se divide en 5 VPCs distintas, una por cada una de las funciones anteriormente comentadas. Mediante esta decisión se busca garantizar un aislamiento total de los servicios allí alojados y acotar al máximo el radio de expansión derivado de problemas por un cyber ataque o errores humanos, entre otros.

A su vez, cada una de estas VPCs se compone de 3 subnets ubicadas en 3 zonas de disponibilidad distintas, buscando maximizar la disponibilidad frente a posibles caídas zonales. A buen seguro que algunos de los sistemas distribuidos analizados en esta casa, como Kafka, Elasticsearch o CokroachDB, en los cuales se recomienda disponer de un mínimo de 3 nodos para entornos productivos, lo agradecerán.

Todas estas VPCs, junto a aquellas creadas en las cuentas encargadas de albergar las cargas de trabajo, se encuentran interconectadas a través de un Transit Gateway, un servicio gestionado, elástico, altamente disponible y multi-cuenta de AWS, que actúa a modo de enrutador de capa 3 entre las VPC, así como con las redes on-premise (siempre que se haga uso de un AWS Managed VPN o AWS Direct Connect), sin que el tráfico sea expuesto de forma pública por Internet.

Sin lugar a dudas se trata de una de las piezas clave de la solución, no solo por como simplifica la gestión de la configuración para la comunicación entre las distintas redes (si, podéis decir adiós a los tediosos VPC peerings), sino también por que permite que todo el tráfico pase por el AWS Network Firewall ubicado en la VPC correspondiente, antes de ser enrutado a su destino, logrando así securizar todos los flujos de tráfico existentes, incluyendo aquellas llamadas entre subnets de una misma VPC. Casi nada.

Ahora bien, para que toda esta magia funcione, las VPCs deben disponer de un Transit Gateway attachment (internamente representado como un ENI) desplegado por zona de disponibilidad, preferiblemente en una subnet completamente aislada del resto de aplicativos. El motivo de su aislamiento es poder seguir aplicando ACLs a nivel de las subnet de las cargas de trabajo, sin que esto impacte al Transit Gateway, razón por lo que desde Amazon recomiendan asignarles un CIDR reducido, de cara ha realizar una gestión optima de las direcciones IP claro está. Seguro que ahora el diagrama comienza a cobrar más sentido.

Al tratarse de un servicio gestionado, permite que, a diferencia de otros productos, no requiera implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con el resto de productos de la casa como el AWS Managed VPN o AWS Direct Connect, así como con los servicios de observabilidad y auditoria propietarios de la nube.

En lo que a los limites del servicio se refiere, comentar qué es capaz de ofrecer un ancho de banda de hasta 50 Gbps y 5,000,000 paquetes por segundo por attachment, más que de sobra para la mayoría de las organizaciones. Ahora bien, de igual manera que un VPC Peering, no es compatible con un direccionamiento entre VPC con CIDR idénticos, por lo que estos deberán ser independientes.

Finalmente, señalar que se factura bajo una modalidad de pago por uso, en concreto, en base a la cantidad de conexiones que se realizan al Transit Gateway por hora y por la cantidad de tráfico que circula a través del servicio, lo que le permite adaptarse a todo tipo de organizaciones y escenarios.

Dado que ya ha sido mencionado brevemente, es un buen momento para describir AWS Direct Connect, el servicio gestionado que hace posible establecer una conexión privada con la infraestructura on-premise.

En concreto, permite enlazar la red interna de una organización a una ubicación de AWS Direct Connect, a través de un cable de fibra óptica Ethernet estándar. Un extremo del cable se conecta al router on-premise y el otro al router de AWS Direct Connect, logrando así una conexión directa, privada y bidireccional entre ambos sistemas, sin que el tráfico viaje a través de los proveedores de servicios de Internet, lo que a la postre permite reducir los costos, aumentar el ancho de banda y brindar una experiencia de red más consistente que las conexiones basadas en Internet.

Ahora bién, lo verdaderamente interesante es la opción de enlazarlo directamente con el Transit Gateway, disponibilizando así el acceso a todas las VPCs desde la infraestructura on-premise. Evidentemente es posible establecer controles de seguridad que filtren el acceso en función del origen, lo importante es comprender las capacidades que ofrece.

Por desgracia, no todo iban a ser buenas noticias y como ocurre en la mayoría de los casos, existen una serie de disclaimers a tener en cuenta. Lo primero es que AWS Direct Connect no ofrece, per sé, alta disponibilidad, por lo que se antoja imprescindible establecer más de una conexión para disponer de redundancia y evitar disgustos a medio-largo plazo.

Lo segundo es que el tráfico no viaja encriptado por defecto, por lo que es necesario activar el MACsec security en aquellas regiones en las que esté soportado, o en su defecto, desplegar una AWS Site-to-Site VPN que funcione sobre el Direct Connect. También es posible emplear ambas soluciones de forma conjunta en aquellas organizaciones en los que los requisitos de seguridad así lo demanden.

Al tratarse de un servicio gestionado, permite que, a diferencia de otros productos, no requiera implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con el resto de productos de la casa como el Transit Gateway mencionado previamente, así como con los servicios de observabilidad y auditoria propietarios de la nube.

En lo que a los limites del servicio se refiere, comentar que es capaz de ofrecer un ancho de banda de hasta 100 Gbps por instancia y emparejarse con 3 Transit Gateways, más que de sobra para la mayoría de las organizaciones, siempre y cuando sigan el modelo de cuentas y despliegue descrito.

Finalmente, señalar que se factura bajo una modalidad de pago por uso, en concreto, en base a a la capacidad contratada, horas de uso y por la cantidad de tráfico que circula a través del servicio, lo que le permite adaptarse a todo tipo de organizaciones y escenarios.

Una vez detallados tanto el Transit Gateway como el Direct Connect, llegó el momento de describir todas esas VPCs que conforman el modelo de solución.

Ingress VPC

Como su propio nombre indica, es la VPC en la que residen todos aquellos elementos que facilitan la ingesta del tráfico proveniente de Internet.

A pesar de resultar algo evidente, se antoja imprescindible remarcar que por esta red únicamente viaja el tráfico de entrada, mientras que el tráfico de salida se gestiona a través de la VPC de Egress, y de carácter público, ya que el tráfico privado proveniente de la infraestructura on-premise se conecta directamente con el Transit Gateway.

En primerísima linea de fuego se encuentra el AWS WAF, un firewall gestionado que actúa en la capa 7 y ayuda a proteger las aplicaciones web o APIs contra ataques web y bots que puedan afectar la disponibilidad, poner en riesgo la seguridad o consumir demasiados recursos.

Al tratarse de un servicio gestionado, permite que, a diferencia de otros productos, no requiera implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con el resto de productos de la casa como él Amazon CloudFront, Amazon API Gateway, o el Application Load Balancer, así como con los servicios de observabilidad y auditoria propietarios de la nube.

En lo que al funcionamiento propiamente dicho se refiere, se han de configurar reglas qué habiliten, bloqueen o monitoricen (cuenten) las peticiones en base a condiciones que incluyan la dirección IP, cabeceras HTTP, cadenas URI, inyección de código SQL o scripting entre sitios, de forma que los aplicativos queden protegidos frente a ataques DDOS, cross-site request forgery, cross-site scripting (XSS), file inclusion, o SQL injection, entre otras amenazas en el Top 10 de OWASP. Así, Amazon proporciona plantillas de CloudFormation que implementan precisamente estas reglas OWASP, si bien la comunidad también las ha desarrollado sobre Terraform.

Ahora bien, a nadie se le escapa que esto es insuficiente para garantizar una primera linea de defensa férrea, y por eso Amazon ofrece un servicio denominado AWS Managed Rules for AWS WAF, que proporciona múltiples grupos de reglas predefinidas que brinda protección contra vulnerabilidades de aplicaciones comunes u otro tráfico no deseado, ahorrando el esfuerzo que supone escribir todas ellas. Y sí, existe una para tratar de mitigar la archiconocida Log4j vulnerability que tantos quebraderos de cabeza ha producido en los últimos meses.

Disclaimer: Tal y como la propia Amazon se encarga de recordar, estas reglas están diseñadas para garantizar una protección frente a amenazas web comunes, pero en ningún caso son un reemplazo de nuestras responsabilidades de seguridad acordados en el modelo de responsabilidad compartida.

Para la gestión del WAF, AWS dispone de un servicio de administración de seguridad denominado AWS Firewall Manager que permite la configuración y administración centralizada de reglas de los distintos firewalls en todas las cuentas y aplicaciones de AWS Organizations. Tal y como se describió en el artículo centrado en el accounting, debe estar alojado en la Security Tooling Account de la unidad organizativa de Security. Como podéis observar, poco a poco van encajando toda las piezas.

En esta ocasión, no hay nada llamativo a destacar de los limites del servicio, no al menos desde el punto de vista de la capacidad o del rendimiento.

Finalmente, señalar que se factura bajo una modalidad de pago por uso, en concreto, en base al número de listas de control de acceso web (ACL web) que se crean, el número de reglas que se añaden por ACL web y el número de solicitudes web que se reciben, lo que le permite adaptarse a todo tipo de organizaciones y escenarios.

Pegadito al WAF se encuentra el AWS CloudFront, un servicio gestionado de CDN (Content Delivery Network) para datos, videos, aplicaciones y APIs, que permite distribuir el contenido con baja latencia y altas tasas de transferencia de datos, mediante una red global conformada por más de 310 puntos de presencia (más de 300 ubicaciones edge y 13 cachés de nivel medio regionales) distribuidos en más de 90 ciudades de 47 países.

En otras palabras, permite cachear el contenido de los aplicativos, generalmente estático, en múltiples servidores ubicados en distintas zonas geográficas, de tal forma que el usuario siempre es atendido por el nodo mas cercano a su ubicación, reduciendo notoriamente el tiempo de respuesta de las peticiones.

Por lo general, los ficheros estáticos “originales” suelen ser almacenados en un bucket S3, no solo porque disponga de una integración nativa con CloudFront, sino por qué ofrece una gran rendimiento a un costo reducido.

Ahora bien, ¿debe emplearse también para atender las peticiones a las distintas APIs publicadas por la organización? Sin lugar a dudas, sí.

Por una parte, CloudFront mantiene un pool de conexiones abierto entre sus puntos de presencia y el sistema final, lo que permite reducir el roadtrip de las peticiones encargadas de llevar a cabo la negociación del protocolo TLS, ya que se realiza únicamente entre el usuario y la nodo de CloudFront, y no con el sistema final, siendo la distancia entre ambos sensiblemente menor. Por si hubiera alguna duda, sí, la solicitud viaja encriptada end to end, desde el origen hasta el destino.

Por otro lado, CloudFront permite ejecutar en sus puntos de presencia funciones Lambda@Edge o CloudFront Functions que tienen la capacidad de manipular la cache-key, URL o cabeceras HTTP, entre otros. Lo interesante es que pueden ser empleadas para enrobustecer la seguridad de los aplicativos, añadiendo una cabecera HTTP Strict Transport Security (HSTS) a la respuesta o validando la integridad de un JWT para aceptar o rechazar la petición, entre otros. Todo esto, sin la que solicitud llegue siquiera a alcanzar la VPC de Ingress.

Adicionalmente, el hecho de distribuir el acceso a la infraestructura entre distintos puntos de presencia no solo permite reducir la latencia y mejorar el rendimiento para los usuarios, sino también absorber los ataques DDoS y aislar los fallos, minimizando así el impacto en la disponibilidad de los aplicativos.

Por tanto, no es casualidad que Amazon recomiende en el AWS Best Practices for DDoS Resiliency AWS Whitepaper su uso, junto al WAF, como las dos principales buenas prácticas para mitigar ataques DDOS de capa 3 (UDP reflection), capa 4 (SYN flood), capa 6 (TLS) o capa 7 (application).

Si aun albergarais alguna duda respecto a CloudFront, señalar que su uso no implica un coste adicional, ya que AWS factura por el tráfico de salida hacia internet, y no por el tráfico de salida hacia CloudFront, lo que significa que se pueden aprovechar el rendimiento y las capacidades de seguridad adicionales, sin incurrir en la factura mensual. El tráfico de entrada en Amazon siempre es gratuito.

A modo de curiosidad, el servicio dispone de una capa gratuita mensual de 1 TB de tráfico saliente de datos y 10.000.000 de solicitudes HTTPS, con unos costes variables adicionales en función del volumen y zona geográfica.

Al tratarse de un servicio gestionado, permite que, a diferencia de otros productos, no requiera implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con el resto de productos de la casa como el AWS WAF, Amazon API Gateway, Application Load Balancer o S3, así como con los servicios de observabilidad y auditoria propietarios de la nube.

Finalmente, en lo que a los limites del servicio se refiere, comentar que es capaz de ofrecer un ancho de banda de hasta 150 Gbps y 250.000 peticiones por segundo e instancia, más que de sobra para la mayoría de las organizaciones, siempre y cuando sigan el modelo de cuentas y despliegue descrito.

Detrás del CloudFront se encuentra el Internet Gateway, un componente horizontalmente escalable, redundate y altamente disponible que habilita la comunicación entre una VPC e Internet. Es decir, sin el no sería posible que el tráfico público llegara o saliera a las subnets enlazadas, y tampoco asignar direcciones IP publicas a aquellos elementos que lo solicitaran. En AWS se considera que una subnet es pública siempre y cuando esté asociada con un Internet Gateway mediante la tabla de rutas, de lo contrario se considera privada.

Al tratarse de un servicio gestionado no requiere implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. De hecho, desde Amazon se limitan a decir que no hay que preocuparse por su disponibilidad o ancho de banda, sin llegar a proporcionar dato alguno al respecto, probablemente por que se trata de una conexión lógica entre la VPC e Internet y no de un componente físico como dicta su definición oficial. Por cierto, su uso es completamente gratuito, algo que siempre es de agradecer.

En la única subnet pública de todo el entorno se encuentra el Application Load Balancer (ALB), un balanceador de carga de capa 7 que permite distribuir el tráfico entrantes entre distintos objetivos (Instancias EC2, contenedores, direcciones IP o funciones Lambda) alojados en múltiples zonas de disponibilidad, en base al contenido de la petición.

Antes de nada, aclarar que a pesar de situarse detrás del CloudFront, es indispensable que el balanceador se encuentre accesible desde Internet, es decir, que esté ubicado en una subnet pública y disponga de una dirección IP pública, para que las peticiones puedan ser correctamente enrutadas, de lo contrario, no alcanzarán a su destino.

Debido a esto, se vuelve fundamental configurar el ALB para restringir el tráfico que no provenga del CloudFront, garantizando que se hace uso de el, asi como del WAF, y se obtienen todos beneficios previamente comentados.

Así, su principal cometido es enrutar las peticiones hasta los aplicativos alojados en las cuentas de Workload en función del host, path, cabecera, método, query string o dirección IP de origen, pasando por el AWS Network Firewall ubicado en la VPC de Firewall, tal y como se detallará posteriormente.

¿Y no se podía haber empleado un Network Load Balancer (NLB) para obtener un mejor rendimiento? La respuesta es no, ya que se trata de un balanceador de capa 4 y por lo tanto, no ofrece capacidades de routing avanzadas, además de no ser compatible con el CloudFront.

¿Y un Amazon API Gateway? No, ya que la comunicación entre el ALB y los aplicativos se realiza a través del Transit Gateway para poder pasar automáticamente por el AWS Network Firewall entre medias, securizando así todos los flujos de tráfico existentes, y el API Gateway no dispone de integración con este elemento tildado como la pieza clave de la solución. Existen otros puntos mas adecuados para el despliegue de un Gateway, tanto si se prefiere un modelo distribuido como centralizado, si bien queda fuera del ámbito del presente artículo.

Como el resto de elementos presentados hasta el momento, se trata de un servicio gestionado que no requiere implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con el resto de productos de la casa como el CloudFront, Cognito o el Certificate Manager, así como con los servicios de observabilidad y auditoria propietarios de la nube.

Precisamente su integración nativa con Cognito, o con cualquier otro identity provider compatible con el protocolo OpenId Connect, como Google o Facebook, es una de sus funcionalidades más apetecibles, ya que permite centralizar la autenticación de los usuarios en un zona perimetral (VPC de Ingress), antes de acceder a las cuentas de workload, a la par que libera a los aplicativos de dicha responsabilidad. Todas las elecciones tienen su razón de fondo.

En esta ocasión, no hay nada llamativo a destacar de los limites del servicio, no al menos desde el punto de vista de la capacidad o del rendimiento.

Finalmente, señalar que se factura bajo una modalidad de pago por uso, en concreto, por cada hora u hora parcial en la que el ALB se ejecute, así como por el número de unidades de capacidad del balanceador de carga (LCU) utilizadas por hora, que a su vez se calculan en base a la cantidad de conexiones nuevas establecidas por segundo, cantidad de conexiones activas por minuto, numero de reglas de routing evaluadas y por la cantidad de tráfico que circula a través del servicio, lo que le permite adaptarse a todo tipo de organizaciones y escenarios.

El último elemento desplegado en la VPC de Ingress es el Transit Gateway attachment que habilita la comunicación con el Transit Gateway. Tal y como se ha mencionado previamente, se encuentra desplegado en una subnet aislada, cumpliendo así con las buenas prácticas recomendadas por Amazon.

Inspection VPC

VPC en la que residen aquellos elementos encargados de inspeccionar todo el tráfico que circula a través del Transit Gateway, ya sea norte-sur o este-oeste.

En concreto, aquí se ubica el AWS Network Firewall, un servicio gestionado de Firewall autoescalable y altamente disponible con el que realizar un minucioso control sobre el tráfico de la red, y evitar así la propagación de actividades maliciosas.

Al tratarse de un servicio gestionado, permite que, a diferencia de otros productos, no requiera implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con el resto de productos de la casa como el AWS Transit Gateway, AWS Firewall Manager o AWS Organizations, así como con los servicios de observabilidad y auditoria propietarios de la nube.

Eso si, es necesario desplegar un Firewall Endpoint (un endpoint service internamente representado como un ENI) por cada zona de disponibilidad, y preferiblemente en una subnet completamente aislada con un tamaño mínimo de /28, ya que no es capaz de proteger a aquellas cargas de trabajo que se ejecutan en la misma subred, en este caso, el Transit Gateway attachment.

En lo que al funcionamiento propiamente dicho se refiere, se han de configurar reglas de tipo stateless access control lists (ACLs), stateful inspection, o intrusion prevention systems (IPSs), qué habiliten o bloqueen el tráfico en base a la URL, dirección IP y dominio, de forma que la organización quede protegida frente a ataques de malware o posibles fugas de datos.

De esta forma es posible 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.

Ahora bien, la inspección profunda de los paquetes de red no está actualmente soportada para el tráfico encriptado, por lo que, en caso de querer hacer uso de esta funcionalidad, toda la comunicación interna debe llevarse a cabo en texto plano…

De lo que seguro que no se encarga es de mitigar los ataques de denegación de servicio (DDOS), ya que está focalizado en el análisis del tráfico interno, y este tipo de medidas se aplican en la zona perimetral, en nuestro caso, la VPC de Ingress.

Al igual que en el WAF, es posible emplear el servicio de administración de seguridad denominado AWS Firewall Manager que permite la configuración y administración centralizada de las reglas de los distintos filrewalls en todas las cuentas y aplicaciones de AWS Organizations. De nuevo, tal y como se describió en el artículo centrado en el accounting, debe estar alojado en la Security tooling account de la unidad organizativa de Security.

En esta ocasión, no hay nada llamativo a destacar de los limites del servicio, no al menos desde el punto de vista de la capacidad o del rendimiento.

Finalmente, señalar que se factura bajo una modalidad de pago por uso, en concreto, por cada hora en la que un Firewall Endpoint se ejecute, así como por la cantidad de tráfico que circula a través del servicio, lo que le permite adaptarse a todo tipo de organizaciones y escenarios.

El último elemento desplegado en la VPC de Inspections es el Transit Gateway attachment que habilita la comunicación con el Transit Gateway.

Egress VPC

Como su propio nombre indica, es la VPC en la que residen todos aquellos elementos que facilitan la salida del tráfico hacia Internet.

En concreto, aquí se ubica el NAT Gateway, un servicio de traducción de direcciones de red (NAT) que permite que los aplicativos alojados en las subredes privadas de las cuentas de Workload puedan salir a Internet, pasando por el correspondiente Internet Gateway, sin que los servicios externos pueden iniciar libremente una conexión con ellos.

Al tratarse de un servicio gestionado, permite que, a diferencia de otros productos, no requiera implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con el resto de productos de la casa como el Internet Gateway mencionado previamente, así como con los servicios de observabilidad y auditoria propietarios de la nube.

Ahora bien, únicamente garantiza la alta disponibilidad para la zona de disponibilidad en la que haya sido desplegado, por lo que es más que recomendable desplegarlo en 3 subnets alojadas en 3 AZ distintas, tal y como se muestra en el diagrama.

Las subredes en cuestión deben de ser públicas, es decir, deben estar enlazadas con el Internet Gateway, para que el NAT Gateway puede obtener una dirección de IP pública en el momento de su creación y disponer de salida al exterior. En caso de ubicar el NAT Gateway en una subred privada, la comunicación con el Internet Gateway se perdería y por tanto, no sería posible acceder a Internet.

Alguno se podría estar preguntando el motivo por el que se ha desechado el uso de un Egress-Only Intenet Gateway (EIGW), servicio que únicamente permite el tráfico saliente, y la respuesta no podía ser más sencilla. Dicho componente solo funciona bajo IPV6 y en la actualidad no todos los servicios de AWS disponen soporte para ello. Un ejemplo ilustrativo de esto es que el EKS no recibió soporte hasta enero de 2022.

En lo que a los limites del servicio se refiere, comentar que es capaz de ofrecer un ancho de banda de 45 Gbps, 4,000,000 paquetes por segundo y 55.000 conexiones activas a un mismo destino, todo por ello, por cada una de las instancias desplegadas, lo que debería ser suficiente para la mayoría de las organizaciones, siempre y cuando sigan el modelo de cuentas y despliegue descrito.

Finalmente, señalar que se factura bajo una modalidad de pago por uso, en concreto, en base a las horas de uso y por la cantidad de tráfico que circula a través del servicio, lo que le permite adaptarse a todo tipo de organizaciones y escenarios.

El último elemento desplegado en la VPC de Egress es el Transit Gateway attachment que habilita la comunicación con el Transit Gateway.

Services Hub VPC

VPC en la que residen todos los VPC Endpoints.

Nota: La siguiente imagen únicamente muestra un subconjunto de posibles VPC Endpoints a desplegar.

Un VPC Endpoint es un servicio gestionado autoescalable y altamente disponible que permite establecer una conexión privada entre una VPC y los servicios admitidos, sin necesidad de emplear un Internet Gateway, NAT Gateway, VPN, o AWS Direct Connect. Es decir, habilita el acceso directo a servicios como S3, DynamoDB, API Gateway o CloudWatch, sin necesidad de una IP pública y sin que el tráfico de red abandone en ningún momento la infraestructura de Amazon.

Al tratarse de un servicio gestionado, permite que, a diferencia de otros productos, no requiera implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con el resto de productos de la casa recién listados, así como con los servicios de observabilidad y auditoria propietarios de la nube.

Probablemente os estéis preguntando cuál es el motivo de centralizar todos los VPC Endpoints en una única cuenta por entorno y la respuesta la encontramos en el billing. Desplegar 3 instancias, una por cada una de las zonas de disponibilidad, equivale a un coste mínimo mensual de 22-23$ por VPC, ya que se factura por horas de uso y tráfico que circula a través del servicio. Si ahora se multiplica esta cifra por cada servicio de AWS al que acceder, así como por cada VPC que los requieran, el coste puede puede volverse algo elevado.

Para que las cargas de trabajo puedan redirigir las peticiones correctamente a los endpoints ubicado en la cuenta de Networking, o bien se deshabilita la opción “private DNS” al crear el VPC Endpoint o bien se crea una entrada de DNS con el nombre completo del service endpoint, apuntando al VPC Endpoint.

Como no podía ser de otra forma, esta solución también presenta sus desventajas, ya que no permite aplicar políticas de privilegios mínimos por VPC Endpoint, lo que obliga a gestionar todos los permisos en un único documento de hasta 20,480 caracteres por servicio.

Eso sí, no debería haber riesgo de convertirse en un cuello de botella, siempre y cuando sigan el modelo de cuentas y despliegue descrito, ya que es capaz de ofrecer un ancho de banda de hasta 40 Gbps por instancia.

El último elemento desplegado en la VPC de Services Hub es el Transit Gateway attachment que habilita la comunicación con el Transit Gateway.

DNS VPC

Como su propio nombre indica, es la VPC en la que residen todos aquellos elementos que se encargan de resolución de nombres de dominio en la nube, tanto públicos como privados, así como de la integración con los sistemas on-premise existentes.

Antes de entrar de lleno a desgranar cada uno de los servicios y las funcionalidades que ofrecen, es conveniente explicar cuál es la estrategia global para la gestión de los DNS.

Así, la solución pasa por que en la cuenta de Networking resida un dominio principal por entorno, mientras que el resto de cuentas albergan de su propio subdominio en el que gestionar de forma aislada y autónoma las entradas o récords necesarias. Sí, en esta ocasión se delega sobre cada equipo la administración de los dominios, ya que no se tratan de políticas globales e uniformes a aplicar de igual manera en todos los casos de uso, logrando así una mayor agilidad.

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. Tranquilos, es mucho más sencillo de lo que parece.

Lo primero de todo, Amazon Route 53 es un servicio autoescalable y altamente disponible de DNS (sistema de nombres de dominio) que permite administrar tanto registros públicos como privados, así como definir políticas de enrutado en base a la geolocalización, geoproximidad, o latencia, entre otros.

Al tratarse de un servicio gestionado, permite que, a diferencia de otros productos, no requiera implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con la inmensa mayoría de productos de la casa, así como con los servicios de observabilidad y auditoria propietarios de la nube.

En lo que al funcionamiento propiamente dicho se refiere, se ha de configurar una Private Hosted Zone (PHZ) por cuenta, oficialmente descrito como un contenedor que aloja información acerca de cómo Amazon Route 53 debe responder a las consultas de DNS de un dominio en una o varias VPC. Es decir, es el mecanismo a través del que se definen los dominios y los récords en una cuenta, para posteriormente ser vinculado a una o mas VPCs.

¿Y como comparten las distintas cuentas su PHZ con la de Networking? Mediante una vpc-association-authorization, un sencillo proceso que actualmente puede llevarse a cabo vía AWS CLI, AWS SDK or AWS Tools for Windows PowerShell o la API de Route53, pero en ningún caso mediante la consola web.

En esta ocasión, no hay nada llamativo a destacar de los limites del servicio, no al menos desde el punto de vista de la capacidad o del rendimiento.

Finalmente, señalar que se factura bajo una modalidad de pago por uso, en concreto, en base al número de PHZ y récords existentes, así como por el número de consultas recibidas, lo que le permite adaptarse a todo tipo de organizaciones y escenarios.

Con los dominios ya compartidos con la cuenta de Networking, es hora de desgranar el mecanismo que hace posible consultar este punto centralizado para que los aplicativos de un mismo entorno puedan invocarse entre si mediante nombres de dominios ajenos a su cuenta.

Así, la magia reside en los Route53 Resolvers y en concreto en sus Inbound/Outbound endpoints, pero vayamos despacio y con buena letra.

Lo primero que se debe saber es que junto a cada VPC se despliega un Route53 Resolver, que se ejecuta en una dirección IP reservada para el rango de red de VPC +2, y se encarga de responder automáticamente a todas aquellas consultas de DNS con nombres de dominio locales a la VPC, como por ejemplo, el DNS privado de una maquina EC2, así como de aquellas consultas a registros existentes en la PHZ asociada. Para el resto de nombres de dominio, Route53 Resolver, realiza búsquedas recursivas en servidores de nombres públicos.

Ahora bien, también es posible configurar este Route53 Resolver con reglas personalizadas para redirigir la resolución de determinados dominios a nuestro servidor de DNS favorito y aquí es precisamente donde entran los Route53 Resolver Endpoints.

Por un lado se encuentra el Inbound Resolver Endpoint, originalmente diseñado para que los servidores DNS de las instalaciones on-premise puedan delegar todas aquellas consultas relacionadas con los dominios alojados en AWS. Para ello proporciona una dirección IP (internamente representado mediante un ENI) que es capaz de emplear el Route53 Resolver de la VPC para resolver, valga la redundancia, aquellos nombres de dominio relativos a los PHZ asociados.

Dado que este endpoint se despliega en la VPC de DNS con la que se asocian todos los PHZ de todas las cuentas de la organización por entorno, automáticamente se convierte en un punto centralizado capaz de resolver cualquier dominio de AWS. Evidentemente la gracia reside en emplear este endpoint para resolver todos aquellos dominios no locales, tanto desde las instalaciones on-premise, como desde el resto de cuentas de AWS, y no, desplegar un Inbound/Outbound Resolver Endpoint por VPC no tiene ni pies ni cabeza, o no al menos desde el punto de vista económico.

¿Y cómo pueden el resto de VPCs redirigir sus consultas hacia el Inbound Resolver Endpoint? A través del Outbound Resolver Endpoint, claro está, servicio originalmente diseñado para que los servidores DNS de AWS puedan delegar todas aquellas consultas relacionadas con los dominios alojados en las instalaciones on-premise.

Por tanto, cada vez que una VPC requiere resolver un dominio de ámbito no local, es decir, no perteneciente a una PHZ asignada, lo delega sobre el Outbound Resolver Endpoint, quien posteriormente lo reenvía, bien al servidor de DNS de la infraestructura on-premise o bien al Inbound Resolver Endpoint, en función del caso de uso. En caso de tener aun algún duda, comentar que en la parte 2 del artículo de Networking se detallan en detenimiento cada uno de estos flujos.

Al tratarse de un servicio gestionado, permite que, a diferencia de otros productos, no requiera implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con Route53, faltaría más, así como con los servicios de observabilidad y auditoria propietarios de la nube.

En lo que a los limites del servicio se refiere, comentar que es capaz de resolver hasta 10.000 consultas por segundo e instancia, lo que debería ser suficiente para la mayoría de las organizaciones, siempre y cuando sigan el modelo de cuentas y despliegue descrito.

Finalmente, señalar que se factura bajo una modalidad de pago por uso, en concreto, por horas de uso, así como por el número de consultas recibidas, lo que le permite adaptarse a todo tipo de organizaciones y escenarios.

El ultimo elemento a describir el Route53 Resolver DNS Firewall, un servicio gestionado de Firewall autoescalable y altamente disponible, que permite bloquear las consultas de DNS a dominios potencialmente maliciosos, habilitando únicamente las peticiones a aquellos dominios de confianza.

Si bien en el del modelo de solución se representa únicamente junto a la VPC de DNS, todas las VPC disponen de su propio firewall que permiten securizar cualquier comunicación posible con el servidor de DNS.

Al tratarse de un servicio gestionado, permite que, a diferencia de otros productos, no requiera implementar y administrar la infraestructura, ni planificar o redimensionar la capacidad necesaria, ya que todo ello corre a cargo de AWS. Además, está perfectamente integrado con el resto de productos de la casa como el AWS Route53 o el AWS Firewall Manager, así como con los servicios de observabilidad y auditoria propietarios de la nube.

En lo que al funcionamiento propiamente dicho se refiere, se han de configurar reglas que determinen los dominios a permitir o bloquear, pudiendo personalizar las respuestas para aquellas consultas de DNS que hubieran sido rechazadas. Estas reglas se aplican tanto para consultas de DNS que se originan dentro de la VPC, como para aquellas consultas provenientes de un Inbound Resolver Endpoint. Eso si, únicamente es compatible con el tráfico de tipo DNS y UDP, no disponiendo de soporte para los protocolos HTTPS, SSH, TLS, o FTP, entre otros.

Al igual que en el WAF, es posible emplear el servicio de administración de seguridad denominado AWS Firewall Manager que permite la configuración y administración centralizada de reglas de los distintos filrewalls en todas las cuentas y aplicaciones de AWS Organizations. De nuevo, tal y como se describió en el artículo centrado en el accounting, debe estar alojado en la Security Tooling Account de la unidad organizativa de Security.

En esta ocasión, no hay nada llamativo a destacar de los limites del servicio, no al menos desde el punto de vista de la capacidad o del rendimiento.

Finalmente, señalar que se factura bajo una modalidad de pago por uso, en concreto, por cada dominio a filtrar, así como por el número de consultas recibidas, lo que le permite adaptarse a todo tipo de organizaciones y escenarios.

Conclusiones

En conclusión, se ha descrito un diseño de solución de red centralizado encargado de aglutinar la entrada, inspección, enrutado y salida de todo el tráfico de red de AWS, incluyendo la comunicación con la infraestructura on-premise.

Como siempre, estad atentos a futuros artículos en los que se detallarán en profundidad los diseños técnicos pendientes, como la segunda parte del networking, 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:

Networking on an AWS landing zone (Part 1)

Network account