Amazon DVA-C02: Bases de datos y almacenamiento en caché (RDS, Aurora, ElastiCache, Timestream, Proxy) — Guía de estudio

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Forma parte de la AWS Developer Associate DVA-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

RDS y Aurora: diseño, escalado y cifrado

El diseño de bases de datos relacionales en RDS o Aurora comienza con los compromisos de la carga de trabajo entre un RDS provisionado de nodo único y el almacenamiento distribuido de Aurora. Elija Aurora cuando necesite una alta escalabilidad de lectura y una conmutación por error (failover) rápida: las réplicas de Aurora comparten el volumen del clúster, por lo que la promoción es rápida, mientras que las réplicas de lectura de RDS MySQL/Postgres utilizan replicación asíncrona basada en binlog y pueden presentar retraso. Para escalar las lecturas, agregue réplicas de lectura y dirija el tráfico de lectura de la aplicación hacia ellas; utilice los puntos de enlace de lector (reader endpoints) en Aurora para balancear automáticamente entre las réplicas. Para las escrituras, el escalado vertical (clase de instancia) y un diseño cuidadoso de esquemas e índices son importantes. Habilite siempre el cifrado en reposo con una CMK de KMS en el momento de la creación; habilitar el cifrado más tarde requiere una restauración a partir de un snapshot en una nueva instancia cifrada, lo cual es una trampa común. Para la protección en tránsito, fuerce las conexiones TLS/SSL (RDS proporciona paquetes de CA). Para las credenciales, prefiera AWS Secrets Manager con rotación automática utilizando la plantilla Lambda de rotación de RDS integrada; obtenga los secretos mediante programación con SecretsManager.getSecretValue() en los SDK. Considere la autenticación de base de datos de IAM para eliminar las contraseñas estáticas: genere un token a través de RDS.Signer (SDK) o rds.generate-db-auth-token, y luego conéctese con un token de corta duración. Instrumente utilizando Performance Insights, Enhanced Monitoring y CloudWatch; utilice los registros de consultas lentas (slow query logs) y EXPLAIN para los puntos calientes (hotspots).

Pool de conexiones, RDS Proxy y patrones serverless

Las funciones serverless y las aplicaciones con uso intensivo de conexiones suelen agotar los límites de conexión de la base de datos. El patrón más sencillo en Node.js es colocar un pool de mysql2/promise en el ámbito global de Lambda y reutilizarlo entre invocaciones, pero esto no resuelve el escalado concurrente masivo. RDS Proxy es la respuesta gestionada: cree el proxy con create_db_proxy, asócielo con secretos de Secrets Manager e instancias de RDS/Aurora de destino, y utilice el punto de enlace (endpoint) del proxy desde su aplicación. RDS Proxy gestiona la multiplexación de conexiones, la integración con la autenticación de IAM y la conmutación por error (failover). Para Aurora Serverless o cuando prefiera llamadas de tipo HTTP, utilice la RDS Data API: rdsdataservice.executeStatement({resourceArn, secretArn, sql, database}) permite a las funciones Lambda ejecutar SQL sin conexiones TCP persistentes. Un problema común es mezclar la Data API con clústeres provisionados: la Data API está diseñada para clústeres serverless y tiene una semántica de latencia y transacciones diferente. Tenga en cuenta también que RDS Proxy introduce un tiempo de espera del pool de conexiones y max_connections; ajuste el tiempo de espera del cliente inactivo (idle client timeout) y el préstamo de conexiones (connection borrowing) para las ráfagas de Lambda. Utilice SecretsManager.getSecretValue() para las credenciales y rótelas con rotateSecret o habilite la rotación automática en la consola/SDK.

Estrategias de caché: ElastiCache, DAX y diseño de caché

Las decisiones sobre el almacenamiento en caché dependen del almacén de datos y los patrones de acceso. Para DynamoDB, DAX proporciona una latencia de lectura de microsegundos y una integración transparente con el SDK a través de AmazonDaxClient, que envuelve a DynamoDB.DocumentClient; es ideal para cargas de trabajo de lectura intensiva y con consistencia eventual. Para el almacenamiento en caché relacional o de clave-valor arbitrario, utilice ElastiCache Redis para estructuras de datos avanzadas, persistencia (snapshots AOF/RDB), replicación y fragmentación (sharding) en modo clúster, o Memcached para un almacenamiento en caché simple y escalable horizontalmente. Implemente el patrón cache-aside para las lecturas y write-through/write-behind solo cuando sea aceptable en términos de consistencia y complejidad. El diseño de las claves es fundamental: utilice prefijos en las claves por aplicación y versión, use TTLs razonables y evite la cardinalidad ilimitada. Gestione las estampidas de caché (cache stampedes) con patrones de bloqueo y actualización (lock-and-refresh) como SETNX o Redlock, o con una actualización probabilística temprana del TTL. Configure Redis con Multi-AZ y conmutación por error (failover) automática; cree grupos de replicación con conmutación por error automática y snapshots a través de CreateReplicationGroup. Las trampas comunes incluyen cachés obsoletas después de las escrituras, no invalidar la caché ante cambios de esquema y esperar una consistencia absoluta. Supervise la tasa de aciertos de caché (cache hit ratio) y las métricas de desalojo (eviction metrics) en CloudWatch y escale los tipos de nodo o los shards del clúster cuando la memoria o la CPU se conviertan en un cuello de botella.

