Semana 4 · Módulo 4 de 11

Bases de datos: RDS, Aurora, DynamoDB, ElastiCache y compañía

Cómo elegir, dimensionar, replicar, proteger y abaratar bases de datos en AWS: RDS y Aurora (Multi-AZ, réplicas, Global Database, Serverless), RDS Proxy, DynamoDB a fondo, cachés con ElastiCache, bases de propósito específico y migraciones con DMS. Es el núcleo de las tasks 3.3 y 4.3 y aparece en muchas preguntas de alta disponibilidad (2.2).

Reparto de la semana

Por qué importa

Las bases de datos concentran preguntas de tres dominios:

• Rendimiento (3.3): patrón de acceso (lecturas intensivas frente a escrituras intensivas), capacidad (unidades de capacidad, clases de instancia, Provisioned IOPS), réplicas, cachés, conexiones y proxies.
• Coste (4.3): DynamoDB frente a RDS, serverless, reservas, retención de copias, formatos de series temporales o columnares, migraciones.
• Resiliencia (2.2 y 2.1): Multi-AZ, failover, réplicas entre regiones, RDS Proxy como concepto de proxy, estrategias de DR.

Casi todas las preguntas se resuelven identificando qué problema hay que resolver: ¿disponibilidad ante la caída de una AZ?, ¿demasiadas lecturas?, ¿demasiadas conexiones?, ¿latencia global?, ¿coste con uso intermitente?

Tipos de bases de datos

Relacional frente a no relacional: el relacional da flexibilidad de consulta (SQL, joins) a costa de escalar sobre todo en vertical (instancia más grande) y en lecturas (réplicas). DynamoDB escala en horizontal casi sin límite, pero tienes que diseñar la tabla según tus consultas (no hay joins; las consultas van por clave o índice).

Amazon RDS

Amazon RDS (Relational Database Service) gestiona por ti el hardware, la instalación, los parches, las copias y la alta disponibilidad. Tú eliges motor, clase de instancia, almacenamiento y red. No tienes acceso al sistema operativo (salvo RDS Custom, para Oracle y SQL Server, cuando necesitas personalizar el SO o el motor).

Motores y elección de motor

Motores: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server e IBM Db2 (más Aurora, que es RDS con otro almacenamiento).

¿MySQL o PostgreSQL? (skill explícito de 3.3 y 4.3):

Oracle y SQL Server en RDS implican licencias: License Included (pagas la licencia en la tarifa) o Bring Your Own License (BYOL, según motor y edición).

Clases de instancia y almacenamiento

• Clases: db.t* (ráfagas, desarrollo y cargas pequeñas), db.m* (propósito general), db.r*/db.x* (optimizadas para memoria, bases grandes). Graviton (g) suele dar mejor precio-rendimiento.
• Almacenamiento: General Purpose SSD (gp3 o gp2), Provisioned IOPS SSD (io1, io2 Block Express) para E/S intensiva y latencia constante, y magnético (heredado).
• Storage autoscaling: RDS amplía el almacenamiento automáticamente cuando se acerca al límite, hasta un máximo que tú fijas. Evita el estado storage-full sin sobredimensionar desde el principio. El almacenamiento solo crece: no se puede reducir.
• Una instancia RDS parada vuelve a arrancarse sola a los 7 días. Para ahorrar en entornos que no usas, haz un snapshot y bórrala.

Backups y restauración

• Automated backups: snapshot diario en la ventana de backup + logs de transacciones. Retención configurable (hasta 35 días; con 0 se desactivan). Permiten point-in-time recovery (PITR) a cualquier segundo dentro del periodo de retención.
• Manual snapshots: los lanzas tú y no caducan; sobreviven al borrado de la instancia (cuota por defecto: 100 por región). Se pueden copiar a otra región y compartir con otras cuentas.
• Restaurar crea siempre una instancia nueva (con un endpoint nuevo). No se restaura «encima».
• Al borrar una instancia puedes pedir un snapshot final y conservar o no los backups automáticos.
• Export to S3: exporta un snapshot a Parquet en S3 para analizarlo con Athena, barato para retención larga.
• AWS Backup también gestiona RDS y Aurora (planes centralizados, copia entre regiones y cuentas, Vault Lock).

