Amazon DOP-C02: Almacenamiento, Bases de Datos y Gestión de Datos — Guía de estudio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Resumen general

El almacenamiento, las bases de datos y el movimiento de datos en AWS deben diseñarse para la durabilidad, la disponibilidad, la rentabilidad y la automatización. Dominar las clases de almacenamiento y la replicación de S3, la capacidad y distribución global de DynamoDB, los controles de configuración y los patrones de copia de seguridad de RDS/Aurora, el almacenamiento en caché en memoria, los sistemas de archivos compartidos y los servicios de migración de datos permite crear sistemas fiables y de baja latencia con un comportamiento de recuperación predecible y un gasto controlado.

Amazon S3: clases de almacenamiento, ciclo de vida, organización en niveles inteligente y replicación

Las clases de almacenamiento de S3 alinean el costo con los patrones de acceso:

Standard: multi-AZ, baja latencia, sin tarifas de recuperación. Predeterminada para datos de acceso frecuente (hot data).
Intelligent-Tiering (S3 INT): multi-AZ con organización automática en niveles entre los niveles de acceso frecuente e infrecuente y niveles de archivo opcionales. Se cobra un cargo por monitoreo y automatización por objeto; los objetos de menos de 128 KB no se organizan automáticamente en niveles. Los niveles Archive Access y Deep Archive Access son opcionales (opt-in) con umbrales de último acceso; se aplican tarifas de recuperación desde los niveles de acceso no frecuente.
Standard-IA y One Zone-IA: menor costo de almacenamiento con tarifas de recuperación; cargo mínimo de almacenamiento de 30 días. One Zone-IA es de una sola AZ para datos que se pueden recrear.
Glacier Instant Retrieval: acceso en milisegundos con costos de archivado; mínimo de 90 días.
Glacier Flexible Retrieval: recuperación en minutos u horas, con opciones bulk/standard/expedited; mínimo de 90 días.
Glacier Deep Archive: recuperación en horas o hasta 12 horas; mínimo de 180 días. Elija el nivel viable más frío (coldest) considerando los cargos por duración mínima de almacenamiento, las tarifas de recuperación y los tiempos de acceso requeridos.

Las políticas de ciclo de vida (Lifecycle policies) automatizan las transiciones y expiraciones usando filtros (prefijo, etiquetas) para un control detallado. Las acciones clave incluyen la transición a los niveles IA/Glacier después de umbrales de inactividad, la transición/expiración de versiones no actuales en buckets con versionamiento, la expiración de marcadores de eliminación (delete markers) y la anulación de cargas multiparte incompletas. El ciclo de vida y el etiquetado de objetos son cruciales para hacer cumplir la retención de datos y la eliminación defendible junto con S3 Object Lock (modos de gobernanza/cumplimiento) cuando se requiere inmutabilidad.

Intelligent-Tiering es ideal cuando los patrones de acceso son desconocidos o variables. Conserva el rendimiento (sin demoras en la recuperación desde los niveles de acceso frecuente/IA), elimina la necesidad de rediseñar la arquitectura cuando los patrones cambian y, opcionalmente, puede archivar automáticamente en niveles profundos basándose en el último acceso, proporcionando la mejor combinación de agilidad y control de costos para conjuntos de datos de larga duración con acceso esporádico.

La replicación de S3 proporciona una copia duradera y asíncrona de los objetos:

Requisitos: el versionamiento debe estar habilitado en el origen y el destino. La configuración de replicación define el bucket/cuenta/región de destino, el filtro por prefijo/etiquetas, la replicación de metadatos (ACL, etiquetas, S3 Object Lock), la clase de almacenamiento y si se deben replicar los marcadores de eliminación y los objetos existentes.
Same-Region Replication (SRR): cumplimiento/soberanía de datos, agregación de registros, procesamiento atómico entre cuentas.
Cross-Region Replication (CRR): recuperación ante desastres (DR), reducción de latencia, distribución global, cumplimiento.
Objetos cifrados con KMS: se debe permitir que el rol de replicación descifre con la clave KMS de origen y cifre con la clave KMS de destino. Especifique la clave KMS de la réplica en la regla de replicación

