Amazon SAA-C03: Bases de Datos y Caching — Guía de estudio

By Laurynas Brazys · 15 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

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

Amazon RDS: Motores Relacionales Administrados

Amazon RDS ofrece seis motores administrados — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server y Amazon Aurora (compatible con MySQL y PostgreSQL) — que abstraen el parcheo, las copias de seguridad, la topología de replicación y la conmutación por error. La elección del motor determina las licencias, la semántica de las copias de seguridad y la disponibilidad de las características: Oracle y SQL Server tienen distinciones entre BYOL (Bring Your Own License) y License Included, SQL Server admite hasta cinco réplicas de lectura a través de replicación nativa, y las réplicas de lectura de Oracle requieren Enterprise Edition con Active Data Guard.

Las dos características de RDS más utilizadas para la disponibilidad y la escalabilidad —y las dos que se confunden con mayor frecuencia— son las implementaciones Multi-AZ y las réplicas de lectura. Son ortogonales, complementarias y no intercambiables.

Multi-AZ aprovisiona una réplica en espera síncrona en una segunda Zona de Disponibilidad. Cada escritura se confirma tanto en la primaria como en la de espera antes del reconocimiento, lo que da un RPO (Recovery Point Objective) efectivamente en cero y un RTO (Recovery Time Objective) de 60 a 120 segundos durante la conmutación por error automática. La réplica en espera no acepta tráfico — existe únicamente para la conmutación por error. Cuando la primaria falla, una AZ está deteriorada o el mantenimiento requiere un reinicio, RDS cambia el CNAME de DNS a la réplica en espera y las aplicaciones se reconectan de forma transparente a través del mismo endpoint. Multi-AZ es la solución de menor esfuerzo para un punto único de falla en una sola AZ: es un interruptor de configuración, no requiere cambios de esquema o aplicación, y preserva el endpoint. La más reciente implementación de clúster Multi-AZ es una topología de tres nodos (un escritor, dos réplicas en espera legibles) que utiliza replicación semi-síncrona con una latencia de confirmación de aproximadamente un segundo, lo que proporciona alta disponibilidad más una descarga de lectura limitada.

Las réplicas de lectura utilizan la replicación asíncrona nativa del motor (binlog de MySQL, streaming WAL de PostgreSQL). Son la herramienta correcta para la escalabilidad de lectura — consultas analíticas, paneles de informes, SELECTs ad-hoc — que de otro modo saturarían el OLTP en la primaria. El escenario canónico: una base de datos de procesamiento de pedidos que se agota porque los empleados ejecutan informes largos de fin de mes. Añadir una réplica de lectura y apuntar la herramienta de informes a su endpoint aísla la carga analítica sin aumentar el tamaño de la primaria. Las réplicas de lectura pueden ser entre regiones y pueden promoverse manualmente a bases de datos independientes, pero la promoción nunca es automática y cualquier transacción aún no replicada en el momento del fallo se pierde.

Dos trampas se repiten en este espacio. Primero, tratar las réplicas de lectura como una solución de alta disponibilidad es incorrecto por múltiples razones: las réplicas son asíncronas (pérdida potencial de datos), no tienen promoción automática, el endpoint cambia en la promoción y las transacciones en curso desaparecen. Si un diseño promete “cero pérdida de datos” y apunta a una réplica de lectura como objetivo de conmutación por error, esa promesa es falsa. Segundo, aprovisionar Multi-AZ para servir tráfico de lectura desperdicia dinero porque la réplica en espera no es legible en la topología estándar. Multi-AZ resuelve la disponibilidad; las réplicas de lectura resuelven la escalabilidad de lectura; a menudo se desean ambas.

Las réplicas de lectura tampoco hacen nada por la escalabilidad de escritura — cada escritura sigue llegando a la primaria y las réplicas deben reproducirla. Para la escalabilidad de escritura, se realiza sharding, se migra a Aurora (almacenamiento desacoplado) o se rediseña hacia DynamoDB.

Dimensionamiento Correcto de las Réplicas de Lectura

