Fundamentos de la computación en la nube
Fundamentos de redes en la nube
Cómo trabajan juntos una red privada virtual, las subredes, los security groups, las network ACLs y un balanceador de carga para llevar la solicitud de un usuario, sin riesgos, desde internet hasta una base de datos privada, y a ningún otro lado.
- Explicar qué es una red privada virtual y por qué existe
- Distinguir subredes públicas y privadas, e identificar qué recursos pertenecen a cada una
- Comparar security groups y network ACLs según su alcance, su estado y el tipo de reglas que soportan
- Describir cómo un balanceador de carga reparte el tráfico entre destinos de cómputo
Llevar una solicitud desde internet hasta una base de datos privada, sin riesgos
2 lecciones atrás, la base de datos de un e-commerce estaba a salvo en una base de datos relacional, guardando pedidos que debían mantenerse consistentes con clientes e inventario reales. Esa base de datos es inútil si el navegador de un comprador no puede alcanzarla, y peligrosa si cualquiera en internet puede alcanzarla directamente. Las redes en la nube son la capa que resuelve esa tensión: llevan una solicitud desde el navegador de un usuario hasta el servidor de aplicación correcto y la base de datos correcta, mientras mantienen la base de datos en sí completamente inalcanzable desde el mundo exterior. Esta lección construye ese camino pieza por pieza.
La VPC: tu propia red privada, virtualizada
Una red privada virtual (VPC) es una red virtual lógicamente aislada dedicada a tu cuenta. Eliges un rango de direcciones IP para ella, y después agregas subredes, gateways y controles de seguridad, las mismas piezas que configurarías en una red física de centro de datos, salvo que no hay cableado ni hardware que instalar. Cada recurso que lanzas, una máquina virtual, una instancia de base de datos, vive dentro de una VPC, que es lo que le da sentido a la siguiente pieza: las subredes.
Subredes: públicas contra privadas
Una subred es un rango de direcciones IP dentro de una VPC, y, en AWS, una subred vive por completo dentro de 1 zona de disponibilidad, el mismo concepto de zona de la lección anterior, ahora aplicado a las redes. Lo que hace pública o privada a una subred no es su nombre sino su tabla de rutas: una subred pública tiene una ruta hacia un internet gateway, así que sus recursos pueden alcanzarse desde internet y pueden alcanzarlo; una subred privada no tiene esa ruta, así que nada fuera de la VPC puede alcanzarla directamente.
Esta es exactamente la forma de la arquitectura de referencia de RDS: los servidores de aplicación están en subredes públicas a través de 2 zonas de disponibilidad, alcanzables por los usuarios, y las instancias de base de datos están en subredes privadas en esas mismas 2 zonas, alcanzables solo por los servidores de aplicación dentro de la VPC, nunca directamente desde internet. Un recurso en una subred privada no queda cortado por completo, todavía puede alcanzar internet de salida, para descargar una actualización de software, por ejemplo, a través de un NAT gateway separado, pero nada de afuera puede iniciar una conexión hacia adentro.
Security groups y network ACLs: 2 candados distintos en 2 puertas distintas
Acertar con la ubicación es solo la mitad del trabajo. La otra mitad es decidir exactamente qué tráfico puede ver cada pieza, y AWS te da 2 herramientas distintas para eso, en 2 alcances distintos.
Un security group es un firewall virtual conectado a una instancia individual, como un portero parado en una sola puerta que recuerda a todos los que ha dejado entrar: una vez que permite una solicitud saliente, deja pasar automáticamente la respuesta correspondiente de vuelta sin volver a revisar su lista. Esa memoria es lo que significa "stateful". Un security group solo soporta reglas de permiso, y revisa todas sus reglas antes de decidir, ya que no hay nada que denegar, solo permiso que otorgar o negar.
Una network ACL trabaja a nivel de subred, más como la recepción de un edificio que revisa a cada persona que cruza el umbral, en cualquier dirección, contra una lista escrita, sin memoria de a quién dejó pasar hace 5 minutos. Eso es "stateless": una network ACL soporta reglas de permiso y de denegación, y se detiene en la primera regla que coincide, revisadas en orden, en vez de repasar todas las reglas como hace un security group.
| Propiedad | Security group | Network ACL |
|---|---|---|
| Se aplica a | Una instancia | Toda una subred |
| Tipos de regla | Solo permiso | Permiso y denegación |
| Evaluación de reglas | Revisa todas las reglas antes de decidir | Se detiene en la primera regla que coincide, en orden |
| Tráfico de retorno | Permitido automáticamente (stateful) | Debe permitirse explícitamente (stateless) |
La guía oficial de AWS es usar security groups como tu control de acceso principal y agregar network ACLs como una capa secundaria y más gruesa encima. La razón es directa: una network ACL protege toda la subred, así que sigue funcionando como respaldo incluso en el caso poco frecuente de que una instancia se lance sin el security group correcto adjunto. 2 capas que pueden fallar de forma distinta te protegen mejor que 1 capa que tiene que ser perfecta siempre.
El balanceador de carga: repartir el tráfico entre destinos saludables
Recuerda el escalado horizontal de la lección de cómputo: agregar más instancias del mismo tamaño en vez de redimensionar una. Repartir la carga entre 4 servidores de aplicación idénticos solo funciona si algo decide cuál de los 4 atiende cada solicitud entrante, y ese algo es un balanceador de carga. Un balanceador de carga se ubica frente a un grupo de destinos, revisa la salud de cada uno con health checks, y enruta el tráfico solo hacia los destinos que están pasando esas revisiones en ese momento, evitando automáticamente una instancia que dejó de responder.
El camino completo, ensamblado
Junta cada pieza de esta lección y el camino que en verdad recorre una solicitud se ve así: la solicitud de un usuario entra a la VPC por un internet gateway, llega a un balanceador de carga, que la enruta hacia uno de varios servidores de aplicación saludables ubicados en una subred pública, protegidos por el security group de esa instancia. El servidor de aplicación entonces entra a una subred privada para leer o escribir la base de datos, una conexión permitida solo porque ambos lados están dentro de la misma VPC, nunca porque la base de datos sea alcanzable desde internet. Una network ACL vigila cada límite de subred en todo el trayecto, como el respaldo de grano grueso detrás de cada security group.
Dónde te deja esto
Las redes no son una sola configuración, son una pila de decisiones: en qué subred vive un recurso decide si internet puede alcanzarlo siquiera, los security groups deciden exactamente qué tráfico llega a una instancia específica, las network ACLs respaldan eso a nivel subred, y un balanceador de carga decide cuál de varias instancias saludables responde en verdad una solicitud dada. Cada servicio que cubrió este tema, cómputo, almacenamiento, bases de datos, vive en algún lugar dentro de esta red, y nada de eso es alcanzable, ni está protegido, sin ella. El siguiente tema de este dominio, Arquitecturas modernas en la nube, se construye sobre cada uno de estos bloques para cubrir los patrones que los equipos despliegan hoy en día: cómputo sin servidor, contenedores y microservicios, e infraestructura como código.