Desarrollo serverless con AWS Lambda - Diseño de funciones y uso de event sources

Explicamos el diseño de funciones de Lambda, el mapeo de event sources, las contramedidas para cold start y el uso de Powertools.

Unos 9 min de lecturaÚltima actualización: 2026-10-28

Descripción general de Lambda

Lambda es un servicio de computación serverless que ejecuta código sin gestión de servidores. Ofrece runtimes gestionados para Node.js, Python, Java, .NET y Ruby, mientras que lenguajes como Go y Rust se ejecutan en el runtime que solo incluye el SO (lista oficial de runtimes de AWS, a fecha de septiembre de 2026). El tiempo máximo de ejecución es de 15 minutos (900 segundos) y la memoria máxima es de 10GB (10,240 MB), ambos según la documentación oficial de AWS a fecha de septiembre de 2026. Con facturación por consumo basada en el número de solicitudes y el tiempo de ejecución (GB-segundos), incluye una capa gratuita mensual de 1 millón de solicitudes y 400,000 GB-segundos (página oficial de precios de AWS Lambda, a fecha de septiembre de 2026).

Diseño de funciones y cold start

Separe la función en el handler (procesamiento de eventos) y el código de inicialización (creación de clientes SDK, carga de configuración). El código de inicialización solo se ejecuta durante el cold start, y en los warm starts solo se ejecuta el handler. Provisioned Concurrency pre-inicializa un número especificado de entornos de ejecución, eliminando los cold starts. Úselo cuando los requisitos de latencia de la API sean estrictos. Lambda Powertools es una biblioteca para implementar de forma sencilla, con decoradores o middleware, las mejores prácticas de logging estructurado, tracing de X-Ray y métricas de CloudWatch.

Patrones de arquitectura en la práctica

Al operar el desarrollo serverless con AWS Lambda en entornos de producción, los patrones de arquitectura que combinan múltiples servicios son más importantes que el uso individual. Como configuración típica, existe el patrón de colocar API Gateway al frente y encargarle la autenticación, la autorización y el throttling. En el backend, la combinación con DynamoDB o Aurora Serverless aporta la persistencia de datos, y el procesamiento asíncrono a través de SQS o EventBridge asegura la capacidad de procesamiento. En la gestión de errores, es imprescindible un mecanismo en el que una Dead Letter Queue (DLQ) configurada captura los eventos cuyo procesamiento falló y CloudWatch Alarms detecta las anomalías. Por el lado de los costos, si el uso es estable y previsible, puede reducir los costos aplicando Compute Savings Plans al uso de Lambda (el descuento que AWS indicó en su blog oficial de septiembre de 2021 es de hasta un 17%; el descuento vigente puede consultarse en la página oficial de Savings Plans de AWS). Para estructurar los logs, introduzca Lambda Powertools y combine el seguimiento de solicitudes mediante correlation ID con la visualización de la latencia entre servicios mediante X-Ray; así podrá identificar con rapidez la causa cuando ocurra un fallo.

Optimización de costos y ajuste de rendimiento

El primer paso en la optimización de costos es la optimización de la configuración de memoria. En el caso de Lambda, aumentar la memoria también asigna proporcionalmente más CPU, por lo que hay casos donde el tiempo de procesamiento se reduce y el costo total disminuye. Con la herramienta AWS Lambda Power Tuning, puede medir automáticamente el tiempo de ejecución y el costo para cada configuración de memoria e identificar el valor óptimo. Considere Provisioned Concurrency en casos exigentes, como cuando el requisito de latencia de la API es de 100 ms o menos en P99. Sin embargo, como genera cargos incluso mientras está en espera, analice los patrones de tráfico y combínelo con Application Auto Scaling para configurar el aumento y la disminución de Provisioned Concurrency según la franja horaria. Al elegir el procesador Graviton2 basado en ARM (arquitectura arm64), puede esperar una mejora de la relación precio-rendimiento de hasta un 34% en comparación con x86 (el precio por tiempo de ejecución es un 20% más bajo y el rendimiento mejora hasta un 19%, según las cifras que AWS publicó en su blog oficial en septiembre de 2021; la diferencia de precio del 20% es la misma en los precios unitarios de la página oficial de precios de AWS a fecha de septiembre de 2026). Al migrar funciones existentes a arm64, es necesario verificar de antemano la compatibilidad de las bibliotecas dependientes, incluidas las que contienen binarios nativos.

Fuentes de eventos e integración

Lambda arranca en respuesta a diversos eventos. Existen invocaciones que responden de forma síncrona a las solicitudes de la API, invocaciones asíncronas que encargan el procesamiento sin esperar el resultado e invocaciones de tipo sondeo que extraen mensajes de colas o streams y los procesan. Puede integrarse con fuentes muy diversas, como la colocación de archivos en S3, los cambios en bases de datos, las programaciones y la llegada de mensajes. Como cada una difiere en el comportamiento de los reintentos y en el tratamiento de los errores, úselas comprendiendo sus características. Diseñar qué eventos recibir y cómo hacerlo es el punto de partida que determina la configuración de una arquitectura serverless.

Concurrencia y escalado