Una réplica no tiene por qué coincidir con la clase de instancia de la primaria. La primaria maneja la carga completa de escritura más las lecturas; una réplica maneja solo las lecturas que la alcanzan. Una primaria db.r6i.4xlarge emparejada con una réplica db.r6i.large para un trabajo de informes nocturno es completamente razonable, siempre que la réplica se mantenga al día con el I/O de replicación. La metodología es: medir la CPU, la memoria y el retraso de replicación reales de la réplica, y luego dimensionarla para esa carga de trabajo. La única advertencia: si se tiene la intención de promover una réplica para que se convierta en la primaria durante la recuperación ante desastres, debe dimensionarse para manejar la carga de escritura. Las réplicas subdimensionadas no son objetivos de promoción.

Implementaciones Blue/Green y Almacenamiento

Las Implementaciones Blue/Green de RDS crean una copia de staging completa de producción (verde) que se mantiene sincronizada a través de replicación lógica. Se actualiza la versión del motor, se cambian los grupos de parámetros o se alteran los esquemas en verde, se prueba y se cambia en menos de un minuto con el cambio de nombre automático del endpoint. Esto elimina el riesgo clásico de actualización in-place donde una actualización fallida de una versión principal fuerza una reversión de instantánea.

La selección del almacenamiento importa tanto como la clase de instancia para OLTP con mucha escritura. La taxonomía gp3/io2:

La mejora de gp3 sobre gp2 es el desacoplamiento de IOPS del tamaño — ya no se sobreaprovisiona capacidad para el rendimiento. Elija io2 cuando las IOPS sostenidas superen el límite de gp3 o cuando se requiera una durabilidad del 99.999%. Multi-Attach permite que un solo volumen io2 se conecte a hasta 16 instancias Nitro, pero el sistema de archivos o la aplicación deben ser conscientes del clúster; no es un sustituto de la replicación. Una trampa de interrupción latente: aprovisionar almacenamiento fijo sin la escalabilidad automática de almacenamiento habilitada o una alarma de CloudWatch en FreeStorageSpace. Cuando el espacio libre llega a cero, RDS entra en storage-full y rechaza las escrituras.

Amazon Aurora: Arquitectura y Endpoints

Aurora reimplementa la capa de almacenamiento subyacente a MySQL y PostgreSQL como un volumen distribuido, estructurado por logs y replicado seis veces, que abarca tres AZs. Los nodos de cómputo son sin estado con respecto al almacenamiento, por lo que una réplica de Aurora lee del mismo volumen subyacente que el escritor en lugar de reproducir un log. El retraso de replicación es típicamente de 10 a 20 ms, en comparación con segundos para las réplicas estándar de RDS, y un clúster soporta hasta 15 réplicas que pueden ser promovidas a escritor en aproximadamente 30 segundos.

Aurora expone cuatro tipos de endpoints:

Los endpoints personalizados son importantes cuando las réplicas son heterogéneas. Si tres de seis réplicas son db.r6g.8xlarge para informes analíticos, mientras que el resto sirve lecturas OLTP, el endpoint de lector general ocasionalmente enruta los informes a nodos más pequeños, lo que perjudica la previsibilidad. Un endpoint personalizado limitado solo a las réplicas grandes proporciona un aislamiento de carga de trabajo determinista:

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

Tenga en cuenta que los TTL de DNS de los endpoints de Aurora son de 5 segundos; almacenar en caché las cadenas de conexión por más tiempo anula el comportamiento de conmutación por error.

Aurora Auto Scaling añade y elimina lectores basándose en métricas de CPU o conexión objetivo, lo cual es la respuesta canónica para cargas de trabajo impredecibles y con muchas lecturas que deben permanecer altamente disponibles:

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

Cuando las réplicas de lectura de RDS MySQL no pueden mantener el retraso de replicación por debajo de un segundo en el pico, la respuesta de bajo código es migrar a Aurora MySQL: las cadenas de conexión apenas cambian y la replicación a nivel de almacenamiento elimina el retraso.

Aurora Serverless v2 y Clonación

Aurora Serverless v2 escala el cómputo verticalmente en unidades de capacidad de Aurora (ACUs, 2 GiB de memoria cada una) de grano fino en aproximadamente medio segundo, sin desconectar sesiones. Es adecuado para cargas de trabajo variables con una huella de memoria base conocida; por ejemplo, una migración de MySQL local que siempre consume al menos 2 GiB. Establezca el mínimo en 1 ACU, el máximo en 32 ACUs, y el clúster se adaptará sin administración. Aurora aprovisionado sigue siendo preferible cuando la carga es constante y predecible, ya que Serverless v2 conlleva un costo adicional por ACU.

