El Curso del Líder Cloud (The Cloud Leader Course)

De cero conocimiento a liderar con fluidez un equipo de ingenieros cloud.

Cómo funciona este curso

Usted no se está formando para ser ingeniero cloud. Se está formando para liderar ingenieros cloud: para seguir cada conversación en la sala, hacer las preguntas que importan, tomar buenas decisiones sobre dinero, riesgo y personas, y ganarse el respeto de los expertos sin fingir ser uno de ellos. Esa es una habilidad distinta y totalmente aprendible — y es la habilidad que este curso enseña.

El curso tiene tres etapas. Etapa 1 (Semanas 1–8): Hable el idioma. Aprende qué es realmente la nube (cloud) y el vocabulario de cada componente básico, para que las reuniones dejen de sonar a ruido. Etapa 2 (Semanas 9–16): Piense como la sala. Arquitectura, seguridad y dinero — las tres conversaciones que todo equipo cloud tiene cada semana, y las tres donde un líder aporta valor o queda ignorado. Etapa 3 (Meses 5–24): Lidere. Certificaciones, contratación, dirigir reuniones de decisión, y el camino honesto de dos años para sostenerse por sí mismo frente a ingenieros senior.

Reglas para todo el curso: estudie una hora al día, seis días a la semana — la constancia vence a la intensidad. Cada módulo termina con un Drill de fluidez (frases que usted dice en voz alta hasta que le salgan con naturalidad) y un Hito (la prueba de que está listo para avanzar). Hágalos; leer solamente construye reconocimiento, no fluidez. Y desde la Semana 1, lleve un Diario de Decisiones: cada vez que aprenda un concepto, escriba una frase sobre cómo afecta al dinero, al riesgo o a las personas — porque esa traducción es todo su trabajo.

ETAPA 1 — HABLE EL IDIOMA (Semanas 1–8)

Módulo 1 (Semanas 1–2): Qué es realmente la nube

La gran idea: la nube es las computadoras de otro, alquiladas por hora, gestionadas por software. Antes de la nube, una empresa compraba servidores físicos, los ponía en una sala y pagaba a gente para mantenerlos — lento, caro, inflexible. AWS, Microsoft Azure y Google Cloud construyeron almacenes con millones de computadoras (data centers, centros de datos) y permiten que cualquiera alquile porciones de ellas por segundo, desde cualquier lugar, a través de una página web o una línea de código. Eso es todo. Todo lo demás en este curso es detalle sobre esa única idea.

Los tres grandes proveedores, definidos:

Su cuenta gratuita de AWS — configúrela en la Semana 1. Vaya a https://aws.amazon.com/free y haga clic en “Create a Free Account” (la página directa de registro es https://signin.aws.amazon.com/signup?request_type=register). Necesitará una dirección de correo electrónico, un número de teléfono y una tarjeta de crédito/débito para verificación de identidad — el Free Tier (capa gratuita) le da una asignación mensual gratuita de los servicios básicos (incluidas 750 horas/mes de un servidor EC2 pequeño durante su primer año), y los ejercicios de este curso se mantienen dentro de ella. Dos hábitos de seguridad desde el primer día: active MFA (el Módulo 6 la explica) y configure una alerta de facturación en $5 (el Módulo 7 explica cómo) para que nunca pueda llevarse una sorpresa. Tras el registro, usted inicia sesión en https://console.aws.amazon.com — la “console” (consola) es simplemente la página web de control de AWS.

Por qué las empresas usan la nube: velocidad (un servidor nuevo en 60 segundos en lugar de 6 semanas), elasticidad (alquile 100 servidores para el gran día de rebajas y devuelva 90 al día siguiente), sin costo inicial (gasto operativo en lugar de gasto de capital) y alcance global (ponga su aplicación cerca de sus clientes en Bangkok, Tokio y Fráncfort sin construir nada).

Las tres capas de servicio — el modelo mental más útil del cloud:

Regiones y zonas de disponibilidad: una Región es un grupo geográfico de centros de datos (Tailandia tiene su propia Región de AWS desde enero de 2025, en Bangkok y sus alrededores). Una Availability Zone (AZ, zona de disponibilidad) es uno o más centros de datos aislados dentro de una región. Las aplicaciones que importan corren en al menos dos AZ, para que la falla de un edificio no las tumbe. Cuando los ingenieros dicen “we’re multi-AZ” (estamos en multi-AZ), quieren decir “un centro de datos puede incendiarse y seguimos en línea”.

Vocabulario:

Videos de este módulo (todos gratuitos, enlaces verificados):

