Concurrencia, limitación y concurrencia reservada

Lambda escala ejecutando múltiples ejecuciones simultáneas de su función: una por cada evento simultáneo. Cuando llegan 100 solicitudes al mismo tiempo, Lambda ejecuta 100 instancias paralelas de su función. AWS administra automáticamente la infraestructura subyacente. El límite de simultaneidad a nivel de cuenta es de 1.000 ejecuciones simultáneas por región de forma predeterminada (es un límite flexible que puede aumentarse mediante una solicitud de cuota de servicio).

La simultaneidad se calcula así: Simultaneidad = Solicitudes por segundo × Duración media en segundos. Si su función procesa 500 solicitudes por segundo y cada una tarda 0,2 segundos, necesita 100 ejecuciones simultáneas. Comprender esta fórmula le ayuda a predecir si los límites de su cuenta son suficientes y si necesita solicitar aumentos de cuota antes de un evento de mucho tráfico.

Cuando Lambda recibe más solicitudes de las que permite su límite de simultaneidad, aplica limitación de velocidad a las solicitudes excedentes. En las invocaciones síncronas (por ejemplo, API Gateway), las solicitudes limitadas reciben inmediatamente un error 429 TooManyRequestsException que debe gestionar el llamador. En las invocaciones asíncronas (por ejemplo, eventos de S3), Lambda pone los eventos en cola y vuelve a intentarlo durante un máximo de 6 horas antes de enviarlos a una cola de mensajes no entregados.

La simultaneidad reservada garantiza un número específico de ejecuciones simultáneas para una función determinada, reservándolas del conjunto de recursos de la cuenta. Tiene dos objetivos: (1) garantizar capacidad: la función siempre tendrá disponibles ese número de ejecuciones, aunque otras funciones estén consumiendo la cuota de la cuenta; (2) limitar la simultaneidad: la función nunca puede superar la cantidad reservada, lo que protege las dependencias posteriores frente a una sobrecarga.

Un escenario clave del examen: una función de Lambda escribe en una base de datos de RDS que tiene un límite de 50 conexiones. Sin controles de simultaneidad, Lambda podría escalar hasta cientos de ejecuciones simultáneas y agotar todas las conexiones de la base de datos, provocando errores en cada función. Establecer una simultaneidad reservada de 40 garantiza que Lambda nunca supere las 40 conexiones simultáneas a la base de datos, protegiendo la instancia de RDS. Este es un patrón fundamental para cualquier función de Lambda que llame a un servicio con un límite de conexiones.

La simultaneidad aprovisionada preinicializa un número especificado de entornos de ejecución de Lambda para que estén listos para responder inmediatamente sin un arranque en frío. Esto es fundamental para las API sensibles a la latencia, en las que incluso un arranque en frío de 100 ms resulta inaceptable. Se paga una tarifa por hora por la simultaneidad aprovisionada incluso cuando esos entornos están inactivos, por lo que debe combinarla con Auto Scaling para ajustar los niveles aprovisionados según los patrones de tráfico previstos.

A menudo se confunden, pero tienen objetivos diferentes. La simultaneidad reservada limita y garantiza la asignación de capacidad del conjunto de recursos de la cuenta; NO elimina los arranques en frío. La simultaneidad aprovisionada mantiene los entornos de ejecución precalentados para eliminar los arranques en frío; NO impide que otras funciones utilicen el mismo conjunto de recursos. Use la simultaneidad reservada para limitar el rendimiento; use la simultaneidad aprovisionada para mejorar la latencia. Ambas pueden utilizarse juntas en la misma función.

Lambda no escala hasta alcanzar la simultaneidad máxima de forma instantánea. Existe un límite de ráfaga a nivel de cuenta (tasa de escalado inicial) que varía según la región: normalmente, una ráfaga inicial de 3.000 ejecuciones, seguida de 500 ejecuciones adicionales por minuto hasta alcanzar el límite. Para aplicaciones que anticipan picos masivos repentinos (tráfico viral, ventas relámpago), use la simultaneidad aprovisionada para precalentar suficientes entornos y evitar que el límite de ráfaga provoque limitaciones durante el aumento inicial.

Supervise la simultaneidad de Lambda con estas métricas clave de CloudWatch:

• ConcurrentExecutions: número actual de instancias en ejecución
• Throttles: cantidad de invocaciones limitadas (debería ser cero en un sistema en buen estado)
• UnreservedConcurrentExecutions: conjunto de recursos no reservados a nivel de cuenta
• ProvisionedConcurrencyUtilization: cantidad de capacidad aprovisionada que está en uso

Configure alarmas en Throttles para recibir una notificación antes de que la limitación afecte a los usuarios finales.

Al diseñar sistemas que invocan Lambda de forma síncrona (API Gateway, llamadas directas mediante el SDK), implemente un retroceso exponencial con jitter en el llamador. Los SDK de AWS incluyen lógica de reintento integrada, pero para Lambda detrás de API Gateway debe gestionar las respuestas 429 en la aplicación cliente. En el caso de Lambda activado por SQS, el propio servicio SQS gestiona los reintentos; establezca adecuadamente Maximum Receives en la cola de origen y configure una DLQ para los reintentos agotados.

Para Kinesis Data Streams y DynamoDB Streams, la simultaneidad de Lambda está limitada por el número de shards (Kinesis) o particiones (DynamoDB). Cada shard o partición se procesa mediante exactamente una ejecución simultánea de Lambda. Si tiene 10 shards de Kinesis, Lambda ejecuta hasta 10 ejecuciones simultáneas para ese desencadenador. Esto significa que los problemas de limitación con desencadenadores basados en flujos suelen resolverse aumentando el número de shards en lugar de elevar los límites de simultaneidad.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que la simultaneidad reservada garantiza y limita las ejecuciones simultáneas de una función para proteger los servicios posteriores y garantizar la disponibilidad; la simultaneidad aprovisionada preinicializa entornos para eliminar los arranques en frío en cargas de trabajo sensibles a la latencia; y la limitación de velocidad se manifiesta como errores 429 en las invocaciones síncronas y como reintentos en cola en las asíncronas, y se supervisa mediante la métrica Throttles de CloudWatch. A continuación exploraremos Lambda Layers y los paquetes de implementación para gestionar dependencias grandes.