La clonación de Aurora crea un nuevo clúster que comparte las páginas de almacenamiento de la fuente mediante copy-on-write. Los clones aparecen en segundos y no cuestan nada hasta que los datos divergen, lo que los hace ideales para entornos de staging, migraciones arriesgadas o para permitir que los analistas trabajen con una copia de producción. Una restauración de snapshot rehidrata físicamente los datos y puede tardar horas; la clonación es mejor cuando la velocidad importa.

Aurora Global Database

Aurora Global Database extiende un clúster a hasta cinco regiones secundarias utilizando una infraestructura de replicación dedicada a nivel de almacenamiento, no el envío de binlogs. El retraso de replicación típico es inferior a un segundo, el RPO es inferior a un segundo y la conmutación por error gestionada promueve una secundaria en menos de un minuto.

Dos semánticas críticas: las regiones secundarias son de solo lectura durante la operación normal, y Global Database está diseñada para DR de bajo RPO y lecturas remotas de baja latencia, no para multi-maestro activo-activo. Asumir que una base de datos global “maneja automáticamente las escrituras en la región secundaria” es incorrecto; las escrituras allí requieren una conmutación por error gestionada explícita o un detach-and-promote. Para un requisito establecido de RPO de 5 minutos / RTO de 20 minutos entre regiones con una sobrecarga operativa mínima, Global Database es la respuesta canónica.

RDS Proxy y Gestión de Conexiones

Las cargas de trabajo sin servidor y altamente concurrentes agravan un problema clásico: las tormentas de conexiones. Una función Lambda que escala a 3.000 ejecuciones concurrentes abre 3.000 sockets, superando max_connections y causando fallas en cascada, precisamente cuando el sistema está bajo carga. Los pools dentro de la función no ayudan porque cada entorno de ejecución concurrente está aislado.

RDS Proxy se sitúa entre los clientes y la base de datos, manteniendo un pool de conexiones “caliente” y multiplexando las sesiones de los clientes en ellas. Resuelve dos problemas:

1. Tormentas de conexiones. Miles de sesiones de clientes se multiplexan en un pequeño pool de backend.
2. Tiempo de conmutación por error. El proxy mantiene las conexiones de los clientes abiertas mientras restablece el enlace de backend, reduciendo el tiempo de conmutación por error percibido hasta en un 66% y eliminando el restablecimiento de TCP/TLS del lado del cliente y la resolución de DNS.

Se integra con IAM y Secrets Manager para el manejo de credenciales, eliminando secretos codificados del código de la aplicación.

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

Las aplicaciones se conectan al endpoint del proxy, no al endpoint del clúster. Cualquier arquitectura de Lambda a RDS o de alta fan-out debería usar RDS Proxy a menos que haya una razón específica para no hacerlo. Ejecutar su propio pooler (PgBouncer, ProxySQL) en EC2 es posible, pero añade la sobrecarga operativa que el proxy existe para eliminar.

DynamoDB: Modos de Capacidad

DynamoDB es un almacén de clave-valor/documentos gestionado con latencia de un solo dígito de milisegundo a cualquier escala, particionado horizontalmente por clave hash. Ofrece dos modos de capacidad:

El modo bajo demanda es drásticamente más simple, pero cuesta aproximadamente 6-7 veces más por solicitud que la capacidad aprovisionada bien utilizada. Para un lote nocturno de 4 horas a 500 WCU, el modo bajo demanda paga significativamente más; el aprovisionado con escalado programado o capacidad reservada es mucho más barato. Por el contrario, usar el aprovisionado para una carga de trabajo impredecible de lanzamiento público provoca ralentizaciones. Para cargas de trabajo estables con varianza moderada, el aprovisionado con autoescalado de seguimiento de objetivos alrededor del 70% de utilización es significativamente más barato que el bajo demanda, a menudo entre un 50% y un 70%:

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

Puedes cambiar de modo una vez cada 24 horas. Asumir que el modo bajo demanda es universalmente más barato es un error costoso; también lo es asumir que el aprovisionado siempre es adecuado para el tráfico con picos.

DynamoDB: Consistencia, Streams, Tablas Globales