Drill de fluidez — diga estas frases hasta que le salgan con naturalidad: “Is that workload on-prem or in the cloud?” (¿Ese workload está on-prem o en la nube?) · “Which region are we in — and are we multi-AZ?” (¿En qué región estamos — y somos multi-AZ?) · “Is this an IaaS approach or is there a managed service that removes the maintenance?” (¿Es este un enfoque IaaS o hay un servicio gestionado que elimina el mantenimiento?)

Ejercicios: (1) Cree su cuenta gratuita de AWS en https://aws.amazon.com/free — el propio flujo de registro le enseña más vocabulario que un capítulo de lectura. (2) Vea los cuatro videos de la tabla anterior (menos de 20 minutos en total). (3) En su diario: escriba la explicación de ascensor de la nube que le daría a un director de escuela tailandés de un solo aliento.

Hito: usted puede explicar IaaS vs PaaS vs SaaS con su propia analogía, y explicar por qué la apertura de la región de AWS en Bangkok importó a los bancos tailandeses (respuesta: latencia + residencia de datos — vea el Módulo 6).

Módulo 2 (Semanas 3–4): Los componentes básicos — cómputo, almacenamiento y bases de datos

Cómputo — los motores que ejecutan código. Una máquina virtual (VM/instancia) es una porción de un servidor físico que se comporta como una computadora completa; usted elige un tamaño (CPU/RAM) y paga por segundo que está encendida. Un container (contenedor) es una forma más ligera y rápida de empaquetar una aplicación para que corra de forma idéntica en cualquier lugar; Docker los empaqueta y Kubernetes (K8s) orquesta flotas de ellos — cuando escuche “K8s”, piense “el sistema que ejecuta y repara nuestros cientos de contenedores automáticamente”. Serverless (sin servidor; AWS Lambda) significa que usted sube solamente una función de código; la nube la ejecuta cuando se dispara y usted paga por invocación — sin servidores que gestionar en absoluto. El patrón a notar: VM → container → serverless es un control deslizante desde “más control, más mantenimiento” hasta “menos control, mantenimiento casi cero”. Los buenos equipos eligen por workload, no por moda.

Almacenamiento — tres formas. Almacenamiento de objetos (Amazon S3): un balde sin fondo para archivos — imágenes, videos, respaldos, datasets; barato, con durabilidad de once nueves, la respuesta por defecto a “¿dónde ponemos los archivos?” Almacenamiento de bloques (EBS): el disco duro virtual conectado a una VM. Almacenamiento de archivos (EFS): una unidad compartida que muchas máquinas montan a la vez. Luego los tiers (niveles): caliente (acceso frecuente, costoso) vs frío/archivo (Glacier — barato, lento) — mover los datos viejos a niveles fríos es una de las victorias de costos más fáciles que cualquier equipo puede lograr.

Bases de datos — dos familias. Relacional/SQL (MySQL, PostgreSQL; gestionadas como Amazon RDS/Aurora): datos en tablas con estructura estricta; la opción por defecto para dinero, pedidos, usuarios — todo aquello donde la corrección es sagrada. NoSQL (DynamoDB, MongoDB): flexible, masivamente escalable; la opción por defecto para datos enormes, rápidos y de forma más simple (sesiones, catálogos, feeds). “Base de datos gestionada” significa que el proveedor se encarga de los respaldos, los parches y el failover — los equipos deberían tener una razón fuerte para operar la suya propia.

Vocabulario:

Videos de este módulo:

Drill de fluidez: “Should this run on VMs, containers, or serverless — and what’s the operational cost of each choice?” (¿Debería esto correr en VMs, contenedores o serverless — y cuál es el costo operativo de cada opción?) · “Is that data hot or can it go to a cheaper tier?” (¿Esos datos son calientes o pueden ir a un tier más barato?) · “Why are we self-managing that database instead of using RDS?” (¿Por qué estamos gestionando esa base de datos nosotros mismos en lugar de usar RDS?)

Ejercicios: (1) En su cuenta gratuita: lance la instancia EC2 más pequeña y luego termínela. Suba un archivo a S3. Acaba de usar IaaS personalmente. (2) Pida a un asistente de IA que lo examine: “Dame 10 escenarios; yo responderé VM, container o serverless, y tú me calificas.”

Hito: dada cualquier aplicación simple descrita en una frase (“un sitio web donde los estudiantes piden el almuerzo”), usted puede nombrar en voz alta sus piezas de cómputo, almacenamiento y base de datos en 60 segundos.

