¿Cómo centralizar el Egress de nuestras VPCs?

El networking en AWS es uno de los puntos más importantes y, por desgracia, muchas veces no le prestamos la suficiente importancia. Al final, no deja de ser algo que viene derivado del mundo más OnPrem y muchas veces lo vemos como algo Legacy. También es verdad que muchas soluciones que se aplican a nivel de Networking vienen derivadas de interconectividad con el mundo OnPrem y pueden llegar a ser limitantes en nuestra evolución de cara a ser nativos en Cloud. A veces, podemos añadir ciertas funcionalidades a estas soluciones que nos pueden ayudar y hoy vamos a ver una de estas soluciones.

Antes de empezar hay que poner un pequeño disclaimer: esta solución no es válida para todos los casos de uso. En algunos casos, implantar esta solución puede añadir más complejidad y coste que utilizar una solución descentralizada. Por eso, en este post vamos a ver cómo centralizar el Egress de nuestras VPCs, para salir a internet de forma homogénea en todas las cuentas, sin tener que desplegar un NAT Gateway en cada cuenta.

¿Por qué centralizar el Egress?

Hay varios motivos por los cuales puede interesarnos centralizar el Egress. En ocasiones, puede ser por ganar cierto control o por ser una solución interesante de cara a ahorrar costes.

Si centralizamos el Egress en una sola cuenta y VPC, tenemos únicamente un punto de control, por lo que podemos llegar a implantar controles para securizar nuestra salida a internet y de esta forma limitar exfiltraciones de datos o incluso minería desde nuestras cuentas.

Es cierto que esto lo podemos hacer también de forma descentralizada y que podemos implantar controles vía GuardDuty y generar auto remediaciones, basándonos en los eventos que detectemos, pero controlar múltiples Egress puede ser muy complicado, además de generar costes adicionales.

Otro punto importante puede ser el ahorro de costes, pero aquí os avanzo que tenemos muchas aristas.

En el caso de una salida descentralizada, necesitaremos en cada cuenta salir por NAT Gateway y tiene coste, además si estamos en una cuenta productiva y la salida a internet es una parte importante de nuestra arquitectura, deberíamos de tener un NAT Gateway por AZ, ya que los NAT Gateways son recursos zonales.

A continuación, puedes ver ejemplos del coste para distintas regiones y modalidades:

Nota: sa-east-1 es probablemente la región más cara de AWS, por eso está en esta tabla con eu-west-1 (la región más habitual en Europa) y us-east-1 (la región principal en USA).

A esto habría que sumar el coste de salida de NAT Gateway que es de 0,05 Dólares por GB procesado.

Si optamos por un solo NAT Gateway en una AZ, tenemos que tener en cuenta el coste por cross-AZ, es decir, al estar algunas de las instancias en una AZ diferente al NAT Gateway que vamos a usar, tenemos un coste extra de 0,02 dólares por GB.

NAT Gateway puede ser un producto caro, pero si queremos centralizar el Egress tenemos que utilizar Transit Gateway, que también tiene coste, pero nos da otras funcionalidades y además no tiene coste adicional por AZ.

A esto habría que sumar el coste de salida de Transit Gateway que es de 0,02 Dólares por GB procesado y el coste de tener una VPC con NAT Gateway centralizado.

Vamos a ver varios ejemplos de coste, utilizando la calculadora de AWS, con diferente número de cuentas y GB procesados, para poder analizarlo.

Con 10 VPCs y 1 TB procesados:

Con 10 VPCs y 100 TB procesados:

Con 100 VPCs y 1 TB procesados:

Con 100 VPCs y 100 TB procesados:

Con 500 VPCs y 1 TB procesados:

Con 500 VPCs y 100 TB procesados:

Como podemos ver en los diferentes casos de uso, el precio varía mucho si vamos a utilizar HA en un modelo descentralizado y el consumo de datos, ya que este puede penalizar mucho.