Las lecturas por defecto son eventualmente consistentes (pueden devolver datos obsoletos en ~1 segundo, cuestan 0.5 RCU). Establecer ConsistentRead=true devuelve el último valor confirmado al doble del costo. Las lecturas fuertemente consistentes no son compatibles a través de índices secundarios globales ni a través de DAX; esas rutas siempre devuelven datos eventualmente consistentes.

DynamoDB Streams captura cambios a nivel de ítem como un registro ordenado retenido durante 24 horas, activando Lambda para procesamiento posterior (indexación de búsqueda, notificaciones, desnormalización entre tablas) sin sondeo.

Las Tablas Globales se basan en Streams para proporcionar replicación multiactiva y multiregión con resolución de conflictos de “último escritor gana”. Son la respuesta correcta cuando las lecturas y escrituras deben ser locales en varias regiones. Pero duplican aproximadamente los costos de almacenamiento y escritura (cada escritura es una WCU en cada región réplica) y debilitan la consistencia entre regiones. La trampa es habilitar las Tablas Globales cuando una sola región satisface los requisitos de disponibilidad: DynamoDB en una sola región ya está replicado en tres AZs con un 99.99% de disponibilidad. La alta disponibilidad rentable en una sola región es una tabla de una sola región con PITR habilitado y, si se desea, capacidad aprovisionada con autoescalado.

La Recuperación a un punto en el tiempo (PITR) proporciona copias de seguridad continuas con granularidad de restauración por segundo durante los últimos 35 días con una sobrecarga insignificante. Habilítala en cualquier tabla de producción; satisface los requisitos típicos de RPO de minutos en lugar de horas. Para una retención más prolongada (retenciones regulatorias), integra AWS Backup para copias de seguridad programadas, gestionadas por ciclo de vida y copiables entre regiones.

TTL te permite especificar un atributo que contiene una expiración de época Unix; DynamoDB elimina asincrónicamente los ítems caducados sin costo, ideal para almacenes de sesiones, tokens efímeros o cachés de eventos. Las eliminaciones de TTL fluyen a través de Streams para el archivo posterior:

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

Para análisis, la exportación a S3 produce una instantánea de punto en el tiempo legible por Athena, Redshift Spectrum o EMR sin consumir capacidad de tabla, un patrón mucho mejor que escanear la tabla.

DAX: Acelerador de DynamoDB

DAX es una caché en memoria de escritura directa totalmente administrada específicamente para DynamoDB, que ofrece una latencia de lectura de microsegundos en comparación con la línea base de milisegundos de un solo dígito de DynamoDB. Su característica distintiva es la compatibilidad con la API: el cliente DAX es un reemplazo directo para el cliente SDK de DynamoDB, por lo que las aplicaciones lo adoptan cambiando la configuración del punto final en lugar de reescribir la lógica de consulta:

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

DAX mantiene dos cachés: una caché de ítems para los resultados de GetItem/BatchGetItem y una caché de consultas para los resultados de Query/Scan. Las escrituras son de escritura directa (DAX actúa como proxy para DynamoDB y actualiza su caché de ítems si tiene éxito), pero la caché de consultas se basa en TTL, por lo que los resultados de las consultas pueden volverse obsoletos incluso para ítems recién escritos.

Dos restricciones importan. Primero, DAX solo acelera las lecturas eventualmente consistentes; las lecturas fuertemente consistentes omiten la caché. Segundo, otros escritores que omiten DAX causan obsolescencia. Para una página de detalles de producto visitada millones de veces al día, DAX es el acelerador con menor sobrecarga operativa: sin código de invalidación de caché, sin gestión de clústeres separada. ElastiCache delante de DynamoDB funcionaría, pero requiere una lógica de caché lateral que DAX hace innecesaria.

ElastiCache: Redis y Memcached

ElastiCache ofrece acceso a datos en memoria en submilisegundos como un servicio gestionado que ejecuta Redis o Memcached. La elección del motor se basa en las características:

• Memcached — caché de clave/valor multiproceso puro con sharding horizontal, sin persistencia, sin replicación, sin pub/sub. Úselo solo para el almacenamiento en caché efímero donde la pérdida de toda la caché es aceptable.
• Redis — admite replicación, Multi-AZ con conmutación por error automática, modo clúster para sharding, persistencia, pub/sub, conjuntos ordenados, transacciones y cifrado en tránsito y en reposo. Requerido para cualquier cosa duradera o que requiera tipos de datos complejos.