Módulo 3 (Semanas 5–6): Redes, y cómo se hablan las piezas

La VPC — su vecindario privado. Una Virtual Private Cloud (nube privada virtual) es su propia sección cercada de la red del proveedor. Dentro hay subredes (subnets) — públicas (alcanzables desde internet, p. ej., servidores web) y privadas (inalcanzables, p. ej., bases de datos). La frase de seguridad más común que escuchará: “la base de datos está en una subred privada.” Si entiende por qué — los atacantes no pueden tocar lo que no tiene camino desde internet — entiende la mitad de la seguridad de redes.

La capa de tráfico: un balanceador de carga (load balancer) reparte el tráfico entrante entre varios servidores (y retira silenciosamente a los enfermos); el DNS (Route 53) traduce nombres como suempresa.com en direcciones; una CDN (CloudFront) almacena en caché su contenido en cientos de ciudades para que cargue rápido en todas partes; una API es la puerta que una pieza de software ofrece a otra — cuando los ingenieros dicen “we’ll expose an API” (expondremos una API), quieren decir “le daremos a otro software una forma controlada de usar el nuestro”; un API gateway es la recepción que gestiona esas puertas.

Conectando mundos: una VPN (túnel cifrado sobre internet) o Direct Connect (una línea física privada) enlaza las oficinas/sistemas on-prem de una empresa con su nube. Nube híbrida = operar tanto on-prem como en la nube (la mayoría de las empresas tailandesas); multi-cloud = usar más de un proveedor.

Vocabulario:

Video de este módulo: AWS Networking Basics — VPC & Subnets for Beginners — KodeKloud — https://www.youtube.com/watch?v=QM63dyA_4Pc (vea la primera mitad ahora; regrese por el resto después del Módulo 5).

Drill de fluidez: “Is the database in a private subnet?” (¿La base de datos está en una subred privada?) · “What happens when one web server dies — is the load balancer health-checking?” (¿Qué pasa cuando muere un servidor web — el balanceador de carga está haciendo health checks?) · “Are we exposing that as an API or is it internal only?” (¿Estamos exponiendo eso como una API o es solo interno?)

Ejercicios: (1) Pida a una IA que lo guíe para dibujar, en papel, la red de una app de entrega de comida: usuarios → CDN → balanceador de carga → servidores web (subred pública) → base de datos (subred privada). Dibújela tres veces hasta que pueda hacerla de memoria. (2) Encuentre el diagrama de arquitectura de su empresa o cualquier diagrama de ejemplo y encierre en un círculo cada caja que ahora puede nombrar.

Hito: usted puede esbozar ese diagrama estándar de tres capas en una pizarra y narrar el camino del clic de un cliente a través de él.

Módulo 4 (Semanas 7–8): Cómo trabajan los equipos cloud — DevOps, IaC y leer la sala

DevOps es la cultura de fusionar “las personas que escriben el software” (Dev) y “las personas que lo operan” (Ops) en un solo equipo que entrega cambios pequeños con frecuencia y seguridad, con la automatización haciendo el trabajo pesado. Su latido es el pipeline de CI/CD (canalización de integración y entrega continuas): cada cambio de código se construye, prueba y despliega automáticamente (Continuous Integration / Continuous Delivery). Cuando un equipo dice “it’s in the pipeline” (está en el pipeline), quiere decir que el robot lo está probando y enviando.

Infrastructure as Code (IaC, infraestructura como código) — la idea que lo cambió todo: en lugar de hacer clics por una consola para crear servidores, los ingenieros escriben archivos de texto que declaran la infraestructura (“dos servidores, un balanceador de carga, una base de datos, estas reglas de firewall”), y una herramienta (Terraform, CloudFormation) hace que la realidad coincida con el archivo. Por qué le importa a los líderes: los archivos viven en Git (control de versiones), así que cada cambio de infraestructura es revisado, reversible y auditable — la diferencia entre un taller y una fábrica.

Los rituales en los que se sentará: stand-up (15 minutos diarios: qué está hecho, qué sigue, qué está bloqueado — escuche los bloqueos; eliminarlos es su trabajo), sprint (una unidad de trabajo planificado de 1–2 semanas), retro (qué mejorar), post-mortem/revisión de incidente (después de una caída: análisis sin culpas de qué falló y qué lo prevendrá — la salud de un equipo se ve en si estos son honestos), on-call (guardia; la rotación de quién es despertado a las 3 a.m.; si el on-call es miserable, su mejor gente se irá — pregunte por él mensualmente).

