# Instancias administradas de Lambda
Las instancias administradas de Lambda le permiten ejecutar funciones de Lambda en las instancias de Amazon EC2 de la generación actual, incluidas Graviton4, las instancias optimizadas para la red y otras opciones de cómputo especializadas, sin administrar los ciclos de vida de las instancias, la aplicación de parches en el tiempo de ejecución del sistema operativo y el lenguaje, el enrutamiento, el equilibrio de carga o las políticas de escalado. Con las instancias administradas de Lambda, se beneficia de las ventajas de precios de EC2, que incluyen Savings Plans e instancias reservadas de EC2.
Para obtener una lista de los tipos de instancias compatibles, vaya a la página de [Precios de AWS Lambda](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) y seleccione su Región de AWS.
## Capacidades clave
Las instancias administradas de Lambda tienen las siguientes capacidades:
+ **Elija las instancias adecuadas**: seleccione las [instancias adecuadas](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) en función de los requisitos de rendimiento y costo, incluido el acceso a las CPU más recientes, como Graviton4, las proporciones de memoria y CPU configurables y las redes de gran ancho de banda.
+ **Aprovisionamiento automático**: AWS aprovisiona automáticamente las instancias adecuadas y activa los entornos de ejecución de las funciones.
+ **Escalado dinámico**: las instancias se escalan de forma dinámica en función de los patrones de tráfico de sus funciones.
+ **Experiencia totalmente administrada**: AWS gestiona la administración, el escalado, la aplicación de parches y el enrutamiento de la infraestructura con las mismas amplias integraciones de orígenes de eventos que ya conoce.
## Cuándo utilizar instancias administradas de Lambda
Considere las instancias administradas de Lambda para los siguientes casos de uso:
+ **Cargas de trabajo predecibles con un volumen elevado**: son ideales para cargas de trabajo de estado estable sin picos de tráfico inesperados. De forma predeterminada, las instancias administradas de Lambda se escalan para gestionar la duplicación del tráfico en 5 minutos.
+ **Aplicaciones críticas para el rendimiento**: acceso a las CPU más recientes, diferentes proporciones entre memoria y CPU y un alto rendimiento de la red.
+ **Requisitos regulatorios**: necesidades de gobernanza granular con control sobre la ubicación de las instancias y de la VPC.
+ **Variedad de aplicaciones**: aplicaciones basadas en eventos, procesamiento de medios y datos, aplicaciones web y cargas de trabajo heredadas que migran a una tecnología sin servidor.
## Funcionamiento
Las instancias administradas de Lambda utilizan los proveedores de capacidad como base para ejecutar sus funciones:
1. **Cree un proveedor de capacidad**: defina dónde se ejecutan sus funciones; para ello, especifique la configuración de la VPC y, opcionalmente, los requisitos de la instancia y la configuración de escalado.
1. **Cree su función**: cree funciones de Lambda como de costumbre y asócielas a un proveedor de capacidad.
1. **Publique una versión de la función**: las versiones de funciones se activan en las instancias del proveedor de capacidad una vez publicadas.
Cuando publica una versión de la función con un proveedor de capacidad, Lambda lanza las instancias administradas en su cuenta. Lanza tres instancias de forma predeterminada para garantizar la resiliencia de la zona de disponibilidad e inicia tres entornos de ejecución antes de marcar la versión de la función como ACTIVA. Si adjunta una función a un proveedor de capacidad existente que ya ejecuta otras funciones, Lambda no podrá activar nuevas instancias si las instancias disponibles ya tienen capacidad para adaptarse a los entornos de ejecución de la nueva función.
## Modo de concurrencia
Las instancias administradas de Lambda admiten varias invocaciones simultáneas, en las que un entorno de ejecución puede gestionar varias invocaciones al mismo tiempo. Esto difiere del tipo de cómputo de Lambda (predeterminado), que proporciona un único modelo de concurrencia en el que un entorno de ejecución puede ejecutar como máximo una invocación a la vez. La concurrencia múltiple permite un mejor uso de las instancias de EC2 subyacentes y resulta especialmente beneficiosa para las aplicaciones con un uso intensivo de E/S, como los servicios web o los trabajos por lotes. Este cambio en el modelo de ejecución implica que la seguridad de los subprocesos, la administración del estado y el aislamiento del contexto deben gestionarse de forma diferente en función del tiempo de ejecución.
## tenencia y aislamiento
El tipo de cómputo de Lambda (predeterminado) es de varios inquilinos y utiliza la tecnología microVM de Firecracker para proporcionar aislamiento entre los entornos de ejecución que se ejecutan en flotas de Lambda compartidas. Las instancias administradas de Lambda se ejecutan en su cuenta y ofrecen las opciones de precio y hardware de EC2 más recientes. Las instancias administradas utilizan contenedores que se ejecutan en instancias de EC2 Nitro para proporcionar aislamiento en lugar de usar Firecracker. Los proveedores de capacidad sirven como límite de seguridad para las funciones de Lambda. Las funciones se ejecutan en contenedores dentro de las instancias.
### Descripción de las instancias administradas
Las funciones de las instancias administradas de Lambda se ejecutan en instancias administradas de EC2 en su cuenta. Lambda administra completamente estas instancias, lo que significa que tiene permisos restringidos en ellas en comparación con las instancias de EC2 estándar. Puede identificar las instancias administradas de Lambda en su cuenta de la siguiente manera:
+ La presencia del campo `Operator` en la salida de `DescribeInstances` de EC2
+ La etiqueta de `aws:lambda:capacity-provider` en la instancia
No puede realizar operaciones de EC2 estándar directamente en estas instancias, como finalizarlas manualmente. Para destruir las instancias administradas, elimine el proveedor de capacidad asociado. A continuación, Lambda finalizará las instancias como parte del proceso de eliminación del proveedor de capacidad.
## Precios
Las instancias administradas de Lambda utilizan precios basados en EC2 con una tarifa de administración del 15 % además del costo de la instancia de EC2. Este modelo de precios admite Savings Plans de EC2, instancias reservadas y cualquier otro descuento de precios que se aplique al uso de EC2. Consulte la página de precios para obtener más información: [https://aws.amazon.com/lambda/pricing/](https://aws.amazon.com/lambda/pricing/).
**Importante:** Los descuentos en los precios de EC2 solo se aplican al cómputo de EC2 subyacente, no a la tarifa de administración.
## Cómo se diferencian las instancias administradas de Lambda del tipo de cómputo de Lambda (predeterminado)
Las instancias administradas de Lambda cambian la forma en que Lambda procesa las solicitudes en comparación con Lambda (predeterminado).
**Diferencias clave:**
| | Lambda (predeterminado) | Instancias administradas de Lambda |
| --- | --- | --- |
| Modo de concurrencia | Modelo de concurrencia único en el que un entorno de ejecución puede admitir un máximo de una invocación a la vez. | Invocaciones simultáneas múltiples, en las que un entorno de ejecución puede gestionar varias invocaciones simultáneamente, lo que aumenta el rendimiento, especialmente en el caso de las aplicaciones con un uso intensivo de E/S. |
| Tenencia y aislamiento | Varios inquilinos, con el uso de la tecnología microVM de Firecracker para proporcionar aislamiento entre los entornos de ejecución que operan en flotas de Lambda compartidas. | Se ejecutan en su cuenta y utilizan EC2 Nitro para proporcionar aislamiento. Los proveedores de capacidad sirven como límite de seguridad, y las funciones se ejecutan en contenedores dentro de las instancias |
| Modelo de precios | Precios de duración por solicitud | Precios basados en instancias con modelos de precios de EC2, que incluyen instancias reservadas y bajo demanda, y opciones de ahorro como Savings Plans para computación. |
| Comportamiento del escalado | Se escala cuando no hay un entorno de ejecución libre para gestionar una invocación entrante (arranque en frío). Se escala a cero sin tráfico. | Se escala de forma asíncrona únicamente en función del uso de los recursos de la CPU, sin arranques en frío. Se escala al mínimo de los entornos de ejecución configurados sin tráfico. |
| El más adecuado para lo siguiente: | Funciona con un tráfico ampliado que puede soportar algunos tiempos de arranque en frío, o aplicaciones sin carga sostenida que se benefician del escalado a cero. | El tráfico predecible de gran volumen funciona cuando se busca la flexibilidad, los planes de precios y las opciones de hardware de EC2 |
## Siguientes pasos
+ Obtenga información sobre los [proveedores de capacidad para las instancias administradas de Lambda](lambda-managed-instances-capacity-providers.md).
+ Conozca el [escalado de las instancias administradas de Lambda](lambda-managed-instances-scaling.md).
+ Revise las guías específicas del tiempo de ejecución para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) y [Python](lambda-managed-instances-python-runtime.md).
+ Configure la [conectividad de VPC para sus proveedores de capacidad](lambda-managed-instances-networking.md).
+ Conozca [la seguridad y los permisos de las instancias administradas de Lambda](lambda-managed-instances-security.md).
# Introducción a las instancias administradas de Lambda
## Creación de una función de instancia administrada de Lambda (consola)
Puede usar la consola de Lambda para crear una función de instancia administrada que se ejecute en instancias de Amazon EC2 administradas por un proveedor de capacidad.
**Importante:** Antes de crear una función de instancia administrada, primero debe crear un proveedor de capacidad. Estas funciones requieren que un proveedor de capacidad defina la infraestructura de Amazon EC2 que ejecutará sus funciones.
**Cómo crear una función de instancia administrada de Lambda (consola)**
1. Abra la consola Lambda.
1. Desde el panel de navegación izquierdo, elija **Proveedores de capacidad**.
1. Elija **Creación de proveedores de capacidad**
1. En la sección de **Configuración de proveedores de capacidad**, introduzca un nombre para su proveedor de capacidad.
1. Seleccione la VPC y los permisos para su proveedor de capacidad. Puede crear uno nuevo o utilizar uno existente. Para obtener información sobre la creación del rol de operador requerido, consulte [Rol de operador de Lambda para instancias administradas de Lambda](lambda-managed-instances-operator-role.md).
1. Amplíe **Configuración avanzada**.
1. Defina los **Requisitos de la instancia**; para ello, elija la arquitectura del procesador y los tipos de instancia.
1. En **Escalado automático**, especifique la cantidad máxima de vCPU de EC2 para su proveedor de capacidad. También puede elegir el **Modo de escalado manual de instancias** para establecer su propio valor de escalado y lograr un control preciso.
1. Elija **Creación de proveedores de capacidad** para crear uno nuevo.
1. A continuación, elija **Create function**.
1. Seleccione **Crear desde cero**.
1. En el panel de **Información básica**, indique un **Nombre de función**.
1. En **Tiempo de ejecución**, elija cualquiera de los tiempos de ejecución compatibles.
1. Elija la **Arquitectura** para su función (la misma que seleccionó como proveedor de capacidad). De forma predeterminada, **x86\$164**.
1. En **Permisos**, asegúrese de tener permiso para el **Rol de ejecución** elegido. En caso contrario, puede crear un rol nuevo.
1. En **Configuraciones adicionales**, seleccione en **Tipo de cómputo** **Instancias administradas de Lambda**.
1. Debe preseleccionar el ARN del proveedor de capacidad que creó en los pasos anteriores.
1. Seleccione **Tamaño de memoria** y **Memoria del entorno de ejecución (GiB) por proporción de vCPU**.
1. Seleccione **Creación de función**.
Se crea la función de instancia administrada de Lambda, que aprovisionará la capacidad del proveedor de capacidad especificado. La creación de funciones suele tardar varios minutos. Una vez completado, puede editar el código de la función y ejecutar la primera prueba.
## Creación de una función de instancia administrada de Lambda (CLI de AWS)
### Requisitos previos
Antes de empezar, asegúrese de que tiene lo siguiente:
+ **CLI de AWS**: instale y configure la CLI de AWS. Para obtener más información, consulte [Instalación o actualización de la versión más reciente de la CLI de AWS](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ **Permisos de IAM**: su rol o usuario de IAM debe tener permisos para crear funciones de Lambda, proveedores de capacidad y transferir roles de IAM. Tenga en cuenta que también necesitará el `iam:CreateServiceLinkedRole` si es la primera vez que crea un proveedor de capacidad en la cuenta o si se ha eliminado el rol vinculado al servicio (SLR).
### Paso 1: crear los roles de IAM requeridos
Las instancias administradas de Lambda requieren dos roles de IAM: un rol de ejecución para la función y un rol de operador para el proveedor de capacidad. El rol de operador permite que Lambda lance, finalice y supervise instancias de Amazon EC2 en su nombre. El rol de ejecución de una función concede a esa función permiso de acceso a otros recursos y servicios de AWS.
**Para crear el rol de ejecución de Lambda**
1. Cree un documento de política de confianza que permita que Lambda asuma el rol:
```
cat > lambda-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
```
1. Cree el rol de ejecución:
```
aws iam create-role \
--role-name MyLambdaExecutionRole \
--assume-role-policy-document file://lambda-trust-policy.json
```
1. Adjunte la política de ejecución básica:
```
aws iam attach-role-policy \
--role-name MyLambdaExecutionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
**Cómo crear el rol de operador del proveedor de capacidad**
1. Cree un documento de política de confianza que permita que Lambda asuma el rol de operador:
```
cat > operator-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
```
1. Cree el rol de operador:
```
aws iam create-role \
--role-name MyCapacityProviderOperatorRole \
--assume-role-policy-document file://operator-trust-policy.json
```
1. Adjunte la política de permisos de EC2 requerida:
```
aws iam attach-role-policy \
--role-name MyCapacityProviderOperatorRole \
--policy-arn arn:aws:iam::aws:policy/AWSLambdaManagedEC2ResourceOperator
```
### Paso 2: configurar recursos de la VPC
Las instancias administradas de Lambda se ejecutan en su VPC y requieren una subred y un grupo de seguridad.
**Cómo crear recursos de la VPC**
1. Cree una VPC:
```
VPC_ID=$(aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--query 'Vpc.VpcId' \
--output text)
```
1. Cree una subred:
```
SUBNET_ID=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.1.0/24 \
--query 'Subnet.SubnetId' \
--output text)
```
1. Cree un grupo de seguridad:
```
SECURITY_GROUP_ID=$(aws ec2 create-security-group \
--group-name my-capacity-provider-sg \
--description "Security group for Lambda Managed Instances" \
--vpc-id $VPC_ID \
--query 'GroupId' \
--output text)
```
**Nota:** Las funciones de las instancias administradas de Lambda requieren una configuración de VPC para acceder a los recursos externos a la VPC y para transmitir los datos de telemetría a Registros de CloudWatch y X-Ray. Para obtener información sobre la configuración, consulte [Redes para instancias administradas de Lambda](lambda-managed-instances-networking.md).
### Paso 3: Crear un proveedor de capacidad
Un proveedor de capacidad administra las instancias de EC2 que ejecutan las funciones de Lambda.
**Para crear un proveedor de capacidad**
```
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
aws lambda create-capacity-provider \
--capacity-provider-name my-capacity-provider \
--vpc-config SubnetIds=[$SUBNET_ID],SecurityGroupIds=[$SECURITY_GROUP_ID] \
--permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::${ACCOUNT_ID}:role/MyCapacityProviderOperatorRole \
--instance-requirements Architectures=[x86_64] \
--capacity-provider-scaling-config MaxVCpuCount=30
```
Este comando crea un proveedor de capacidad con la siguiente configuración:
+ **Configuración de VPC**: especifica la subred y el grupo de seguridad de las instancias de EC2.
+ **Permisos**: define el rol de IAM que Lambda utiliza para administrar las instancias de EC2.
+ **Requisitos de instancia**: especifica la arquitectura x86\$164.
+ **Configuración de escalado**: establece un máximo de 30 vCPU para el proveedor de capacidad.
### Paso 4: crear una función de Lambda con código en línea
**Cómo crear una función con código en línea**
1. Primero, cree una función de Python simple y empaquétela en línea:
```
# Create a temporary directory for the function code
mkdir -p /tmp/my-lambda-function
cd /tmp/my-lambda-function
# Create a simple Python handler
cat > lambda_function.py << 'EOF'
import json
def lambda_handler(event, context):
return {
'statusCode': 200,
'body': json.dumps({
'message': 'Hello from Lambda Managed Instances!',
'event': event
})
}
EOF
# Create a ZIP file
zip function.zip lambda_function.py
```
1. Cree la función de Lambda mediante el archivo ZIP en línea:
```
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REGION=$(aws configure get region)
aws lambda create-function \
--function-name my-managed-instance-function \
--package-type Zip \
--runtime python3.13 \
--handler lambda_function.lambda_handler \
--zip-file fileb:///tmp/my-lambda-function/function.zip \
--role arn:aws:iam::${ACCOUNT_ID}:role/MyLambdaExecutionRole \
--architectures x86_64 \
--memory-size 2048 \
--ephemeral-storage Size=512 \
--capacity-provider-config LambdaManagedInstancesCapacityProviderConfig={CapacityProviderArn=arn:aws:lambda:${REGION}:${ACCOUNT_ID}:capacity-provider:my-capacity-provider}
```
La función se crea con lo siguiente:
+ **Tiempo de ejecución**: Python 3.13.
+ **Controlador**: la función `lambda_handler` en `lambda_function.py`.
+ **Memoria**: 2048 MB.
+ **Almacenamiento efímero**: 512 MB.
+ **Proveedor de capacidad**: enlaza con el proveedor de capacidad que creó.
### Paso 5: publicar una versión de la función
Para ejecutar la función en instancias administradas de Lambda, debe publicar una versión.
**Cómo publicar una versión de la función**
```
aws lambda publish-version \
--function-name my-managed-instance-function
```
Este comando publica la versión 1 de la función y la implementa en el proveedor de capacidad.
### Paso 6: invocar su función
Después de la publicación, puede invocar la función.
**Para invocar tu función**
```
aws lambda invoke \
--function-name my-managed-instance-function:1 \
--payload '{"name": "World"}' \
response.json
# View the response
cat response.json
```
La función se ejecuta en las instancias de EC2 administradas por su proveedor de capacidad y devuelve una respuesta.
### Limpieza
Para evitar incurrir en cargos, elimine los recursos que haya creado:
1. Elimine la función:
```
aws lambda delete-function --function-name my-managed-instance-function
```
1. Elimine el proveedor de capacidad:
```
aws lambda delete-capacity-provider --capacity-provider-name my-capacity-provider
```
1. Elimine los recursos de la VPC:
```
aws ec2 delete-security-group --group-id $SECURITY_GROUP_ID
aws ec2 delete-subnet --subnet-id $SUBNET_ID
aws ec2 delete-vpc --vpc-id $VPC_ID
```
1. Elimine los roles de IAM:
```
aws iam detach-role-policy \
--role-name MyLambdaExecutionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
aws iam detach-role-policy \
--role-name MyCapacityProviderOperatorRole \
--policy-arn arn:aws:iam::aws:policy/AWSLambdaManagedEC2ResourceOperator
aws iam delete-role --role-name MyLambdaExecutionRole
aws iam delete-role --role-name MyCapacityProviderOperatorRole
```
# Conceptos clave
Las instancias administradas de Lambda presentan varios conceptos básicos que difieren de las funciones de Lambda tradicionales. Comprender estos conceptos es esencial para implementar y administrar sus funciones de manera efectiva en la infraestructura de EC2.
Los **proveedores de capacidad** constituyen la base de las instancias administradas de Lambda. Un proveedor de capacidad define la infraestructura de cómputo en la que se ejecutan las funciones, incluida la configuración de la VPC, los requisitos de las instancias y las políticas de escalado. Los proveedores de capacidad también funcionan como límite de seguridad de las funciones, lo que significa que todas las funciones asignadas al mismo proveedor de capacidad deben ser de confianza mutua.
El **comportamiento de escalado** difiere considerablemente de las funciones de Lambda tradicionales. En lugar de escalar bajo demanda cuando llegan las invocaciones, las instancias administradas se escalan de forma asíncrona en función del uso de los recursos de la CPU. Este enfoque elimina los arranques en frío, pero requiere planificar el crecimiento del tráfico. Si el tráfico más que se duplica en 5 minutos, es posible que experimente limitaciones a medida que Lambda escala verticalmente su capacidad para satisfacer la demanda.
**La seguridad y los permisos** requieren una cuidadosa consideración. Necesita permisos de rol de operador para permitir que Lambda administre los recursos de EC2 en sus proveedores de capacidad. Además, los usuarios necesitan el permiso de `lambda:PassCapacityProvider` para asignar funciones a los proveedores de capacidad, lo que actúa como una puerta de seguridad para controlar qué funciones pueden ejecutarse en una infraestructura específica.
La **ejecución simultánea múltiple** es una característica clave de las instancias administradas. Cada entorno de ejecución puede gestionar varias invocaciones simultáneamente, lo que maximiza la utilización de los recursos para las aplicaciones con un uso intensivo de E/S. Esto difiere de las funciones de Lambda tradicionales, en la que cada entorno procesa una solicitud a la vez. Este modelo de ejecución requiere prestar atención a la seguridad de los subprocesos, la administración del estado y el aislamiento del contexto en función del tiempo de ejecución.
Las siguientes secciones brindan información detallada sobre cada concepto clave.
# Proveedores de capacidad
Un proveedor de capacidad es la base para ejecutar instancias administradas de Lambda. Actúa como límite de seguridad de las funciones y define los recursos de cómputo que Lambda aprovisionará y administrará en su nombre.
Cuando crea un proveedor de capacidad, especifica lo siguiente:
+ **Configuración de VPC**: las subredes y los grupos de seguridad donde se ejecutarán las instancias.
+ **Permisos**: roles de IAM para que Lambda administre los recursos de EC2.
+ **Requisitos de la instancia** (opcional): preferencias de arquitectura y [tipo de instancia](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High).
+ **Configuración de escalado** (opcional): cómo Lambda escala las instancias.
## Descripción de los proveedores de capacidad como límite de seguridad
Los proveedores de capacidad sirven como límite de seguridad para las funciones de Lambda dentro de su VPC y sustituyen el aislamiento basado en FireCracker. Las funciones se ejecutan en contenedores dentro de las instancias, pero los contenedores no proporcionan un fuerte aislamiento de seguridad entre las funciones, a diferencia de Firecracker microVMS.
**Conceptos clave de seguridad:**
+ **Proveedor de capacidad:** el límite de seguridad que define los niveles de confianza para las funciones de Lambda.
+ **Aislamiento de contenedores:** los contenedores NO son un proveedor de seguridad; no confíe en ellos para garantizar la seguridad entre cargas de trabajo que no sean de confianza.
+ **Separación de confianza:** separe las cargas de trabajo en las que no se confíe mutuamente mediante distintos proveedores de capacidad.
## Creación de un proveedor de capacidad
Puede crear un proveedor de capacidad con la CLI de AWS, la consola de administración de AWS o los AWS SDK.
**Uso de la CLI de AWS:**
```
aws lambda create-capacity-provider \
--capacity-provider-name my-capacity-provider \
--vpc-config SubnetIds=subnet-12345,subnet-67890,subnet-11111,SecurityGroupIds=sg-12345 \
--permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::123456789012:role/MyOperatorRole \
--instance-requirements Architectures=x86_64 \
--capacity-provider-scaling-config ScalingMode=Auto
```
### Parámetros necesarios
**CapacityProviderName**
+ Un nombre único para el proveedor de capacidad.
+ Debe ser único en su cuenta de AWS.
**VpcConfig**
+ **SubnetIds** (obligatorio): al menos una subred y 16 como máximo. Utilice varias subredes entre varias zonas de disponibilidad para establecer la resiliencia.
+ **SecurityGroupIds** (opcional): grupos de seguridad para sus instancias. Toma como valor predeterminado el grupo de seguridad predeterminado de VPC, si no se especifica.
**PermissionsConfig**
+ **CapacityProviderOperatorRoleArn** (obligatorio): rol de IAM que permite que Lambda administre los recursos de EC2 en su proveedor de capacidad.
### Parámetros opcionales
**InstanceRequirements**
Especifique la arquitectura y los [tipos de instancia](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) de su proveedor de capacidad:
+ **Arquitecturas**: elija `x86_64` o `arm64`. El valor predeterminado es `x86_64`
+ **AllowedInstanceTypes**: especifique los tipos de instancia permitidos. Ejemplo:: `m5.8xlarge`
+ **ExcludedInstanceTypes:** especifique los tipos de instancias excluidas mediante caracteres comodín. Puede especificar solo uno de los tipos de AllowedInstanceTypes o ExcludedInstanceTypes.
De forma predeterminada, Lambda elige los mejores tipos de instancias para su carga de trabajo. Le recomendamos que deje que las instancias administradas de Lambda elijan los tipos de instancia por usted, ya que restringir la cantidad de tipos de instancias posibles puede reducir la disponibilidad.
**CapacityProviderScalingConfig**
Configure la forma en que Lambda escala sus instancias:
+ **ScalingMode**: configúrelo en `Auto` para el escalado automático o en `Manual` para el control manual. El valor predeterminado es `Auto`
+ **MaxVCpuCount**: número máximo de vCPU para el proveedor de capacidad. El valor predeterminado es 400.
+ **ScalingPolicies**: defina las políticas de escalado y seguimiento de objetivos para el uso de la CPU y la memoria.
**KmsKeyArn**
Especifique una clave AWS KMS para el cifrado de EBS. Si no se especifica, toma como valor predeterminado la clave administrada de AWS.
**Etiquetas de**
Añada etiquetas para organizar y administrar los proveedores de capacidad.
## Administración de los proveedores de capacidad
### Actualización de un proveedor de capacidad
Puede actualizar determinadas propiedades de un proveedor de capacidad mediante la API de `UpdateCapacityProvider`.
```
aws lambda update-capacity-provider \
--capacity-provider-name my-capacity-provider \
--capacity-provider-scaling-config ScalingMode=Auto
```
### Eliminación de un proveedor de capacidad
Puede eliminar un proveedor de capacidad cuando ya no sea necesario mediante la API de `DeleteCapacityProvider`.
```
aws lambda delete-capacity-provider \
--capacity-provider-name my-capacity-provider
```
**Nota:** No puede eliminar un proveedor de capacidad que tenga versiones de funciones asociadas.
### Cómo ver la información del proveedor de capacidad
Recupere información sobre un proveedor de capacidad mediante la API de `GetCapacityProvider`.
```
aws lambda get-capacity-provider \
--capacity-provider-name my-capacity-provider
```
## Estados de proveedores de capacidad
Un proveedor de capacidad puede tener uno de los siguientes estados:
+ **Pendiente**: el proveedor de capacidad está en proceso de creación.
+ **Activo**: el proveedor de capacidad está listo para usarse.
+ **Error:** no se pudo crear el proveedor de capacidad.
+ **Eliminación**: el proveedor de capacidad está en proceso de eliminación.
## Cuotas
+ **Capacidad máxima de proveedores por cuenta**: 1000.
+ **Número máximo de versiones de funciones por proveedor de capacidad**: 100 (no se puede aumentar).
## Prácticas recomendadas
1. **Establezca una separación por nivel de confianza**: cree diferentes proveedores de capacidad para cargas de trabajo con diferentes requisitos de seguridad.
1. **Utilice nombres descriptivos**: denomine los proveedores de capacidad para indicar claramente su uso previsto y su nivel de confianza (por ejemplo, `production-trusted`, `dev-sandbox`).
1. **Utilice varias zonas de disponibilidad**: especifique subredes en varias zonas de disponibilidad para lograr una alta disponibilidad.
1. **Deje que Lambda elija los tipos de instancia**: a menos que tenga requisitos de hardware específicos, deje que Lambda seleccione los mejores tipos de instancias óptimos para garantizar la disponibilidad.
1. **Supervise el uso**: utilice AWS CloudTrail para supervisar las asignaciones de los proveedores de capacidad y los patrones de acceso.
## Siguientes pasos
+ Obtenga información sobre el [escalado de instancias administradas de Lambda](lambda-managed-instances-scaling.md).
+ Conozca [la seguridad y los permisos de las instancias administradas de Lambda](lambda-managed-instances-security.md).
+ Configure la [conectividad de VPC para sus proveedores de capacidad](lambda-managed-instances-networking.md).
+ Revise las guías específicas del tiempo de ejecución para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) y [Python](lambda-managed-instances-python-runtime.md).
# Escalado de instancias administradas de Lambda
Las instancias administradas de Lambda no se escalan cuando llegan las invocaciones y no admiten arranques en frío. En su lugar, escala de forma asíncrona mediante señales de consumo de recursos. Las instancias administradas actualmente se escalan en función del uso de los recursos de la CPU y de la saturación de la concurrencia múltiple.
**Diferencias clave:**
+ **Lambda (predeterminado):** escala cuando no hay un entorno de ejecución libre para gestionar una invocación entrante (arranque en frío).
+ **Instancias administradas de Lambda:** se escalan de forma asíncrona en función del uso de los recursos de la CPU y de la saturación de concurrencia múltiple de los entornos de ejecución.
Si el tráfico más que se duplica en 5 minutos, es posible que experimente limitaciones a medida que Lambda escala verticalmente las instancias y los entornos de ejecución para satisfacer la demanda.
## El ciclo de vida del escalado
Las instancias administradas de Lambda utilizan una arquitectura distribuida para administrar el escalado:
**Componentes:**
+ **Instancias administradas**: se ejecutan en su cuenta, en las subredes que proporcione.
+ **Enrutador y escalador**: componentes Lambda compartidos que enrutan las invocaciones y administran el escalado.
+ **Agente de Lambda**: se ejecuta en cada instancia administrada para administrar el ciclo de vida del entorno de ejecución y supervisar el consumo de recursos.
**Funcionamiento:**
1. Cuando publica una versión de la función con un proveedor de capacidad, Lambda lanza las instancias administradas en su cuenta. Lanza tres de forma predeterminada para garantizar la resiliencia de la zona de disponibilidad e inicia tres entornos de ejecución antes de marcar la versión de la función como ACTIVA.
1. Cada instancia administrada puede ejecutar entornos de ejecución para varias funciones asignadas al mismo proveedor de capacidad.
1. A medida que el tráfico fluye hacia su aplicación, los entornos de ejecución consumen recursos. El agente de Lambda notifica al escalador, que decide si escalar nuevos entornos de ejecución o instancias administradas.
1. Si el enrutador intenta enviar una invocación a un entorno de ejecución con un alto consumo de recursos, el agente de Lambda de esa instancia le notifica que reintente en otra.
1. A medida que disminuye el tráfico, el agente de Lambda notifica al escalador, que toma la decisión de reducir verticalmente los entornos de ejecución y reducir horizontalmente las instancias administradas.
## Ajuste del comportamiento de escalado
Puede personalizar el comportamiento de escalado de las instancias administradas mediante cuatro controles:
### Controles de nivel de función
#### 1. Memoria y vCPU de la función
Elija el tamaño de la memoria y la asignación de vCPU para su función. El tamaño de función más pequeño admitido es de 2 GB y 1 vCPU.
**Consideraciones:**
+ Elija una configuración de memoria y vCPU que admita ejecuciones simultáneas múltiples de su función.
+ No puede configurar una función con menos de 1 vCPU porque las funciones que se ejecutan en instancias administradas deben admitir varias cargas de trabajo simultáneas.
+ No puede elegir menos de 2 GB porque esto coincide con la proporción de memoria con respecto a la vCPU de 2 a 1 de las instancias c, que tienen la proporción más baja.
+ Para las aplicaciones de Python, es posible que deba elegir una proporción más alta de memoria con respecto a las vCPU, por ejemplo, 4 a 1 u 8 a 1, debido a la forma en que Python gestiona la concurrencia múltiple.
+ Si ejecuta operaciones con un uso intensivo de la CPU o realiza poca E/S, debe elegir más de una vCPU.
#### 2. Simultaneidad máxima
Establezca la concurrencia máxima por entorno de ejecución.
**Comportamiento predeterminado:** Lambda elija valores predeterminados razonables que equilibran el consumo de recursos y el rendimiento y que funcionan para una amplia variedad de aplicaciones.
**Pautas de ajuste:**
+ **Aumente la concurrencia:** si las invocaciones de sus funciones utilizan muy poca CPU, puede aumentar la concurrencia máxima hasta un máximo de 64 por vCPU.
+ **Reduzca la concurrencia:** si su aplicación consume una gran cantidad de memoria y muy poca CPU, puede reducir la concurrencia máxima.
**Importante:** Dado que las instancias administradas de Lambda están diseñadas para aplicaciones simultáneas múltiples, los entornos de ejecución con una concurrencia muy baja pueden experimentar limitaciones en el momento del escalado.
### Controles de nivel de los proveedores de capacidad
#### 3. Utilización de recursos de destino
Elija su propio objetivo de consumo de uso de la CPU.
**Comportamiento predeterminado:** Lambda mantiene suficiente margen de maniobra para que el tráfico se duplique en 5 minutos sin limitaciones.
**Opciones de optimización:**
+ Si su carga de trabajo es muy estable o si su aplicación no es sensible a las limitaciones, puede configurar el objetivo en un nivel alto para lograr una mayor utilización y reducir los costos.
+ Si desea mantener el margen para las ampliaciones de tráfico, puede establecer los objetivos de recursos en un nivel bajo, lo que requerirá más capacidad.
#### 4. Selección del tipo de instancia
Configure los tipos de instancias permitidos o excluidos.
**Comportamiento predeterminado:** Lambda elige los mejores tipos de instancias para su carga de trabajo. Le recomendamos que deje que las instancias administradas de Lambda elijan los tipos de instancia por usted, ya que restringir la cantidad de tipos de instancias posibles puede reducir la disponibilidad.
**Configuración personalizada:**
+ **Requisitos de hardware específicos:** defina los tipos de instancias permitidos en una lista de instancias compatibles. Por ejemplo, si tiene una aplicación que requiere un ancho de banda de la red elevado, puede seleccionar varios tipos de instancias n.
+ **Optimización de costos:** para los entornos de pruebas o desarrollo, podría elegir tipos de instancias más pequeñas, como los tipos de instancia m7a.large.
## Siguientes pasos
+ Obtenga información sobre los [proveedores de capacidad para las instancias administradas de Lambda](lambda-managed-instances-capacity-providers.md).
+ Revise las guías específicas del tiempo de ejecución para gestionar la concurrencia múltiple.
+ Configure la [conectividad de VPC para sus proveedores de capacidad](lambda-managed-instances-networking.md).
+ Supervise las métricas de escalado para optimizar el comportamiento de escalado.
# Seguridad y permisos
Las instancias administradas de Lambda utilizan **proveedores de capacidad como límites de confianza**. Las funciones se ejecutan en contenedores dentro de estas instancias, pero los contenedores no proporcionan aislamiento de seguridad entre las cargas de trabajo. Todas las funciones asignadas al mismo proveedor de capacidad deben ser de confianza mutua.
## Conceptos clave de seguridad
+ **Proveedor de capacidad**: el límite de seguridad que define los niveles de confianza para las funciones de Lambda.
+ **Aislamiento de contenedores:** los contenedores no son un límite de seguridad; no confíe en ellos para garantizar la seguridad entre cargas de trabajo que no sean de confianza.
+ **Separación de confianza:** separe las cargas de trabajo en las que no se confíe mutuamente mediante distintos proveedores de capacidad.
## Permisos necesarios
### Acción de PassCapacityProvider
Los usuarios necesitan el permiso de `lambda:PassCapacityProvider` para asignar funciones a los proveedores de capacidad. Este permiso actúa como una puerta de seguridad, ya que garantiza que solo los usuarios autorizados puedan colocar funciones en proveedores de capacidad específicos.
Los administradores de cuentas controlan qué funciones pueden utilizar proveedores de capacidad específicos mediante la acción de IAM `lambda:PassCapacityProvider`. Esta acción se requiere en las siguientes situaciones:
+ Creación de funciones que utilizan instancias administradas de Lambda.
+ Actualización de las configuraciones de funciones para usar un proveedor de capacidad.
+ Implementación de funciones a través de la infraestructura como código.
**Política de IAM de ejemplo**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:PassCapacityProvider",
"Resource": "arn:aws:lambda:*:*:capacity-provider:trusted-workloads-*"
}
]
}
```
### Rol vinculado a servicio
AWS Lambda utiliza el rol vinculado a servicios `AWSServiceRoleForLambda` para administrar los recursos ec2 de las instancias administradas de Lambda en sus proveedores de capacidad.
## Prácticas recomendadas
1. **Establezca una separación por nivel de confianza**: cree diferentes proveedores de capacidad para cargas de trabajo con diferentes requisitos de seguridad.
1. **Utilice nombres descriptivos**: denomine los proveedores de capacidad para indicar claramente su uso previsto y su nivel de confianza (por ejemplo, `production-trusted`, `dev-sandbox`).
1. **Aplique el privilegio mínimo**: conceda permisos de `PassCapacityProvider` solo a los proveedores de capacidad necesarios.
1. **Supervise el uso**: utilice AWS CloudTrail para supervisar las asignaciones de los proveedores de capacidad y los patrones de acceso.
## Siguientes pasos
+ Obtenga información sobre los [proveedores de capacidad para las instancias administradas de Lambda](lambda-managed-instances-capacity-providers.md).
+ Conozca el [escalado de las instancias administradas de Lambda](lambda-managed-instances-scaling.md).
+ Configure la [conectividad de VPC para sus proveedores de capacidad](lambda-managed-instances-networking.md).
+ Revise las guías específicas del tiempo de ejecución para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) y [Python](lambda-managed-instances-python-runtime.md).
# Rol de operador de Lambda para instancias administradas de Lambda
Cuando utiliza instancias administradas de Lambda, Lambda necesita permisos para administrar la capacidad de cómputo de su cuenta. El rol de operador proporciona estos permisos a través de las políticas de IAM que permiten que Lambda administre las instancias de EC2 en el proveedor de capacidad.
Lambda asume el rol de operador cuando realiza estas operaciones de administración, de forma similar a como Lambda asume un rol de ejecución cuando se ejecuta la función.
## Creación de un rol de operador
Puede crear un rol de operador en la consola de IAM o mediante la CLI de AWS. El rol debe incluir lo siguiente:
+ **Política de permisos**: otorga permisos para administrar los proveedores de capacidad y los recursos asociados.
+ **Política de confianza**: permite que el servicio de Lambda (`lambda.amazonaws.com`) asuma el rol.
### Política de permisos
El rol de operador necesita permisos para administrar los proveedores de capacidad y los recursos de cómputo subyacentes. Como mínimo, el rol requiere los permisos de la política administrada de [AWSLambdaManagedEC2ResourceOperator](https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAWSLambdaManagedEC2ResourceOperator), que actualmente:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateTags",
"ec2:AttachNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"StringEquals": {
"ec2:ManagedResourceOperator": "scaler.lambda.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeAvailabilityZones",
"ec2:DescribeCapacityReservations",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstanceTypeOfferings",
"ec2:DescribeInstanceTypes",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:image/*"
],
"Condition": {
"StringEquals": {
"ec2:Owner": "amazon"
}
}
}
]
}
```
### Política de confianza
Esta política de confianza permite que Lambda asuma el rol de operador:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## rol vinculado a servicios para instancias administradas de Lambda
Para administrar de forma responsable el ciclo de vida de las instancias administradas de Lambda, Lambda necesita un acceso persistente para cerrar las instancias administradas de su cuenta. Lambda utiliza un rol vinculado a servicios (SLR) de AWS Identity and Access Management (IAM) para realizar estas operaciones.
**Creación automática**: el rol vinculado a servicios se crea automáticamente la primera vez que se crea un proveedor de capacidad. El usuario que crea el primer proveedor de capacidad debe tener el permiso del `iam:CreateServiceLinkedRole` para la entidad principal de `lambda.amazonaws.com`.
**Permisos**: el rol vinculado a servicios otorga a Lambda los siguientes permisos en las instancias administradas:
+ `ec2:TerminateInstances`: finalizar instancias al final de su ciclo de vida.
+ `ec2:DescribeInstances`: enumerar las instancias administradas.
**Eliminación**: solo puede eliminar este rol vinculado a servicios después de haber eliminado todos los proveedores de capacidad de instancias administradas de Lambda de su cuenta.
Para obtener más información acerca de los roles vinculados a servicios, consulte [Uso de roles vinculados a servicios en Lambda](using-service-linked-roles.md).
# Descripción del entorno de ejecución de instancias administradas de Lambda
Las instancias administradas de Lambda proporcionan un modelo de implementación alternativo que ejecuta el código de función en instancias de Amazon EC2 propiedad del cliente, mientras que Lambda administra los aspectos operativos. El entorno de ejecución de las instancias administradas presenta varias diferencias importantes con respecto a las funciones de Lambda (predeterminadas), especialmente en la forma en que gestiona las invocaciones simultáneas y gestiona los ciclos de vida de los contenedores.
**Nota:** Para obtener información sobre el entorno de ejecución de Lambda (predeterminado), consulte Descripción del ciclo de vida del entorno de ejecución de Lambda.
## Ciclo de vida del entorno de ejecución
El ciclo de vida de un entorno de ejecución de funciones de instancias administradas de Lambda difiere del de Lambda (predeterminado) en varios aspectos clave:
### Fase "init"
Durante la fase de inicialización, Lambda realiza los siguientes pasos:
+ Inicializa y registra todas las extensiones.
+ Arranca el punto de entrada del tiempo de ejecución. El tiempo de ejecución genera el número configurado de trabajadores en tiempo de ejecución (la implementación depende del tiempo de ejecución).
+ Ejecuta el código de inicialización de la función (código externo al controlador).
+ Espera a que al menos un trabajador en tiempo de ejecución indique que está listo mediante una llamada a `/runtime/invocation/next`.
La fase de inicio se considera completa cuando las extensiones se han inicializado y al menos un trabajador en tiempo de ejecución ha llamado a `/runtime/invocation/next`. La función está entonces lista para procesar las invocaciones.
**nota**
En el caso de las funciones de las instancias administradas de Lambda, la inicialización puede tardar hasta 15 minutos. El tiempo de espera es 130 segundos o el tiempo de espera de la función configurado (máximo de 900 segundos), lo que sea mayor.
### Fase "invoke"
La fase de invocación para las funciones de instancias administradas de Lambda tiene varias características únicas:
**Funcionamiento continuo.** A diferencia de Lambda (predeterminado), el entorno de ejecución permanece activo de forma continua y procesa las invocaciones a medida que llegan sin bloquearse entre las invocaciones.
**Procesamiento en paralelo.** Se pueden ejecutar varias invocaciones simultáneamente en el mismo entorno de ejecución, y cada una de ellas es administrada por un trabajador en tiempo de ejecución diferente.
**Tiempos de espera independientes.** El tiempo de espera configurado de la función se aplica a cada invocación individual. Cuando se agota el tiempo de espera de una invocación, Lambda marca esa invocación específica como fallida, pero no interrumpe otras invocaciones en ejecución ni finaliza el entorno de ejecución.
**Gestión de la contrapresión.** Si todos los trabajadores en tiempo de ejecución están ocupados procesando las invocaciones, se rechazan las nuevas solicitudes de invocación hasta que haya un trabajador disponible.
## Gestión de errores y recuperación
La gestión de errores en los entornos de ejecución de funciones de instancias administradas de Lambda es diferente al de Lambda (predeterminado):
**Tiempos de espera de invocación.** Cuando se agota el tiempo de espera de una invocación individual, Lambda devuelve un error de tiempo de espera para esa invocación. Sin embargo, las instancias gestionadas por Lambda no exigen el tiempo de espera; el código seguirá ejecutándose. Como desarrollador de funciones, usted es responsable de detectar y gestionar el tiempo de espera. El objeto de contexto expone el tiempo restante de la invocación, con un valor cero o negativo que indica que se ha agotado el tiempo de espera. Otras invocaciones simultáneas en el entorno de ejecución se siguen procesando con normalidad.
**Errores del trabajador en tiempo de ejecución.** Si un proceso de trabajo en tiempo de ejecución se bloquea, el entorno de ejecución sigue funcionando con el resto de los trabajadores en buen estado.
**La extensión se bloquea.** Si un proceso de extensión se bloquea durante la inicialización o la operación, todo el entorno de ejecución se marca como en mal estado y finaliza. Lambda crea un nuevo entorno de ejecución para reemplazarlo.
**Sin reinicio/reparación.** A diferencia de Lambda (predeterminado), las instancias administradas no intentan restablecer ni reinicializar el entorno de ejecución después de los errores. En cambio, los contenedores en mal estado se finalizan y se reemplazan por otros nuevos.
# Versión \$1LATEST.PUBLISHED en instancias administradas de Lambda
Las funciones de instancias administradas de Lambda admiten el mismo flujo de trabajo de control de versiones numerado que Lambda (predeterminado). Si prefiere no mantener versiones numeradas, las instancias administradas de Lambda introduce un nuevo tipo de versión: `$LATEST.PUBLISHED`. Esta versión le permite crear o volver a publicar una última versión publicada según sea necesario con el código o la configuración actualizados, sin tener que administrar versiones numeradas.
**Diferencia clave con \$1LATEST:** cuando se invoca una función de instancias administradas de Lambda mediante un ARN no calificado, Lambda invoca implícitamente la versión `$LATEST.PUBLISHED` en lugar de la versión \$1LATEST no publicada.
El siguiente comando de la CLI de AWS crea o vuelve a publicar la versión de `$LATEST.PUBLISHED`.
```
aws lambda publish-version --function-name my-function --publish-to LATEST_PUBLISHED
```
Debería ver los siguientes datos de salida:
```
{
"FunctionName": "my-function",
"FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function:$LATEST.PUBLISHED",
"Version": "$LATEST.PUBLISHED",
"Role": "arn:aws:iam::123456789012:role/lambda-role",
"Handler": "function.handler",
"Runtime": "nodejs24.x",
...
}
```
**nota**
Si utiliza AWS CloudFormation o la consola de Lambda para crear una función de instancias administradas de Lambda, Lambda crea automáticamente la versión `$LATEST.PUBLISHED`.
# Tiempos de ejecución de instancias administradas de Lambda
Lambda procesa las solicitudes de forma diferente cuando se utilizan instancias administradas de Lambda. En lugar de gestionar las solicitudes en cada entorno de ejecución de forma secuencial, las instancias administradas de Lambda procesan varias solicitudes de forma simultánea en cada entorno de ejecución. Este cambio en el modelo de ejecución significa que las funciones que utilizan instancias administradas de Lambda deben tener en cuenta la seguridad de los subprocesos, la administración del estado y el aislamiento del contexto, problemas que no surgen en el modelo de concurrencia única de Lambda (predeterminado). Además, la implementación de concurrencia múltiple varía según los tiempos de ejecución.
## Lenguajes admitidos
Las instancias administradas de Lambda se pueden usar con los siguientes lenguajes de programación y tiempos de ejecución:
+ **Java:** Java 21 y versiones posteriores.
+ **Python:** Python 3.13 y versiones posteriores.
+ **Node.js:** Node.js 22 y versiones posteriores.
+ **.NET:** .NET 8 y versiones posteriores.
+ **Rust:** compatible con el tiempo de ejecución solo del sistema operativo `provided.al2023` y versiones posteriores.
## Consideraciones específicas del lenguaje
Cada lenguaje de programación implementa la concurrencia múltiple de forma diferente. Debe comprender cómo se implementa la concurrencia múltiple en el lenguaje de programación que elija para aplicar las mejores prácticas de concurrencia adecuadas.
**Java**
Utiliza un único proceso con subprocesos del sistema operativo para la concurrencia. Varios subprocesos ejecutan el método del controlador simultáneamente, lo que requiere una gestión segura de los recursos compartidos.
**Python**
Utiliza varios procesos de Python en los que cada solicitud simultánea se ejecuta en un proceso independiente. Esto protege contra la mayoría de los problemas de concurrencia, aunque hay que ejercer precaución con los recursos compartidos, como el directorio `/tmp`.
**Node.js**
Utiliza [subprocesos de trabajo](https://nodejs.org/api/worker_threads.html) con ejecución asíncrona. Las solicitudes simultáneas se distribuyen entre los subprocesos de trabajo, y cada subproceso de trabajo también puede gestionar las solicitudes simultáneas de forma asíncrona, lo que requiere una gestión segura de los recursos compartidos y del estado.
**.NET**
Utiliza tareas de .NET con procesamiento asíncrono de varias solicitudes simultáneas. Requiere una gestión segura de los recursos compartidos y del estado.
**Rust**
Utiliza un único proceso con tareas asíncronas impulsadas por [Tokio](https://tokio.rs/). El controlador debe ser `Clone` \$1 `Send`.
## Siguientes pasos
Para obtener información detallada sobre cada tiempo de ejecución, consulte los siguientes temas:
+ [Tiempo de ejecución de Java para instancias administradas de Lambda](lambda-managed-instances-java-runtime.md)
+ [Tiempo de ejecución de Node.js para instancias administradas de Lambda](lambda-managed-instances-nodejs-runtime.md)
+ [Tiempo de ejecución de Python para instancias administradas de Lambda](lambda-managed-instances-python-runtime.md)
+ [Tiempo de ejecución de .NET para instancias administradas de Lambda](lambda-managed-instances-dotnet-runtime.md)
+ [Compatibilidad de Rust con instancias administradas de Lambda](lambda-managed-instances-rust.md)
# Tiempo de ejecución de Java para instancias administradas de Lambda
En el caso de los tiempos de ejecución de Java, las instancias administradas de Lambda utilizan subprocesos del sistema operativo para la concurrencia. Lambda carga el objeto controlador una vez por entorno de ejecución durante la inicialización y, a continuación, crea varios subprocesos. Estos subprocesos se ejecutan en paralelo y requieren una gestión segura de subprocesos de los recursos compartidos y los estados. Cada subproceso comparte el mismo objeto controlador y todos los campos estáticos.
## Configuración de concurrencia
El número máximo de solicitudes simultáneas que envía Lambda a cada entorno de ejecución se controla mediante el ajuste `PerExecutionEnvironmentMaxConcurrency` de la configuración de la función. Se trata de una configuración opcional y el valor predeterminado varía en función del tiempo de ejecución. Para los tiempos de ejecución de Java, el valor predeterminado es de 32 solicitudes simultáneas por vCPU, o puede configurar su propio valor. Este valor también determina el número de subprocesos utilizados por el tiempo de ejecución de Java. Lambda ajusta automáticamente el número de solicitudes simultáneas hasta el máximo configurado en función de la capacidad de cada entorno de ejecución para absorber esas solicitudes.
## Creación de funciones para la concurrencia múltiple
Debe aplicar las mismas prácticas de seguridad de subprocesos cuando utilice instancias administradas de Lambda que en cualquier otro entorno de subprocesos múltiples. Como el objeto controlador se comparte entre todos los subprocesos de trabajo en tiempo de ejecución, cualquier estado mutable debe ser seguro para subprocesos. Esto incluye las colecciones, las conexiones a bases de datos y cualquier objeto estático que se modifique durante el procesamiento de la solicitud.
Los clientes de AWS SDK son seguros para subprocesos y no requieren una gestión especial.
**Ejemplo: grupos de conexiones a bases de datos**
El código siguiente utiliza un objeto de conexión de base de datos estático que se comparte entre subprocesos. Según la biblioteca de conexiones utilizada, es posible que no sea segura para subprocesos.
```
public class DBQueryHandler implements RequestHandler {
// Single connection shared across all threads - NOT SAFE
private static Connection connection;
public DBQueryHandler() {
this.connection = DriverManager.getConnection(jdbcUrl, username, password);
}
@Override
public String handleRequest(Object input, Context context) {
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery();
// Multiple threads using same connection causes issues
return result.toString();
}
}
```
Un enfoque seguro para subprocesos consiste en utilizar un grupo de conexiones. En el siguiente ejemplo, el controlador de funciones recupera una conexión del grupo. La conexión solo se utiliza en el contexto de una única solicitud.
```
public class DBQueryHandler implements RequestHandler {
private static HikariDataSource dataSource;
public DBQueryHandler() {
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/your_database");
dataSource = new HikariDataSource(config); // Create pool once per Lambda container
}
@Override
public String handleRequest(Object input, Context context) {
String query = "SELECT column_name FROM your_table LIMIT 10";
StringBuilder result = new StringBuilder("Data:\n");
// try-with-resources automatically calls close() on the connection,
// which returns it to the HikariCP pool (does NOT close the physical DB connection)
try (Connection connection = dataSource.getConnection();
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery()) {
while (rs.next()) {
result.append(rs.getString("column_name")).append("\n");
}
} catch (Exception e) {
context.getLogger().log("Error: " + e.getMessage());
return "Error";
}
return result.toString();
}
}
```
**Ejemplo: colecciones**
Las recopilaciones estándar de Java no son seguras para los subprocesos:
```
public class Handler implements RequestHandler {
private static List items = new ArrayList<>();
private static Map cache = new HashMap<>();
@Override
public String handleRequest(Object input, Context context) {
items.add("list item"); // Not thread-safe
cache.put("key", input); // Not thread-safe
return "Success";
}
}
```
En su lugar, utilice colecciones seguras para subprocesos:
```
public class Handler implements RequestHandler {
private static final List items =
Collections.synchronizedList(new ArrayList<>());
private static final ConcurrentHashMap cache =
new ConcurrentHashMap<>();
@Override
public String handleRequest(Object input, Context context) {
items.add("list item"); // Thread-safe
cache.put("key", input); // Thread-safe
return "Success";
}
}
```
## Directorio /tmp compartido
El directorio `/tmp` se comparte entre todas las solicitudes simultáneas del entorno de ejecución. Las escrituras simultáneas en el mismo archivo pueden dañar los datos, por ejemplo, si otro proceso sobrescribe el archivo. Para solucionar este problema, implemente el bloqueo de archivos para los archivos compartidos o utilice nombres de archivo únicos por subproceso o por solicitud para evitar conflictos. Recuerde limpiar los archivos innecesarios para no agotar el espacio disponible.
## Registro
El intercalado de registros (las entradas de registro de diferentes solicitudes se intercalan en los registros) es normal en los sistemas simultáneos múltiples.
Las funciones que utilizan instancias administradas de Lambda utilizan siempre el formato de registro JSON estructurado introducido con los [controles de registro avanzados](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Este formato incluye el `requestId`, lo que permite correlacionar las entradas de registro con una sola solicitud. Cuando utiliza el objeto `LambdaLogger` de `context.getLogger()`, el `requestId` se incluye automáticamente en cada entrada de registro. Para obtener información adicional, consulte [Uso de los controles de registro avanzados de Lambda con Java](java-logging.md#java-logging-advanced).
## El contexto de la solicitud
El objeto `context` está enlazado al subproceso de solicitud. El uso de `context.getAwsRequestId()` proporciona un acceso seguro para subprocesos al identificador de solicitud de la solicitud actual.
Utilice el `context.getXrayTraceId()` para acceder al identificador de seguimiento de X-Ray. Esto proporciona un acceso seguro para subprocesos al identificador de seguimiento de la solicitud actual. Lambda no admite la variable de entorno `_X_AMZN_TRACE_ID` con las instancias administradas de Lambda. El identificador de seguimiento de X-Ray se propaga automáticamente cuando se utiliza AWS SDK.
Utilice `com.amazonaws.services.lambda.runtime.Context.getRemainingTimeInMillis()` para detectar tiempos de espera. Para obtener más información, consulte [Gestión de errores y recuperación](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
Si utiliza subprocesos virtuales en su programa o crea subprocesos durante la inicialización, tendrá que pasar cualquier contexto de solicitud necesario a estos subprocesos.
## Inicialización y apagado
La inicialización de la función se produce una vez por entorno de ejecución. Los objetos creados durante la inicialización se comparten entre los subprocesos.
En el caso de las funciones de Lambda con extensiones, el entorno de ejecución emite una señal SIGTERM durante el cierre. Las extensiones utilizan esta señal para desencadenar tareas de limpieza, como vaciar los búferes. Puede suscribirse a los eventos SIGTERM para desencadenar tareas de limpieza de funciones, como cerrar las conexiones a las bases de datos. Para obtener más información sobre el ciclo de vida del entorno de ejecución, consulte [Comprender el ciclo de vida del entorno de ejecución de Lambda](lambda-runtime-environment.md).
## Versiones de dependencias
Las instancias administradas de Lambda requieren las siguientes versiones de paquete como mínimo:
+ AWS SDK para Java 2.0: versión 2.34.0 o posterior
+ AWS X-Ray SDK para Java: versión 2.20.0 o posterior
+ AWS Distro para OpenTelemetry, instrumentación para Java: versión 2.20.0 o posterior
+ Powertools para AWS Lambda (Java): versión 2.8.0 o posterior
## Powertools para AWS Lambda (Java)
Powertools para AWS Lambda (Java) es compatible con las instancias administradas de Lambda y proporciona utilidades para el registro, el seguimiento, las métricas y mucho más. Para obtener más información, consulte [Powertools para AWS Lambda (Java)](https://github.com/aws-powertools/powertools-lambda-java).
## Siguientes pasos
+ Revise el [tiempo de ejecución de Node.js para instancias administradas de Lambda](lambda-managed-instances-nodejs-runtime.md).
+ Revise el [tiempo de ejecución de Python para instancias administradas de Lambda](lambda-managed-instances-python-runtime.md).
+ Revise el [tiempo de ejecución de .NET para instancias administradas de Lambda](lambda-managed-instances-dotnet-runtime.md).
+ Obtenga información sobre el [escalado de instancias administradas de Lambda](lambda-managed-instances-scaling.md).
# Tiempo de ejecución de Node.js para instancias administradas de Lambda
Para los tiempos de ejecución de Node.js, las instancias administradas de Lambda utilizan subprocesos de trabajo con ejecución basada en `async` o en `await` para gestionar las solicitudes simultáneas. La inicialización de la función se produce una vez por subproceso de trabajo. Las invocaciones simultáneas se gestionan en dos dimensiones: los subprocesos de trabajo proporcionan paralelismo entre las vCPU y la ejecución asíncrona proporciona concurrencia dentro de cada subproceso. Cada solicitud simultánea administrada por el mismo subproceso de trabajo comparte el mismo objeto controlador y el mismo estado global, por lo que es necesaria una gestión segura en el caso de varias solicitudes simultáneas.
## Simultaneidad máxima
El número máximo de solicitudes simultáneas que envía Lambda a cada entorno de ejecución se controla mediante el ajuste `PerExecutionEnvironmentMaxConcurrency` de la configuración de la función. Se trata de una configuración opcional y el valor predeterminado varía en función del tiempo de ejecución. Para los tiempos de ejecución de Node.js, el valor predeterminado es de 64 solicitudes simultáneas por vCPU, o puede configurar su propio valor. Lambda ajusta automáticamente el número de solicitudes simultáneas hasta el máximo configurado en función de la capacidad de cada entorno de ejecución para absorber esas solicitudes.
En el caso de Node.js, el número de solicitudes simultáneas que puede procesar cada entorno de ejecución viene determinado por el número de subprocesos de trabajo y la capacidad de cada subproceso de trabajo para procesar solicitudes simultáneas de forma asíncrona. El número predeterminado de subprocesos de trabajo viene determinado por la cantidad de vCPU disponibles, o puede configurar la cantidad de subprocesos de trabajo configurando la variable de entorno `AWS_LAMBDA_NODEJS_WORKER_COUNT`. Recomendamos utilizar controladores de funciones asíncronos, ya que permiten procesar varias solicitudes por subproceso de trabajo. Si su controlador de funciones es sincrónico, cada subproceso de trabajo solo puede procesar una solicitud a la vez.
## Creación de funciones para la concurrencia múltiple
Con un controlador de funciones asíncrono, cada trabajador en tiempo de ejecución procesa varias solicitudes de forma simultánea. Los objetos globales se compartirán en varias solicitudes simultáneas. En el caso de los objetos mutables, evite usar el estado global o utilice el `AsyncLocalStorage`.
Los clientes de AWS SDK son seguros para la modalidad asíncrona y no requieren una gestión especial.
**Ejemplo: estado global**
El siguiente código usa un objeto global que está mutado dentro del controlador de funciones. Esto no es seguro para el proceso de forma asíncrona.
```
let state = {
currentUser: null,
requestData: null
};
export const handler = async (event, context) => {
state.currentUser = event.userId;
state.requestData = event.data;
await processData(state.requestData);
// state.currentUser might now belong to a different request
return { user: state.currentUser };
};
```
La inicialización del objeto `state` dentro del controlador de funciones evita un estado global compartido.
```
export const handler = async (event, context) => {
let state = {
currentUser: event.userId,
requestData: event.data
};
await processData(state.requestData);
return { user: state.currentUser };
};
```
**Ejemplo: conexiones a bases de datos**
El código siguiente utiliza un objeto de cliente compartido que se comparte entre varias invocaciones. Según la biblioteca de conexiones utilizada, es posible que no sea segura para la concurrencia.
```
const { Client } = require('pg');
// Single connection created at init time
const client = new Client({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD
});
// Connect once during cold start
client.connect();
exports.handler = async (event) => {
// Multiple parallel invocations share this single connection = BAD
// With multi-concurrent Lambda, queries will collide
const result = await client.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
Un enfoque seguro para la concurrencia consiste en utilizar un grupo de conexiones. El grupo utiliza una conexión independiente para cada consulta simultánea de la base de datos.
```
const { Pool } = require('pg');
// Connection pool created at init time
const pool = new Pool({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
max: 20, // Max connections in pool
idleTimeoutMillis: 30000,
connectionTimeoutMillis: 2000
});
exports.handler = async (event) => {
// Pool gives each parallel invocation its own connection
const result = await pool.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
## Controladores de Node.js 22 basados en la devolución de llamada
Cuando utiliza Node.js 22, no puede usar un controlador de funciones basado en la devolución de llamada con instancias administradas de Lambda. Los controladores basados en la devolución de llamada son compatibles solo con las funciones de Lambda (predeterminadas). Para los tiempos de ejecución de Node.js 24 y versiones posteriores, los controladores de funciones basados en la devolución de llamada están obsoletos, tanto para Lambda (predeterminado) como para las instancias administradas de Lambda.
En su lugar, utilice un controlador de funciones `async` cuando utilice instancias administradas de Lambda. Para obtener más información, consulte [Definición de controlador de funciones de Lambda en Node.js](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html).
## Directorio /tmp compartido
El directorio `/tmp` se comparte entre todas las solicitudes simultáneas del entorno de ejecución. Las escrituras simultáneas en el mismo archivo pueden dañar los datos, por ejemplo, si otro proceso sobrescribe el archivo. Para solucionar este problema, implemente el bloqueo de archivos para los archivos compartidos o utilice nombres de archivo únicos por solicitud para evitar conflictos. Recuerde limpiar los archivos innecesarios para no agotar el espacio disponible.
## Registro
El intercalado de registros (las entradas de registro de diferentes solicitudes se intercalan en los registros) es normal en los sistemas simultáneos múltiples. Las funciones que utilizan instancias administradas de Lambda utilizan siempre el formato de registro JSON estructurado introducido con los [controles de registro avanzados](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Este formato incluye el `requestId`, lo que permite correlacionar las entradas de registro con una sola solicitud. Cuando utiliza el registrador de la `console`, el `requestId` se incluye automáticamente en cada entrada de registro. Para obtener información adicional, consulte [Uso de controles de registro avanzados de Lambda con Node.js](nodejs-logging.md#node-js-logging-advanced).
Las bibliotecas de registro populares de terceros, como [Winston](https://github.com/winstonjs/winston), normalmente incluyen la compatibilidad con el uso de la consola para la salida del registro.
## El contexto de la solicitud
El uso del `context.awsRequestId` proporciona un acceso asíncrono y seguro al identificador de solicitud de la solicitud actual.
Utilice el `context.xRayTraceId` para acceder al identificador de seguimiento de X-Ray. Esto proporciona un acceso simultáneo y seguro al identificador de seguimiento de la solicitud actual. Lambda no admite la variable de entorno `_X_AMZN_TRACE_ID` con las instancias administradas de Lambda. El identificador de seguimiento de X-Ray se propaga automáticamente cuando se utiliza AWS SDK.
Utilice `context.getRemainingTimeInMillis()` para detectar tiempos de espera. Para obtener más información, consulte [Gestión de errores y recuperación](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Inicialización y apagado
La inicialización de la función se produce una vez por subproceso de trabajo. Es posible que vea entradas de registro repetidas si su función emite registros durante la inicialización.
En el caso de las funciones de Lambda con extensiones, el entorno de ejecución emite una señal SIGTERM durante el cierre. Las extensiones utilizan esta señal para desencadenar tareas de limpieza, como vaciar los búferes. Las funciones de Lambda (predeterminadas) con extensiones también pueden suscribirse a la señal SIGTERM mediante `process.on()`. Esto no se admite para las funciones que utilizan instancias administradas de Lambda, ya que no se puede utilizar el `process.on()` con subprocesos de trabajo. Para obtener más información sobre el ciclo de vida del entorno de ejecución, consulte [Comprender el ciclo de vida del entorno de ejecución de Lambda](lambda-runtime-environment.md).
## Versiones de dependencias
Las instancias administradas de Lambda requieren las siguientes versiones de paquete como mínimo:
+ AWS SDK para JavaScript v3: versión 3.933.0 o posterior
+ AWS X-Ray SDK para Node.js: versión 3.12.0 o posterior
+ AWS Distro para OpenTelemetry, instrumentación para JavaScript: versión 0.8.0 o posterior
+ Powertools para AWS Lambda (TypeScript): versión 2.29.0 o posterior
## Powertools para AWS Lambda (TypeScript)
Powertools para AWS Lambda (TypeScript) es compatible con las instancias administradas de Lambda y proporciona utilidades para el registro, el seguimiento, las métricas y mucho más. Para obtener más información, consulte [Powertools para AWS Lambda (TypeScript)](https://github.com/aws-powertools/powertools-lambda-typescript).
## Siguientes pasos
+ Revise el [tiempo de ejecución de Java para instancias administradas de Lambda](lambda-managed-instances-java-runtime.md).
+ Revise el [tiempo de ejecución de Python para instancias administradas de Lambda](lambda-managed-instances-python-runtime.md).
+ Revise el [tiempo de ejecución de .NET para instancias administradas de Lambda](lambda-managed-instances-dotnet-runtime.md).
+ Obtenga información sobre el [escalado de instancias administradas de Lambda](lambda-managed-instances-scaling.md).
# Tiempo de ejecución de Python para instancias administradas de Lambda
El tiempo de ejecución de Lambda utiliza varios procesos de Python para gestionar las solicitudes simultáneas. Cada solicitud simultánea se ejecuta en un proceso independiente con su propio espacio de memoria e inicialización. Cada proceso gestiona una solicitud a la vez, de forma sincrónica. Los procesos no comparten memoria directamente, por lo que las variables globales, las cachés a nivel de módulo y los objetos individuales están aislados entre las solicitudes simultáneas.
## Configuración de concurrencia
El número máximo de solicitudes simultáneas que envía Lambda a cada entorno de ejecución se controla mediante el ajuste `PerExecutionEnvironmentMaxConcurrency` de la configuración de la función. Se trata de una configuración opcional y el valor predeterminado varía en función del tiempo de ejecución. Para los tiempos de ejecución de Python, el valor predeterminado es de 16 solicitudes simultáneas por vCPU, o puede configurar su propio valor. Este valor también determina el número de procesos utilizados por el tiempo de ejecución de Python. Lambda ajusta automáticamente el número de solicitudes simultáneas hasta el máximo configurado en función de la capacidad de cada entorno de ejecución para absorber esas solicitudes.
**importante**
El uso de la concurrencia basada en procesos significa que cada proceso de trabajo en tiempo de ejecución realiza su propia inicialización. El uso total de la memoria es igual a la memoria por proceso multiplicada por el número de procesos simultáneos. Si carga bibliotecas o conjuntos de datos de gran tamaño y tiene una concurrencia elevada, tendrá un gran consumo de memoria. Según su carga de trabajo, es posible que necesite ajustar la proporción de CPU con respecto a la memoria o utilizar una configuración de concurrencia más baja para evitar sobrepasar la memoria disponible. Puede utilizar la métrica de `MemoryUtilization` de CloudWatch para hacer un seguimiento del consumo de memoria.
## Creación de funciones para la concurrencia múltiple
Debido al modelo de concurrencia múltiple basado en procesos, las funciones de las instancias administradas de Lambda que utilizan tiempos de ejecución de Python no acceden a los recursos en memoria de forma simultánea desde varias invocaciones. No es necesario aplicar prácticas de codificación para garantizar la concurrencia en memoria.
## Directorio /tmp compartido
El directorio `/tmp` se comparte entre todas las solicitudes simultáneas del entorno de ejecución. Las escrituras simultáneas en el mismo archivo pueden dañar los datos, por ejemplo, si otro proceso sobrescribe el archivo. Para solucionar este problema, implemente el bloqueo de archivos para los archivos compartidos o utilice nombres de archivo únicos por proceso o por solicitud para evitar conflictos. Recuerde limpiar los archivos innecesarios para no agotar el espacio disponible.
## Registro
El intercalado de registros (las entradas de registro de diferentes solicitudes se intercalan en los registros) es normal en los sistemas simultáneos múltiples.
Las funciones que utilizan instancias administradas de Lambda utilizan siempre el formato de registro JSON estructurado introducido con los [controles de registro avanzados](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Este formato incluye el `requestId`, lo que permite correlacionar las entradas de registro con una sola solicitud. Cuando utiliza el módulo de `logging` de la biblioteca estándar de Python en Lambda, el `requestId` se incluye automáticamente en cada entrada de registro. Para obtener más información, consulte [Uso de los controles de registro avanzados de Lambda con Python](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced).
## El contexto de la solicitud
Utilice `context.aws_request_id` para acceder al identificador de solicitud de la solicitud actual.
Con los tiempos de ejecución de Python, puede usar la variable de entorno `_X_AMZN_TRACE_ID` para acceder al identificador de seguimiento de X-Ray con instancias administradas de Lambda. El identificador de seguimiento de X-Ray se propaga automáticamente cuando se utiliza AWS SDK.
Utilice `context.get_remaining_time_in_millis()` para detectar tiempos de espera. Para obtener más información, consulte [Gestión de errores y recuperación](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Inicialización y apagado
La inicialización de la función se produce una vez por proceso. Es posible que vea entradas de registro repetidas si su función emite registros durante la inicialización.
En el caso de las funciones de Lambda con extensiones, el entorno de ejecución emite una señal SIGTERM durante el cierre. Las extensiones utilizan esta señal para desencadenar tareas de limpieza, como vaciar los búferes. Puede suscribirse a los eventos SIGTERM para desencadenar tareas de limpieza de funciones, como cerrar las conexiones a las bases de datos. Para obtener más información sobre el ciclo de vida del entorno de ejecución, consulte [Comprender el ciclo de vida del entorno de ejecución de Lambda](lambda-runtime-environment.md).
## Versiones de dependencias
Las instancias administradas de Lambda requieren las siguientes versiones de paquete como mínimo:
+ Powertools para AWS Lambda (Python): versión 3.23.0 o posterior
## Powertools para AWS Lambda (Python)
Powertools para AWS Lambda (Python) es compatible con las instancias administradas de Lambda y proporciona utilidades para el registro, el seguimiento, las métricas y mucho más. Para obtener más información, consulte [Powertools para AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python).
## Siguientes pasos
+ Revise el [tiempo de ejecución de Java para instancias administradas de Lambda](lambda-managed-instances-java-runtime.md).
+ Revise el [tiempo de ejecución de Node.js para instancias administradas de Lambda](lambda-managed-instances-nodejs-runtime.md).
+ Revise el [tiempo de ejecución de .NET para instancias administradas de Lambda](lambda-managed-instances-dotnet-runtime.md).
+ Obtenga información sobre el [escalado de instancias administradas de Lambda](lambda-managed-instances-scaling.md).
# Tiempo de ejecución de .NET para instancias administradas de Lambda
Para los tiempos de ejecución de .NET, las instancias administradas de Lambda utilizan un único proceso .NET por entorno de ejecución. Se procesan varias solicitudes simultáneas mediante las tareas de .NET.
## Configuración de concurrencia
El número máximo de solicitudes simultáneas que envía Lambda a cada entorno de ejecución se controla mediante el ajuste `PerExecutionEnvironmentMaxConcurrency` de la configuración de la función. Se trata de una configuración opcional y el valor predeterminado varía en función del tiempo de ejecución. Para los tiempos de ejecución de .NET, el valor predeterminado es de 32 solicitudes simultáneas por vCPU, o puede configurar su propio valor. Lambda ajusta automáticamente el número de solicitudes simultáneas hasta el máximo configurado en función de la capacidad de cada entorno de ejecución para absorber esas solicitudes.
## Creación de funciones para la concurrencia múltiple
Debe aplicar las mismas prácticas de seguridad de concurrencia cuando utilice instancias administradas de Lambda que en cualquier otro entorno de concurrencia múltiple. Como el objeto controlador se comparte entre todas las tareas, cualquier estado mutable debe ser seguro para subprocesos. Esto incluye las colecciones, las conexiones a bases de datos y cualquier objeto estático que se modifique durante el procesamiento de la solicitud.
Los clientes de AWS SDK son seguros para subprocesos y no requieren una gestión especial.
**Ejemplo: grupos de conexiones a bases de datos**
El código siguiente utiliza un objeto de conexión de base de datos estático que se comparte entre solicitudes simultáneas. El objeto `SqlConnection` no es seguro para los subprocesos.
```
public class DBQueryHandler
{
// Single connection shared across threads - NOT SAFE
private SqlConnection connection;
public DBQueryHandler()
{
connection = new SqlConnection("your-connection-string-here");
connection.Open();
}
public string Handle(object input, ILambdaContext context)
{
using var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT ..."; // your query
using var reader = cmd.ExecuteReader();
...
}
}
```
Para solucionar este problema, use una conexión independiente para cada solicitud, extraída de un grupo de conexiones. Los proveedores de ADO.NET, por ejemplo `Microsoft.Data.SqlClient`, admiten automáticamente la agrupación de conexiones cuando se abre el objeto de conexión.
```
public class DBQueryHandler
{
public DBQueryHandler()
{
}
public string Handle(object input, ILambdaContext context)
{
using var connection = new SqlConnection("your-connection-string-here");
connection.Open();
using var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT ..."; // your query
using var reader = cmd.ExecuteReader();
...
}
}
```
**Ejemplo: colecciones**
Las recopilaciones estándar de .NET no son seguras para los subprocesos:
```
public class Handler
{
private static List items = new List();
private static Dictionary cache = new Dictionary();
public string FunctionHandler(object input, ILambdaContext context)
{
items.Add(context.AwsRequestId);
cache["key"] = input;
return "Success";
}
}
```
Utilice colecciones del espacio de nombres de `System.Collections.Concurrent` para garantizar la seguridad de la concurrencia:
```
public class Handler
{
private static ConcurrentBag items = new ConcurrentBag();
private static ConcurrentDictionary cache = new ConcurrentDictionary();
public string FunctionHandler(object input, ILambdaContext context)
{
items.Add(context.AwsRequestId);
cache["key"] = input;
return "Success";
}
}
```
## Directorio /tmp compartido
El directorio `/tmp` se comparte entre todas las solicitudes simultáneas del entorno de ejecución. Las escrituras simultáneas en el mismo archivo pueden dañar los datos, por ejemplo, si otra solicitud sobrescribe el archivo. Para solucionar este problema, implemente el bloqueo de archivos para los archivos compartidos o utilice nombres de archivo únicos por solicitud para evitar conflictos. Recuerde limpiar los archivos innecesarios para no agotar el espacio disponible.
## Registro
El intercalado de registros (las entradas de registro de diferentes solicitudes se intercalan en los registros) es normal en los sistemas simultáneos múltiples. Las funciones que utilizan instancias administradas de Lambda utilizan siempre el formato de registro JSON estructurado introducido con los [controles de registro avanzados](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Este formato incluye el `requestId`, lo que permite correlacionar las entradas de registro con una sola solicitud. Cuando utiliza el objeto `context.Logger` para generar registros, el `requestId` se incluye automáticamente en cada entrada de registro. Para obtener información adicional, consulte [Uso de los controles de registro avanzados de Lambda con .NET](csharp-logging.md#csharp-logging-advanced).
## El contexto de la solicitud
Utilice la propiedad `context.AwsRequestId` para acceder al identificador de solicitud de la solicitud actual.
Utilice la propiedad `context.TraceId` para acceder al identificador de seguimiento de X-Ray. Esto proporciona un acceso simultáneo y seguro al identificador de seguimiento de la solicitud actual. Lambda no admite la variable de entorno `_X_AMZN_TRACE_ID` con las instancias administradas de Lambda. El identificador de seguimiento de X-Ray se propaga automáticamente cuando se utiliza AWS SDK.
Utilice `ILambdaContext.RemainingTime` para detectar tiempos de espera. Para obtener más información, consulte [Gestión de errores y recuperación](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Inicialización y apagado
La inicialización de la función se produce una vez por entorno de ejecución. Los objetos creados durante la inicialización se comparten entre las solicitudes.
En el caso de las funciones de Lambda con extensiones, el entorno de ejecución emite una señal SIGTERM durante el cierre. Las extensiones utilizan esta señal para desencadenar tareas de limpieza, como vaciar los búferes. Puede suscribirse a los eventos SIGTERM para desencadenar tareas de limpieza de funciones, como cerrar las conexiones a las bases de datos. Para obtener más información sobre el ciclo de vida del entorno de ejecución, consulte [Comprender el ciclo de vida del entorno de ejecución de Lambda](lambda-runtime-environment.md).
## Versiones de dependencias
Las instancias administradas de Lambda requieren las siguientes versiones de paquete como mínimo:
+ Amazon.Lambda.Core: versión 2.7.1 o posterior
+ Amazon.Lambda.RuntimeSupport: versión 1.14.1 o posterior
+ OpenTelemetry.Instrumentation.AWSLambda: versión 1.14.0 o posterior
+ AWSXRayRecorder.Core: versión 2.16.0 o posterior
+ AWSSDK.Core: versión 4.0.0.32 o posterior
## Powertools para AWS Lambda (.NET)
[Powertools para AWS Lambda (.NET)](https://docs.aws.amazon.com/powertools/dotnet/) y [AWS Distro para OpenTelemetry: la instrumentación para DotNet](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) actualmente no admite instancias administradas de Lambda.
## Siguientes pasos
+ Revise el [tiempo de ejecución de Java para instancias administradas de Lambda](lambda-managed-instances-java-runtime.md).
+ Revise el [tiempo de ejecución de Node.js para instancias administradas de Lambda](lambda-managed-instances-nodejs-runtime.md).
+ Revise el [tiempo de ejecución de Python para instancias administradas de Lambda](lambda-managed-instances-python-runtime.md).
+ Obtenga información sobre el [escalado de instancias administradas de Lambda](lambda-managed-instances-scaling.md).
# Compatibilidad de Rust con instancias administradas de Lambda
## Configuración de concurrencia
El número máximo de solicitudes simultáneas que envía Lambda a cada entorno de ejecución se controla mediante el ajuste `PerExecutionEnvironmentMaxConcurrency` de la configuración de la función. Esta es una configuración opcional y el valor predeterminado para Rust es de 8 solicitudes simultáneas por vCPU; también puede configurar su propio valor. Este valor determina la cantidad de tareas de Tokio que genera el tiempo de ejecución y permanece fijo durante toda la vida útil del entorno de ejecución. Cada proceso de trabajo gestiona exactamente una solicitud en curso a la vez, sin multiplexación por proceso de trabajo. Lambda ajusta automáticamente el número de solicitudes simultáneas hasta el máximo configurado en función de la capacidad de cada entorno de ejecución para absorber esas solicitudes.
## Creación de funciones para la concurrencia múltiple
Debe aplicar las mismas prácticas de seguridad de subprocesos cuando utilice instancias administradas de Lambda que en cualquier otro entorno de subprocesos múltiples. Como el objeto controlador se comparte entre todos los subprocesos de trabajo, cualquier estado mutable debe ser seguro para subprocesos. Esto incluye las colecciones, las conexiones a bases de datos y cualquier objeto estático que se modifique durante el procesamiento de la solicitud.
Para habilitar el manejo de solicitudes simultáneas, agregue la marca de la característica `concurrency-tokio` a su archivo `Cargo.toml`.
```
[dependencies]
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }
```
El punto de entrada `lambda_runtime::run_concurrent(…)` debe llamarse dentro de un tiempo de ejecución de Tokio, que normalmente se proporciona mediante el atributo `#[tokio::main]` en su función principal. El cierre de su controlador debe implementar [https://doc.rust-lang.org/std/clone/trait.Clone.html](https://doc.rust-lang.org/std/clone/trait.Clone.html) \$1 [https://doc.rust-lang.org/std/marker/trait.Send.html](https://doc.rust-lang.org/std/marker/trait.Send.html). Esto permite que el marco de trabajo comparta el controlador entre varias tareas asíncronas de forma segura. Si no se cumplen esos límites, su código no se compilará.
Cuando necesite estado compartido en el código entre invocaciones (un grupo de conexiones a base de datos, una estructura de configuración), encapsúlelo en [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html) y clone el `Arc` en cada invocación.
Todos los clientes del SDK AWS para Rust son seguros para la concurrencia y no requieren un manejo especial.
### Ejemplo: cliente del SDK AWS
En el siguiente ejemplo, se utiliza un cliente de S3 para cargar un objeto en cada invocación. El cliente se clona directamente en el cierre sin `Arc`:
```
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
let s3_client = aws_sdk_s3::Client::new(&config);
run_concurrent(service_fn(move |event: LambdaEvent| {
let s3_client = s3_client.clone(); // cheap clone, no Arc needed
async move {
s3_client.put_object()
.bucket(&event.payload.bucket)
.key(&event.payload.key)
.body(event.payload.body.into_bytes().into())
.send()
.await?;
Ok(Response { message: "uploaded".into() })
}
}))
.await
```
### Ejemplo: grupos de conexiones a bases de datos
Cuando el controlador necesita acceder a estado compartido, como un cliente y una configuración, encapsúlelo en [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html) y clone el `Arc` en cada invocación.
```
#[derive(Debug)]
struct AppState {
dynamodb_client: DynamoDbClient,
table_name: String,
cache_ttl: Duration,
}
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
let state = Arc::new(AppState {
dynamodb_client: DynamoDbClient::new(&config),
table_name: std::env::var("TABLE_NAME").expect("TABLE_NAME must be set"),
cache_ttl: Duration::from_secs(300),
});
run_concurrent(service_fn(move |event: LambdaEvent| {
let state = state.clone();
async move { handle(event, state).await }
}))
.await
```
## Directorio /tmp compartido
El directorio `/tmp` se comparte entre todas las invocaciones simultáneas en el mismo entorno de ejecución. Utilice nombres de archivo únicos por invocación (por ejemplo, incluya el identificador de solicitud) o implemente un bloqueo de archivos explícito para evitar la corrupción de datos.
## Registro
El intercalado de registros (las entradas de registro de diferentes solicitudes se intercalan en los registros) es normal en los sistemas simultáneos múltiples. Las funciones que utilizan instancias administradas de Lambda admiten el formato de registro JSON estructurado mediante los [controles de registro avanzados](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) de Lambda. Este formato incluye el `requestId`, lo que permite correlacionar las entradas de registro con una sola solicitud. Para obtener información adicional, consulte [Implementación del registro avanzado con la caja Tracing](rust-logging.md#rust-logging-tracing).
## Contexto de la solicitud
El objeto `Context` se pasa directamente a cada invocación del controlador. Utilice `event.context.request_id` para acceder al identificador de solicitud de la solicitud actual.
Utilice el `event.context.xray_trace_id` para acceder al identificador de seguimiento de X-Ray. Lambda no admite la variable de entorno `_X_AMZN_TRACE_ID` con las instancias administradas de Lambda. El identificador de seguimiento de X-Ray se propaga automáticamente cuando se utiliza el SDK AWS para Rust.
Utilice `event.context.deadline` para detectar tiempos de espera: contiene el plazo de la invocación en milisegundos.
## Inicialización y apagado
La inicialización de la función se produce una vez por entorno de ejecución. Los objetos creados durante la inicialización se comparten entre las solicitudes.
En el caso de las funciones de Lambda con extensiones, el entorno de ejecución emite una señal SIGTERM durante el cierre. Las extensiones utilizan esta señal ppara activar tareas de limpieza, como el vaciado de búferes. `lambda_runtime` ofrece una función auxiliar para simplificar la configuración del manejo del apagado ordenado de señales, [https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html](https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html). Para obtener más información sobre el ciclo de vida del entorno de ejecución, consulte [Comprender el ciclo de vida del entorno de ejecución de Lambda](lambda-runtime-environment.md).
## Versiones de dependencias
Las instancias administradas de Lambda requieren la siguiente versión de paquete como mínimo:
+ `lambda_runtime`: versión 1.1.1 o posterior, con la característica `concurrency-tokio` habilitada
+ La versión mínima compatible de Rust (MSRV) es la 1.84.0.
# Redes para instancias administradas de Lambda
Cuando ejecuta las funciones de instancias administradas de Lambda, debe configurar la conectividad de red para permitir que sus funciones accedan a recursos externos a la VPC. Esto incluye servicios de AWS como Amazon S3 y DynamoDB. La conectividad también es necesaria para transmitir datos de telemetría a Registros de CloudWatch y X-Ray.
## Opciones de conectividad
Existen tres enfoques principales para configurar la conectividad de la VPC, cada uno con diferentes ventajas y desventajas en cuanto a costo, seguridad y complejidad.
## Una subred pública con puerta de enlace de Internet
Esta opción utiliza una subred pública con acceso directo a Internet a través de una puerta de enlace de Internet. Puede elegir entre configuraciones de IPv4 e IPv6.
### IPv4 con puerta de enlace de Internet
**Cómo configurar la conectividad IPv4 con una puerta de enlace de Internet**
1. Cree o utilice una subred pública existente con un bloque de CIDR IPv4.
1. Adjunte un gateway de Internet a su VPC.
1. Actualice la tabla de enrutamiento para enrutar el tráfico de `0.0.0.0/0` a la puerta de enlace de Internet.
1. Asegúrese de que los recursos tengan direcciones IPv4 públicas o direcciones IP elásticas asignadas.
1. Configure grupos de seguridad para permitir el tráfico saliente en los puertos necesarios.
Esta configuración proporciona conectividad bidireccional, lo que permite tanto las conexiones salientes desde sus funciones como las entrantes desde Internet.
### IPv6 con puerta de enlace de Internet
**Cómo configurar la conectividad IPv6 con una puerta de enlace de Internet**
1. Habilite IPv6 en su VPC.
1. Cree o utilice una subred pública existente con un bloque de CIDR IPv6 asignado.
1. Adjunte una puerta de enlace de Internet a su VPC (la misma puerta de enlace de Internet puede gestionar tanto IPv4 como IPv6).
1. Actualice la tabla de enrutamiento para enrutar el tráfico de `::/0` a la puerta de enlace de Internet.
1. Compruebe que los servicios de AWS a los que necesita acceder sean compatibles con IPv6 en su región.
1. Configure grupos de seguridad para permitir el tráfico saliente en los puertos necesarios.
Esta configuración proporciona conectividad bidireccional mediante el direccionamiento IPv6.
### IPv6 con puerta de enlace de Internet solo de salida
**Cómo configurar la conectividad IPv6 con una puerta de enlace de Internet solo de salida**
1. Habilite IPv6 en su VPC.
1. Cree o utilice una subred pública existente con un bloque de CIDR IPv6 asignado.
1. Asocie una puerta de enlace de Internet solo de salida a su VPC.
1. Actualice la tabla de enrutamiento para enrutar el tráfico de `::/0` a la puerta de enlace de Internet solo de salida.
1. Compruebe que los servicios de AWS a los que necesita acceder sean compatibles con IPv6 en su región.
1. Configure grupos de seguridad para permitir el tráfico saliente en los puertos necesarios.
Esta configuración proporciona conectividad solo de salida, lo que evita las conexiones entrantes desde Internet y permite que sus funciones inicien las conexiones salientes.
## Puntos de conexión de VPC
Los puntos de conexión de VPC le permiten conectar de forma privada su VPC a los servicios de AWS compatibles sin necesidad de una puerta de enlace de Internet, un dispositivo NAT, una conexión de VPN o una conexión de Direct Connect de AWS. El tráfico entre su VPC y el servicio AWS no sale de la red de Amazon.
**Cómo configurar puntos de conexión de VPC**
1. Abra la consola de Amazon VPC en [console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. En el panel de navegación, elija **Puntos de conexión**.
1. Elija **Crear punto de conexión**.
1. En **Service category** (Categoría de servicios), elija ** AWSServices** (Servicios de AWC).
1. En **Nombre del servicio**, seleccione el punto de conexión del servicio que necesita (por ejemplo, `com.amazonaws.region.s3` para Amazon S3).
1. En **VPC**, seleccione la VPC.
1. En **Subredes**, seleccione las subredes en las que quiere crear las interfaces de red de punto de conexión. Para lograr un mayor nivel de disponibilidad, seleccione subredes en varias zonas de disponibilidad.
1. En **Grupos de seguridad**, seleccione los grupos de seguridad que deban asociarse a las interfaces de red del punto de conexión. Los grupos de seguridad deben permitir el tráfico entrante desde el grupo de seguridad de la función en los puertos necesarios.
1. Seleccione **Crear punto de conexión**.
Repita estos pasos para cada servicio de AWS al que tengan que acceder sus funciones.
## Subred privada con puerta de enlace NAT
Esta opción utiliza una puerta de enlace NAT para proporcionar acceso a Internet para los recursos en las subredes privadas y, al mismo tiempo, mantener la privacidad de los recursos.
**Cómo configurar una subred privada con una puerta de enlace NAT**
1. Cree una subred pública (si aún no existe) con un bloque de CIDR.
1. Adjunte un gateway de Internet a su VPC.
1. Cree una puerta de enlace NAT en la subred pública y asigne una dirección IP elástica.
1. Actualice la tabla de enrutamiento de la subred pública para añadir una ruta: `0.0.0.0/0` → puerta de enlace de Internet.
1. Cree o utilice una subred privada existente con un bloque de CIDR.
1. Actualice la tabla de enrutamiento de la subred privada para añadir una ruta: `0.0.0.0/0` → puerta de enlace NAT.
1. Configure grupos de seguridad para permitir el tráfico saliente en los puertos necesarios.
Para obtener una alta disponibilidad, implemente una puerta de enlace NAT en cada zona de disponibilidad y configure las tablas de enrutamiento por zona de disponibilidad para usar la puerta de enlace NAT local. Esto evita los cargos por transferencia de datos entre zonas de disponibilidad y mejora la resiliencia.
## Elección de una opción de conectividad
Considere los siguientes factores cuando elija una opción de conectividad:
**Subred pública con puerta de enlace de Internet**
+ La configuración más sencilla con el costo más bajo.
+ Adecuada para entornos de desarrollo y pruebas.
+ Los recursos pueden recibir conexiones entrantes de Internet (por motivos de seguridad).
+ Compatible con IPv4 e IPv6.
**Puntos de conexión de VPC de**
+ Máxima seguridad, el tráfico permanece dentro de la red de AWS.
+ Menor latencia en comparación con el enrutamiento de Internet.
+ Recomendados para entornos de producción con requisitos de seguridad estrictos.
+ Mayor costo por punto de conexión, por zona de disponibilidad y por GB procesado.
+ Requieren un punto de conexión en cada zona de disponibilidad para una alta disponibilidad.
**Subred privada con puerta de enlace NAT**
+ Los recursos permanecen privados sin acceso entrante a Internet.
+ Patrón de arquitectura empresarial estándar.
+ Compatible con todo el tráfico de Internet IPv4.
+ Costo moderado con una puerta de enlace NAT por hora y cargos por procesamiento de datos.
+ Solo compatible con IPv4.
## Siguientes pasos
+ Obtenga información sobre los [proveedores de capacidad para las instancias administradas de Lambda](lambda-managed-instances-capacity-providers.md).
+ Conozca el [escalado de las instancias administradas de Lambda](lambda-managed-instances-scaling.md).
+ Revise las guías específicas del tiempo de ejecución para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) y [Python](lambda-managed-instances-python-runtime.md).
+ Conozca [la seguridad y los permisos de las instancias administradas de Lambda](lambda-managed-instances-security.md).
# Supervisión de instancias de administración de Lambda
Puede supervisar las instancias administradas de Lambda mediante las métricas de CloudWatch. Lambda publica automáticamente las métricas en CloudWatch para ayudarle a supervisar la utilización de los recursos, realizar un seguimiento de los costos y optimizar el rendimiento.
## Métricas disponibles
Las instancias administradas de Lambda proporcionan métricas en dos niveles: nivel del proveedor de capacidad y nivel del entorno de ejecución.
### Métricas a nivel del proveedor de capacidad
Las métricas a nivel del proveedor de capacidad proporcionan visibilidad de la utilización general de los recursos en las instancias. Estas métricas utilizan las siguientes dimensiones:
+ **CapacityProviderName**: el nombre de su proveedor de capacidad
+ **InstanceType**: el tipo de instancia de EC2
**Métricas de utilización de recursos:**
+ **CPUUtilization**: el porcentaje de utilización de la CPU en las instancias del proveedor de capacidad
+ **MemoryUtilization** el porcentaje de utilización de la memoria en las instancias del proveedor de capacidad
**Métricas de capacidad:**
+ **vCPUAvailable**: la cantidad de vCPU disponible en las instancias para su asignación (en recuento)
+ **MemoryAvailable**: la cantidad de memoria disponible en las instancias para su asignación (en bytes)
+ **vCPUAllocated**: la cantidad de vCPU asignada a las instancias para los entornos de ejecución (en recuento)
+ **MemoryAllocated**: la cantidad de memoria asignada a las instancias para los entornos de ejecución (en bytes)
### Métricas a nivel del entorno de ejecución
Las métricas a nivel del entorno de ejecución proporcionan visibilidad de la utilización de los recursos y la concurrencia de las funciones individuales. Estas métricas utilizan las siguientes dimensiones:
+ **CapacityProviderName**: el nombre de su proveedor de capacidad
+ **FunctionName**: el nombre de su función de Lambda
+ **Resource**: por recurso, puede ver métricas de una versión específica de alguna función.
**nota**
En el caso de las instancias administradas de Lambda (LMI), la dimensión `Resource` solo admite versiones de funciones. El formato es `:`.
**Métricas del entorno de ejecución disponibles:**
+ **ExecutionEnvironmentConcurrency**: la concurrencia máxima durante un período de muestra de 5 minutos
+ **ExecutionEnvironmentConcurrencyLimit**: el límite máximo de concurrencia por entorno de ejecución
+ **ExecutionEnvironmentCPUUtilization**: el porcentaje de uso de la CPU para los entornos de ejecución de la función
+ **ExecutionEnvironmentMemoryUtilization**: el porcentaje de uso de la memoria para los entornos de ejecución de la función
## Frecuencia y retención métricas
Las métricas de las instancias administradas de Lambda se publican a intervalos de 5 minutos y se conservan durante 15 meses.
## Ver métricas con CloudWatch
**Cómo ver las métricas de las instancias administradas de Lambda en la consola de CloudWatch**
1. Abra la consola de CloudWatch en [console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. En el panel de navegación, seleccione **Métricas**.
1. En la pestaña **Todas las métricas**, elija **AWS/Lambda**.
1. Elija la dimensión de la métrica que desea ver:
+ Para las métricas a nivel del proveedor de capacidad, filtre por **CapacityProviderName** e **Instancetype**.
+ Para las métricas a nivel del entorno de ejecución, filtre por **CapacityProviderName**, **FunctionName** y **Resource**.
1. Seleccione la métrica que quiere supervisar.
## Uso de métricas para optimizar el rendimiento
Supervise el uso de la CPU y la memoria para saber si sus funciones tienen el tamaño adecuado. Un uso elevado puede indicar la necesidad de tipos de instancias más grandes o de una mayor asignación de memoria a las funciones. Realice un seguimiento de las métricas de concurrencia para comprender el comportamiento de escalado e identificar posibles limitaciones.
Supervise las métricas de capacidad para verificar que haya suficientes recursos disponibles para sus cargas de trabajo. Las métricas de **vCPUAvailable** y **MemoryAvailable** lo ayudan a comprender la capacidad restante de sus instancias.
## Siguientes pasos
+ Obtenga información sobre el [escalado de instancias administradas de Lambda](lambda-managed-instances-scaling.md).
+ Revise las guías específicas del tiempo de ejecución para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) y [Python](lambda-managed-instances-python-runtime.md).
+ Configure la [conectividad de VPC para sus proveedores de capacidad](lambda-managed-instances-networking.md).
+ Conozca [la seguridad y los permisos de las instancias administradas de Lambda](lambda-managed-instances-security.md).
# Cuotas de instancias administradas de Lambda
En esta página, se describen las cuotas de servicio de las instancias administradas de AWS Lambda. Estas cuotas son independientes de las cuotas de AWS Lambda (predeterminadas). Algunas cuotas pueden aumentarse según la solicitud.
## Cuotas de solicitud de la API de Lambda
Estas cuotas controlan la velocidad a la que puede realizar llamadas a la API para administrar los proveedores de capacidad de las instancias administradas de Lambda. Los límites de velocidad de lectura y escritura de las API se aplican a todas las operaciones combinadas de los proveedores de capacidad, incluidas la creación, actualización, descripción y eliminación de los proveedores de capacidad.
| Recurso | Cuota |
| --- | --- |
| La tasa máxima combinada (solicitudes por segundo) para todas las API de lectura de proveedores de capacidad. | 15 solicitudes por segundo. No se puede aumentar. |
| La tasa máxima combinada (solicitudes por segundo) para todas las API de escritura de proveedores de capacidad. | 1 solicitud por segundo. No se puede aumentar. |
## Cuotas de recursos de instancias administradas de Lambda
Estas cuotas definen los límites de los recursos principales de las instancias administradas de Lambda de su cuenta de AWS. Regulan la cantidad de proveedores de capacidad que puede crear y la cantidad de versiones de funciones que se pueden asociar a cada proveedor de capacidad.
| Recurso | Cuota |
| --- | --- |
| Proveedores de capacidad | 1.000 El número máximo de proveedores de capacidad creado en una cuenta. |
| Versiones de funciones por proveedor de capacidad | 100 El número máximo de versiones de funciones por proveedor de capacidad. No se puede aumentar. |
## Cuotas de asignación de orígenes de eventos
Estas cuotas controlan los límites de rendimiento y configuración para procesar eventos de varios servicios de AWS en las instancias administradas de Lambda. Los límites de rendimiento garantizan un rendimiento predecible, mientras que los límites de recuento de las asignaciones ayudan a mantener la estabilidad del servicio. Las asignaciones de orígenes de eventos de las instancias administradas de Lambda admiten Amazon SQS, DynamoDB Streams, Amazon Kinesis Data Streams, Amazon MSK y Apache Kafka autoadministrado como orígenes de eventos.
| Recurso | Cuota |
| --- | --- |
| Rendimiento de la asignación de orígenes de eventos de SQS estándar en instancias administradas de Lambda | 5 MB por segundo. No se puede aumentar. |
| Rendimiento de la asignación de orígenes de eventos de Kafka estándar en instancias administradas de Lambda | 1 MB por segundo. No se puede aumentar. |
| Asignaciones de orígenes de eventos de Kafka estándar en instancias administradas de Lambda | 100 asignaciones de orígenes de eventos. No se puede aumentar. |
| Rendimiento de la asignación de orígenes de eventos de Kinesis en instancias administradas de Lambda | 25 MB por segundo. Se puede aumentar. |
| Rendimiento de la asignación de orígenes de eventos de DynamoDB en instancias administradas de Lambda | 10 MB por segundo. Se puede aumentar. |
| Rendimiento de la solicitud de invocación para las invocaciones asíncronas en instancias administradas de Lambda | 5 MB por segundo. Se puede aumentar. |
## Solicitud de aumento de cuota
Para las cuotas que se pueden aumentar, puede solicitar un aumento mediante la consola de Service Quotas.
**Cómo solicitar un aumento de cuota**
1. Abra la consola de Service Quotas en [console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/).
1. En el panel de navegación, elija **Servicios de AWS**.
1. Elija **AWS Lambda**.
1. Seleccione la cuota que quiere aumentar.
1. Elija **Solicitar aumento de cuota**.
1. Ingrese el nuevo valor de cuota y proporcione una justificación del aumento.
1. Seleccione **Solicitar**.
## Siguientes pasos
+ Obtenga información sobre los [proveedores de capacidad para las instancias administradas de Lambda](lambda-managed-instances-capacity-providers.md).
+ Conozca el [escalado de las instancias administradas de Lambda](lambda-managed-instances-scaling.md).
+ Revise las guías específicas del tiempo de ejecución para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) y [Python](lambda-managed-instances-python-runtime.md).
+ Configure la [conectividad de VPC para sus proveedores de capacidad](lambda-managed-instances-networking.md).
# Prácticas recomendadas para las instancias administradas de Lambda
## Configuración de los proveedores de capacidad
**Separe los proveedores de capacidad por nivel de confianza.** Cree diferentes proveedores de capacidad para cargas de trabajo con diferentes requisitos de seguridad. Todas las funciones asignadas al mismo proveedor de capacidad deben ser de confianza mutua, ya que los proveedores de capacidad sirven de límite de seguridad.
**Utilice nombres descriptivos.** Denomine los proveedores de capacidad para indicar claramente su uso previsto y su nivel de confianza (por ejemplo, `production-trusted`, `dev-sandbox`). Esto ayuda a los equipos a entender el propósito y la postura de seguridad de cada proveedor de capacidad.
**Use varias zonas de disponibilidad.** Especifique las subredes entre varias zonas de disponibilidad cuando cree los proveedores de capacidad. Lambda lanza tres instancias de forma predeterminada para la resiliencia de las zonas de disponibilidad, lo que garantiza una alta disponibilidad para sus funciones.
## Selección del tipo de instancia
**Deje que Lambda elija los tipos de instancia.** De forma predeterminada, Lambda elige los mejores tipos de instancias para su carga de trabajo. Le recomendamos que deje que las instancias administradas de Lambda elijan los tipos de instancia por usted, ya que restringir la cantidad de tipos de instancias posibles puede reducir la disponibilidad.
**Especifique los tipos de instancias según los requisitos específicos.** Si tiene requisitos de hardware específicos, establezca los tipos de instancias permitidos en una lista de instancias compatibles. Por ejemplo:
+ Para las aplicaciones que requieren un ancho de banda de la red elevado, seleccione varios tipos de instancias n.
+ Para entornos de pruebas o desarrollo con limitaciones de costos, elija tipos de instancias más pequeños, como m7a.large.
## Función de configuración
**Elija la configuración de memoria y vCPU adecuada.** Seleccione configuraciones de memoria y vCPU que admitan varias ejecuciones simultáneas de su función. El tamaño mínimo de función admitido es de 2 GB y 1 vCPU.
+ Para las aplicaciones de Python, elija una proporción más alta de memoria con respecto a las vCPU (por ejemplo, 4 a 1 u 8 a 1) debido a la forma en que Python gestiona la concurrencia múltiple.
+ Para operaciones con uso intensivo de la CPU o funciones que realizan poca E/S, elija más de una vCPU
+ En el caso de las aplicaciones con un uso intensivo de E/S, como los servicios web o los trabajos por lotes, la concurrencia múltiple ofrece la mayor ventaja
**Configure la máxima concurrencia de forma adecuada.** Lambda elige valores predeterminados razonables para una concurrencia máxima que equilibre el consumo de recursos y el rendimiento. Ajuste esta configuración en función del uso de recursos de la función:
+ Aumente la concurrencia máxima (hasta 64 por vCPU) si las invocaciones de sus funciones utilizan muy poca CPU.
+ Reduzca la concurrencia máxima si la aplicación consume una gran cantidad de memoria y muy poca CPU.
Tenga en cuenta que los entornos de ejecución con una concurrencia muy baja pueden experimentar limitaciones y dificultades de escalado.
## Scaling configuration (Escalado de configuración)
**Establezca un objetivo adecuado de utilización de los recursos.** De forma predeterminada, Lambda mantiene suficiente margen de maniobra para que el tráfico se duplique en 5 minutos sin limitaciones. Ajústelo en función de las características de su carga de trabajo:
+ Para cargas de trabajo muy estables o aplicaciones que no sean sensibles a las limitaciones, fije el objetivo en un nivel alto para lograr una mayor utilización y reducir los costos.
+ Para cargas de trabajo con posibles ampliaciones de tráfico, establezca los objetivos de recursos en un nivel bajo para mantener un margen de maniobra adicional.
**Planifique el crecimiento del tráfico.** Si el tráfico se incrementa a más del doble en 5 minutos, pueden presentarse limitaciones mientras Lambda aumenta las instancias y los entornos de ejecución. Diseñe su aplicación para gestionar las posibles limitaciones durante los períodos de escalado vertical rápido.
## Seguridad
**Aplique el privilegio mínimo a los permisos de PassCapacityProvider.** Otorgue permisos de `lambda:PassCapacityProvider` solo a los proveedores de capacidad necesarios. Utilice los permisos a nivel de recursos para restringir los proveedores de capacidad que los usuarios pueden asignar a las funciones.
**Supervise el uso de los proveedores de capacidad.** Utilice AWS CloudTrail para supervisar las asignaciones de los proveedores de capacidad y los patrones de acceso. Esto ayuda a identificar los intentos de acceso no autorizados y garantiza el cumplimiento de las políticas de seguridad.
**Separe las cargas de trabajo que no son de confianza.** No confíe en los contenedores para el aislamiento de seguridad entre cargas de trabajo que no sean de confianza. Utilice distintos proveedores de capacidad para separar las cargas de trabajo en las que no se confíe mutuamente.
## Optimización de costos
**Aproveche las opciones de precios de EC2.** Aproveche los Savings Plans y las instancias reservadas de EC2 para reducir los costos. Estas opciones de precios se aplican al cómputo de EC2 subyacente (no se descuenta la tarifa de administración del 15 %).
**Optimice para cargas de trabajo estables.** Las instancias administradas de Lambda son las más adecuadas para funciones de estado estable con tráfico predecible de gran volumen. Para los patrones con ampliación de tráfico, Lambda (predeterminado) puede ser más rentable.
**Supervise la utilización de recursos.** Realice un seguimiento de las métricas de CloudWatch para comprender la utilización de la CPU y la memoria. Ajuste la asignación de memoria de las funciones y la selección del tipo de instancia según los patrones de uso reales para optimizar los costos.
## Supervisión y observabilidad
**Supervise las métricas de los proveedores de capacidad.** Realice un seguimiento de las métricas a nivel del proveedor de capacidad, incluidas CPUUtilization, MemoryUtilization, vCPUAvailable y MemoryAvailable para verificar que haya suficientes recursos disponibles para sus cargas de trabajo.
**Supervise las métricas del entorno de ejecución.** Realice un seguimiento de las métricas a nivel del entorno de ejecución, incluidas ExecutionEnvironmentConcurrency y ExecutionEnvironmentConcurrencyLimit, para comprender el comportamiento de escalado e identificar posibles limitaciones.
**Configure las alarmas de CloudWatch.** Cree alarmas de CloudWatch para las métricas clave a fin de identificar los problemas de forma proactiva:
+ Uso elevado de la CPU o la memoria
+ Poca capacidad disponible
+ Aproximación de los límites de concurrencia
## Consideraciones específicas del lenguaje
**Siga las prácticas recomendadas específicas del lenguaje.** Cada lenguaje de programación gestiona la concurrencia múltiple de forma diferente. Consulte las guías específicas del lenguaje para obtener recomendaciones detalladas:
+ **Java:** utilice colecciones seguras para subprocesos, `AtomicInteger` y `ThreadLocal`para el estado específico de la solicitud.
+ **Node.js:** utilice InvokeStore para todos los estados específicos de la solicitud y evite las variables globales.
+ **Python:** utilice nombres de archivo únicos en `/tmp` con los identificadores de solicitud y considere el aislamiento de la memoria basado en procesos.
+ **Rust:** utilice `run_concurrent` en lugar de `run`, con la característica `concurrency-tokio` habilitada. El controlador debe ser `Clone` \$1 `Send`.
**Haga pruebas para detectar problemas de seguridad y concurrencia de los subprocesos.** Antes de implementarlas en producción, compruebe minuciosamente sus funciones para detectar problemas de seguridad de los subprocesos, condiciones de carrera y aislamiento de estado adecuado bajo carga simultánea.
## Siguientes pasos
+ Obtenga información sobre los [proveedores de capacidad para las instancias administradas de Lambda](lambda-managed-instances-capacity-providers.md).
+ Conozca el [escalado de las instancias administradas de Lambda](lambda-managed-instances-scaling.md).
+ Revise las guías específicas del tiempo de ejecución para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) y [Python](lambda-managed-instances-python-runtime.md).
+ Configure la [conectividad de VPC para sus proveedores de capacidad](lambda-managed-instances-networking.md).
+ Supervise las instancias administradas de Lambda con las [métricas de CloudWatch](lambda-managed-instances-monitoring.md).
# Solución de problemas de las instancias administradas de Lambda
## Problemas de limitación y escalado
### Tasas elevadas de error durante el escalado vertical
**Problema:** se producen errores de limitación (HTTP 429) cuando el tráfico aumenta rápidamente.
**Causa:** las instancias administradas de Lambda se escalan de forma asíncrona en función del uso de los recursos de la CPU y de la saturación de la concurrencia múltiple. Si el tráfico más que se duplica en 5 minutos, es posible que experimente limitaciones a medida que Lambda escala verticalmente las instancias y los entornos de ejecución para satisfacer la demanda.
**Solución:**
+ **Ajuste el objetivo de utilización de los recursos:** si su carga de trabajo tiene patrones de tráfico predecibles, establezca un objetivo de utilización de los recursos más bajo para mantener un margen de maniobra adicional ante las ampliaciones de tráfico.
+ **Capacidad de precalentamiento:** si el tráfico se incrementa de forma planificada, aumente el tráfico gradualmente durante un período más largo para que el escalado pueda mantener el ritmo.
+ **Supervise las métricas de escalado:** haga un seguimiento de las métricas de error de limitación para comprender el motivo de los problemas de limitación y escalado de la capacidad.
+ **Revise la configuración de la función:** asegúrese de que la memoria de las funciones y la configuración de la vCPU admitan varias ejecuciones simultáneas. Aumente la memoria de las funciones o la asignación de vCPU, si es necesario.
### Reducción vertical lenta
**Problema:** las instancias tardan mucho tiempo en reducirse verticalmente una vez que disminuye el tráfico.
**Causa:** las instancias administradas de Lambda se reducen verticalmente de forma gradual para mantener la disponibilidad y evitar cambios rápidos de capacidad que podrían afectar el rendimiento.
**Solución:**
Este es el comportamiento esperado. Lambda reduce verticalmente las instancias de forma conservadora para garantizar la estabilidad. Supervise las métricas de CloudWatch para realizar un seguimiento del número de instancias en ejecución.
## Problemas de concurrencia
### Los entornos de ejecución con poca concurrencia experimentan limitaciones.
**Problema:** sus funciones presentan limitaciones a pesar de tener capacidad disponible.
**Causa:** los entornos de ejecución con una concurrencia máxima muy baja pueden tener dificultades para lograr un escalado eficaz. Las instancias administradas de Lambda están diseñadas para aplicaciones simultáneas múltiples.
**Solución:**
+ **Aumente la concurrencia máxima:** si las invocaciones de sus funciones utilizan muy poca CPU, aumente la configuración de concurrencia máxima a 64 por vCPU.
+ **Optimice el código de la función:** revise el código de la función para reducir el consumo de CPU por invocación, lo que permitirá una mayor concurrencia.
+ **Ajuste la memoria de la función y la vCPU:** asegúrese de que su función tenga recursos suficientes para gestionar varias invocaciones simultáneas.
### Problemas de seguridad de los subprocesos (tiempo de ejecución de Java)
**Problema:** la función de Java produce resultados incorrectos o experimenta condiciones de carrera bajo carga.
**Causa:** varios subprocesos ejecutan el método del controlador simultáneamente y el estado compartido no es seguro para subprocesos.
**Solución:**
+ Utilice `AtomicInteger` o `AtomicLong` para contadores en lugar de tipos primitivos.
+ Reemplace `HashMap` por `ConcurrentHashMap`
+ Utilice `Collections.synchronizedList()` para encapsular `ArrayList`.
+ Utilice `ThreadLocal` para el estado específico de una solicitud.
+ Acceda a los identificadores de seguimiento desde el objeto de contexto de Lambda, no desde las variables de entorno.
Para obtener una guía detallada, consulte la documentación sobre el [tiempo de ejecución de Java para instancias administradas de Lambda](lambda-managed-instances-java-runtime.md).
### Problemas de aislamiento de estados (tiempo de ejecución de Node.js)
**Problema:** la función de Node.js devuelve datos de diferentes solicitudes o los datos están dañados.
**Causa:** las variables globales se comparten en las invocaciones simultáneas del mismo subproceso de trabajo. Cuando las operaciones asíncronas ceden el control, otras invocaciones pueden modificar el estado compartido.
**Solución:**
+ Instale y utilice `@aws/lambda-invoke-store` para todos los estados específicos de solicitud.
+ Sustituya las variables globales por `InvokeStore.set()` y `InvokeStore.get()`.
+ Utilice nombres de archivo únicos en `/tmp` junto con los identificadores de solicitud.
+ Acceda a los identificadores de seguimiento mediante `InvokeStore.getXRayTraceId()` en lugar de utilizar variables de entorno.
Para obtener una guía detallada, consulte la documentación sobre el [tiempo de ejecución de Node.js para instancias administradas de Lambda](lambda-managed-instances-nodejs-runtime.md).
### Conflictos de archivos (tiempo de ejecución de Python)
**Problema:** la función de Python lee datos incorrectos de los archivos en `/tmp`.
**Causa:** varios procesos comparten el directorio `/tmp`. Las escrituras simultáneas en el mismo archivo pueden dañar los datos.
**Solución:**
+ Utilice nombres de archivo únicos con los identificadores de solicitud: `/tmp/request_{context.request_id}.txt`.
+ Utilice el bloqueo de archivos con `fcntl.flock()` para los archivos compartidos.
+ Limpie los archivos temporales con `os.remove()` después de su uso.
Para obtener una guía detallada, consulte la documentación sobre el [tiempo de ejecución de Python para instancias administradas de Lambda](lambda-managed-instances-python-runtime.md).
## Problemas de rendimiento
### Utilización elevada de memoria
**Problema:** sus funciones experimentan un uso elevado de memoria o errores de memoria insuficiente.
**Causa:** cada solicitud simultánea en Python se ejecuta en un proceso independiente con su propio espacio de memoria. El uso total de memoria es igual a la memoria por proceso multiplicada por los procesos simultáneos.
**Solución:**
+ Supervise la métrica de `MemoryUtilization` en CloudWatch.
+ Reduzca la configuración de `MaxConcurrency` si el uso de memoria se acerca al límite de memoria de la función.
+ Aumente la asignación de memoria de las funciones para admitir una mayor concurrencia.
+ Optimice el uso de la memoria; para ello, cargue los datos bajo demanda en lugar de durante la inicialización.
### Rendimiento incoherente
**Problema:** el rendimiento de las funciones varía considerablemente entre las invocaciones.
**Causa:** Lambda puede seleccionar distintos tipos de instancias en función de la disponibilidad, o las funciones pueden ejecutarse en instancias con una disponibilidad de recursos variable.
**Solución:**
+ **Especifique los tipos de instancia permitidos:** si tiene requisitos de rendimiento específicos, configure los tipos de instancias permitidos en su proveedor de capacidad para limitar los tipos de instancias que Lambda puede seleccionar.
+ **Supervise las métricas a nivel de instancia:** realice un seguimiento de `CPUUtilization` y `MemoryUtilization` a nivel del proveedor de capacidad, para identificar las limitaciones de los recursos.
+ **Revise las métricas de capacidad:** compruebe `vCPUAvailable` y `MemoryAvailable` para asegurarse de que haya suficientes recursos disponibles en sus instancias.
## Problemas con los proveedores de capacidad
### La versión de la función no se ACTIVA.
**Problema:** la versión de la función permanece en estado pendiente tras su publicación.
**Causa:** Lambda está en proceso de lanzamiento de instancias administradas e inicia entornos de ejecución. Este proceso lleva tiempo, especialmente en el caso de la primera versión de la función en un nuevo proveedor de capacidad.
**Solución:**
Espere a que Lambda complete el proceso de inicialización. Lambda lanza tres instancias de forma predeterminada para garantizar la resiliencia de la zona de disponibilidad e inicia tres entornos de ejecución antes de marcar la versión de la función como ACTIVA. Esta operación suele tardar varios minutos.
### No se puede eliminar el proveedor de capacidad.
**Problema:** recibe un error cuando intenta eliminar un proveedor de capacidad.
**Causa:** no puede eliminar un proveedor de capacidad que tenga versiones de funciones asociadas.
**Solución:**
1. Identifique todas las versiones de funciones mediante el proveedor de capacidad con la API de `ListFunctionVersionsByCapacityProvider`.
1. Elimine o actualice esas versiones de funciones para eliminar la asociación con los proveedores de capacidad.
1. Reintente eliminar el proveedor de capacidad.
### Mensajes de error genéricos durante la publicación de la función
**Problema:** cuando publica funciones, aparecen mensajes de error genéricos como «Se ha producido un error interno durante la publicación».
**Solución:**
+ **Compruebe los permisos de IAM:** asegúrese de tener el permiso `lambda:PassCapacityProvider` para el proveedor de capacidad que intenta utilizar.
+ **Verifique la configuración del proveedor de capacidad:** confirme que su proveedor de capacidad esté en estado ACTIVO mediante la API de `GetCapacityProvider`.
+ **Revise la configuración de la VPC:** asegúrese de que las subredes y los grupos de seguridad especificados en su proveedor de capacidad estén configurados correctamente y sean accesibles.
+ **Compruebe los registros de AWS CloudTrail:** revise los registros de CloudTrail para obtener información detallada sobre los errores de la operación fallida.
## Problemas de supervisión y observabilidad
### Métricas de CloudWatch faltantes
**Problema:** no ve las métricas esperadas en CloudWatch para su proveedor de capacidad o sus funciones.
**Causa:** las métricas se publican a intervalos de 5 minutos. Es posible que los nuevos proveedores de capacidad o funciones no dispongan de métricas de forma inmediata.
**Solución:**
Espere al menos de 5 a 10 minutos después de publicar la versión de una función antes de esperar que las métricas aparezcan en CloudWatch. Compruebe que busca el espacio de nombres (`AWS/Lambda`) y las dimensiones (`CapacityProviderName`, `FunctionName` o `InstanceType`) correctos.
### No se pueden encontrar los registros de CloudWatch.
**Problema:** la función se ejecuta correctamente, pero no puede encontrar los registros en Registros de CloudWatch.
**Causa:** las instancias administradas de Lambda se ejecutan en la VPC y requieren conectividad de red para enviar los registros a Registros de CloudWatch. Sin una configuración de conectividad de VPC adecuada, sus funciones no pueden llegar al punto de conexión del servicio Registros de CloudWatch.
**Solución:**
Configure la conectividad de la VPC para permitir que sus funciones envíen registros a Registros de CloudWatch. Tiene tres opciones:
**Opción 1: punto de conexión de VPC para Registros de CloudWatch (recomendado para producción)**
1. Abra la consola de Amazon VPC en [console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. En el panel de navegación, elija **Puntos de conexión**.
1. Elija **Crear punto de conexión**.
1. En **Service category** (Categoría de servicios), elija ** AWSServices** (Servicios de AWC).
1. En **Nombre del servicio**, seleccione `com.amazonaws.region.logs` (sustituya la `region` por su región de AWS).
1. En **VPC**, seleccione la VPC utilizada por el proveedor de capacidad.
1. En **Subredes**, seleccione las subredes en las que quiere crear las interfaces de red de punto de conexión. Para lograr un mayor nivel de disponibilidad, seleccione subredes en varias zonas de disponibilidad.
1. En **Grupos de seguridad**, seleccione los grupos de seguridad que permitan el tráfico HTTPS entrante (puerto 443) desde el grupo de seguridad de su función.
1. Habilite **DNS privado** para el punto de conexión.
1. Seleccione **Crear punto de conexión**.
**Opción 2: subred pública con puerta de enlace de Internet**
Si su proveedor de capacidad utiliza subredes públicas, asegúrese de lo siguiente:
1. La puerta de enlace de Internet está asociada a su VPC.
1. La tabla de enrutamiento dirige el tráfico de `0.0.0.0/0` a la puerta de enlace de Internet.
1. Los grupos de seguridad permiten el tráfico HTTPS saliente en el puerto 443.
**Opción 3: subred privada con puerta de enlace NAT**
Si su proveedor de capacidad utiliza subredes privadas, asegúrese de lo siguiente:
1. Existe una puerta de enlace NAT en una subred pública.
1. La tabla de enrutamiento de la subred privada enruta el tráfico de `0.0.0.0/0` hacia la puerta de enlace NAT.
1. La tabla de enrutamiento de la subred pública enruta el tráfico de `0.0.0.0/0` hacia una puerta de enlace de Internet.
1. Los grupos de seguridad permiten el tráfico HTTPS saliente en el puerto 443.
Para obtener una guía detallada sobre las opciones de conectividad de la VPC, consulte [Conectividad de VPC para instancias administradas de Lambda](lambda-managed-instances-networking.md).
### Dificultad para correlacionar los registros de solicitudes simultáneas
**Problema:** los registros de las distintas solicitudes están intercalados, lo que dificulta el seguimiento de las solicitudes individuales.
**Causa:** el intercalado de registros es lo esperado y es un comportamiento estándar en los sistemas de concurrencia múltiple.
**Solución:**
+ **Utilice un registro estructurado con formato JSON:** incluya el identificador de solicitud en todas las declaraciones de registro.
+ **Java:** utilice Log4j con `ThreadContext` para incluir automáticamente el identificador de solicitud.
+ **Node.js:** utilice el `console.log()` con el formato JSON e incluya `InvokeStore.getRequestId()`.
+ **Python:** utilice el módulo de registro estándar con formato JSON e incluya el `context.request_id`.
Para obtener una guía detallada, consulte las páginas de documentación específicas de los tiempos de ejecución.
## Cómo obtener ayuda adicional
Si sigue teniendo problemas después de probar estas soluciones, pruebe lo siguiente:
1. **Revise las métricas de CloudWatch:** compruebe las métricas del proveedor de capacidad y del entorno de ejecución para identificar las limitaciones de recursos o los problemas de escalado.
1. **Compruebe los registros de AWS CloudTrail:** revise los registros de CloudTrail para obtener información detallada sobre las llamadas a la API y los errores.
1. **Póngase en contacto con el servicio de asistencia de AWS:** si no puede resolver el problema, póngase en contacto con el servicio de asistencia de AWS con los detalles de la configuración del proveedor de capacidad, la configuración de las funciones y los mensajes de error específicos que aparecen.
## Siguientes pasos
+ Obtenga información sobre los [proveedores de capacidad para las instancias administradas de Lambda](lambda-managed-instances-capacity-providers.md).
+ Conozca el [escalado de las instancias administradas de Lambda](lambda-managed-instances-scaling.md).
+ Revise las guías específicas del tiempo de ejecución para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) y [Python](lambda-managed-instances-python-runtime.md).
+ Supervise las instancias administradas de Lambda con las [métricas de CloudWatch](lambda-managed-instances-monitoring.md).
+ Revise las [prácticas recomendadas para las instancias administradas de Lambda](lambda-managed-instances-best-practices.md).