Dos patrones canónicos dominan.

Almacén de sesiones centralizado. Cuando un ALB distribuye el tráfico entre instancias EC2 o ECS sin estado, el almacenamiento de sesiones local fuerza las sesiones persistentes, lo que desequilibra la carga y falla durante la reducción de escala, las implementaciones y los fallos de AZ. Externalizar las sesiones a Redis permite que cualquier instancia atienda cualquier solicitud, y las sesiones sobreviven a los fallos del host:

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

Descarga de lectura para consultas costosas — tablas de clasificación (conjuntos ordenados de Redis a través de ZADD/ZREVRANGE), búsquedas de catálogos, agregaciones. Las estrategias de almacenamiento en caché deben coincidir con las necesidades de consistencia:

• Carga perezosa (cache-aside): la aplicación lee la caché; si no la encuentra, lee la base de datos y rellena la caché con un TTL. Simple, pero las fallas en frío duelen y los datos pueden estar obsoletos.
• Write-through: la aplicación escribe en la caché y en la base de datos en la misma operación. La caché se mantiene fresca, pero las escrituras son más lentas y los datos no utilizados siguen ocupando memoria.
• Write-back (write-behind): las escrituras van primero a la caché, se vacían asincrónicamente a la base de datos. Las escrituras más rápidas, pero un fallo de la caché pierde datos.

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

Confiar en cualquier capa de almacenamiento en caché sin una estrategia de invalidación — TTL, DEL explícito en la actualización o write-through — produce lecturas obsoletas. El modo de fallo es silencioso: la aplicación parece correcta hasta que los usuarios notan la divergencia. El almacenamiento en caché también suele ser la forma más económica de escalar las lecturas más allá de lo que las réplicas de lectura soportan cómodamente y protege al primario durante los picos de tráfico.

A diferencia de DAX, ElastiCache es agnóstico al motor — usted es el dueño de la lógica de invalidación — por lo que DAX gana en simplicidad operativa cuando el almacén de respaldo es DynamoDB.

Migración: DMS y SCT

AWS Database Migration Service (DMS) replica datos entre motores homogéneos (Oracle→Oracle, MySQL→Aurora MySQL) o heterogéneos (Oracle→Aurora PostgreSQL, SQL Server→RDS MySQL, on-prem→DynamoDB). Una tarea de DMS tiene tres fases:

1. Carga completa — copia masiva de filas existentes.
2. CDC (captura de datos de cambios) — rastrea el registro de transacciones de la fuente y aplica los cambios en curso.
3. Carga completa + CDC — el patrón común de tiempo de inactividad mínimo: la fuente permanece en línea, DMS mantiene el destino sincronizado, el cambio es un breve cambio de DNS.

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

DMS Serverless elimina la necesidad de dimensionar y administrar instancias de replicación — la capacidad se aprovisiona automáticamente a la carga de trabajo, lo que se adapta a CDC variable o de larga duración. Los motores de origen deben tener habilitado el registro suplementario (Oracle) o el registro binario en formato ROW (MySQL). Para semillas muy grandes, DMS se integra con Snowball Edge para cargas fuera de línea.

DMS mueve datos, no esquemas. Para migraciones heterogéneas, lo combina con la AWS Schema Conversion Tool (SCT), que convierte procedimientos almacenados, vistas, disparadores, secuencias y tipos específicos de dialecto — por ejemplo, Oracle PL/SQL a PostgreSQL PL/pgSQL, o T-SQL a Aurora MySQL. SCT produce un informe de evaluación que señala los objetos que requieren reelaboración manual (típicamente del 5 al 20% para bases de código complejas). Ejecutar DMS solo para una migración entre motores es un error común: si bien DMS puede crear tablas de destino rudimentarias, no traduce procedimientos ni tipos propietarios correctamente. Para migraciones homogéneas, SCT es innecesario — las herramientas nativas (mysqldump, pg_dump, RMAN) más DMS CDC son suficientes.

El patrón completo entre motores:

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

Copias de seguridad y recuperación a un momento dado

