El dominio D3 del SAP-C02 evalúa la mejora continua de arquitecturas existentes. La confiabilidad va más allá de Multi-AZ — implica probar activamente los fallos, analizar los modos de fallo, y mejorar continuamente la postura de seguridad con Access Analyzer y Permission Boundaries.
Contenido
El pilar de Confiabilidad del Well-Architected Framework define cómo diseñar sistemas que se recuperen de fallos, escalen dinámicamente y entreguen la capacidad correcta para satisfacer la demanda.
Foundations
Gestión de límites de servicio (quotas), planificación de capacidad de red. Establecer límites de servicio apropiados antes de que se necesiten.
Workload Architecture
Diseñar para HA y recuperación desde el diseño inicial. Circuit breakers, retry con backoff exponencial, bulkheads.
Change Management
Gestionar cambios en las cargas de trabajo con pruebas y rollback automatizados. Auto Scaling, deployment sin downtime.
Patrones de resiliencia de software para el SAP-C02
Retry con Backoff Exponencial
Reintentar operaciones fallidas con espera creciente + jitter aleatorio. Evita el "thundering herd" problem.
Circuit Breaker
Después de N fallos consecutivos, "abrir" el circuito y no enviar más requests hasta que el servicio se recupere.
Bulkhead
Aislar recursos por función. Si el servicio de búsqueda colapsa, no afecta al checkout. Limits de threads/conexiones por servicio.
Timeout
Nunca esperar infinitamente. Definir timeouts a todas las llamadas externas. Fail fast es preferible a esperar.
FMEA (Failure Mode and Effects Analysis) es el proceso de identificar sistemáticamente cómo puede fallar cada componente y qué impacto tendría. En AWS, se traduce en revisar la arquitectura buscando SPOFs.
| Componente | Modo de fallo | Mitigación AWS |
|---|---|---|
| EC2 single instance | La instancia falla o el host subyacente falla | ASG con mínimo 2 instancias en 2 AZs + ALB |
| RDS single-AZ | Fallo de hardware → horas de downtime para restaurar | RDS Multi-AZ — failover automático en < 1 min |
| NAT Gateway en una AZ | Si esa AZ falla, subnets privadas en otras AZs pierden internet | Una NAT Gateway por AZ usada |
| Lambda concurrency throttling | Spike de tráfico agota la concurrencia disponible | Reserved Concurrency + SQS buffer para suavizar picos |
| DynamoDB hot partition | Partition recibe todas las escrituras → throttling | Rediseñar partition key con más cardinalidad o write sharding |
| S3 single bucket region | Interrupción de la región → datos inaccesibles | CRR a bucket en región secundaria para DR |
| DNS con TTL alto | Si ALB/endpoint cambia, clientes en caché van al endpoint incorrecto | TTL bajo en Route 53 para registros críticos (60-300s) |
Tipos de eventos de AWS Health
Service Events
Interrupciones y degradaciones de servicios AWS que afectan a TODOS los clientes en una región. Ej: "EC2 API degraded in us-east-1". Visible en AWS Service Health Dashboard público.
Account Events
Eventos que afectan específicamente a TU cuenta: instancias EC2 programadas para retirement, certificados SSL próximos a vencer, RIs expirando. Solo visible en tu Personal Health Dashboard.
Scheduled Changes
Mantenimientos programados de AWS que impactarán tus recursos. Ej: "tu instancia en este host será migrada el día X". Debes actuar antes de la fecha.
Automatización con AWS Health + EventBridge
Los eventos de AWS Health publican en EventBridge, permitiendo respuestas automáticas.
La ingeniería del caos inyecta fallos controlados en producción (o pre-producción) para descubrir debilidades antes de que ocurran en situaciones reales. AWS Fault Injection Service (FIS) es el servicio nativo para esto.
AWS Fault Injection Service (FIS)
AWS Resilience Hub + Game Days
IAM Access Analyzer
Analiza políticas de recursos (S3 buckets, IAM roles, KMS keys, Lambda, SQS, Secrets Manager) para identificar acceso externo no intencionado fuera de la trust zone definida.
Permission Boundaries
Permission Boundaries son políticas IAM que definen el máximo de permisos que una entidad IAM puede tener, independientemente de qué políticas se le adjunten después.
Caso de uso clave del examen
"Los developers pueden crear IAM roles para sus Lambda functions, pero no pueden escalar sus propios permisos más allá de lo que ellos mismos tienen."
→ Permission Boundary que limita los roles que los devs pueden crear.
Para el SAP-C02, el backup no es solo "crear snapshots" — es una estrategia coordinada de retención, prueba de recuperación, y compliance. AWS Backup con Organizations es el patrón enterprise.
| Estrategia | Cómo implementar | Para qué |
|---|---|---|
| 3-2-1 Rule | 3 copias, 2 medios diferentes, 1 offsite. En AWS: original + snapshot en misma región + copia cross-region. | Cumplimiento estándar de backup best practice |
| Immutable backups | AWS Backup Vault Lock (WORM). Los backups no pueden eliminarse antes de expirar. | Protección anti-ransomware y anti-manipulación |
| Cross-account backups | Vault en cuenta centralizada de backup. Copias de todas las cuentas miembro van al vault central. | Proteger backups de eliminación accidental o maliciosa en la cuenta fuente |
| Testing de restauración | AWS Backup Restore Testing: automatiza pruebas de restauración de backups periódicamente. | Garantizar que los backups son realmente recuperables |
| Tag-based backup policies | Backup Plan que selecciona recursos por tag (Environment=Production). Auto-incluye nuevos recursos con ese tag. | Governance: garantizar que todos los recursos de producción tienen backup |
Trampa: "IAM Access Analyzer y IAM Credential Report hacen lo mismo"
Realidad: Diferentes. Access Analyzer analiza POLÍTICAS de recursos para encontrar acceso no intencionado desde fuera de la trust zone. Credential Report lista las credenciales de usuarios IAM y su estado (MFA, última vez usada, contraseña expirada).
Trampa: "Permission Boundaries dan permisos adicionales"
Realidad: FALSO. Permission Boundaries SOLO limitan los permisos máximos posibles. No otorgan ningún permiso por sí mismos. El permiso real resulta de la INTERSECCIÓN de la Permission Boundary y las políticas de identidad.
Trampa: "AWS FIS solo funciona en entornos de test/staging"
Realidad: AWS FIS puede ejecutar experimentos en producción (con las salvaguardas adecuadas: stop conditions, monitoring). De hecho, el propósito principal es probar en producción para descubrir fallos reales que no se manifestarían en entornos de test.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un equipo de plataforma quiere permitir que los equipos de desarrollo creen sus propios roles IAM para funciones Lambda, pero necesitan garantizar que esos roles no tengan más permisos que los que los propios developers tienen. También quieren detectar automáticamente si algún role IAM creado por developers permite acceso desde cuentas externas. ¿Qué combinación de servicios implementa AMBOS requisitos?
Inicia sesión para llevar tu progreso.