Tips para mejorar el networking en AWS

Que el networking es de las partes más importantes de una infraestructura, da igual si es en la nube o no, es algo que ya (casi) nadie niega. En AWS, con la posibilidad de crear organizaciones con múltiples cuentas surgió la necesidad de interconectar algunas de esas cuentas entre si y ahí comenzó a liarse todo mucho.

Estos son algunos de las bases (prefiero bases a trucos :)) que aplico para poder estar tranquilo cuando se trata de la fontanería en AWS. Y sí, algunos son básicos y los hemos escuchado desde el primer día pero no viene mal un recordatorio.

CIDRs #

Mucho antes de que saliese Amazon VPC IP Address Manager (IPAM) la gestión de los rangos de red, o CIDRs, era una auténtica pesadilla. Tanto si estás planteando una infraestructura desde el principio, como si te la has encontrado hecha, una de las primeras acciones a tomar es saber qué hay para poder pensar a dónde quieres llegar.

Esta es una lista de lo que tengo en cuenta cuando hay que jugar con CIDRs…

Hojas de cálculo everywhere #

Nada mejor que una hoja de cálculo con todas las cuentas, las VPCs y los CIDRs y donde puedas saber, de un vistazo, qué rangos hay disponibles y cuales están duplicados, entre otras cosas. Además, lo soportan todo y se puede actualizar fácilmente con todo tipo de información importante como la interconexión de las VPCs.

AWS IPAM está muy bien, es muy claro y sencillo de usar lo que sucede es que está organizado para servir a un amplio rango de usuarios y tiene las opciones e información que pueden servir a la mayoría de ellos. Una hoja de cálculo, por el contrario, tendrá exactamente la información que necesitas, ordenada según la necesitas y hasta con los colores que más te gustan. Es, en definitiva, una extensión de tu cerebro.

Máscara de red #

Suelo utilizar la mayor máscara de red posible para evitar que falten IPs y, a no ser que no pueda, utilizo una /16, aunque se trate de subredes que no van a necesitar un número elevado de direcciones. En AWS todo tiene, como poco, una tarjeta de red asociada, sino más y cada una de esas ENIs necesita una IP. Antes de que te des cuenta, la VPC de tu cuenta de producción ha dejado de levantar instancias porque las 50 disponibles te las has fundido con balanceadores, lambdas y demás servicios.

En una ocasión asigné un /24 a la VPC de un cliente que teóricamente usaría media docena de IPs y terminé destruyéndola para cambiar el rango a un /16 el día posterior a tenerlo todo montado. Al final, resultó que nos habríamos quedado sin IPs a los tres meses.

Rangos con cabeza #

Mi forma de organizar las cuentas y sus correspondientes rangos pasa por agruparlos por tareas, equipos, proyectos y clientes de tal forma que con saber a qué entorno de qué equipo tienes que acceder, ya sabes el rango. Y sí, lo de memorizar rangos de IPs es muy friki :D.

Imaginemos que tenemos que preparar CIDRs para un número desconocido de VPCs, en un número desconocido de cuentas y hacerlo escalable durante, al menos, dos años. Pues sabiendo esto, que es entro poco y nada, comenzamos…

• AWS nos dice que podemos asignar rangos de IPs desde /16 a /28 por lo que lo mejor es utilizar el mayor rango posible, /16
• Como queremos evitar solapamientos (aunque ya hay un montón de servicios que los soportan, la mejor política es evitarlos) podremos disponer de 256 rangos /16 antes de pisar ninguna IP.
• Si usamos un diseño habitual de 2 subredes por AZ (pública y privada) y dos zonas de disponibilidad, cada subred tendrá un rango /18 y 16377 IPs disponibles.

Mi forma de ordenar los rangos es la siguiente:

• 10.0.0.0/16 a 10.10.0.0/16 para VPC de acceso, seguridad, tooling, etc… cualquier VPC que tenga un uso comunitario, iría aquí.
• 10.10.0.0/16 a 10.20.0.0/16 para VPCs del proyecto principal. Además suelo dejar la primera del rango para el tooling o herramientas comunes a todas las VPC, luego va la de desarrollo, la de integración, la de producción y la de data. Si hay alguna necesidad extra, como una VPC extra para una determinada herramienta, se podría a continuación.
• 10.20.0.0/16 a 10.30.0.0/16 para VPCs del proyecto número dos, con el mismo esquema que el primero.
• 10.100.0.0/16 a 10.110.0.0/16 para VPCs de un cliente, manteniendo el mismo esquema que en el proyecto principal.
• 10.110.0.0/16 a 10.120.0.0/16 para VPCs de otro cliente.

Esta ordenación permite saber el rango de una VPC fácilmente con saber el entorno y proyecto o cliente. Por ejemplo, el de integración del primer cliente sería 10.100.2.0/16.

Bastión o VPN #

Voy a suponer que el lector o lectora que tenga implementado Zero Trust no tiene dudas de qué opción es mejor porque su respuesta es ninguno de los dos :). Pero, para el resto, en algún momento tuvimos que elegir entre desplegar unos cuantos bastiones o plantearnos la instalación de una VPN para el acceso a las capas privadas de la infra.

Antes de seguir, una aclaración: cuando digo VPN me refiero a las VPN de acceso remoto, no a las de punto a punto y que usan el protocolo IPSec habitualmente. Hablo de las VPN que permiten a alguien conectarse a una infraestructura utilizando certificados para autenticarse con programas como OpenVPN.

Quien me conoce sabe que los bastiones son mi última opción, justo por delante de borrar las cuentas en AWS pero, en algunas ocasiones pueden ayudar a acceder a la capa privada de la cuenta sin arruinar a la empresa en el camino. Si el número de usuarios es pequeño (y por pequeño me refiero a manejable), no hay suficiente gente para gestionar algo más complejo y no se dispone de mucho tiempo para poner en marcha la conectividad, un bastión puede ser la respuesta. Eso sí, no hay que olvidar que son vectores de entrada y que deben estar actualizados y securizados de todas las formas posibles.

Si el número de usuarios del bastión aumenta (yo pongo el límite en quince), o se requiere más de un bastión para dar soporte a diferentes zonas y hay que levantar más de uno, yo soy partidario de instalar uno o varios servidores VPN, a ser posible con un LDAP detrás para centralizar la gestión de los usuarios. Hay multitud de plantillas para desplegar OpenVPN en AWS y, si se hace con el bastión en funcionamiento, se puede ir pasando a la gente de un sistema a otro con relativa tranquilidad.

Así que la respuesta a la pregunta, ¿qué es mejor, un bastión o una VPN?, la respuesta es depende…

VPC Peering o Transit Gateway #

Otro de esos casos de cuál es mejor… Y la respuesta, aunque análoga a la de las VPN y los bastiones, depende casi completamente en el gasto asociado al servicio.

Porque la Transit Gateway es una pieza de software formidable pero cara y no compensa tenerla para unas pocas cuentas. Facilita enormemente la gestión de peerings y VPNs (punto a punto, no las del punto anterior) y lo que era una maraña de conexiones, Route tables y transitividad desaparece. Porque la TGW factura por el número de conexiones y la cantidad de tráfico que la atraviesa con lo que hasta que no tengas más de 25 peerings (¡¡estimación a ojo!!) no te empieza a compensar. Desde que el tráfico de los VPC Peering es gratuíto dentro de la AZ, hay que generar mucho tráfico entre cuentas y con el exterior para dar el salto. E incluso, con una TGW a pleno rendimiento se suelen eliminar los NAT gateways de las cuentas privadas y se redirije el tráfico saliente a una cuenta especial que centraliza ese servicio para ahorrar los 75 dólares al mes que cuesta cada NATGW, tráfico aparte.

Con esto quiero dejar claro que es una cuestión de dinero y que sólo al alcanzar un nivel de gasto considerable comienza a ser una buena opción la instalación de una transit gateway y que, incluso entonces, se trata de recortar algo del gasto asociado.

Prometo que mi intención era contar cuatro cosas de nada en una entrada ligera y rápida de leer…