Las copias de seguridad automatizadas de RDS combinan instantáneas diarias con copias de seguridad de registros de transacciones de 5 minutos, lo que permite la recuperación a un momento dado (PITR) a cualquier segundo dentro de la ventana de retención (1 a 35 días, 7 por defecto). La restauración crea una nueva instancia — no se puede restaurar en el mismo lugar — por lo que los puntos finales de la aplicación o los CNAME deben actualizarse. Las instantáneas manuales persisten más allá de la retención y sobreviven a la eliminación de la instancia (sujeto a la configuración de la instantánea final), se pueden copiar entre regiones para DR y se pueden compartir entre cuentas.

Fast Snapshot Restore (FSR) para instantáneas respaldadas por EBS elimina la penalización de carga perezosa, lo que brinda a los volúmenes restaurados un rendimiento completo de inmediato — útil al iniciar múltiples entornos desde una instantánea bajo presión de tiempo. La clonación de Aurora omite las instantáneas por completo para copias en la misma región. DynamoDB PITR es una característica paralela que debe habilitarse por tabla y produce una nueva tabla al restaurar.

Bases de datos diseñadas para un propósito específico

La selección de un motor diseñado para un propósito específico cuando los patrones de acceso lo exigen evita una re-arquitectura costosa. Amazon Neptune es una base de datos de gráficos administrada que admite Gremlin, openCypher y SPARQL — apropiada cuando las consultas atraviesan relaciones (redes de fraude, gráficos sociales, gráficos de conocimiento) donde las uniones recursivas en un motor relacional serían prohibitivamente costosas. Amazon QLDB es un libro mayor inmutable y criptográficamente verificable con un diario de solo anexión, adecuado para sistemas de registro que requieren auditorías a prueba de manipulaciones — procedencia de la cadena de suministro, transacciones financieras, registros de DMV. DynamoDB es el valor predeterminado para el acceso de clave-valor o documento en milisegundos de un solo dígito a cualquier escala, utilizando patrones como el diseño de una sola tabla, claves de clasificación compuestas para acceso jerárquico e GSI para rutas de acceso alternativas. Forzar estas cargas de trabajo en RDS crea contención de bloqueo (escrituras de libros mayores), complejidad de consultas (recorrido de gráficos) o límites de escalado (clave-valor de alto rendimiento) — cada uno mucho más costoso de remediar más tarde que elegir correctamente en el momento del diseño.

Resumen de errores comunes

• Réplicas de lectura como HA. Asíncronas, sin promoción automática, cambios de endpoint en la promoción, transacciones en curso perdidas. Multi-AZ es la respuesta para HA.
• Multi-AZ para escalado de lectura. El standby no es legible en RDS Multi-AZ estándar. Use réplicas de lectura o réplicas de Aurora.
• Producción Single-AZ. Sin objetivo de failover; pierde disponibilidad en cualquier evento de AZ o reinicio de instancia. Multi-AZ tiene aproximadamente el doble de costo para un salto cualitativo en disponibilidad.
• Réplica del mismo tamaño que la principal por defecto. Las réplicas a menudo necesitan mucho menos; ajuste el tamaño a la carga de trabajo medida a menos que la réplica sea un objetivo de promoción.
• DynamoDB bajo demanda siempre más barato. Es aproximadamente 6-7 veces el costo por solicitud; aprovisionado + autoescalado gana para cargas de trabajo estables.
• Tablas globales para necesidades de una sola región. Duplica el costo y debilita la consistencia sin beneficio a menos que se requiera proximidad de usuario multiregión o DR.
• Las secundarias de Aurora Global Database sirven escrituras. Son de solo lectura hasta que una conmutación por error gestionada las promueve.
• Lambda → RDS sin RDS Proxy. La tormenta de conexiones agota max_connections; los pools dentro de la función no ayudan en entornos de ejecución concurrentes.
• DMS solo para migración heterogénea. Mueve datos, no esquemas. Combínelo con SCT.
• Almacenamiento RDS fijo sin autoescalado o alarmas de FreeStorageSpace. Interrupción latente: el estado storage-full rechaza las escrituras.
• Almacenamiento en caché sin estrategia de invalidación. Obsolecencia silenciosa. TTLs, escritura directa o invalidación explícita no son negociables.
• Lecturas fuertemente consistentes a través de DAX o GSIs. Ambos caminos solo sirven datos eventualmente consistentes.

← Entrega de Contenido · Todos los dominios · Análisis →

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

Explorar Amazon →