Cuando aumentan las solicitudes, Lambda incrementa automáticamente los entornos de ejecución y las procesa en paralelo. Esta concurrencia tiene un límite y, cuando un aumento repentino lo alcanza, las solicitudes pueden limitarse. Para las funciones importantes, puede reservar concurrencia y asegurarla, de modo que no les afecten otras funciones. Si desea evitar los cold starts, utilice un mecanismo que mantenga calientes de antemano los entornos de ejecución. También es importante limitar la concurrencia para proteger de una sobrecarga a las bases de datos posteriores y otros recursos. Un diseño que comprenda el comportamiento del escalado y tenga en cuenta el límite y la capacidad de procesamiento de los sistemas posteriores conduce a una operación estable.

Observabilidad y gestión de errores

En serverless, como el procesamiento está distribuido, garantizar la observabilidad es la clave de la operación. Registre los logs de ejecución de cada función y siga con trazas distribuidas por qué servicios pasó una solicitud y de qué manera. Así podrá identificar las causas de los fallos y los puntos donde ocurren retrasos. En la gestión de errores, prepare una dead-letter queue que aparte los eventos que fallaron en invocaciones asíncronas y evite así perder eventos. Es importante diseñar el procesamiento para que sea idempotente, de modo que no surjan problemas aunque los reintentos ejecuten el mismo procesamiento en múltiples ocasiones. Combine los logs, las trazas y la separación de los errores para poder operar con fiabilidad un procesamiento distribuido difícil de ver.

Seguridad y operaciones

Asigne un rol de ejecución a cada función de Lambda y permita, con el mínimo privilegio, solo las operaciones que esa función necesita. Evite los permisos excesivos, porque amplían el daño si la función resulta comprometida. Ejecute dentro de una VPC las funciones que acceden a recursos privados, como bases de datos, y controle la red. No escriba las credenciales ni las claves de API directamente en el código ni en las variables de entorno; obténgalas con seguridad desde un servicio dedicado. Cifre las variables de entorno para protegerlas. Si aplica a fondo estos diseños de seguridad, podrá crear aplicaciones robustas y protegidas mientras disfruta de la sencillez de serverless.

Resumen

Lambda es un servicio de computación serverless basado en eventos que logra facturación por consumo y cero gestión. Provisioned Concurrency elimina los cold starts y SnapStart reduce el tiempo de inicio de las funciones de Java, Python y .NET (runtimes compatibles según la documentación oficial de AWS, a fecha de septiembre de 2026). Gracias a la integración con 220 o más servicios de AWS (página oficial del producto de AWS, a fecha de septiembre de 2026), procesa automáticamente eventos de API Gateway, S3, DynamoDB Streams, SQS y otros.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Patrones de diseño de Amazon API Gateway - Criterios de selección entre REST API y HTTP APIClarificamos los criterios de selección entre HTTP API y REST API, y presentamos patrones de autenticación con Cognito y Lambda Authorizer, así como métodos prácticos de diseño de throttling.Patrones de integración de Amazon EFS con Lambda / ECS - Uso de sistemas de archivos compartidos en serverlessSe monta EFS en funciones Lambda y tareas de ECS para aprovechar un sistema de archivos compartido. Se presentan el diseño de los puntos de acceso y la optimización del rendimiento.Por qué el límite de 15 minutos de Lambda es de 15 minutos - La racionalidad oculta en las restricciones de diseño serverlessSe explican los valores actuales de los diversos límites serverless, como el tiempo máximo de ejecución de 15 minutos de Lambda, el límite de memoria de 10 GB y el payload de 6 MB, y cómo afectan al diseño de la arquitectura. El análisis parte de la perspectiva de la operación multi-tenant y del ciclo de vida del entorno de ejecución.La verdad sobre el cold start de Lambda y cómo elegir entre 3 estrategias de optimizaciónExplicamos el mecanismo por el cual ocurre el cold start de Lambda desde el ciclo de vida de Firecracker MicroVM, y comparamos técnicas de optimización en 3 ejes: SnapStart, Provisioned Concurrency y diseño de funciones, en términos de costo y restricciones.Detrás de las 1.000 ejecuciones simultáneas de Lambda - Cómo funcionan el warm pool de Firecracker y el worker managerSe explica el mecanismo con el que Lambda gestiona las micro VM dentro del límite predeterminado de 1.000 ejecuciones simultáneas. También se presentan la estrategia de reutilización mediante el warm pool, las decisiones de ubicación del worker manager y las optimizaciones internas que reducen la tasa de cold start.Construcción de APIs serverless - Infraestructura API escalable con Amazon API GatewayExplicamos cómo construir APIs serverless utilizando Amazon API Gateway y Lambda.Diseño de máquinas de estado - Orquestación de flujos de trabajo con Step FunctionsSe explican los métodos de diseño de máquinas de estado que aprovechan AWS Step Functions y se presentan los flujos de trabajo visuales, la gestión de errores y la orquestación de flujos de trabajo mediante la integración con Lambda.Orquestación de flujos de trabajo diseñada con AWS Step Functions - Cómo elegir entre Standard y ExpressSe aclaran los criterios para elegir entre los flujos de trabajo Standard y los flujos de trabajo Express, y se presentan la gestión de errores declarativa con Retry/Catch y el procesamiento en paralelo a gran escala con el mapa distribuido.