Cómo funciona DynamoDB en AWS

Curso de AWS Certified Solutions Architect Associate

Contenido del curso

Fundamentos de AWS

Identidad, Acceso y Gobernanza Multicuenta

Servicios de Computo en AWS

Contenedores en AWS

Redes en AWS

Escalamiento y balanceo en AWS

Almacenamiento en AWS

Bases de datos en AWS

Migración en AWS

Monitoreo y Auditoria en AWS

DNS y CDN en AWS

Servicios de Seguridad

Serverless

Servicios de Datos en AWS

Servicios de AI y ML em AWS

64
Servicios de IA y ML en AWS
04:09 min

Servicios de Backup y Recuperación ante desastres

Architect Solutions Certificate

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:008:09

Cómo funciona DynamoDB en AWS

Curso de AWS Certified Solutions Architect Associate

Clase 38 de 69

Clase 38 / 69

Recursos

Si estás diseñando una base de datos para una aplicación que crece rápido y necesita responder en milisegundos, Amazon DynamoDB es una de las opciones más potentes dentro de AWS. Aquí descubrirás cómo funciona esta base de datos NoSQL, qué la hace tan flexible y cómo aprovechar funciones como índices secundarios, streams y tablas globales para construir arquitecturas resilientes.

¿Qué es DynamoDB y por qué lo creó Amazon?

Amazon desarrolló DynamoDB porque las bases de datos transaccionales tradicionales no aguantaban el rendimiento ni la escala que la compañía necesitaba en eventos como Black Friday o Prime Day. Es una base de datos no relacional, lo que significa que no exige un esquema fijo: cada item dentro de una tabla puede tener atributos distintos y todos conviven sin problema [1:30].

Imagina una tabla con un libro que tiene nombre, autor y año, junto a un álbum que tiene nombre, autor y un track ID, y al lado una película con director y protagonista. Todo en la misma tabla. Esa flexibilidad de esquema es uno de los grandes diferenciales frente a una base relacional.

¿DynamoDB es SQL o NoSQL? Es NoSQL. No usa tablas con esquema fijo ni joins; cada item puede tener atributos distintos dentro de una misma tabla.

¿Cómo funcionan las primary keys, partition keys y sort keys?

La forma de acceder a cada item en DynamoDB es a través de una primary key, que se compone de una partition key y, opcionalmente, una sort key [2:35]. A diferencia de una base relacional, aquí no hay foreign keys ni relaciones entre tablas. El diseño depende completamente de cómo vayas a consultar los datos.

Por eso, elegir bien tu partition key y tu sort key desde el inicio es una decisión crítica. Puedes consultar por identificador de libro, por autor o por año, pero todo eso se define con la estructura de claves que armes.

¿Cuándo usar capacidad bajo demanda o aprovisionada?

DynamoDB escala automáticamente con picos de tráfico y te ofrece dos modelos para aprovisionar capacidad [3:45]:

Bajo demanda: las unidades de lectura y escritura crecen o decrecen solas. Ideal cuando la carga es impredecible.
Aprovisionada: defines desde el inicio cuántas lecturas y escrituras necesitas. Más económica si ya conoces tu patrón de uso.

Esa elección impacta directamente el costo y la previsibilidad de tu factura.

¿Qué diferencia hay entre local secondary index y global secondary index?

Una ventaja clave de DynamoDB es poder consultar los mismos datos por distintos patrones sin duplicar tablas. Para eso existen dos tipos de índices [5:30]:

Local secondary index (LSI): reutiliza la partition key de la tabla principal y cambia la sort key. Solo se puede crear al momento de crear la tabla y no se puede modificar después.
Global secondary index (GSI): permite definir partition keys y sort keys completamente distintas. Puedes crearlos, modificarlos y eliminarlos en cualquier momento.

Los GSI son tu mejor aliado cuando los patrones de acceso cambian con el tiempo o no los conoces desde el principio.

¿Cuándo conviene un GSI sobre un LSI? Cuando necesitas flexibilidad para cambiar los patrones de búsqueda después de crear la tabla, o cuando la partition key del nuevo índice debe ser distinta a la original.

