Hace un tiempo me tocó integrar DynamoDB con Lambda en un proyecto pequeño: un backend serverless para registrar eventos de usuario. Nada del otro mundo en papel, pero me demoré un poco más de lo esperado por eso esta guía cubre desde qué es DynamoDB hasta cómo exponerlo con API Gateway, con una sección de debugging real, optimización de costos, y un FAQ con las preguntas que más se repiten en el grupo de la comunidad.

¿Qué es DynamoDB y cuándo usarlo?

DynamoDB es el servicio de base de datos NoSQL administrado de AWS. "Administrado" significa que no hay servidor que configurar, parches que aplicar ni réplicas que coordinar. Tú defines la tabla, insertas datos, y AWS gestiona el resto: replicación multi-AZ, backups, escalabilidad.

A diferencia de una base relacional, en DynamoDB no defines un esquema estricto con columnas fijas. Cada ítem puede tener atributos distintos. Lo que sí es obligatorio al crear la tabla es definir la clave primaria, que puede ser:

Partition Key (PK) — clave simple, identifica de forma única cada ítem.
Partition Key + Sort Key (PK + SK) — clave compuesta, útil para agrupar múltiples ítems bajo una misma partición (ej: todos los pedidos de un usuario).

Modelo mental correcto
El diseño en DynamoDB gira alrededor del patrón de acceso, no del modelo de datos. Primero define cómo vas a consultar, luego diseña la tabla. Es al revés que en SQL, y eso confunde al principio.

¿Cuándo tiene sentido? Cuando el patrón de acceso es predecible, necesitas escala sin fricción, y especialmente cuando estás construyendo arquitecturas serverless. Ambos son stateless, ambos escalan automáticamente, y ninguno requiere conexiones persistentes.

⚠️ Cuándo NO usarlo
Si necesitas JOINs complejos, consultas ad-hoc frecuentes sobre múltiples atributos, o transacciones ACID complejas entre varias entidades, considera RDS o Aurora. DynamoDB brilla en acceso de clave-valor y patrones bien definidos, no en exploración libre de datos.

El flujo que vamos a construir

Vamos a construir dos versiones: la primera es solo Lambda + DynamoDB (ideal para aprender los conceptos sin ruido). La segunda agrega API Gateway para tener un endpoint HTTP real.

Paso a paso: desde cero hasta funcional

1. Crear la tabla en DynamoDB
Desde la consola de AWS → DynamoDB → Create table. Configuración mínima:

Table name: usuarios
Partition key: userId — tipo String
Capacity mode: On-demand (para pruebas y carga impredecible)

On-demand vs Provisionado
On-demand: pagas por cada unidad de lectura/escritura. Ideal para tráfico variable o proyectos nuevos donde no conoces el volumen.
Provisionado: defines RCUs y WCUs fijas. Más barato a escala predecible, pero si te quedas corto pagas con throttling.

2. Crear el rol IAM para Lambda
Este paso define qué puede hacer tu función Lambda. La regla de oro es least privilege: solo los permisos necesarios, nada más.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DynamoDBUsuariosAccess",
    "Effect": "Allow",
    "Action": [
      "dynamodb:PutItem",
      "dynamodb:GetItem",
      "dynamodb:UpdateItem",
      "dynamodb:DeleteItem",
      "dynamodb:Query"
    ],
    // ARN específico de tu tabla — OJO, NO uses "*"
    "Resource": "arn:aws:dynamodb:us-east-1:TU_ACCOUNT_ID:table/usuarios"
  }]
}

Pilas con este error clásico de seguridad
No uses "Resource": "*" en producción. El ARN lo encuentras en la consola de DynamoDB en la pestaña "Additional info" de la tabla. Cópialo desde ahí, no lo construyas a mano.