Diseño de retención (skill de 4.3, «frecuencia de snapshots»): el RPO lo marca el PITR (del orden de minutos) y la retención, cuántos días atrás puedes volver. Para años de retención, snapshots mensuales con AWS Backup y transición a cold storage, o exportación a S3 con ciclo de vida. Más retención = más coste de almacenamiento de backup.

Cifrado y seguridad

• Cifrado en reposo con KMS: se elige al crear la instancia. Cifra almacenamiento, logs, backups, réplicas y snapshots.
• No se puede cifrar una instancia existente. Procedimiento: snapshot → copiar el snapshot activando el cifrado → restaurar una instancia nueva desde la copia → cambiar la aplicación al nuevo endpoint.
• Una réplica de una instancia cifrada va cifrada (en otra región, con una clave KMS de esa región). No hay réplicas cifradas de instancias sin cifrar ni al revés.
• En tránsito: TLS en las conexiones del cliente (puedes forzarlo con parámetros como rds.force_ssl en PostgreSQL o require_secure_transport en MySQL).
• Autenticación: usuario y contraseña (idealmente en Secrets Manager con rotación; RDS puede gestionar la contraseña maestra en Secrets Manager por ti), IAM database authentication (tokens temporales en MySQL, MariaDB y PostgreSQL) o Kerberos/Active Directory.
• Red: en subredes privadas (DB subnet group), sin acceso público, con un security group que solo admita el puerto del motor desde el security group de la aplicación.

Alta disponibilidad en RDS: Multi-AZ

Cómo funciona el failover: la aplicación se conecta a un endpoint DNS; en un failover, RDS apunta ese nombre al standby promovido. No cambias la cadena de conexión, pero la aplicación debe reintentar conexiones (y no cachear el DNS mucho tiempo). Se dispara ante fallo del primario, de la AZ, de red o de almacenamiento, al cambiar el tipo de instancia o durante parches; puedes forzarlo con reboot-db-instance --force-failover para probarlo.

• Pasar de Single-AZ a Multi-AZ se hace modificando la instancia, sin parada (RDS toma un snapshot y crea el standby).
• Los backups se toman del standby, así que no congelan la E/S del primario.
• Multi-AZ no protege de errores lógicos (un DELETE erróneo se replica al instante): para eso, backups y PITR.

Réplicas de lectura

Una read replica es una copia de solo lectura actualizada con replicación asíncrona (puede ir con retraso: replica lag).

• Hasta 15 réplicas por instancia primaria (cuota por defecto; en Oracle AWS recomienda no pasar de 5).
• Misma región o entre regiones (cross-Region read replica): lecturas de baja latencia cerca de los usuarios y DR entre regiones. El tráfico de replicación dentro de la misma región no se cobra; entre regiones, sí.
• Necesita los backups automáticos activados en el origen.
• Cada réplica tiene su propio endpoint: la aplicación debe mandar las lecturas allí (o usar un balanceo propio, Route 53 con varios registros, o el endpoint de lectura en Aurora). RDS no escala automáticamente el número de réplicas (Aurora sí).
• Una réplica puede ser a su vez Multi-AZ y se puede promocionar a instancia independiente (lectura-escritura). La promoción rompe la replicación: es una operación de DR o de migración, no un failover automático.
• En MySQL y MariaDB se pueden encadenar réplicas (réplica de réplica).

RDS Proxy

Amazon RDS Proxy es un proxy de base de datos gestionado y de alta disponibilidad que mantiene un pool de conexiones compartido entre muchos clientes.

• Problema que resuelve: muchas conexiones cortas y simultáneas (típico de AWS Lambda o de picos de tráfico) agotan memoria y CPU de la base de datos y alcanzan max_connections.
• Qué hace: reutiliza conexiones (multiplexing), pone en cola o limita las que no puede atender en vez de dejar caer la base de datos, y en un failover mantiene las conexiones de la aplicación y enruta al nuevo primario sin depender de la caché DNS. En Aurora Multi-AZ reduce el tiempo de failover hasta un 66 %.
• Seguridad: puede exigir IAM a los clientes y conectarse a la base de datos con credenciales guardadas en Secrets Manager (o IAM). La aplicación deja de manejar contraseñas.
• Restricciones: vive en la misma VPC que la base de datos y no puede ser público; en RDS se asocia al writer (no a una réplica); para Aurora ofrece también endpoints de solo lectura.
• Compatible con la mayoría de aplicaciones sin cambios de código (solo el endpoint).

