Módulo 3: Domain 2 Resilient Architectures

7. El pilar de confiabilidad del Well-Architected Framework

Descripción

Las lecciones 2 a 6 cubrieron los dos task statements de Domain 2 en detalle. Esta lección cierra el círculo conceptual del módulo con el marco que los organiza a todos: el pilar de confiabilidad (Reliability) del AWS Well-Architected Framework. Como ya viste en el Módulo 2, lección 7, los cuatro dominios del examen mapean, casi palabra por palabra, a cuatro de los seis pilares oficiales — y Domain 2 (Resilient) es, con precisión, el que corresponde al pilar de Reliability.

Conexión con el módulo

Cada decisión que tomaste en las lecciones 2 a 6 —desacoplar con EventBridge, elegir el balanceador correcto según capa, distribuir entre Availability Zones, definir RPO/RTO, escalar con EC2 Auto Scaling— es una instancia concreta de uno de los cinco principios de diseño que esta lección nombra. Y hay una conexión adicional que ningún otro módulo de esta guía tiene: sre-and-incident-response-guide, una guía hermana completa, construyó de verdad —con código Python ejecutado, no solo prosa— el mismo vocabulario de confiabilidad que este pilar describe, desde un ángulo distinto y complementario.

Los cuatro dominios y los seis pilares, con Reliability en el centro

La tabla que ya viste en el Módulo 2, repetida aquí porque esta lección desarrolla la fila que quedó pendiente:

Dominio del examen SAA-C03	Pilar del Well-Architected Framework
Domain 1 — Design Secure Architectures	Security
Domain 2 — Design Resilient Architectures	Reliability
Domain 3 — Design High-Performing Architectures	Performance Efficiency
Domain 4 — Design Cost-Optimized Architectures	Cost Optimization

Los cinco principios de diseño de confiabilidad, con lo que ya construiste debajo de cada uno

La documentación oficial del pilar de confiabilidad lista cinco principios de diseño — uno menos que los siete de seguridad, pero cada uno con una instancia directa y concreta en este módulo:

"Automatically recover from failure" — detectar fallas y disparar recuperación automática, sin intervención humana. Es, con precisión, lo que un health check de ELB combinado con EC2 Auto Scaling hace (lección 6): una instancia que falla su chequeo se reemplaza sola, y lo que un failover automático de Route 53 respaldado por un health check hace (lección 4): el tráfico se mueve al destino sano sin que nadie apriete un botón.
"Test recovery procedures" — nunca confiar en que un plan de recuperación funciona sin haberlo probado. Es la razón de ser de la advertencia explícita de la lección 5: una estrategia de DR nunca probada es, en la práctica, una estrategia desconocida — el mismo criterio que AWS Resilience Hub aplica al validar continuamente si un workload cumple sus objetivos de RTO/RPO reales, no solo los declarados en un documento.
"Scale horizontally to increase aggregate system availability" — repartir la carga entre múltiples recursos pequeños en vez de depender de uno solo, más grande. Es, con precisión, el principio detrás de Multi-AZ (lección 4) y de un Auto Scaling Group con varias instancias medianas en vez de una sola instancia enorme (lección 6) — perder una de varias duele menos que perder la única que existe.
"Stop guessing capacity" — dejar de adivinar cuánta capacidad vas a necesitar, y dejar que el sistema la ajuste según demanda real medida. Es, exactamente, el problema que EC2 Auto Scaling con target tracking resuelve (lección 6): nadie decide "cuántas instancias" una sola vez y espera tener razón para siempre.
"Manage change through automation" — cualquier cambio a la infraestructura debería aplicarse mediante automatización controlada, no mediante pasos manuales propensos a error. Es, con precisión, por qué el whitepaper de recuperación ante desastres (lección 5) insiste en infraestructura como código para redesplegar en la región de recuperación — el mismo criterio de disciplina que terraform-and-iac-guide construyó de verdad para toda la infraestructura de Andes Cargo.

Las cuatro áreas del pilar, como checklist de cierre de módulo

