Amazon SAP-C02: Bases de Datos y Análisis — Guía de estudio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Bases de datos transaccionales, patrones de escalado y caché

La elección entre Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server), Amazon Aurora y Amazon DynamoDB comienza con el perfil de la carga de trabajo: un esquema relacional estricto y transacciones complejas favorecen a RDS/Aurora; la escala masiva, las búsquedas con latencia de milisegundos de un solo dígito y un esquema flexible favorecen a DynamoDB. Aurora ofrece un alto rendimiento (throughput) con almacenamiento distribuido, autoescalado de réplicas, conmutación por error (failover) rápida, Global Database para lecturas entre regiones y recuperación ante desastres (disaster recovery) de menor latencia. RDS Multi-AZ proporciona replicación síncrona para la disponibilidad, pero no para el escalado de lectura; las réplicas de lectura (read replicas) (RDS/Aurora) gestionan las cargas de trabajo con un uso intensivo de lectura. Para el almacenamiento en caché de clave-valor y una latencia de microsegundos, ElastiCache (Redis o Memcached) reduce la carga de la base de datos; MemoryDB for Redis añade durabilidad y persistencia compatible con Redis donde los datos deben ser altamente disponibles y recuperables. Algunas trampas comunes incluyen subestimar los límites de conexión (conexiones máximas de MySQL), no usar la agrupación de conexiones (connection pooling) (Lambda/contenedores que generan muchas conexiones), particiones calientes (hot partitions) en DynamoDB por un mal diseño de claves y descuidar la expulsión/diseño de la caché, lo que lleva a la obsolescencia de los datos (data staleness). Las compensaciones (trade-offs) en la toma de decisiones a menudo se centran en el costo frente al rendimiento y la resiliencia: las instancias provisionadas de Aurora o RDS de gran tamaño cuestan más, pero reducen la latencia y simplifican las transacciones, mientras que DynamoDB con capacidad bajo demanda (on-demand) o autoescalado puede reducir las operaciones, pero requiere una planificación cuidadosa del esquema y la capacidad. Los patrones de cifrado, copias de seguridad automatizadas, recuperación a un punto en el tiempo (PITR) y replicación entre regiones deben elegirse según el RPO/RTO.

Data Lake, ETL y motores de consulta analítica

S3 es el data lake duradero canónico; el diseño debe centrarse en el particionamiento, los formatos columnares (Parquet/ORC), la compresión y la compactación para impulsar consultas rentables. AWS Glue y AWS Glue Data Catalog proporcionan ETL sin servidor (serverless), descubrimiento de esquemas y catalogación; Lake Formation añade control de acceso centralizado, permisos detallados (fine-grained) y uso compartido entre cuentas para data lakes gobernados. Para análisis interactivos, Amazon Athena consulta los datos de S3 directamente (sin servidor, pago por consulta), mientras que Amazon Redshift (con soporte para RA3/Iceberg) proporciona un data warehouse MPP administrado y de alto rendimiento para BI complejo y operaciones de join. Use Redshift Spectrum para consultar datos de S3 desde Redshift sin necesidad de ingerirlo todo. Kinesis Data Firehose es una ruta de ingesta administrada para depositar eventos de streaming en S3 o Redshift. Las trampas comunes para los arquitectos incluyen tener demasiados archivos pequeños que causan una sobrecarga (overhead) alta en Athena/Redshift, claves de partición mal elegidas que crean sesgos (skews) y no compactar o convertir a formatos columnares. Las compensaciones son latencia frente a costo: Athena tiene un bajo costo operativo para consultas ad-hoc; Redshift proporciona un rendimiento sostenido más alto a un costo provisionado mayor. La gobernanza de datos y el linaje (lineage) a través de Glue/Lake Formation son esenciales para el cumplimiento normativo (compliance) y la propiedad compartida entre múltiples equipos.

Streaming, procesamiento en tiempo real y búsqueda