¿Qué es la consistencia eventual en DynamoDB?

DynamoDB está diseñado para responder con latencia mínima y replicarse automáticamente. Cuando una tabla se replica en varias zonas o regiones, hay un trade-off importante con la consistencia de los datos [7:15].

Con consistencia eventual, tus lecturas son más rápidas y baratas, pero podrías leer datos que aún no reflejan la última escritura. Si necesitas siempre el dato más actualizado, debes pedir lecturas fuertemente consistentes, sacrificando algo de latencia.

¿Para qué sirve DynamoDB Streams?

DynamoDB Streams captura y guarda durante 24 horas todos los eventos que ocurren sobre una tabla: lecturas, escrituras y borrados [8:20]. Es la pieza clave para arquitecturas basadas en eventos.

Un flujo típico se ve así:

La aplicación escribe en una tabla de DynamoDB.
Streams captura el evento y dispara una función Lambda.
La Lambda procesa el dato y lo envía a otra tabla, a un bucket de S3 o a un servicio de notificaciones.

También puedes conectar Streams con Kinesis Data Streams para procesar eventos en tiempo real, enviarlos con Data Firehose a S3, consultarlos con Athena o cargarlos en un clúster de Amazon Redshift para análisis de big data. Y si necesitas búsquedas avanzadas, puedes integrarlo con OpenSearch o con SNS y SQS para notificaciones.

¿Qué son las tablas globales en DynamoDB?

La mayoría de servicios de AWS viven en una sola región y se replican entre zonas de disponibilidad dentro de esa región. DynamoDB rompe ese límite con las tablas globales [10:30]: activas la opción y AWS replica automáticamente tus tablas en otras regiones.

Esto te garantiza alta disponibilidad y resiliencia sin tener que diseñar pasos intermedios de replicación. Para una empresa de juegos en línea con usuarios distribuidos por el mundo, esa replicación global combinada con capacidad bajo demanda es la receta más rentable para mantener una experiencia fluida.

¿Cómo diseñarías tú la arquitectura para esa empresa de juegos? Déjame tu respuesta en los comentarios.

Resumen

¿Qué es DynamoDB y por qué lo creó Amazon?

¿DynamoDB es SQL o NoSQL? Es NoSQL. No usa tablas con esquema fijo ni joins; cada item puede tener atributos distintos dentro de una misma tabla.

¿Cómo funcionan las primary keys, partition keys y sort keys?

¿Cuándo usar capacidad bajo demanda o aprovisionada?

DynamoDB escala automáticamente con picos de tráfico y te ofrece dos modelos para aprovisionar capacidad [3:45]:

Bajo demanda: las unidades de lectura y escritura crecen o decrecen solas. Ideal cuando la carga es impredecible.
Aprovisionada: defines desde el inicio cuántas lecturas y escrituras necesitas. Más económica si ya conoces tu patrón de uso.

Esa elección impacta directamente el costo y la previsibilidad de tu factura.

¿Qué diferencia hay entre local secondary index y global secondary index?

Una ventaja clave de DynamoDB es poder consultar los mismos datos por distintos patrones sin duplicar tablas. Para eso existen dos tipos de índices [5:30]:

Local secondary index (LSI): reutiliza la partition key de la tabla principal y cambia la sort key. Solo se puede crear al momento de crear la tabla y no se puede modificar después.
Global secondary index (GSI): permite definir partition keys y sort keys completamente distintas. Puedes crearlos, modificarlos y eliminarlos en cualquier momento.

Los GSI son tu mejor aliado cuando los patrones de acceso cambian con el tiempo o no los conoces desde el principio.

¿Cuándo conviene un GSI sobre un LSI? Cuando necesitas flexibilidad para cambiar los patrones de búsqueda después de crear la tabla, o cuando la partition key del nuevo índice debe ser distinta a la original.

¿Qué es la consistencia eventual en DynamoDB?

¿Para qué sirve DynamoDB Streams?

DynamoDB Streams captura y guarda durante 24 horas todos los eventos que ocurren sobre una tabla: lecturas, escrituras y borrados [8:20]. Es la pieza clave para arquitecturas basadas en eventos.

