Fundamentos de AWS explicados con la analogía del barrio
Si estás aprendiendo cloud y sentís que todos hablan de Kubernetes y arquitecturas multi-cloud mientras vos todavía pelás con qué hace una VPC, frená. Los fundamentos de AWS (redes, subnets, security groups) son la base real de todo lo demás, y entenderlos bien vale más que memorizar 200 servicios.
Los fundamentos de AWS son el conjunto de conceptos de red y seguridad sobre los que se monta cualquier infraestructura en la nube de Amazon: VPCs, subnets públicas y privadas, routing tables, internet gateways, NAT gateways y security groups. No son servicios “avanzados” ni opcionales. Son la arquitectura que define qué recurso puede hablar con qué otro y quién entra desde afuera.
En 30 segundos
- Los fundamentos de AWS son redes y seguridad: VPC, subnets, routing tables, gateways y security groups, no la cantidad de servicios que sepas nombrar.
- Una VPC es como un barrio: las subnets públicas son las avenidas con acceso desde afuera, las privadas son las calles tranquilas donde viven tus bases de datos.
- Los security groups son stateful: si permitís la entrada en un puerto, la respuesta de salida se habilita sola.
- El error más común es meter una base de datos en una subnet pública por comodidad. Mala idea.
- El primer paso práctico: armá una VPC desde cero en vez de usar la default, que te esconde toda la complejidad.
¿Por qué el hype de Kubernetes y los servicios avanzados te hace sentir detrás?
Abrís LinkedIn o YouTube y parece que todo el mundo ya domina Kubernetes, arquitecturas serverless complejas y setups multi-cloud. Mientras tanto, vos seguís tratando de entender qué hace una VPC. Esa sensación de estar siempre corriendo de atrás la describe bien un post publicado el 10 de junio de 2026 en dev.to, donde el autor cuenta que sentía exactamente eso.
El problema es que ese FOMO empuja a saltearse los fundamentals. ¿Y qué pasa cuando alguien arranca directo con un cluster de Kubernetes sin entender networking? Exacto: el cluster no levanta, los pods no se comunican, y no tenés idea de por qué. La complejidad no desapareció. Solo la pateaste para adelante.
Acordate de esto: nadie construye una casa empezando por el techo. Saber qué es una subnet privada no es “básico” en el sentido peyorativo. Es la diferencia entre copiar comandos de un tutorial y entender qué estás haciendo. Tema relacionado: un pipeline de CI/CD bien estructurado.
¿Qué incluyen realmente los fundamentos de AWS?
Cuando uno arranca, piensa que aprender AWS es memorizar servicios y lanzar servidores. Pero la nube es mucho más grande que eso. El núcleo real son estos componentes de red:
- VPC (Virtual Private Cloud): tu red privada aislada dentro de AWS. Todo vive acá adentro.
- Subnets: subdivisiones de esa red. Públicas o privadas según tengan o no salida directa a internet.
- Routing tables: las reglas que deciden hacia dónde va el tráfico de cada subnet.
- Internet gateway: la puerta que conecta tu VPC con internet.
- NAT gateway: deja que recursos privados salgan a internet sin quedar expuestos a que les entren desde afuera.
- Security groups: firewalls a nivel de cada instancia que controlan qué puertos están abiertos y para quién.
Fijate que ninguno de estos es un “servicio que lanzás”. Son la columna vertebral sobre la que después corren EC2, RDS, los load balancers y todo lo demás.
¿Cómo entender una VPC sin explicaciones técnicas que te abrumen?
Acá viene lo bueno. El autor del post cuenta que todo le hizo clic el día que se explicó las VPCs a sí mismo con una analogía de barrio. Y la verdad es que funciona mejor que cualquier diagrama lleno de flechas.
La VPC es el barrio entero. Todo lo que pongas vive dentro de ese barrio, con sus límites bien definidos. Las subnets públicas son las avenidas principales: cualquiera puede transitarlas, tienen acceso desde afuera. Las subnets privadas son las calles tranquilas del fondo, donde viven los recursos sensibles como las bases de datos, lejos del tráfico de la calle. Complementá con elegir la herramienta de automatización correcta.
El internet gateway es la puerta de entrada al barrio. Y los security groups son los porteros en la puerta de cada edificio, decidiendo quién pasa y quién no. Una vez que pensás la red así, dejás de ver reglas aleatorias y empezás a ver una ciudad con lógica.
¿Cuál es la diferencia entre subnets públicas y privadas?
La diferencia es dónde colocás cada recurso y por qué. Una subnet pública tiene una ruta hacia el internet gateway, así que lo que pongas ahí puede recibir y mandar tráfico a internet de forma directa. Una subnet privada no tiene esa ruta: para salir necesita pasar por un NAT gateway, y nadie de afuera la alcanza sin pedir permiso.
| Aspecto | Subnet pública | Subnet privada |
|---|---|---|
| Acceso desde internet | Directo (vía internet gateway) | Ninguno entrante |
| Salida a internet | Directa | Solo vía NAT gateway |
| Qué poner ahí | Web servers, load balancers, bastion hosts | Bases de datos, servicios internos, backends |
| Riesgo de exposición | Alto, requiere security groups ajustados | Bajo por diseño |
| Analogía del barrio | Avenida principal | Calle tranquila del fondo |
El criterio es simple. Si algo necesita recibir tráfico del público (un sitio, una API expuesta), va en la pública. Si guarda datos o lógica que nadie de afuera debería tocar, va en la privada. Tu base de datos no tiene por qué ser accesible desde internet. Nunca.
¿Cómo controlan el acceso los security groups en AWS?
Seguimos con la analogía: si la VPC es el barrio, el security group es el portero parado en la puerta de cada edificio. Cada instancia EC2 tiene el suyo. Vos le decís qué puertos abrir y desde qué direcciones, y el portero deja pasar solo eso. Más contexto en estrategias internacionales en tu stack.
Lo importante acá es que los security groups son stateful. ¿Qué significa? Que si permitís una conexión entrante en un puerto, la respuesta de salida se habilita sola, sin que tengas que escribir otra regla. Esto los diferencia de las Network ACLs, que operan a nivel de subnet y son stateless (ahí sí tenés que definir entrada y salida por separado).
Ejemplos concretos de reglas que vas a escribir todo el tiempo:
- SSH en el puerto 22: para entrar a administrar la instancia. Limitalo a tu IP, no lo dejes abierto al mundo.
- HTTP en el puerto 80 y HTTPS en el 443: para que la web sea accesible.
- MySQL en el puerto 3306: abierto solo hacia el security group de tu backend, jamás hacia 0.0.0.0/0.
Un error en una de estas reglas y tenés un problema real: o no entra nadie, o entra cualquiera.
Errores comunes cuando recién aprendés AWS
Estos los comete gente real, todo el tiempo. Vale la pena anticiparlos.
- Meter la base de datos en una subnet pública: se hace “para que sea más fácil conectarse”. Es la receta para que te la encuentren escaneando puertos. Las bases van en privada, siempre.
- Confundir subnets con security groups: la subnet define dónde vive el recurso a nivel de red, el security group define quién le puede hablar. Son capas distintas y trabajan juntas, no es lo mismo.
- Creer que la VPC default es “AWS simple”: la default ya viene con subnets, routing e internet gateway armados. No es que no exista esa complejidad, es que te la esconde. Cuando algo falla, no sabés dónde mirar.
- Usar un security group como si fuera un firewall global: cada instancia tiene el suyo. No hay una regla única que proteja todo el barrio de una.
¿Cuál es el primer paso práctico para aprender bien?
Algo accionable: armá una VPC desde cero. No uses la default. Creá dos subnets, una pública y una privada. Lanzá una instancia EC2 en cada una. Después jugá con los security groups y fijate qué podés alcanzar y qué no.
Vas a romper cosas, no vas a poder conectarte a la instancia privada, te vas a confundir con las routing tables, vas a abrir un puerto que no debías y recién ahí, cuando lo tengas que arreglar a mano, el modelo mental se te va a fijar de verdad y ningún tutorial te lo va a poder quitar. El free tier de AWS te alcanza para experimentar sin gastar. Y si después necesitás montar un proyecto web sobre infraestructura más simple y con soporte en español, donweb.com tiene hosting y dominios pensados para Argentina.
Preguntas Frecuentes
¿Qué son los fundamentos de AWS?
Son los conceptos de red y seguridad sobre los que se monta cualquier infraestructura en AWS: VPCs, subnets, routing tables, internet gateways, NAT gateways y security groups. No son servicios avanzados, son la base que define cómo se comunican los recursos y quién accede desde afuera. Ya lo cubrimos antes en ejecutar agentes sin depender de APIs externas.
¿Qué es una VPC en AWS?
Una VPC (Virtual Private Cloud) es tu red privada aislada dentro de AWS, donde viven todos tus recursos. Pensala como un barrio con límites definidos: adentro organizás avenidas (subnets públicas) y calles tranquilas (subnets privadas) según qué tan expuesto querés que esté cada recurso.
¿Cuál es la diferencia entre una subnet pública y una privada?
Una subnet pública tiene ruta directa al internet gateway, así que sus recursos reciben y mandan tráfico a internet. Una subnet privada no la tiene: para salir usa un NAT gateway y nadie de afuera la alcanza. Web servers van en pública, bases de datos van en privada.
¿Por qué los security groups son stateful?
Porque si permitís una conexión entrante en un puerto, AWS habilita la respuesta de salida automáticamente, sin que escribas una regla extra. Esto los diferencia de las Network ACLs, que son stateless y exigen definir entrada y salida por separado.
¿Conviene aprender AWS desde cero o saltar a servicios avanzados?
Conviene empezar por los fundamentos de red y seguridad. Saltar directo a Kubernetes o serverless sin entender VPCs y subnets termina en errores que no podés diagnosticar. Los servicios avanzados se montan sobre estos conceptos, no los reemplazan.
Conclusión
El cambio importante no es técnico, es de mentalidad. Sentirse detrás porque otros hablan de arquitecturas complejas no significa que estés atrasado: significa que estás viendo el ruido de internet, no el camino real de aprendizaje. Los fundamentos de AWS (VPCs, subnets, security groups) son lo que te permite después entender cualquier servicio avanzado sin perderte.
Qué hacer concreto: dejá de memorizar nombres de servicios y armá una VPC a mano. Lanzá instancias en subnets públicas y privadas. Rompé cosas con los security groups y arreglalas. Esa práctica vale más que diez videos de Kubernetes que vas a entender recién cuando tengas la base sólida.