Las métricas de salud que importan: uptime/disponibilidad (“tres nueves” = 99.9% ≈ 8.8 horas caído/año; cada nueve extra multiplica el costo), SLA (la promesa, con penalizaciones), SLO (el objetivo interno), MTTR (qué tan rápido se recupera — los equipos maduros optimizan la recuperación, no la fantasía de cero fallas), frecuencia de despliegue (los equipos sanos entregan cambios pequeños a menudo; el miedo a desplegar es una mala señal).

Vocabulario:

Videos de este módulo:

Drill de fluidez: “Is that change through the pipeline or was it manual?” (¿Ese cambio pasó por el pipeline o fue manual?) · “What did the post-mortem conclude, and what’s the prevention item?” (¿Qué concluyó el post-mortem, y cuál es la acción de prevención?) · “What’s our MTTR trending like?” (¿Cómo va la tendencia de nuestro MTTR?) · “Is this in Terraform, or did someone click it into existence?” (¿Esto está en Terraform, o alguien lo creó a punta de clics?) (esto último se llama “ClickOps”, dicho con el ceño fruncido).

Ejercicios: (1) Vea la discusión de un informe post-mortem real de un incidente (muchos son públicos — los informes de caídas de Cloudflare y AWS son famosos) y resúmalo en su diario en cinco frases. (2) Asista (o vea la grabación de) cualquier stand-up y anote los tres bloqueos que escuchó.

Hito — fin de la Etapa 1: usted puede sentarse en una reunión técnica de planificación de 30 minutos y seguir ≥80% de ella, y su diario lo demuestra: notas de una reunión real o simulada con cada acrónimo correctamente expandido. Este es también el momento de agendar el examen AWS Cloud Practitioner (CLF-C02) — 2–4 semanas de preparación enfocada sobre estos módulos es la norma publicada, y aprobarlo es su primera prueba externa.

ETAPA 2 — PIENSE COMO LA SALA (Semanas 9–16)

Módulo 5 (Semanas 9–10): Arquitectura — juzgar diseños sin dibujarlos

Su papel en una revisión de diseño no es diseñar — es interrogar. El marco que usa toda la industria es el Well-Architected Framework de AWS, seis pilares ante los cuales todo diseño debe responder: excelencia operativa, seguridad, confiabilidad, eficiencia de rendimiento, optimización de costos, sostenibilidad. Aprenda a fondo los tres en negrita; ahí es donde viven el dinero y el riesgo.

Confiabilidad, en palabras simples: todo falla tarde o temprano, así que los buenos sistemas lo asumen. Redundancia (ningún punto único de falla — dos de cada cosa importante), multi-AZ (sobrevivir la pérdida de un centro de datos), auto-scaling (escalado automático; máquinas añadidas/retiradas automáticamente según la demanda), respaldos que se prueban (un respaldo no probado es una esperanza, no un plan), RTO/RPO (Recovery Time Objective: cuánto tiempo podemos estar caídos; Recovery Point Objective: cuántos datos podemos perder — esos dos números son la conversación de recuperación ante desastres, y son decisiones de negocio, es decir, suyas).

El triángulo de los trade-offs (compromisos): rápido, barato, resiliente — elija dos. Cada discusión de arquitectura que usted arbitrará se reduce a en qué punto de ese triángulo necesita sentarse el negocio para este workload. Un sistema de pagos y un sitio de marketing no merecen la misma respuesta.

Las siete preguntas del líder — memorícelas; lo vuelven peligroso en cualquier revisión de diseño:

1. “What happens when this component fails?” (¿Qué pasa cuando falla este componente?) (siempre hay un “cuando”)
2. “What are the RTO and RPO, and who signed off on them?” (¿Cuáles son el RTO y el RPO, y quién los aprobó?)
3. “Where does this run — single AZ, multi-AZ, multi-region — and why?” (¿Dónde corre esto — una sola AZ, multi-AZ, multi-región — y por qué?)
4. “What will this cost per month at 10× today’s load?” (¿Cuánto costará esto al mes con 10× la carga de hoy?)
5. “What’s the simplest version that meets the requirement?” (¿Cuál es la versión más simple que cumple el requisito?) (la sobreingeniería es la enfermedad del junior; la simplicidad es la virtud del senior)
6. “What are we locked into, and what would leaving cost?” (¿A qué estamos atados, y cuánto costaría salir?) (el vendor lock-in es un precio, a veces vale la pena pagarlo — a sabiendas)
7. “Who else has built this before — are we inventing or assembling?” (¿Quién más ha construido esto antes — estamos inventando o ensamblando?) (prefiera los patrones aburridos y probados)

