Cómo Aprender Cloud Computing Desde Cero en 2026

Eran las 11 de la noche de un martes y estaba leyendo mi decimoquinto artículo comparando AWS con Azure. Los ojos se me cerraban. Tenía tres pestañas abiertas con calculadoras de precios, dos con gráficos de cuota de mercado, y una con un hilo de Reddit donde desconocidos se gritaban sobre serverless.

Llevaba dos semanas “aprendiendo cloud”. No había lanzado un solo recurso.

Y entonces mi compañero Dave — el tipo de persona que aprende las cosas rompiéndolas — me dijo que creara una cuenta de AWS y rompiera cosas. Así que lo hice. Lancé una instancia EC2 esa misma noche. No podía conectarme por SSH. Pasé una hora mirando las reglas del security group, intentando descifrar por qué el puerto 22 actuaba como una puerta cerrada con llave. A medianoche, lo había logrado. Y había aprendido más sobre redes en esa hora frustrante y llena de café que en dos semanas de artículos comparativos.

Eso es básicamente todo el artículo resumido. Aprendes cloud haciendo cloud.

Todo lo demás es solo tú, a las 11 de la noche, leyendo calculadoras de precios.

Lo que realmente necesitas antes de tocar una consola

No mucho. Pero si te saltas esto, cada mensaje de error va a parecer escrito en otro idioma.

Algo de redes. Qué es una dirección IP. Qué es una subred. Cómo funciona el DNS. Qué es un puerto. No hablo de sacarte el CCNA — solo lo suficiente para que cuando un security group bloquee tu tráfico, tengas una oportunidad de entender por qué. Dediqué dos tardes a ver los videos gratuitos de Network+ de Professor Messer. Fue suficiente. Dos tardes.

Las redes son un poco como las verduras que tienes que comer antes del postre. No es lo más emocionante. Pero es la diferencia entre “¿por qué diablos no funciona esto??” y “ah, el puerto 443 está cerrado.” Ese clic mental vale todo el aburrimiento.

Línea de comandos Linux. La mayoría de la infraestructura cloud corre sobre Linux. Necesitas que ls, cd, grep, ssh, chmod se sientan naturales. No a nivel experto. Solo que no te dé pánico. En Windows, instala WSL. Diez minutos.

Una idea general de VMs y contenedores. Una VM es una computadora simulada completa. Un contenedor es una caja aislada y ligera. Docker empaqueta aplicaciones en contenedores. Punto. No profundices todavía. Ya profundizarás cuando lo necesites, y tendrá mucho más sentido en ese momento.

Tres cosas. Esa es la lista. Pasé un mes intentando entender toda la teoría cloud antes de tocar una consola, y lo único que conseguí fue una carpeta de favoritos muy organizada y cero habilidades prácticas.

Elige uno y deja de dar vueltas

AWS, Azure o GCP. El debate eterno. He visto gente pasar más tiempo eligiendo un proveedor cloud que aprendiendo uno.

Lo que me hubiera gustado que alguien me gritara: todos hacen lo mismo a nivel fundamental. Compute, almacenamiento, redes, bases de datos, gestión de identidad. Si aprendes bien AWS, pasarte a Azure lleva semanas. No meses. Semanas. Los conceptos se transfieren.

Si no tienes ninguna preferencia clara: ve con AWS. Mayor cuota de mercado, más tutoriales, más ofertas de trabajo. Camino de menor fricción. Si tu empresa usa Azure, o te va más la data y el ML donde GCP brilla, ve con eso. Pero elige. El peor resultado posible es pasar un mes saltando entre los tres sin aprender ninguno.

Crea una cuenta de free tier. Y antes de hacer cualquier otra cosa — cualquier cosa — configura una alerta de facturación en $5.

Tengo que hablarte de la facturación porque estoy harto de ver gente quemarse. Mi amigo dejó un NAT gateway corriendo un fin de semana. $47 en su tarjeta de crédito el lunes por la mañana. Se quedó mirando el email como si fuera una multa de tránsito. No es dinero catastrófico, pero para un principiante que solo intenta aprender, es suficiente para cerrar la pestaña y no volver nunca. El free tier es generoso, pero tiene bordes invisibles. Configura la alerta.

Después, más o menos en este orden:

1. Lanza una instancia EC2. Conéctate por SSH. Instala nginx. Ve una página web. Siente un pequeño subidón de logro.
2. Pon un sitio estático en S3. Hazlo públicamente accesible.
3. Crea una base de datos RDS. Conéctate desde tu instancia EC2.
4. Escribe una función Lambda. Dispárala desde API Gateway. Mírala responder.
5. Configura usuarios IAM con diferentes permisos. Intenta hacer algo prohibido. Observa cómo falla.