Es el ejemplo que la guía pone de «proxy concepts» (task 2.2) y de «database connections and proxies» (3.3 y 4.3).

Amazon Aurora

Amazon Aurora es el motor relacional de AWS compatible con MySQL y PostgreSQL, con un almacenamiento distribuido propio.

Almacenamiento

• Cluster volume compartido: seis copias de los datos en tres AZ, independientemente de cuántas instancias tengas. Los datos sobreviven a la pérdida de una AZ.
• Crece solo según los datos (hasta 128 TiB, o 256 TiB en versiones concretas del motor) y, en versiones actuales, también decrece al borrar datos. Pagas lo usado.
• Separar cómputo y almacenamiento permite añadir réplicas en minutos (no copian datos) y hacer clonación rápida.

Réplicas, failover y endpoints

• Hasta 15 Aurora Replicas por clúster, con retraso típico de menos de 100 ms (leen del mismo volumen).
• Failover: si falla el writer, Aurora promociona una réplica (orden según prioridad de 0 a 15); el servicio vuelve normalmente en menos de 60 segundos y a menudo en menos de 30. Sin réplicas, Aurora recrea el writer, lo que suele tardar menos de 10 minutos. Para alta disponibilidad, al menos una réplica en otra AZ.
• Aurora Auto Scaling añade o quita réplicas según CPU o conexiones.
• Endpoints:
  • Cluster endpoint (writer): siempre apunta al primario actual.
  • Reader endpoint: reparte conexiones de lectura entre réplicas.
  • Custom endpoints: grupos de instancias (por ejemplo, réplicas grandes para analítica).
  • Instance endpoints: una instancia concreta (diagnóstico).

Aurora Global Database

Para aplicaciones globales y DR entre regiones:

• Un clúster primario (escrituras) y hasta 10 clústeres secundarios de solo lectura en otras regiones.
• Replicación a nivel de almacenamiento, con latencia típica inferior a 1 segundo y poco impacto en el primario.
• Switchover (planificado, sin pérdida de datos) y failover (tras una caída regional) para promover una región secundaria: RPO de segundos y RTO de minutos en la práctica, mucho mejor que las réplicas lógicas.
• Write forwarding: los secundarios pueden reenviar escrituras al primario (la aplicación local escribe sin conocer la región primaria).
• Cada secundario admite hasta 16 instancias de lectura.

Aurora Serverless v2

• La capacidad se mide en ACU (Aurora Capacity Unit, unos 2 GiB de memoria con su CPU y red). Defines un rango mínimo-máximo y Aurora escala en incrementos de hasta 0,5 ACU, sin cortes, mientras hay transacciones abiertas.
• Rango de 0 a 256 ACU en versiones recientes: con mínimo 0, la instancia se pausa automáticamente sin actividad (auto-pause) y deja de cobrar cómputo.
• Se puede mezclar con instancias provisionadas en el mismo clúster (por ejemplo, writer provisionado y readers serverless). Admite Multi-AZ, réplicas y Global Database.
• Casos: cargas variables o impredecibles, entornos de desarrollo, aplicaciones nuevas, SaaS multi-tenant. Para una carga estable y predecible, lo provisionado con reserva suele ser más barato.
• Aurora Serverless v1 está obsoleto: si ves «Aurora Serverless» en el examen, piensa en v2.

Clonación, backtrack y otras funciones

• Aurora cloning: crea en minutos un clúster nuevo que comparte el almacenamiento con el original usando copy-on-write (solo se copian las páginas que cambian). Ideal para probar en producción real sin afectarla ni duplicar coste de almacenamiento.
• Backtrack (solo Aurora MySQL): «rebobina» el clúster en el sitio a un momento anterior, en minutos, sin crear un clúster nuevo. Ventana máxima de 72 horas; hay que activarlo al crear el clúster (o al restaurar un snapshot). No sustituye a los backups. Aurora Global Database no lo admite.
• PITR y snapshots como en RDS (restaurar crea un clúster nuevo).
• Aurora I/O-Optimized frente a Aurora Standard (ver costes): con I/O-Optimized no pagas por operación de E/S.
• Babelfish (Aurora PostgreSQL entiende el protocolo y el T-SQL de SQL Server) y zero-ETL hacia Redshift para analítica casi en tiempo real sin pipelines.
• Amazon Aurora DSQL: base relacional distribuida y serverless, activa-activa multirregión, compatible con PostgreSQL. Es reciente y no figura en la guía; si aparece, piensa en «SQL distribuido con escrituras en varias regiones».

Amazon DynamoDB

DynamoDB es una base de datos NoSQL clave-valor y de documentos, serverless, con latencia de milisegundos de un dígito a cualquier escala, sin servidores ni versiones que gestionar. Replica automáticamente en varias AZ de la región.

Modelo de datos

• Tabla → items (hasta 400 KB cada uno) → atributos (esquema flexible salvo la clave).
• Primary key: solo partition key (clave de partición) o partition key + sort key (clave compuesta). La partition key decide en qué partición física vive el item: elige una con alta cardinalidad para repartir la carga y evitar particiones calientes (hot partitions).
• Operaciones: GetItem (por clave), Query (por partition key y rango de sort key; eficiente), Scan (lee toda la tabla; caro, evítalo), PutItem, UpdateItem, DeleteItem, BatchGetItem/BatchWriteItem, escrituras condicionales, y PartiQL (sintaxis tipo SQL).
• Lecturas: eventualmente consistentes por defecto; fuertemente consistentes si lo pides (no disponibles en GSI).

Capacidad: on-demand frente a provisioned

Unidades de capacidad (memorízalas, salen en cálculos):

• 1 RCU = 1 lectura fuertemente consistente por segundo de un item de hasta 4 KB, o 2 lecturas eventualmente consistentes. Las lecturas transaccionales cuestan el doble (2 RCU por 4 KB).
• 1 WCU = 1 escritura por segundo de un item de hasta 1 KB. Las escrituras transaccionales cuestan el doble.
• Se redondea hacia arriba por item: leer un item de 5 KB con consistencia fuerte cuesta 2 RCU; escribir uno de 1,5 KB cuesta 2 WCU.

Ejemplo: 80 lecturas/s fuertemente consistentes de items de 3 KB → 80 RCU. Si fueran eventualmente consistentes → 40 RCU. 100 escrituras/s de 512 bytes → 100 WCU.

• Auto scaling (con Application Auto Scaling) ajusta RCU/WCU hacia un objetivo de utilización (AWS recomienda 70 %).
• Superar la capacidad produce throttling (ProvisionedThroughputExceededException): reintentos con backoff, más capacidad, on-demand o mejor partition key.
• Table classes: Standard o Standard-IA (almacenamiento más barato y lecturas/escrituras más caras) para tablas con mucho dato y poco acceso.

Índices secundarios

Los índices copian (proyectan) atributos: KEYS_ONLY, INCLUDE o ALL. Proyectar lo justo abarata almacenamiento y escrituras.

DAX

DynamoDB Accelerator (DAX) es una caché en memoria compatible con la API de DynamoDB (cambias el cliente, no la lógica) que baja las lecturas de milisegundos a microsegundos.

• Ideal: lecturas muy repetidas, claves calientes (una oferta del día), cargas de lectura intensiva que quieren reducir RCU.
• No sirve para: lecturas fuertemente consistentes (DAX las pasa a la tabla), cargas de escritura intensiva o con pocas lecturas repetidas.
• Es un clúster en tu VPC (se paga por nodo-hora).

DAX frente a ElastiCache: DAX solo cachea DynamoDB y sin cambiar la lógica; ElastiCache cachea cualquier cosa (resultados de SQL, sesiones, cálculos) pero la aplicación gestiona la caché.

DynamoDB Streams