Un flujo típico se ve así:

La aplicación escribe en una tabla de DynamoDB.
Streams captura el evento y dispara una función Lambda.
La Lambda procesa el dato y lo envía a otra tabla, a un bucket de S3 o a un servicio de notificaciones.

¿Qué son las tablas globales en DynamoDB?

¿Cómo diseñarías tú la arquitectura para esa empresa de juegos? Déjame tu respuesta en los comentarios.

Gustavo Bautista Hernández

Hace un año

La respuesta correcta es la Opción D:

"Utilizar tablas globales de DynamoDB para la replicación automática entre regiones. Implemente tablas en varias regiones de AWS. Use el modo de capacidad aprovisionada. Habilite el escalado automático."

¿Por qué es la respuesta correcta?

Esta solución cumple con todos los requisitos de forma óptima:

Alta disponibilidad y resiliencia: Las tablas globales replican datos automáticamente en múltiples regiones. Si una región falla, las otras continúan funcionando sin interrupción.
Baja latencia: Los usuarios acceden a la tabla en la región más cercana, garantizando una experiencia de juego fluida.
Replicación automática: DynamoDB Global Tables gestiona la replicación multi-región automáticamente con conflictos resueltos mediante "last writer wins".
Modo de capacidad aprovisionada + Auto Scaling:
- Permite optimizar costos mejor que on-demand
- El auto scaling ajusta la capacidad automáticamente según la demanda
- Es más rentable para cargas de trabajo predecibles o con patrones identificables
Arquitectura robusta: Cumple perfectamente con el requisito de "disponibilidad continua y resiliente".

¿Por qué las otras opciones no son correctas?

Opción A - "Crear tablas de DynamoDB en una sola región de AWS. Utilizar el modo de capacidad bajo demanda. Utilizar tablas globales para replicar datos en múltiples regiones.":

Contradicción interna: Dice "una sola región" pero luego menciona "tablas globales" que requieren múltiples regiones
Confusa: No está clara la arquitectura propuesta
On-demand no es lo más rentable: Para juegos con uso predecible, aprovisionada + auto scaling es más económico

Opción B - "Utilizar DynamoDB Accelerator (DAX) para almacenar en caché los datos de acceso frecuente. Implementar tablas en una sola región de AWS... Configurar manualmente la replicación entre regiones en otras regiones.":

Una sola región = punto único de fallo: No cumple con "disponibilidad continua"
Replicación manual: Compleja, propensa a errores y no es nativa
DAX innecesario: Aunque DAX mejora el rendimiento de lectura, no resuelve el problema de disponibilidad multi-región
No es la más rentable: Añade costo de DAX sin abordar el requisito principal

Opción C - "Crear tablas de DynamoDB en múltiples regiones de AWS. Utilizar el modo de capacidad bajo demanda. Utilizar DynamoDB Streams para la replicación entre regiones.":

Replicación personalizada con Streams: Requiere implementar y mantener tu propia lógica de replicación usando Lambda u otros servicios
Mayor complejidad operativa: No es "la forma más rentable"
DynamoDB Streams no está diseñado para esto: Es para procesamiento de eventos, no replicación multi-región
Reinventar la rueda: ¿Para qué implementar replicación manual cuando Global Tables lo hace automáticamente?
On-demand: Generalmente más costoso que aprovisionada + auto scaling para cargas predecibles

Comparación de costos (Capacidad Aprovisionada vs On-Demand):

Modo Aprovisionado + Auto Scaling:

Ideal para cargas de trabajo predecibles o con patrones
Costo por hora de capacidad reservada
Auto scaling ajusta según métricas (más control y optimización)
Más rentable para aplicaciones con tráfico constante o patrones conocidos

Modo On-Demand:

Pagas por cada solicitud
Ideal para cargas de trabajo impredecibles o esporádicas
Más caro en aplicaciones con uso constante o alto volumen

Para un juego en línea con base de usuarios creciente, el modo aprovisionado con auto scaling es más rentable.

Miguel Angel Reyes Moreno

Hace un año

