El Curso de Arquitecto Cloud (The Cloud Architect Course)

De cero conocimiento a diseñar sistemas cloud a los que una empresa apostaría su negocio.

Cómo funciona este curso

Usted no se está formando para operar sistemas cloud. Se está formando para diseñarlos: para tomar un problema de negocio desordenado (“necesitamos venderle a un millón de clientes y no perder nunca un pedido”), convertirlo en un plan técnico dibujado, costeado y defendible, y luego persuadir tanto a los ingenieros que lo construirán como a los ejecutivos que lo pagarán. Ese es el trabajo de un arquitecto cloud (también anunciado como solutions architect, cloud solutions architect o cloud domain architect), y es un oficio aprendible con un plan de estudios claro — este.

El curso tiene cinco etapas. Etapa 1 (Semanas 1–6): Los componentes básicos, como decisiones. Cada componente cloud, re-enseñado no como un hecho sino como una elección con trade-offs (compromisos) — porque la unidad de trabajo de un arquitecto es la decisión. Etapa 2 (Semanas 7–14): Los dominios de diseño. Los seis pilares del Well-Architected Framework — confiabilidad, seguridad, rendimiento, costos, operaciones, sostenibilidad — cada uno enseñado a fondo con sus patrones estándar y un diseño trabajado. Etapa 3 (Semanas 15–20): El catálogo de patrones. La docena de arquitecturas que resuelven el 95% de los problemas reales, y — más importante — cuándo no usar cada una. Etapa 4 (Semanas 21–26): Migración y el mundo real. Mover empresas existentes a la nube, y las restricciones (ley, sistemas heredados, lock-in) que hacen la arquitectura real más difícil que la de pizarra. Etapa 5 (Meses 7–12): El oficio. Los documentos, diagramas, revisiones, presentaciones y certificaciones que lo hacen empleable como arquitecto, coronado por tres proyectos de diseño de calidad de portafolio.

Para quién es este curso. Asume cero conocimiento previo: todo aquello de lo que depende se re-enseña brevemente antes de usarse. Si usted ya completó El Curso de Ingeniero Cloud (o trabaja hoy con las manos en el cloud), la Etapa 1 le resultará familiar — hojéela, pero haga sus ejercicios de todos modos, porque re-enmarca cosas que usted conoce como hechos en cosas que debe sopesar como decisiones, y ese re-enmarcado es todo el cambio de ingeniero a arquitecto.

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 una tabla de Vocabulario (las palabras que debe dominar), Ejercicios (trabajo de diseño, no lectura — la arquitectura se aprende dibujando y decidiendo) y un Hito (la prueba de que está listo para avanzar; no se salte un hito sin cumplirlo). Y desde la Semana 1, lleve un Diario de Diseño: cada arquitectura que dibuje, cada trade-off que señale, cada predicción que haga sobre costos o fallas. Dentro de diez meses se convierte en su portafolio de entrevistas; nada impresiona más a un panel de contratación que un cuaderno fechado con cuarenta diseños y notas honestas sobre lo que salió mal.

Qué hace realmente un arquitecto cloud

Piense en una arquitecta de edificios. Ella no coloca ladrillos — pero debe saber exactamente qué pueden y no pueden hacer los ladrillos, cuánto cuestan y cómo fallan los edificios. Escucha a un cliente (“una casa familiar, soleada, dentro de este presupuesto, en este terreno complicado”) y convierte deseos y restricciones en planos y especificaciones lo bastante precisos como para que los constructores construyan a partir de ellos y el cliente los apruebe. Luego se queda durante la construcción, respondiendo preguntas y ajustando el plan cuando el suelo resulta más blando de lo que decía el estudio.

Cambie ladrillos por servidores y ese es el trabajo. Un arquitecto cloud pasa su semana haciendo alguna mezcla de: escuchar a los interesados del negocio y extraer requisitos reales de deseos vagos; diseñar — elegir componentes, dibujar diagramas, dejar por escrito las decisiones y el porqué; revisar los diseños de otros contra los seis pilares; estimar cuánto costará un diseño al mes y defender ese número ante finanzas; planificar migraciones de sistemas viejos hacia la nube; presentar — el mismo diseño explicado de una manera a los ingenieros y de una manera completamente distinta a los ejecutivos; y mentorar a ingenieros para que los estándares sobrevivan al contacto con los plazos. En muchos equipos también hay pre-ventas: sentarse junto a un vendedor frente a un cliente potencial, esbozando la solución que gana el trato.

Lo que un arquitecto no es: el mejor programador de la sala (normalmente no lo es), la persona que más teclea (es la que menos teclea), ni un genio solitario que baja planos desde el olimpo (la forma más rápida de ser ignorado). El producto real del arquitecto son buenas decisiones, escritas, que otros construyen de buena gana.

La descripción de puesto para la que se está formando

En agosto de 2026 recopilamos publicaciones y plantillas reales de puestos de Cloud/Solutions Architect — la plantilla de arquitecto cloud de un reclutador (KORE1), la descripción de puesto de una firma de staffing (4 Corner Resources), la definición del propio Microsoft del rol de arquitecto en el Azure Well-Architected Framework, una publicación de Solutions Architect de pre-ventas (Arpio, recuperación ante desastres en AWS), una publicación de Solution Architect empresarial (Intel, vía Built In) y una publicación empresarial de Cloud Domain Architect (Halliburton, Azure-first). Quite el sabor de cada empresa y los mismos doce requisitos aparecen una y otra vez. Este curso está construido según esa lista — aquí está exactamente dónde se enseña cada uno:

Certificaciones, verificadas contra el mismo mercado: la escalera estándar es AWS Certified Solutions Architect – Associate (SAA-C03) — la credencial individual más solicitada, típicamente 2–3 meses de preparación — seguida por AWS Certified Solutions Architect – Professional (SAP-C02), típicamente 4–8 meses más; los entornos con mucho Azure piden AZ-305 (Azure Solutions Architect Expert); las grandes empresas a veces añaden TOGAF para el método de arquitectura empresarial. El plan completo está en la Etapa 5, Módulo 14.

ETAPA 1 — LOS COMPONENTES BÁSICOS, COMO DECISIONES (Semanas 1–6)

Graduados del Curso de Ingeniero Cloud: hojeen las explicaciones, pero hagan todos los ejercicios. Los hechos son los mismos; las preguntas son nuevas.

Módulo 1 (Semanas 1–2): Qué es la nube, y cómo piensan los arquitectos

La nube en un párrafo (el repaso desde cero). La nube es las computadoras de otro, alquiladas por hora, gestionadas por software. AWS, Microsoft Azure y Google Cloud operan almacenes de servidores (data centers, centros de datos) agrupados en Regiones geográficas (p. ej., “Asia Pacific (Bangkok)”); cada región contiene varias Availability Zones (AZs, zonas de disponibilidad) aisladas — edificios separados con energía independiente, lo bastante cercanos para conexiones rápidas, lo bastante lejanos para que una inundación o un incendio no pueda tumbar dos. Usted alquila porciones de todo esto por segundo: máquinas en bruto (IaaS — usted gestiona todo lo que corre en ellas), plataformas gestionadas (PaaS — usted solo trae su aplicación) o software terminado (SaaS — usted solo lo usa). Ese es todo el sustrato. Todo lo que un arquitecto diseña se acomoda encima de él.

Ahora el movimiento del arquitecto: convertir cada hecho en una pregunta. Un ingeniero aprende “una AZ es un centro de datos aislado”. Un arquitecto pregunta de inmediato: “¿Cuántas AZ merece este workload?” — porque dos AZ cuestan más que una, tres más que dos, y un sitio de folletos de marketing no merece lo que merece un sistema de pagos. Esta es la primera y más importante idea del curso:

La arquitectura es la disciplina de hacer explícitos los trade-offs. Casi no hay componentes incorrectos — solo componentes incorrectos para este workload, este presupuesto, este equipo, este plazo.

El triángulo de los trade-offs. Todo diseño negocia entre tres esquinas: rápido (rendimiento — rápido para los usuarios, rápido de construir), barato (factura mensual baja, poco esfuerzo de ingeniería) y resiliente (sobrevive fallas, escala, se mantiene seguro). Usted puede empujar hacia cualesquiera dos esquinas; la tercera lo paga. El prototipo de una startup debe ser rápido y barato — la resiliencia puede esperar. El libro mayor central de un banco debe ser resiliente y rápido — no será barato. Cuando un interesado dice “queremos las tres”, su trabajo es sonreír y preguntar cuál quiere más, porque el diseño no puede empezar hasta que respondan. Dibuje este triángulo en la parte superior de cada diseño que haga en este curso, y marque dónde se sitúa el workload. Le ahorrará mil discusiones.

Requisitos: la materia prima del diseño. Los arquitectos separan los requisitos funcionales (qué hace el sistema — “los clientes pueden pedir el almuerzo”) de los requisitos no funcionales (NFRs) (qué tan bien debe hacerlo — “en menos de 2 segundos, para 10,000 estudiantes simultáneos, el 99.9% del tiempo, dentro de la PDPA”). Los principiantes se obsesionan con la primera lista; los arquitectos se ganan su salario con la segunda, porque los NFRs son lo que realmente determina la arquitectura. Dos preguntas mágicas extraen NFRs de interesados que no saben que los tienen: “¿Qué le pasa al negocio si esto está caído una hora?” y “¿Cómo se ve el éxito a diez veces el tamaño de hoy?”

Vocabulario:

Videos de este módulo (enlaces verificados):

Vea el recorrido de Fireship dos veces: una ahora para el mapa, otra al final de la Etapa 1 — se sorprenderá de cuántos servicios ya puede colocar en un diseño.