Drill de fluidez: practique entregar las preguntas 1, 4 y 5 en un tono cálido — aterrizan como sabiduría o como ataque dependiendo enteramente de la entrega. “Help me understand what happens if the cache goes down” (Ayúdeme a entender qué pasa si se cae la caché) vence a “did you think about failure?” (¿pensó en las fallas?).

Ejercicios: (1) Tome tres arquitecturas de ejemplo (pida a una IA que genere: un sitio de e-commerce, un backend de app móvil, una plataforma de analítica de datos) y aplique las siete preguntas a cada una, escribiendo las respuestas que esperaría. (2) Lea el resumen de una página de los pilares Well-Architected en https://aws.amazon.com/architecture/well-architected/.

Videos de este módulo:

Hito: en una revisión de diseño simulada (hágala con una IA en el papel del ingeniero), usted hace cinco preguntas sustanciales y resume correctamente el punto más débil del diseño al final.

Módulo 6 (Semanas 11–12): Seguridad y cumplimiento — la conversación que puede acabar con empresas

El modelo de responsabilidad compartida — lo primero que hay que entender: el proveedor asegura la nube en sí (edificios, hardware, hipervisores); usted asegura lo que pone dentro de ella (sus datos, reglas de acceso, configuraciones). La mayoría de las brechas son errores de configuración del cliente — un bucket de S3 dejado público, una clave de acceso filtrada — no fallas del proveedor. Así que “AWS is secure” (AWS es seguro) y “we are secure on AWS” (nosotros somos seguros en AWS) son frases distintas.

El vocabulario de la defensa: IAM (Identity and Access Management, gestión de identidades y accesos — quién puede hacer qué; lo más auditado del cloud), mínimo privilegio (least privilege) (todos reciben el acceso mínimo necesario — la regla de oro), MFA (autenticación multifactor; segundo factor en cada inicio de sesión humano — no negociable), cifrado en reposo y en tránsito (datos codificados en disco y en la red — lo mínimo esperable, siempre activo), cuenta root (la llave maestra — guardada bajo llave, nunca usada a diario), gestión de secretos (contraseñas/claves en una bóveda, nunca en el código), zero trust (confianza cero; verificar todo, no confiar en ninguna ubicación de red por defecto), penetration test (prueba de penetración; atacantes contratados que ponen a prueba sus defensas), ransomware (la razón por la que los respaldos probados y fuera de línea son un control de seguridad, no solo de operaciones).

PDPA — la ley de datos de Tailandia, y su ventaja de mercado. La Personal Data Protection Act es el GDPR de Tailandia: consentimiento requerido para recolectar datos personales, un deber de notificación de brechas en 72 horas, Data Protection Officers para procesadores a gran escala, y reglas sobre el envío de datos a través de fronteras. La aplicación se volvió real en 2025 — más de THB 21.5M en primeras multas, incluido un hospital multado por supervisar mal a un proveedor. Dos consecuencias para usted: (1) toda empresa tailandesa tiene ahora un problema de cumplimiento que a su empresa le pueden pagar por gestionar; (2) la residencia de datos — mantener los datos tailandeses en suelo tailandés — es un impulsor real que empuja workloads hacia las regiones de Bangkok. Este párrafo es la mitad de su discurso de ventas en Tailandia; apréndaselo al dedillo.

Las preguntas de seguridad del líder: “Who has access to production, and when did we last review the list?” (¿Quién tiene acceso a producción, y cuándo revisamos la lista por última vez?) · “Are we alerted on unusual access, or would we find out from the news?” (¿Recibimos alertas por accesos inusuales, o nos enteraríamos por las noticias?) · “When did we last restore a backup?” (¿Cuándo fue la última vez que restauramos un respaldo?) (no “¿tenemos respaldos?”) · “If we lost this dataset, is it a PDPA-notifiable breach — and could we notify within 72 hours?” (Si perdiéramos este dataset, ¿es una brecha notificable bajo PDPA — y podríamos notificar en 72 horas?) · “What did the last pen test find, and what’s still open?” (¿Qué encontró el último pen test, y qué sigue abierto?)

Vocabulario:

Video de este módulo: The AWS Shared Responsibility Model — Digital Cloud Training — 4 min — https://www.youtube.com/watch?v=ESPBBEK-cvo