En general, el coste entre una solución descentralizada sin usar los NAT Gateway en HA es un poco más económica que centralizar, pero en el momento que necesitemos HA a nivel de NAT Gateway la diferencia se dispara en favor de la solución descentralizada.

De ahí que al inicio del post tuviésemos un pequeño disclaimer, ya que esta solución no es válida para algunos casos de uso.

Si tu caso de uso es sencillo, sin muchas cuentas, sin necesidad de HA, seguramente no necesites utilizar este tipo de soluciones.

Pero si ya tenemos que desplegar un Transit Gateway porque requerimos una conectividad con On-Prem en nuestras VPCs o requerimos interconectividad entre ellas, en este caso, el attachment de Transit Gateway tiene que existir y, por tanto, ese coste ya no entraría en escena. En ese caso, esta solución gana muchos puntos.

Por otro lado, tenemos que tener en cuenta que NAT Gateway es una solución muy buena, pero que penaliza en los consumos altos, desplegar otra solución no suele ser recomendable, ya que hay que mantenerla. Pero si tenemos gran cantidad de cuentas y VPCs podemos estudiar otras soluciones utilizando NAT Instances como alterNAT o incluso un appliance de un Vendor si lo requerimos por otras causas, pues al utilizar un Internet Gateway directamente estas soluciones tienen un coste de networking mucho menor (menos de la mitad).

Estas soluciones no se suelen recomendar, puesto que son más complejas de gestionar y tienen mucha carga de operación, algo que nos penaliza mucho en modelos descentralizados, pero en una solución centralizada como esta, estas restricciones cambian. En este caso podemos primar soluciones más económicas, aunque sean más complejas, porque van a dar servicio a muchos proyectos y el coste operacional se distribuye en muchos proyectos.

Si además necesitamos filtrar el tráfico de salida, de cara a bloquear ciertos contextos o bloquear la conectividad con direccionamientos maliciosos, podemos utilizar un servicio como Network Firewall.

Desplegar este servicio en un modelo descentralizado tiene sus pegas, porque es más costoso (requiere un endpoint por Egress en cada AZ) y la gestión se complica bastante. Mientras que en un modelo centralizado es más económico y también es más sencillo de operar.

Arquitectura de Egress centralizado

La arquitectura consiste en utilizar un Transit Gateway conectado a todas las VPCs de forma que enrute la salida a internet a través de una VPC de Egress. En esta VPC de Egress se desplegará un Network Firewall para que todo el tráfico hacia internet pase por este Firewall y así poder filtrar.

Es una solución en la que perfectamente se pueden cambiar piezas, por lo que podemos sustituir Network Firewall y NAT Gateway por una solución de Firewall Appliances de cualquier Vendor o sustituir NAT Gateway por una solución de NAT Instances como alterNAT.

Si no conocéis alterNAT os recomiendo que le echéis un ojo, ya que es una solución desarrollada por el equipo de ingenieros de Chile y que nos permite sustituir NAT Gateway por esta solución que desplegará NAT Instances de forma desatendida y sin requerir gestión adicional.

Ahora vamos a ver la configuración un poco más en detalle.

VPCs

La configuración dentro de cada VPC es bastante sencilla, siendo necesario desplegar un Transit Gateway Attachment en las AZs donde tengamos nuestras Subnets.

No es necesario desplegar el Attachment en las subnets que vayamos a enrutar, de hecho se puede desplegar en cualquier subnet, pero por organización y coherencia suele desplegarse en alguna de estas o en una subnet dedicada para ello.

A nivel de Routing añadimos una ruta para enrutar todo el tráfico por el Transit Gateway de forma que todo el tráfico a internet se enrute por el Transit Gateway, podemos añadir rutas específicas a otros destinos, si las quisiéramos.

El siguiente ejemplo sería válido para una VPC con subnets privadas y públicas, enrutando por el Transit Gateway solo las subnets privadas (ya que las públicas tienen que utilizar un Internet Gateway):