Ejercicios: (1) Elija tres apps que use a diario (una app bancaria, una de entrega de comida, una de video) y, para cada una, escriba sus tres NFRs principales y márquela en el triángulo de trade-offs. (2) Entreviste a un amigo sobre una idea de negocio durante diez minutos y extraiga cinco requisitos funcionales y cinco no funcionales — note cómo los NFRs solo salen cuando hace las dos preguntas mágicas. (3) Comience su Diario de Diseño con la entrada #1: el triángulo, y un párrafo sobre por qué “¿qué esquina sacrificamos?” es una pregunta de negocio, no técnica.

Hito: dada cualquier descripción de sistema en una frase, usted puede producir sus NFRs probables y su posición en el triángulo en cinco minutos, en voz alta, sin notas.

Módulo 2 (Semanas 3–4): Cómputo, almacenamiento, base de datos, red — las cuatro decisiones

Todo diseño que usted dibuje en su vida son estas cuatro elecciones, hechas deliberadamente. Aquí está cada una enseñada como decisión.

Decisión 1 — Cómputo: ¿VM, container o serverless? Una máquina virtual (VM) es una porción alquilada de un servidor que actúa como una computadora completa — máximo control, máximo mantenimiento (usted la parchea, usted la escala, usted paga mientras está ociosa). Un container (contenedor) empaqueta una aplicación con todo lo que necesita para que corra de forma idéntica en cualquier lugar; un orquestador (Kubernetes) ejecuta y repara flotas de ellos — gran densidad y portabilidad, pero usted ha adoptado una plataforma compleja que necesita gente capacitada. Serverless (sin servidor; AWS Lambda, Azure Functions) ejecuta su código solo cuando se dispara y factura por invocación — mantenimiento casi cero y perfecto para tráfico con picos, pero con límites (topes de tiempo de ejecución, cold starts, y un matrimonio más profundo con un solo proveedor). La tabla de decisión que debe poder reproducir de memoria:

La perspectiva senior: esta es una elección por workload, no una religión de empresa. Los parques reales corren las tres a la vez, correctamente.

Decisión 2 — Almacenamiento: ¿objetos, bloques o archivos — y qué tan caliente? El almacenamiento de objetos (Amazon S3) es un balde sin fondo para archivos — barato, absurdamente durable (“once nueves”), la respuesta por defecto a “¿a dónde van los archivos?” El almacenamiento de bloques (EBS) es el disco virtual atornillado a una VM. El almacenamiento de archivos (EFS) es una unidad compartida que muchas máquinas montan a la vez. La dimensión extra del arquitecto es la temperatura: datos calientes (accedidos constantemente, con precio de velocidad) versus niveles fríos/de archivo (Glacier — centavos, pero de minutos a horas para recuperar). Diseñar reglas de ciclo de vida que deriven los datos viejos hacia niveles fríos es la victoria de costos más barata del cloud; olvidarlo es lo más común.

Decisión 3 — Base de datos: ¿SQL o NoSQL (y cuál variante gestionada)? Las bases de datos relacionales/SQL (PostgreSQL, MySQL; gestionadas como RDS/Aurora) mantienen los datos en tablas estrictas con consistencia garantizada — el predeterminado para todo aquello donde la corrección es sagrada: dinero, pedidos, inventario, usuarios. Las bases de datos NoSQL (DynamoDB, MongoDB) intercambian estructura estricta por flexibilidad y escala horizontal casi ilimitada — el predeterminado para sesiones, catálogos, feeds, telemetría. La heurística de decisión: empiece con SQL a menos que pueda nombrar la razón específica por la que no funcionará (escala extrema, esquema flexible, lecturas globales de un dígito de milisegundos). Y en la nube, “base de datos” debería significar casi siempre “base de datos gestionada” — el proveedor se encarga de respaldos, parches y failover; un equipo que opera su propia base de datos en VMs debería tener una razón por escrito. Añada los especialistas a su vocabulario: caché (Redis — datos calientes en memoria, lecturas de microsegundos), warehouse (almacén de datos; analítica a escala — Etapa 3), cola (queue) (no es una base de datos, pero a menudo es la pieza faltante — Etapa 3).

Decisión 4 — Red: la forma del mundo privado. Una VPC (Virtual Private Cloud, nube privada virtual) es su sección cercada de la red del proveedor. Dentro de ella, las subredes públicas contienen lo que internet puede alcanzar (balanceadores de carga), y las subredes privadas contienen todo lo demás — servidores de aplicación y, siempre, las bases de datos. “La base de datos está en una subred privada” es la frase más repetida en las revisiones de arquitectura; el razonamiento — nada puede atacar lo que no tiene camino desde internet — es la mitad de la seguridad de redes. Alrededor de la VPC: un balanceador de carga (load balancer) reparte el tráfico entre servidores y esquiva a los enfermos; el DNS (Route 53) convierte nombres en direcciones; una CDN (CloudFront) almacena en caché el contenido en cientos de ciudades para que sea rápido en todas partes; un API gateway es la recepción gestionada de sus APIs (autenticación, límites de tasa, registro). Conectando con el mundo viejo: VPN (túnel cifrado sobre internet) o Direct Connect (una línea física privada) — los cordones umbilicales de todo diseño híbrido de la Etapa 4.

Vocabulario:

Videos de este módulo (enlaces verificados):

Ejercicios: (1) Para cada uno de estos cinco workloads, elija cómputo, base de datos y almacenamiento, y escriba una frase de justificación para cada uno: un sitio escolar de pedidos de almuerzo; el libro mayor de transacciones de un banco; una app para compartir fotos; un generador de informes nocturno que corre 20 minutos; una app de chat para 5 millones de usuarios. (2) Tome una de sus elecciones y defienda la elección opuesta tan persuasivamente como pueda — los arquitectos que no pueden defender con fuerza la alternativa no han entendido el trade-off. (3) Diario: su tabla de decisión de cómputo, de memoria.

Hito: dado cualquier workload en una frase, usted puede nombrar sus cuatro decisiones con justificaciones en menos de tres minutos — y para al menos una decisión, nombrar qué le haría cambiar de opinión.

Módulo 3 (Semanas 5–6): Leer y dibujar diagramas de arquitectura

Un arquitecto que no puede dibujar es un consultor que solo puede hablar. Los diagramas son su idioma de trabajo: este módulo lo hace fluido en leerlos y competente en dibujarlos.

El diagrama canónico — aprenda este primero. La arquitectura de tres capas (three-tier) es la “estructura de oración” de los diagramas cloud; la mayoría de los diseños son variaciones de ella:

Users → DNS → CDN → Load Balancer → [Web/App servers, ×N, multi-AZ, auto-scaled]
                                          → [Cache]
                                          → [Database: primary + standby, private subnets]

Capa 1 (presentación): lo que los usuarios tocan — contenido estático desde la CDN, solicitudes a través del balanceador de carga. Capa 2 (aplicación): la flota de servidores intercambiables que ejecutan su lógica, en subredes privadas, escalada automáticamente. Capa 3 (datos): la base de datos, la más profunda y protegida, con una copia en espera en una segunda AZ. El tráfico fluye en un solo sentido: los usuarios nunca tocan la capa de aplicación directamente, y solo la capa de aplicación habla con la capa de datos. Practique dibujar esto hasta que su mano lo haga sin su cerebro — es el arranque de la entrevista de pizarra en cualquier lugar del planeta.

Convenciones de notación que lo hacen ver profesional (porque lo hacen pensar profesionalmente): las cajas son componentes — etiquete cada una con lo que es y con qué servicio (“App servers — EC2, auto-scaling group”). Las flechas muestran la dirección en que fluye una solicitud, etiquetadas con el protocolo cuando importa. Los recuadros punteados muestran fronteras — la VPC, cada subred, cada AZ (dibuje las fronteras de AZ y el multi-AZ se vuelve visible en lugar de declarado). Un usuario/actor queda fuera del sistema. Los números en las flechas (1, 2, 3…) le permiten narrar el viaje de una solicitud. Y todo diagrama lleva título, fecha y leyenda. La regla más profunda: un diagrama, una audiencia, una pregunta. Un diagrama que muestra todo no muestra nada; aprenderá el conjunto estándar de niveles de zoom (contexto → contenedores → despliegue) en la Etapa 5.