undefined

. Para la replicación entre cuentas, actualice la política del bucket de destino para permitir que el rol de replicación escriba.

Objetos existentes: use S3 Batch Replication para rellenar los datos históricos (backfill).
Replication Time Control (RTC): añade un SLA de 15 minutos para la finalización de la replicación, con métricas y notificaciones para monitorear los SLA. Es útil para el cumplimiento y RPO estrictos.
Propiedad y acceso: al cruzar cuentas, habilite la opción de propietario del bucket preferido (bucket owner preferred) o la propiedad del objeto forzada al propietario del bucket (Object Ownership bucket owner enforced) para evitar la complejidad de las ACL y garantizar que la cuenta de destino sea la propietaria de las réplicas.

Bases de datos en AWS: DynamoDB, RDS y Aurora

Modos de capacidad y escalado de DynamoDB:

Bajo demanda: sin planificación de capacidad; precios por solicitud; ideal para cargas de trabajo impredecibles o con picos y para tablas nuevas sin tráfico conocido.
Aprovisionado: establezca RCUs/WCUs con DynamoDB Application Auto Scaling sobre una utilización objetivo; apropiado para tráfico estable o predecible y para el control de costos.
Capacidad adaptativa: redistribuye automáticamente el rendimiento de las particiones a las claves calientes (hot keys), pero las particiones extremadamente calientes aún necesitan nivelación de carga (p. ej., fragmentación de escritura o write sharding). Los GSI tienen capacidad separada; modele cuidadosamente para evitar la limitación (throttling).
El tamaño del elemento afecta la capacidad: 1 WCU por cada 1 KB de escritura; 1 RCU por cada 4 KB de lectura de consistencia alta (strongly consistent) u 8 KB de lectura de consistencia final (eventually consistent).

Streams y DAX de DynamoDB:

Streams capturan mutaciones a nivel de elemento con una retención de 24 horas. Elija los tipos de vista para incluir imágenes NUEVAS/ANTIGUAS (NEW/OLD). Los patrones comunes incluyen: disparadores de Lambda para escrituras CQRS/dirigidas por eventos, sincronización entre tablas y pistas de auditoría. El orden es por clave de partición y la entrega es al menos una vez (at-least-once).
DAX es una caché en memoria, administrada y compatible con la API para DynamoDB que reduce drásticamente la latencia de lectura. Soporta lecturas de consistencia final; las lecturas de consistencia alta deben omitir DAX. Ofrece escritura directa (write-through) para mutaciones de elementos e invalidación basada en TTL. Use clústeres Multi-AZ para alta disponibilidad y ubique las subredes de DAX cerca de los clientes.

Tablas globales de DynamoDB:

Replicación multirregional y multimaestro usando streams con resolución de conflictos del tipo “el último escritor gana” (last-writer-wins) basada en una marca de tiempo del sistema. Diseñe para evitar actualizaciones concurrentes de los mismos atributos entre Regiones o implemente la reconciliación del lado de la aplicación.
El atributo TTL se replica como datos de elemento normales; las eliminaciones impulsadas por TTL se procesan por Región y no se replican como eliminaciones explícitas.
Las copias de seguridad y PITR tienen alcance regional; restaure a tablas nuevas por Región y (opcionalmente) vuelva a crear como una nueva tabla global.

Configuración y copias de seguridad de Amazon RDS:

Los grupos de parámetros definen los parámetros del motor. Los parámetros estáticos requieren reinicio; los parámetros dinámicos se aplican inmediatamente donde se soporte. Use grupos de parámetros de BD para motores a nivel de instancia y grupos de parámetros de clúster para Aurora.
Los grupos de opciones habilitan características nativas del motor (p. ej., Oracle TDE/OEM, copia de seguridad/restauración nativa de SQL Server, plugins de MySQL/MariaDB). Las opciones pueden requerir reinicios del motor; gestione las ventanas de cambio con cuidado.
Las copias de seguridad automatizadas habilitan PITR dentro de una ventana de retención (hasta 35 días). Capturan instantáneas diarias y registros de transacciones en S3; las restauraciones producen nuevas instancias.
Las instantáneas manuales se conservan hasta que se eliminan, se pueden copiar entre Regiones y se pueden compartir entre cuentas (respetando los permisos de la clave KMS para instantáneas cifradas). Use la copia de instantáneas entre Regiones como base para la recuperación ante desastres (DR).

Especificidades de Amazon Aurora:

Puntos de conexión (Endpoints): el punto de conexión del clúster (escritor) siempre apunta a la instancia principal para las escrituras. El punto de conexión de lectura balancea la carga entre las réplicas. Los puntos de conexión personalizados pueden seleccionar un subconjunto de lectores para grupos de lectura por niveles o cargas de trabajo especializadas. Dirija siempre las escrituras al punto de conexión de escritor y las lecturas al de lector o al punto de conexión personalizado apropiado para interrupciones mínimas durante las conmutaciones por error (failovers).
Serverless v2: escalado instantáneo y de grano fino de ACUs sin reinicio. Se ejecuta dentro de un clúster de Aurora, soporta instancias mixtas, serverless y aprovisionadas, y es muy adecuado para cargas de trabajo con picos, desarrollo/pruebas o aplicaciones multi-tenant con demanda irregular. Conserva la consistencia de la conexión mejor que la v1 debido al escalado continuo.
Clonación: clones rápidos de tipo “copia en escritura” (copy-on-write) dentro de una Región para desarrollo/pruebas, ciencia de datos o validación de cambios azul/verde. Los clones son eficientes en espacio y divergen solo en las páginas modificadas. Puede encadenar clones; elimine cuando termine para recuperar el almacenamiento.

Caché y sistemas de archivos compartidos: ElastiCache y EFS

ElastiCache for Redis vs Memcached:

Redis: estructuras de datos avanzadas, replicación, Pub/Sub, Lua, streams, geoespacial, conjuntos ordenados (sorted sets) y persistencia mediante instantáneas; soporta conmutación por error automática Multi-AZ y Redis Global Datastore para réplicas de lectura entre Regiones. Elija Redis cuando necesite tipos de datos enriquecidos, durabilidad (restauración de instantáneas) o alta disponibilidad con conmutación por error.
Memcached: simple, multihilo, sin replicación ni persistencia; escalado horizontal mediante fragmentación del lado del cliente; sin estado y fácil de escalar horizontalmente. Elija Memcached para caché puro y efímero con un rendimiento muy alto y cuando desee controlar la fragmentación en el cliente. Modo clúster y grupos de replicación de Redis:
Modo clúster deshabilitado: un fragmento (shard) con una instancia principal y réplicas; escalado vertical o escalado horizontal limitado mediante réplicas de lectura.
Modo clúster habilitado: fragmentación por hash-slot entre múltiples fragmentos principales, cada uno con réplicas, permitiendo un escalado horizontal casi lineal. Los grupos de replicación definen la topología primario/réplica y la conmutación por error Multi-AZ. Las copias de seguridad son por grupo de replicación; pruebe la conmutación por error para validar el RTO.

Amazon EFS para archivos POSIX compartidos:

Destinos de montaje (Mount targets): cree uno en cada AZ de la VPC para garantizar rutas de acceso y disponibilidad dentro de la AZ. Los grupos de seguridad en los destinos de montaje controlan el tráfico NFS; use el asistente de montaje de EFS para TLS en tránsito y autorización de IAM si es necesario.
Puntos de acceso: imponen un directorio raíz y una identidad POSIX (UID/GID) para las aplicaciones, permitiendo el aislamiento multi-tenant y un montaje simple con privilegios mínimos por parte de ECS/EKS/EC2 sin coordinar la gestión de usuarios del sistema operativo.
Gestión del ciclo de vida y clases de almacenamiento: EFS Standard y Standard-IA (Regional, multi-AZ) y One Zone/One Zone-IA (una sola AZ). El almacenamiento por niveles inteligente (Intelligent tiering) mueve automáticamente los archivos entre las clases estándar e IA según el último tiempo de acceso; también puede establecer políticas de transición explícitas. Elija las variantes One Zone para datos recreables o no críticos para ahorrar costos. Combine con AWS Backup para políticas centralizadas y copias de seguridad entre cuentas/Regiones.

Migración de datos: DMS, Snowball y DataSync

AWS Database Migration Service (DMS): migración en línea con un tiempo de inactividad mínimo mediante una carga completa más captura de datos de cambios (CDC). Admite migraciones homogéneas y heterogéneas a través de la conversión de esquemas integrada (con AWS Schema Conversion Tool para conversiones complejas). Úsalo para hacer un lift-and-shift a RDS/Aurora, a DynamoDB (mediante mapeo JSON) o para replicación continua para descargar lecturas o para transiciones por fases. Dimensiona las instancias de replicación para las tasas de cambio máximas; asegúrate de que los logs de origen (p. ej., binlog/redo) retengan suficiente historial.
AWS Snowball (Edge Storage/Compute Optimized): transferencia de datos offline a escala de petabytes cuando las redes son limitadas o costosas, o cuando necesitas cargar conjuntos de datos masivos en S3/EFS rápidamente. Encadena múltiples dispositivos para cargas de varios petabytes. Úsalo para cargas masivas iniciales, recolección en ubicaciones remotas/de borde (edge) o migración desde centros de datos con restricciones. Los datos se cifran de extremo a extremo con KMS; el seguimiento del dispositivo y los sellos a prueba de manipulaciones respaldan la cadena de custodia.
AWS DataSync: transferencia en línea y acelerada para NFS/SMB a S3/EFS/FSx y entre servicios de almacenamiento/Regiones de AWS. Gestiona la detección de cambios incrementales, la paralelización, la compresión, el control del ancho de banda, la programación y las comprobaciones de integridad. Úsalo para mover deltas recurrentes, flujos de trabajo híbridos y reemplazar scripts rsync personalizados con automatización gestionada. Despliega el agente de DataSync on-premise para acceder al almacenamiento local.

Escenario de Problema Práctico

Shopify necesita modernizar su canalización de medios de productos y datos de catálogo a nivel global, al tiempo que mejora la resiliencia y la latencia para los compradores de todo el mundo. La empresa debe: replicar las imágenes de los productos entre Regiones y cuentas con un RPO estricto, reducir la latencia de lectura de DynamoDB en Norteamérica y Europa, migrar activos NFS on-premise con deltas continuos y simplificar las operaciones de RDS con copias de seguridad fiables.

Implementar S3 CRR con Replication Time Control desde el bucket de medios principal en us-east-1 (cuenta de merchandising) a un bucket de destino en eu-west-1 (cuenta de entrega).

Por qué: CRR satisface la separación entre Regiones y entre cuentas para el mínimo privilegio y la soberanía de los datos. RTC proporciona un SLA de replicación de 15 minutos y monitorización para un RPO de grado de cumplimiento (compliance). La política de bucket entre cuentas garantiza que el rol de replicación de origen pueda escribir, y especificar una clave KMS de destino mantiene los dominios de cifrado.

Definir reglas de replicación de S3 filtradas por prefijo y etiqueta para segregar originales, miniaturas y logs, y habilitar la replicación de marcadores de eliminación. Usar S3 Batch Replication para rellenar los objetos heredados.

Por qué: La delimitación de reglas evita costos de replicación innecesarios, y la replicación de marcadores de eliminación mantiene la consistencia semántica entre Regiones. Batch Replication cierra las brechas históricas sin necesidad de scripts a medida.

Convertir el catálogo de productos y el inventario a una tabla global de DynamoDB entre us-east-1 y eu-west-1; cambiar las tablas a capacidad bajo demanda y añadir clústeres de DAX por Región para las API con mucha lectura.

Por qué: Las tablas globales proporcionan escrituras activo-activo con lecturas/escrituras locales de baja latencia y replicación continua. La capacidad bajo demanda elimina el riesgo de la planificación de capacidad durante los picos de tráfico. DAX reduce las latencias P99 para lecturas frecuentes (hot reads), protegiendo a DynamoDB de accesos en ráfagas.

Migrar la carga de trabajo relacional de pedidos a Amazon Aurora MySQL con endpoints de escritor y lector; añadir un lector pequeño de Aurora Serverless v2 para analíticas con picos y habilitar copias de seguridad automatizadas con una política de retención de 14 días.

Por qué: Los endpoints de clúster/lector desacoplan la lectura/escritura y minimizan la interrupción durante el mantenimiento o la conmutación por error (failover). Serverless v2 absorbe ráfagas analíticas impredecibles de manera rentable. Las copias de seguridad automatizadas ofrecen PITR y procesos de restauración simplificados.

Introducir ElastiCache for Redis (modo clúster habilitado) para el almacenamiento de sesiones y el almacenamiento en caché de la disponibilidad de productos con Multi-AZ y copias de seguridad de instantáneas (snapshots); establecer TTLs alineados con los SLAs del negocio.

Por qué: Las estructuras de datos de Redis y la conmutación por error Multi-AZ garantizan sesiones rápidas y con estado (stateful) y una invalidación de caché casi en tiempo real. El modo clúster escala horizontalmente a medida que crecen el tamaño del catálogo y el tráfico.

Crear un sistema de archivos EFS Regional con destinos de montaje (mount targets) en cada AZ de la aplicación y Puntos de Acceso para cargas de trabajo que requieran almacenamiento POSIX compartido (p. ej., procesadores de medios). Habilitar las transiciones del ciclo de vida de EFS a IA después de 30 días.

Por qué: EFS proporciona almacenamiento compartido elástico y Multi-AZ; los Puntos de Acceso imponen el aislamiento por aplicación y las identidades POSIX. La gestión del ciclo de vida reduce los costos automáticamente para los activos de acceso poco frecuente (cold assets) que permanecen accesibles.

Migrar las bibliotecas de medios NFS on-premise usando AWS DataSync con tareas programadas para sincronizaciones incrementales nocturnas en S3 y EFS.

Por qué: DataSync gestiona la detección de cambios, el paralelismo, la verificación de integridad y el control del ancho de banda mejor que un rsync ad hoc, automatizando los deltas continuos con una sobrecarga operativa mínima.

Mover el catálogo heredado de PostgreSQL a Aurora usando AWS DMS (carga completa más CDC) y AWS Schema Conversion Tool donde sea necesario; realizar la transición (cut over) después de que se drene el retraso (lag) de CDC.

Por qué: DMS permite una migración con un tiempo de inactividad casi nulo, con una replicación continua que garantiza la paridad de los datos en el momento de la transición. SCT se encarga de las conversiones específicas del motor.

Cargar los medios históricos de varios petabytes en S3 usando dispositivos Snowball Edge, y luego cambiar a DataSync para los incrementos continuos.

Por qué: Snowball acelera la transferencia masiva inicial sin saturar los enlaces WAN; DataSync mantiene las actualizaciones continuas después de la carga inicial con verificación y programación.

Esta arquitectura reduce las latencias de lectura globales, proporciona RPOs de replicación predecibles, simplifica las operaciones relacionales y las copias de seguridad, centraliza el almacenamiento compartido con controles de acceso y ofrece una ruta pragmática desde la migración masiva offline hasta el movimiento de datos incremental y automatizado.

← Arquitecturas Orientadas a Eventos y Automatización · Todos los dominios · Redes y Entrega de Contenido →

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