Cloud Computing Fundamentals 5.1 - Conceptos de Networking para la Nube

El Terreno y el Mensajero

El día que la nube cobró sentido

Algo que hice cuando inicié mi camino en la nube hace poco más de 2 años fue entrar directo a la consola de AWS. Ni siquiera era mi propia cuenta, sino la de la empresa para la que entré a trabajar y con la cual inicié mi camino en IT.

La interfaz de AWS marea, y bastante. Más allá de eso, mi primera misión fue intentar entender qué era Lambda, qué era serverless y desplegar una de estas funciones. Eso sí, dicha Lambda también tenía que conectarse a RDS.

Claramente sentí bastante pánico. Me fui corriendo a buscar tutoriales en YouTube, la documentación de AWS y otros recursos más.

Finalmente lo logré: Lambda desplegada, bases de datos Postgres en RDS también. Aun así, faltaba algo importante: había que lograr que Lambda se conectase a la base de datos de forma segura. ¿Cómo lograrlo? Aislando la base de datos desde la propia configuración de red.

La confusión empeoró al sumarme a un huddle de Slack con otros compañeros que ya la tenían bastante más clara que yo:

• "Ah sí, habría que poner la RDS detrás de un Bastion Host"
• "Y si ponemos la Lambda en una VPC?"
• "Habría que colocar la base de datos en una subnet privada"

Yo solo podía pensar: "¿De qué diantres están hablando?"

Con el tiempo fui aprendiendo una que otra cosita de manera aislada, intentando conectar los puntos como si fuera un rompecabezas. Pero no fue hasta que hice un curso de red fantástico (te dejo link al final del artículo, a modo recompensa) que la nube, o más bien AWS en este caso, cobró sentido.

Hoy vamos a hablar brevemente de eso. Y digo "brevemente" porque el networking, o las redes de computadoras, es un mundo inmenso.

Además, en mi experiencia y opinión, no considero que tengas que aprender absolutamente todo lo relacionado a redes para operar con eficiencia y seguridad en AWS. Pero sí pienso que hay conceptos fundamentales que no hay que saltarse.

En esta entrada (la anteúltima de la serie Cloud Computing Fundamentals), te voy a presentar de manera ordenada:

• Conceptos clave de redes organizados en 4 bloques (en este post vamos a ver 2)
• Y cómo se conectan estos conceptos con AWS

Si para el final de este artículo sentís curiosidad por estos temas y te nacen las ganas de entenderlos a mayor profundidad, o alguna explicación te hizo más sentido que lo que leíste en otros lados, entonces me sentiré enormemente complacido.

Es más, no importa si algunas cosas no las entendés de entrada. Lo importante es que tu cerebro ya tome contacto con ellas, de modo que no te resulten totalmente desconocidas cuando decidas estudiarlas con otros recursos.

Vamos a desarmar este rompecabezas en dos partes lógicas: El Terreno y El Mensajero.

Bloque 1: El Terreno (Direccionamiento e Infraestructura Base)

Para construir cualquier cosa en la nube, primero necesitás delimitar tu terreno, tu espacio en el mundo, y saber cómo se identifican las máquinas.

Para ello, necesitás comprender 3 elementos.

1. La anatomía de una IP (Calle vs. Casa)

Todo host (lo que incluye una computadora) necesita de una dirección IPv4 para participar en la internet y prácticamente cualquier LAN.

Una dirección IP (como 192.168.1.50) no es un número aleatorio. Tiene dos porciones invisibles que tu computadora necesita descifrar:

• La porción de Red es el vecindario o la calle donde vivís.
• La porción de Host es el número exacto de tu casa.
• Para saber la diferencia entre ambas porciones, se utiliza la máscara de subred

2. Máscara de subred: Trazando las fronteras

Si la dirección IP nos dice la calle y la casa, la máscara de subred dibuja la línea exacta donde termina el vecindario y empiezan las propiedades privadas.

Una dirección IPv4 es un bloque largo de 32 bits. Tu computadora necesita una regla física para saber cuántos de esos bits identifican a la red (el vecindario) y cuántos quedan libres para los hosts (las casas).

