Desplegar una función Lambda que consulta DynamoDB en AWS exige ajustar variables de ambiente, parámetros dinámicos en la URL y permisos IAM. Si vienes de probar tu GET en local con Serverless Framework, hay tres detalles que debes resolver antes de subir tu aplicación a la nube para que funcione sin errores.

Por qué fallan las variables de ambiente entre local y la nube

Cuando tu cliente de DynamoDB tiene parámetros quemados apuntando a localhost, la Lambda en producción intentará conectarse a tu computadora y romperá la ejecución. La solución es condicionar esos parámetros según el entorno.

Serverless Framework inyecta automáticamente la variable IS_OFFLINE cuando trabajas en local. Esa variable vive en process.env.IS_OFFLINE y será true en tu máquina o undefined en la nube. Aprovechándola, puedes definir un objeto dynamoDbClientParams vacío por defecto y solo asignarle los valores locales cuando detectes el entorno offline [03:30].

¿Qué hace IS_OFFLINE en Serverless Framework? Es una variable de ambiente que el framework inyecta solo cuando ejecutas la función en tu máquina. Te permite diferenciar lógicamente entre local y producción sin cambiar código manualmente.

Cuando el objeto llega vacío al cliente, este apunta por defecto a la base de datos en la nube. Así evitas duplicar configuraciones.

Cómo capturar el ID desde la URL con path parameters

Un GET real necesita recibir el identificador del recurso desde la ruta, no tener un 1 quemado en el código. Aquí entra en juego el objeto event, que contiene toda la información del trigger que disparó la Lambda.

Si el trigger es HTTP, event trae el request completo. Si fuera una cola SQS, traería los mensajes. Para extraer un parámetro de ruta usas event.pathParameters.id y lo guardas en una variable userId [05:45].

En el archivo serverless.yml, dentro del evento HTTP, debes declarar el parámetro abriendo llaves en el path:

yaml http: method: get path: users/{id}

Con esto, el endpoint responderá a cualquier string que venga después de /users/.

Por qué aparece el error access denied al consultar DynamoDB

Después de desplegar con sls deploy, es muy probable que tu primera petición devuelva un error. La forma correcta de diagnosticarlo es ir a CloudWatch, el servicio de AWS que centraliza los logs de cómputo. Lambda inyecta sus logs allí por defecto, agrupados en log groups y log streams.

Al revisar el detalle, verás un mensaje tipo access denied: el rol que asume la Lambda no tiene autorización para hacer queries a DynamoDB. Serverless Framework crea por defecto un rol con permisos mínimos, así que tú debes ampliarlos [09:15].

¿Qué es un rol en AWS? Es un conjunto de permisos asignado a una entidad, como una Lambda. Define qué servicios y acciones puede ejecutar esa entidad dentro de tu cuenta de AWS.

Cómo agregar permisos IAM desde serverless.yml

IAM es el servicio de AWS que gestiona permisos y roles. Dentro de serverless.yml puedes declarar un bloque iam con un role y dentro de él, una lista de statements. Cada statement lleva tres claves:

• Effect: usa Allow para conceder el permiso.
• Action: define qué se permite, por ejemplo dynamodb:* para todas las acciones.
• Resource: limita el permiso a un recurso específico mediante su ARN.

Usar dynamodb:* sin restringir el recurso sería demasiado holgado. Una Lambda con ese permiso podría borrar otras tablas. Por eso, copia el ARN exacto de tu tabla desde la consola de DynamoDB, en la sección de información adicional, y pégalo en Resource.

Cómo verificar que el GET funciona en producción

Tras un nuevo serverless deploy, la actualización del rol queda activa. Si consultas la URL con un ID que no existe, recibirás una lista vacía sin errores, lo cual confirma que la conexión funciona.

Para probar de verdad, agrega manualmente un elemento en la consola de DynamoDB con un atributo id igual a 1 y otro atributo como name. Ejecuta un scan desde la consola para confirmar que el registro existe y luego vuelve a tu endpoint:

• La respuesta trae el elemento con su nombre.
• El campo count muestra 1.
• El scanned count también marca 1.

¿Qué es un scan en DynamoDB? Es una operación que recorre todos los elementos de una tabla y los devuelve. Sirve para inspeccionar el contenido completo, aunque no es la forma más eficiente para consultas en producción.

Un detalle para mejorar: actualmente la función devuelve una lista, pero como el id es único, tiene más sentido retornar un solo objeto de usuario. Refactorizar esa lógica es un buen ejercicio antes de avanzar al método POST para crear usuarios desde la API. ¿Te animas a hacer ese refactor y compartir tu solución en los comentarios?