# Comprender el escalado de la función de Lambda
La **simultaneidad** representa la cantidad de solicitudes que la función AWS Lambda puede tolerar al mismo tiempo. Para cada solicitud simultánea, Lambda aprovisiona una instancia independiente del entorno de ejecución. A medida que las funciones reciben más solicitudes, Lambda se encarga automáticamente de escalar la cantidad de entornos de ejecución hasta que alcance el límite de simultaneidad de la cuenta. De forma predeterminada, Lambda proporciona a su cuenta un límite de simultaneidad total de 1000 ejecuciones simultáneas en todas las funciones de una Región de AWS. Para satisfacer las necesidades específicas de la cuenta, puede [solicitar un aumento de la cuota](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/) y configurar los controles de simultaneidad en la función para que las funciones críticas no sufran limitaciones.
En este tema se explican los conceptos de simultaneidad y el escalado de funciones en Lambda. Al final de este tema, podrá entender cómo calcular la simultaneidad, visualizar las dos opciones principales de control de simultaneidad (reservadas y aprovisionadas), estimar la configuración de control de simultaneidad adecuada y ver las métricas para una mayor optimización.
**Topics**
+ [
## Cómo comprender y visualizar la simultaneidad
](#understanding-concurrency)
+ [
## Calcular la simultaneidad de una función
](#calculating-concurrency)
+ [
## Comprender la simultaneidad reservada y simultaneidad aprovisionada
](#reserved-and-provisioned)
+ [
## Descripción de la simultaneidad y las solicitudes por segundo
](#concurrency-vs-requests-per-second)
+ [
## Cuotas de simultaneidad
](#concurrency-quotas)
+ [
# Configurar la simultaneidad reservada para una función
](configuration-concurrency.md)
+ [
# Configuración de simultaneidad aprovisionada para una función
](provisioned-concurrency.md)
+ [
# Comportamiento de escalado de Lambda
](scaling-behavior.md)
+ [
# Monitoreo de la simultaneidad
](monitoring-concurrency.md)
## Cómo comprender y visualizar la simultaneidad
Lambda invoca la función en un [entorno de ejecución](lambda-runtime-environment.md) seguro y aislado. Para administrar una solicitud, Lambda debe inicializar primero un entorno de ejecución (la [fase Init](lambda-runtime-environment.md#runtimes-lifecycle-ib)), antes de usarlo para invocar la función (la [fase Invoke](lambda-runtime-environment.md#runtimes-lifecycle-invoke)):
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-1-environment.png)
**nota**
Las duraciones reales de inicio e invocación pueden variar en función de muchos factores, como el tiempo de ejecución que elija y el código de la función de Lambda. El diagrama anterior no pretende representar las proporciones exactas de las duraciones de las fases de inicio e invocación.
El diagrama anterior utiliza un rectángulo para representar un único entorno de ejecución. Cuando la función recibe la primera solicitud (representada por un círculo amarillo con la etiqueta `1`), Lambda crea un nuevo entorno de ejecución y ejecuta el código fuera del controlador principal durante la fase Init. A continuación, Lambda ejecuta el código del controlador principal de la función durante la fase Invoke. Durante todo este proceso, este entorno de ejecución está ocupado y no puede procesar otras solicitudes.
Cuando Lambda termina de procesar la primera solicitud, este entorno de ejecución puede procesar solicitudes adicionales para la misma función. Para las solicitudes posteriores, Lambda no necesita volver a inicializar el entorno.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-2-two-requests.png)
En el diagrama anterior, Lambda reutiliza el entorno de ejecución para administrar la segunda solicitud (representada por el círculo amarillo con la etiqueta `2`).
Hasta ahora, nos hemos centrado en una sola instancia del entorno de ejecución (es decir, una simultaneidad de 1). En la práctica, es posible que Lambda necesite aprovisionar varias instancias del entorno de ejecución en paralelo para administrar todas las solicitudes entrantes. Cuando la función recibe una nueva solicitud, puede ocurrir una de estas dos cosas:
+ Si una instancia de entorno de ejecución preinicializada está disponible, Lambda la utiliza para procesar la solicitud.
+ De lo contrario, Lambda crea una nueva instancia del entorno de ejecución para procesar la solicitud.
Por ejemplo, analicemos lo que ocurre cuando la función recibe 10 solicitudes:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-3-ten-requests.png)
En el diagrama anterior, cada plano horizontal representa una única instancia del entorno de ejecución (etiquetada de la `A` a `F`). Así es como Lambda administra cada solicitud:
| Solicitud | Comportamiento de Lambda | Razonamiento |
| --- | --- | --- |
| 1 | Aprovisiona el nuevo entorno **A**. | Esta es la primera solicitud; no hay instancias de entorno de ejecución disponibles. |
| 2 | Aprovisiona el nuevo entorno **B**. | La instancia **A** del entorno de ejecución existente está ocupada. |
| 3 | Aprovisiona el nuevo entorno **C**. | Las instancias **A** y **B** del entorno de ejecución existentes están ocupadas. |
| 4 | Aprovisiona el nuevo entorno **D**. | Las instancias **A**, **B** y **C** del entorno de ejecución existentes están todas ocupadas. |
| 5 | Aprovisiona el nuevo entorno **E**. | Las instancias **A**, **B**, **C** y **D** del entorno de ejecución existentes están todas ocupadas. |
| 6 | Reutiliza el entorno **A**. | La instancia **A** del entorno de ejecución terminó de procesar la solicitud **1** y ya está disponible. |
| 7 | Reutiliza el entorno **B**. | La instancia **B** del entorno de ejecución terminó de procesar la solicitud **2** y ya está disponible. |
| 8 | Reutiliza el entorno **C**. | La instancia **C** del entorno de ejecución terminó de procesar la solicitud **3** y ya está disponible. |
| 9 | Aprovisiona el nuevo entorno **F**. | Las instancias **A**, **B**, **C**, **D** y **E** del entorno de ejecución existentes están todas ocupadas. |
| 10 | Reutiliza el entorno **D**. | La instancia **D** del entorno de ejecución terminó de procesar la solicitud **4** y ya está disponible. |
Como respuesta, a medida que la función recibe más solicitudes simultáneas, Lambda escala verticalmente la cantidad de instancias del entorno de ejecución. La siguiente animación registra la cantidad de solicitudes simultáneas a lo largo del tiempo:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-4-animation.gif)
Cuando se congela la animación anterior en seis puntos distintos en el tiempo, se obtiene el siguiente diagrama:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-5-animation-summary.png)
En el diagrama anterior, podemos dibujar una línea vertical en cualquier momento y contar la cantidad de entornos que se cruzan con esta línea. Esto nos da la cantidad de solicitudes simultáneas en ese momento. Por ejemplo, en el momento `t1`, existen tres entornos activos que atienden tres solicitudes simultáneas. La cantidad máxima de solicitudes simultáneas de esta simulación se produce en el momento `t4`, cuando hay seis entornos activos que atienden seis solicitudes simultáneas.
En resumen, la simultaneidad de la función es la cantidad de solicitudes simultáneas que se administran a la vez. En respuesta a un aumento en la simultaneidad de la función, Lambda aprovisiona más instancias del entorno de ejecución para satisfacer la demanda de solicitudes.
## Calcular la simultaneidad de una función
En general, la simultaneidad de un sistema es la capacidad de procesar más de una tarea simultáneamente. En Lambda, la simultaneidad es la cantidad de solicitudes en vuelo que la función administra al mismo tiempo. Una forma rápida y práctica de medir la simultaneidad de una función de Lambda consiste en utilizar la siguiente fórmula:
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
**La simultaneidad se diferencia de las solicitudes por segundo.** Por ejemplo, supongamos que la función recibe una media de 100 solicitudes por segundo. Si la duración media de las solicitudes es de un segundo, es cierto que la simultaneidad también es de 100:
```
Concurrency = (100 requests/second) * (1 second/request) = 100
```
Sin embargo, si la duración media de la solicitud es de 500 ms, entonces la simultaneidad es de 50:
```
Concurrency = (100 requests/second) * (0.5 second/request) = 50
```
¿Qué significa en la práctica una simultaneidad de 50? Si la duración media de las solicitudes es de 500 ms, entonces puede pensar que una instancia de la función puede administrar dos solicitudes por segundo. Luego, se necesitan 50 instancias de la función para administrar una carga de 100 solicitudes por segundo. Una simultaneidad de 50 significa que Lambda debe aprovisionar 50 instancias del entorno de ejecución para administrar esta carga de trabajo de manera eficiente sin ningún tipo de limitación. A continuación, se explica cómo expresar esto en forma de ecuación:
```
Concurrency = (100 requests/second) / (2 requests/second) = 50
```
Si la función recibe el doble de solicitudes (200 solicitudes por segundo), pero solo necesita la mitad del tiempo para procesar cada solicitud (250 ms), entonces la simultaneidad sigue siendo de 50:
```
Concurrency = (200 requests/second) * (0.25 second/request) = 50
```
### Evaluemos su comprensión de la simultaneidad
Supongamos que tiene una función que tarda, en promedio, 200 ms en ejecutarse. Durante la carga máxima, nota que hay 5000 solicitudes por segundo. ¿Cuál es la simultaneidad de la función durante la carga máxima?
#### Respuesta
La duración promedio de la función es de 200 ms o 0,2 segundos. Con la fórmula de simultaneidad, puede introducir los números para obtener una simultaneidad de 1000:
```
Concurrency = (5,000 requests/second) * (0.2 seconds/request) = 1,000
```
Como alternativa, una duración promedio de una función de 200 ms significa que la función puede procesar 5 solicitudes por segundo. Para administrar la carga de trabajo de 5000 solicitudes por segundo, necesita 1000 instancias de entorno de ejecución. Por lo tanto, la simultaneidad es de 1000:
```
Concurrency = (5,000 requests/second) / (5 requests/second) = 1,000
```
## Comprender la simultaneidad reservada y simultaneidad aprovisionada
De forma predeterminada, la cuenta tiene un límite de simultaneidad de 1000 ejecuciones simultáneas en todas las funciones de una región. Las funciones comparten este conjunto de 1000 simultaneidades bajo demanda. Sus funciones experimentan limitación (es decir, comienzan a descartar solicitudes) si se queda sin concurrencia disponible.
Es posible que algunas de las funciones sean más importantes que otras. Como resultado, es posible que desee configurar los ajustes de simultaneidad para garantizar que las funciones críticas obtengan la simultaneidad que necesitan. Existen dos tipos de controles de simultaneidad disponibles: simultaneidad reservada y simultaneidad aprovisionada.
+ Utilice la **simultaneidad reservada** para establecer el número máximo y mínimo de instancias simultáneas y así reservar una parte de la simultaneidad de su cuenta para una función. Esto resulta útil si no desea que otras funciones ocupen toda la simultaneidad no reservada disponible. Cuando una función ha reservado simultaneidad, ninguna otra función puede usarla.
+ Utilice la **simultaneidad aprovisionada** para preinicializar varias instancias de entorno para una función. Esto es útil para reducir las latencias de arranque en frío.
### Simultaneidad reservada
Si desea garantizar que haya una cierta cantidad de simultaneidad disponible para la función en cualquier momento, utilice la simultaneidad reservada.
La simultaneidad reservada establece la cantidad máxima y mínima de instancias simultáneas que desea asignar a la función. Cuando dedica la simultaneidad reservada a una función, ninguna otra función puede usarla. En otras palabras, la configuración de la simultaneidad reservada puede afectar al grupo de simultaneidad que está disponible para otras funciones. Las funciones que no tienen simultaneidad reservada comparten el conjunto restante de simultaneidad no reservada.
La configuración de la simultaneidad reservada cuenta para el límite general de simultaneidad de la cuenta. No hay ningún cargo por configurar la concurrencia reservada para una función.
Para entender mejor la simultaneidad reservada, tenga en cuenta el siguiente diagrama:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-6-reserved-concurrency.png)
En este diagrama, el límite de simultaneidad de la cuenta para todas las funciones de esta región está en el límite predeterminado de 1000. Supongamos que tiene dos funciones críticas, la `function-blue` y la `function-orange`, que de forma rutinaria se espera que obtengan altos volúmenes de invocación. Decide asignar 400 unidades de simultaneidad reservada a la `function-blue` y 400 unidades de simultaneidad reservada a la `function-orange`. En este ejemplo, todas las demás funciones de la cuenta deben compartir las 200 unidades restantes de simultaneidad no reservada.
El diagrama tiene cinco puntos de interés:
+ En el momento `t1`, tanto la `function-orange` como la `function-blue` comienzan a recibir solicitudes. Cada función comienza a utilizar su parte asignada de las unidades de simultaneidad reservadas.
+ En el momento `t2`, la `function-orange` y la `function-blue` reciben cada vez más solicitudes. Al mismo tiempo, implementa otras funciones de Lambda, que comienzan a recibir solicitudes. No asigna la simultaneidad reservada a estas otras funciones. Estas empiezan a utilizar las 200 unidades restantes de simultaneidad no reservada.
+ En el momento `t3`, la `function-orange` alcanza la simultaneidad máxima de 400. Aunque hay simultaneidad no utilizada en otras partes de la cuenta, la `function-orange` no puede acceder a esta. La línea roja indica que la `function-orange` se está sufriendo limitaciones y Lambda podría anular las solicitudes.
+ En el momento `t4`, la `function-orange` comienza a recibir menos solicitudes y ya no tiene limitaciones. Sin embargo, las otras funciones experimentan un aumento en el tráfico y comienzan a sufrir limitaciones. Si bien hay simultaneidad no utilizada en otras partes de la cuenta, estas otras funciones no pueden acceder a esta. La línea roja indica que las demás funciones están sufriendo limitaciones.
+ En el momento `t5`, otras funciones comienzan a recibir menos solicitudes y ya no experimentan limitaciones.
En este ejemplo, observe que reservar la simultaneidad tiene los siguientes efectos:
+ **La función se puede escalar independientemente de otras funciones de la cuenta.** Todas las funciones de la cuenta en la misma región que no tienen simultaneidad reservada comparten el grupo de simultaneidad no reservada. Sin simultaneidad reservada, otras funciones pueden llegar a utilizar toda la simultaneidad disponible. Esto impide que las funciones críticas se escalen verticalmente cuando sea necesario.
+ **La función no se puede escalar horizontalmente de forma descontrolada.** La simultaneidad reservada limita a la simultaneidad máxima y mínima de la función. Esto significa que la función no puede usar la simultaneidad reservada para otras funciones ni la simultaneidad del grupo no reservado. Además, la simultaneidad reservada actúa tanto como límite inferior como superior: reserva la capacidad especificada exclusivamente para su función y, al mismo tiempo, evita que se escale más allá de ese límite. Puede reservar simultaneidad para evitar que la función utilice toda la simultaneidad disponible en la cuenta o que sobrecargue los recursos empleados posteriormente.
+ **Es posible que no pueda utilizar toda la simultaneidad disponible en la cuenta.** Reservar la simultaneidad cuenta para el límite de simultaneidad de la cuenta, pero esto también significa que otras funciones no pueden usar esa parte de la simultaneidad reservada. Si la función no consume toda la simultaneidad que reserva para esta, efectivamente está desperdiciando esa simultaneidad. Esto no es un problema, a menos que otras funciones de la cuenta puedan aprovechar la simultaneidad desperdiciada.
Para saber cómo administrar la configuración de la simultaneidad reservada para las funciones, consulte [Configurar la simultaneidad reservada para una función](configuration-concurrency.md).
### Simultaneidad aprovisionada
La simultaneidad reservada se utiliza para definir la cantidad máxima de entornos de ejecución reservados para una función de Lambda. Sin embargo, ninguno de estos entornos viene preinicializado. Como resultado, las invocaciones de la función pueden tardar más porque Lambda primero debe inicializar el nuevo entorno antes de poder usarlo para invocar la función. Cuando Lambda tiene que inicializar un nuevo entorno para llevar a cabo una invocación, esto se denomina [arranque en frío](lambda-runtime-environment.md#cold-start-latency). Para mitigar los arranques en frío, puede utilizar la simultaneidad aprovisionada.
La simultaneidad aprovisionada es la cantidad de entornos de ejecución preinicializados que desea asignar a la función. Si se establece la simultaneidad aprovisionada en una función, Lambda inicializa esa cantidad de entornos de ejecución para que estén preparados para responder a las solicitudes de la función.
**nota**
Utilizar la simultaneidad aprovisionada genera cargos en su cuenta. Si trabaja con los entornos de ejecución de Java 11 o Java 17, también puede utilizar Lambda SnapStart para mitigar los problemas de arranque en frío sin costo adicional. SnapStart utiliza instantáneas almacenadas en caché de su entorno de ejecución para mejorar de forma significativa el rendimiento de inicio. No puede utilizar SnapStart y la simultaneidad aprovisionada en la misma versión de la función. Para obtener más información sobre las características, las limitaciones y las regiones admitidas de SnapStart, consulte [Mejora del rendimiento de inicio con Lambda SnapStart](snapstart.md).
Cuando se utiliza la simultaneidad aprovisionada, Lambda sigue reciclando los entornos de ejecución en segundo plano. Por ejemplo, esto puede ocurrir [después de un error de invocación](lambda-runtime-environment.md#runtimes-lifecycle-invoke-with-errors). Sin embargo, Lambda se asegura, en todos los casos y en cualquier momento, de que la cantidad de entornos preinicializados sea igual al valor de la configuración de simultaneidad aprovisionada por la función. Es importante destacar que, incluso si utiliza la simultaneidad aprovisionada, puede seguir experimentando un retraso en el arranque en frío si Lambda tiene que restablecer el entorno de ejecución.
Por el contrario, al utilizar simultaneidad reservada, Lambda puede terminar por completo un entorno tras un periodo de inactividad. En el siguiente diagrama se demuestra esto, comparando el ciclo de vida de un único entorno de ejecución cuando se configura la función mediante la simultaneidad reservada, en contraposición a la simultaneidad aprovisionada.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-7-reserved-vs-provisioned.png)
El diagrama tiene cuatro puntos de interés:
| Time | Simultaneidad reservada | Simultaneidad aprovisionada |
| --- | --- | --- |
| t1 | No ocurre nada. | Lambda preinicializa una instancia del entorno de ejecución. |
| t2 | Se presenta la solicitud 1. Lambda debe inicializar una nueva instancia del entorno de ejecución. | Se presenta la solicitud 1. Lambda utiliza la instancia de entorno preinicializada. |
| t3 | Tras un tiempo de inactividad, Lambda termina la instancia del entorno activo. | No ocurre nada. |
| t4 | Se presenta la solicitud 2. Lambda debe inicializar una nueva instancia del entorno de ejecución. | Se presenta la solicitud 2. Lambda utiliza la instancia de entorno preinicializada. |
Para comprender mejor la simultaneidad aprovisionada, tenga en cuenta el siguiente diagrama:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-8-provisioned-concurrency.png)
En este diagrama, tiene un límite de simultaneidad de cuentas de 1000. Decide otorgar 400 unidades de simultaneidad aprovisionadas a la `function-orange`. Todas las funciones de la cuenta, *incluida* la `function-orange`, pueden usar las 600 unidades restantes de simultaneidad no reservadas.
El diagrama tiene cinco puntos de interés:
+ En el momento `t1`, la `function-orange` comienza a recibir solicitudes. Dado que Lambda ha preinicializado 400 instancias del entorno de ejecución, la `function-orange` está lista para la invocación inmediata.
+ En el momento `t2`, la `function-orange` alcanza las 400 solicitudes simultáneas. Como resultado, la `function-orange` agota la simultaneidad aprovisionada. Sin embargo, dado que todavía hay simultaneidad no reservada disponible, Lambda puede usarla para administrar solicitudes adicionales a la `function-orange` (sin limitaciones). Lambda debe crear nuevas instancias para atender estas solicitudes, y es posible que la función experimente latencias de arranque en frío.
+ En el momento `t3`, la `function-orange` vuelve a las 400 solicitudes simultáneas tras un breve aumento en el tráfico. Nuevamente, Lambda puede administrar todas las solicitudes sin latencias de arranque en frío.
+ En el momento `t4`, las funciones de la cuenta experimentan una ráfaga de tráfico. Esta ráfaga puede provenir de la `function-orange` o de cualquier otra función de la cuenta. Lambda utiliza la simultaneidad no reservada para administrar estas solicitudes.
+ En el momento `t5`, las funciones de la cuenta alcanzan el límite máximo de simultaneidad de 1000 y experimentan limitaciones.
En el ejemplo anterior se consideró solo la simultaneidad aprovisionada. En la práctica, puede configurar tanto la simultaneidad aprovisionada como la reservada en una función. Podría hacerlo si tuviera una función que gestione una carga constante de invocaciones durante los días de la semana, pero que detecte picos de tráfico de forma rutinaria durante los fines de semana. En este caso, puede utilizar la simultaneidad aprovisionada para establecer una cantidad básica de entornos para administrar las solicitudes durante los días de semana y utilizar la simultaneidad reservada para administrar los picos de los fines de semana. Tenga en cuenta el siguiente diagrama:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-9-reserved-and-provisioned.png)
En este diagrama, imagine que configura 200 unidades de simultaneidad aprovisionadas y 400 unidades de simultaneidad reservadas para la `function-orange`. Como configuró la simultaneidad reservada, la `function-orange` no puede usar ninguna de las 600 unidades de simultaneidad no reservadas.
Este diagrama tiene cinco puntos de interés:
+ En el momento `t1`, la `function-orange` comienza a recibir solicitudes. Dado que Lambda ha preinicializado 200 instancias del entorno de ejecución, la `function-orange` está lista para la invocación inmediata.
+ En el momento `t2`, la `function-orange` utiliza toda su simultaneidad aprovisionada. La `function-orange` puede seguir atendiendo solicitudes mediante la simultaneidad reservada, pero estas solicitudes pueden experimentar latencias de arranque en frío.
+ En el momento `t3`, la `function-orange` alcanza las 400 solicitudes simultáneas. Como resultado, la `function-orange` agota toda su simultaneidad reservada. Como la `function-orange` no puede utilizar la simultaneidad no reservada, las solicitudes comienzan a sufrir limitaciones.
+ En el momento `t4`, la `function-orange` comienza a recibir menos solicitudes y ya no experimenta limitaciones.
+ En el momento `t5`, la `function-orange` se reduce a 200 solicitudes simultáneas, por lo que todas las solicitudes pueden volver a utilizar la simultaneidad aprovisionada (es decir, sin latencias de arranque en frío).
Tanto la simultaneidad reservada como la aprovisionada se tienen en cuenta para el límite de simultaneidad de la cuenta y [las cuotas regionales](gettingstarted-limits.md). En otras palabras, la simultaneidad reservada y aprovisionada puede afectar al grupo de simultaneidad que está disponible para otras funciones. La configuración de la simultaneidad aprovisionada genera cargos para su Cuenta de AWS.
**nota**
Si el volumen de simultaneidad aprovisionada en las versiones y alias de una función se suma a la simultaneidad reservada de la función, entonces todas las invocaciones se ejecutan en la simultaneidad aprovisionada. Esta configuración también tiene el efecto de aplicar una limitación controlada a la versión sin publicar de la función (`$LATEST`), lo que impide que se ejecute. No puede asignar más concurrencia aprovisionada que la concurrencia reservada para una función.
Para administrar la configuración de la simultaneidad aprovisionada para las funciones, consulte [Configuración de simultaneidad aprovisionada para una función](provisioned-concurrency.md). Para automatizar el escalado de simultaneidad aprovisionada en función de un cronograma o la utilización de la aplicación, consulte [Uso de Application Auto Scaling para automatizar la administración de simultaneidad aprovisionada](provisioned-concurrency.md#managing-provisioned-concurency).
### Cómo asigna Lambda la simultaneidad aprovisionada
La simultaneidad aprovisionada no se pone en línea inmediatamente después de configurarla. Lambda comienza a asignar simultaneidad aprovisionada después de uno o dos minutos de preparación. Para cada función, Lambda puede aprovisionar hasta 6000 entornos de ejecución por minuto, independientemente de su Región de AWS. Es exactamente igual a la [tasa de escalado de simultaneidad](scaling-behavior.md#scaling-rate) de las funciones.
Cuando envíe una solicitud para asignar la simultaneidad aprovisionada, no podrá acceder a ninguno de esos entornos hasta que Lambda termine de asignarlos por completo. Por ejemplo, si solicita 5000 entornos de simultaneidad aprovisionada, ninguna de sus solicitudes puede utilizar la simultaneidad aprovisionada hasta que Lambda termine de asignar por completo los 5000 entornos de ejecución.
### Comparación de la simultaneidad reservada con la aprovisionada
En la siguiente tabla se resumen y se comparan la simultaneidad reservada y la aprovisionada.
| Topic | Simultaneidad reservada | Simultaneidad aprovisionada |
| --- | --- | --- |
| Definición | Cantidad máxima de instancias del entorno de ejecución para la función. | Cantidad fija de instancias del entorno de ejecución preaprovisionadas para la función. |
| Comportamiento de aprovisionamiento | Lambda aprovisiona nuevas instancias bajo demanda. | Lambda aprovisiona previamente las instancias (es decir, antes de que la función comience a recibir solicitudes). |
| Comportamiento de arranque en frío | Es posible la latencia de arranque en frío, ya que Lambda debe crear nuevas instancias bajo demanda. | La latencia de arranque en frío no es posible, ya que Lambda no necesita crear instancias bajo demanda. |
| Comportamiento de las limitaciones | La función experimenta limitaciones cuando se alcanza el límite de simultaneidad reservado. | Si la simultaneidad reservada no está configurada, la función utiliza la simultaneidad no reservada cuando se alcanza el límite de simultaneidad aprovisionado. Si se establece la simultaneidad reservada, la función experimenta limitaciones cuando se alcanza el límite de simultaneidad reservado. |
| El comportamiento predeterminado no está configurado | La función utiliza la simultaneidad no reservada disponible en la cuenta. | Lambda no preaprovisiona ninguna instancia. En su lugar, si la simultaneidad reservada no está configurada, la función utiliza la simultaneidad no reservada disponible en la cuenta. Si se configura la simultaneidad reservada, la función usa la simultaneidad reservada. |
| Precios | Sin cargo adicional. | Conlleva cargos adicionales. |
## Descripción de la simultaneidad y las solicitudes por segundo
Como se mencionó en la sección anterior, la simultaneidad se diferencia de las solicitudes por segundo. Esta es una distinción importante cuando se trabaja con funciones que tienen una duración promedio de solicitud inferior a 100 ms.
En todas las funciones de su cuenta, Lambda aplica un límite de solicitudes por segundo igual a 10 veces la simultaneidad de la cuenta. Por ejemplo, dado que el límite predeterminado de simultaneidad de la cuenta es de 1000, las funciones de su cuenta pueden gestionar un máximo de 10 000 solicitudes por segundo.
Por ejemplo, considere una función con una duración promedio de solicitud de 50 ms. Con 20 000 solicitudes por segundo, la simultaneidad de esta función es la siguiente:
```
Concurrency = (20,000 requests/second) * (0.05 second/request) = 1,000
```
Según este resultado, se podría esperar que el límite de simultaneidad de la cuenta de 1000 sea suficiente para gestionar esta carga. Sin embargo, debido al límite de 10 000 solicitudes por segundo, la función solo puede gestionar 10 000 solicitudes por segundo del total de 20 000. Esta función experimenta una limitación.
La lección es que debe tener en cuenta tanto la simultaneidad como las solicitudes por segundo al configurar los ajustes de simultaneidad de las funciones. En este caso, debe solicitar un aumento del límite de simultaneidad de la cuenta a 2000, ya que esto aumentaría el límite total de solicitudes por segundo a 20 000.
**nota**
En función de este límite de solicitudes por segundo, es incorrecto decir que cada entorno de ejecución de Lambda solo puede gestionar un máximo de 10 solicitudes por segundo. En lugar de observar la carga en cualquier entorno de ejecución individual, Lambda solo tiene en cuenta la simultaneidad general y las solicitudes totales por segundo al momento de calcular las cuotas.
### Ponga a prueba su comprensión de la simultaneidad (funciones de menos de 100 ms)
Supongamos que tiene una función que tarda, en promedio, 20 ms en ejecutarse. Durante la carga máxima, nota que hay 30 000 solicitudes por segundo. ¿Cuál es la simultaneidad de la función durante la carga máxima?
#### Respuesta
La duración promedio de la función es de 20 ms o 0,02 segundos. Con la fórmula de simultaneidad, puede introducir los números para obtener una simultaneidad de 600:
```
Concurrency = (30,000 requests/second) * (0.02 seconds/request) = 600
```
De forma predeterminada, el límite de simultaneidad de la cuenta de 1000 parece ser suficiente para gestionar esta carga. Sin embargo, el límite de 10 000 solicitudes por segundo no es suficiente para gestionar las 30 000 solicitudes entrantes por segundo. Para admitir por completo las 30 000 solicitudes, debe solicitar un aumento del límite de simultaneidad de la cuenta a 3000 o más.
El límite de solicitudes por segundo se aplica a todas las cuotas en Lambda que implican simultaneidad. En otras palabras, se aplica a las funciones sincrónicas bajo demanda, las funciones que utilizan la simultaneidad aprovisionada y [al comportamiento de escalado de la simultaneidad.](scaling-behavior.md) Por ejemplo, a continuación, se muestran algunos escenarios en los que debe considerar con detenimiento sus límites de simultaneidad y de solicitudes por segundo:
+ Una función que utilice la simultaneidad bajo demanda puede experimentar un aumento de ráfaga de simultaneidad de 500 cada 10 segundos o de 5000 solicitudes por segundo cada 10 segundos, lo que ocurra primero.
+ Supongamos que tiene una función que tiene una asignación de simultaneidad aprovisionada de 10. Esta función se extiende a la simultaneidad bajo demanda después de una simultaneidad de 10 o de 100 solicitudes por segundo, lo que ocurra primero.
## Cuotas de simultaneidad
Lambda establece cuotas para la cantidad total de simultaneidad que puede utilizar en todas las funciones de una región. Estas cuotas existen en dos niveles:
+ **A nivel de cuenta**, de forma predeterminada, las funciones pueden tener hasta 1000 unidades de simultaneidad. Para solicitar un aumento de cuota, consulte [Solicitud de aumento de cuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) en la *Guía del usuario de Service Quotas*.
+ **A nivel de función**, de forma predeterminada, puede reservar hasta 900 unidades de simultaneidad en todas las funciones de forma predeterminada. Independientemente del límite total de simultaneidad de la cuenta, Lambda siempre reserva 100 unidades de simultaneidad para las funciones que no reserven explícitamente la simultaneidad. Por ejemplo, si aumentó el límite de simultaneidad de la cuenta a 2000, entonces puede reservar hasta 1900 unidades de simultaneidad a nivel de función.
+ Tanto a nivel de la cuenta como de la función, Lambda también impone un límite de solicitudes por segundo igual a 10 veces la cuota de simultaneidad correspondiente. Por ejemplo, esto se aplica a la simultaneidad a nivel de la cuenta, a las funciones que utilizan la simultaneidad bajo demanda, a las funciones que utilizan la simultaneidad aprovisionada y [al comportamiento de escalado de la simultaneidad](scaling-behavior.md). Para obtener más información, consulte [Descripción de la simultaneidad y las solicitudes por segundo](#concurrency-vs-requests-per-second).
Para comprobar la cuota de simultaneidad actual a nivel de cuenta, utilice la AWS Command Line Interface (AWS CLI) para ejecutar el siguiente comando:
```
aws lambda get-account-settings
```
Debería ver una salida con un aspecto similar al siguiente:
```
{
"AccountLimit": {
"TotalCodeSize": 80530636800,
"CodeSizeUnzipped": 262144000,
"CodeSizeZipped": 52428800,
"ConcurrentExecutions": 1000,
"UnreservedConcurrentExecutions": 900
},
"AccountUsage": {
"TotalCodeSize": 410759889,
"FunctionCount": 8
}
}
```
`ConcurrentExecutions` es la cuota total de simultaneidad a nivel de cuenta. `UnreservedConcurrentExecutions` es la cantidad de simultaneidad reservada que aún puede asignar a sus funciones.
A medida que una función recibe más solicitudes, Lambda escala de forma automática la cantidad de entornos de ejecución para gestionar estas solicitudes hasta que su cuenta alcance la cuota de simultaneidad. Sin embargo, para protegerse contra el exceso de escalado en respuesta a ráfagas repentinas de tráfico, Lambda limita la rapidez con la que sus funciones pueden escalar. Esta **tasa de escalado de simultaneidad** es la tasa máxima a la que las funciones de su cuenta pueden escalar en respuesta a un aumento de las solicitudes. (Es decir, la rapidez con la que Lambda puede crear nuevos entornos de ejecución). La tasa de escalado de simultaneidad difiere del límite de simultaneidad de la cuenta, que es la cantidad total de simultaneidad disponible para sus funciones.
**En cada Región de AWS y para cada función, su tasa de escalado de simultaneidad es de 1000 instancias del entorno de ejecución cada 10 segundos (o 10 000 solicitudes por segundo cada 10 segundos).** En otras palabras, cada 10 segundos, Lambda puede asignar como máximo 1000 instancias de entorno de ejecución adicionales o admitir 10 000 solicitudes por segundo adicionales a cada una de sus funciones.
Por lo general, no debe preocuparse por esta limitación. La tasa de escalado de Lambda es suficiente para la mayoría de los casos de uso.
Es importante destacar que la tasa de escalado de simultaneidad es un límite de función. Esto significa que cada función de su cuenta puede escalar independientemente de otras funciones.
Para obtener más información acerca de comportamientos de escalado, consulte [Comportamiento de escalado de Lambda](scaling-behavior.md).
# Configurar la simultaneidad reservada para una función
En Lambda, la [simultaneidad](lambda-concurrency.md) es la cantidad de solicitudes en tránsito que la función administra en la actualidad. Hay dos tipos de controles de concurrencia disponibles:
+ Simultaneidad reservada: representa la cantidad máxima y mínima de instancias simultáneas asignadas a la función. Cuando una función ha reservado simultaneidad, ninguna otra función puede usarla. La simultaneidad reservada es útil para garantizar que las funciones más importantes siempre tengan suficiente simultaneidad para manejar las solicitudes entrantes. Además, la simultaneidad reservada se puede utilizar para limitar la simultaneidad y evitar la sobrecarga de los recursos posteriores, como las conexiones de bases de datos. La simultaneidad reservada actúa como límite inferior y superior: reserva la capacidad especificada exclusivamente para su función y, al mismo tiempo, impide que escale más allá de ese límite. No hay ningún cargo adicional por configurar la concurrencia reservada para una función.
+ Simultaneidad aprovisionada: es la cantidad de entornos de ejecución preinicializados asignados a la función. Estos entornos de ejecución están listos para responder de forma inmediata a las solicitudes de funciones entrantes. La simultaneidad aprovisionada es útil para reducir las latencias de arranque en frío de las funciones y está diseñada para que las funciones estén disponibles con tiempos de respuesta de decenas de milisegundos. Por lo general, las cargas de trabajo interactivas son las que más se benefician de esta característica. Se trata de aplicaciones en las que los usuarios inician solicitudes, como las aplicaciones web y móviles y son las más sensibles a la latencia. Las cargas de trabajo asíncronas, como las canalizaciones de procesamiento de datos, suelen ser menos sensibles a la latencia y, por lo tanto, no suelen necesitar la simultaneidad aprovisionada. La configuración de la simultaneidad aprovisionada genera cargos adicionales para su Cuenta de AWS.
En este tema se detalla cómo administrar y configurar la simultaneidad reservada. Para obtener una descripción general conceptual de estos dos tipos de controles de simultaneidad, consulte [Simultaneidad reservada y simultaneidad aprovisionada](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned). Para obtener información sobre la configuración de la simultaneidad aprovisionada, consulte [Configuración de simultaneidad aprovisionada para una función](provisioned-concurrency.md).
**nota**
Las funciones de Lambda enlazadas a una asignación de orígenes de eventos de Amazon MQ tienen una simultaneidad máxima predeterminada. Para Apache Active MQ, el número máximo de instancias simultáneas es 5. Para Rabbit MQ, el número máximo de instancias simultáneas es 1. Establecer una simultaneidad reservada o aprovisionada para su función no cambia estos límites. Para solicitar un aumento de la simultaneidad máxima predeterminada al utilizar Amazon MQ, póngase en contacto con Soporte.
**Topics**
+ [
## Configuración de la simultaneidad reservada
](#configuring-concurrency-reserved)
+ [
## Estimar con precisión la simultaneidad reservada requerida para una función
](#estimating-reserved-concurrency)
## Configuración de la simultaneidad reservada
Puede configurar la simultaneidad reservada de una función a través la consola o la API de Lambda.
**Para reservar la simultaneidad de una función (consola)**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija la función para la que desea reservar la simultaneidad.
1. Elija **Configuración** y, a continuación, elija **Simultánea**.
1. En **Simultaneidad**, elija **Editar**.
1. Seleccione **Simultaneidad de reserva**. Escriba la cantidad de simultaneidad que reservar para la función.
1. Seleccione **Save**.
Puede reservar hasta el valor de **Simultaneidad de cuenta sin reserva** menos 100. Las 100 unidades restantes son para funciones que no utilizan la simultaneidad reservada. Por ejemplo, si la cuenta tiene un límite de simultaneidad de 1000, no puede reservar las 1000 unidades de simultaneidad para una sola función.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-reserve-over-limit.png)
Reservar simultaneidad para una función puede afectar al grupo de simultaneidad que está disponible para otras funciones. Por ejemplo, si reserva 100 unidades de simultaneidad para `function-a`, otras funciones de su cuenta deberán compartir las 900 unidades restantes, incluso si `function-a` no utiliza las 100 unidades de simultaneidad reservadas.
Para aplicar la limitación controlada a una función de forma intencional, establezca la simultaneidad reservada en 0. Esto impide que la función pueda procesar los eventos hasta que elimine el límite.
Para configurar la simultaneidad reservada con la API de Lambda, use las siguientes operaciones de la API.
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)
+ [GetFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConcurrency.html)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)
Para configurar la simultaneidad reservada con la AWS Command Line Interface (CLI), use el comando `put-function-concurrency`. El siguiente comando reserva 100 unidades de simultaneidad para una función llamada `my-function`:
```
aws lambda put-function-concurrency --function-name my-function \
--reserved-concurrent-executions 100
```
Debería ver una salida con un aspecto similar al siguiente:
```
{
"ReservedConcurrentExecutions": 100
}
```
## Estimar con precisión la simultaneidad reservada requerida para una función
Si actualmente la función atiende el tráfico, puede ver fácilmente sus métricas de simultaneidad mediante las [métricas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html). En concreto, la métrica `ConcurrentExecutions` muestra la cantidad de invocaciones simultáneas para cada función de la cuenta.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
Según el gráfico anterior, esta función atiende un promedio de 5 a 10 solicitudes simultáneas en cualquier momento y alcanza un máximo de 20 solicitudes en un día normal. Supongamos que hay muchas otras funciones en la cuenta. ** Si esta función es esencial para la aplicación y no quiere descartar ninguna solicitud**, utilice un número igual o mayor a 20 como configuración de la simultaneidad reservada.
Como alternativa, recuerde que también puede [calcular la simultaneidad](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency) mediante la siguiente fórmula:
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
Al multiplicar el promedio de solicitudes por segundo por la duración promedio de las solicitudes en segundos, obtendrá una estimación aproximada de la cantidad de simultaneidad que necesita reservar. Puede estimar el promedio de solicitudes por segundo mediante la métrica de `Invocation` y la duración promedio de las solicitudes en segundos mediante la métrica de `Duration`. Consulte [Uso de métricas de CloudWatch con Lambda](monitoring-metrics.md) para obtener más detalles.
También debería familiarizarse con las limitaciones de rendimiento ascendentes y descendentes. Si bien las funciones de Lambda se escalan sin problemas con la carga, es posible que las dependencias ascendentes y descendentes no tengan las mismas capacidades de rendimiento. Si necesita limitar cuán alto se puede escalar su función, configure la simultaneidad reservada de su función.
# Configuración de simultaneidad aprovisionada para una función
En Lambda, la [simultaneidad](lambda-concurrency.md) es la cantidad de solicitudes en tránsito que la función administra en la actualidad. Hay dos tipos de controles de concurrencia disponibles:
+ Simultaneidad reservada: representa la cantidad máxima y mínima de instancias simultáneas asignadas a la función. Cuando una función ha reservado simultaneidad, ninguna otra función puede usarla. La simultaneidad reservada es útil para garantizar que las funciones más importantes siempre tengan suficiente simultaneidad para manejar las solicitudes entrantes. Además, la simultaneidad reservada se puede utilizar para limitar la simultaneidad y evitar la sobrecarga de los recursos posteriores, como las conexiones de bases de datos. La simultaneidad reservada actúa como límite inferior y superior: reserva la capacidad especificada exclusivamente para su función y, al mismo tiempo, impide que escale más allá de ese límite. No hay ningún cargo adicional por configurar la concurrencia reservada para una función.
+ Simultaneidad aprovisionada: es la cantidad de entornos de ejecución preinicializados asignados a la función. Estos entornos de ejecución están listos para responder de forma inmediata a las solicitudes de funciones entrantes. La simultaneidad aprovisionada es útil para reducir las latencias de arranque en frío de las funciones y está diseñada para que las funciones estén disponibles con tiempos de respuesta de decenas de milisegundos. Por lo general, las cargas de trabajo interactivas son las que más se benefician de esta característica. Se trata de aplicaciones en las que los usuarios inician solicitudes, como las aplicaciones web y móviles y son las más sensibles a la latencia. Las cargas de trabajo asíncronas, como las canalizaciones de procesamiento de datos, suelen ser menos sensibles a la latencia y, por lo tanto, no suelen necesitar la simultaneidad aprovisionada. La configuración de la simultaneidad aprovisionada genera cargos adicionales para su Cuenta de AWS.
En este tema se detalla cómo administrar y configurar la simultaneidad aprovisionada. Para obtener una descripción general conceptual de estos dos tipos de controles de simultaneidad, consulte [Simultaneidad reservada y simultaneidad aprovisionada](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned). Para obtener más información sobre los límites de simultaneidad reservada, consulte [Configurar la simultaneidad reservada para una función](configuration-concurrency.md).
**nota**
Las funciones de Lambda enlazadas a una asignación de orígenes de eventos de Amazon MQ tienen una simultaneidad máxima predeterminada. Para Apache Active MQ, el número máximo de instancias simultáneas es 5. Para Rabbit MQ, el número máximo de instancias simultáneas es 1. Establecer una simultaneidad reservada o aprovisionada para su función no cambia estos límites. Para solicitar un aumento de la simultaneidad máxima predeterminada al utilizar Amazon MQ, póngase en contacto con Soporte.
**Topics**
+ [
## Configuración de simultaneidad aprovisionada
](#configuring-provisioned-concurrency)
+ [
## Estimar con precisión la simultaneidad aprovisionada requerida para una función
](#estimating-provisioned-concurrency)
+ [
## Optimizar el código de la función cuando se utiliza la simultaneidad aprovisionada
](#optimizing-latency)
+ [
## Usar variables de entorno para ver y controlar el comportamiento de simultaneidad aprovisionado
](#pc-environment-variables)
+ [
## Comprenda el comportamiento de registro y facturación con la simultaneidad aprovisionada
](#pc-logging-behavior)
+ [
## Uso de Application Auto Scaling para automatizar la administración de simultaneidad aprovisionada
](#managing-provisioned-concurency)
## Configuración de simultaneidad aprovisionada
Puede configurar los ajustes de la simultaneidad aprovisionada para una función mediante la consola o la API de Lambda.
**Para asignar la simultaneidad aprovisionada para una función (consola)**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija la función para la que desee asignar la simultaneidad aprovisionada.
1. Elija **Configuración** y, a continuación, elija **Simultánea**.
1. En **Configuraciones de concurrencia aprovisionadas**, seleccione **Agregar configuración**.
1. Elija el tipo de calificador y el alias o la versión.
**nota**
No puede utilizar la simultaneidad aprovisionada con la versión \$1LATEST de ninguna función.
Si su función tiene un origen de eventos, asegúrese de que este apunte al alias o la versión correctos de la función. De lo contrario, la función no utilizará los entornos de simultaneidad aprovisionada.
1. Ingrese un número en **Simultaneidad aprovisionada**.
1. Seleccione **Save**.
Puede configurar hasta el valor de **Simultaneidad de cuenta sin reserva** de su cuenta, menos 100. Las 100 unidades restantes son para funciones que no utilizan la simultaneidad reservada. Por ejemplo, si su cuenta tiene un límite de simultaneidad de 1000 y no ha asignado ninguna simultaneidad reservada o aprovisionada a ninguna de sus otras funciones, puede configurar un máximo de 900 unidades de simultaneidad aprovisionadas para una sola función.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/provisioned-concurrency-over-limit.png)
La configuración de la simultaneidad aprovisionada de una función tiene un impacto en el grupo de simultaneidad que está disponible para otras funciones. Por ejemplo, si configura 100 unidades de simultaneidad aprovisionadas para `function-a`, otras funciones de su cuenta deberán compartir las 900 unidades de simultaneidad restantes. Esto es válido incluso si `function-a` no utiliza las 100 unidades.
Es posible asignar simultaneidad reservada y simultaneidad aprovisionada para la misma función. En esos casos, la simultaneidad aprovisionada no puede superar la reservada.
Esta limitación se extiende a las versiones de funciones. La simultaneidad aprovisionada máxima que puede asignar a una versión de función específica es igual a la simultaneidad reservada de la función menos la simultaneidad aprovisionada en otras versiones de la función.
Para configurar la simultaneidad aprovisionada con la API de Lambda, use las siguientes operaciones de la API.
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html)
+ [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
Por ejemplo, para configurar la simultaneidad aprovisionada con la AWS Command Line Interface (CLI), utilice el comando `put-provisioned-concurrency-config`. El siguiente comando asigna 100 unidades de simultaneidad aprovisionadas para el alias `BLUE` de una función llamada `my-function`:
```
aws lambda put-provisioned-concurrency-config --function-name my-function \
--qualifier BLUE \
--provisioned-concurrent-executions 100
```
Debería ver una salida con un aspecto similar al siguiente:
```
{
"Requested ProvisionedConcurrentExecutions": 100,
"Allocated ProvisionedConcurrentExecutions": 0,
"Status": "IN_PROGRESS",
"LastModified": "2023-01-21T11:30:00+0000"
}
```
## Estimar con precisión la simultaneidad aprovisionada requerida para una función
Puede ver las métricas de simultaneidad de cualquier función activa mediante las [métricas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html). En concreto, la métrica `ConcurrentExecutions` muestra la cantidad de invocaciones simultáneas para las funciones de la cuenta.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
Según el gráfico anterior, esta función atiende un promedio de 5 a 10 solicitudes simultáneas en cualquier momento y alcanza un máximo de 20 solicitudes. Supongamos que hay muchas otras funciones en la cuenta. ** Si esta función es esencial para la aplicación y necesita una respuesta de baja latencia en cada invocación**, configure, al menos, 20 unidades de simultaneidad aprovisionada.
Recuerde que también puede [calcular la simultaneidad](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency) mediante la siguiente fórmula:
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
Para calcular cuánta simultaneidad necesita, multiplique el promedio de solicitudes por segundo por la duración promedio de las solicitudes en segundos. Puede estimar el promedio de solicitudes por segundo mediante la métrica de `Invocation` y la duración promedio de las solicitudes en segundos mediante la métrica de `Duration`.
Al configurar la simultaneidad aprovisionada, Lambda sugiere agregar un búfer del 10 % además de la cantidad de simultaneidad que normalmente necesita la función. Por ejemplo, si la función suele alcanzar un máximo de 200 solicitudes simultáneas, establezca la simultaneidad aprovisionada en 220 (200 solicitudes simultáneas \$1 un 10 % = 220 de simultaneidad aprovisionada).
## Optimizar el código de la función cuando se utiliza la simultaneidad aprovisionada
Si utilizas la simultaneidad aprovisionada, considera la posibilidad de reestructurar el código de función para optimizarlo y lograr una latencia baja. Para las funciones que se ejecutan con simultaneidad aprovisionada, Lambda ejecuta cualquier código de inicialización (por ejemplo, cargar bibliotecas y crear instancias de clientes) en el momento de la asignación. Por lo tanto, se recomienda mover la mayor cantidad de inicialización fuera del controlador de funciones principal para evitar que afecte a la latencia durante las invocaciones reales de la función. Por el contrario, inicializar bibliotecas o crear instancias de clientes dentro del código de su controlador principal significa que la función debe ejecutarlo cada vez que la invoque, independientemente de si utiliza o no la simultaneidad aprovisionada.
Para las invocaciones bajo demanda, es posible que Lambda tenga que volver a ejecutar el código de inicialización cada vez que la función se inicie en frío. Para estas funciones, puede optar por aplazar la inicialización de una capacidad específica hasta que su función lo necesite. Por ejemplo, considere el siguiente flujo de control para un controlador de Lambda:
```
def handler(event, context):
...
if ( some_condition ):
// Initialize CLIENT_A to perform a task
else:
// Do nothing
```
En el ejemplo anterior, en lugar de inicializar `CLIENT_A` fuera del controlador principal, el desarrollador lo inicializó dentro de la instrucción `if`. De este modo, Lambda ejecuta este código solo si se cumple `some_condition`. Si inicializa `CLIENT_A` fuera del controlador principal, Lambda ejecuta ese código cada vez que se inicia en frío. Esto puede aumentar la latencia general.
Puede medir los arranques en frío a medida que Lambda escale verticalmente y que agregue la monitorización de X-Ray a su función. Una función que utiliza la simultaneidad aprovisionada no presenta un comportamiento de arranque en frío, ya que el entorno de ejecución se prepara antes de la invocación. Sin embargo, la simultaneidad aprovisionada se debe aplicar a una [versión o alias específicos](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) de una función, no a la versión \$1LATEST. En los casos en los que aún se produzca un comportamiento de arranque en frío, asegúrese de invocar la versión del alias con la simultaneidad aprovisionada configurada.
## Usar variables de entorno para ver y controlar el comportamiento de simultaneidad aprovisionado
Es posible que la función utilice toda la simultaneidad aprovisionada. Lambda usa instancias bajo demanda para gestionar cualquier exceso de tráfico. Para determinar el tipo de inicialización que Lambda usó para un entorno determinado, compruebe el valor de la variable de entorno `AWS_LAMBDA_INITIALIZATION_TYPE`. Esta variable tiene dos valores posibles: `provisioned-concurrency` u `on-demand`. El valor de `AWS_LAMBDA_INITIALIZATION_TYPE` es inmutable y constante durante toda la vida útil del entorno. Para comprobar el valor de una variable de entorno en el código de su función, consulte [Recuperar variables de entorno Lambda](configuration-envvars.md#retrieve-environment-variables).
Si utiliza el tiempo de ejecución .NET 8, puede configurar la variable de entorno `AWS_LAMBDA_DOTNET_PREJIT` para mejorar la latencia de las funciones, incluso si no utilizan la simultaneidad aprovisionada. El tiempo de ejecución .NET utiliza compilación e inicialización perezosa para cada biblioteca a la que llama el código por primera vez. Como resultado, la primera invocación de una función de Lambda puede tardar más que las posteriores. Para mitigar este problema, puede elegir uno de los tres valores para `AWS_LAMBDA_DOTNET_PREJIT`:
+ `ProvisionedConcurrency`: Lambda realiza una compilación JIT anticipada para todos los entornos mediante la simultaneidad aprovisionada. Este es el valor predeterminado.
+ `Always`: Lambda realiza una compilación JIT anticipada para cada entorno, incluso si la función no usa la simultaneidad aprovisionada.
+ `Never`: Lambda deshabilita la compilación JIT anticipada para todos los entornos.
## Comprenda el comportamiento de registro y facturación con la simultaneidad aprovisionada
Para los entornos de simultaneidad aprovisionada, el código de inicialización de su función se ejecuta durante la asignación y de manera periódica, a medida que las instancias de la función se reciclan. Lambda factura la inicialización incluso si la instancia de entorno nunca procesa una solicitud. La simultaneidad aprovisionada se ejecuta continuamente y se factura por separado de los costos de inicialización e invocación. Para obtener más información, consulte [Precios de AWS Lambda](https://aws.amazon.com/lambda/pricing/).
Al configurar una función de Lambda con una simultaneidad aprovisionada, Lambda preinicializa ese entorno de ejecución para que esté disponible antes de las solicitudes de invocación. Lambda registra el [campo Duración de inicio](lambda-runtime-environment.md#runtimes-lifecycle-ib) de la función en un evento de registro [platform-initReport](telemetry-schema-reference.md#platform-initReport) en formato de registro JSON cada vez que se inicializa el entorno. Para ver este evento de registro, configure su [nivel de registro JSON](monitoring-cloudwatchlogs-logformat.md) en al menos `INFO`. También puede usar la [API de telemetría](telemetry-api-reference.md) para consumir los eventos de la plataforma en los que se registra el campo Duración de inicio.
## Uso de Application Auto Scaling para automatizar la administración de simultaneidad aprovisionada
El Auto Scaling de aplicaciones le permite administrar la simultaneidad aprovisionada según una programación o en función de la utilización. Si la función recibe patrones de tráfico predecibles, use el escalado programado. Si quiere que la función mantenga un porcentaje de utilización especifico, utilice una política de escalado de seguimiento de destino.
**nota**
Si usa el escalado automático de aplicaciones para administrar la simultaneidad aprovisionada de su función, asegúrese de [configurar primero un valor de simultaneidad aprovisionada inicial](#configuring-provisioned-concurrency). Si su función no tiene un valor de simultaneidad aprovisionado inicialmente, es posible que el escalado automático de aplicaciones no maneje el escalado de funciones correctamente.
### Escalado programado
Con el Auto Scaling de aplicaciones, puede definir su propia programación de escalado según los cambios predecibles en las cargas. Para obtener más información y ejemplos, consulte [Escalado programado para el Auto Scaling de aplicaciones](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) en la Guía del usuario de Auto Scaling de aplicaciones y [Programación de la simultaneidad aprovisionada de AWS Lambda para picos de uso recurrentes](https://aws.amazon.com/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/) en el blog de AWS Compute.
### Seguimiento de destino
Con el seguimiento de destino, el Auto Scaling de aplicaciones crea y administra un conjunto de alarmas de CloudWatch según la forma en que usted define la política de escalado. Cuando se activan estas alarmas, el Auto Scaling de aplicaciones ajusta automáticamente la cantidad de entornos asignados mediante la simultaneidad aprovisionada. Utilice el seguimiento de destino para aplicaciones que no tienen patrones de tráfico predecibles.
Para escalar la simultaneidad aprovisionada mediante el seguimiento de destino, use las operaciones `RegisterScalableTarget` y `PutScalingPolicy` de la API de Auto Scaling de aplicaciones. Por ejemplo, si usa la AWS Command Line Interface (CLI), siga los siguientes pasos:
1. Registre el alias de una función como destino del escalado. En el ejemplo siguiente se registra el alias BLUE de una función denominada `my-function`:
```
aws application-autoscaling register-scalable-target --service-namespace lambda \
--resource-id function:my-function:BLUE --min-capacity 1 --max-capacity 100 \
--scalable-dimension lambda:function:ProvisionedConcurrency
```
1. Aplique una política de escalado al destino. En el ejemplo siguiente, se configura el escalado automático de aplicaciones para ajustar la configuración de simultaneidad aprovisionada para que un alias mantenga la utilización cerca del 70 %, pero puede aplicar cualquier valor entre 10 % y 90 %.
```
aws application-autoscaling put-scaling-policy \
--service-namespace lambda \
--scalable-dimension lambda:function:ProvisionedConcurrency \
--resource-id function:my-function:BLUE \
--policy-name my-policy \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{ "TargetValue": 0.7, "PredefinedMetricSpecification": { "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization" }}'
```
Debería ver un resultado con un aspecto similar al siguiente:
```
{
"PolicyARN": "arn:aws:autoscaling:us-east-2:123456789012:scalingPolicy:12266dbb-1524-xmpl-a64e-9a0a34b996fa:resource/lambda/function:my-function:BLUE:policyName/my-policy",
"Alarms": [
{
"AlarmName": "TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7",
"AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7"
},
{
"AlarmName": "TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66",
"AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66"
}
]
}
```
Auto Scaling de aplicaciones crea dos alarmas en CloudWatch. La primera alarma se desencadena cuando la utilización de la simultaneidad aprovisionada supera sistemáticamente el 70 %. Cuando esto sucede, Auto Scaling de aplicaciones asigna más simultaneidad aprovisionada para reducir esta utilización. La segunda alarma se desencadena cuando la utilización nunca supera el 63 % (un 90 % del objetivo del 70 %). Cuando esto sucede, Auto Scaling de aplicaciones reduce la concurrencia aprovisionada del alias.
**nota**
Lambda emite la métrica `ProvisionedConcurrencyUtilization` solo cuando la función se encuentra activa y está recibiendo solicitudes. Durante los períodos de inactividad, no se emite ninguna métrica y las alarmas de escalado automático presentarán el estado `INSUFFICIENT_DATA`. Como resultado, Application Auto Scaling no podrá ajustar la simultaneidad aprovisionada de la función. Esto podría provocar una facturación inesperada.
En el ejemplo siguiente, una función escala entre una cantidad mínima y máxima de concurrencia aprovisionada basada en la utilización.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/features-scaling-provisioned-auto.png)
**Leyenda**
+ ![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/features-scaling-provisioned.instances.png) Instancias de función
+ ![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/features-scaling-provisioned.open.png) Solicitudes abiertas
+ ![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/features-scaling-provisioned.provisioned.png) Simultaneidad aprovisionada
+ ![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/features-scaling-provisioned.standard.png) Simultanidad estándar
Cuando aumenta el número de solicitudes abiertas, el Auto Scaling de aplicaciones aumenta la simultaneidad aprovisionada en grandes pasos hasta que alcanza el máximo configurado. Luego, la función podrá seguir escalando según la simultaneidad estándar no reservada si la cuenta no alcanzó su límite de simultaneidad. Cuando la utilización disminuye y permanece baja, el escalado automático de aplicaciones disminuye la simultaneidad aprovisionada en pasos periódicos más pequeños.
Las dos alarmas del escalado automático de aplicaciones utilizan la estadística promedio de forma predeterminada. Es posible que las funciones que experimentan ráfagas no desencadenen estas alarmas. Por ejemplo, supongamos que la función de Lambda se ejecuta rápidamente (es decir, de 20 a 100 ms) y que el tráfico se produce en ráfagas rápidas. En este caso, el número de solicitudes supera la simultaneidad aprovisionada asignada durante la ráfaga. Sin embargo, el escalado automático de aplicaciones requiere que la carga de ráfaga se mantenga durante al menos 3 minutos para aprovisionar entornos adicionales. Además, ambas alarmas de CloudWatch requieren 3 puntos de datos que alcancen el promedio de destino para activar la política de escalado automático. Si su función experimenta ráfagas rápidas de tráfico, usar la estadística **Máximo** en lugar de la estadística **Promedio** puede resultar más eficaz a la hora de escalar la simultaneidad aprovisionada y minimizar los arranques en frío.
Para obtener más información acerca de las políticas de escalado de seguimiento de destino, consulte [Políticas de escalado de seguimiento de destino para el Auto Scaling de aplicaciones](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html).
# Comportamiento de escalado de Lambda
A medida que una función recibe más solicitudes, Lambda escala de forma automática la cantidad de entornos de ejecución para gestionar estas solicitudes hasta que su cuenta alcance la cuota de simultaneidad. Sin embargo, para protegerse contra el exceso de escalado en respuesta a ráfagas repentinas de tráfico, Lambda limita la rapidez con la que sus funciones pueden escalar. Esta **tasa de escalado de simultaneidad** es la tasa máxima a la que las funciones de su cuenta pueden escalar en respuesta a un aumento de las solicitudes. (Es decir, la rapidez con la que Lambda puede crear nuevos entornos de ejecución). La tasa de escalado de simultaneidad difiere del límite de simultaneidad de la cuenta, que es la cantidad total de simultaneidad disponible para sus funciones.
## Tasa de escalado de simultaneidad
**En cada Región de AWS y para cada función, su tasa de escalado de simultaneidad es de 1000 instancias del entorno de ejecución cada 10 segundos (o 10 000 solicitudes por segundo cada 10 segundos)**. En otras palabras, cada 10 segundos, Lambda puede asignar como máximo 1000 instancias de entorno de ejecución adicionales o admitir 10 000 solicitudes por segundo adicionales a cada una de sus funciones.
Por lo general, no debe preocuparse por esta limitación. La tasa de escalado de Lambda es suficiente para la mayoría de los casos de uso.
Es importante destacar que la tasa de escalado de simultaneidad es un límite de función. Esto significa que cada función de su cuenta puede escalar independientemente de otras funciones.
**nota**
En la práctica, Lambda hace todo lo posible por reponer la tasa de escalado de simultaneidad de forma continua a lo largo del tiempo, en lugar de hacer una sola reposición de 1000 unidades cada 10 segundos.
Lambda no acumula partes no utilizadas de la tasa de escalado de simultaneidad. Esto significa que, en cualquier momento, su tasa de escalado es siempre de 1000 unidades de simultaneidad como máximo. Por ejemplo, si no utiliza ninguna de las 1000 unidades de simultaneidad disponibles en un intervalo de 10 segundos, no acumulará 1000 unidades adicionales en el siguiente intervalo de 10 segundos. Su tasa de escalado de simultaneidad seguirá siendo de 1000 en el siguiente intervalo de 10 segundos.
Mientras su función continúe recibiendo un número cada vez mayor de solicitudes, Lambda escalará a la tasa más rápida disponible hasta el límite de simultaneidad de su cuenta. Puede limitar la cantidad de simultaneidad que pueden utilizar las funciones individuales [configurando la simultaneidad reservada](configuration-concurrency.md). Si llegan solicitudes más rápidamente de lo que la función puede escalar o si la función está en la simultaneidad máxima, entonces las solicitudes adicionales fallan con un error de limitación (código de estado 429).
# Monitoreo de la simultaneidad
Lambda emite métricas de Amazon CloudWatch para ayudarlo a monitorear la simultaneidad de sus funciones. En este tema, se explican estas métricas y cómo interpretarlas.
**Topics**
+ [
## Métricas generales de simultaneidad
](#general-concurrency-metrics)
+ [
## Métricas de simultaneidad aprovisionada
](#provisioned-concurrency-metrics)
+ [
## Cómo trabajar con la métrica `ClaimedAccountConcurrency`
](#claimed-account-concurrency)
## Métricas generales de simultaneidad
Utilice estas métricas para monitorear la simultaneidad de las funciones de Lambda. La granularidad de cada métrica es de 1 minuto.
+ `ConcurrentExecutions`: la cantidad de invocaciones simultáneas activas en un momento determinado. Lambda emite esta métrica para todas las funciones, alias y versiones. Para cualquier función de la consola de Lambda, se muestra el gráfico sobre `ConcurrentExecutions` de forma nativa en la pestaña **Monitoreo**, en **Métricas**. Visualice esta métrica mediante **MAX**.
+ `UnreservedConcurrentExecutions`: la cantidad de invocaciones simultáneas activas que utilizan la simultaneidad no reservada. Lambda emite esta métrica en todas las funciones de una región. Visualice esta métrica mediante **MAX**.
+ `ClaimedAccountConcurrency`: la cantidad de simultaneidad que no está disponible para las invocaciones bajo demanda. `ClaimedAccountConcurrency` es igual a `UnreservedConcurrentExecutions` más la cantidad de simultaneidad asignada (es decir, la simultaneidad reservada total más la simultaneidad aprovisionada total). Si `ClaimedAccountConcurrency` supera el límite de simultaneidad de su cuenta, puede [solicitar un límite de simultaneidad de cuentas superior](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/). Visualice esta métrica mediante **MAX**. Para obtener más información, consulte [Cómo trabajar con la métrica `ClaimedAccountConcurrency`](#claimed-account-concurrency).
## Métricas de simultaneidad aprovisionada
Utilice las siguientes métricas para monitorear las funciones de Lambda mediante la simultaneidad aprovisionada. La granularidad de cada métrica es de 1 minuto.
+ `ProvisionedConcurrentExecutions`: la cantidad de instancias de entorno de ejecución que están procesando de forma activa una invocación con simultaneidad aprovisionada. Lambda emite esta métrica para cada versión y alias de función con la simultaneidad aprovisionada configurada. Visualice esta métrica mediante **MAX**.
`ProvisionedConcurrentExecutions` no es lo mismo que el número total de simultaneidad aprovisionada que usted asigna. Por ejemplo, supongamos que asigna 100 unidades de simultaneidad aprovisionadas a una versión de la función. Durante un minuto dado, si al menos 50 de esos 100 entornos de ejecución gestionaban invocaciones en simultáneo, el valor de **MAX** (`ProvisionedConcurrentExecutions`) es 50.
+ `ProvisionedConcurrencyInvocations`: es la cantidad de veces que Lambda invoca el código de la función mediante la simultaneidad aprovisionada. Lambda emite esta métrica para cada versión y alias de función con la simultaneidad aprovisionada configurada. Visualice esta métrica mediante **SUM**.
`ProvisionedConcurrencyInvocations` difiere de `ProvisionedConcurrentExecutions` en que `ProvisionedConcurrencyInvocations` cuenta el número total de invocaciones, mientras que `ProvisionedConcurrentExecutions` cuenta el número de entornos activos. Para entender esta distinción, considere el siguiente escenario:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/concurrency-metrics-pc-executions-vs-invocations.png)
En este ejemplo, suponga que recibe 1 invocación por minuto y que cada invocación tarda 2 minutos en completarse. Cada barra horizontal naranja representa una única solicitud. Supongamos que asigna 10 unidades de simultaneidad aprovisionadas a esta función, de modo que cada solicitud se ejecute con simultaneidad aprovisionada.
Entre los minutos 0 y 1, entra `Request 1`. **En el minuto 1**, el valor de **MAX** (`ProvisionedConcurrentExecutions`) es 1, ya que, como máximo, 1 entorno de ejecución estuvo activo durante el último minuto. El valor de **SUM** (`ProvisionedConcurrencyInvocations`) también es 1, ya que se recibió 1 solicitud nueva en el último minuto.
Entre los minutos 1 y 2, entra la `Request 2` y la `Request 1` continúa ejecutándose. **En el minuto 2**, el valor de **MAX** (`ProvisionedConcurrentExecutions`) es 2, ya que durante el último minuto estuvieron activos como máximo 2 entornos de ejecución. Sin embargo, el valor de **SUM** (`ProvisionedConcurrencyInvocations`) es 1, ya que solo se recibió 1 solicitud nueva en el último minuto. Este comportamiento de la métrica continúa hasta el final del ejemplo.
+ `ProvisionedConcurrencySpilloverInvocations`: es la cantidad de veces que Lambda invoca la función en simultaneidad estándar (reservada o no reservada) cuando toda la simultaneidad aprovisionada está en uso. Lambda emite esta métrica para cada versión y alias de función con la simultaneidad aprovisionada configurada. Visualice esta métrica mediante **SUM**. El valor de `ProvisionedConcurrencyInvocations` \$1 `ProvisionedConcurrencySpilloverInvocations` debe ser igual al número total de invocaciones de funciones (es decir, la métrica `Invocations`).
`ProvisionedConcurrencyUtilization`: el porcentaje de simultaneidad aprovisionada en uso (por ejemplo, el valor de `ProvisionedConcurrentExecutions` dividido por la cantidad total de simultaneidad aprovisionada asignada). Lambda emite esta métrica para cada versión y alias de función con la simultaneidad aprovisionada configurada. Visualice esta métrica mediante **MAX**.
Por ejemplo, supongamos que aprovisiona 100 unidades de simultaneidad aprovisionadas a una versión de la función. Durante un minuto dado, si como máximo 60 de esos 100 entornos de ejecución gestionaban invocaciones de forma simultánea, el valor de **MAX** (`ProvisionedConcurrentExecutions`) es 60 y el valor de **MAX** (`ProvisionedConcurrencyUtilization`) es 0,6.
Un valor alto para `ProvisionedConcurrencySpilloverInvocations` puede indicar que necesita asignar una simultaneidad aprovisionada adicional para su función. Como alternativa, puede [configurar el Auto Scaling de aplicaciones para gestionar el escalado automático de la simultaneidad aprovisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency) en función de umbrales predefinidos.
Por el contrario, los valores consistentemente bajos de `ProvisionedConcurrencyUtilization` pueden indicar que ha asignado en exceso la simultaneidad aprovisionada para su función.
## Cómo trabajar con la métrica `ClaimedAccountConcurrency`
Lambda utiliza la métrica `ClaimedAccountConcurrency` para determinar la cantidad de simultaneidad disponible de su cuenta para las invocaciones bajo demanda. Lambda calcula `ClaimedAccountConcurrency` mediante la siguiente fórmula:
```
ClaimedAccountConcurrency = UnreservedConcurrentExecutions + (allocated concurrency)
```
`UnreservedConcurrentExecutions` es la cantidad de invocaciones simultáneas activas que utilizan la simultaneidad no reservada. La simultaneidad asignada es la suma de las siguientes dos partes (`RC` se sustituye por “simultaneidad reservada” y `PC` por “simultaneidad aprovisionada”):
+ El `RC` total de todas las funciones de una Región.
+ El `PC` total de todas las funciones de una Región que utilizan `PC`, excepto las funciones que utilizan `RC`.
**nota**
No puede asignar más `PC` que `RC` para una función. Por lo tanto, la `RC` de una función siempre es mayor o igual que su `PC`. Para calcular la contribución a la simultaneidad asignada para dichas funciones con `PC` y `RC`, Lambda solo tiene en cuenta `RC`, que es la más alta de las dos.
Lambda utiliza la métrica `ClaimedAccountConcurrency`, en lugar de `ConcurrentExecutions`, para determinar la cantidad de simultaneidad disponible para las invocaciones bajo demanda. Si bien la métrica `ConcurrentExecutions` es útil para realizar un seguimiento del número de invocaciones simultáneas activas, no siempre refleja su verdadera disponibilidad simultánea. Esto se debe a que Lambda también considera la simultaneidad reservada y la simultaneidad aprovisionada para determinar la disponibilidad.
Para ejemplificar `ClaimedAccountConcurrency`, imagine un escenario en el que configura una gran cantidad de simultaneidad reservada y aprovisionada en todas las funciones que prácticamente no se utilizan. En el siguiente ejemplo, supongamos que el límite de simultaneidad de su cuenta es 1000 y que tiene dos funciones principales en su cuenta: `function-orange` y `function-blue`. Asigna 600 unidades de simultaneidad reservada a `function-orange`. Asigna 200 unidades de simultaneidad aprovisionada a `function-blue`. Supongamos que, con el transcurso del tiempo, implementa funciones adicionales y observa el siguiente patrón de tráfico:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/claimed-account-concurrency.png)
En el diagrama anterior, las líneas negras indican el uso real de la simultaneidad a lo largo del tiempo y la línea roja indica el valor de `ClaimedAccountConcurrency` a lo largo del tiempo. En este escenario, `ClaimedAccountConcurrency` es 800 como mínimo, a pesar del bajo uso real de la simultaneidad en todas las funciones. Esto se debe a que asignó 800 unidades totales de simultaneidad para `function-orange` y `function-blue`. Desde el punto de vista de Lambda, usted “reclamó” esta simultaneidad para utilizarla, por lo que, efectivamente, solo le quedan 200 unidades de simultaneidad para otras funciones.
En este escenario, la simultaneidad asignada es 800 en la fórmula `ClaimedAccountConcurrency`. A continuación, podemos derivar el valor de `ClaimedAccountConcurrency` en varios puntos del diagrama:
+ En `t1`, `ClaimedAccountConcurrency` es 800 (800 \$1 0 `UnreservedConcurrentExecutions`).
+ En `t2`, `ClaimedAccountConcurrency` es 900 (800 \$1 100 `UnreservedConcurrentExecutions`).
+ En `t3`, `ClaimedAccountConcurrency` es nuevamente 900 (800 \$1 100`UnreservedConcurrentExecutions`).
### Configuración de la métrica `ClaimedAccountConcurrency` en CloudWatch
Lambda emite la métrica `ClaimedAccountConcurrency` en CloudWatch. Utilice esta métrica junto con el valor de `SERVICE_QUOTA(ConcurrentExecutions)` para obtener el porcentaje de utilización de la simultaneidad en su cuenta, como se muestra en la siguiente fórmula:
```
Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100%
```
La siguiente captura de pantalla muestra cómo se puede graficar esta fórmula en CloudWatch. La línea verde `claim_utilization` representa la utilización simultánea de esta cuenta, que es alrededor de 40 %:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/claimed-account-concurrency-cloudwatch-graph.png)
La captura de pantalla anterior también incluye una alarma de CloudWatch que pasa a estado `ALARM` cuando la utilización de la simultaneidad supera el 70 %. Puede utilizar la métrica `ClaimedAccountConcurrency` junto con alarmas similares para determinar de forma proactiva cuándo podría ser necesario solicitar un límite de simultaneidad de cuentas superior.