DynamoDB Streams registra cada cambio de item (inserción, modificación, borrado) en orden por item, durante 24 horas. Puedes elegir qué guarda (KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, NEW_AND_OLD_IMAGES). Se consume con Lambda (disparadores) para arquitecturas orientadas a eventos: enviar un correo al crear un pedido, actualizar un agregado, replicar a OpenSearch. Alternativa con más retención y consumidores: Kinesis Data Streams for DynamoDB (módulo 09).

Global tables

Global tables replican una tabla en varias regiones, todas activas en lectura y escritura (multi-active).

• Modo por defecto MREC (multi-Region eventual consistency): replicación asíncrona y resolución de conflictos last writer wins. RPO bajo (no cero).
• Modo MRSC (multi-Region strong consistency): lecturas fuertemente consistentes en cualquier región y RPO cero, con más latencia de escritura. El modo se elige al crear y no se cambia.
• Pueden abarcar varias cuentas (con MREC).
• Casos: aplicaciones globales con usuarios que escriben en su región, DR activo-activo entre regiones.

Backups, TTL, transacciones y otras funciones

• PITR: copias continuas con recuperación al segundo dentro de un periodo configurable de 1 a 35 días. Restaura a una tabla nueva (también en otra región).
• On-demand backups: copias completas que guardas el tiempo que quieras; también con AWS Backup (copias entre regiones y cuentas, cold storage, Vault Lock).
• Export to S3 (requiere PITR): exporta la tabla a S3 sin consumir capacidad, para analizarla con Athena o Glue. Import from S3 para cargas masivas.
• TTL (Time to Live): marcas un atributo con la fecha de caducidad (número, epoch en segundos) y DynamoDB borra los items caducados sin consumir capacidad de escritura, normalmente en unos pocos días tras caducar (filtra por fecha si no quieres verlos antes). Los borrados aparecen en Streams como borrados del servicio. Perfecto para sesiones, tokens y datos temporales (política de retención de datos gratuita).
• Transacciones: TransactWriteItems y TransactGetItems dan ACID en varios items y tablas (todo o nada), al doble de coste de capacidad.
• Cifrado en reposo siempre activo (clave propiedad de AWS, administrada por AWS o administrada por el cliente en KMS). Acceso con IAM, incluida granularidad por item (condición dynamodb:LeadingKeys). Acceso privado desde la VPC con gateway endpoint gratuito.
• Deletion protection para evitar borrar tablas por error.

Amazon ElastiCache y estrategias de caché

Amazon ElastiCache ofrece cachés en memoria gestionadas con latencia de submilisegundo. Motores actuales: Valkey (bifurcación de código abierto de Redis, recomendada por AWS en versiones nuevas), Redis OSS y Memcached. Puedes desplegarlo como clúster de nodos o como ElastiCache Serverless (sin dimensionar nodos).

Estrategias de caché (la guía las menciona en 2.1, 3.3 y 4.3):

• Lazy loading (cache-aside): la aplicación lee de la caché; si no está (cache miss), lee de la base de datos y la guarda en caché. Solo cachea lo que se pide; el dato puede quedar desactualizado.
• Write-through: al escribir en la base de datos, también se escribe en la caché. Datos siempre frescos, pero se cachea cosas que quizá nadie lea y cada escritura es más lenta.
• TTL: caducidad para limitar la antigüedad de los datos y liberar memoria. Lo habitual es combinar lazy loading + TTL.
• Sesiones: guardar el estado de sesión en ElastiCache (o DynamoDB) hace que los servidores web sean stateless y puedan escalar con Auto Scaling.

Dónde cachear: CloudFront (contenido en el borde), API Gateway (respuestas de API), ElastiCache (resultados de consultas, sesiones), DAX (DynamoDB), RDS/Aurora read replicas (no es caché, pero descarga lecturas).

Bases de datos de propósito específico

La guía pide «using purpose-built AWS services for workloads» (2.1 y 2.2). Resumen de las que no son RDS/Aurora/DynamoDB:

• Amazon Redshift: almacén de datos (data warehouse) columnar y MPP (procesamiento masivamente paralelo) para OLAP: consultas analíticas complejas sobre TB o PB con SQL. Provisionado (nodos RA3 con almacenamiento gestionado) o Redshift Serverless. Redshift Spectrum consulta datos en S3 sin cargarlos. No es para OLTP (muchas transacciones pequeñas). Se ve con más detalle en el módulo 09.
• Amazon DocumentDB (with MongoDB compatibility): base de documentos JSON gestionada, compatible con las APIs y drivers de MongoDB; almacenamiento distribuido al estilo de Aurora (seis copias en tres AZ, crece solo), réplicas de lectura, global clusters para DR y lecturas en otras regiones y elastic clusters (particionado horizontal para cargas de escritura muy grandes). «Migrar MongoDB a un servicio gestionado con cambios mínimos» → DocumentDB (con AWS DMS si hay que mover los datos en caliente).
• Amazon Keyspaces (for Apache Cassandra): serverless, compatible con Cassandra y CQL (reutilizas drivers y código), capacidad on-demand o provisionada con auto scaling, cifrado siempre activo, PITR y replicación multirregión. «Tenemos Cassandra y queremos dejar de gestionar nodos, parches y reparaciones» → Keyspaces.
• Amazon Neptune: base de datos de grafos (Gremlin, openCypher, SPARQL) para relaciones muy conectadas: redes sociales, motores de recomendación, detección de fraude, grafos de conocimiento. Almacenamiento replicado en tres AZ como Aurora, hasta 15 réplicas de lectura, Multi-AZ, Neptune Serverless (capacidad variable), Neptune Global Database y Neptune Analytics (análisis de grafos en memoria).

• Amazon Timestream: series temporales. Timestream for LiveAnalytics está en maintenance (no admite clientes nuevos desde junio de 2025); la opción vigente es Timestream for InfluxDB. La guía pide «cost-effective database types (time series format)»: para telemetría de IoT o métricas con marca de tiempo, una base de series temporales es más barata y eficiente que una relacional.
• Amazon QLDB (libro mayor inmutable) se cerró el 31/07/2025. Si aparece en material antiguo, hoy se resolvería con otras opciones (por ejemplo, Aurora PostgreSQL con tablas de auditoría o Object Lock para los registros).

Tabla «qué base de datos elijo»

Migración de bases de datos: AWS DMS

AWS Database Migration Service (DMS) migra datos entre bases de datos con la de origen operativa durante la migración. Al menos uno de los extremos debe estar en AWS.

• Homogénea (mismo motor: Oracle → RDS for Oracle, MySQL → Aurora MySQL): el esquema es compatible; a menudo bastan las herramientas nativas (dump/restore, replicación nativa) o DMS. Para MySQL/PostgreSQL → Aurora, también puedes crear una réplica de Aurora a partir de una instancia RDS y promocionarla.
• Heterogénea (motores distintos: Oracle → Aurora PostgreSQL, SQL Server → Aurora MySQL): hay que convertir el esquema y el código (procedimientos, funciones, tipos) antes de mover los datos:
  1. DMS Schema Conversion (función gestionada y web de DMS, construida sobre el motor de AWS SCT, Schema Conversion Tool, que también existe como herramienta de escritorio) evalúa, convierte el esquema y marca lo que requiere trabajo manual; puede usar IA generativa para convertir más objetos.
  2. DMS mueve los datos.
• Tipos de tarea: full load (carga completa), full load + CDC (change data capture: después de la carga, replica los cambios en continuo hasta el corte) o solo CDC. Con CDC, el tiempo de parada del corte es mínimo.
• Componentes: replication instance (o DMS Serverless, que dimensiona solo), endpoints de origen y destino, y tareas.
• Destinos no relacionales también: S3 (data lake), DynamoDB, Redshift, Kinesis, OpenSearch…

Optimización de costes en bases de datos

Trampas típicas del examen

