Cloud Engineer es uno de los roles con mejor relación entre demanda y cantidad de perfiles disponibles. La razón es simple: todo lo que se construye hoy —aplicaciones, pipelines de datos, modelos de IA en producción— corre sobre infraestructura en la nube, y alguien tiene que diseñarla, automatizarla y sostenerla.

Esta guía ordena el camino: qué es realmente el cloud computing, qué proveedor elegir para empezar, qué certificaciones sirven y en qué orden aprender cada pieza sin perderse en la enormidad del ecosistema.

Qué hace un Cloud Engineer

No es "el que sabe AWS". El rol combina cuatro frentes:

• Diseñar infraestructura. Elegir qué servicios usar, cómo se conectan y cómo escalan cuando crece la demanda.

• Automatizar el aprovisionamiento. Que levantar un entorno completo sea un comando, no un procedimiento manual de dos días.

• Controlar costos. La nube es elástica en ambos sentidos: sin control, la factura se dispara. Optimizar gasto es parte del trabajo, no un extra.

• Garantizar seguridad y disponibilidad. Permisos mínimos, redes segmentadas, respaldos, planes de recuperación.

En equipos chicos el rol se solapa con DevOps y con SRE. En organizaciones grandes hay separación: el Cloud Engineer construye la plataforma y otros equipos la consumen.

La ruta de aprendizaje, paso a paso

Paso 1 — Fundamentos que no son "de nube"

Este es el paso que más gente se saltea y el que más problemas causa después. Antes de tocar una consola cloud, hace falta:

• Redes. Direcciones IP, subredes, DNS, puertos, firewalls. Sin esto, la mitad de los conceptos cloud son magia.

• Linux y línea de comandos. Navegar, permisos, procesos, logs, scripting básico en bash.

• Modelo cliente-servidor y HTTP. Qué pasa entre que alguien escribe una URL y ve una página.

• Git. Porque toda la infraestructura moderna se define como código versionado.

Dedicarle cuatro a seis semanas a esta base ahorra meses de confusión más adelante.

Paso 2 — Elegir un proveedor y quedarse ahí

AWS, Azure y Google Cloud comparten los mismos conceptos con nombres distintos. El error caro es estudiar los tres en paralelo. Criterios para elegir:

Si te cuesta decidir, este análisis comparativo entre AWS, Azure y Google Cloud desarrolla el criterio con más detalle. Una vez que dominás uno, migrar a otro lleva semanas, no años.

Paso 3 — Los servicios centrales

Cada proveedor tiene cientos de servicios; se empieza por cinco categorías:

1. Cómputo. Máquinas virtuales, contenedores y funciones serverless. Cuándo usar cada uno.

2. Almacenamiento. Objetos, discos y archivos. Clases de almacenamiento y su impacto en el costo.

3. Redes. Redes privadas virtuales, subredes, balanceadores, grupos de seguridad.

4. Identidad y accesos. Usuarios, roles y políticas. Es la puerta de entrada de la mayoría de los incidentes de seguridad.

5. Bases de datos gestionadas. Relacionales y NoSQL administradas por el proveedor.

Paso 4 — Infraestructura como código

Es lo que separa a un usuario de la consola de un ingeniero de nube. Terraform es la herramienta más transferible entre proveedores y su documentación oficial es un buen punto de partida; cada nube tiene además su alternativa nativa. Aprender a describir la infraestructura en archivos versionados, aplicar cambios de forma reproducible y revertir cuando algo sale mal es la habilidad más valorada del rol.

Paso 5 — Contenedores y orquestación

Docker primero, Kubernetes después. No al revés. Kubernetes tiene una curva empinada y sin entender contenedores no se sostiene. Si querés una introducción ordenada, esta guía sobre Docker y Kubernetes explica el punto de partida.

Paso 6 — CI/CD y observabilidad

Automatizar el camino desde el commit hasta producción, y saber qué está pasando cuando ya está corriendo: métricas, logs centralizados y alertas. Un sistema que no se puede observar no se puede operar.