No sigas los tutoriales como un robot. Cambia un parámetro. Quita una regla del security group. Mira qué se rompe. Ahí es donde realmente vive el aprendizaje.

Hablemos de proyectos

Primero tengo que ser honesto con algo. Le digo a todo el mundo que construya proyectos. Es el consejo correcto. Pero cuando yo empecé, no hice eso. Vi cuarenta horas de tutoriales de Kubernetes en YouTube, me sentí genial conmigo mismo, y cuando intenté desplegar algo de verdad me di cuenta de que no podía. El conocimiento de los tutoriales se evaporó en el segundo en que tuve que tomar una decisión real sin que nadie me llevara de la mano.

Es como ver a alguien cocinar un soufflé en YouTube y creer que sabes hacerlo. La confianza está ahí. El soufflé no.

Los proyectos te obligan a conectar los puntos de una manera que los tutoriales nunca logran. Un tutorial te enseña “así funciona S3.” Un proyecto te enseña “así funciona S3 cuando CloudFront está cacheando archivos viejos y tu policy IAM está ligeramente mal y CORS rechaza todo y llevas dos horas debuggeando y solo quieres cenar.”

Tres proyectos que me enseñaron mucho:

Un sitio portfolio con CI/CD. S3 para el hosting, CloudFront delante, un dominio conectado. Push a GitHub, se despliega automáticamente. Toca almacenamiento, redes, caché, automatización. Me llevó más tiempo del que me gustaría admitir. Pero cuando ese primer auto-deploy funcionó, levanté el puño. En mi escritorio. Solo. Sin arrepentimientos.

Una API serverless. Lambda detrás de API Gateway, hablando con DynamoDB. Procesar datos, devolver JSON. Ahí fue donde la “arquitectura event-driven” dejó de ser un buzzword y se convirtió en algo que realmente podía construir.

Un setup de monitoreo. Dashboards de CloudWatch y alertas SNS sobre una app corriendo. Es lo aburrido que separa “desplegué algo” de “podría mantener algo en producción sin que se incendie a las 3 de la mañana.”

Ponlos en GitHub. Escribe READMEs. Los reclutadores — lo digo como alguien que ha revisado cientos de CVs — valoran más un proyecto real con código imperfecto que una insignia de certificación sin nada detrás. Hay gente que no está de acuerdo conmigo. No pasa nada.

Especialízate después (en serio)

Cuando tengas algunos proyectos, elige una dirección:

• DevOps — Terraform, pipelines CI/CD, Kubernetes si te atreves
• Data engineering — data lakes, ETL, Redshift o BigQuery
• Seguridad cloud — IAM a fondo, cifrado, compliance

Yo estaba convencido de que me interesaba data engineering. Durante meses. Leí artículos. Planifiqué una trayectoria profesional. Y luego pasé un mes haciéndolo de verdad y descubrí que DevOps me apasionaba mucho más. Toda esa planificación, a la basura. Por eso exactamente tienes que explorar antes de comprometerte. Tu yo de dentro de tres meses va a tener opiniones diferentes al de hoy.

Los mismos errores de siempre

La trampa de los tutoriales. Ya te conté mi saga de Kubernetes. Cuarenta horas viendo, cero horas haciendo. Si no has abierto una consola esta semana, no estás aprendiendo cloud. Estás viendo a alguien más aprenderlo. Sé que la diferencia es difícil de sentir en el momento. Pero es real.

Olvidarse del dinero. La alerta de facturación. La he mencionado tres veces ya. Probablemente la mencione otra vez antes de terminar el artículo. El free tier tiene límites que no siempre son obvios. Una instancia olvidada por aquí, un exceso de transferencia de datos por allá.

Saltarse las redes. Ya lo dije. Lo repito. He visto demasiada gente pasar tres días peleando con security groups porque nunca aprendieron qué es una máscara de subred. No es glamuroso. No es negociable.

Certificarte antes de construir. Las certificaciones son útiles — estructuran tu aprendizaje y les dan algo a los reclutadores para filtrar. Pero una certificación sin práctica es solo trivia. Construye primero. Certifícate alrededor del mes cuatro o cinco. El examen será más fácil con contexto, y un GitHub con proyectos reales impresiona más que una insignia sola.

Siempre me preguntan: ¿necesito saber programar? No para empezar. Redes, almacenamiento, compute, IAM — nada de código. Pero en cuanto toques Lambda o Infrastructure as Code, Python o Bash se vuelve necesario. Apréndelo cuando lo necesites, no como prerrequisito. Se queda mejor cuando tienes una razón real.

Creo que ya cubrí todo. Probablemente me olvidé de algo. No pasa nada.

¿Listo para empezar a construir? Empieza a aprender hoy —>