Más allá de los principios de diseño, AWS organiza el contenido del pilar en cuatro áreas de mejores prácticas: foundations, workload architecture, change management y failure management. Úsalas como checklist final — si puedes nombrar, para cada área, al menos un servicio o práctica de las lecciones 2 a 6 que la cubre, dominaste Domain 2 completo:

   LAS 4 ÁREAS DEL PILAR DE CONFIABILIDAD — TU CHECKLIST DE CIERRE DE MÓDULO

   Foundations              →  Service quotas, límites de cuenta y región (L6)
   Workload architecture    →  Desacoplamiento con EventBridge/SQS, ALB/NLB/GWLB (L2, L3)
   Change management        →  Infraestructura como código para DR, Auto Scaling gradual (L5, L6)
   Failure management       →  Multi-AZ/Multi-Region, DR strategies, RDS Proxy, X-Ray (L4, L5, L6)

Mismo pilar, dos guías, dos ángulos — sin fricción entre ellas

sre-and-incident-response-guide construyó, con código real y ejecutado, un vocabulario de confiabilidad que complementa —nunca repite— el de esta lección. La diferencia de fondo entre ambas guías vale la pena nombrarla con precisión, porque el examen y la práctica real de un arquitecto de soluciones necesitan los dos ángulos:

	Esta lección (Domain 2, SAA-C03)	`sre-and-incident-response-guide`
Pregunta central	¿Qué arquitectura sobrevive un fallo?	¿Cómo medimos, con números reales, si el sistema está siendo confiable?
Vocabulario	Multi-AZ, failover, Auto Scaling, RPO/RTO	SLI, SLO, error budget, burn rate
Artefacto construido	Diagramas de arquitectura de referencia (Módulo 7 de esta guía)	`error_budget_calculator.py`, corrido de verdad, con datasets reales de 30 días de tráfico
Documento de cierre	`SERVICE-COVERAGE-MATRIX.md` (Módulo 6 de esta guía)	`SLO.md` — el SLI y el SLO reales de Andes Cargo, con evidencia, no con una corazonada

La conexión concreta: el error budget de sre-and-incident-response-guide —calculado sobre process-shipment-manifest, usando las cuatro señales doradas de Google SRE como base para elegir qué medir— es, en efecto, la forma cuantitativa de responder la misma pregunta que este módulo responde de forma arquitectónica. Una arquitectura Multi-AZ con Auto Scaling (esta lección) es la decisión de diseño; un SLO de 99.9% de disponibilidad con un error budget de 43 minutos al mes (sre-and-incident-response-guide Módulo 2) es cómo confirmas, con datos reales, si esa decisión de diseño está funcionando de verdad en producción. Ninguna de las dos guías reemplaza a la otra — un arquitecto de soluciones que solo sabe diseñar Multi-AZ, sin saber medir si funciona, y un SRE que solo sabe medir burn rate, sin saber qué arquitectura reduce el riesgo de fondo, están, cada uno, resolviendo la mitad del mismo problema.

Errores comunes

Tratar "Reliability" y "Resilient" como si fueran dos temas distintos que memorizar por separado (de duplicación innecesaria). Qué pasa: alguien estudia el pilar de confiabilidad como si fuera contenido nuevo, sin conectar cada principio con las lecciones 2-6 ya vistas. Cómo detectarlo: si no puedes nombrar, sin pensarlo, qué principio de diseño describe EC2 Auto Scaling. Cómo corregirlo: el pilar no es contenido nuevo — es el vocabulario de más alto nivel que organiza exactamente lo que ya aprendiste en este módulo, la misma disciplina que el Módulo 2, lección 7, ya estableció para el pilar de seguridad.