Gran aporte, y sí, estoy totalmente de acuerdo contigo, llegué a la misma conclusión

Fundamentos de AWS

Certificación AWS Solutions Architect Associate: Fundamentos y Preparación

Preparación para certificación AWS Arquitecto de Soluciones

Configuración de presupuestos en AWS para controlar costos

Los 6 pilares del Well-Architected Framework

Identidad, Acceso y Gobernanza Multicuenta

Cómo evitar brechas de seguridad con IAM

Creación de usuarios administrador y practicante en AWS IAM

Gestión de cuentas con AWS Organizations

Detecta recursos AWS expuestos con Access Analyzer

Cómo gestionar múltiples cuentas AWS

Servicios de Computo en AWS

Servicios de cómputo AWS: EC2, procesadores Graviton y AMIs

Compute Savings Plan para EC2 y Lambda

Cómo lanzar tu primera instancia EC2

Optimizar latencia en EC2 con tenencia dedicada

Cómo consultar metadatos de EC2 con IMDSv2

AWS Outposts: ejecutar AWS en tu data center

Despliegue de app web en Elastic Beanstalk

Contenedores en AWS

Contenedores en AWS: ECS, EKS y ECR

Gestión de imágenes de contenedores con ECR y Fargate

Configuración de clusters, tareas y servicios en Amazon ECS

Redes en AWS

Direccionamiento IP y bloques CIDR para redes AWS

NAT Gateway para subredes privadas en AWS

Configuración de instancias públicas y privadas con NAT Gateway

NACL y Security Groups en AWS

Cómo reparar un Security Group en EC2

Conectividad híbrida en AWS: VPC Peering, Transit Gateway y Endpoints

Escalamiento y balanceo en AWS

Tipos de balanceadores de carga en AWS

Configuración de balanceadores de carga en AWS para alta disponibilidad

Autoescalamiento en EC2 con Auto Scaling Groups

Cómo crear un Auto Scaling Group en EC2

Almacenamiento en AWS

Tipos de almacenamiento en AWS: EBS, EFS y S3

Instance Store vs EBS en AWS

EFS vs FSx para compartir archivos en AWS

Creación y configuración de volúmenes EBS en AWS

Transfer Acceleration para datos globales en S3

Configuración de EFS para compartir almacenamiento entre instancias

Recuperar objetos borrados en Amazon S3

Bases de datos en AWS

Bases de datos relacionales vs no relacionales en AWS

Cómo funciona DynamoDB en AWS

Creación y configuración de bases de datos Dynamo en AWS

Elasticache y DAX

RDS vs Aurora: réplicas y alta disponibilidad

Cómo configurar Aurora con alta disponibilidad en RDS

Migración en AWS

Estrategias de migración AWS: las 6 R para trasladar aplicaciones

Cómo migramos 500 TB a AWS sin downtime

Migración de datos con AWS Snow Family: opciones y características

DMS y SCT para migrar bases de datos en AWS

Monitoreo y Auditoria en AWS

CloudTrail y EventBridge en arquitecturas AWS

Monitoreo de AWS con CloudWatch

DNS y CDN en AWS

Zonas locales y de borde en AWS

CloudFront vs Global Accelerator en AWS

Failover en Route 53 para arquitectura activo-pasiva

Configuración de políticas de geoproximidad en AWS Route 53

Servicios de Seguridad

KMS vs CloudHSM para datos regulados

AWS Shield y WAF contra ataques DDoS

Servicios AWS para detectar vulnerabilidades

GuardDuty y Trusted Advisor para detectar amenazas en AWS

Serverless

API Gateway y Lambda en arquitecturas serverless

Creación y configuración de funciones Lambda para automatización

AWS SQS: Tipos de filas y configuración para arquitecturas serverless

AWS SNS y Step Functions para comunicación y workflows visuales

Servicios de Datos en AWS

Servicios de datos en AWS para tu examen

Kinesis, EMR, Glue

Casos de uso de Amazon Redshift en AWS

Servicios de AI y ML em AWS

Servicios de IA y ML en AWS

Servicios de Backup y Recuperación ante desastres