Drill de fluidez: “Is that bucket public? Why?” (¿Ese bucket es público? ¿Por qué?) · “Least privilege — does the intern really need prod access?” (Mínimo privilegio — ¿el practicante de verdad necesita acceso a prod?) · “Where does the PDPA line sit in this design — what’s personal data here and where does it physically live?” (¿Dónde queda la línea de la PDPA en este diseño — qué son datos personales aquí y dónde viven físicamente?)

Ejercicios: (1) Lea una historia famosa de brecha por mala configuración cloud (Capital One 2019 es el clásico) y escriba la versión de tres frases para su diario. (2) Haga que una IA simule a un cliente que pregunta “¿por qué debería confiarle mis datos?” y practique la respuesta usando el lenguaje de responsabilidad compartida + PDPA.

Hito: usted puede explicar el modelo de responsabilidad compartida y el significado práctico de la PDPA a un dueño de negocio tailandés no técnico en menos de tres minutos — porque esa explicación es la reunión de ventas del MSP.

Módulo 7 (Semanas 13–14): El dinero — economía del cloud y FinOps

Aquí es donde un líder no ingeniero aporta valor más rápido, porque a la mayoría de los ingenieros nunca se lo enseñaron y el desperdicio es enorme — las encuestas encuentran consistentemente que aproximadamente un tercio del gasto en cloud se desperdicia.

Cómo corre el medidor: el cómputo se factura por segundo que está encendido (no por uso — un servidor ocioso factura completo; “lo dejamos corriendo” es el desperdicio clásico), el almacenamiento por GB-mes, y — la trampa famosa — el egress (salida de datos): los datos que fluyen hacia afuera de la nube cuestan dinero mientras que los datos que entran son gratis. Las grandes facturas de egress sorprenden a todos una vez; después de este módulo, a usted no.

El menú de precios: on-demand (bajo demanda; precio completo, flexibilidad completa) · instancias reservadas / savings plans (comprométase 1–3 años por 30–70% de descuento — la palanca más grande sobre un workload estable) · instancias spot (hasta 90% de descuento para trabajo interrumpible como los jobs por lotes) · rightsizing (ajuste de tamaño; la mayoría de los servidores están sobredimensionados; encogerlos es dinero gratis) · niveles de almacenamiento (Módulo 2) · auto-scaling como herramienta de costos (¿por qué pagar la capacidad de medianoche a precios de mediodía?).

FinOps es la práctica de hacer el gasto cloud visible, asignado y optimizado continuamente: etiquetado (tagging) de cada recurso con su dueño y proyecto (el gasto sin etiquetar es gasto sin responsable), showback/chargeback (mostrar a cada equipo su factura — el comportamiento cambia al instante), presupuestos con alertas (nunca descubra el sobregasto por la factura), y unit economics (economía unitaria) — la métrica del líder: no “nuestra factura es ฿800k/mes” sino “nuestro costo por transacción de cliente está bajando”. La credencial FinOps Certified Practitioner toma unas dos semanas y es, para un líder del lado del negocio, el certificado con mayor credibilidad por hora de todo el mundo cloud. Obténgala.

Las preguntas de dinero del líder: “What’s our cost per [customer/transaction/tenant], and which direction is it moving?” (¿Cuál es nuestro costo por [cliente/transacción/tenant], y en qué dirección se mueve?) · “What percentage of our steady workload is on reservations?” (¿Qué porcentaje de nuestro workload estable está en reservas?) · “What’s untagged?” (¿Qué está sin etiquetar?) · “What died but is still billing?” (¿Qué murió pero sigue facturando?) (discos huérfanos e IPs ociosas — toda cuenta los tiene) · “What would this bill look like at 10× growth — does our architecture get cheaper or more expensive per unit?” (¿Cómo se vería esta factura con un crecimiento de 10× — nuestra arquitectura se vuelve más barata o más cara por unidad?)

Vocabulario:

Video de este módulo: What is FinOps? — FinOps Foundation (oficial) — 2 min — https://www.youtube.com/watch?v=Y-c_xw9bHFw · luego el curso gratuito “Introduction to FinOps” en https://learn.finops.org.

Ejercicios: (1) Abra la calculadora de precios de AWS y cotice un sistema real pequeño (dos servidores, una base de datos, 500GB de almacenamiento, 1TB de egress) — el ejercicio de hacerlo una vez desmitifica toda conversación futura de costos. (2) Pida a una IA que interprete a un ingeniero defendiendo un servidor sobredimensionado; practique negociar el rightsizing con amabilidad.

Hito: tome (o agende) el examen FinOps Practitioner, y en una revisión simulada, encuentre cuatro problemas de costos en una factura de ejemplo que una IA genere para usted.