Transit Gateway

Transit Gateway se encarga de enrutar el tráfico hacia la VPC de Egress, de forma que es necesario generar las Tablas de rutas de Transit Gateway.

Si queremos aislar los entornos, podemos generar una tabla de rutas por cada VPC o una tabla de rutas por cada entorno que engloba varias VPCs o incluso utilizar solamente una tabla si queremos tener routing entre todas nuestras VPCs.

Adicionalmente, es necesario que exista una tabla de rutas con todas las VPCs para que la VPC de Egress pueda llegar a las VPCs que van a utilizar el Egress centralizado.

En este diagrama podemos ver un ejemplo en el que las VPC A y VPC B comparten Tabla de enrutamiento, teniendo rutas hacia sí mismas, hacia OnPrem via Direct Connect y hacia la VPC de Egress, pero tienen un BlackHole que corta el enrutamiento hacia las VPC C y D.

Las VPC C y D tienen también enrutamiento entre sí, con OnPrem y con la VPC de Egress, pero también tienen un BlackHole con las VPC A y B.

La VPC de Egress tiene enrutamiento contra todas las VPCs. Esto es necesario porque la ruta vuelta del tráfico utilizara esta tabla de rutas y, por tanto, requiere visibilidad de todas las VPCs.

De esta forma tenemos 2 entornos aislados entre sí, pero que utilizan la VPC Egress para la salida a internet.

Egress VPC

Dentro de la Egress VPC se desplegarán tanto los NAT Gateway como los Network Firewall Endpoints.

En este caso sí que tenemos una Subnet dedicada a Attachment de Transit Gateway, esto es debido a que no se recomienda desplegar nada en la Subnet de Network Firewall, ya que únicamente inspecciona elementos que crucen la subnet y no que tengan como origen o destino la propia subnet.

Se desplegará cada elemento en su propia subnet y con una tabla de enrutamiento en cada AZ, para direccionar el tráfico desde los Transit Gateway Attachment hacia los Network Firewall Endpoints y desde estos hacia los NAT Gateways y realizando el camino inverso para las respuestas desde Internet.

El siguiente diagrama muestra esta configuración:

Dentro de Network Firewall se desplegarán las reglas que queramos para filtrar el tráfico.

Network firewall tiene multitud de reglas que podemos aplicar: reglas gestionadas, reglas custom e, incluso, llegar a importar reglas stateful compatibles con Suricata.

Suricata es un proyecto opensource de ciberseguridad mantenido por la OSIF (Open Information Security Foundation).

Si vamos a usar Appliances, cada Vendedor tiene diferentes modelos de despliegue, pero son bastante similares, aunque si vamos a utilizarlos es necesario activar el appliance mode al desplegar el Transit Gateway Attachment de la VPC de Egress.

Conclusiones

Tal y como comentamos al principio, no es una solución válida para todos los casos de uso, pero es interesante en modelos que requieren soluciones más centralizadas o en caso de que ya tengamos desplegado Transit Gateway para interconectividad de VPCs u OnPrem.

Es una solución que se puede generar vía IaC sin problema, incluso en la parte que implica el despliegue de VPC de las cuentas para generar los attachments automáticamente.

Con esta solución centralizamos todo el tráfico de salida a internet y además podríamos añadir una capa de seguridad que no tenemos con un NAT Gateway.

A nivel costes, como hemos visto, puede no ser muy competitiva en entornos multicuenta pequeños, pero en entornos multicuenta grandes puede reducir nuestra factura considerablemente.

Es una solución que añade complejidad al centralizar recursos y al requerir cierta operación que en un modelo descentralizado gestiona cada proyecto. Pero hay que pensar que en entornos multi cuentas grandes o medianos en los que el control del Egress a internet puede ser crítico, esta solución mejora el nivel de control y, por tanto, la seguridad.