La ingesta y el procesamiento en tiempo real utilizan Kinesis Data Streams (rendimiento basado en fragmentos (shards) y garantías de orden), Kinesis Data Firehose (entrega administrada a destinos o sinks), Kinesis Data Analytics (procesamiento con SQL/Apache Flink) o Amazon MSK para necesidades compatibles con Kafka. Elija Kinesis para una integración directa, nativa de AWS y sin servidor; elija MSK cuando los clientes dependan de las herramientas del ecosistema de Kafka. La semántica de entrega de “al menos una vez” (at-least-once), los límites de los fragmentos (shards), el paralelismo de los consumidores y el aprovisionamiento de una cantidad adecuada de fragmentos son escollos operativos comunes. Para la búsqueda rápida y la observabilidad en etapas posteriores (downstream), Amazon OpenSearch Service proporciona indexación, búsqueda casi en tiempo real y paneles de Kibana integrados; la gestión del ciclo de vida de los índices (index lifecycle management) y los niveles warm/cold reducen el costo de los datos más antiguos. Use Kinesis + Lambda o Kinesis + KDA para enriquecer/transformar eventos antes de persistirlos en OpenSearch o S3. Diseñe la idempotencia y la deduplicación en los consumidores, ya que los reintentos o las repeticiones (replays) causan duplicados. Los criterios de decisión equilibran el rendimiento (throughput) y la latencia: Kinesis con muchos fragmentos (shards) soporta un alto rendimiento, pero aumenta el costo y la gestión; Firehose elimina la carga del consumidor, pero ofrece una transformación menos flexible.

Migración, replicación, gobernanza y resiliencia operativa

Database Migration Service (AWS DMS) y Schema Conversion Tool (SCT) son las herramientas de migración principales para traslados homogéneos y heterogéneos, permitiendo la captura continua de datos de cambio (CDC). Los patrones de migración incluyen rehost (lift-and-shift), replatform (p. ej., mover a Aurora) y refactor a DynamoDB o serverless cuando sea apropiado. Utilice DMS con validación previa y posterior a la migración, copia de tablas en paralelo y un manejo cuidadoso de LOB/LOBLOB. La replicación entre cuentas y entre regiones requiere acceso a claves de KMS, VPC peering o Transit Gateway, y planificación del ancho de banda de red; las Global Databases y las réplicas de lectura son alternativas cuando se necesitan lecturas de baja latencia entre regiones. La gobernanza y la seguridad deben incluir Lake Formation para compartir datos, el principio de privilegio mínimo de IAM, políticas de recursos para snapshots de S3 y RDS, y endpoints de VPC/PrivateLink para evitar la salida pública. Las trampas operativas incluyen un monitoreo insuficiente (no detectar el replica lag), no probar los failover/runbooks y los costos de egreso ocultos durante las transferencias masivas. Las copias de seguridad, la estrategia de PITR y la recuperación automatizada influyen en el equilibrio entre RTO/RPO; combine la replicación para la disponibilidad con copias de seguridad regulares para la retención a largo plazo y el cumplimiento normativo.

Problema práctico: escenario de caso de uso

Escenario: Acme Retail opera una plataforma de comercio electrónico en una AWS Organization multicuenta con cargas de trabajo de producción en us-east-1 y europe-west-1. Almacenan flujos de clics (clickstreams) y eventos de transacciones en S3 y operan una base de datos OLTP on-premises que debe migrarse a AWS con un tiempo de inactividad mínimo.

Desafío: Migrar la base de datos OLTP a un destino de alta disponibilidad y escalable para lecturas entre regiones, mientras se construye un lago de datos analítico gobernado en S3 con capacidad de ingesta y consulta en tiempo real.

Enfoque recomendado:

Utilizar AWS DMS con SCT para la conversión de esquemas y configurar CDC continuo desde la base de datos on-premises a Amazon Aurora (Global Database) en us-east-1 con una réplica de lectura de Aurora en europe-west-1.
Ingerir los clickstreams y los eventos de transacciones a través de Amazon Kinesis Data Streams y Firehose; almacenar en búfer y entregar los eventos sin procesar a S3 en formato Parquet, particionados por fecha y región.
Catalogar los datos de S3 con AWS Glue, aplicar el control de acceso a través de Lake Formation y realizar ETL con trabajos de Glue (o Glue Studio) para producir conjuntos de datos curados; exponerlos a los analistas a través de Amazon Athena y Redshift Spectrum.
Añadir ElastiCache (Redis) para el almacenamiento en caché de alta lectura de datos de sesión y productos populares (hot data); instrumentar el monitoreo de extremo a extremo con CloudWatch, habilitar el Monitoreo Mejorado (Enhanced Monitoring) en Aurora y validar el failover con runbooks.

Justificación: Este enfoque minimiza el tiempo de inactividad utilizando CDC de DMS, proporciona lecturas globales de baja latencia a través de Aurora Global Database, establece un lago de datos gobernado en S3 para agilidad analítica y reduce la carga en los sistemas OLTP con almacenamiento en caché e ingesta de streaming desacoplada, en línea con las mejores prácticas empresariales de resiliencia y rendimiento.

← Almacenamiento y Gestión de Datos · Todos los dominios · Migración y Modernización →

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