Amazon SOA-C02: Bases de Datos y Almacenamiento en Caché — Guía de estudio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

Las bases de datos y el almacenamiento en caché son responsabilidades operativas fundamentales para un administrador de SysOps: proporcionan almacenamiento persistente, disponibilidad y lecturas de baja latencia para las aplicaciones. Este dominio abarca la ejecución de bases de datos relacionales gestionadas (RDS y Aurora), el escalado de la capacidad de lectura/escritura, la replicación y el comportamiento de conmutación por error (failover), y el uso de ElastiCache para reducir la carga de la base de datos. La configuración adecuada de copias de seguridad, grupos de parámetros, monitorización y patrones de invalidación de caché previene la pérdida de datos y reduce los incidentes operativos.

Operaciones de RDS y Aurora, copias de seguridad y Multi-AZ

RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server) y Amazon Aurora (compatible con MySQL y PostgreSQL) son motores relacionales gestionados con semánticas operativas diferentes. Multi-AZ para RDS crea una instancia de reserva (standby) síncrona en otra AZ, gestionada por AWS, con conmutación por error (failover) automatizada en minutos, sin promoción manual, y la instancia de reserva no es accesible para lecturas. Aurora separa los puntos de conexión (endpoints) de escritura y de lectura: el de escritura es un punto de conexión de clúster respaldado por una instancia principal, y Aurora utiliza almacenamiento distribuido que se replica automáticamente entre AZs y normalmente puede conmutar por error más rápido que RDS porque el almacenamiento es compartido.

Configure las copias de seguridad y la retención utilizando:

Copias de seguridad automatizadas: habilítelas con un período de retención (p. ej.,

undefined

). Estas proporcionan recuperación a un punto en el tiempo (PITR) a cualquier segundo dentro de la ventana de retención para los motores compatibles.

Instantáneas (snapshots) manuales:

undefined

para Aurora) para capturar una instantánea que se conservará; las instantáneas persisten hasta que las elimine.

Restauración PITR:

undefined

para RDS, o

undefined

y luego crear instancias para Aurora.

Criterios de decisión:

Utilice Multi-AZ para alta disponibilidad y conmutación por error automatizada cuando la disponibilidad de escritura es crítica y no se requieren lecturas en la instancia de reserva.
Utilice Aurora (almacenamiento en clúster) cuando necesite un alto número de IOPS, conmutación por error rápida y autoescalado del almacenamiento.
Utilice réplicas de lectura para el escalado de lecturas y la recuperación ante desastres entre regiones (son asíncronas y pueden ser promovidas).

Ejemplos de CLI operativos:

Habilitar Multi-AZ:

undefined

Crear instantánea manual:

undefined

Restaurar PITR:

undefined

Réplicas de lectura, conmutación por error y estrategias de replicación

Las réplicas de lectura son copias asíncronas (lectores de RDS o Aurora) que se utilizan principalmente para escalar el tráfico de lectura y descargar la carga de los informes. Incurren en un retraso de replicación (monitoree la métrica ReplicaLag) y no son adecuadas para una consistencia fuerte. Las réplicas de lectura pueden promoverse a instancias de base de datos independientes para dar soporte a la recuperación ante desastres.

Estrategias y opciones de replicación:

Síncrona (instancia de reserva Multi-AZ de RDS): garantía de cero deriva de datos, sin capacidad de lectura en la instancia de reserva.
Réplicas de lectura asíncronas: escalan las lecturas, permiten copias entre regiones, con riesgo de retraso en la replicación y posible pérdida de datos en la conmutación por error.
Lectores de Aurora: proporcionan puntos de conexión de lectura en clúster, conmutación por error de baja latencia mediante el redireccionamiento de puntos de conexión y balanceo automático del punto de conexión del lector.

Patrones operativos:

Crear réplica de lectura:

undefined

Promover réplica:

undefined

Monitoree: CloudWatch DatabaseConnections, ReplicaLag, ReadIOPS, WriteIOPS y Performance Insights para decidir cuándo agregar o eliminar réplicas.

Criterios de decisión:

Si necesita alta disponibilidad para escrituras, elija Multi-AZ. Si necesita rendimiento de lectura y descarga de análisis, elija réplicas de lectura o lectores de Aurora.
Para la recuperación ante desastres (DR) entre regiones, cree réplicas de lectura en la región de destino y considere la copia automatizada de instantáneas o DMS para la migración.

Almacenamiento en caché con ElastiCache e invalidación de caché

ElastiCache ofrece Redis y Memcached para reducir la carga y la latencia de la base de datos. Elija Redis cuando necesite persistencia, replicación, estructuras de datos y alta disponibilidad con Multi-AZ y conmutación por error automática. Elija Memcached para un almacenamiento en caché horizontal simple donde la fragmentación (sharding) y el rendimiento multifilamento son prioridades.

Configuraciones y patrones clave:

Crear clúster de Redis con réplicas y Multi-AZ:

undefined

Utilice el modo clúster habilitado para Redis para escalar los fragmentos (shards); Memcached requiere hashing del lado del cliente para la fragmentación.
Políticas de expulsión (eviction): volatile-lru, allkeys-lru, noeviction — ajústelas según si prefiere expulsar solo las claves caducadas o cualquier clave cuando la memoria está llena.
Monitoree CacheHits y CacheMisses para calcular la tasa de aciertos de caché (cache hit ratio): hit_ratio = CacheHits / (CacheHits + CacheMisses). Apunte a una tasa de aciertos alta para reducir las lecturas de la base de datos.

Estrategias de invalidación de caché:

Cache-aside: la aplicación comprueba primero la caché; si hay un fallo (miss), lee la base de datos y puebla la caché; expire o elimine explícitamente la caché en las escrituras.
Write-through/write-behind: las escrituras en la caché se propagan a la base de datos; write-behind agrupa las escrituras a la base de datos en lotes (agrega complejidad).
Tiempo de vida (TTL): establezca TTLs conservadores para datos que pueden volverse obsoletos; combine con versionado de caché o claves de invalidación para cambios de esquema o invalidación masiva.
Utilice Redis pub/sub o eventos de Lambda para notificar a las instancias de la aplicación para una invalidación distribuida cuando sea necesario.

Grupos de parámetros de base de datos, escalado y monitoreo

Los grupos de parámetros controlan configuraciones específicas del motor (p. ej., max_connections, innodb_buffer_pool_size). RDS utiliza grupos de parámetros de BD para instancias y grupos de parámetros de clúster de BD para Aurora. Los cambios en algunos parámetros requieren un reinicio (se aplican tras un reinicio pendiente, apply pending-reboot), mientras que otros se aplican de inmediato.

Patrones de gestión:

Crear y modificar un grupo de parámetros: aws rds create-db-parameter-group –db-parameter-group-name pg1 –db-parameter-group-family mysql8.0 –description “custom”; luego aws rds modify-db-parameter-group –db-parameter-group-name pg1 –parameters “ParameterName=max_connections,ParameterValue=500,ApplyMethod=immediate”
Escalar la clase de instancia: aws rds modify-db-instance –db-instance-identifier mydb –db-instance-class db.r5.large –apply-immediately (o durante la ventana de mantenimiento para evitar un reinicio).
Autoescalado de almacenamiento: habilitar para los tipos de motor compatibles; Aurora autoescala el almacenamiento automáticamente.

Señales de monitoreo y escalado:

Use CloudWatch (FreeableMemory, CPUUtilization, DatabaseConnections, WriteLatency, ReadLatency, DiskQueueDepth) y Performance Insights para SQL lento y las principales esperas (top waits).
Habilite Enhanced Monitoring y establezca la granularidad (p. ej., 1s para la resolución de problemas).
Use RDS Proxy para gestionar la agrupación de conexiones (connection pooling) y reducir las tormentas de conexiones para aplicaciones sin servidor o con alta concurrencia.

Procedimientos de copia de seguridad/restauración y consideraciones de migración

Las copias de seguridad y las restauraciones deben ser explícitas y probadas. Las copias de seguridad automatizadas proporcionan recuperación a un punto en el tiempo (PITR) dentro del período de retención; las instantáneas manuales se conservan hasta que se eliminan y se pueden copiar entre regiones y a diferentes claves KMS. Sea explícito sobre la región y la marca de tiempo al restaurar.

Comandos comunes de restauración:

Restaurar a un punto en el tiempo (RDS): aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –use-latest-restorable-time / o especifique –restore-time
Restaurar instantánea (entre regiones): primero copie la instantánea con copy-db-snapshot a la región de destino y luego restáurela.

Consideraciones de migración:

AWS DMS para migraciones con tiempo de inactividad mínimo (heterogéneas/homogéneas). DMS admite la replicación continua; asegúrese de que la configuración del motor de origen sea correcta (binlog habilitado para MySQL).
Migración lógica (mysqldump, pg_dump) para exportaciones simples; restauración de instantánea física para conjuntos de datos grandes.
Valide los juegos de caracteres, las diferencias en los grupos de parámetros y las claves KMS para las instantáneas cifradas.

Errores Comunes y Criterios de Decisión

Restaurar copias de seguridad en la región o el momento incorrectos: siempre verifique –region y –restore-time antes de restaurar; use la instantánea copiada en la región de destino y pruebe las restauraciones en un entorno de preproducción (staging).
Asumir que las réplicas de lectura proporcionan alta disponibilidad: recuerde que las réplicas son asíncronas; use Multi-AZ o Aurora para alta disponibilidad de escritura (write HA) y replicación síncrona.
Pasar por alto la invalidación de la caché: diseñe TTL, claves versionadas o invalidación basada en eventos; evite depender únicamente de TTL cortos para la correctitud de los datos.
No habilitar correctamente las copias de seguridad automatizadas o la retención: establezca backup-retention-period >0 y valide la recuperación a un punto en el tiempo (PITR) con restauraciones de prueba; asegúrese de que las claves KMS estén disponibles en la región de destino para la copia de la instantánea.
Modificar grupos de parámetros sin reiniciar: verifique el ApplyMethod; programe los reinicios en las ventanas de mantenimiento para los parámetros que lo requieran para evitar tiempos de inactividad inesperados.
Escalar sin gestión de conexiones: aumentar la clase de instancia sin usar RDS Proxy o agrupación de conexiones puede que no resuelva las tormentas de conexiones; implemente la agrupación (pooling) para gestionar muchas conexiones de corta duración.

Problema Práctico: Escenario de Caso de Uso

Acme Retail opera una instancia principal de MySQL en RDS con un tráfico de lectura intenso y picos ocasionales de análisis; se enfrentan a un retraso en la réplica (replica lag) durante el ETL nocturno y observan una alta rotación de conexiones (connection churn) que causa picos de CPU.

Habilitar un grupo adicional de réplicas de lectura para análisis, aislado de los lectores de la aplicación, y ubicarlo en una AZ o región diferente para recuperación ante desastres (DR).
Configurar el monitoreo de réplicas (métrica ReplicaLag) y agregar lógica de autoescalado para añadir lectores cuando el retraso o la métrica ReadLatency excedan los umbrales.
Desplegar RDS Proxy frente a la aplicación para multiplexar conexiones y reducir la rotación de conexiones; ajustar max_connections en el grupo de parámetros de manera apropiada.
Mover los trabajos de análisis para que usen la réplica de análisis y adoptar un patrón de caché cache-aside a través de ElastiCache Redis con TTL apropiados para reducir las consultas repetidas.
Probar los procedimientos de conmutación por error (failover) y restauración: realizar una restauración PITR en una instancia de preproducción (staging) y validar los pasos de promoción de la réplica.

Este enfoque separa las cargas de trabajo de lectura, reduce la presión de las conexiones en la instancia principal y utiliza el almacenamiento en caché para disminuir el volumen de lectura de la base de datos. Sigue las mejores prácticas de AWS al combinar el escalado de lectura, la agrupación de conexiones y procesos probados de copia de seguridad/restauración para mantener la disponibilidad y la resiliencia operativa.

← Cómputo y Auto Scaling · Todos los dominios · Serverless e Integración de Aplicaciones →

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