Curso AWS Cloud Practitioner CLF-C02

AWS tiene muchas bases de datos, y eso al principio puede parecer un lío. Pero en CLF-C02 no esperan que seas DBA ni que administres motores en profundidad. Lo que el examen quiere comprobar es más sencillo: que sepas reconocer qué tipo de base de datos encaja mejor con cada caso de uso.

La pregunta clave no es “¿cuál es la mejor base de datos de AWS?”, porque esa base de datos universal no existe. La pregunta correcta es: ¿qué necesita la aplicación? ¿SQL? ¿NoSQL? ¿baja latencia? ¿analítica? ¿caché? ¿relaciones tipo grafo? ¿documentos? ¿series temporales?

1. Primero entiende las familias de bases de datos

Antes de memorizar servicios, ordena las bases de datos por familias. Esto ayuda muchísimo en preguntas de examen.

• Relacionales: datos en tablas, SQL, relaciones, transacciones. Piensa en RDS y Aurora.
• NoSQL clave-valor/documento: alta escala, baja latencia, modelos flexibles. Piensa en DynamoDB.
• Data warehouse: analítica, BI, reporting y grandes volúmenes de datos. Piensa en Redshift.
• Caché en memoria: reducir latencia y descargar lecturas de una base principal. Piensa en ElastiCache o MemoryDB.
• Grafos: relaciones complejas entre entidades. Piensa en Neptune.
• Documentos: documentos JSON y compatibilidad con MongoDB. Piensa en DocumentDB.
• Series temporales: métricas, sensores, IoT y datos con marca de tiempo. Piensa en Timestream.
• Ledger: histórico inmutable y verificable. Piensa en QLDB.

2. Amazon RDS: bases relacionales gestionadas

Amazon RDS es el servicio gestionado de bases de datos relacionales de AWS. Lo usarías cuando quieres una base SQL tradicional sin encargarte de muchas tareas operativas como backups automáticos, parches, alta disponibilidad o réplicas, según configuración.

RDS soporta motores conocidos como:

• MySQL.
• PostgreSQL.
• MariaDB.
• Oracle.
• Microsoft SQL Server.
• Db2.

Para CLF-C02, la asociación es clara: base relacional gestionada + motor SQL conocido = Amazon RDS.

3. Amazon Aurora: relacional optimizada para AWS

Amazon Aurora también es relacional, pero está diseñada para AWS. Es compatible con MySQL y PostgreSQL y suele aparecer cuando el escenario habla de alto rendimiento, disponibilidad y una base relacional cloud-native.

No pienses en Aurora como “otra NoSQL”. Aurora es relacional. La diferencia mental frente a RDS es que Aurora es una opción optimizada por AWS para cargas relacionales compatibles con MySQL/PostgreSQL.

• Compatible con MySQL y PostgreSQL.
• Diseñada para alta disponibilidad y rendimiento en AWS.
• Gestionada por AWS.
• Puede ser buena opción para aplicaciones relacionales críticas.

4. Amazon DynamoDB: NoSQL serverless de baja latencia

Amazon DynamoDB es una base de datos NoSQL serverless de clave-valor y documento. Es una de las bases más importantes para CLF-C02 porque aparece en escenarios de aplicaciones modernas, serverless, alto tráfico, escalabilidad automática y baja latencia.

Piensa en DynamoDB cuando una aplicación necesita responder muy rápido a muchísimas peticiones y no requiere joins SQL complejos.

• NoSQL.
• Serverless.
• Clave-valor y documento.
• Baja latencia.
• Escala automáticamente.
• Muy usado en arquitecturas serverless con Lambda y API Gateway.

5. Amazon Redshift: data warehouse, no base transaccional

Amazon Redshift es el data warehouse de AWS. Se usa para analítica, BI, reporting y consultas sobre grandes volúmenes de datos. No es la primera opción para una aplicación web que necesita guardar pedidos uno a uno en tiempo real.

La diferencia importante es esta:

6. ElastiCache y MemoryDB: memoria para ir más rápido

Amazon ElastiCache proporciona caché en memoria compatible con Redis o Memcached. Su objetivo habitual es reducir latencia y descargar trabajo de una base de datos principal.

Ejemplo sencillo: una aplicación consulta muchas veces los mismos datos. En lugar de ir siempre a la base principal, guarda resultados frecuentes en caché para responder más rápido.

• ElastiCache: caché en memoria con Redis o Memcached.
• MemoryDB for Redis: base de datos en memoria compatible con Redis, duradera y de alto rendimiento.

7. Amazon Neptune: base de datos de grafos

Amazon Neptune es una base de datos de grafos. Se usa cuando lo importante son las relaciones entre entidades: nodos, aristas, conexiones y recorridos.

Casos típicos:

• Redes sociales.
• Recomendaciones.
• Detección de fraude.
• Grafos de conocimiento.
• Relaciones complejas entre usuarios, productos, cuentas o eventos.

8. Amazon DocumentDB: documentos compatibles con MongoDB

Amazon DocumentDB es una base documental gestionada compatible con cargas MongoDB. Se usa cuando el modelo de datos se basa en documentos, normalmente tipo JSON.

No la confundas con DynamoDB. Ambas pueden sonar “NoSQL”, pero no son lo mismo:

• DynamoDB: NoSQL serverless clave-valor/documento, muy orientada a escala y baja latencia.
• DocumentDB: base documental gestionada compatible con MongoDB.

9. Amazon Timestream: series temporales

Amazon Timestream está pensada para datos de series temporales. Es decir, datos donde el tiempo es parte esencial del análisis.

Ejemplos típicos:

• Métricas de sistemas.
• Datos de sensores.
• Telemetría IoT.
• Eventos con timestamp.
• Mediciones repetidas a lo largo del tiempo.

10. Amazon QLDB: ledger inmutable y verificable

Amazon Quantum Ledger Database (QLDB) es una base de datos tipo ledger. Su objetivo es mantener un historial inmutable y verificable de cambios.

Puede aparecer en escenarios donde una organización necesita trazabilidad fuerte, registro histórico verificable o un libro mayor centralizado sin administrar una red blockchain.

• Historial inmutable.
• Registro verificable.
• Auditoría de cambios.
• Ledger centralizado.

11. Comparativa para examen

12. Cómo razonar una pregunta de bases de datos

Cuando veas una pregunta de bases de datos, intenta seguir este orden:

1. Identifica si es transaccional o analítica. Transaccional suele ir a RDS/Aurora/DynamoDB. Analítica suele ir a Redshift o Athena.
2. Mira si pide SQL. SQL tradicional apunta a RDS o Aurora.
3. Mira si pide NoSQL serverless y baja latencia. Eso apunta a DynamoDB.
4. Mira si pide caché. Eso apunta a ElastiCache.
5. Mira si el modelo de datos es especial. Grafos, documentos, series temporales o ledger apuntan a servicios especializados.
6. No elijas el servicio más famoso. Elige el que resuelve exactamente el requisito.

13. Diferencias que suelen confundir

• RDS vs Aurora: ambos son relacionales; Aurora está optimizada para AWS y es compatible con MySQL/PostgreSQL.
• RDS vs DynamoDB: RDS es SQL relacional; DynamoDB es NoSQL serverless.
• DynamoDB vs DocumentDB: DynamoDB es clave-valor/documento serverless; DocumentDB se asocia a compatibilidad MongoDB.
• Redshift vs RDS: Redshift es analítica/data warehouse; RDS es transaccional.
• Redshift vs Athena: Redshift es un data warehouse; Athena consulta datos en S3 con SQL de forma serverless.
• ElastiCache vs RDS: ElastiCache no sustituye normalmente a la base principal; acelera lecturas y reduce latencia.
• Neptune vs DocumentDB: Neptune es grafos; DocumentDB es documentos.
• Timestream vs DynamoDB: Timestream está optimizada para datos temporales; DynamoDB es NoSQL general de baja latencia.

14. Cómo estudiar este módulo

Te recomiendo aprenderlo como una tabla mental de decisiones:

• ¿Necesito SQL gestionado? RDS.
• ¿Necesito SQL compatible MySQL/PostgreSQL optimizado para AWS? Aurora.
• ¿Necesito NoSQL serverless y baja latencia? DynamoDB.
• ¿Necesito data warehouse para BI? Redshift.
• ¿Necesito caché en memoria? ElastiCache.
• ¿Necesito relaciones complejas? Neptune.
• ¿Necesito documentos compatibles con MongoDB? DocumentDB.
• ¿Necesito datos de sensores o métricas por tiempo? Timestream.
• ¿Necesito historial inmutable y verificable? QLDB.

15. Errores típicos

• Elegir Redshift para una aplicación transaccional normal.
• Elegir DynamoDB cuando el requisito pide joins SQL complejos.
• Olvidar ElastiCache cuando el requisito es caché en memoria.
• Confundir DocumentDB con DynamoDB solo porque ambas son NoSQL.
• Usar RDS cuando el escenario pide grafos o series temporales.
• Elegir Aurora pensando que es NoSQL.
• Elegir Athena cuando el escenario pide un data warehouse gestionado para BI empresarial.
• Olvidar que las bases especializadas existen para casos muy concretos.

16. Cómo saber si dominas este módulo

Vas bien si puedes responder sin mirar apuntes:

• Qué servicio elegirías para PostgreSQL gestionado.
• Qué diferencia hay entre RDS y Aurora.
• Cuándo elegir DynamoDB frente a RDS.
• Por qué Redshift no es la primera opción para una aplicación OLTP normal.
• Qué servicio usarías para caché en memoria.
• Qué servicio usarías para grafos.
• Qué servicio usarías para documentos compatibles con MongoDB.
• Qué servicio usarías para datos de sensores con marca temporal.
• Qué servicio usarías para un ledger inmutable y verificable.

Resumen final

Las bases de datos AWS se entienden mejor cuando las estudias por patrón de uso. No intentes memorizar una lista sin contexto. Pregúntate siempre qué necesita la aplicación: SQL, NoSQL, analítica, caché, grafos, documentos, series temporales o historial inmutable.

Para CLF-C02, las asociaciones más importantes son: RDS para bases relacionales gestionadas; Aurora para relacional optimizada en AWS; DynamoDB para NoSQL serverless de baja latencia; Redshift para data warehouse; ElastiCache para caché; Neptune para grafos; DocumentDB para documentos compatibles con MongoDB; Timestream para series temporales; QLDB para ledger.