Tradicionalmente, esa regla se escribía en un formato decimal bastante incómodo, como 255.255.255.0. Los números 255 actúan como un resaltador fluorescente: todo lo que está "tapado" por esos 255 es el nombre de la calle, y el 0 es el espacio reservado para los números de las casas.

3. Notación CIDR: Menos caracteres, más claridad

Escribir combinaciones como 192.168.1.50 con una máscara de 255.255.255.0 en cada configuración de red se volvió tedioso. Por eso nació la Notación CIDR (Classless Inter-Domain Routing), que es simplemente un atajo inteligente.

En lugar de escribir toda la máscara decimal, CIDR usa esa misteriosa barra diagonal (/) seguida de un número para indicarle a la nube exactamente cuántos bits están "resaltados" para la red:

• Decir 255.255.255.0 es exactamente lo mismo que poner un /24 al final (porque tres bloques de 255 representan 24 bits activados). Esto acorta el terreno a una sola calle interna con espacio para 256 IPs.
• Decir 255.255.0.0 es exactamente lo mismo que usar un /16 (16 bits para la red). Al liberar más espacio para las casas, ¡pasás a tener un terreno gigantesco con más de 65,000 IPs disponibles!

En la nube, la notación CIDR es el lenguaje universal. Al definir tu bloque de red en AWS, un número chico como /16 te da un lienzo masivo para construir, mientras que números más grandes como /24 o /28 te permiten delimitar sectores pequeños y controlados dentro de tu arquitectura.

4. Subnetting: El secreto de la seguridad arquitectónica

El subnetting es, simplemente, poner rejas y subdivisiones dentro de tu terreno para mantener el orden y la seguridad. En AWS, esto se traduce en subnets:

• Subnet Pública (La entrada o living de la casa): Abierta a internet. Acá ponés lo que tus usuarios necesitan ver (como tu servidor web o un balanceador de carga).
• Subnet Privada (La caja fuerte): Completamente aislada del exterior. Acá es donde obligatoriamente debe vivir tu base de datos (RDS).

¿Cómo se conecta esto con AWS?

• Amazon VPC (Virtual Private Cloud): Es tu data center virtual aislado. Al crearla, lo primero que hacés es definir su tamaño usando un bloque CIDR (ej. 10.0.0.0/16).
• Subnets de AWS (Públicas y Privadas): Dentro de la VPC es donde aplicás el subnetting real. Creás subredes más pequeñas (ej. /24) para separar tus servidores de bases de datos (en subnets privadas sin acceso directo) de tus balanceadores de carga o servidores web (en subnets públicas). Recordá el ejemplo que vimos.
  • Si planeás recibir visitas, los haces pasar al living, pero no los dejás pasar hacia donde está la caja fuerte. Lo mismo ocurre con un servicio o recurso que necesite tener conexión directa desde y hacia la internet pública, y para ello debés colocarlo en una subnet pública.
  • Del mismo modo, tu caja fuerte tiene que estar en un lugar que no sea visible para tus visitas. Si un servicio o recurso tiene que estar protegido desde el acceso del exterior, es decir, la internet pública, entonces colocalo en una subnet privada.

Bloque 2: El Mensajero (Protocolos, Puertos y Sockets)

Una vez que el vecindario está construido y las casas tienen número, las aplicaciones necesitan empezar a hablarse. ¿Cómo viaja la información?

1. Puertos y Sockets: ¿A qué ventanilla estás llamando?

Imaginate que tu servidor es un edificio de oficinas enorme con una sola dirección postal (su IP). Si un paquete llega al edificio, ¿a quién va dirigido? Para eso existen los puertos. Cada servicio atiende en una "ventanilla" o puerto diferente: la navegación web segura atiende en el puerto 443 (el famoso protocolo HTTPS), las bases de datos Postgres en el 5432, etc.

La combinación exacta de una dirección IP y un Puerto es lo que en redes llamamos un Socket (ej: 192.168.1.50:443). Es la coordenada definitiva de comunicación.

2. TCP vs. UDP: El cartero obsesivo vs. el repartidor veloz

En la capa de transporte, hay dos formas de enviar tus paquetes de datos:

• TCP (El Cartero Obsesivo): Antes de entregar nada, te hace firmar un contrato (handshake). Si un paquete se pierde en el camino, vuelve a buscarlo y te lo reenvía. Es lento pero 100% confiable. Ideal para tu base de datos o tu página web, donde es importantísimo que todo llegue a destino en tiempo y más que nada en forma.
• UDP (El Repartidor Veloz): No pide firmas, no pregunta si estás en casa. Solo pasa corriendo y tira los paquetes por la ventana, que sea lo que Dios quiera. Si algo se pierde, no le importa, sigue de largo. Eso sí, es increíblemente rápido. Ideal para transmisiones en vivo o videojuegos en línea, donde la velocidad de transmisión importa más que la confiabilidad.

El mapeo dentro de AWS

• Security Groups y NACLs (Network Access Control Lists): Son los firewalls de la nube. Cuando configurás una regla de entrada en un Security Group para permitir tráfico, AWS te pregunta: "¿Qué protocolo (TCP/UDP)? ¿Qué puerto (80, 443)? ¿Y desde qué IP/CIDR origen?" Entender puertos es lo que te evita dejar tus servidores expuestos al mundo por error.
• Elastic Load Balancing (ALB / NLB): Un Application Load Balancer (ALB) opera a nivel de aplicación (Capa 7 del modelo OSI, que veremos en la próxima parte), pero si necesitás gestionar millones de peticiones por segundo con ultra-baja latencia usando el protocolo TCP o UDP puro, AWS te ofrece el Network Load Balancer (NLB) que trabaja en el nivel de transporte (Capa 4 del modelo OSI).

Conclusión

Al principio de esta entrada te conté que en mis inicios todo esto me fue una tremenda confusión con su buena cuota de pánico.

Así estuve un par de meses. De hecho, ahí es donde empecé a prepararme para la certificación Solutions Architect Associate. Cuando se lo comenté a mi jefe, este me felicitó pero también me dijo: "Pausá la certificación un toque. Hacete un curso de redes. Eso es más importante".

Y qué razón tenía. El curso que elegí para dar mis primeros pasos, y que te hiper recomiendo hacer, es el fantástico Networking Basics de Cisco. Explicaciones super didácticas en video y texto, exámenes por capítulo con respuestas multiple o single choice, ejercicios en Packet Tracer (su software para emular redes). Nah, está espectacular. ¿Lo mejor de todo? Gratis. No tenés excusa para no aprender.

En fin, seguí el consejo de mi jefe, y a medida que iba profundizando e incorporando conceptos de red, todas esas siglas extrañas que vimos empezaron a cobrar sentido inmediato:

• ¿Te acordás de los Security Groups? No son magia; son simplemente porteros automáticos que configurás usando Sockets. Le decís al portero: "Solo dejá pasar tráfico que venga por el puerto 5432 (Postgres) si proviene de la IP exacta de mi función Lambda".
• ¿Y el famoso Bastion Host? Bueno, por un lado te cuento que es la solución que adoptamos para aislar esa RDS. Por otro lado, te cuento que simplemente es una instancia EC2 con una IP pública viviendo en una Subnet Pública. Funciona como una cabina telefónica segura: nos conectamos ahí desde internet, y desde esa cabina saltás de forma privada hacia la Subnet Privada donde la base de datos descansa en paz, lejos de los ojos del mundo.

Si algo quiero que te lleves de todo este recorrido, es esto:

Las herramientas en la nube van a cambiar, van a salir servicios nuevos con nombres locos y marketineros, pero la infraestructura y los "mensajeros" que corren por debajo siguen siendo los mismos estándares que están documentados hace décadas. Dominá el mapa, dominá los conceptos, y nunca más vas a sentir pánico en una consola de infraestructura.

En la próxima y úlltima parte de la serie Cloud Computing Fundamentals, vamos a cerrar esto repasando brevemente los últimos 2 bloques, con ejemplos, analogías y dibujitos:

• Bloque 3: Traducción de Direcciones y Salida a Internet
• Bloque 4: La Capa de Aplicación y la Identidad en la Web (Capa 7)