Nelson: Alejandra, últimamente he estado pensando en algo que veo mucho en el mundo corporativo.

Alejandra: ¿Qué cosa?

Nelson: Que muchas veces las certificaciones terminan convertidas en una hoja de cálculo: personas certificadas, badges, métricas, cumplimiento… y sí, todo eso tiene valor. Pero me pregunto algo: ¿eso realmente garantiza que una persona pueda operar bien dentro del alcance de esa certificación?

Alejandra: O sea, ¿alguien puede aprobar el examen, pero no necesariamente saber llevar eso a la práctica?.

Nelson: Exactamente y es muy común. Puedes saber qué servicio usar para monitorear, alertar o remediar. Pero la pregunta real es otra: ¿lo sabes hacer?, ¿lo has hecho?, ¿lo puedes validar?, ¿entiendes qué riesgo estás reduciendo?

Esa conversación resume bastante bien la inquietud que me llevó a crear esta serie.

No estoy en contra de las certificaciones; al contrario, creo que certificarse ayuda a ordenar conocimiento, entender un alcance técnico y validar una base formal frente a un proveedor como AWS. El problema aparece cuando el proceso se queda solo en memorizar preguntas, ver videos, repetir respuestas y buscar pasar el examen.

Porque memorizar no es lo mismo que desarrollar capacidad operativa.

Y en cloud, como sucede con muchas otras tecnologías, tarde o temprano hay que operar. Hay que entrar a la consola, usar CLI cuando haga falta, configurar, validar, equivocarse, corregir, revisar logs, entender permisos, controlar costos, limpiar recursos y tomar decisiones con criterio.

El mercado no necesita únicamente personas certificadas, opino que el mejor escenario es otro: personas con capacidad operativa real que además, estén certificadas, ¡no lo contrario!.

La brecha

Hay muchos cursos buenos, bancos de preguntas, bootcamps y documentación. Todo eso suma. Pero veo un espacio que todavía puede trabajarse mejor, especialmente en español: laboratorios ejecutables que conecten directamente las guías oficiales de examen de AWS con habilidades prácticas.

No hablo de laboratorios sueltos ni de ejercicios genéricos. La idea es partir de los objetivos de las guías oficiales, entender el dominio, revisar la tarea que se espera dominar y llevar eso a una práctica concreta en AWS.

En otras palabras:

Guía oficial / blueprint → caso práctico → laboratorio ejecutable → checkpoints → cleanup → mirada Well-Architected

Porque nuevamente una cosa es leer que CloudWatch permite monitorear recursos y crear alarmas; otra cosa es configurar logs, crear métricas, definir una alarma, conectarla con SNS, probar si dispara, validar el flujo y limpiar todo al final para no dejar costos innecesarios.

Responder bien una pregunta no es lo mismo que ejecutar bien una práctica.

Qué significa aprender AWS

Para mí, aprender AWS no es solo saber que un servicio existe y que hace, es desarrollar criterio para entender cuándo usarlo, cuándo no, qué problema resuelve, qué costo introduce, qué riesgo reduce y cómo se comporta dentro de una arquitectura real.

En cloud casi siempre hay más de una forma de resolver un problema, pero no todas las respuestas tienen la misma calidad arquitectónica. Una opción puede funcionar, pero ser costosa. Otra puede ser segura, pero compleja de operar. Otra puede resolver el problema hoy, pero dejar una deuda enorme para el equipo que tenga que mantenerla mañana.

Por eso quiero que cada laboratorio tenga una conexión clara con el AWS Well-Architected Framework. No como decoración al final del post, sino como una forma de cerrar la práctica con criterio: operación, seguridad, confiabilidad, eficiencia, costos y sostenibilidad.

Porque que algo funcione no significa necesariamente que esté bien diseñado.

Por qué Digital Cafe Luna

Para darle continuidad a la serie voy a usar una empresa ficticia llamada Digital Cafe Luna.

Es un digital coffee shop: un espacio donde personas del mundo tech, profesionales remotos, freelancers... pueden trabajar, reunirse, tomar café y compartir comunidad.

Digital Cafe Luna empieza como una tienda física pequeña, un negocio local que poco a poco va creciendo. Primero necesita operar mejor su infraestructura básica; luego empieza a vender online, aparecen nuevas sedes, más usuarios, más datos, más riesgos, más costos y más necesidad de automatización.

Ahí es donde AWS entra en la historia. No porque sí, sino porque el crecimiento del negocio empieza a exigir capacidades reales: observabilidad, seguridad, disponibilidad, control de costos, gobierno, automatización y operación cloud.

A quién va dirigida esta serie

Esta serie es para personas que están preparando certificaciones AWS, pero no quieren quedarse solo con teoría. También es para Cloud Engineers junior, intermedios o semi-senior que ya conocen servicios, pero quieren fortalecer ejecución.

También pienso en líderes técnicos, managers, directores de arquitectura, soluciones, operaciones o delivery que necesitan entender mejor lo que viven sus equipos. Porque colegas no basta con mirar la operación desde el escritorio; hay que entender qué decisiones se toman, qué restricciones existen, qué riesgos aparecen y qué implica realmente operar una plataforma.

Y, por supuesto, también pienso en personas que vienen de otros mundos profesionales y quieren entrar a cloud de forma práctica. En mis clases he visto contadores, médicos, personas de operaciones, empleados de restaurantes, negocios y muchas otras áreas.

A ellos también les puede servir una serie así.

El método

Cada laboratorio seguirá una estructura simple:

• Guía oficial / blueprint: partimos de un objetivo real del examen.
• Caso práctico: lo llevamos a un escenario de Digital Cafe Luna.
• Lab ejecutable: configuramos servicios reales en AWS.
• Checkpoints: validamos que cada parte funcione.
• CleanUp completo: eliminamos recursos para evitar costos innecesarios.
• Well-Architected lens: cerramos conectando la práctica con buenas decisiones de arquitectura.

La intención no es solo crear recursos. La intención es entender el caso, ejecutar, validar, equivocarse cuando toque, corregir y aprender.

Cadencia de publicación

Mi intención es publicar un laboratorio cada semana, siempre priorizando la calidad, la ejecución real y la validación.

El detalle completo estará en Dev.to, porque ahí puedo desarrollar el caso, explicar los pasos, incluir validaciones, comandos, cleanup y cierre técnico. LinkedIn será el punto de entrada: el espacio para abrir la conversación, compartir el gancho y conectar con quienes quieran ejecutar el laboratorio completo.

Qué viene primero

El primer laboratorio será:

SOA-Lab1 — Observabilidad mínima: CloudWatch Logs + Alarmas + SNS

Un punto sencillo para empezar, pero muy importante: si no puedes observar una carga, tampoco puedes operarla bien, mucho menos garantizar su disponibilidad.

Para cerrar

Esta serie no nace desde el ego de “miren lo que sé”. Nace desde una idea mucho más práctica: compartir mientras aprendo, ordenar conocimiento mientras lo explico y madurar capacidades mientras diseño laboratorios que otras personas también puedan ejecutar.

Mi invitación es simple:

• Planifica tu tiempo.
• Toma el control de tu aprendizaje.
• Ejecuta los laboratorios.
• Rompe cosas en ambientes controlados.
• Valida, corrige, limpia y repite.

Ahí es donde la teoría empieza a convertirse en habilidad.

Nos vemos en el primer laboratorio de Digital Cafe Luna.