Certificaciones: cuáles sirven y cuándo darlas

Las certificaciones no reemplazan la práctica, pero funcionan bien como filtro en procesos de selección y como estructura de estudio. El orden habitual:

• Nivel fundacional (AWS Cloud Practitioner, Azure Fundamentals, Google Cloud Digital Leader). Útil para ordenar vocabulario, poco peso en una entrevista técnica.

• Nivel asociado (AWS Solutions Architect Associate y equivalentes). Este es el que realmente mueve la aguja en búsquedas junior y semi-senior.

• Nivel profesional o especialidad. Recomendable recién con experiencia real; sin ella, el contenido queda abstracto.

La documentación oficial de certificaciones de AWS detalla los temarios y el formato de examen. Un consejo: rendí la certificación después de haber construido algo, no antes. Los exámenes actuales premian el criterio arquitectónico, no la memorización.

Qué proyectos armar para el portfolio

1. Una aplicación desplegada de punta a punta con infraestructura definida en Terraform, versionada en un repositorio público.

2. Un pipeline de CI/CD que despliegue automáticamente al hacer merge a la rama principal.

3. Un caso de optimización de costos: documentar una arquitectura, identificar el gasto innecesario y mostrar la versión optimizada.

El tercero es el menos común y el que más impresiona: demuestra que entendés la nube como decisión de negocio y no solo como tecnología.

Cursos recomendados de Coderhouse

Para recorrer el camino según tu punto de partida:

• Curso de Cloud Computing con AWS — el ingreso natural al ecosistema líder, con los servicios centrales cubiertos.

• Curso de DevOps y Cloud — nivel intermedio: automatización, contenedores y despliegue continuo.

• Curso de Ciberseguridad — complemento clave, porque buena parte del trabajo de nube es gestión de accesos y superficie de ataque.

• Curso de Python — el lenguaje más usado para scripting de automatización e integración con APIs de los proveedores.

• Carrera de Desarrollo Backend — si te falta la base de desarrollo que sostiene las decisiones de infraestructura.

Preguntas frecuentes

¿Necesito saber programar para ser Cloud Engineer?

Sí, aunque no al nivel de un desarrollador de aplicaciones. Se espera scripting sólido —Python o bash— para automatizar tareas, y capacidad de leer código ajeno. La infraestructura como código es, literalmente, escribir código. Sin esa habilidad el techo del rol aparece rápido.

¿Cuánto tiempo lleva convertirse en Cloud Engineer desde cero?

Entre diez y dieciocho meses con dedicación sostenida, contando los fundamentos de redes y Linux. Quien viene de desarrollo o de soporte de sistemas suele acortar ese plazo a la mitad, porque ya tiene resuelta buena parte de la base.

¿Qué diferencia hay entre Cloud Engineer, DevOps Engineer y SRE?

El Cloud Engineer se enfoca en diseñar y construir la infraestructura en la nube. El DevOps Engineer trabaja sobre el flujo completo de entrega de software, incluyendo cultura y automatización de procesos. El SRE se orienta a la confiabilidad del sistema en producción, con foco en métricas de disponibilidad. En equipos chicos, la misma persona cubre los tres.

¿Conviene empezar por AWS aunque la empresa donde quiero trabajar use Azure?

Los conceptos se transfieren casi por completo: una máquina virtual, una red privada o un rol de acceso funcionan con la misma lógica en las tres nubes. Dicho esto, si tenés un objetivo laboral concreto, estudiar directamente el proveedor que usa esa empresa te ahorra un paso de traducción.

¿Se puede aprender cloud sin gastar dinero?

Sí. Los tres proveedores principales ofrecen capas gratuitas con límites mensuales suficientes para practicar los servicios centrales. La precaución obligatoria es configurar alertas de facturación desde el primer día: la mayoría de los sustos con la nube vienen de un recurso que quedó encendido y nadie miró durante un mes.