Series temporales con Timestream y patrones de réplicas de lectura

Amazon Timestream está diseñado específicamente para series temporales: ingesta datos usando la API WriteRecords del SDK con llamadas WriteRecords por lotes y consulta con TimestreamQuery.query(sql). Diseña el esquema de tus registros con dimensiones de baja cardinalidad y usa registros de múltiples medidas (multi-measure) para reducir la amplificación de escritura. Configura reglas de retención en memoria y magnéticas por tabla para mantener los datos recientes “calientes” (hot) y almacenar económicamente los datos más antiguos; ajustar la retención es crítico porque el tamaño de la retención en el nivel de memoria afecta el costo y el rendimiento de las consultas. Para el análisis, utiliza consultas específicas de series temporales (time_bin o bin) y aplica filtros (push down) sobre las dimensiones para minimizar los datos escaneados. Al integrar series temporales con almacenes relacionales, descarga los datos históricos inmutables a Timestream y sirve los metadatos “calientes” (hot) desde RDS/Aurora con ElastiCache. Para el escalado de lectura relacional, añade réplicas de lectura y dirige el tráfico de solo lectura; para Aurora, usa los endpoints de lector (reader endpoints) y examina el retraso de la réplica (CloudWatch ReplicaLag) antes de dirigir lecturas críticas. Un error común de los desarrolladores (gotcha) es la alta cardinalidad en Timestream o en las claves de caché producidas por solicitud, lo que dispara el almacenamiento y perjudica el rendimiento. Usa el procesamiento por lotes para las escrituras y pipelines de ingesta asíncronos (Kinesis, Firehose) para suavizar los picos y evitar el throttling.

Problema práctico: Escenario de caso de uso

Escenario: NovaShop opera una plataforma de comercio electrónico multirregional en AWS usando Aurora MySQL para los pedidos en us-east-1, con APIs basadas en Lambda y un catálogo global de clientes en DynamoDB. Los desarrolladores usan CI/CD en una única cuenta de AWS y almacenan las credenciales de la base de datos en Secrets Manager.

Desafío: Durante los picos de ventas, las funciones Lambda agotan las conexiones de la base de datos y el catálogo necesita lecturas de microsegundos; los desarrolladores deben preservar la seguridad con credenciales rotadas y una latencia mínima para las lecturas de productos.

Enfoque recomendado:

Crea un RDS Proxy para el clúster de Aurora usando CreateDBProxy, vincula el ARN del secreto de Secrets Manager y configura la autenticación IAM; actualiza Lambda para usar el endpoint del proxy y SecretsManager.getSecretValue() para las credenciales.
Para el catálogo, despliega un clúster de Amazon DAX y cambia el cliente de DynamoDB a AmazonDaxClient({endpoints}), que envuelve al DynamoDB DocumentClient para lecturas de microsegundos.
Habilita la rotación automática de Secrets Manager para el secreto de Aurora usando la plantilla Lambda de rotación de RDS (rotate-secret o configúralo a través de la consola) y asegúrate de que el rol IAM de Lambda pueda llamar a secretsmanager:GetSecretValue.
Añade un clúster de ElastiCache para Redis (en modo clúster) para el almacenamiento en caché de sesiones e implementa el patrón cache-aside con TTLs y un bloqueo de actualización SETNX para prevenir estampidas (stampedes).

Justificación: Usar RDS Proxy previene las tormentas de conexiones por el escalado de Lambda, mientras que IAM/Secrets Manager protege las credenciales con rotación automatizada; DAX proporciona lecturas de microsegundos en DynamoDB y ElastiCache maneja el almacenamiento en caché transitorio de sesiones/lecturas, alineándose con las mejores prácticas de escalado sin servidor y seguridad.

← Almacenamiento · Todos los dominios · Mensajería →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →