SAA-C03
Deep Dive
Las preguntas de base de datos en SAA-C03 suelen probar la diferencia entre Multi-AZ (HA/failover) y Read Replicas (escalar lectura). Aurora añade su propia capa de resiliencia nativa. DynamoDB Global Tables para multi-región activo-activo.
Contenido
Esta es la distinción más importante y frecuente en el examen. Multi-AZ = Alta Disponibilidad. Read Replicas = Escalar lectura.No son intercambiables.
| Característica | Multi-AZ | Read Replicas |
|---|---|---|
| Propósito principal | Failover automático (HA) | Escalar consultas de lectura |
| Tipo de replicación | Síncrona (mismo tiempo) | Asíncrona (eventual) |
| Failover automático | Sí — ~60 segundos, cambia DNS | No — manual o manual promotion |
| Puede recibir tráfico de lectura | No (standby es pasivo) | Sí — endpoint separado |
| Ubicación | Otra AZ en la misma región | Otra AZ, región o cuenta |
| Número máximo | 1 standby | 5 (RDS), 15 (Aurora) |
| Costo | Doble de instancias/storage | Una instancia por réplica |
| Uso en el examen | "Si falla la instancia principal..." | "Alto tráfico de lectura, dashboards, reportes..." |
Pregunta trampa del examen
"¿Multi-AZ mejora el rendimiento de lectura?"→ NO. La réplica standby en Multi-AZ es pasiva — no sirve consultas de lectura. Para escalar lectura, necesitas Read Replicas, no Multi-AZ.
Aurora reimagina el almacenamiento de base de datos. En vez de un volumen EBS replicado, Aurora usa un cluster de almacenamiento distribuido que mantiene 6 copias en 3 AZs automáticamente.
Arquitectura de almacenamiento
6 copias en 3 AZs
2 copias por AZ. Puede perder hasta 2 copias sin pérdida de escritura.
Quórum de escritura
4 de 6 copias deben confirmar la escritura.
Quórum de lectura
3 de 6 copias para lectura consistente.
Self-healing
Detecta y repara bloques corruptos automáticamente.
Auto-scaling storage
Crece de 10GB a 128TB automáticamente sin downtime.
Comparativa Aurora vs RDS
Aurora Serverless v2
Escala automáticamente desde 0.5 ACUs hasta 128 ACUs en fracciones de segundo. Ideal para cargas impredecibles, dev/test, aplicaciones que no se usan 24/7. Señal en examen: "carga de trabajo intermitente o impredecible".
Características
Señales en el examen
DynamoDB es multi-AZ por defecto — los datos se replican automáticamente en 3 AZs dentro de una región. Para resiliencia global, DynamoDB Global Tables extiende esto a múltiples regiones.
DynamoDB Global Tables
Réplicas activo-activo en múltiples regiones. Escrituras aceptadas en cualquier región. Replicación asíncrona en <1 segundo.
Examen
"Aplicación global que necesita escrituras locales en cada región" → Global Tables.
Point-in-Time Recovery (PITR)
Restaura la tabla a cualquier punto en los últimos 35 días. Para recuperación de borrados o corrupciones accidentales.
Examen
"Usuario eliminó accidentalmente ítems de DynamoDB" → PITR para restaurar.
DynamoDB Streams
Captura cambios (inserts, updates, deletes) en la tabla en orden cronológico. Retenidos 24 horas. Trigger para Lambda.
Examen
"Procesar cambios en DynamoDB en tiempo real" → Streams + Lambda.
On-Demand vs Provisioned
On-Demand: escala automáticamente, paga por request. Provisioned: defines RCUs/WCUs, más barato para carga predecible.
Examen
"Carga impredecible o variable" → On-Demand. "Carga estable con ahorro de costo" → Provisioned + Auto Scaling.
ElastiCache Redis
•Persistencia (snapshots)
•Replicación Multi-AZ con failover
•Pub/Sub messaging
•Sorted sets, lists (estructuras complejas)
•Cluster mode: sharding horizontal
Cuándo usar
Sesiones de usuario, leaderboards de gaming, pub/sub, colas de tareas, caché de DB con persistencia.
ElastiCache Memcached
•Sin persistencia
•Multi-thread (mejor para multi-core)
•Sharding horizontal simple
•Sin replicación
•Para objetos simples en cache
Cuándo usar
Caché de objetos simples sin necesidad de persistencia. Cuando la velocidad es más importante que la durabilidad.
Sesiones en apps sin estado (stateless)
Si múltiples instancias EC2 manejan requests, las sesiones de usuario no deben almacenarse en memoria local. Usar ElastiCache Redis para sesiones compartidas — cualquier instancia puede leer la sesión del usuario. El examen llama esto "stateless application design".
| Escenario en el examen | Servicio | Razón |
|---|---|---|
| Failover automático en <60s | RDS Multi-AZ | Réplica síncrona, DNS failover automático |
| Escalar 1000s de consultas de lectura | RDS Read Replicas | Distribución de carga de lectura |
| MySQL/PostgreSQL de máximo rendimiento | Aurora | 5x más rápido, 15 read replicas |
| Base de datos global activo-activo | DynamoDB Global Tables | Escrituras en múltiples regiones |
| Carga de BD impredecible o intermitente | Aurora Serverless v2 | Escala a 0, sin gestión de capacidad |
| Latencia de microsegundos para NoSQL | DynamoDB + DAX | DAX agrega cache in-memory a DynamoDB |
| Caché de sesiones con persistencia | ElastiCache Redis | Persistencia + Multi-AZ + estructuras complejas |
| Caché simple multi-thread sin persistencia | ElastiCache Memcached | Multi-thread, más sencillo, sin HA |
| Data warehouse para analytics | Amazon Redshift | Columnar, petabytes, BI tools |
| Búsqueda de texto completo | Amazon OpenSearch Service | Elasticsearch, Kibana integrado |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una aplicación tiene una base de datos RDS MySQL con Multi-AZ habilitado. Los reportes ejecutados por el equipo de analytics están degradando el rendimiento de la aplicación principal. ¿Cuál es la solución más apropiada?