Módulo 8 (Semanas 15–16): Bootcamp de fluidez — juntando todo el idioma

Esta quincena es pura integración — la diferencia entre conocer las palabras y ser fluido en las reuniones.

Drill diario (30 min): haga que una IA genere una transcripción realista de reunión (revisión de diseño, retro de incidente o revisión de costos), con dos errores técnicos deliberados escondidos en ella. Su trabajo: resumir la reunión en cinco frases, atrapar los errores y escribir las tres preguntas que habría hecho. Alterne los tipos de reunión a diario.

El músculo de la traducción (15 min): tome una afirmación técnica por día y tradúzcala para tres audiencias — el CFO (dinero), un cliente (riesgo/beneficio) y un ingeniero junior nuevo (enseñanza). Ejemplo: “We’re moving the session store from the database to Redis” (Estamos moviendo el almacén de sesiones de la base de datos a Redis) → CFO: “reduce la carga de la base de datos y así aplazamos una ampliación de ฿2M” → cliente: “las páginas cargan más rápido en las horas pico” → junior: “Redis mantiene los datos calientes en memoria, así dejamos de martillar la base de datos con cada clic.”

Práctica de lectura (15 min): un artículo real de blog de ingeniería por día (el AWS Architecture Blog, o los blogs de ingeniería de Netflix/Grab — Grab es especialmente relevante: escala del sudeste asiático, mercado vecino al tailandés). Ahora entenderá el 70–80% de ellos. Busque el resto.

Su compañero de preparación de examen para esta etapa: el famoso curso completo gratuito — AWS Certified Cloud Practitioner (CLF-C02) 2026 de Andrew Brown en freeCodeCamp — https://www.youtube.com/watch?v=7HKot-brXFE (la edición anterior de 14 horas, también válida para el mismo código de examen, está en https://www.youtube.com/watch?v=NhDYbskXRgc). Véalo a 1.25× a lo largo de las Semanas 13–16; después de los Módulos 1–7 la mayor parte le parecerá repaso, que es exactamente la señal de que está listo.

Hito — fin de la Etapa 2, su examen de graduación: (1) Apruebe el AWS Cloud Practitioner si aún no lo ha hecho. (2) El desafío simulado: una IA interpreta a un ingeniero senior que le presenta una arquitectura defectuosa para un cliente tailandés de e-commerce; usted debe encontrar la base de datos en una sola AZ, el bucket de S3 público, la estimación de egress faltante y la consideración de PDPA ausente — y entregar la retroalimentación en un tono que haga que el “ingeniero” se sienta ayudado, no atrapado. Cuando pueda hacer eso, usted es conversacionalmente peligroso, a dieciséis semanas de haber empezado.

ETAPA 3 — LIDERE (Meses 5–24)

Módulo 9 (Meses 5–8): La certificación profunda y el piso técnico

Trabaje el material de AWS Solutions Architect Associate (SAA-C03) — 2–3 meses a su ritmo de una hora. Puede o no presentar el examen (como líder, el material es el valor; la insignia es teatro opcional), pero aquí es donde las regiones, las VPC, IAM y los precios dejan de ser vocabulario y se convierten en un sistema conectado en su cabeza. En paralelo, mantenga los drills diarios del Módulo 8 a media dosis. Esta es también la ventana para añadir fundamentos de Azure (nivel AZ-900) — Tailandia es un mercado empresarial muy orientado a Microsoft, y la alfabetización bilingüe (AWS+Azure) amplía sus conversaciones con clientes.

Módulo 10 (Meses 5–12, en curso continuo): Contratar y gestionar ingenieros