Asumir que sre-and-incident-response-guide "ya cubrió" Domain 2 y que esta lección es redundante (de solapamiento mal entendido). Qué pasa: alguien, al ver la tabla de conexión con SRE, concluye que estudiar una guía hace innecesaria la otra para el examen. Cómo detectarlo: si crees que SLI/SLO/error budget son las respuestas correctas para una pregunta de examen sobre arquitectura de alta disponibilidad. Cómo corregirlo: el examen SAA-C03 prueba diseño de arquitectura (Multi-AZ, Auto Scaling, failover) — el vocabulario SRE (SLI/SLO/burn rate) no aparece en el temario oficial de Domain 2 como tal; es un complemento valioso para tu criterio real como arquitecto, no material de examen sustituto.

❓ Pregunta de práctica — Dominio 2 (Resilient)

Escenario: SeguroTotal, una aseguradora, diseña un nuevo sistema de cotizaciones. Un ingeniero propone lanzar el sistema completo sobre una sola instancia EC2 de tamaño extra grande, argumentando que una sola máquina potente es más simple de administrar que varias máquinas medianas coordinadas. El equipo de arquitectura rechaza la propuesta, citando directamente uno de los principios de diseño del pilar de confiabilidad del Well-Architected Framework.

Pregunta: ¿Cuál principio de diseño describe mejor la razón del rechazo?

A. "Automatically recover from failure" B. "Scale horizontally to increase aggregate system availability" C. "Manage change through automation" D. "Stop guessing capacity"

✅ Respuesta correcta: B

Por qué es correcta: el principio "scale horizontally to increase aggregate system availability" describe exactamente el riesgo de la propuesta rechazada: una sola instancia grande, sin importar cuán potente sea, es un único punto de falla — perderla significa perder el sistema completo. Repartir la misma capacidad entre varias instancias medianas (horizontalmente) reduce el impacto de perder cualquiera de ellas individualmente, exactamente el criterio que gobierna Multi-AZ y Auto Scaling Groups en este módulo.

Por qué las demás fallan:

A: "automatically recover from failure" es sobre mecanismos de recuperación automática (health checks, reemplazo automático de instancias) — es relevante en general, pero no es la razón específica por la que "una instancia grande" es peor que "varias medianas"; incluso una sola instancia grande podría, en teoría, tener mecanismos de recuperación automática configurados.
C: "manage change through automation" es sobre cómo se aplican los cambios a la infraestructura (IaC, despliegues controlados) — el escenario no describe ningún problema relacionado con cómo se despliegan cambios, sino con la distribución de la capacidad de cómputo.
D: "stop guessing capacity" es sobre dejar que el sistema ajuste capacidad según demanda real medida, en vez de que un humano la adivine una sola vez — relevante para justificar Auto Scaling sobre una capacidad fija, pero el argumento central del rechazo en el escenario es específicamente sobre una sola instancia como punto único de falla, no sobre si esa instancia fue bien dimensionada.

Resumen y siguiente paso

En esta lección cerraste el círculo conceptual de Domain 2: confirmaste que Resilient mapea al pilar de Reliability, viste los cinco principios de diseño con una instancia concreta de cada uno ya construida en las lecciones 2-6, y trazaste la conexión explícita —sin solapamiento— con el vocabulario cuantitativo de sre-and-incident-response-guide: la arquitectura que diseñas aquí es la que ese vocabulario mide con números reales.

Antes de avanzar deberías poder nombrar los cinco principios de diseño del pilar de confiabilidad y conectar cada uno con al menos una decisión de este módulo.

La lección 8 cierra Domain 2 con el banco de práctica completo: preguntas originales que combinan los dos task statements, con el mismo formato y estándar de explicación que el examen real usa.

Recursos

AWS Well-Architected Framework — Reliability Pillar — fuente oficial de los cinco principios de diseño y las cuatro áreas del pilar, citados en esta lección.
AWS Well-Architected Framework — The Six Pillars — panorama completo de los seis pilares y su relación con los cuatro dominios del examen.
sre-and-incident-response-guide, Módulo 2 (NIEVA) — error_budget_calculator.py y SLO.md, el ángulo cuantitativo complementario a esta lección.

← Anterior6. Task 2.2 cont.: EC2 Auto Scaling, RDS Proxy y *service quotas*Siguiente →8. Práctica: Dominio 2 (Resilient)