• Multi-AZ para escalar lecturas (en Multi-AZ DB instance): no; el standby no sirve lecturas. Réplicas o Multi-AZ DB cluster.
• Read replica para alta disponibilidad automática: no; la promoción es manual y la replicación asíncrona puede perder datos recientes.
• Cifrar una RDS existente: no se activa en caliente → snapshot, copia cifrada, restaurar.
• Restaurar un snapshot o PITR crea una instancia nueva con otro endpoint.
• Aurora sin réplicas no hace failover rápido (recrea la instancia).
• Backtrack solo en Aurora MySQL y hay que activarlo al crear.
• Aurora Global Database vs cross-Region read replica de RDS: para RPO de segundos y RTO de minutos con Aurora, Global Database.
• RDS Proxy no es público y va en la misma VPC; no es una caché de consultas.
• DynamoDB Scan para búsquedas frecuentes: no; diseña claves o índices y usa Query.
• LSI tras crear la tabla: imposible; GSI.
• Lecturas fuertemente consistentes en un GSI o a través de DAX: no.
• DAX para escrituras intensivas: no aporta.
• Memcached cuando piden persistencia, replicación o failover: no; Valkey/Redis OSS.
• Redshift para OLTP o RDS para analítica de PB: al revés.
• DynamoDB para joins complejos y consultas ad hoc: mala elección; relacional.
• Global tables resuelven conflictos con last writer wins (en MREC).
• TTL no borra al instante (puede tardar días).
• Aurora I/O-Optimized solo compensa con E/S alta (≥ 25 % del gasto).
• QLDB y Timestream for LiveAnalytics ya no admiten clientes nuevos.
• DocumentDB no es «DynamoDB con otro nombre»: si el enunciado dice MongoDB-compatible o «reutilizar los drivers y consultas de MongoDB», es DocumentDB; si dice «clave-valor serverless a cualquier escala» sin mencionar MongoDB, es DynamoDB.
• Keyspaces frente a DynamoDB: ambos son serverless, pero Keyspaces solo tiene sentido si hay Cassandra/CQL que conservar. Cassandra autogestionado en EC2 casi nunca es la respuesta de LEAST operational overhead.
• Neptune frente a relacional: «consultas de varios saltos sobre relaciones» (amigos de amigos, cadenas de transacciones sospechosas) → grafo. Resolverlo con muchos joins en RDS es el distractor.
• Migración heterogénea sin conversión de esquema: falta DMS Schema Conversion/SCT.

Resumen

• Multi-AZ = disponibilidad (instance: 1 standby pasivo, síncrono; cluster: 2 readers legibles, semisíncrono, MySQL/PostgreSQL).
• Read replicas = lecturas y DR (asíncronas, hasta 15, misma región o entre regiones, promoción manual).
• RDS: storage autoscaling, Provisioned IOPS, backups de hasta 35 días con PITR, snapshots manuales, cifrado solo al crear.
• RDS Proxy: pool de conexiones, Lambda, failover más rápido, IAM + Secrets Manager.
• Aurora: 6 copias en 3 AZ, 15 réplicas, endpoints, Global Database (10 secundarias, menos de 1 s de retraso), Serverless v2 (0-256 ACU), clonación, backtrack (MySQL, 72 h), I/O-Optimized.
• DynamoDB: on-demand (por defecto) o provisioned; RCU = 4 KB, WCU = 1 KB; GSI/LSI; DAX; Streams 24 h; global tables (MREC/MRSC); PITR 1-35 días; TTL; transacciones.
• ElastiCache: Valkey/Redis OSS (estructuras, réplica, failover, persistencia) frente a Memcached (simple, multihilo); lazy loading, write-through, TTL.
• Propósito específico: Redshift (OLAP), DocumentDB (MongoDB), Keyspaces (Cassandra), Neptune (grafos), Timestream (series temporales).
• DMS (full load + CDC) y DMS Schema Conversion/SCT para migraciones heterogéneas.
• Costes: tamaño adecuado, RI, Database Savings Plans, serverless, I/O-Optimized, retención ajustada.

Cobertura del temario

Practica lo aprendido

Documentación oficial para ampliar

• Configuring and managing a Multi-AZ deployment for Amazon RDS
• Working with DB instance read replicas
• Amazon RDS Proxy
• Amazon Aurora storage
• Using Amazon Aurora Global Database
• How Aurora serverless works
• DynamoDB throughput capacity
• In-memory acceleration with DynamoDB Accelerator (DAX)
• Comparing Valkey, Memcached, and Redis OSS clusters
• Converting database schemas using DMS Schema Conversion
• Database Savings Plans