Contratar cuando no puede juzgar del todo la habilidad: la estructura vence al instinto. Use un circuito consistente: una conversación de filtrado que usted lidera (motivación, comunicación, cómo explican un proyecto pasado a un no ingeniero — si no pueden, también fallarán con sus clientes) + una entrevista técnica conducida por su bar-raiser (su #2 técnico o un contratista senior pagado) + una llamada de referencias donde usted hace exactamente la única pregunta que importa: “would you hire this person again for this role?” (¿volvería a contratar a esta persona para este puesto?). Vigile los dos arquetipos de fracaso: el conversador fluido sin profundidad (su bar-raiser los atrapa) y el experto profundo pero callado (a menudo oro en los equipos tailandeses, donde la modestia es cultural — no deje que el brillo en la entrevista pese más que la evidencia de trabajo real).

El #2 técnico — la decisión más importante de la aventura: contrátelo primero, páguele con equity significativo (10–20% si es un verdadero cofundador), y defina el trato explícitamente: él sostiene el estándar técnico y es dueño de las decisiones de arquitectura; usted es dueño de los clientes, el dinero, las prioridades y las personas; los desacuerdos entre ustedes ocurren en privado y se resuelven antes de que el equipo los vea.

Los rituales que hacen que los ingenieros se queden: 1:1s semanales o quincenales que son sobre ellos (carrera, fricción, energía — no informes de estado); un plan de crecimiento por escrito por persona (en el mercado tailandés con déficit de 70k talentos/año, el crecimiento y los presupuestos de certificación retienen mejor que el salario solo — pague cada certificación, con un bono de permanencia de 12 meses al completarla); crédito en público, corrección en privado; y protección implacable de su tiempo de concentración — un líder que cancela una reunión a mitad de sprint es un héroe.

Foros de decisión — cómo tomar decisiones técnicas que no puede evaluar del todo: para toda decisión grande, exija un documento de decisión de una página al ingeniero que propone: el problema, 2–3 opciones, costos, riesgos, recomendación. Luego dirija la reunión con sus siete preguntas del Módulo 5. Usted no es el arquitecto más inteligente de la sala y nunca necesita serlo — usted es la persona que hace que gane la opción mejor argumentada, a tiempo, con los trade-offs de dinero y riesgo hechos explícitos. Los ingenieros respetan esto profundamente cuando se hace con honestidad; anote quién predijo qué (su Diario de Decisiones otra vez) y revise las predicciones trimestralmente — eso los calibra a usted y a ellos.

Módulo 11 (Meses 6–24): La curva de credibilidad, con honestidad

La experiencia publicada en la literatura de liderazgo de ingeniería converge en esta línea de tiempo, y fingir lo contrario es la forma en que fracasan los fundadores no técnicos: ~90 días para dirigir el ritmo del negocio con competencia · ~6 meses para una efectividad básica (reuniones fluidas, decisiones estructuradas, equipo estable) · 12–18 meses antes de que sus instintos técnicos valgan mucho por sí solos · ~2 años antes de sostenerse genuinamente frente a ingenieros senior en trade-offs de arquitectura. Las mitigaciones mientras la curva sube: pida credibilidad prestada (su #2 presenta la mitad técnica de las reuniones de ventas — los clientes necesitan ver la banca de todos modos), nunca fanfarronee (el asesino de credibilidad más rápido; “I don’t know — walk me through it” (No lo sé — explíquemelo) es una frase de liderazgo), y deje que sus preguntas hablen por usted: un líder que pregunta “what’s our RPO and who signed off on it?” (¿cuál es nuestro RPO y quién lo aprobó?) suena a treinta años de cicatrices, y después de este curso, usted lo dirá en serio.

Módulo 12 (En curso): La capa del mercado tailandés

Incorpore los detalles de la Parte 5 del TSI como conocimiento operativo: la PDPA como deber de cumplimiento y como producto (§Módulo 6); las escaleras de partners (AWS Select necesita un puñado de personal certificado + 3 acuerdos lanzados; Microsoft Solutions Partner necesita un puntaje de capacidad de 70/100 — las certificaciones de su equipo son literalmente activos de ventas, otra razón para financiarlas); la promoción BOI para la propiedad extranjera del 100% de la empresa; las bandas salariales de Bangkok (junior ฿50–75k → arquitecto ฿180–280k/mes) para cotizar licitaciones y ofertas correctamente; y la matemática de ventas del momento — más de $27B en inversión aprobada de centros de datos, un mandato gubernamental cloud-first, y una brecha de habilidades de 70,000/año que su banca certificada existe para llenar.

El plan de estudios en una página

Unas palabras de cierre de su profesor. Dentro de dieciséis semanas usted seguirá cada conversación en la sala. Esa no es la línea de meta — es la licencia para empezar. La curva de dos años hasta el verdadero juicio técnico no es un muro; es un foso: cada semana que usted completa de ella es una semana que los fundadores no técnicos de sus competidores no completaron. Estudie a diario, registre cada decisión en su diario, nunca fanfarronee, y contrate a personas mejores que usted y haga que se alegren de haber venido. Ese es todo el trabajo.

Complemento de “The Thailand Strategic Investment (TSI)”, Parte 5. Las estimaciones de tiempo de preparación de certificaciones y las líneas de tiempo de liderazgo provienen de las fuentes allí citadas (CBT Nuggets, StudyTech, FinOps Foundation, First Round Review, The Pragmatic Engineer).