Amazon SAA-C03: Bases de datos y almacenamiento en caché — Guía de estudio

By Laurynas Brazys · 16 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 gestionados

Amazon RDS ofrece seis motores gestionados —MySQL, PostgreSQL, MariaDB, Oracle, SQL Server y Amazon Aurora (compatible con MySQL y PostgreSQL)— que abstraen la aplicación de parches, las copias de seguridad, la topología de replicación y la conmutación por error (failover). La elección del motor determina las licencias, la semántica de las copias de seguridad y la disponibilidad de características: Oracle y SQL Server tienen distinciones entre BYOL y Licencia Incluida, SQL Server admite hasta cinco réplicas de lectura mediante 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 más frecuencia— son los despliegues Multi-AZ y las réplicas de lectura (read replicas). Son ortogonales, complementarias y no intercambiables.

Multi-AZ aprovisiona una réplica en espera (standby) síncrona en una segunda Zona de Disponibilidad. Cada escritura se confirma tanto en la principal como en la de espera antes de ser reconocida, lo que da un RPO efectivamente de cero y un RTO 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 principal falla, una AZ se ve afectada 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 fallo en una sola AZ: es un simple ajuste de configuración, no requiere cambios en el esquema ni en la aplicación, y conserva el endpoint. El más reciente despliegue de clúster Multi-AZ es una topología de tres nodos (un escritor, dos réplicas de lectura en espera) que utiliza replicación semisíncrona con una latencia de confirmación de aproximadamente un segundo, proporcionando alta disponibilidad (HA) 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 de WAL de PostgreSQL). Son la herramienta correcta para escalar la lectura —consultas analíticas, paneles de informes, SELECTs ad-hoc— que de otro modo consumirían los recursos de OLTP en la principal. El escenario canónico: una base de datos de procesamiento de pedidos que sufre timeouts porque los empleados ejecutan largos informes 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 necesidad de aumentar el tamaño de la principal. Las réplicas de lectura pueden ser entre regiones (cross-region) y pueden promoverse manualmente a bases de datos independientes, pero la promoción nunca es automática y cualquier transacción que aún no se haya replicado en el momento del fallo se pierde.

Dos trampas son recurrentes en este ámbito. Primero, tratar las réplicas de lectura como una solución de alta disponibilidad (HA) 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 se desvanecen. Si un diseño promete “cero pérdida de datos” y apunta a una réplica de lectura como el objetivo de conmutación por error, esa promesa es falsa. Segundo, aprovisionar Multi-AZ para servir tráfico de lectura es un desperdicio de 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 quieren ambas.

Las réplicas de lectura tampoco sirven para escalar la escritura; cada escritura todavía llega a la principal y las réplicas deben reproducirla. Para escalar la escritura, se debe usar sharding, migrar a Aurora (almacenamiento desacoplado) o rediseñar hacia DynamoDB.

Dimensionamiento correcto de las réplicas de lectura

Una réplica no tiene que coincidir con la clase de instancia de la principal. La principal maneja la carga completa de escritura más las lecturas; una réplica maneja solo las lecturas que le llegan. Una principal db.r6i.4xlarge emparejada con una réplica db.r6i.large para un trabajo de informes nocturno es totalmente razonable, siempre que la réplica pueda mantenerse al día con la E/S de replicación. La metodología es: medir la CPU, la memoria y el retraso de la réplica (replica lag) reales, 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 principal durante una recuperación de desastres (DR), debe estar dimensionada para soportar la carga de escritura. Las réplicas subdimensionadas no son objetivos de promoción.

Despliegues Blue/Green y almacenamiento

Los despliegues Blue/Green de RDS crean una copia de staging completa de la producción (el entorno verde) que se mantiene sincronizada mediante replicación lógica. Se puede actualizar la versión del motor, cambiar los grupos de parámetros o alterar los esquemas en el entorno verde, probarlo y realizar el cambio en menos de un minuto con el renombramiento automático del endpoint. Esto elimina el riesgo clásico de una actualización in-place, donde una actualización de versión mayor fallida obliga a una restauración desde un snapshot.

La selección del almacenamiento es tan importante como la clase de instancia para cargas de trabajo OLTP intensivas en escritura. La taxonomía de gp3/io2:

La mejora de gp3 sobre gp2 es el desacoplamiento de los IOPS del tamaño; ya no es necesario sobreaprovisionar capacidad para obtener rendimiento. Elija io2 cuando los IOPS sostenidos superen el límite de gp3 o cuando se requiera una durabilidad del 99.999%. Multi-Attach permite que un único volumen io2 se conecte a hasta 16 instancias Nitro, pero el sistema de archivos o la aplicación deben ser compatibles con clústeres; no es un sustituto de la replicación. Una trampa de interrupción latente: aprovisionar almacenamiento fijo sin tener habilitado el autoescalado de almacenamiento o una alarma de CloudWatch en FreeStorageSpace. Cuando el espacio libre llega a cero, RDS entra en el estado storage-full y rechaza las escrituras.

Amazon Aurora: Arquitectura y puntos de conexión

Aurora reimplementa la capa de almacenamiento subyacente a MySQL y PostgreSQL como un volumen distribuido, estructurado en logs y replicado seis veces que se extiende por tres AZs. Los nodos de cómputo no tienen estado en relación con el almacenamiento, por lo que una réplica de Aurora lee del mismo volumen subyacente que la instancia de escritura en lugar de reproducir un log. El retardo de replicación (replication lag) es típicamente de 10 a 20 ms, en comparación con los segundos de las réplicas estándar de RDS, y un clúster admite hasta 15 réplicas que pueden ser promovidas a instancia de escritura en unos 30 segundos.

Aurora expone cuatro tipos de puntos de conexión:

Los puntos de conexión 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 atiende lecturas OLTP, el punto de conexión de lectura general ocasionalmente dirige los informes a nodos más pequeños, afectando la predictibilidad. Un punto de conexión personalizado limitado solo a las réplicas grandes proporciona un aislamiento de cargas 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

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

Aurora Auto Scaling añade y elimina lectores basándose en métricas objetivo de CPU o de conexiones, lo que es la respuesta canónica para cargas de trabajo impredecibles y con uso intensivo de lectura 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 un retardo de replicación por debajo de un segundo en momentos de máxima carga, 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 retardo.

Aurora Serverless v2 y Clonación

Aurora Serverless v2 escala el cómputo verticalmente en unidades de capacidad de Aurora (ACU, 2 GiB de memoria cada una) de forma granular en aproximadamente medio segundo, sin desconectar las sesiones. Es adecuado para cargas de trabajo variables con un consumo de memoria base conocido; por ejemplo, una migración de un MySQL on-premise que siempre consume al menos 2 GiB. Establece un mínimo de 1 ACU y un máximo de 32 ACU, y el clúster se ajustará sin necesidad de administración. Aurora Provisioned sigue siendo preferible cuando la carga es estable y predecible, ya que Serverless v2 conlleva un sobrecoste por ACU.

La clonación de Aurora crea un nuevo clúster que comparte las páginas de almacenamiento del origen 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 intensivamente sobre una copia de producción. La restauración de un snapshot rehidrata físicamente los datos y puede tardar horas; la clonación es la mejor opción cuando la velocidad es importante.

Aurora Global Database

Aurora Global Database extiende un clúster hasta a cinco regiones secundarias utilizando una infraestructura de replicación dedicada a nivel de almacenamiento, no el envío de binlogs. El retardo de replicación típico es inferior a un segundo, el RPO es inferior a un segundo y el failover gestionado promueve una región 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ñado para DR con bajo RPO y lecturas remotas de baja latencia, no para un esquema activo-activo multi-maestro. Asumir que una Global DB “gestiona automáticamente las escrituras en la región secundaria” es incorrecto; las escrituras allí requieren un failover gestionado explícito o un proceso de desvinculación y promoción (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 serverless y altamente concurrentes agravan un problema clásico: las tormentas de conexiones (connection storms). Una función Lambda que escala a 3000 ejecuciones concurrentes abre 3000 sockets, superando el límite de max_connections y causando fallos en cascada, precisamente cuando el sistema está bajo carga. Los pools de conexiones 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 activas (warm pool) y multiplexando las sesiones de los clientes sobre ellas. Resuelve dos problemas:

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

Se integra con IAM y Secrets Manager para la gestión de credenciales, eliminando los secretos codificados (hard-coded) 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 punto de conexión del proxy, no al punto de conexión del clúster. Cualquier arquitectura Lambda-a-RDS o con un alto grado de distribución (high-fan-out) debería usar RDS Proxy a menos que haya una razón específica para no hacerlo. Ejecutar tu propio gestor de pools (PgBouncer, ProxySQL) en EC2 es posible, pero añade la sobrecarga operativa que el proxy precisamente busca eliminar.

DynamoDB: Modos de capacidad

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

El modo bajo demanda es drásticamente más simple, pero cuesta aproximadamente de 6 a 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 resulta en un sobrepago significativo; la capacidad aprovisionada con escalado programado o la capacidad reservada es mucho más económica. Por el contrario, usar la capacidad aprovisionada para una carga de trabajo impredecible de un lanzamiento público conduce al throttling. Para cargas de trabajo estables con una variación moderada, la capacidad aprovisionada con autoescalado de seguimiento de objetivo en torno al 70 % de utilización es significativamente más barata que el modo 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 modo aprovisionado es siempre el adecuado para el tráfico con picos.

DynamoDB: Consistencia, Streams y Global Tables

Las lecturas son por defecto de consistencia final (eventually consistent) (pueden devolver datos obsoletos en un lapso de ~1 segundo, cuestan 0.5 RCU). Establecer ConsistentRead=true devuelve el último valor confirmado (committed) al doble del costo. Las lecturas de consistencia alta (strongly consistent) no son compatibles con los índices secundarios globales ni a través de DAX; esas vías siempre devuelven datos con consistencia final.

DynamoDB Streams captura los cambios a nivel de ítem como un registro ordenado que se retiene durante 24 horas, activando Lambda para el procesamiento posterior (downstream), como la indexación para búsquedas, notificaciones o la desnormalización entre tablas, sin necesidad de sondeo (polling).

Global Tables se basan en Streams para proporcionar una replicación multiactiva y multirregional con resolución de conflictos del tipo last-writer-wins (el último en escribir gana). Son la respuesta correcta cuando las lecturas y escrituras deben ser locales en múltiples Regiones. Pero aproximadamente duplican los costos de almacenamiento y escritura (cada escritura es una WCU en cada Región de réplica) y debilitan la consistencia entre Regiones. La trampa es habilitar Global Tables cuando una sola Región satisface los requisitos de disponibilidad: DynamoDB en una sola Región ya está replicado en tres AZ con una disponibilidad del 99.99 %. Una alta disponibilidad (HA) rentable en una sola Región se logra con una tabla en una única Región con PITR habilitado y, si se desea, capacidad aprovisionada con autoescalado.

Point-in-Time Recovery (PITR) proporciona copias de seguridad continuas con una granularidad de restauración por segundo para los últimos 35 días con una sobrecarga insignificante. Habilítalo en cualquier tabla de producción: satisface los requisitos de RPO típicos de minutos en lugar de horas. Para una retención más prolongada (por retenciones regulatorias), integra AWS Backup para copias de seguridad programadas, gestionadas por ciclo de vida y que se pueden copiar entre regiones.

TTL te permite especificar un atributo que contiene una fecha de expiración en formato de época Unix; DynamoDB elimina de forma asíncrona los ítems caducados sin costo, lo que es ideal para almacenes de sesiones, tokens efímeros o cachés de eventos. Las eliminaciones por TTL fluyen a través de Streams para su archivo posterior:

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

Para análisis, la exportación a S3 produce una instantánea (snapshot) en un momento dado que puede ser leída por Athena, Redshift Spectrum o EMR sin consumir la capacidad de la tabla, un patrón mucho mejor que escanear la tabla.

DAX: DynamoDB Accelerator

DAX es una caché en memoria, totalmente administrada y de escritura directa (write-through) específica para DynamoDB, que ofrece una latencia de lectura de microsegundos en comparación con la base de milisegundos de un solo dígito de DynamoDB. Su característica distintiva es la compatibilidad con la API: el cliente de DAX es un reemplazo directo (drop-in replacement) del cliente del SDK de DynamoDB, por lo que las aplicaciones lo adoptan cambiando la configuración del endpoint en lugar de reescribir la lógica de las consultas:

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 tipo write-through: DAX actúa como proxy para DynamoDB y actualiza su caché de ítems si la operación tiene éxito. Sin embargo, la caché de consultas depende del TTL, por lo que los resultados de las consultas pueden volverse obsoletos incluso para ítems recién escritos.

Hay dos restricciones importantes. Primero, DAX solo acelera las lecturas de consistencia final; las lecturas de consistencia alta omiten la caché. Segundo, otros escritores que omiten DAX causan obsolescencia de los datos (staleness). Para una página de detalles de producto que recibe millones de visitas diarias, DAX es el acelerador con la menor sobrecarga operativa: no requiere código de invalidación de caché ni una gestión de clúster separada. ElastiCache delante de DynamoDB funcionaría, pero requiere una lógica de cache-aside que DAX hace innecesaria.

ElastiCache: Redis y Memcached

ElastiCache ofrece acceso a datos en memoria por debajo del milisegundo 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 puro y multihilo con particionamiento horizontal (sharding), sin persistencia, sin replicación, sin pub/sub. Úsalo solo para almacenamiento en caché efímero donde la pérdida de toda la caché es aceptable.
• Redis — soporta replicación, Multi-AZ con conmutación por error (failover) automática, modo clúster para particionamiento (sharding), persistencia, pub/sub, conjuntos ordenados (sorted sets), transacciones y cifrado en tránsito y en reposo. Requerido para cualquier cosa duradera o que necesite tipos de datos complejos.

Dos patrones canónicos predominan.

Almacén de sesiones centralizado. Cuando un ALB distribuye el tráfico entre instancias EC2 o ECS sin estado, el almacenamiento de sesiones local obliga a usar sesiones persistentes (sticky sessions), lo que desequilibra la carga y falla durante el escalado hacia adentro (scale-in), los despliegues y las caídas de AZ. Externalizar las sesiones a Redis permite que cualquier instancia atienda cualquier solicitud, y las sesiones sobreviven a las caídas 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 mediante ZADD/ZREVRANGE), búsquedas de catálogos, agregaciones. Las estrategias de caché deben coincidir con las necesidades de consistencia:

• Lazy loading (cache-aside): la aplicación lee de la caché; en caso de fallo (miss), lee de la BD y puebla la caché con un TTL. Simple, pero los fallos en frío (cold misses) perjudican y los datos pueden quedar obsoletos.
• Write-through: la aplicación escribe en la caché y en la BD en la misma operación. La caché se mantiene actualizada, 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é y se vuelcan asíncronamente a la BD. Las escrituras más rápidas, pero un fallo de la caché provoca la pérdida de 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))

Depender de cualquier capa de caché sin una estrategia de invalidación —TTL, un DEL explícito en la actualización o write-through— produce lecturas de datos obsoletos. 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 barata de escalar las lecturas más allá de lo que las réplicas de lectura (read replicas) soportan cómodamente y protege a la principal durante los picos de tráfico.

A diferencia de DAX, ElastiCache es agnóstico al motor —tú eres el dueño de la lógica de invalidación—, razón por la cual 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-premise→DynamoDB). Una tarea de DMS tiene tres fases:

1. Carga completa (Full load) — copia masiva de las filas existentes.
2. CDC (change data capture) — sigue el registro de transacciones del origen y aplica los cambios en curso.
3. Carga completa + CDC — el patrón común de tiempo de inactividad mínimo: el origen permanece en línea, DMS mantiene el destino sincronizado, y el cambio (cutover) 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 gestionar instancias de replicación — la capacidad se autoprovisiona según la carga de trabajo, lo que es adecuado para CDC variable o de larga duración. Los motores de origen deben tener habilitado el registro suplementario (supplemental logging) (Oracle) o el registro binario en formato ROW (MySQL). Para cargas iniciales (seeds) muy grandes, DMS se integra con Snowball Edge para cargas sin conexión.

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

El patrón completo para migraciones 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 punto en el tiempo (PITR)

Las copias de seguridad automatizadas de RDS combinan snapshots diarios con copias de los registros de transacciones cada 5 minutos, permitiendo la recuperación a un punto en el tiempo (PITR) a cualquier segundo dentro de la ventana de retención (de 1 a 35 días, por defecto 7). La restauración crea una nueva instancia —no se puede restaurar sobre la existente—, por lo que los puntos de conexión (endpoints) de la aplicación o los CNAMEs deben actualizarse. Los snapshots manuales persisten más allá de la retención y sobreviven a la eliminación de la instancia (sujeto a la configuración del snapshot final), pueden copiarse entre regiones para recuperación ante desastres (DR) y compartirse entre cuentas.

Fast Snapshot Restore (FSR) para snapshots respaldados por EBS elimina la penalización de la carga diferida (lazy-load), dando a los volúmenes restaurados un rendimiento completo de inmediato — útil al levantar múltiples entornos desde un único snapshot bajo presión de tiempo. La clonación de Aurora omite por completo los snapshots

Resumen de Errores Comunes

• Réplicas de lectura como alta disponibilidad (HA). Replicación asíncrona, sin promoción automática, el endpoint cambia en la promoción, se pierden las transacciones en curso. Multi-AZ es la respuesta para HA.
• Multi-AZ para escalado de lectura. La instancia en espera (standby) no es legible en una configuración Multi-AZ estándar de RDS. Usa réplicas de lectura o réplicas de Aurora.
• Producción en una sola AZ (Single-AZ). Sin un objetivo de conmutación por error (failover); se pierde la disponibilidad ante cualquier evento de AZ o reinicio de la instancia. Multi-AZ tiene un costo aproximado del doble por un salto cualitativo en la disponibilidad.
• Réplica con el mismo tamaño que la principal por defecto. Las réplicas a menudo necesitan mucho menos; dimensiona según la carga de trabajo medida, a menos que la réplica sea un objetivo de promoción.
• DynamoDB bajo demanda (On-demand) siempre es más barato. Tiene un costo por solicitud de 6 a 7 veces mayor; la capacidad aprovisionada + auto-scaling es mejor para cargas de trabajo estables.
• Global Tables para necesidades de una sola región. Duplica el costo y debilita la consistencia sin ningún beneficio, a menos que se requiera proximidad al usuario en múltiples regiones o recuperación ante desastres (DR).
• Las bases de datos secundarias de Aurora Global Database atienden escrituras. Son de solo lectura hasta que una conmutación por error (failover) gestionada las promueve.
• Lambda → RDS sin RDS Proxy. Una tormenta de conexiones agota max_connections; los pools de conexiones dentro de la función no ayudan entre entornos de ejecución concurrentes.
• DMS por sí solo para una migración heterogénea. Mueve los datos, no el esquema. Combínalo con SCT.
• Almacenamiento fijo en RDS sin autoescalado o alarmas de FreeStorageSpace. Interrupción latente: el estado storage-full rechaza las escrituras.
• Caching sin una estrategia de invalidación. Datos obsoletos de forma silenciosa. Los TTL, la escritura directa (write-through) o la invalidación explícita no son negociables.
• Lecturas de consistencia alta (strongly consistent) a través de DAX o GSI. Ambas rutas solo ofrecen datos con consistencia eventual.

← Entrega de contenido · Todos los dominios · Analítica →

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

Explorar Amazon →