Leer los diagramas de otros — los rayos X del arquitecto. Cuando le entreguen un diagrama, ejecute este escaneo en voz alta: ¿Dónde toca internet a este sistema (cada punto de contacto es superficie de ataque)? ¿Dónde están los datos, y están en una subred privada? ¿Qué está duplicado (resiliente) y qué es un punto único de falla — una caja sin gemela? ¿Dónde dolería a 10× el tráfico? ¿Cuánto cuesta cada caja al mes? Cinco preguntas, treinta segundos, y usted ha leído el diagrama como un médico lee una radiografía. Navegue por el AWS Architecture Center (https://aws.amazon.com/architecture/) y ejecute el escaneo sobre tres arquitecturas de referencia publicadas.

Vocabulario:

Ejercicios: (1) Dibuje el diagrama de tres capas de memoria, cinco días seguidos, hasta que tome menos de cuatro minutos con todas las fronteras (VPC, subredes, dos AZ) dibujadas. (2) Tome los cinco workloads del Módulo 2 y dibuje cada uno — veinte minutos por diagrama, con las reglas de notación aplicadas. (3) Encuentre cualquier diagrama de arquitectura real en línea (el AWS Architecture Center tiene cientos) y escriba en su diario su escaneo de rayos X de cinco preguntas. (4) El drill de narración: con el diagrama al frente, narre el clic de un usuario desde el navegador hasta la base de datos y de vuelta, en voz alta, numerando las flechas sobre la marcha.

Hito — fin de la Etapa 1: en una pizarra (o papel, fotografiado para su diario), usted puede dibujar un diseño de tres capas correcto y bien anotado para un workload nuevo de una frase en menos de quince minutos, narrar una solicitud a través de él, y responder “¿qué falla si esta caja muere?” para cada caja. Este dibujo-más-interrogatorio es precisamente la primera mitad de una entrevista real de arquitecto — de aquí en adelante, todo es profundidad.

ETAPA 2 — LOS DOMINIOS DE DISEÑO (Semanas 7–14)

El mapa de esta etapa es el AWS Well-Architected Framework — la lista compartida de la industria de lo que significa “diseñado correctamente”, organizada en seis pilares: excelencia operativa, seguridad, confiabilidad, eficiencia de rendimiento, optimización de costos, sostenibilidad. (Azure tiene un marco casi idéntico; aprenda uno a fondo y habrá aprendido ambos.) Las descripciones de puesto piden por nombre arquitectos que puedan “dirigir revisiones Well-Architected”, así que tomamos los pilares uno a la vez, y para cada uno usted aprende tres cosas: las preguntas clave del pilar, sus patrones estándar (las respuestas aburridas y probadas — los arquitectos ensamblan antes de inventar) y un ejemplo trabajado sobre un escenario recurrente.

El escenario recurrente de toda la Etapa 2: ThaiTicket, una plataforma ficticia de venta de boletos para eventos en Bangkok. Carga normal: 2,000 visitantes/hora. Pero cuando los boletos de un artista famoso salen a las 10:00 a.m., recibe 400,000 visitantes en diez minutos, los pagos no deben vender dos veces el mismo asiento, y los datos personales de los clientes tailandeses caen bajo la PDPA. Rápido, barato, resiliente — ThaiTicket necesita las tres cosas y no puede tenerlas, que es lo que lo convierte en el paciente de práctica perfecto.

Vea antes del Módulo 4 (enlaces verificados):

Y guarde en marcadores el marco mismo — https://aws.amazon.com/architecture/well-architected/ y el documento completo en https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html — vivirá en él durante ocho semanas.

Módulo 4 (Semanas 7–8): Confiabilidad — diseñar para el día en que las cosas se rompen

El credo del pilar: todo falla, todo el tiempo. Los discos mueren, las AZ se inundan, los despliegues salen mal, y siempre hay un certificado en algún lugar a punto de expirar. La confiabilidad no es la ausencia de fallas — es la irrelevancia de las fallas: diseñar de modo que cuando (no si) un componente muera, los usuarios nunca lo noten.

Preguntas clave (hágaselas a todo diseño, para siempre): ¿Qué pasa cuando falla cada componente — hay siempre un “y entonces qué”? ¿Cómo maneja el sistema 10× la carga? ¿Cómo sabemos que algo falló antes de que nos lo digan los clientes? ¿Cuáles son nuestros RTO y RPO — y quién en el negocio los aprobó? ¿Cuándo fue la última vez que probamos una recuperación?

RTO y RPO — los dos números que son la conversación del desastre. Recovery Time Objective (objetivo de tiempo de recuperación): ¿cuánto tiempo podemos estar caídos? Recovery Point Objective (objetivo de punto de recuperación): ¿cuántos datos podemos perder (es decir, qué tan viejo puede ser el último respaldo bueno)? Un RTO de 4 horas y un RPO de 1 hora significa: de vuelta en cuatro horas, habiendo perdido como máximo una hora de datos. Estas son decisiones de negocio con etiquetas de precio exponenciales — un RPO de 24 horas es un respaldo nocturno (barato); un RPO de ~cero es replicación continua (caro); un RTO de minutos significa infraestructura tibia ociosa en espera (muy caro). El trabajo del arquitecto es hacer que el negocio elija los números a sabiendas — y diseñar exactamente para ellos, no románticamente más allá de ellos.

Los patrones estándar: redundancia (dos de todo lo que importa — N+1) · multi-AZ (duplicados entre centros de datos; el balanceador de carga y el failover de la base de datos gestionada lo hacen automático) · auto-scaling (la capacidad sigue a la demanda) · health checks + autorreparación (instancias muertas detectadas y reemplazadas por maquinaria, no por humanos) · respaldos, probados (un respaldo no probado es una esperanza, no un plan — agende simulacros de restauración) · degradación elegante (bajo sobrecarga, suelte primero las funciones menos importantes: ThaiTicket puede dejar caer las vistas previas del mapa de asientos y conservar el checkout) · colas como amortiguadores (Etapa 3) · evitar fallas en cascada (timeouts, reintentos con backoff, circuit breakers — para que una dependencia lenta no ahogue a la flota).

Ejemplo trabajado — diseño de confiabilidad de ThaiTicket. Dos AZ en la región de Bangkok. Capa de aplicación stateless en un grupo de auto-scaling detrás de un balanceador de carga, precalentada por calendario antes de los horarios de venta anunciados (el auto-scaling reacciona en minutos; un lanzamiento a las 10:00 necesita capacidad a las 09:45). Base de datos Aurora, primaria en la AZ-a, copia síncrona en espera en la AZ-b, failover automático ≈ menos de un minuto. Una cola entre los clics de “comprar” y el procesamiento de pagos, para que una lentitud del proveedor de pagos encole pedidos en lugar de tumbar el sitio. Respaldos: continuos, restauración a un punto en el tiempo, simulacro de restauración mensual. Números acordados con el negocio: RTO 15 minutos, RPO ~cero para los pedidos (es dinero), RPO 24 horas para los datos de analítica (no lo es). Ejercicio de diario: ¿qué nos costó esto desde la esquina “barato” del triángulo?

Vocabulario:

Ejercicios: (1) Tome su diseño de pedidos de almuerzo de la Etapa 1 y mejórelo para sobrevivir: la muerte de una instancia, la pérdida de una AZ, una falla de base de datos y una hora pico de almuerzo de 10× — dibuje el antes y el después. (2) Escriba la conversación de RTO/RPO para tres negocios (un blog, un sitio de e-commerce, un sistema de expedientes hospitalarios) como un diálogo corto entre arquitecto y dueño — practique hacer visible el costo en el diálogo. (3) Diario: liste cada SPOF en el diseño de ThaiTicket de arriba. Queda al menos uno, dejado deliberadamente. (Pista: ¿cuántas regiones?)

Hito: usted puede ejecutar el interrogatorio de “¿qué pasa cuando esto falla?” sobre cualquier diagrama durante diez minutos seguidos sin quedarse seco, y puede explicar RTO vs RPO a un dueño no técnico usando una analogía de la inundación de una tienda en noventa segundos.

Módulo 5 (Semanas 9–10): Seguridad — diseñar sistemas difíciles de lastimar

El marco: el modelo de responsabilidad compartida. El proveedor asegura la nube en sí — edificios, hardware, el hipervisor. Usted asegura todo lo que pone en ella — datos, identidades, configuraciones, código. Casi todas las brechas cloud famosas son errores de configuración del lado del cliente (un bucket público, una clave filtrada, un rol con permisos excesivos), y por eso la seguridad es un problema de arquitectura antes que un problema de herramientas: las descripciones de puesto dicen “integrar la seguridad en el diseño en lugar de añadirla al final”, y este módulo es el cómo.

Preguntas clave: ¿Quién y qué puede acceder a cada componente, y cada permiso es el mínimo necesario? ¿Dónde se cifran los datos — en reposo, en tránsito, y quién guarda las llaves? ¿Dónde están las fronteras de red, y qué las cruza? ¿Cómo detectaríamos una brecha — y podríamos contar la historia después a partir de los logs? ¿Qué ley aplica a estos datos, y dónde viven físicamente?

Los patrones estándar: mínimo privilegio (least privilege) (cada humano y programa recibe el acceso mínimo que su trabajo necesita — la regla de oro contra la que se juzga cada política de IAM) · MFA en todas partes, root bajo llave · cifrado en reposo y en tránsito, siempre activo (en la nube es una casilla; no hay excusa) · segmentación de red (subredes públicas/privadas, security groups como firewalls por servidor; el radio de daño de una brecha lo definen las paredes que usted dibujó por adelantado) · secretos en una bóveda, nunca en el código · zero trust (confianza cero; verificar cada solicitud explícitamente — identidad, dispositivo, contexto — no confiar en nada solo por estar “dentro de la red”; las descripciones de puesto lo nombran, usted también debe) · defensa en profundidad (capas, para que un control fallido no sea el fin del juego) · registro de auditoría (registros estilo CloudTrail de quién hizo qué — inmutables, monitoreados) · la seguridad como barandillas, no como puertas (codifique las reglas como política automatizada que hace del camino seguro el camino fácil, en lugar de una reunión de revisión que convierte a la seguridad en enemiga de la entrega).

Ejemplo trabajado — diseño de seguridad de ThaiTicket. Los datos de clientes (nombres, correos, referencias de pago) clasificados como datos personales bajo la PDPA → almacenados cifrados en Aurora en la región de Bangkok (residencia de datos), llaves en KMS. Red: solo el balanceador de carga es público; la capa de aplicación privada; la subred de la base de datos acepta conexiones solo desde el security group de la capa de aplicación. Humanos: SSO + MFA; los ingenieros obtienen acceso de solo lectura a producción por defecto y acceso elevado con límite de tiempo bajo solicitud (mínimo privilegio con rastro de auditoría). El manejo de tarjetas de pago delegado a un proveedor de pagos certificado para que los números de tarjeta en bruto nunca toquen nuestros sistemas — una decisión de diseño que elimina una carga entera de cumplimiento, que es la arquitectura de seguridad en su mejor forma. CloudTrail activado, alertas por accesos inusuales. La pregunta de la brecha, pre-respondida: la PDPA tiene un deber de notificación de 72 horas — los logs y el runbook deben permitirnos contar la historia en menos.

Vocabulario:

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

Ejercicios: (1) Dibuje el diagrama de ThaiTicket y superponga su seguridad: marque cada frontera de confianza, cada punto de cifrado, cada lugar donde viven credenciales. Este hábito de superposición — el mismo diagrama, la lente de seguridad — es exactamente lo que una revisión le pide. (2) Lea un post-mortem público de una brecha por mala configuración cloud (Capital One 2019 es el clásico de enseñanza) y escriba, en su diario, cuál patrón de arriba la habría prevenido. (3) Juego de roles con una IA: interpreta a un fundador de startup que dice “añadiremos la seguridad después” — convénzalo de lo contrario con la aritmética del costo de una brecha, con amabilidad.

Hito: usted puede tomar cualquiera de sus diagramas de la Etapa 1 y producir su superposición de seguridad en veinte minutos, y explicar el mínimo privilegio, el zero trust y el modelo de responsabilidad compartida a un interesado no técnico sin jerga.

Módulo 6 (Semanas 11–12): Rendimiento y costos — velocidad y dinero, los pilares acoplados

Estos dos pilares se enseñan juntos porque son la misma palanca empujada en direcciones opuestas, y el arquitecto es la persona con la mano en la palanca.

Eficiencia de rendimiento — preguntas clave: ¿Dónde sentirán los usuarios la lentitud primero? ¿Qué se calcula repetidamente que podría calcularse una vez y guardarse en caché? ¿Es cada componente la herramienta correcta (SQL haciendo el trabajo de un motor de búsqueda es un bug de rendimiento de la arquitectura, no del código)? ¿Cómo cambia el rendimiento a 10× — y dónde está el primer cuello de botella?

Patrones de rendimiento: capas de caché — el patrón de rendimiento de mayor palanca: caché del navegador → CDN en el borde (contenido estático servido desde una ciudad cercana al usuario; puede absorber la gran mayoría del tráfico de lectura) → caché de aplicación (Redis delante de la base de datos para lecturas calientes: mapas de asientos, sesiones, páginas de producto) → caché de consultas de la base de datos. Cada capa responde solicitudes antes de que lleguen al núcleo costoso; las preguntas de diseño son siempre qué puede guardarse en caché, por cuánto tiempo y cómo se invalida cuando la verdad cambia. Luego: réplicas de lectura (copias de la base de datos que sirven lecturas para que la primaria siga escribiendo) · procesamiento asíncrono (no haga esperar a los usuarios por trabajo que puede ocurrir después — recibos por correo, miniaturas, informes) · la herramienta correcta para cada trabajo (búsqueda → un motor de búsqueda; analítica → un warehouse; consultas calientes → un almacén clave-valor) · y medir primero (el trabajo de rendimiento sin medición es superstición).

Optimización de costos — preguntas clave: ¿Cuánto cuesta este diseño al mes con la carga de hoy — y por unidad (por pedido, por cliente)? ¿Qué está corriendo a las 3 a.m. que no necesita estarlo? ¿Qué uso estable podría comprometerse con descuento? ¿Qué diría finanzas que es la tendencia?

Patrones de costos: rightsizing (la mayoría de las flotas están silenciosamente sobredimensionadas; encoger a la necesidad medida es dinero gratis) · estrategia de reservas — el menú de precios: on-demand (precio completo, libertad completa) para carga con picos/desconocida, instancias reservadas / savings plans (compromiso de 1–3 años, 30–70% de descuento) para la línea base estable, spot (hasta 90% de descuento, reclamable con poco aviso) para trabajo por lotes interrumpible; el movimiento del arquitecto es apilarlos: reservar el piso, auto-escalar el medio en on-demand, y poner los lotes en spot · ciclo de vida de almacenamiento (los niveles del Módulo 2, automatizados) · apagar cosas (los entornos no productivos durmiendo noches y fines de semana pueden recortar su costo en dos tercios) · vigilar el egress (los datos que salen de la nube se facturan; los diseños parlanchines entre regiones y las grandes descargas públicas sorprenden a todos una vez) · etiquetado y showback (cada recurso etiquetado con dueño/proyecto para que cada baht sea atribuible) · y la métrica corona, la unit economics (economía unitaria): no “la factura es ฿800k/mes” sino “el costo por boleto vendido es ฿1.90 y va bajando”. Las facturas crecientes están bien; los costos unitarios crecientes son un mal olor de arquitectura. Esta disciplina tiene nombre — FinOps — y los arquitectos se sientan en su centro.

Ejemplo trabajado — ThaiTicket, ambas lentes. Rendimiento: CloudFront sirve las páginas de artistas y las imágenes de mapas de asientos (los 400,000 curiosos en su mayoría nunca tocan los servidores); Redis guarda en caché la disponibilidad de asientos con un TTL de 2 segundos — lo bastante desactualizado para ser barato, lo bastante fresco para que el checkout (que verifica de nuevo contra Aurora, la fuente de la verdad) impida la doble venta; los recibos y boletos se generan asíncronamente después del pago. Costos: la línea base estable de 2,000 visitantes/hora corre con un savings plan (≈40% de descuento); los picos de venta corren en on-demand durante la hora que existen; los trabajos de analítica corren en spot de noche; staging duerme fuera del horario laboral; cada recurso etiquetado project:thaiticket. La propuesta al CFO dice: “฿62,000/mes de línea base, ≈฿9,000 por cada gran evento de venta, costo por boleto ≈฿1.90 y decreciente con el volumen” — y esa frase es cómo suena un arquitecto fluido en costos.

Vocabulario:

Video de este módulo (enlace verificado): What is FinOps? — FinOps Foundation (oficial) — ~2 min — https://www.youtube.com/watch?v=Y-c_xw9bHFw

Ejercicios: (1) Cotice la línea base de ThaiTicket en la calculadora de precios de AWS (busque “AWS pricing calculator” — el ejercicio de detallar un diseño real una vez desmitifica toda conversación futura de costos); compare su total con los ฿62,000 de arriba y explique cualquier brecha. (2) Añada la superposición de caché a dos de sus diagramas de la Etapa 1: marque cada caché, su TTL y su historia de invalidación. (3) Una IA interpreta a un ingeniero que quiere todo en on-demand “para mantenerlo simple” — negocie la estrategia de reservas, con números.

Hito: para cualquier diseño que haya dibujado, usted puede enunciar sus tres mayores líneas de costo y su probable primer cuello de botella — y proponer un cambio que mejore ambos a la vez (casi siempre hay uno; la caché suele serlo).

Módulo 7 (Semanas 13–14): Excelencia operativa, sostenibilidad — y ejecutar los seis pilares juntos

La excelencia operativa es el pilar que pregunta: ¿pueden los humanos realmente operar esta cosa, con calma? Preguntas clave: ¿Cómo llega un cambio a producción — a través de un pipeline automatizado y probado, o a través de un humano heroico? ¿Cómo sabemos que el sistema está sano ahora mismo? Cuando se rompe a las 3 a.m., ¿qué hace realmente el ingeniero de guardia? Patrones: infraestructura como código (el entorno definido en texto revisado y bajo control de versiones — Terraform/CloudFormation — para que sea reproducible y auditable; una arquitectura que existe solo como clics de consola es folclore, no ingeniería) · pipelines de CI/CD con estrategias de despliegue seguras (blue-green: levante la versión nueva junto a la vieja y cambie; canary: dele a la versión nueva el 5% del tráfico y observe) · observabilidad (logs, métricas, trazas y alertas ligadas a síntomas visibles para el usuario, no a trivialidades de máquina) · runbooks (el qué-hacer escrito para cada falla conocida) · post-mortems sin culpas (tras los incidentes: qué falló, por qué, qué previene una repetición — sin villanos, o la gente deja de decir la verdad). La parte del arquitecto: diseñar para la operabilidad — un sistema el doble de ingenioso y la mitad de observable es un sistema peor.

La sostenibilidad, el sexto pilar, le pide desperdiciar menos del mundo físico: haga rightsizing (las CPUs ociosas queman electricidad real), escale según la demanda en lugar de aprovisionar para el pico, use servicios gestionados y serverless (la infraestructura compartida es infraestructura más llena), use niveles de almacenamiento y borre lo que está muerto. Convenientemente, la elección sostenible y la elección barata suelen ser la misma elección — diga ambas en las revisiones y se ganará la sala dos veces.

Ejecutar los pilares juntos — su primera revisión Well-Architected. En las revisiones reales los pilares chocan: la confiabilidad multi-región pelea con el costo; la revisión de seguridad estricta pelea con la velocidad operativa; la caché de rendimiento pelea con la corrección de frescura de los datos. El marco no resuelve los conflictos por usted — los fuerza a salir a la luz, donde el negocio puede elegir. Ese es todo su genio, y el suyo para empuñarlo. El método de la revisión en sí (los conjuntos de preguntas, priorizar hallazgos, el informe) se enseña completo en la Etapa 5, Módulo 12; esta quincena usted ensaya la habilidad cruda: interrogar un diseño desde seis direcciones en una sola sesión.

Vocabulario:

Ejercicios: (1) El drill de las seis lentes: tome su mejor diagrama y dedique diez minutos por pilar a escribir hallazgos — sesenta minutos, un diseño, seis lentes; este drill es la Etapa 2 en miniatura, repítalo semanalmente de ahora en adelante. (2) Lea dos informes post-incidente de AWS (publicados en sus páginas de estado tras caídas mayores) e identifique cuál patrón de cuál pilar falló. (3) Diario: para ThaiTicket, escriba los tres conflictos entre pilares que usted le presentaría al negocio, cada uno como una elección de una frase (“Podemos tener X o Y con este presupuesto — ¿cuál?”).

Hito — fin de la Etapa 2: la revisión simulada: una IA genera una arquitectura defectuosa para una startup tailandesa de préstamos en línea; usted debe producir hallazgos escritos en los seis pilares, incluyendo al menos: una brecha de confiabilidad (su base de datos en una sola AZ), una brecha de seguridad (IAM demasiado amplio), una brecha de costos (todo en on-demand), una brecha operativa (sin IaC) y la conversación de RTO/RPO que nunca tuvieron — cada hallazgo formulado como una pregunta que un colega podría escuchar sin estremecerse. Cuando su lista de hallazgos se lea como la de un colega senior servicial y no la de un auditor, la Etapa 2 está terminada.

ETAPA 3 — EL CATÁLOGO DE PATRONES (Semanas 15–20)

Los arquitectos no inventan; seleccionan. Esta etapa es su catálogo de las arquitecturas estándar — para cada una: qué es, cuándo usarla, cuándo no, y su perfil de costo/complejidad. Las columnas de “cuándo no” son la verdadera carga de esta etapa: cualquier curso puede decirle qué son los microservicios; saber cuándo destrozarán a una empresa es aquello por lo que le pagan. Mientras estudia, siga navegando arquitecturas de referencia reales en https://aws.amazon.com/architecture/ — detectar patrones en la naturaleza es el ejercicio que hace que el catálogo se fije.

Módulo 8 (Semanas 15–17): Patrones de aplicación

Monolito vs. microservicios — la discusión más ruidosa de la industria, resuelta con calma. Un monolito es una aplicación desplegable que contiene todas las funciones; los microservicios dividen el sistema en muchos servicios pequeños, desplegados independientemente, cada uno dueño de sus datos, hablando por APIs y eventos. La tabla honesta:

El fallo del arquitecto: empiece monolítico, modular por dentro; extraiga servicios cuando — y solo cuando — llegue de verdad un dolor de escalado de equipo o de carga. Decir esto en las entrevistas, con razones, lo marca como senior; la ideología en cualquiera de las dos direcciones lo marca como junior.

Arquitectura orientada a eventos — colas y topics, los amortiguadores. En lugar de componentes que se llaman entre sí y esperan (síncrono), los componentes publican eventos (“OrderPlaced”) a una cola (SQS — un consumidor toma cada mensaje, a su propio ritmo) o a un topic (SNS — cada suscriptor recibe una copia; fan-out). El productor no sabe ni le importa quién escucha. Úsela cuando: los componentes deben sobrevivir las caídas de los otros (la cola retiene los mensajes mientras un consumidor está caído — resiliencia y desacoplamiento en una sola compra); la carga tiene picos (la cola absorbe el pico; los workers la drenan con constancia); una ocurrencia dispara muchas reacciones (pedido realizado → cobro, correo, inventario, analítica — cuatro suscriptores, cero acoplamiento). NO la use cuando: el usuario necesita la respuesta ahora (el checkout no puede confirmar “eventualmente”); o el equipo es pequeño y una simple llamada síncrona bastaría — cada cola añade semánticas de entrega (at-least-once significa que los consumidores deben ser idempotentes — seguros de ejecutar dos veces), manejo de dead letters y una carga de monitoreo. Costo/complejidad: componentes baratos, depuración más cara — la historia de una solicitud está ahora dispersa entre servicios y colas, y por eso la observabilidad (Módulo 7) deja de ser opcional aquí.

Tres capas: ya es suya (Módulo 3). Úsela para: el amplio centro de las aplicaciones web — es el patrón contra el que se miden los demás. No para: workloads con picos muy marcados y valles ociosos (serverless es más barato) o productos genuinamente enormes de múltiples equipos (vea arriba). Perfil: bien entendida en todas partes, se contrata fácil, costo medio.

Serverless-first: componga piezas gestionadas — API Gateway → funciones Lambda → DynamoDB, S3 y colas — sin poseer ningún servidor. Úsela cuando: tráfico con picos o bajo (escalar a cero significa que lo ocioso cuesta ~nada), equipos pequeños, rapidez de salida al mercado, pegamento orientado a eventos. NO la use cuando: cómputo de larga duración o especializado (límites de runtime), rutas ultrasensibles a la latencia (cold starts), carga estable masiva (el precio por invocación puede superar a los servidores reservados — haga la aritmética a escala), o cuando la portabilidad entre nubes es un requisito genuino (este es el lock-in más profundo de todos los patrones — a menudo vale la pena, pero dígalo en voz alta). Perfil: la carga de operaciones más baja del catálogo; costo excelente a escala baja/con picos, requiere verificación a gran escala estable.

Vocabulario:

Ejercicios: (1) Diseñe el flujo de pedidos de ThaiTicket dos veces — tres capas síncrono, y luego orientado a eventos con SQS/SNS — y escriba un párrafo sobre qué hace cada versión durante una caída del proveedor de pagos; ese párrafo es todo el argumento a favor de los eventos. (2) Para cuatro empresas (startup de 3 personas, scale-up de 50 ingenieros, un banco, una app de votación de TV usada 4 noches al año), elija un patrón y defiéndalo — y luego nombre el disparador que haría que cada empresa cambiara de patrón. (3) Encuentre una historia real de blog de ingeniería de “migramos a microservicios y nos arrepentimos” y una historia de éxito; anote en el diario la diferencia (casi siempre es el tamaño del equipo y la madurez del dominio).

Hito: dada la descripción de una empresa, usted puede recomendar un patrón con su rampa de salida — “empiece aquí; cuando pase X, evolucione hacia Y” — en cinco minutos. Rutas de evolución, no veredictos, son la manera en que los arquitectos hablan de verdad.

Módulo 9 (Semanas 18–20): Patrones de datos, globales e híbridos

Arquitecturas de datos — lake vs. warehouse. Las bases de datos transaccionales (Etapa 1) hacen funcionar el negocio; la analítica quiere hacerle preguntas sin frenarlo. Un data warehouse (Redshift, Snowflake, BigQuery) almacena datos estructurados y limpios optimizados para analítica SQL rápida — úselo cuando las preguntas son conocidas y los tableros deben ser rápidos; cuesta más por TB, necesita disciplina de modelado por adelantado. Un data lake (S3 + catálogo + motores de consulta como Athena) almacena todo, en bruto, barato — logs, clickstreams, imágenes — y aplica la estructura al momento de leer; úselo cuando quiere conservarlo todo ahora y decidir las preguntas después; pero sin gobernanza degenera en el chiste de la industria, el data swamp (pantano de datos). El consenso moderno es ambos, en capas (“lakehouse”): la verdad en bruto en el lake, los marts curados en el warehouse, alimentados por pipelines de ETL/ELT. Las reglas del arquitecto: la analítica nunca consulta la base de datos de producción (la alimentan réplicas o pipelines), y cada dataset tiene un dueño, una entrada de catálogo y una política de retención — esa línea de gobernanza es una frase en su diseño y un año de dolor si la omite.

Multi-región: activo-pasivo vs. activo-activo. Cuando una región no basta — porque el negocio exige DR ante desastres a escala de región, o los usuarios abarcan continentes — usted elige:

La frase de nivel de entrevista: “Multi-AZ is table stakes; multi-region is a business case.” (Multi-AZ es lo mínimo esperable; multi-región es un caso de negocio.) Haga que el negocio declare el RTO/RPO, cotice las opciones y deje que los números elijan.

Nube híbrida. Parte on-prem, parte cloud, unidas por VPN o Direct Connect — para la mayoría de las empresas establecidas no es un patrón sino una realidad de una década: mainframes que no pueden moverse, sistemas de fábrica atados a la latencia, datos regulados fijados en las instalaciones, y una migración (Etapa 4) de paso. Úsela como: un puente deliberado con una dirección de viaje. NO acepte: “híbrido” como eufemismo de “nunca decidimos”. Notas de diseño: la identidad debe unificarse primero (un solo inicio de sesión entre ambos mundos — lo que las descripciones de puesto empresariales quieren decir con “hybrid identity integration”); nombre qué sistemas son la fuente de la verdad; vigile los costos de egress a través del enlace; y espere que el enlace de red sea un SPOF a menos que se duplique. Complejidad: todo por partida doble, un parque por cada mundo — la razón honesta por la que los arquitectos empujan a encoger el lado on-prem con constancia.

Vocabulario:

Ejercicios: (1) ThaiTicket se vuelve regional: diseñe la expansión a Singapur dos veces — activo-pasivo (Bangkok primaria) y activo-activo — con múltiplos de costo y RTO/RPO para cada una; escriba la recomendación de una página y tome una decisión. (2) Un minorista tiene 15 años de ventas en una base de datos SQL de producción y quiere “analítica lista para IA”; esboce el diseño de lake + warehouse y escriba las tres frases de gobernanza. (3) Detección de patrones: elija tres arquitecturas de referencia de https://aws.amazon.com/architecture/ y nombre cada patrón del catálogo presente en cada una.

Hito — fin de la Etapa 3: el desafío del catálogo: una IA le da seis escenarios a ritmo rápido; para cada uno usted nombra el patrón, la razón, la advertencia de cuándo-NO y el perfil de costo/complejidad — en menos de cinco minutos cada uno. Este intercambio exacto, a esta velocidad exacta, es el tercio medio de una entrevista real de arquitecto.

ETAPA 4 — MIGRACIÓN Y EL MUNDO REAL (Semanas 21–26)

El diseño greenfield es la minoría del trabajo. La mayor parte de la arquitectura ocurre en empresas que ya existen — con salas de servidores, software antiguo del que depende el negocio, contratos y leyes. Esta etapa es ese mundo, y es donde se enseña “liderar iniciativas de migración y modernización” — un punto en casi todas las descripciones de puesto que estudiamos.

Módulo 10 (Semanas 21–23): Migración — mover una empresa a la nube

Las 7 R — el vocabulario compartido de toda conversación de migración. Para cada workload del parque, usted elige una:

El método de migración: evaluar → movilizar → migrar. Evaluar: inventaríe todo (herramientas de descubrimiento más la arqueología de preguntarle a la gente), y califique cada workload por valor de negocio y dificultad de migración — productos: un inventario de aplicaciones con una R por fila, y un caso de negocio (TCO de quedarse vs. moverse; sea honesto en que la factura sube durante el período de traslape en que ambos parques corren — los líderes a quienes no se les advierte sobre la burbuja de migración se convierten en líderes que cancelan migraciones a la mitad). Movilizar: construya la landing zone (zona de aterrizaje) — la fundación cloud pre-construida y gobernada antes de que aterrice el primer workload: estructura multi-cuenta (cuentas separadas por entorno y equipo, para que los radios de daño se mantengan pequeños), identidad y registro centralizados, el hub de red (VPCs hub-and-spoke, el Direct Connect de vuelta a on-prem) y guardrails (barandillas) — políticas automatizadas que hacen del camino seguro, etiquetado y conforme el camino por defecto (AWS Control Tower es el kit de inicio gestionado). Las descripciones de puesto dicen “diseñar la landing zone que cada workload hereda” — esto es eso. Saltársela para “simplemente empezar a migrar” recrea el centro de datos desordenado en la nube a mayor costo; es la firma clásica de la migración fallida. Migrar por olas: agrupe los workloads en olas de unos pocos, ordenadas de lo fácil primero: la Ola 1 es deliberadamente de bajo riesgo (aprenda la maquinaria donde los errores son baratos), las olas posteriores llevan las joyas de la corona con cutovers ensayados, cada una con un plan de rollback y un período de hypercare de vigilancia intensificada. Para cada movimiento de base de datos, las dos preguntas que importan son los números del Módulo 4 disfrazados: cuánta caída puede tomar el cutover (RTO) — y la replicación continua con un cambio corto existe para cuando la respuesta es “casi ninguna”.

Vocabulario:

Ejercicios: (1) La migración en papel: una IA genera el inventario de una empresa ficticia de 40 servidores (la volverá a encontrar como Capstone 2); asigne una R a cada fila y defienda las diez decisiones más difíciles. (2) Esboce una landing zone: diagrama de cuentas, flujo de identidad, hub-and-spoke de red, cinco guardrails que impondría desde el primer día. (3) Escriba la advertencia de dos párrafos sobre la “burbuja de migración” a un CFO — practicar las malas noticias temprano es el cardio del arquitecto.

Hito: dado un inventario de ~20 workloads con descripciones, usted produce una tabla defendible de R por workload, un plan de tres olas con razonamiento y un esbozo de landing zone — en una sola sesión.

Módulo 11 (Semanas 24–26): Restricciones — ley, sistemas heredados y lock-in

La residencia de datos y las leyes de privacidad como insumos de arquitectura. Las leyes de datos personales — la PDPA de Tailandia, el GDPR de Europa y sus primas en todo el mundo — comparten una forma que un arquitecto debe conocer al dedillo: los datos personales necesitan una base legal (a menudo el consentimiento); los individuos tienen derechos (acceso, corrección, borrado — su diseño debe poder encontrar y borrar los datos de una persona, lo cual es difícil si los ha dispersado en copias sin gobernanza); las brechas conllevan un deber de notificación en 72 horas (su registro debe permitirle contar la historia en menos); y las reglas de transferencia transfronteriza restringen dónde pueden vivir físicamente los datos — lo cual es una restricción de selección de región, una restricción de diseño de replicación (esa copia de analítica en Singapur puede ser un evento legal) y una razón por la que existen las regiones dentro del país. El método del arquitecto, en orden: clasifique los datos (¿qué es personal?), mapee sus viajes (cada almacén, cada copia, cada frontera cruzada — los flujos que nadie dibujó son donde viven las violaciones), y luego diseñe los controles: regiones conformes con la residencia, cifrado, calendarios de retención y una ruta de borrado que realmente alcance la expiración de los respaldos. Diga “data protection by design” (protección de datos desde el diseño) — es la frase que usan ambas leyes, y es literalmente su título de trabajo en una frase.

Integración con sistemas heredados. El sistema de facturación en mainframe no se mueve este año, y la flamante app cloud debe hablar con él. Los patrones: una anti-corruption layer (capa anticorrupción) — un servicio de traducción entre lo nuevo y lo viejo, para que las formas de datos extrañas del sistema heredado no se filtren y corrompan su diseño nuevo; el strangler fig (higuera estranguladora) — enrute el tráfico a través de una fachada, y luego desprenda funciones del sistema heredado una por una hasta que, años después, pueda apagarse (nombrado por la higuera que envuelve lentamente a un árbol huésped; vence a las reescrituras big-bang, que fallan a una tasa legendaria); puentes por lotes y tomas de eventos para los datos que deben fluir entre mundos; y respeto por la física de latencia de las llamadas parlanchinas cloud-a-on-prem (Direct Connect ayuda; mejor aún, diseñe la charla fuera). La regla: contenga lo heredado, no se contagie de ello — cada componente nuevo debe construirse como si el sistema heredado ya no existiera.

La economía del vendor lock-in. Cada servicio gestionado conveniente profundiza su matrimonio con un proveedor; la portabilidad (abstracciones multi-cloud, todo autogestionado) es una opción real que cuesta dinero real en complejidad y velocidad sacrificada. Ninguno es un pecado — el modo de falla no es elegir el lock-in, es no notarlo. La herramienta del arquitecto es una estimación de costo de salida escrita en el diseño: “Usar DynamoDB ahorra ≈2 años-ingeniero ahora; cambiar después ≈ una reescritura de 6 meses de la capa de datos — lo aceptamos, y aquí está la frontera de interfaz que encogería la reescritura.” Tres frases, cotizadas con honestidad, decisión registrada (los ADRs de la Etapa 5) — eso es gestión madura del lock-in. El multi-cloud como estrategia (correr el mismo workload de forma portátil en dos nubes) suele ser la respuesta más cara posible y la compran exactamente las organizaciones cuya escala o regulador lo exige; el multi-cloud como hecho (distintos workloads en distintas nubes por historia o por conveniencia) es la vida normal.

Vocabulario:

Ejercicios: (1) Mapee los flujos de los datos de clientes de ThaiTicket: cada almacén, cada copia (no olvide los logs, los respaldos, el pipeline de analítica, las exportaciones del equipo de soporte), cada frontera; luego escriba la ruta de borrado. Sienta cómo el mapa encuentra problemas que el diagrama escondía. (2) Diseñe el plan de strangler fig para un sistema de inventario on-prem de 20 años, con los tres primeros desprendimientos nombrados. (3) Escriba el párrafo de lock-in al estilo DynamoDB (beneficio ahora, costo de salida después, aceptado o mitigado) para tres servicios que usted realmente usaría.

Hito — fin de la Etapa 4: el desafío de las restricciones: un encargo de diseño cargado con las tres (“aseguradora tailandesa, datos de clientes, sistema de pólizas en mainframe, junta nerviosa por la dependencia de AWS”) — usted produce un enfoque de una página que toca residencia, integración y lock-in, cada uno con un patrón nombrado y un costo honesto. Cuando las restricciones lo emocionen más de lo que lo haría el greenfield — porque las restricciones son donde los arquitectos ganan más que los dibujantes de diagramas — la Etapa 4 está terminada.

ETAPA 5 — EL OFICIO DEL ARQUITECTO (Meses 7–12)

Todo lo anterior lo hizo capaz de diseñar. Esta etapa lo hace capaz de trabajar como arquitecto — los documentos, revisiones, presentaciones y pruebas de las que el rol está hecho realmente, más las certificaciones que lo hacen pasar de RR. HH., y tres capstones que se convierten en su portafolio.

Módulo 12 (Meses 7–8): Los entregables — ADRs, conjuntos de diagramas y dirigir revisiones

Architecture Decision Records (ADRs, registros de decisiones de arquitectura). Un ADR es un documento de una página que captura una decisión significativa: qué elegimos, qué no elegimos y por qué — escrito cuando se toma la decisión, numerado y conservado en el repositorio del proyecto para siempre. Por qué las descripciones de puesto los nombran: dentro de dos años, alguien preguntará “¿por qué demonios esto es DynamoDB?” y el ADR responde en treinta segundos — con el contexto, las restricciones y las alternativas honestamente consideradas. Los equipos con ADRs no relitigen nada; los equipos sin ellos discuten en círculos cada año. La plantilla — memorícela:

# ADR-014: Use DynamoDB for the session store
Status: Accepted            Date: 2026-08-13
Context:     What situation forced a decision? (Load, constraints, deadlines — the facts.)
Decision:    What we chose, in one sentence, active voice: "We will…"
Options considered:  2–3 real alternatives, each with honest pros/cons — including the one you rejected reluctantly.
Consequences: What becomes easier; what becomes harder; the risks we accept; the exit cost.

Escriba un ADR por cada decisión significativa en cada capstone. Un portafolio de entrevistas que contiene ADRs reales es raro y devastadoramente efectivo.

El conjunto de diagramas — un sistema, tres niveles de zoom. La documentación de arquitectura real es un conjunto (el modelo C4 popularizó esta disciplina): el diagrama de contexto — el sistema como una sola caja, con sus usuarios y los sistemas externos que toca; la vista para ejecutivos/recién llegados, y la que presentará al liderazgo. El diagrama de contenedores — acerque el zoom: las piezas principales en ejecución (app web, API, base de datos, cola, caché) y cómo hablan; la vista cotidiana de ingeniería, aproximadamente sus dibujos de las Etapas 1–3. El diagrama de despliegue — dónde corre todo físicamente: región, AZs, VPC, subredes, grupos de escalado; la vista para revisiones, seguridad y operaciones. Un sistema, tres audiencias, tres diagramas — mantenidos al día, fechados, bajo control de versiones junto a los ADRs. Un diagrama que no puede encontrarse o en el que no se puede confiar es un diagrama que no existe.

Dirigir una revisión Well-Architected. Usted conoce los seis pilares (Etapa 2); aquí está la reunión en sí. Antes: elija el workload y el alcance, ponga al día el conjunto de diagramas, invite a las personas que operan la cosa (no solo a sus diseñadores) y fije el tono — esto es un chequeo de salud para beneficio del equipo, no una auditoría para el expediente de nadie. Durante (medio día): recorra los pilares con los conjuntos de preguntas del marco (AWS los publica, con una herramienta Well-Architected gratuita en la consola que estructura todo el ejercicio — https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html); para cada respuesta, anote el hallazgo y priorice sobre la marcha — un puñado de asuntos de alto riesgo, no cien detallitos. Su tono de preguntas es la revisión: “help me understand what happens when the payment provider times out” (ayúdeme a entender qué pasa cuando el proveedor de pagos expira) abre puertas que “you don’t handle timeouts?” (¿no manejan timeouts?) cierra de golpe. Después: un informe corto — los hallazgos principales, cada uno con riesgo, esfuerzo y una recomendación — y los elementos de mejora aterrizan en el backlog real del equipo con dueños, o la revisión fue teatro. Práctica: dirija una revisión completa contra su propio diseño del Capstone 1; encontrar sus propias fallas de forma estructurada es la habilidad de este curso que más rápido se capitaliza.

Ejercicios: (1) Escriba retroactivamente ADRs para cinco decisiones grandes de sus diseños de diario de las Etapas 2–3 — encontrará al menos una que ya no puede justificar, y esa es la lección. (2) Produzca el conjunto completo de tres diagramas para ThaiTicket. (3) Dirija la revisión simulada de arriba y produzca el informe de hallazgos de una página.

Hito: un extraño (o una IA interpretándolo) puede tomar su paquete de ThaiTicket — tres diagramas + cinco ADRs — y responder correctamente “¿qué es esto, cómo corre y por qué está construido así?” sin usted en la sala. Ese paquete es el entregable del trabajo del arquitecto.

Módulo 13 (Meses 8–9): El oficio humano — presentar, costear, manejar la resistencia y mentorar

Presentar a ejecutivos vs. a ingenieros — un diseño, dos idiomas. Los ejecutivos compran resultados; los ingenieros compran mecanismos. A los ejecutivos: empiece con la decisión y el número (“Este diseño soporta la meta del millón de clientes a ฿1.90 por pedido, y aquí están las dos decisiones que necesito de ustedes”); una diapositiva, el diagrama de contexto, los riesgos formulados como riesgos de negocio (ingresos, cumplimiento, reputación), y nunca diga “Kubernetes” cuando “la plataforma” bastará. Prepárese para las tres preguntas que los ejecutivos siempre hacen: ¿cuánto cuesta, qué podría salir mal, por qué no la opción más barata? A los ingenieros: empiece con el problema y las restricciones antes de la solución (los ingenieros que sienten el problema aceptan la solución; los ingenieros a quienes se les entrega un veredicto cazan fallas por principio), muestre los diagramas de contenedores y despliegue, nombre usted mismo los trade-offs y las opciones rechazadas (la credibilidad viene de lo que usted admite), y deje espacio real para cambiar el diseño — las preguntas en la sala son revisión gratuita. El peor hábito de arquitecto es una sola presentación para ambas audiencias; el mejor hábito es escribir el resumen ejecutivo primero, porque si el diseño no sobrevive a la compresión en cinco frases, no está terminado.

Estimar costos para una propuesta. El método: descomponga el diseño en sus ~10 componentes con costo; cotice cada uno a la carga esperada en la calculadora de precios; declare sus supuestos por escrito (solicitudes/día, crecimiento de datos, egress — los supuestos son la estimación; cuando cambian, el número se mueve con la conciencia tranquila); aplique la estrategia de reservas a las partes estables; añada escenarios de crecimiento (hoy, 2×, 10× — los ejecutivos recuerdan el número de 10×); y presente como un rango con impulsores (“฿55–70k/mes, impulsado principalmente por el egress — aquí está la palanca”), nunca como un número único de falsa precisión. Incluya la burbuja de migración si la hay. Subestimar para ganar la aprobación es el pecado clásico del arquitecto junior; el proyecto lo recuerda.

Manejar la resistencia. Lo presionarán por el costo (“demasiado caro” → regrese al triángulo: “podemos recortar ฿30k aceptando una sola AZ — aquí está la matemática de la caída; usted decide, y yo lo dejo por escrito” — hacer el intercambio explícito y registrado convierte la mayor parte de la resistencia en acuerdo o en riesgo aceptado informado, ambos aceptables); por gusto (“un ingeniero prefiere otro stack” → defienda con fuerza esa alternativa en voz alta, y luego llévela a criterios, no a preferencias: ajuste a los NFRs, habilidades del equipo, ecosistema, costo de salida — y cuando esté genuinamente parejo, deje ganar la preferencia del ingeniero que implementa, comprando compromiso a bajo precio); y por autoridad (“el amigo del CTO dice que usen X” → nunca pelee opinión contra opinión; pida los criterios, pase X por la misma evaluación pública que todo lo demás, deje que la matriz responda con cortesía). Y cuando usted se equivoque — diseñará algo que falla; a todo arquitecto le pasa — el movimiento es el post-mortem sin culpas aplicado a usted mismo, en público, con el ADR actualizado. Nada construye credibilidad de décadas más rápido; nada la destruye más rápido que defender un cadáver.

Mentorar ingenieros. La frase de las descripciones de puesto es “mentorar a los ingenieros que construyen según sus estándares”, y las formas de trabajo son: horas de oficina de revisión de diseño (una puerta permanente, para que la guía llegue antes del código, no después); revisar sus diseños con amabilidad — preguntas antes que veredictos, y siempre el porqué detrás del estándar (un guardrail explicado recluta un aliado; un guardrail impuesto recluta una evasión); delegar decisiones reales con una red de seguridad (“usted es dueño del diseño de la caché; aquí están las restricciones; yo reviso, y respaldaré su decisión”); y enseñar en público — cada ADR, cada informe de revisión, cada sesión informal lo escala más allá de sus propias horas. La verdad cruda de la carrera: un arquitecto genio solitario toca techo; un arquitecto que ha convertido a cinco ingenieros en colegas capaces de diseñar dirige la práctica.

Ejercicios: (1) Presente ThaiTicket dos veces — una versión ejecutiva de 5 minutos y una versión de ingeniería de 20 minutos — grabe ambas y escuche la jerga filtrándose en la primera. (2) Produzca la propuesta de costos completa por escrito (supuestos, rango, impulsores, escenarios de 2×/10×). (3) Teatro de resistencia con una IA: tres rondas — ataque de costos de un CFO, preferencia de stack de un ingeniero senior, jugada de autoridad del amigo del CTO — anote en el diario qué funcionó. (4) Revise por escrito el diseño de un junior (una IA puede generar uno defectuoso), con preguntas primero, y haga que la IA califique su tono.

Hito: el doble reto: entregue el pitch ejecutivo y sobreviva veinte minutos de preguntas y respuestas mixtas hostiles-pero-justas (panel de IA: un CFO, un ingeniero escéptico) sin cruces de jerga, sin actitud defensiva y sin un solo trade-off no escrito.

Módulo 14 (Meses 9–12): Certificaciones y los tres capstones

La ruta de certificaciones, con líneas de tiempo honestas. Las certificaciones no lo hacen arquitecto — los trece módulos anteriores lo hacen — pero le consiguen entrevistas, y prepararse para ellas le cablea los servicios del proveedor en los dedos. La escalera, al ritmo de una hora al día: AWS Certified Solutions Architect – Associate (SAA-C03) — 2–3 meses; la credencial de arquitecto más solicitada en los anuncios de empleo, y después de las Etapas 1–3 gran parte le parecerá repaso con nombres de servicios adjuntos; tómela primero. AWS Certified Solutions Architect – Professional (SAP-C02) — 4–8 meses después de la Associate; basada en escenarios, genuinamente difícil, y la línea de currículum más fuerte de este campo; el material de migración y multi-cuenta de la Etapa 4 es la mitad de su temario. Azure AZ-305 (Azure Solutions Architect Expert) — añádala si su mercado es muy de Microsoft (la mayoría de los mercados empresariales son al menos bilingües); espere 2–3 meses con el conocimiento de AWS transfiriéndose con gran descuento (empiece en https://learn.microsoft.com/en-us/credentials/certifications/azure-solutions-architect/). TOGAF Foundation — opcional, 2–4 semanas; algunas grandes empresas la piden; certifica método y vocabulario de arquitectura empresarial más que habilidad cloud. Secuencia para este curso: estudio de la SAA junto a los Meses 7–8, examen alrededor del Mes 8; luego o la SA Pro (ruta técnica profunda) o la AZ-305 (ruta de amplitud) hasta el Mes 12, con la SA Pro completada para el Mes 14–16 al ritmo honesto.

Los tres capstones. Cada uno es un paquete completo de calidad de portafolio: conjunto de diagramas de tres niveles, 5+ ADRs, estimación de costos con supuestos, y una revisión Well-Architected autoejecutada con hallazgos. Dedique 3–4 semanas a cada uno. Estos tres artefactos, más su diario, son su evidencia de entrevista de “diseño de soluciones de extremo a extremo”.

Capstone 1 — el greenfield: una plataforma tailandesa de e-commerce para 1M de usuarios. Encargo: marketplace, 1M de usuarios registrados, 50k concurrentes en el pico de una venta flash, mobile-first, integración de pagos estilo PromptPay, conforme con la PDPA, 99.9% de disponibilidad, consciente del presupuesto de etapa semilla. Debe incluir: elección de patrón con ruta de evolución, estrategia de caché, conversación de RTO/RPO escrita como diálogo, estimación de unit economics, mapa de flujos de datos personales.

Capstone 2 — el brownfield: migrar una empresa on-prem de 40 servidores. Encargo: una firma tailandesa de logística; 40 servidores (ERP sobre Oracle, app de gestión de almacén de 12 años, archivos compartidos, AD, varias apps departamentales — genere el inventario completo con una IA y congélelo); el contrato del centro de datos expira en 14 meses; la junta quiere salir. Debe incluir: tabla completa de inventario con las 7 R, plan de tres olas con razonamiento de dependencias, diseño de landing zone, línea de tiempo de costos de la burbuja de migración, y el memorando al CFO.

Capstone 3 — el difícil: DR multi-región para una fintech. Encargo: una empresa de pagos regulada a RTO ≤ 15 minutos / RPO ≈ 0 para el libro mayor, con restricciones de residencia de datos sobre los datos de clientes y una prueba anual de failover presenciada por el regulador. Debe incluir: análisis activo-pasivo vs. activo-activo con costos, diseño de replicación con el mapa de residencia, el runbook de failover y el plan de simulacros.

La rúbrica de autoevaluación (aplíquela a cada capstone, con honestidad, en su diario):

Califique cada dimensión con 4+ en los tres capstones — revisando hasta lograrlo — y habrá completado el curso.

Diez preguntas de entrevista de arquitecto (con respuestas sólidas)

Practíquelas en voz alta; la fuerza está en la estructura de cada respuesta, que ahora es suya.

1. “Design a URL shortener / ticketing site / photo app for a million users.” (Diseñe un acortador de URLs / un sitio de boletos / una app de fotos para un millón de usuarios.) Forma sólida: los requisitos primero, en voz alta (“¿Las lecturas dominan a las escrituras? ¿Meta de disponibilidad? ¿Presupuesto?”) → posición en el triángulo → esqueleto de tres capas o serverless-first con multi-AZ, caché, CDN → nombre los trade-offs sin que se lo pidan → termine con el orden de magnitud del costo y la ruta de evolución a 10×. Los entrevistadores aprueban por las preguntas que usted hace, no por las cajas que dibuja.

2. “When would you choose NoSQL over a relational database?” (¿Cuándo elegiría NoSQL sobre una base de datos relacional?) “Mi predeterminado es SQL — garantías de corrección y habilidades universales — hasta que una razón con nombre lo anule: escala horizontal extrema, esquema flexible o acceso clave-valor de un dígito de milisegundos. Entonces elijo la variante NoSQL que se ajuste al patrón de acceso, y escribo el ADR incluyendo lo que cedemos: los joins, y algo de semántica de consistencia.”

3. “Explain RTO and RPO, and how they drive design.” (Explique RTO y RPO, y cómo dirigen el diseño.) Defina ambos con precisión → “son decisiones de negocio con etiquetas de precio exponenciales” → la escalera: respaldos nocturnos → replicación continua → standby tibio → activo-activo, con el costo subiendo en cada peldaño → “mi trabajo es hacer que el negocio elija a sabiendas, y luego diseñar exactamente para el número — y ensayarlo, porque un failover no probado es una esperanza.”

4. “Monolith or microservices?” (¿Monolito o microservicios?) El fallo del Módulo 8, textual: empiece con un monolito modular; extraiga cuando llegue de verdad el dolor de escalado de equipo o de carga; los microservicios son una herramienta de escalado de equipos que cobra un impuesto de sistemas distribuidos. Puntos extra por “prefiero operar un buen monolito que un mal sistema distribuido.”

5. “How do you handle a large cloud bill / cost optimization?” (¿Cómo maneja una factura cloud grande / la optimización de costos?) “Visibilidad primero — etiquetado y showback; luego la cosecha en orden de esfuerzo: matar los recursos muertos, rightsizing a partir de mediciones, niveles de almacenamiento, dormir los entornos no productivos, y luego reservar la línea base estable. Y reporto unit economics, no totales — una factura creciente con costo por pedido decreciente es un éxito, no un problema.”

6. “How would you migrate a legacy on-prem application?” (¿Cómo migraría una aplicación heredada on-prem?) “Evaluar antes de mover — inventario, dependencias y una R por workload de las 7 R; construir la landing zone antes de la primera ola; olas de lo fácil primero con cutovers ensayados y planes de rollback; y para la base de datos joya de la corona, cutover basado en replicación dimensionado a la caída que el negocio firmó. Además: la advertencia honesta de la burbuja de migración por adelantado.”

7. “How do you secure a cloud architecture?” (¿Cómo asegura una arquitectura cloud?) Recorra las capas: identidad (mínimo privilegio, MFA, sin root diario) → red (subredes privadas, segmentación, superficie de ataque mínima) → datos (cifrado en reposo/en tránsito, clasificación, residencia) → detección (logs de auditoría, alertas) → “y desde el diseño, no atornillada después — el control de seguridad más barato es la decisión de arquitectura que elimina el riesgo por completo, como nunca tocar datos de tarjetas en bruto.”

8. “Tell me about a design decision you got wrong.” (Cuénteme sobre una decisión de diseño en la que se equivocó.) Están probando el ego, no la historia. Forma: ejemplo real (de capstone) → lo que usted creía → lo que dijo la realidad → el post-mortem, el ADR actualizado, el patrón que ahora revisa. Un arquitecto que no puede producir esta respuesta es un arquitecto que no ha sido revisado.

9. “How do you explain a complex technical decision to a non-technical executive?” (¿Cómo explica una decisión técnica compleja a un ejecutivo no técnico?) “La decisión y el número de negocio primero, el mecanismo solo si lo piden; diagrama de contexto, no de contenedores; los riesgos en términos de ingresos-cumplimiento-reputación; y llevo las dos decisiones que necesito de ellos, escritas como opciones con etiquetas de precio — los ejecutivos deciden entre opciones; no aprueban misterios.”

10. “An engineer strongly disagrees with your design. What do you do?” (Un ingeniero está en fuerte desacuerdo con su diseño. ¿Qué hace usted?) “Primero defiendo su postura con fuerza en voz alta — puede tener razón, y la revisión que cambia mi diseño es la revisión funcionando. Si está genuinamente parejo, deciden los criterios (ajuste a los NFRs, habilidades del equipo, costo de salida), no la antigüedad — y dejo que la preferencia del implementador gane los empates, porque el compromiso es barato a ese precio. En cualquier caso, la decisión y la opción rechazada van al ADR, para que nunca lo discutamos dos veces.”

El plan de estudios en una página

Unas palabras de cierre de su profesor. A las veintiséis semanas, usted podía diseñar; a los doce meses, puede ejercer — hay una diferencia, y es la diferencia que este curso fue construido para cerrar. Los hábitos son ahora la carrera: dibuje antes de discutir, escriba el ADR el día que decida, cotice lo que proponga, nombre el trade-off antes de que alguien pregunte, y haga crecer a los ingenieros a su alrededor hasta que sus estándares sobrevivan a su presencia en la sala. La arquitectura es el raro trabajo técnico que mejora a medida que usted envejece en él, porque su materia prima es el juicio, y el juicio se capitaliza. Siga con el diario. Dentro de cuarenta diseños, usted no necesitará este curso — lo estará corrigiendo.

Fuentes

Descripciones de puesto y definiciones de rol usadas para el mapeo de requisitos (recuperadas en agosto de 2026): la plantilla de descripción de puesto de Cloud Architect de KORE1 · la descripción de puesto de Cloud Architect de 4 Corner Resources · las responsabilidades del Solution Architect de Microsoft en el Azure Well-Architected Framework · la publicación de Pre-Sales Solutions Architect – AWS de Arpio · la publicación de Solution Architect – Enterprise de Intel (vía Built In) · la publicación de Cloud Domain Architect de Halliburton. Estimaciones de tiempo de preparación de certificaciones: la encuesta de tiempo de estudio de la SAA-C03 de CBT Nuggets y la guía de preparación de la SAP-C02 de Whizlabs; definiciones de certificaciones de Microsoft Learn (AZ-305) y el AWS Well-Architected Framework. Un volumen complementario de El Curso del Líder Cloud (The Cloud Leader Course) en la serie B4LCILC.