# Instâncias gerenciadas do Lambda
As instâncias gerenciadas do Lambda permitem que você execute funções do Lambda em suas instâncias do Amazon EC2 de geração atual, incluindo Graviton4, instâncias otimizadas para rede e outras opções de computação especializadas, sem gerenciar ciclos de vida de instâncias, correções de runtimes de sistemas operacionais e linguagens, roteamento, balanceadores de carga ou políticas de escalabilidade. Com as instâncias gerenciadas do Lambda, você se beneficia das vantagens dos preços do EC2, incluindo o EC2 Savings Plans e as instâncias reservadas.
Para ver uma lista dos tipos de instância com suporte, acesse a página [Preços do AWS Lambda](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) e selecione sua Região da AWS.
## Capacidades gerais
As instâncias gerenciadas do Lambda fornecem os recursos a seguir:
+ **Escolha instâncias adequadas**: selecione [instâncias apropriadas](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) com base nos requisitos de performance e custo, incluindo acesso às CPUs mais recentes, como a Graviton4, proporções configuráveis de memória e CPU e rede de alta largura de banda.
+ **Provisionamento automático**: a AWS provisiona automaticamente as instâncias adequadas e acelera os ambientes de execução de funções.
+ **Escalabilidade dinâmica**: as instâncias escalam dinamicamente com base nos padrões de tráfego da sua função.
+ **Experiência totalmente gerenciada**: a AWS lida com gerenciamento, escalabilidade, aplicação de patches e roteamento da infraestrutura, com as mesmas integrações abrangentes de origem de eventos com as quais você está familiarizado.
## Quando usar instâncias gerenciadas do Lambda
Considere as instâncias gerenciadas do Lambda para os casos de uso a seguir:
+ **Workloads de alto volume previsíveis**: ideais para workloads em estado fixo, sem picos de tráfego inesperados. Por padrão, as instâncias gerenciadas do Lambda escalam para lidar com a duplicação do tráfego em cinco minutos.
+ **Aplicações essenciais para a performance**: acesso às CPUs mais recentes, taxas variáveis de memória e CPU e alto throughput de rede
+ **Requisitos regulatórios**: necessidades granulares de governança com controle sobre posicionamento de instâncias e VPC
+ **Variedade de aplicações**: orientados por eventos, processamento de mídia/dados, aplicações da Web e workloads legadas migrando para a tecnologia sem servidor
## Como funciona
As instâncias gerenciadas do Lambda usam provedores de capacidade como base para a execução das suas funções:
1. **Crie um provedor de capacidade**: defina onde suas funções serão executadas especificando a configuração da VPC e, opcionalmente, os requisitos de instância e a configuração de escalabilidade
1. **Crie sua função**: crie funções do Lambda normalmente e anexe-as a um provedor de capacidade
1. **Publique uma versão da função**: as versões de funções se tornam ativas nas instâncias do provedor de capacidade depois de publicadas
Quando você publica uma versão da função com um provedor de capacidade, o Lambda executa instâncias gerenciadas em sua conta. Ele executa três instâncias por padrão para resiliência de AZ e inicia três ambientes de execução antes de marcar a versão da sua função como ATIVA. Se você anexar uma função a um provedor de capacidade existente que já esteja executando outras funções, o Lambda poderá não gerar novas instâncias caso as instâncias disponíveis já tenham capacidade para acomodar os ambientes de execução da nova função.
## Modelo de simultaneidade
As instâncias gerenciadas do Lambda oferecem suporte a várias invocações simultâneas, em que um ambiente de execução pode lidar com várias invocações ao mesmo tempo. Isso difere do tipo de computação do Lambda (padrão), que fornece um único modelo de simultaneidade em que um ambiente de execução pode executar no máximo uma invocação por vez. A multissimultaneidade proporciona uma melhor utilização de suas instâncias do EC2 subjacentes e é especialmente benéfica para aplicações com alto nível de E/S, como serviços da Web ou trabalhos em lote. Essa mudança no modelo de execução significa que a segurança de thread, o gerenciamento de estado e o isolamento de contexto devem ser tratados de forma diferente, dependendo do runtime.
## Locação e isolamento
O tipo de computação do Lambda (padrão) é multilocatário, fazendo uso da tecnologia Firecracker microVM para fornecer isolamento entre ambientes de execução executados em frotas compartilhadas do Lambda. As instâncias gerenciadas do Lambda são executadas em sua conta, fornecendo as mais recentes opções de hardware e preços do EC2. As instâncias gerenciadas usam contêineres executados em instâncias Nitro do EC2 para fornecer isolamento, em vez do Firecracker. Os provedores de capacidade servem como limite de segurança para as funções do Lambda. As funções são executadas em contêineres dentro das instâncias.
### Noções básicas sobre instâncias gerenciadas
As funções das instâncias gerenciadas do Lambda são executadas em instâncias gerenciadas de EC2 em sua conta. Essas instâncias são totalmente gerenciadas pelo Lambda, o que significa que você tem permissões restritas sobre elas em comparação com as instâncias padrão do EC2. É possível identificar instâncias gerenciadas do Lambda em sua conta da forma a seguir:
+ A presença do campo `Operator` na saída `DescribeInstances` do EC2
+ A tag `aws:lambda:capacity-provider` na instância
Não é possível realizar operações padrão do EC2 diretamente nessas instâncias, como encerrá-las manualmente. Para destruir instâncias gerenciadas, exclua o provedor de capacidade associado. O Lambda então encerrará as instâncias como parte do processo de exclusão do provedor de capacidade.
## Preços
As instâncias gerenciadas do Lambda usam uma definição de preços baseada em EC2 com uma taxa de gerenciamento de 15% sobre o custo da instância do EC2. Esse modelo de preços oferece suporte ao EC2 Savings Plans, instâncias reservadas e quaisquer outros descontos de preços aplicados ao seu uso do EC2. Consulte a página de definição de preços para obter detalhes adicionais: [https://aws.amazon.com/lambda/pricing/](https://aws.amazon.com/lambda/pricing/)
**Importante:** os descontos nos preços do EC2 se aplicam somente à computação subjacente do EC2, não à taxa de gerenciamento.
## Como as instâncias gerenciadas do Lambda diferem do tipo de computação do Lambda (padrão)
As instâncias gerenciadas do Lambda mudam a forma como o Lambda processa solicitações em comparação com o Lambda (padrão).
**Principais diferenças:**
| | Lambda (padrão) | Instâncias gerenciadas do Lambda |
| --- | --- | --- |
| Modelo de simultaneidade | Modelo único de simultaneidade em que um ambiente de execução pode oferecer suporte a, no máximo, uma invocação por vez | Invocações multissimultâneas em que um ambiente de execução pode lidar com várias invocações simultaneamente, aumentando a taxa de transferência, especialmente para aplicações com alto volume de E/S |
| Locação e isolamento | Multilocatário, usando a tecnologia Firecracker microVM para fornecer isolamento entre ambientes de execução executados em frotas do Lambda compartilhadas | Execute em sua conta, usando o Nitro do EC2 para fornecer isolamento. Os provedores de capacidade servem como limite de segurança, com funções executadas em contêineres dentro de instâncias |
| Modelo de definição de preços | Preços de duração por solicitação | Definição de preços baseada em instâncias com modelos de preços do EC2, incluindo instâncias sob demanda e reservadas, e opções de economia, como Savings Plans para computação |
| Comportamento do ajuste de escala | Escala quando não há ambiente de execução livre para lidar com uma invocação recebida (inicialização a frio). Escala até zero sem tráfego | Escala de forma assíncrona com base somente na utilização dos recursos da CPU, sem inicializações a frio. Escala até ambientes de execução mínimos configurados sem tráfego |
| Mais adequado para | Funções com tráfego em rajadas que podem suportar algum tempo de inicialização a frio ou aplicações sem carga sustentada que se beneficiam da escala até zero | Funções com tráfego previsível de alto volume quando você deseja a flexibilidade, os planos de preços e as opções de hardware do EC2 |
## Próximas etapas
+ Saiba mais sobre [provedores de capacidade para instâncias gerenciadas do Lambda](lambda-managed-instances-capacity-providers.md)
+ Entenda a [escalabilidade para instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
+ Consulte os guias específicos de runtime para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) e [Python](lambda-managed-instances-python-runtime.md)
+ Configure a [conectividade de VPC para seus provedores de capacidade](lambda-managed-instances-networking.md)
+ Entenda a [segurança e as permissões das instâncias gerenciadas do Lambda](lambda-managed-instances-security.md)
# Conceitos básicos das instâncias gerenciadas do Lambda
## Criação de uma função de instância gerenciada do Lambda (console)
É possível usar o console do Lambda para criar uma função de instância gerenciada que é executada em instâncias do Amazon EC2 gerenciadas por um provedor de capacidade.
**Importante:** antes de criar uma função de instância gerenciada, você deve primeiro criar um provedor de capacidade. Essas funções exigem que um provedor de capacidade defina a infraestrutura do Amazon EC2 que executará suas funções.
**Para criar uma função de instância gerenciada do Lambda (console)**
1. Abra o console do lambda.
1. Escolha **Provedores de capacidade** no painel de navegação à esquerda.
1. Escolha **Criar provedor de capacidade**.
1. Na seção **Configurações do provedor de capacidade**, insira um nome para seu provedor de capacidade.
1. Selecione a VPC e as permissões para seu provedor de capacidade. É possível usar uma existente ou criar uma nova. Para obter informações sobre como criar o perfil de operador necessário, consulte [Perfil de operador do Lambda para instâncias gerenciadas do Lambda](lambda-managed-instances-operator-role.md).
1. Expanda **Advanced settings (Configurações avançadas)**.
1. Defina seus **requisitos de instância** escolhendo a arquitetura do processador e os tipos de instância.
1. Em **Ajuste de escala automático**, especifique o número máximo de vCPUs EC2 para seu provedor de capacidade. Também é possível escolher o **modo de escalabilidade de instâncias manual** para definir seu próprio valor de escalabilidade para um controle preciso.
1. Escolha **Criar provedor de capacidade** para criar um novo.
1. A seguir, escolha **Create function**.
1. Selecione **Criar do zero**.
1. No painel **Informações básicas**, forneça o **Nome da função**.
1. Em **Runtime**, escolha qualquer um dos runtimes com suporte.
1. Escolha a **Arquitetura** para sua função (a mesma que você selecionou para o provedor de capacidade). Por padrão, **x86\$164**.
1. Em **Permissões**, verifique se você tem permissão para o **perfil de execução** escolhido. Caso contrário, é possível criar um novo perfil.
1. Em **Configurações adicionais**, escolha o **Tipo de computação** como **Instâncias gerenciadas do Lambda**.
1. O ARN do provedor de capacidade que você criou nas etapas anteriores deve ser pré-selecionado.
1. Escolha **Tamanho da memória** e **Memória do ambiente de execução (GiB) por proporção de vCPU**.
1. Escolha a opção **Criar função**.
Sua função de Instância gerenciada do Lambda é criada e provisionará a capacidade em seu provedor de capacidade especificado. A criação da função normalmente leva vários minutos. Depois de concluído, será possível editar o código da função e executar seu primeiro teste.
## Criação de uma função de instância gerenciada do Lambda (AWS CLI)
### Pré-requisitos
Antes de começar, você deve ter o seguinte:
+ **AWS CLI**: instale e configure a AWS CLI. Para obter mais informações, consulte [Instalação ou atualização da versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ **Permissões do IAM**: seu perfil ou usuário do IAM deve ter permissões para criar funções do Lambda, provedores de capacidade e transmitir perfis do IAM. Observe que você também precisará de `iam:CreateServiceLinkedRole` se for a primeira vez que cria um provedor de capacidade na conta ou se o perfil vinculado ao serviço (SLR) foi excluído.
### Etapa 1: criação dos perfis do IAM necessários.
As instâncias gerenciadas do Lambda exigem dois perfis do IAM: um perfil de execução para sua função e um perfil de operador para o provedor de capacidade. O perfil do operador permite que o Lambda inicie, encerre e monitore instâncias do Amazon EC2 em seu nome. O perfil de execução da função concede a ela permissões para acessar outros serviços e recursos da AWS.
**Para criar o perfil de execução do Lambda**
1. Crie um documento de política de confiança que permita que o Lambda assuma o perfil:
```
cat > lambda-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
```
1. Crie o perfil de execução
```
aws iam create-role \
--role-name MyLambdaExecutionRole \
--assume-role-policy-document file://lambda-trust-policy.json
```
1. Anexe a política básica de execução:
```
aws iam attach-role-policy \
--role-name MyLambdaExecutionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
**Para criar o perfil de operador do provedor de capacidade**
1. Crie um documento de política de confiança que permita que o Lambda assuma o perfil 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. Crie o perfil de operador:
```
aws iam create-role \
--role-name MyCapacityProviderOperatorRole \
--assume-role-policy-document file://operator-trust-policy.json
```
1. Anexe a política de permissões do EC2 necessária:
```
aws iam attach-role-policy \
--role-name MyCapacityProviderOperatorRole \
--policy-arn arn:aws:iam::aws:policy/AWSLambdaManagedEC2ResourceOperator
```
### Etapa 2: configuração dos recursos da VPC
As instâncias gerenciadas do Lambda são executadas em sua VPC e exigem uma sub-rede e um grupo de segurança.
**Para criar recursos de VPC**
1. Crie uma VPC:
```
VPC_ID=$(aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--query 'Vpc.VpcId' \
--output text)
```
1. Crie uma sub-rede:
```
SUBNET_ID=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.1.0/24 \
--query 'Subnet.SubnetId' \
--output text)
```
1. Crie um grupo de segurança:
```
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)
```
**Observação:** suas funções de instâncias gerenciadas do Lambda exigem a configuração da VPC para acessar recursos fora da VPC e transmitir dados de telemetria para o CloudWatch Logs e o X-Ray. Para obter detalhes de configuração, consulte [Rede para instâncias gerenciadas do Lambda](lambda-managed-instances-networking.md).
### Etapa 3: Criar um provedor de capacidade
Um provedor de capacidade gerencia as instâncias do EC2 que executam suas funções do Lambda.
**Para criar um provedor de capacidade**
```
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 cria um provedor de capacidade com a configuração a seguir:
+ **Configuração da VPC**: especifica a sub-rede e o grupo de segurança para as instâncias do EC2
+ **Permissões**: define o perfil do IAM que o Lambda usa para gerenciar instâncias do EC2
+ **Requisitos da instância**: especifica a arquitetura x86\$164
+ **Configuração de escalabilidade**: define um máximo de 30 vCPUs para o provedor de capacidade
### Etapa 4: criação de uma função do Lambda com código embutido
**Para criar uma função com código embutido**
1. Primeiro, crie uma função simples do Python e empacote-a em linha:
```
# 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. Crie a função do Lambda usando o arquivo ZIP embutido:
```
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}
```
A função é criada com:
+ **Runtime**: Python 3,13
+ **Manipulador**: a função `lambda_handler` em `lambda_function.py`
+ **Memória**: 2048 MB
+ **Armazenamento efêmero**: 512 MB
+ **Provedor de capacidade**: links para o provedor de capacidade que você criou
### Etapa 5: publicação de uma versão da função
Para executar sua função nas instâncias gerenciadas do Lambda, é necessário publicar uma versão.
**Para publicar uma versão da função**
```
aws lambda publish-version \
--function-name my-managed-instance-function
```
Esse comando publica a versão 1 da sua função e a implanta no provedor de capacidade.
### Etapa 6: invocação da sua função
Depois de publicar, é possível invocar sua função.
**Para invocar sua função**
```
aws lambda invoke \
--function-name my-managed-instance-function:1 \
--payload '{"name": "World"}' \
response.json
# View the response
cat response.json
```
A função é executada nas instâncias do EC2 gerenciadas pelo seu provedor de capacidade e retorna uma resposta.
### Limpeza
Para evitar incorrer em custos, exclua os recursos que você criou:
1. Exclua a função:
```
aws lambda delete-function --function-name my-managed-instance-function
```
1. Exclua o provedor de capacidade:
```
aws lambda delete-capacity-provider --capacity-provider-name my-capacity-provider
```
1. Exclua os recursos da 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. Excluas os perfis do 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
```
# Conceitos principais
As instâncias gerenciadas do Lambda introduzem vários conceitos principais que diferem das funções do Lambda tradicionais. Compreender esses conceitos é essencial para implantar e gerenciar com eficácia suas funções na infraestrutura do EC2.
Os **provedores de capacidade** formam a base das instâncias gerenciadas do Lambda. Um provedor de capacidade define a infraestrutura computacional em que suas funções são executadas, incluindo configuração de VPC, requisitos de instância e políticas de escalabilidade. Os provedores de capacidade também servem como limite de segurança para suas funções, o que significa que todas as funções atribuídas ao mesmo provedor de capacidade devem ser mutuamente confiáveis.
O **comportamento de escalabilidade** difere significativamente das funções do Lambda tradicionais. Em vez de escalar sob demanda quando as invocações chegam, as instâncias gerenciadas escalam de forma assíncrona com base na utilização dos recursos da CPU. Essa abordagem elimina as inicializações a frio, mas exige planejamento para o crescimento do tráfego. Se o seu tráfego mais do que dobrar em 5 minutos, será possível enfrentar controles de utilização à medida que o Lambda aumenta a escala verticalmente para atender à demanda.
**A segurança e as permissões** exigem uma consideração cuidadosa. Você precisa de permissões de perfil de operador para permitir que o Lambda gerencie recursos do EC2 em seus provedores de capacidade. Além disso, os usuários precisam da permissão `lambda:PassCapacityProvider` para atribuir funções aos provedores de capacidade, atuando como uma porta de segurança para controlar quais funções podem ser executadas em uma infraestrutura específica.
A **execução multissimultânea** é uma característica fundamental das instâncias gerenciadas. Cada ambiente de execução pode lidar com várias invocações simultaneamente, maximizando a utilização de recursos para aplicações com uso intenso de E/S. Isso difere do Lambda tradicional, onde cada ambiente processa uma solicitação por vez. Esse modelo de execução exige atenção à segurança dos threads, ao gerenciamento do estado e ao isolamento do contexto, dependendo do runtime.
As seções a seguir fornecem informações detalhadas sobre cada conceito fundamental.
# Provedores de capacidade
Um provedor de capacidade é a base para a execução de instâncias gerenciadas do Lambda. Ele atua como limite de segurança para suas funções e define os recursos computacionais que o Lambda provisionará e gerenciará em seu nome.
Ao criar um provedor de capacidade, você especifica:
+ **Configuração de VPC**: as sub-redes e os grupos de segurança em que as instâncias serão executadas
+ **Permissões**: as funções do IAM para o Lambda gerenciar recursos do EC2
+ **Requisitos da instância** (opcional): preferências de arquitetura e de [tipo de instância](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High)
+ **Configuração de escalabilidade** (opcional): como o Lambda escala suas instâncias
## Noções básicas dos provedores de capacidade como limite de segurança
Os provedores de capacidade servem como limite de segurança para as funções do Lambda em sua VPC, substituindo o isolamento baseado em Firecracker. As funções são executadas em contêineres dentro de instâncias, mas os contêineres não fornecem um forte isolamento de segurança entre as funções, ao contrário das microVMs do Firecracker.
**Principais conceitos de segurança:**
+ **Provedor de capacidade:** o limite de segurança que define os níveis de confiança para as funções do Lambda
+ **Isolamento de contêineres:** os contêineres NÃO são um provedor de segurança. Não confie neles para garantir a segurança entre workloads não confiáveis
+ **Separação de confiança:**: separe as workloads que não sejam mutuamente confiáveis usando diferentes provedores de capacidade.
## Criação de um provedor de capacidade
É possível criar um provedor de capacidade usando a AWS CLI, o Console de Gerenciamento da AWS ou as SDKs da AWS.
**Uso da AWS CLI**
```
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 necessários
**CapacityProviderName**
+ Um nome exclusivo para o seu provedor de capacidade
+ Ele deve ser exclusivo na sua conta da AWS
**VpcConfig**
+ **SubnetIds** (obrigatório): ao menos uma sub-rede, máximo de 16. Use sub-redes em várias zonas de disponibilidade para obter resiliência
+ **SecurityGroupIds** (opcional): grupos de segurança para suas instâncias. O padrão é o grupo de segurança padrão da VPC, se não for especificado
**PermissionsConfig**
+ **CapacityProviderOperatorRoleArn** (obrigatório): perfil do IAM que permite ao Lambda gerenciar recursos do EC2 em seu provedor de capacidade
### Parâmetros opcionais
**InstanceRequirements**
Especifique a arquitetura e os [tipos de instância](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) para seu provedor de capacidade:
+ **Arquiteturas**: escolha `x86_64` ou `arm64`. O padrão é `x86_64`
+ **AllowedInstanceTypes**: especifique os tipos de instância permitidos. Exemplo: `m5.8xlarge`
+ **ExcludedInstanceTypes**: especifique os tipos de instância excluídos usando curingas. É possível especificar apenas um dentre AllowedInstanceTypes ou ExcludedInstanceTypes.
Por padrão, o Lambda escolhe os tipos de instância ideais para sua workload. Recomendamos que as instâncias gerenciadas do Lambda escolham os tipos de instância para você, pois restringir o número de tipos de instância possíveis pode resultar em menor disponibilidade.
**CapacityProviderScalingConfig**
Configure como o Lambda escala suas instâncias:
+ **ScalingMode**: defina como `Auto` para escalabilidade automática ou `Manual` para controle manual. O padrão é `Auto`
+ **MaxVCpuCount**: número máximo de vCPUs para o provedor de capacidade. O padrão é de 400.
+ **ScalingPolicies**: defina políticas de escalabilidade de rastreamento de destinos para utilização de CPU e memória
**KmsKeyArn**
Especifique uma chave do AWS KMS para a criptografia do EBS. O padrão é de chave gerenciada pela AWS, caso não especificado.
**Tags**
Adicione tags para organizar e gerenciar os provedores de capacidade.
## Gerenciamento dos provedores de capacidade
### Atualização de um provedor de capacidade
É possível atualizar determinadas propriedades de um provedor de capacidade usando a API `UpdateCapacityProvider`.
```
aws lambda update-capacity-provider \
--capacity-provider-name my-capacity-provider \
--capacity-provider-scaling-config ScalingMode=Auto
```
### Exclusão de um provedor de capacidade
É possível excluir um provedor de capacidade quando ele não for mais necessário usando a API `DeleteCapacityProvider`.
```
aws lambda delete-capacity-provider \
--capacity-provider-name my-capacity-provider
```
**Observação:** não é possível excluir um provedor de capacidade que tenha versões de função anexadas a ele.
### Visualização de detalhes do provedor de capacidade
Recupere informações sobre um provedor de capacidade usando a API `GetCapacityProvider`.
```
aws lambda get-capacity-provider \
--capacity-provider-name my-capacity-provider
```
## Estados do provedor de capacidade
Um provedor de capacidade pode estar em um dos estados a seguir:
+ **Pendente**: o provedor de capacidade está sendo criado
+ **Ativo**: o provedor de capacidade está pronto para uso
+ **Com falha**: a criação do provedor de capacidade falhou
+ **Em exclusão**: o provedor de capacidade está sendo excluído
## Cotas
+ **Máximo de provedores de capacidade por conta**: 1.000
+ **Versões máximas de funções por provedor de capacidade**: 100 (não pode ser aumentado)
## Práticas recomendadas
1. **Separe por nível de confiança**: crie diferentes provedores de capacidade para workloads com diferentes requisitos de segurança
1. **Use nomes descritivos**: nomeie os provedores de capacidade para indicar claramente o uso pretendido e o nível de confiança (por exemplo, `production-trusted`, `dev-sandbox`).
1. **Use várias zonas de disponibilidade**: especifique as sub-redes em várias zonas de disponibilidade para obter alta disponibilidade
1. **Deixe o Lambda escolher os tipos de instância**: a menos que você tenha requisitos específicos de hardware, permita que o Lambda selecione os tipos de instância ideais para disponibilidade
1. **Monitore o uso**: use o AWS CloudTrail para monitorar as atribuições e os padrões de acesso do provedor de capacidade.
## Próximas etapas
+ Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
+ Entenda a [segurança e as permissões das instâncias gerenciadas do Lambda](lambda-managed-instances-security.md)
+ Configure a [conectividade de VPC para seus provedores de capacidade](lambda-managed-instances-networking.md)
+ Consulte os guias específicos de runtime para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) e [Python](lambda-managed-instances-python-runtime.md)
# Escalabilidade de instâncias gerenciadas do Lambda
As instâncias gerenciadas do Lambda não escalam quando as invocações chegam e não oferecem suporte a inicializações a frio. Em vez disso, elas escalam de forma assíncrona usando sinais de consumo de recursos. Atualmente, as instâncias gerenciadas escalam com base na utilização de recursos da CPU e na saturação de multissimultaneidade.
**Principais diferenças:**
+ **Lambda (padrão):** escala quando não há ambiente de execução livre para lidar com uma invocação recebida (inicialização a frio)
+ **Instâncias gerenciadas do Lambda:** escalam de forma assíncrona com base na utilização de recursos da CPU e na saturação de multissimultaneidade dos ambientes de execução
Se seu tráfego mais do que dobrar em 5 minutos, será possível ver controles de utilização quando o Lambda aumentar a escala verticalmente das instâncias e ambientes de execução para atender à demanda.
## O ciclo de vida de escalabilidade
As instâncias gerenciadas do Lambda usam uma arquitetura distribuída para gerenciar a escalabilidade:
**Componentes:**
+ **Instâncias gerenciadas**: executadas na sua conta, nas sub-redes que você fornece
+ **Roteador e escalador**: componentes compartilhados do Lambda que roteiam invocações e gerenciam a escalabilidade
+ **Agente do Lambda**: executado em cada instância gerenciada para gerenciar o ciclo de vida do ambiente de execução e monitorar o consumo de recursos
**Como funciona:**
1. Quando você publica uma versão da função com um provedor de capacidade, o Lambda executa instâncias gerenciadas em sua conta. Ele executa três por padrão, para resiliência de AZ, e inicia três ambientes de execução antes de marcar sua versão de função como ATIVA.
1. Cada instância gerenciada pode executar ambientes de execução para várias funções mapeadas para o mesmo provedor de capacidade.
1. Conforme o tráfego flui para a sua aplicação, os ambientes de execução consomem recursos. O agente do Lambda notifica o escalador, que decide se quer escalar novos ambientes de execução ou instâncias gerenciadas.
1. Se o roteador tentar enviar uma invocação para um ambiente de execução com alto consumo de recursos, o agente do Lambda nessa instância o notificará para tentar novamente em outra.
1. À medida que o tráfego diminui, o agente do Lambda notifica o escalador, que toma a decisão de reduzir a escala verticalmente dos ambientes de execução e reduzir a escala horizontalmente das instâncias gerenciadas.
## Ajuste do comportamento de escalabilidade
É possível personalizar o comportamento de escalabilidade das instâncias gerenciadas por meio de quatro controles:
### Controles em nível de função
#### 1. Memória da função e vCPUs
Escolha o tamanho da memória e a alocação de vCPUs para sua função. O menor tamanho de função com suporte é de 2 GB e 1 vCPU.
**Considerações:**
+ Selecione uma configuração de memória e vCPU que ofereça suporte a execuções multissimultâneas da sua função.
+ Não é possível configurar uma função com menos de 1 vCPU, pois as funções executadas em instâncias gerenciadas devem oferecer suporte a workloads multissimultâneas
+ Não é possível escolher menos de 2 GB, pois isso corresponde à proporção de 2 para 1 memória por vCPU das instâncias c, que têm a menor proporção
+ Para aplicações em Python, talvez seja necessário escolher uma proporção maior de memória para vCPUs, como 4 para 1 ou 8 para 1, devido à forma como o Python lida com a multissimultaneidade
+ Se você estiver executando operações intensivas de CPU ou executando pouca E/S, é necessário escolher mais de uma vCPU
#### 2. Simultaneidade máxima
Defina a simultaneidade máxima por ambiente de execução.
**Comportamento padrão:** o Lambda escolhe padrões sensatos que equilibram o consumo de recursos e o throughput, o que funciona para uma ampla variedade de aplicações.
**Diretrizes de ajuste:**
+ **Aumente a simultaneidade:** se suas invocações de função usarem muito pouca CPU, será possível aumentar a simultaneidade máxima até um máximo de 64 por vCPU
+ **Reduza a simultaneidade:** se a sua aplicação consome uma grande quantidade de memória e muito pouca CPU, é possível reduzir sua simultaneidade máxima
**Importante:** como as instâncias gerenciadas do Lambda são destinadas a aplicações multissimultâneas, ambientes de execução com simultaneidade muito baixa podem sofrer controles de utilização durante a escalabilidade.
### Controles em nível de provedor de capacidade
#### 3. Utilização de recursos do destino
Escolha seu próprio destino para o consumo de utilização da CPU.
**Comportamento padrão:** o Lambda mantém espaço suficiente para que seu tráfego dobre em 5 minutos sem controles de utilização.
**Opções de otimização:**
+ Se a sua workload for muito estável ou se sua aplicação não for sensível a restrições, será possível definir a meta em um nível alto para obter maior utilização e custos mais baixos
+ Se você quiser manter o espaço livre para picos de tráfego, é possível definir metas de recursos em um nível baixo, o que exigirá mais capacidade
#### 4. Seleção do tipo de instância
Defina os tipos de instância permitidos ou excluídos.
**Comportamento padrão:** o Lambda escolhe os melhores tipos de instância para sua workload. Recomendamos que as instâncias gerenciadas do Lambda escolham os tipos de instância para você, pois restringir o número de tipos de instância possíveis pode resultar em menor disponibilidade.
**Configuração personalizada:**
+ **Requisitos específicos de hardware:** defina os tipos de instância permitidos em uma lista de instâncias compatíveis. Por exemplo, se você tiver uma aplicação que exija alta largura de banda da rede, poderá selecionar vários tipos de instâncias n.
+ **Otimização de custos:** para ambientes de testes ou desenvolvimento, é possível escolher tipos de instância menores, como tipos de instância m7a.large
## Próximas etapas
+ Saiba mais sobre [provedores de capacidade para instâncias gerenciadas do Lambda](lambda-managed-instances-capacity-providers.md)
+ Revise os guias específicos de runtime para lidar com a multissimultaneidade
+ Configure a [conectividade de VPC para seus provedores de capacidade](lambda-managed-instances-networking.md)
+ Monitore as métricas de escalabilidade para otimizar o comportamento da escalabilidade
# Segurança e permissões
As instâncias gerenciadas do Lambda usam **provedores de capacidade como limites de confiança**. As funções são executadas em contêineres dentro dessas instâncias, mas os contêineres não fornecem isolamento de segurança entre as workloads. Todas as funções atribuídas ao mesmo provedor de capacidade devem ser mutuamente confiáveis.
## Principais conceitos de segurança:
+ **Provedor de capacidade**: o limite de segurança que define os níveis de confiança para as funções do Lambda
+ **Isolamento de contêineres**: os contêineres não são um limite de segurança. Não confie neles para garantir a segurança entre workloads não confiáveis
+ **Separação de confiança**: separe as workloads que não sejam mutuamente confiáveis usando diferentes provedores de capacidade.
## Permissões obrigatórias
### Ação do PassCapacityProvider
Os usuários precisam da permissão `lambda:PassCapacityProvider` para atribuir funções aos provedores de capacidade. Essa permissão atua como uma porta de segurança, garantindo que somente usuários autorizados possam colocar funções em provedores de capacidade específicos.
Os administradores da conta controlam quais funções podem usar provedores de capacidade específicos por meio da ação `lambda:PassCapacityProvider` do IAM. Essa ação será necessária quando:
+ Criação de funções que usem as instâncias gerenciadas do Lambda
+ Atualização das configurações da função para usar um provedor de capacidade
+ Implantação de funções via infraestrutura como código
**Exemplo de política do IAM**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:PassCapacityProvider",
"Resource": "arn:aws:lambda:*:*:capacity-provider:trusted-workloads-*"
}
]
}
```
### Função vinculada ao serviço
O AWS Lambda usa o perfil vinculado ao serviço `AWSServiceRoleForLambda` para gerenciar recursos do ec2 de instâncias gerenciadas do Lambda em seus provedores de capacidade.
## Práticas recomendadas
1. **Separe por nível de confiança**: crie diferentes provedores de capacidade para workloads com diferentes requisitos de segurança
1. **Use nomes descritivos**: nomeie os provedores de capacidade para indicar claramente o uso pretendido e o nível de confiança (por exemplo, `production-trusted`, `dev-sandbox`).
1. **Aplique o privilégio mínimo**: conceda permissões `PassCapacityProvider` somente para os provedores de capacidade necessários
1. **Monitore o uso**: use o AWS CloudTrail para monitorar as atribuições e os padrões de acesso do provedor de capacidade.
## Próximas etapas
+ Saiba mais sobre [provedores de capacidade para instâncias gerenciadas do Lambda](lambda-managed-instances-capacity-providers.md)
+ Entenda a [escalabilidade para instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
+ Configure a [conectividade de VPC para seus provedores de capacidade](lambda-managed-instances-networking.md)
+ Consulte os guias específicos de runtime para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) e [Python](lambda-managed-instances-python-runtime.md)
# Perfil de operador do Lambda para instâncias gerenciadas do Lambda
Quando você usa as instâncias gerenciadas do Lambda, o Lambda precisa de permissões para gerenciar a capacidade computacional em sua conta. O perfil de operador fornece essas permissões por meio de políticas do IAM que permitem que o Lambda gerencie instâncias do EC2 no provedor de capacidade.
O Lambda assume o perfil de operador ao realizar essas operações de gerenciamento, da mesma forma que o Lambda assume um perfil de execução quando sua função é executada.
## Criação de um perfil de operador
É possível criar um perfil de operador no console do IAM ou com a AWS CLI. O perfil deve incluir:
+ **Política de permissões**: concede permissões para gerenciar provedores de capacidade e recursos associados
+ **Política de confiança**: permite que o serviço do Lambda (`lambda.amazonaws.com`) assuma o perfil.
### Política de permissões
O perfil de operador precisa de permissões para gerenciar os provedores de capacidade e os recursos computacionais subjacentes. No mínimo, o perfil exige as permissões na política gerenciada [AWSLambdaManagedEC2ResourceOperator](https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAWSLambdaManagedEC2ResourceOperator), atualmente:
```
{
"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 confiança
A política de confiança permite que o Lambda assuma o perfil do operador:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Perfil vinculado ao serviço para instâncias gerenciadas do Lambda
Para gerenciar com responsabilidade o ciclo de vida das instâncias gerenciadas do Lambda, o Lambda exige acesso persistente para encerrar as instâncias gerenciadas em sua conta. O Lambda usa um perfil vinculado ao serviço (SLR) do AWS Identity and Access Management (IAM) para realizar essas operações.
**Criação automática**: o perfil vinculado ao serviço é criado automaticamente na primeira vez que você cria um provedor de capacidade. O usuário que cria o primeiro provedor de capacidade deve ter a permissão `iam:CreateServiceLinkedRole` para a entidade principal `lambda.amazonaws.com`.
**Permissões**: o perfil vinculado ao serviço concede ao Lambda as permissões a seguir em instâncias gerenciadas:
+ `ec2:TerminateInstances`: para encerrar instâncias no final de seu ciclo de vida
+ `ec2:DescribeInstances`: para enumerar instâncias gerenciadas
**Exclusão**: é possível somente excluir esse perfil vinculado ao serviço depois de excluir todos os provedores de capacidade de instâncias gerenciadas do Lambda em sua conta.
Para obter mais informações sobre funções vinculadas ao serviço, consulte [Uso de perfis vinculados ao serviço para o Lambda](using-service-linked-roles.md).
# Noções básicas sobre o ambiente de execução das instâncias gerenciadas do Lambda
As instâncias gerenciadas do Lambda fornecem um modelo de implantação alternativo que executa seu código de função em instâncias do Amazon EC2 de propriedade do cliente, enquanto o Lambda gerencia os aspectos operacionais. O ambiente de execução das instâncias gerenciadas tem várias diferenças importantes em relação às funções do Lambda (padrão), principalmente na forma como ele lida com invocações simultâneas e gerencia os ciclos de vida do contêiner.
**Observação:** para obter informações sobre o ambiente de execução do Lambda (padrão), consulte Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda.
## Ciclo de vida do ambiente de execução
O ciclo de vida de um ambiente de execução de uma função das instâncias gerenciadas do Lambda difere do Lambda (padrão) de várias maneiras fundamentais:
### Fase de inicialização
Durante a fase de inicialização, o Lambda executa as etapas a seguir:
+ Inicialização e registro de todas as extensões
+ Bootstrap do ponto de entrada do runtime. O runtime gera o número configurado de operadores de runtime (a implementação depende do runtime)
+ Execução do código de inicialização da função (código fora do manipulador)
+ Espere que pelo menos um operador de runtime sinalize que está pronto chamando `/runtime/invocation/next`
A fase de inicialização é considerada concluída quando as extensões são inicializadas e pelo menos um operador de runtime tiver chamado `/runtime/invocation/next`. A função está então pronta para processar as invocações.
**nota**
Para as funções das instâncias gerenciadas do Lambda, a inicialização pode levar até 15 minutos. O tempo limite é de no máximo 130 segundos ou o tempo limite configurado da função (até 900 segundos).
### Fase de invocação
A fase de invocação para funções das instâncias gerenciadas do Lambda tem várias características exclusivas:
**Operação contínua.** Ao contrário do Lambda (padrão), o ambiente de execução permanece continuamente ativo, processando as invocações à medida que elas chegam, sem congelar entre as invocações.
**Processamento paralelo.** Várias invocações podem ser executadas simultaneamente no mesmo ambiente de execução, cada uma gerenciada por um operador de runtime diferente.
**Tempos limite independentes.** O tempo limite configurado da função se aplica a cada invocação individual. Quando uma invocação expira, o Lambda marca essa invocação específica como com falha, mas não interrompe outras invocações em andamento nem encerra o ambiente de execução.
**Tratamento de contrapressão.** Se todos os operadores de runtime estiverem ocupados processando invocações, novas solicitações de invocação serão rejeitadas até que um operador fique disponível.
## Tratamento de erros e recuperação
O tratamento de erros em ambientes de execução das funções de instâncias gerenciadas do Lambda difere do Lambda (padrão):
**Tempos limite de invocações.** Quando uma invocação individual expira, o Lambda retorna um erro de tempo limite para essa invocação. No entanto, as Instâncias Gerenciadas Lambda não impõem o tempo limite; seu código continuará em execução. Como desenvolvedor de funções, você é responsável por detectar e gerenciar o tempo limite. O objeto de contexto expõe o tempo restante para a invocação, com um valor zero ou negativo indicando um tempo limite. Outras invocações simultâneas no ambiente de execução continuam sendo processadas normalmente.
**Falhas do operador de runtime.** Se um processo de operador de runtime falhar, o ambiente de execução continuará funcionando com os demais operadores íntegros.
**Falhas de extensão.** Se um processo de extensão falhar durante a inicialização ou operação, todo o ambiente de execução será marcado como não íntegro e encerrado. O Lambda criará um novo ambiente de execução para substituí-lo.
**Sem redefinição/reparo.** Diferentemente do Lambda (padrão), as instâncias gerenciadas não tentam redefinir e reinicializar o ambiente de execução após erros. Em vez disso, os contêineres não íntegros são encerrados e substituídos por novos.
# Versão \$1LATEST.PUBLISHED em instâncias gerenciadas do Lambda
As funções de instâncias gerenciadas do Lambda oferecem suporte ao mesmo fluxo de trabalho de versionamento numerado do Lambda (padrão). Se você preferir não manter versões numeradas, as instâncias gerenciadas do Lambda introduzem um novo tipo de versão: `$LATEST.PUBLISHED`. Essa versão permite criar ou republicar uma versão publicada mais recente, conforme necessário, com código ou configuração atualizados, sem gerenciar versões numeradas.
**Principal diferença de \$1LATEST:** quando você invoca uma função de instâncias gerenciadas do Lambda usando um ARN não qualificado, o Lambda invoca implicitamente a versão `$LATEST.PUBLISHED` em vez da versão \$1LATEST não publicada.
O comando da AWS CLI a seguir cria ou republica a versão `$LATEST.PUBLISHED`.
```
aws lambda publish-version --function-name my-function --publish-to LATEST_PUBLISHED
```
A seguinte saída deverá ser mostrada:
```
{
"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**
Se você usa o AWS CloudFormation ou o console do Lambda para criar uma função de instâncias gerenciadas do Lambda, o Lambda criará automaticamente a versão `$LATEST.PUBLISHED`.
# Runtimes de instâncias gerenciadas do Lambda
O Lambda processa solicitações de forma diferente ao usar as instâncias gerenciadas do Lambda. Em vez de lidar com solicitações sequencialmente em cada ambiente de execução, as instâncias gerenciadas do Lambda processam várias solicitações simultaneamente em cada ambiente de execução. Essa mudança no modelo de execução significa que as funções que usam instâncias gerenciadas do Lambda precisam considerar a segurança de threads, o gerenciamento do estado e o isolamento do contexto, questões que não surgem no modelo de simultaneidade única do Lambda (padrão). Além disso, a implementação de multissimultaneidade varia entre os runtimes.
## Idiomas compatíveis
As instâncias gerenciadas do Lambda podem ser usadas com as seguintes linguagens de programação e runtimes:
+ **Java:** Java 21 e posteriores.
+ **Python:** Python 3.13 e posteriores.
+ **Node.js:** Node.js 22 e posteriores.
+ **.NET:** .NET 8 e posteriores.
+ **Rust:** com suporte usando o runtime exclusivo do sistema operacional `provided.al2023` e versões posteriores.
## Considerações específicas de cada linguagem
Cada linguagem de programação implementa a multiconcorrência de maneira diferente. Você precisa entender como a multisaimultaneidade é implementada na linguagem de programação escolhida para aplicar as melhores práticas de simultaneidade apropriadas.
**Java**
Usa um único processo com threads de sistema operacional para simultaneidade. Vários threads executam o método manipulador simultaneamente, exigindo um tratamento seguro do estado e dos recursos compartilhados.
**Python**
Usa vários processos do Python em que cada solicitação simultânea é executada em um processo separado. Isso protege contra a maioria dos problemas de simultaneidade, embora seja necessário cuidado com recursos compartilhados, como o diretório `/tmp`.
**Node.js**
Usa [threads de operador](https://nodejs.org/api/worker_threads.html) com execução assíncrona. As solicitações simultâneas são distribuídas entre os threads de operador, e cada thread de operador também pode lidar com solicitações simultâneas de forma assíncrona, exigindo tratamento seguro do estado e dos recursos compartilhados.
**.NET**
Usa tarefas do .NET com processamento assíncrono de várias solicitações simultâneas. Requer o manuseio seguro do estado e dos recursos compartilhados.
**Rust**
Utiliza um único processo com tarefas assíncronas implementadas por [Tokio](https://tokio.rs/). O manipulador deve ser `Clone` \$1 `Send`.
## Próximas etapas
Para obter informações detalhadas sobre cada runtime, consulte os tópicos a seguir:
+ [Runtime de Java para instâncias gerenciadas do Lambda](lambda-managed-instances-java-runtime.md)
+ [Runtime de Node.js para instâncias gerenciadas do Lambda](lambda-managed-instances-nodejs-runtime.md)
+ [Runtime de Python para instâncias gerenciadas do Lambda](lambda-managed-instances-python-runtime.md)
+ [.Runtime do .NET para instâncias gerenciadas do Lambda](lambda-managed-instances-dotnet-runtime.md)
+ [Suporte ao Rust para instâncias gerenciadas do Lambda](lambda-managed-instances-rust.md)
# Runtime de Java para instâncias gerenciadas do Lambda
Para runtimes de Java, as instâncias gerenciadas do Lambda usam threads do sistema operacional para simultaneidade. O Lambda carrega seu objeto manipulador uma vez por ambiente de execução durante a inicialização e, em seguida, cria vários threads. Esses threads são executados paralelamente e exigem um tratamento seguro do estado e dos recursos compartilhados. Cada thread compartilha o mesmo objeto manipulador e quaisquer campos estáticos.
## Configuração de simultaneidade
O número máximo de solicitações simultâneas que o Lambda envia para cada ambiente de execução é controlado pela definição `PerExecutionEnvironmentMaxConcurrency` da configuração da função. Essa é uma definição opcional e o valor padrão varia de acordo com o runtime. Para runtimes de Java, o padrão é 32 solicitações simultâneas por vCPU, ou é possível configurar seu próprio valor. Esse valor também determina o número de threads usados pelo runtime de Java. O Lambda ajusta automaticamente o número de solicitações simultâneas até o máximo configurado com base na capacidade de cada ambiente de execução de absorver essas solicitações.
## Funções de construção para multissimultaneidade
É necessário aplicar as mesmas práticas de segurança de thread ao usar instâncias gerenciadas do Lambda como você faria em qualquer outro ambiente de vários threads. Como o objeto manipulador é compartilhado entre todas as threads de operador de runtime, qualquer estado mutável deve ser seguro para threads. Isso inclui coleções, conexões de banco de dados e quaisquer objetos estáticos que sejam modificados durante o processamento da solicitação.
Os clientes de SDK da AWS são seguros para threads e não exigem tratamento especial.
**Exemplo: grupos de conexão de banco de dados**
O código a seguir usa um objeto de conexão de banco de dados estático que é compartilhado entre threads. Dependendo da biblioteca de conexão usada, isso pode não ser seguro para threads.
```
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();
}
}
```
Uma abordagem segura para threads é usar um grupo de conexões. No exemplo a seguir, o manipulador de funções recupera uma conexão do grupo. A conexão só é usada no contexto de uma única solicitação.
```
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();
}
}
```
**Exemplo: coleções**
As coleções de Java padrão não são seguras para threads:
```
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";
}
}
```
Em vez disso, use coleções seguras para threads:
```
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";
}
}
```
## Diretório /tmp compartilhado
O diretório `/tmp` é compartilhado entre todas as solicitações simultâneas no ambiente de execução. Gravações simultâneas no mesmo arquivo podem causar corrupção de dados, por exemplo, se outro processo sobrescrever o arquivo. Para resolver isso, implemente o bloqueio de arquivos para arquivos compartilhados ou use nomes de arquivo exclusivos por thread ou por solicitação para evitar conflitos. Lembre-se de limpar arquivos desnecessários para evitar o esgotamento do espaço disponível.
## Registro em log
A intercalação de logs (entradas de logs de solicitações diferentes sendo intercaladas em logs) é normal em sistemas multissimultâneos.
As funções que usam instâncias gerenciadas do Lambda sempre usam o formato de log de JSON estruturado introduzido com [controles de registro em log avançados](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Esse formato inclui o `requestId`, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Quando você usa o objeto `LambdaLogger` de `context.getLogger()`, o `requestId` é incluído automaticamente em cada entrada de log. Consulte para obter mais informações [Usar controles avançados de registro em log do Lambda com Java](java-logging.md#java-logging-advanced).
## Contexto da solicitação
O objeto `context` está vinculado ao thread da solicitação. O uso de `context.getAwsRequestId()` proporciona acesso com segurança de thread para acessar o ID da solicitação atual.
Use `context.getXrayTraceId()` para acessar o ID de rastreamento do X-Ray. Isso fornece acesso com segurança de thread ao ID de rastreamento da solicitação atual. O Lambda não oferece suporte à variável de ambiente `_X_AMZN_TRACE_ID` com instâncias gerenciadas do Lambda. O ID de rastreamento do X-Ray é propagado automaticamente ao usar o AWS SDK.
Use `com.amazonaws.services.lambda.runtime.Context.getRemainingTimeInMillis()` para detectar tempos limite. Consulte [Tratamento de erros e recuperação](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling) para obter mais informações.
Se você usar threads virtuais em seu programa ou criar threads durante a inicialização, precisará passar qualquer contexto de solicitação necessário para esses threads.
## Inicialização e desligamento
A inicialização da função ocorre uma vez por ambiente de execução. Os objetos criados durante a inicialização são compartilhados entre os threads.
Para as funções do Lambda com extensões, o ambiente de execução emite um sinal SIGTERM durante o desligamento. Esse sinal é usado pelas extensões para acionar tarefas de limpeza, como descarregar buffers. É possível se inscrever em eventos SIGTERM para acionar tarefas de limpeza de funções, como fechar conexões de banco de dados. Para saber mais sobre o ciclo de vida do ambiente de execução, consulte [Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda](lambda-runtime-environment.md).
## Versões de dependências
As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir:
+ AWS SDK para Java 2.0: versão 2.34.0 ou posterior
+ AWS X-Ray SDK para Java: versão 2.20.0 ou posterior
+ AWS Distro para OpenTelemetry - Instrumentação para Java: versão 2.20.0 ou posterior
+ Powertools para AWS Lambda (Java): versão 2.8.0 ou posterior
## Powertools para AWS Lambda (Java)
O Powertools para AWS Lambda (Java) é compatível com as instâncias gerenciadas do Lambda e fornece utilitários para registro em log, rastreamento, métricas e muito mais. Para obter mais informações, consulte [Powertools para AWS Lambda (Java)](https://github.com/aws-powertools/powertools-lambda-java).
## Próximas etapas
+ Analise o [runtime de Node.js para instâncias gerenciadas do Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Analise o [runtime de Python para instâncias gerenciadas do Lambda](lambda-managed-instances-python-runtime.md)
+ Analise o [runtime de .NET para instâncias gerenciadas do Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
# Runtime de Node.js para instâncias gerenciadas do Lambda
Para runtimes de Node.js, as instâncias gerenciadas do Lambda usam threads de operador com execução `async`/`await` para lidar com solicitações simultâneas. A inicialização da função ocorre uma vez por thread de operador. As invocações simultâneas são tratadas em duas dimensões: os threads de operador fornecem paralelismo entre vCPUs e a execução assíncrona fornece simultaneidade em cada thread. Cada solicitação simultânea tratada pelo mesmo thread de operador compartilha o mesmo objeto manipulador e estado global, exigindo tratamento seguro em várias solicitações simultâneas.
## Simultaneidade máxima
O número máximo de solicitações simultâneas que o Lambda envia para cada ambiente de execução é controlado pela definição `PerExecutionEnvironmentMaxConcurrency` da configuração da função. Essa é uma definição opcional e o valor padrão varia de acordo com o runtime. Para os runtimes de Node.js, o padrão é 64 solicitações simultâneas por vCPU, ou é possível configurar seu próprio valor. O Lambda ajusta automaticamente o número de solicitações simultâneas até o máximo configurado com base na capacidade de cada ambiente de execução de absorver essas solicitações.
Para o Node.js, o número de solicitações simultâneas que cada ambiente de execução pode processar é determinado pelo número de threads de operador e pela capacidade de cada thread de operador de processar solicitações simultâneas de forma assíncrona. O número padrão de threads de operador é determinado pelo número de vCPUs disponíveis, ou é possível configurar o número de threads de operador definindo a variável de ambiente `AWS_LAMBDA_NODEJS_WORKER_COUNT`. Recomendamos o uso de manipuladores de funções assíncronos, pois isso permite processar várias solicitações por thread de operador. Se seu manipulador de funções for síncrono, cada thread de operador só poderá processar uma única solicitação por vez.
## Funções de construção para multissimultaneidade
Com um manipulador de funções assíncrono, cada operador de runtime processa várias solicitações simultaneamente. Objetos globais serão compartilhados por várias solicitações simultâneas. Para objetos mutáveis, evite usar o estado global ou use `AsyncLocalStorage`.
Os clientes de SDK da AWS são seguros para assincronia e não exigem tratamento especial.
**Exemplo: estado global**
O código a seguir usa um objeto global que sofre mutação dentro do manipulador de funções. Isso não é seguro para uso assíncrono.
```
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 };
};
```
Inicializar o objeto `state` dentro do manipulador de funções evita o estado global compartilhado.
```
export const handler = async (event, context) => {
let state = {
currentUser: event.userId,
requestData: event.data
};
await processData(state.requestData);
return { user: state.currentUser };
};
```
**Exemplo: conexões de banco de dados**
O código a seguir usa um objeto cliente compartilhado que é compartilhado entre várias invocações. Dependendo da biblioteca de conexão usada, isso pode não ser seguro para simultaneidade.
```
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])
};
};
```
Uma abordagem segura para simultaneidade é usar um grupo de conexões. O grupo usa uma conexão separada para cada consulta simultânea ao banco de dados.
```
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])
};
};
```
## Manipuladores baseados em retorno de chamada do Node.js 22
Ao usar o Node.js 22, não é possível usar um manipulador de funções baseado em retorno de chamada com instâncias gerenciadas do Lambda. Há suporte para manipuladores baseados em retorno de chamada apenas com funções do Lambda (padrão). Para runtimes do Node.js 24 e posteriores, os manipuladores de funções baseados em retorno de chamada estão obsoletos tanto para o Lambda (padrão) quanto para instâncias gerenciadas do Lambda.
Em vez disso, use um manipulador de funções `async` ao usar instâncias gerenciadas do Lambda. Para obter mais informações, consulte [Definição do manipulador de função do Lambda em Node.js](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html).
## Diretório /tmp compartilhado
O diretório `/tmp` é compartilhado entre todas as solicitações simultâneas no ambiente de execução. Gravações simultâneas no mesmo arquivo podem causar corrupção de dados, por exemplo, se outro processo sobrescrever o arquivo. Para resolver isso, implemente o bloqueio de arquivos para arquivos compartilhados ou use nomes de arquivo exclusivos por solicitação para evitar conflitos. Lembre-se de limpar arquivos desnecessários para evitar o esgotamento do espaço disponível.
## Registro em log
A intercalação de logs (entradas de logs de solicitações diferentes sendo intercaladas em logs) é normal em sistemas multissimultâneos. As funções que usam instâncias gerenciadas do Lambda sempre usam o formato de log de JSON estruturado introduzido com [controles de registro em log avançados](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Esse formato inclui o `requestId`, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Quando você usa o logger `console`, o `requestId` é incluído automaticamente em cada entrada de log. Consulte para obter mais informações [Usar controles avançados de registro em log do Lambda com Node.js](nodejs-logging.md#node-js-logging-advanced).
Bibliotecas de registro em log populares de terceiros, como a [Winston](https://github.com/winstonjs/winston), geralmente incluem suporte para o uso do console para saída de logs.
## Contexto da solicitação
O uso de `context.awsRequestId` proporciona acesso com segurança de assincronia para acessar o ID da solicitação atual.
Use `context.xRayTraceId` para acessar o ID de rastreamento do X-Ray. Isso fornece acesso com segurança de simultaneidade ao ID de rastreamento da solicitação atual. O Lambda não oferece suporte à variável de ambiente `_X_AMZN_TRACE_ID` com instâncias gerenciadas do Lambda. O ID de rastreamento do X-Ray é propagado automaticamente ao usar o AWS SDK.
Use `context.getRemainingTimeInMillis()` para detectar tempos limite. Consulte [Tratamento de erros e recuperação](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling) para obter mais informações.
## Inicialização e desligamento
A inicialização da função ocorre uma vez por thread de operador. É possível visualizar ver entradas de log repetidas se sua função emitir logs durante a inicialização.
Para as funções do Lambda com extensões, o ambiente de execução emite um sinal SIGTERM durante o desligamento. Esse sinal é usado pelas extensões para acionar tarefas de limpeza, como descarregar buffers. Funções do Lambda (padrão) com extensões também podem assinar o sinal SIGTERM usando.`process.on()`. Não há suporte para isso em funções que usam instâncias gerenciadas do Lambda, pois `process.on()` não pode ser usado com threads de operador. Para saber mais sobre o ciclo de vida do ambiente de execução, consulte [Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda](lambda-runtime-environment.md).
## Versões de dependências
As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir:
+ AWS SDK para JavaScript v3: versão 3.933.0 ou posterior
+ AWS X-Ray SDK para Node.js: versão 3.12.0 ou posterior
+ AWS Distro para OpenTelemetry - Instrumentação para JavaScript: versão 0.8.0 ou posterior
+ Powertools para AWS Lambda (TypeScript): versão 2.29.0 ou posterior
## Powertools para AWS Lambda (TypeScript)
O Powertools para AWS Lambda (TypeScript) é compatível com as instâncias gerenciadas do Lambda e fornece utilitários para registro em log, rastreamento, métricas e muito mais. Para obter mais informações, consulte [Powertools para AWS Lambda (TypeScript)](https://github.com/aws-powertools/powertools-lambda-typescript).
## Próximas etapas
+ Analise o [runtime de Java para instâncias gerenciadas do Lambda](lambda-managed-instances-java-runtime.md)
+ Analise o [runtime de Python para instâncias gerenciadas do Lambda](lambda-managed-instances-python-runtime.md)
+ Analise o [runtime de .NET para instâncias gerenciadas do Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
# Runtime de Python para instâncias gerenciadas do Lambda
O runtime do Lambda usa vários processos do Python para lidar com solicitações simultâneas. Cada solicitação simultânea é executada em um processo separado com seu próprio espaço de memória e inicialização. Cada processo lida com uma solicitação por vez, de forma síncrona. Os processos não compartilham memória diretamente, então variáveis globais, caches em nível de módulo e objetos singleton são isolados entre solicitações simultâneas.
## Configuração de simultaneidade
O número máximo de solicitações simultâneas que o Lambda envia para cada ambiente de execução é controlado pela definição `PerExecutionEnvironmentMaxConcurrency` da configuração da função. Essa é uma definição opcional e o valor padrão varia de acordo com o runtime. Para runtimes de Python, o padrão é 16 solicitações simultâneas por vCPU, ou é possível configurar seu próprio valor. Esse valor também determina o número de processos usados pelo runtime de Java. O Lambda ajusta automaticamente o número de solicitações simultâneas até o máximo configurado com base na capacidade de cada ambiente de execução de absorver essas solicitações.
**Importante**
Usar a simultaneidade baseada em processos significa que cada processo de operador de runtime executa sua própria inicialização. O uso total de memória é igual à memória por processo multiplicada pelo número de processos simultâneos. Se você estiver carregando grandes bibliotecas ou conjuntos de dados e tiver alta simultaneidade, ocupará uma grande quantidade de memória. De acordo com sua workload, talvez seja necessário ajustar a relação CPU/memória ou usar uma configuração de simultaneidade mais baixa para evitar exceder a memória disponível. É possível usar a métrica `MemoryUtilization` no CloudWatch para monitorar o consumo de memória.
## Funções de construção para multissimultaneidade
Devido ao modelo de multissimultaneidade baseado em processos, as funções de instâncias gerenciadas do Lambda que usam runtimes de Python não acessam recursos na memória simultaneamente a partir de várias invocações. Não é preciso aplicar práticas de codificação para segurança de simultaneidade na memória.
## Diretório /tmp compartilhado
O diretório `/tmp` é compartilhado entre todas as solicitações simultâneas no ambiente de execução. Gravações simultâneas no mesmo arquivo podem causar corrupção de dados, por exemplo, se outro processo sobrescrever o arquivo. Para resolver isso, implemente o bloqueio de arquivos para arquivos compartilhados ou use nomes de arquivo exclusivos por processo ou por solicitação para evitar conflitos. Lembre-se de limpar arquivos desnecessários para evitar o esgotamento do espaço disponível.
## Registro em log
A intercalação de logs (entradas de logs de solicitações diferentes sendo intercaladas em logs) é normal em sistemas multissimultâneos.
As funções que usam instâncias gerenciadas do Lambda sempre usam o formato de log de JSON estruturado introduzido com [controles de registro em log avançados](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Esse formato inclui o `requestId`, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Quando você usa o módulo `logging` da biblioteca padrão do Python no Lambda, o `requestId` é incluído automaticamente em cada entrada de log. Para obter mais informações, consulte [Uso de controles avançados de registro em log do Lambda com Python](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced).
## Contexto da solicitação
Use `context.aws_request_id` para acessar o ID da solicitação atual.
Com os runtimes de Python, é possível usar a variável de ambiente `_X_AMZN_TRACE_ID` para acessar o ID de rastreamento do X-Ray com instâncias gerenciadas do Lambda. O ID de rastreamento do X-Ray é propagado automaticamente ao usar o AWS SDK.
Use `context.get_remaining_time_in_millis()` para detectar tempos limite. Consulte [Tratamento de erros e recuperação](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling) para obter mais informações.
## Inicialização e desligamento
A inicialização da função ocorre uma vez por processo. É possível visualizar ver entradas de log repetidas se sua função emitir logs durante a inicialização.
Para as funções do Lambda com extensões, o ambiente de execução emite um sinal SIGTERM durante o desligamento. Esse sinal é usado pelas extensões para acionar tarefas de limpeza, como descarregar buffers. É possível se inscrever em eventos SIGTERM para acionar tarefas de limpeza de funções, como fechar conexões de banco de dados. Para saber mais sobre o ciclo de vida do ambiente de execução, consulte [Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda](lambda-runtime-environment.md).
## Versões de dependências
As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir:
+ Powertools para AWS Lambda (Python): versão 3,23.0 ou posterior
## Powertools para AWS Lambda (Python)
O Powertools para AWS Lambda (Python) é compatível com as instâncias gerenciadas do Lambda e fornece utilitários para registro em log, rastreamento, métricas e muito mais. Para obter mais informações, consulte [Powertools para AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python).
## Próximas etapas
+ Analise o [runtime de Java para instâncias gerenciadas do Lambda](lambda-managed-instances-java-runtime.md)
+ Analise o [runtime de Node.js para instâncias gerenciadas do Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Analise o [runtime de .NET para instâncias gerenciadas do Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
# Runtime do .NET para instâncias gerenciadas do Lambda
Para runtimes do .NET, as instâncias gerenciadas do Lambda usam um único processo .NET por ambiente de execução. Várias solicitações simultâneas são processadas usando tarefas do .NET.
## Configuração de simultaneidade
O número máximo de solicitações simultâneas que o Lambda envia para cada ambiente de execução é controlado pela definição `PerExecutionEnvironmentMaxConcurrency` da configuração da função. Essa é uma definição opcional e o valor padrão varia de acordo com o runtime. Para os runtimes do .NET, o padrão é 32 solicitações simultâneas por vCPU, ou é possível configurar seu próprio valor. O Lambda ajusta automaticamente o número de solicitações simultâneas até o máximo configurado com base na capacidade de cada ambiente de execução de absorver essas solicitações.
## Funções de construção para multissimultaneidade
É necessário aplicar as mesmas práticas de segurança de simultaneidade ao usar instâncias gerenciadas do Lambda como você faria em qualquer outro ambiente multissimultâneo. Como o objeto manipulador é compartilhado entre todas as tarefas, qualquer estado mutável deve ser seguro para threads. Isso inclui coleções, conexões de banco de dados e quaisquer objetos estáticos que sejam modificados durante o processamento da solicitação.
Os clientes de SDK da AWS são seguros para threads e não exigem tratamento especial.
**Exemplo: grupos de conexão de banco de dados**
O código a seguir usa um objeto de conexão de banco de dados estático que é compartilhado entre solicitações simultâneas. O objeto `SqlConnection` não é seguro para threads.
```
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 resolver isso, use uma conexão separada para cada solicitação, extraída de um grupo de conexões. Os provedores de ADO.NET como o `Microsoft.Data.SqlClient` oferecem suporte automático a grupos de conexões quando o objeto de conexão é aberto.
```
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();
...
}
}
```
**Exemplo: coleções**
As coleções .NET padrão não são de threads seguros:
```
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";
}
}
```
Use coleções do namespace `System.Collections.Concurrent` para segurança de simultaneidade:
```
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";
}
}
```
## Diretório /tmp compartilhado
O diretório `/tmp` é compartilhado entre todas as solicitações simultâneas no ambiente de execução. Gravações simultâneas no mesmo arquivo podem causar corrupção de dados, por exemplo, se outra solicitação sobrescrever o arquivo. Para resolver isso, implemente o bloqueio de arquivos para arquivos compartilhados ou use nomes de arquivo exclusivos por solicitação para evitar conflitos. Lembre-se de limpar arquivos desnecessários para evitar o esgotamento do espaço disponível.
## Registro em log
A intercalação de logs (entradas de logs de solicitações diferentes sendo intercaladas em logs) é normal em sistemas multissimultâneos. As funções que usam instâncias gerenciadas do Lambda sempre usam o formato de log de JSON estruturado introduzido com [controles de registro em log avançados](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Esse formato inclui o `requestId`, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Quando você usa o objeto `context.Logger` para gerar logs, o `requestId` é incluído automaticamente em cada entrada de log. Consulte para obter mais informações [Uso de controles avançados de registro em log do Lambda com .NET](csharp-logging.md#csharp-logging-advanced).
## Contexto da solicitação
Use a propriedade `context.AwsRequestId` para acessar o ID da solicitação atual.
Use a propriedade `context.TraceId` para acessar o ID de rastreamento do X-Ray. Isso fornece acesso com segurança de simultaneidade ao ID de rastreamento da solicitação atual. O Lambda não oferece suporte à variável de ambiente `_X_AMZN_TRACE_ID` com instâncias gerenciadas do Lambda. O ID de rastreamento do X-Ray é propagado automaticamente ao usar o AWS SDK.
Use `ILambdaContext.RemainingTime` para detectar tempos limite. Consulte [Tratamento de erros e recuperação](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling) para obter mais informações.
## Inicialização e desligamento
A inicialização da função ocorre uma vez por ambiente de execução. Os objetos criados durante a inicialização são compartilhados entre as solicitações.
Para as funções do Lambda com extensões, o ambiente de execução emite um sinal SIGTERM durante o desligamento. Esse sinal é usado pelas extensões para acionar tarefas de limpeza, como descarregar buffers. É possível se inscrever em eventos SIGTERM para acionar tarefas de limpeza de funções, como fechar conexões de banco de dados. Para saber mais sobre o ciclo de vida do ambiente de execução, consulte [Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda](lambda-runtime-environment.md).
## Versões de dependências
As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir:
+ Amazon.Lambda.Core: versão 2.7.1 ou posterior
+ Amazon.Lambda.RuntimeSupport: versão 1.14.1 ou posterior
+ OpenTelemetry.Instrumentation.AWSLambda: versão 1.14.0 ou posterior
+ AWSXRayRecorder.Core: versão 2.16.0 ou posterior
+ AWSSDK.Core: versão 4.0.0.32 ou posterior
## Powertools para AWS Lambda (.NET)
[Powertools para AWS Lambda (.NET)](https://docs.aws.amazon.com/powertools/dotnet/) e [AWS Distro para OpenTelemetry - Instrumentação para DotNet](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) atualmente não oferecem suporte a instâncias gerenciadas do Lambda.
## Próximas etapas
+ Analise o [runtime de Java para instâncias gerenciadas do Lambda](lambda-managed-instances-java-runtime.md)
+ Analise o [runtime de Node.js para instâncias gerenciadas do Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Analise o [runtime de Python para instâncias gerenciadas do Lambda](lambda-managed-instances-python-runtime.md)
+ Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
# Suporte ao Rust para instâncias gerenciadas do Lambda
## Configuração de simultaneidade
O número máximo de solicitações simultâneas que o Lambda envia para cada ambiente de execução é controlado pela definição `PerExecutionEnvironmentMaxConcurrency` da configuração da função. Esta é uma configuração opcional, e o valor padrão no Rust é de 8 solicitações simultâneas por vCPU; você também pode definir seu próprio valor. Esse valor determina o número de tarefas da Tokio criadas pelo runtime e permanece fixo durante todo o tempo de vida do ambiente de execução. Cada operador lida com exatamente uma solicitação em andamento por vez, sem multiplexação por operador. O Lambda ajusta automaticamente o número de solicitações simultâneas até o máximo configurado com base na capacidade de cada ambiente de execução de absorver essas solicitações.
## Funções de construção para multissimultaneidade
É necessário aplicar as mesmas práticas de segurança de thread ao usar instâncias gerenciadas do Lambda como você faria em qualquer outro ambiente de vários threads. Como o objeto manipulador é compartilhado entre todas as threads de operador, qualquer estado mutável deve ser seguro para threads. Isso inclui coleções, conexões de banco de dados e quaisquer objetos estáticos que sejam modificados durante o processamento da solicitação.
Para habilitar o tratamento simultâneo de solicitações, adicione o sinalizador de recurso `concurrency-tokio` ao arquivo `Cargo.toml`.
```
[dependencies]
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }
```
O ponto de entrada `lambda_runtime::run_concurrent(…)` deve ser chamado de dentro de um runtime da Tokio, normalmente fornecido pelo atributo `#[tokio::main]` em sua função principal. O fechamento do manipulador deve 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). Isso permite que o framework compartilhe seu manipulador entre várias tarefas assíncronas com segurança. Se esses limites não forem respeitados, seu código não será compilado.
Quando você precisar de um estado compartilhado entre invocações (um pool de bancos de dados, uma estrutura de configuração), envolva-o em [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html) e clone `Arc` em cadainvocação.
Todos os clientes do AWS SDK para Rust são seguros contra concorrência e não exigem tratamento especial.
### Exemplo: cliente do AWS SDK
O exemplo abaixo usa um cliente do S3 para carregar um objeto em cada invocação. O cliente é clonado diretamente no fechamento sem `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
```
### Exemplo: grupos de conexão de banco de dados
Quando o manipulador precisar acessar um estado compartilhado, como um cliente e uma configuração, envolva-o em [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html) e clone `Arc` em cada invocação:
```
#[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
```
## Diretório /tmp compartilhado
O diretório `/tmp` é compartilhado entre todas as chamadas simultâneas no mesmo ambiente de execução. Use nomes de arquivo exclusivos para cada chamada (por exemplo, inclua o ID da solicitação) ou implemente o bloqueio explícito de arquivos para evitar corrupção de dados.
## Registro em log
A intercalação de logs (entradas de logs de solicitações diferentes sendo intercaladas em logs) é normal em sistemas multissimultâneos. Funções do Lambda que utilizam Instâncias gerenciadas do Lambda oferecem suporte ao formato de log JSON estruturado por meio de [controles avançados de registro de logs](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) do Lambda. Esse formato inclui o `requestId`, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Consulte para obter mais informações [Implementar registro em log avançado com a caixa Tracing](rust-logging.md#rust-logging-tracing).
## Contexto da solicitação
O objeto `Context` é passado diretamente para cada invocação do manipulador. Use `event.context.request_id` para acessar o ID para a solicitação atual.
Use `event.context.xray_trace_id` para acessar o ID de rastreamento do X-Ray. O Lambda não oferece suporte à variável de ambiente `_X_AMZN_TRACE_ID` com instâncias gerenciadas do Lambda. O ID de rastreamento do X-Ray é propagado automaticamente ao usar o AWS SDK para Rust.
Use `event.context.deadline` para detectar tempos limite: ele contém o prazo de invocação em milissegundos.
## Inicialização e desligamento
A inicialização da função ocorre uma vez por ambiente de execução. Os objetos criados durante a inicialização são compartilhados entre as solicitações.
Para as funções do Lambda com extensões, o ambiente de execução emite um sinal SIGTERM durante o desligamento. Esse sinal é usado por extensões como um gatilho para tarefas de limpeza, como a liberação de buffers. `lambda_runtime` oferece uma função auxiliar para simplificar a configuração do tratamento de sinais de desligamento ordenado, [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 saber mais sobre o ciclo de vida do ambiente de execução, consulte [Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda](lambda-runtime-environment.md).
## Versões de dependências
As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir:
+ `lambda_runtime`: versão 1.1.1 ou posterior, com o recurso `concurrency-tokio` habilitado
+ A versão mínima compatível do Rust (MSRV) é a 1.84.0.
# Rede para instâncias gerenciadas do Lambda
Ao executar funções de instâncias gerenciadas do Lambda, é necessário configurar a conectividade de rede para permitir que suas funções acessem recursos fora da VPC. Isso inclui serviços da AWS como o Amazon S3 e o DynamoDB. A conexão também é necessária para transmitir dados de telemetria para o CloudWatch Logs e o X-Ray.
## Opções de conectividade
Há três abordagens principais para configurar a conectividade da VPC, cada uma com diferentes compensações de custo, segurança e complexidade.
## Sub-rede pública com um gateway da Internet
Essa opção usa uma sub-rede pública com acesso direto à Internet por meio de um gateway da Internet. É possível escolher entre configurações IPv4 e IPv6.
### IPv4 com gateway da Internet
**Para configurar a conectividade de IPv4 com um gateway da Internet**
1. Crie ou use uma sub-rede pública existente com um bloco CIDR IPv4.
1. Anexar um gateway da Internet à VPC.
1. Atualize a tabela de rotas para rotear o tráfego de `0.0.0.0/0` para o gateway da Internet.
1. Certifique-se de que os recursos tenham endereços IPv4 públicos ou endereços IP elásticos atribuídos a ela.
1. Configurar grupos de segurança para permitir o tráfego de saída nas portas necessárias.
Essa configuração fornece conectividade bidirecional, permitindo conexões de saída de suas funções e conexões de entrada da Internet.
### IPv6 com gateway da Internet
**Para configurar a conectividade de IPv6 com um gateway da Internet**
1. Ative o IPv6 na sua VPC.
1. Crie ou use uma sub-rede pública existente com um bloco CIDR IPv6 atribuído.
1. Conecte um gateway da Internet à sua VPC (o mesmo gateway da Internet pode lidar com IPv4 e IPv6).
1. Atualize a tabela de rotas para rotear o tráfego de `::/0` para o gateway da Internet.
1. Verifique se os serviços da AWS que você precisa acessar oferecem suporte a IPv6 na sua região.
1. Configurar grupos de segurança para permitir o tráfego de saída nas portas necessárias.
Essa configuração fornece conectividade bidirecional usando endereçamento IPv6.
### IPv6 com gateway da Internet somente de saída
**Para configurar a conectividade de IPv6 com um gateway da Internet somente de saída**
1. Ative o IPv6 na sua VPC.
1. Crie ou use uma sub-rede pública existente com um bloco CIDR IPv6 atribuído.
1. Vincule um gateway da Internet somente de saída à sua VPC.
1. Atualize a tabela de rotas para rotear o tráfego de `::/0` para o gateway da Internet somente de saída.
1. Verifique se os serviços da AWS que você precisa acessar oferecem suporte a IPv6 na sua região.
1. Configurar grupos de segurança para permitir o tráfego de saída nas portas necessárias.
Essa configuração fornece conectividade somente de saída, impedindo conexões de entrada da Internet e permitindo que suas funções iniciem as conexões de saída.
## Endpoints da VPC
Os endpoints da VPC permitem que você conecte de forma privada sua VPC aos serviços da AWS com suporte sem exigir um gateway da Internet, dispositivo NAT, conexão de VPN ou conexão do AWS Direct Connect. O tráfego entre sua VPC e o serviço da AWS não sai da rede da Amazon.
**Para configurar endpoints da VPC**
1. Abra o console da Amazon VPC, em [console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. No painel de navegação, escolha **Endpoints**.
1. Escolha **Criar endpoint**.
1. Em **Categoria do serviço**, escolha **Serviços do AWS**.
1. Em **Nome do serviço**, selecione o endpoint de serviço de que você precisa (por exemplo, `com.amazonaws.region.s3` para o Amazon S3).
1. Em **VPC**, selecione sua VPC.
1. Em **Sub-redes**, selecione as sub-redes nas quais deseja criar as interfaces de rede de endpoint. Para obter alta disponibilidade, selecione sub-redes em várias zonas de disponibilidade.
1. Em **Grupos de segurança**, selecione os grupos de segurança para associar às interfaces de rede do endpoint. Os grupos de segurança devem permitir tráfego de entrada do grupo de segurança da sua função nas portas necessárias.
1. Escolha **Criar endpoint**.
Repita essas etapas para cada serviço da AWS que suas funções precisem acessar.
## Sub-rede privada com um gateway de NAT
Essa opção usa um gateway de NAT para fornecer acesso à Internet para recursos em sub-redes privadas, mantendo os recursos privados.
**Para configurar uma sub-rede privada com um gateway de NAT**
1. Crie uma sub-rede pública (se ainda não existir) com um bloco CIDR.
1. Anexar um gateway da Internet à VPC.
1. Crie um gateway de NAT na sub-rede pública e atribua um endereço IP elástico.
1. Atualize a tabela de rotas da sub-rede pública para adicionar uma rota:`0.0.0.0/0` → gateway da Internet.
1. Crie ou use uma sub-rede provada existente com um bloco CIDR.
1. Atualize a tabela de rotas da sub-rede privada para adicionar a rota: `0.0.0.0/0` → gateway de NAT.
1. Configurar grupos de segurança para permitir o tráfego de saída nas portas necessárias.
Para obter alta disponibilidade, implante um gateway de NAT em cada zona de disponibilidade e configure tabelas de rotas por zona de disponibilidade para usar o gateway de NAT local. Isso evita cobranças de transferência de dados entre AZs e melhora a resiliência.
## Escolha de uma opção de conectividade
Considere os fatores a seguir ao escolher uma opção de conectividade:
**Sub-rede pública com gateway da Internet**
+ Configuração mais simples com menor custo
+ Adequado para ambientes de teste e desenvolvimento
+ Os recursos podem receber conexões de entrada da Internet (consideração de segurança)
+ Suporte a IPv4 e a IPv6.
**Endpoints da VPC**
+ Segurança máxima, o tráfego permanece dentro da rede da AWS
+ Menor latência em comparação com o roteamento da Internet
+ Recomendado para ambientes de produção com requisitos rígidos de segurança
+ Maior custo por endpoint, por zona de disponibilidade e por GB processado
+ Requer um endpoint em cada zona de disponibilidade para alta disponibilidade
**Sub-rede privada com um gateway de NAT**
+ Os recursos permanecem privados sem acesso de entrada à Internet
+ Padrão de arquitetura corporativa
+ Oferece suporte a todo o tráfego de IPv4 da Internet
+ Custo moderado com gateway de NAT por hora e taxas de processamento de dados
+ Oferece suporte somente a IPv4
## Próximas etapas
+ Saiba mais sobre [provedores de capacidade para instâncias gerenciadas do Lambda](lambda-managed-instances-capacity-providers.md)
+ Entenda a [escalabilidade para instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
+ Consulte os guias específicos de runtime para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) e [Python](lambda-managed-instances-python-runtime.md)
+ Entenda a [segurança e as permissões das instâncias gerenciadas do Lambda](lambda-managed-instances-security.md)
# Monitoramento de instâncias gerenciadas do Lambda
É possível monitorar as instâncias gerenciadas do Lambda usando métricas do Amazon CloudWatch. O Lambda publica automaticamente métricas no CloudWatch para ajudá-lo a monitorar a utilização de recursos, monitorar custos e otimizar a performance.
## Métricas disponíveis
As instâncias gerenciadas do Lambda fornecem métricas em dois níveis: nível do provedor de capacidade e nível do ambiente de execução.
### Métricas do nível do provedor de capacidade
As métricas do nível do provedor de capacidade fornecem visibilidade da utilização geral dos recursos em suas instâncias. Essas métricas usam as dimensões a seguir:
+ **CapacityProviderName**: o nome do seu provedor de capacidade
+ **InstanceType**: o tipo de instância do EC2.
**Métricas de utilização de recursos:**
+ **CPUUtilization**: o percentual de utilização de CPU em todas as instâncias no provedor de capacidade
+ **MemoryUtilization**: o percentual de utilização de memória em todas as instâncias no provedor de capacidade
**Métricas de capacidade:**
+ **vCPUAvailable**: a quantidade de vCPU disponível nas instâncias para alocação (em contagem)
+ **MemoryAvailable**: a quantidade de memória disponível nas instâncias para alocação (em bytes)
+ **vCpuAllocated**: a quantidade de vCPU alocada em instâncias para ambientes de execução (em contagem)
+ **MemoryAllocated**: a quantidade de memória alocada em instâncias para ambientes de execução (em bytes)
### Métricas do nível do ambiente de execução
As métricas do nível do ambiente de execução fornecem visibilidade sobre a utilização de recursos e a simultaneidade de funções individuais. Essas métricas usam as dimensões a seguir:
+ **CapacityProviderName**: o nome do seu provedor de capacidade
+ **FunctionName**: o nome da função do Lambda
+ **Recurso**: por recurso, visualize as métricas de uma versão específica de uma função.
**nota**
Para instâncias gerenciadas do Lambda (LMI), a dimensão `Resource` oferece suporte somente a versões de função. O formato de é `:`.
**Métricas disponíveis do ambiente de execução:**
+ **ExecutionEnvironmentConcurrency**: a simultaneidade máxima em um período de amostra de 5 minutos
+ **ExecutionEnvironmentConcurrencyLimit**: o limite máximo de simultaneidade por ambiente de execução
+ **ExecutionEnvironmentCPUUtilization**: o percentual de utilização de CPU para os ambientes de execução da função
+ **ExecutionEnvironmentMemoryUtilization**: o percentual de utilização de memória para os ambientes de execução da função
## Frequência e retenção das métricas
As métricas das instâncias gerenciadas do Lambda são publicadas em intervalos de 5 minutos e mantidas por 15 meses.
## Visualização de métricas com o CloudWatch
**Para visualizar as métricas das instâncias gerenciadas do Lambda no console do CloudWatch**
1. Abra o console do CloudWatch, em [console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Métricas**.
1. Na guia **Todas as métricas**, escolha **AWS/Lambda**.
1. Escolha a dimensão da métrica que você deseja visualizar:
+ Para métricas do nível do provedor de capacidade, filtre por **CapacityProviderName** e **InstanceType**
+ Para métricas em nível do ambiente de execução, filtre por **CapacityProviderName**, **FunctionName** e **Resource**
1. Escolha a métrica que você deseja monitorar.
## Uso de métricas para otimizar a performance
Monitore a utilização da CPU e da memória para entender se suas funções estão dimensionadas adequadamente. A alta utilização pode indicar a necessidade de tipos de instância maiores ou maior alocação de memória funcional. Acompanhe as métricas de simultaneidade para entender o comportamento de escalabilidade e identificar possíveis controles de utilização.
Monitore as métricas de capacidade para verificar se recursos suficientes estão disponíveis para suas workloads. As métricas **vCPUAvailable** e **MemoryAvailable** ajudam você a entender a capacidade restante em suas instâncias.
## Próximas etapas
+ Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
+ Consulte os guias específicos de runtime para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) e [Python](lambda-managed-instances-python-runtime.md)
+ Configure a [conectividade de VPC para seus provedores de capacidade](lambda-managed-instances-networking.md)
+ Entenda a [segurança e as permissões das instâncias gerenciadas do Lambda](lambda-managed-instances-security.md)
# Cotas de instâncias gerenciadas pelo Lambda
Esta página descreve as cotas de serviço para instâncias gerenciadas do AWS Lambda. Essas cotas são separadas das cotas do AWS Lambda (padrão). Algumas cotas podem ser aumentadas mediante solicitação.
## Cotas de solicitações da API do Lambda
Essas cotas controlam a taxa na qual é possível fazer chamadas de API para gerenciar provedores de capacidade de instâncias gerenciadas do Lambda. Os limites de taxa de API de leitura e gravação se aplicam a todas as operações combinadas do provedor de capacidade, incluindo criação, atualização, descrição e exclusão de provedores de capacidade.
| Recurso | Quota |
| --- | --- |
| A taxa máxima combinada (solicitações por segundo) para todas as APIs de leitura do provedor de capacidade | 15 solicitações por segundo. Não pode ser aumentado. |
| A taxa máxima combinada (solicitações por segundo) para todas as APIs de gravação do provedor de capacidade | 1 solicitação por segundo Não pode ser aumentado. |
## Cotas de recirso de instâncias gerenciadas pelo Lambda
Essas cotas definem os limites dos principais recursos das instâncias gerenciadas do Lambda em sua conta da AWS. Elas controlam o número de provedores de capacidade que podem ser criados e o número de versões de funções que podem ser associadas a cada provedor de capacidade.
| Recurso | Quota |
| --- | --- |
| Provedores de capacidade | 1.000. O número máximo de provedores de capacidade criados em uma conta. |
| Versões de função por provedor de capacidade | 100. O número máximo de versões de função por provedor de capacidade. Não pode ser aumentado. |
## Cotas de mapeamento da origem do evento
Essas cotas controlam o throughput e os limites de configuração para o processamento de eventos de vários serviços da AWS nas instâncias gerenciadas do Lambda. Os limites de throughput garantem uma performance previsível, enquanto os limites de contagem de mapeamento ajudam a manter a estabilidade do serviço. Os mapeamentos da origem do evento em instâncias gerenciadas do Lambda oferecem suporte ao Amazon SQS, DynamoDB Streams, Amazon Kinesis Data Streams, Amazon MSK e Apache Kafka autogerenciado como origens de evento.
| Recurso | Quota |
| --- | --- |
| Throughput padrão de mapeamento da origem do evento do SQS em instâncias gerenciadas do Lambda | 5 MB por segundo. Não pode ser aumentado. |
| Throughput padrão de mapeamento da origem do evento do Kafka em instâncias gerenciadas do Lambda | 1 MB por segundo. Não pode ser aumentado. |
| Mapeamentos da origem do evento padrão do Kafka em instâncias gerenciadas do Lambda | 100 mapeamentos da origem do evento Não pode ser aumentado. |
| Throughput de mapeamento da origem do evento do Kinesis em instâncias gerenciadas do Lambda | 25 MB por segundo. Pode ser aumentado. |
| Throughput de mapeamento da origem do evento do DynamoDB em instâncias gerenciadas do Lambda | 10 MB por segundo. Pode ser aumentado. |
| Throughput de solicitações de invocação para invocações assíncronas em instâncias gerenciadas do Lambda | 5 MB por segundo. Pode ser aumentado. |
## Solicitar um aumento de cota
Para cotas que podem ser aumentadas, é possível solicitar um aumento por meio do console do Service Quotas.
**Para solicitar um aumento da cota**
1. Abra o console do Service Quotas em [console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/).
1. No painel de navegação, escolha **Serviços da AWS**.
1. Escolha **AWS Lambda**.
1. Selecione a cota que você deseja aumentar.
1. Selecione **Solicitar aumento de cota**.
1. Insira o novo valor da cota e forneça uma justificativa para o aumento.
1. Escolha **Solicitar**.
## Próximas etapas
+ Saiba mais sobre [provedores de capacidade para instâncias gerenciadas do Lambda](lambda-managed-instances-capacity-providers.md)
+ Entenda a [escalabilidade para instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
+ Consulte os guias específicos de runtime para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) e [Python](lambda-managed-instances-python-runtime.md)
+ Configure a [conectividade de VPC para seus provedores de capacidade](lambda-managed-instances-networking.md)
# Práticas recomendadas para instâncias gerenciadas do Lambda
## Configuração do provedor de capacidade
**Separe os provedores de capacidade por nível de confiança.** Crie diferentes provedores de capacidade para workloads com diferentes requisitos de segurança. Todas as funções atribuídas ao mesmo provedor de capacidade devem ser mutuamente confiáveis, pois os provedores de capacidade servem como o limite de segurança.
**Use nomes descritivos.** Nomeie os provedores de capacidade para indicar claramente o uso pretendido e o nível de confiança (por exemplo, `production-trusted`, `dev-sandbox`). Isso ajuda as equipes a entenderem o propósito e a postura de segurança de cada provedor de capacidade.
**Use várias zonas de disponibilidade**. Especifique sub-redes dentre várias zonas de disponibilidade ao criar provedores de capacidade. O Lambda inicia três instâncias por padrão para resiliência de zona de disponibilidade, garantindo alta disponibilidade para suas funções.
## Seleção do tipo de instância
**Deixe o Lambda escolher os tipos de instância.** Por padrão, o Lambda escolhe os melhores tipos de instância para sua workload. Recomendamos que as instâncias gerenciadas do Lambda escolham os tipos de instância para você, pois restringir o número de tipos de instância possíveis pode resultar em menor disponibilidade.
**Especifique os tipos de instância para requisitos específicos.** Se você tiver requisitos específicos de hardware, defina os tipos de instância permitidos em uma lista de instâncias compatíveis. Por exemplo:
+ Para aplicações que exijam alta largura de banda da rede, selecione vários tipos de instâncias n.
+ Para ambientes de teste ou desenvolvimento com restrições de custo, escolha tipos de instância menores, como a m7a.large
## Configuração da função
**Escolha as configurações apropriadas de memória e vCPU.** Selecione configurações de memória e vCPU que ofereçam suporte a execuções multissimultâneas da sua função. O tamanho mínimo de função com suporte é de 2 GB e 1 vCPU.
+ Para aplicações em Python, escolha uma proporção maior de memória para vCPUs (como 4 para 1 ou 8 para 1) devido à forma como o Python lida com a multissimultaneidade
+ Para operações intensivas de CPU ou funções que executem pouca E/S, escolha mais de uma vCPU
+ Para aplicações com alto nível de E/S, como serviços da Web ou trabalhos em lote, a multissimultaneidade oferece o maior benefício
**Configure a simultaneidade máxima de forma adequada.** O Lambda escolhe padrões sensatos para a simultaneidade máxima que equilibram o consumo de recursos e o throughput. Ajuste essa configuração com base no uso de recursos da sua função:
+ Aumente a simultaneidade máxima (até 64 por vCPU) se as suas invocações de função usarem muito pouca CPU
+ Reduza a simultaneidade máxima se a sua aplicação consumir uma grande quantidade de memória e muito pouca CPU
Observe que ambientes de execução com simultaneidade muito baixa podem apresentar controles de utilização e dificuldade de escalabilidade.
## Scaling configuration (Configuração de escalabilidade)
**Defina a meta apropriada de utilização dos recursos.** Por padrão, o Lambda mantém espaço suficiente para que seu tráfego dobre em 5 minutos sem controles de utilização. Ajuste isso com base nas características da sua workload:
+ Para workloads muito estáveis ou aplicações que não sejam sensíveis a controles de utilização, defina a meta em um nível alto para obter maior utilização e custos mais baixos
+ Para workloads com possíveis picos de tráfego, defina metas de recursos em um nível baixo para manter mais espaço livre
**Planeje o crescimento do tráfego.** Se seu tráfego mais do que dobrar em 5 minutos, será possível ver controles de utilização quando o Lambda aumentar a escala verticalmente das instâncias e ambientes de execução. Projete sua aplicação para lidar com possíveis controles de utilização durante períodos rápidos de aumento da escala verticalmente.
## Segurança
**Aplique o privilégio mínimo às permissões do PassCapacityProvider.** Conceda permissões `lambda:PassCapacityProvider` somente para os provedores de capacidade necessários. Use permissões em nível de recurso para restringir quais provedores de capacidade os usuários podem atribuir às funções.
**Monitore o uso do provedor de capacidade.** Use o AWS CloudTrail para monitorar as atribuições e os padrões de acesso do provedor de capacidade. Isso ajuda a identificar tentativas de acesso não autorizado e garante a conformidade com as políticas de segurança.
**Separe as workloads não confiáveis.** Não confie em contêineres para isolamento de segurança entre workloads não confiáveis. Use diferentes provedores de capacidade para separar workloads que não sejam mutuamente confiáveis.
## Otimização de custos
**Aproveite as opções de preços do EC2.** Aproveite os Savings Plans e as instâncias reservadas do EC2 para reduzir custos. Essas opções de preços se aplicam à computação subjacente do EC2 (a taxa de gerenciamento de 15% não é descontada).
**Otimize para workload em estado fixo.** As instâncias gerenciadas do Lambda são mais adequadas para funções de estado fixo com tráfego previsível de alto volume. Para padrões de tráfego intermitente, o Lambda (padrão) pode ser mais econômico.
**Monitore a utilização dos recursos.** Acompanhe as métricas do CloudWatch para entender a utilização da CPU e da memória. Ajuste a alocação de memória da função e a seleção do tipo de instância com base nos padrões reais de uso para otimizar os custos.
## Monitoramento e observabilidade
**Monitore as métricas do provedor de capacidade.** Acompanhe as métricas no nível do provedor de capacidade, incluindo CPUUtilization, MemoryUtilization, vCPUAvailable e MemoryAvailable para verificar se há recursos suficientes disponíveis para suas workloads.
**Monitore as métricas do ambiente de execução.** Acompanhe as métricas no nível do ambiente de execução, incluindo ExecutionEnvironmentConcurrency e ExecutionEnvironmentConcurrencyLimit, para entender o comportamento de escalabilidade e identificar possíveis controles de utilização.
**Defina alarmes do CloudWatch.** Crie alarmes do CloudWatch para as principais métricas para identificar problemas de forma proativa:
+ Alta utilização de CPU ou memória
+ Baixa capacidade disponível
+ Aproximando-se dos limites de simultaneidade
## Considerações específicas de cada linguagem
**Siga as práticas recomendadas específicas para cada idioma.** Cada linguagem de programação lida com a multiconcorrência de maneira diferente. Consulte os guias específicos para cada idioma para obter recomendações detalhadas:
+ **Java**: use coleções com threads seguras, `AtomicInteger` e `ThreadLocal` para o estado específico da solicitação
+ **Node.js**: use o InvokeStore para todos os estados específicos da solicitação e evite variáveis globais
+ **Python**: use nomes de arquivo exclusivos em `/tmp` com IDs de solicitação e considere o isolamento de memória baseado em processos
+ **Rust:** use `run_concurrent` em vez de`run`, com o recurso `concurrency-tokio` habilitado. O manipulador deve ser `Clone` \$1 `Send`.
**Teste a segurança da thread e problemas de simultaneidade.** Antes de implantar na produção, teste minuciosamente suas funções quanto a problemas de segurança da thread, condições de corrida e isolamento de estado adequado sob carga simultânea.
## Próximas etapas
+ Saiba mais sobre [provedores de capacidade para instâncias gerenciadas do Lambda](lambda-managed-instances-capacity-providers.md)
+ Entenda a [escalabilidade para instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
+ Consulte os guias específicos de runtime para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) e [Python](lambda-managed-instances-python-runtime.md)
+ Configure a [conectividade de VPC para seus provedores de capacidade](lambda-managed-instances-networking.md)
+ Monitore instâncias gerenciadas do Lambda com [métricas do CloudWatch](lambda-managed-instances-monitoring.md)
# Solução de problemas de instâncias gerenciadas do Lambda
## Problemas de controle de utilização e escalabilidade
### Altas taxas de erro durante o aumento de escala na vertical
**Problema:** você enfrenta erros de controle de utilização (HTTP 429) quando o tráfego aumenta rapidamente.
**Causa:** as instâncias gerenciadas do Lambda escalam de forma assíncrona com base na utilização de recursos da CPU e na saturação da multissimultaneidade. Se seu tráfego mais do que dobrar em 5 minutos, será possível ver controles de utilização quando o Lambda aumentar a escala verticalmente das instâncias e ambientes de execução para atender à demanda.
**Solução:**
+ **Ajuste a utilização de recursos de destino:** se sua workload tiver padrões de tráfego previsíveis, defina uma menor utilização dos recursos de destino para manter espaço adicional para picos de tráfego.
+ **Capacidade de pré-aquecimento:** para aumentos planejados de tráfego, aumente gradualmente o tráfego por um longo período para permitir que a escalabilidade acompanhe o ritmo.
+ **Monitore as métricas de escalabilidade:** acompanhe as métricas de erro de controle de utilização para compreender o motivo dos problemas de controle de utilização e escalabilidade de capacidade.
+ **Revise a configuração da função:** certifique-se de que suas configurações de memória de função e vCPU suportem execuções multissimultâneas. Aumente a memória funcional ou a alocação de vCPUs, se necessário.
### Redução lenta da escala na vertical
**Problema:** as instâncias demoram muito para reduzir a escala verticalmente depois que o tráfego diminui.
**Causa:** as instâncias gerenciadas do Lambda reduzem a escala verticalmente de forma gradual para manter a disponibilidade e para evitar mudanças rápidas de capacidade que possam afetar a performance.
**Solução:**
Esse comportamento é esperado. O Lambda reduz a escala verticalmente das instâncias de forma conservadora para garantir a estabilidade. Monitore suas métricas do CloudWatch para acompanhar o número de instâncias em execução.
## Problemas de simultaneidade
### Ambientes de execução com baixa simultaneidade sofrem controles de utilização
**Problema:** suas funções sofrem controle de utilização apesar de terem capacidade disponível.
**Causa:** os ambientes de execução com simultaneidade máxima muito baixa podem ter dificuldade em escalar de forma eficaz. As instâncias gerenciadas do Lambda são projetadas para aplicações multissimultâneas.
**Solução:**
+ **Aumente a simultaneidade:** se suas invocações de função usarem muito pouca CPU, aumente a configuração de simultaneidade máxima até 64 por vCPU.
+ **Otimize o código da função:** revise seu código de função para reduzir o consumo de CPU por invocação, permitindo maior simultaneidade.
+ **Ajuste a memória a vCPU da função:** certifique-se de que sua função tenha recursos suficientes para lidar com várias invocações simultâneas.
### Problemas de segurança de thread (runtime de Java)
**Problema:** sua função de Java produz resultados incorretos ou passa por condições de corrida sob carga.
**Causa:** vários threads executam o método manipulador simultaneamente, e o estado compartilhado não é seguro para threads.
**Solução:**
+ Use `AtomicInteger` ou `AtomicLong` para contadores em vez de tipos primitivos
+ Substitua `HashMap` por `ConcurrentHashMap`
+ Use `Collections.synchronizedList()` para encapsular `ArrayList`
+ Use `ThreadLocal` para o estado específico da solicitação
+ Acesse os IDs de rastreamento a partir do objeto de contexto do Lambda, não de variáveis de ambiente
Para obter orientação detalhada, consulte a documentação do [runtime de Java para instâncias gerenciadas do Lambda](lambda-managed-instances-java-runtime.md).
### Problemas de isolamento de estado (runtime de Node.js)
**Problema:** sua função de Node.js retorna dados de diferentes solicitações ou sofre corrupção de dados.
**Causa:** as variáveis globais são compartilhadas entre invocações simultâneas no mesmo thread de operador. Quando as operações assíncronas geram controle, outras invocações podem modificar o estado compartilhado.
**Solução:**
+ Instale e use `@aws/lambda-invoke-store` para todos os estados específicos da solicitação
+ Substitua as variáveis globais por `InvokeStore.set()` e `InvokeStore.get()`
+ Use nomes de arquivo exclusivos em `/tmp` com IDs de solicitação
+ Acesse os IDs de rastreamento usando `InvokeStore.getXRayTraceId()` em vez de variáveis de ambiente
Para obter orientação detalhada, consulte a documentação do [runtime de Node.js para instâncias gerenciadas do Lambda](lambda-managed-instances-nodejs-runtime.md).
### Conflitos de arquivos (runtime de Python)
**Problema:** sua função de Python lê dados incorretos dos arquivos em `/tmp`.
**Causa:** vários processos compartilham o diretório `/tmp`. Gravações simultâneas no mesmo arquivo podem causar corrupção de dados.
**Solução:**
+ Use nomes de arquivo exclusivos com IDs de solicitação: `/tmp/request_{context.request_id}.txt`
+ Use o bloqueio de arquivos com `fcntl.flock()` para arquivos compartilhados
+ Limpe arquivos temporários com `os.remove()` após o uso
Para obter orientação detalhada, consulte a documentação do [runtime de Python para instâncias gerenciadas do Lambda](lambda-managed-instances-python-runtime.md).
## Problemas de performance
### Alta utilização de memória
**Problema:** suas funções apresentam alta utilização de memória ou erros de memória insuficiente.
**Causa:** cada solicitação simultânea em Python é executada em um processo separado com seu próprio espaço de memória. O uso total de memória é igual à memória por processo multiplicada pelos processos simultâneos.
**Solução:**
+ Monitore a métrica `MemoryUtilization` no CloudWatch
+ Reduza a configuração `MaxConcurrency` se o uso da memória se aproximar do limite de memória da função
+ Aumente a alocação de memória da função para suportar maior simultaneidade
+ Otimize o uso da memória carregando dados sob demanda em vez de durante a inicialização
### Performance inconsistente
**Problema:** a performance da função varia significativamente entre as invocações.
**Causa:** o Lambda pode selecionar diferentes tipos de instância com base na disponibilidade, ou as funções podem estar sendo executadas em instâncias com disponibilidade variável de recursos.
**Solução:**
+ **Especifique os tipos de instância permitidos:** se você tiver requisitos de performance específicos, configure os tipos de instância permitidos em seu provedor de capacidade para limitar os tipos de instância que o Lambda pode selecionar.
+ **Monitore as métricas em nível de instância:** acompanhe `CPUUtilization` e `MemoryUtilization` no nível do provedor de capacidade para identificar restrições de recursos.
+ **Analise as métricas de capacidade:** verifique `vCPUAvailable` e `MemoryAvailable` para garantir que recursos suficientes estejam disponíveis em suas instâncias.
## Problemas do provedor de capacidade
### A versão da função falha ao se tornar ATIVA
**Problema:** sua versão da função permanece em um estado pendente após a publicação.
**Causa:** o Lambda está executando instâncias gerenciadas e iniciando ambientes de execução. Esse processo leva tempo, especialmente para a primeira versão da função em um novo provedor de capacidade.
**Solução:**
Aguarde até que o Lambda conclua o processo de inicialização. O Lambda executa três instâncias por padrão para resiliência de AZ e inicia três ambientes de execução antes de marcar a versão da sua função como ATIVA. Isso normalmente demora vários minutos.
### Não é possível excluir o provedor de capacidade
**Problema:** você recebe um erro ao tentar excluir um provedor de capacidade.
**Causa:** não é possível excluir um provedor de capacidade que tenha versões de função anexadas a ele.
**Solução:**
1. Identifique todas as versões de funções usando o provedor de capacidade com a API `ListFunctionVersionsByCapacityProvider`.
1. Exclua ou atualize essas versões de funções para remover a associação do provedor de capacidade.
1. Tente excluir novamente o provedor de capacidade.
### Mensagens de erro genéricas durante a publicação da função
**Problema:** você encontra mensagens de erro genéricas, como “Ocorreu um erro interno durante a publicação” ao publicar as funções.
**Solução:**
+ **Verifique as permissões do IAM:** certifique-se de ter a permissão `lambda:PassCapacityProvider` para o provedor de capacidade que está tentando usar.
+ **Verifique a configuração do provedor de capacidade:** confirme se seu provedor de capacidade está no estado ATIVO usando a API `GetCapacityProvider`.
+ **Revise a configuração da VPC:** certifique-se de que as sub-redes e os grupos de segurança especificados em seu provedor de capacidade estejam configurados e acessíveis corretamente.
+ **Verifique os logs do AWS CloudTrail:** revise os logs do CloudTrail para obter informações detalhadas de erro sobre a operação que falhou.
## Problemas de monitoramento e observabilidade
### Métricas ausentes do CloudWatch
**Problema:** você não vê as métricas esperadas no CloudWatch para seu provedor de capacidade ou funções.
**Causa:** as métricas são publicadas em intervalos de 5 minutos. Novos provedores de capacidade ou funções podem não ter métricas disponíveis imediatamente.
**Solução:**
Aguarde pelo menos de 5 a 10 minutos após publicar uma versão de função antes de esperar que as métricas apareçam no CloudWatch. Verifique se você está vendo o namespace (`AWS/Lambda`) e as dimensões (`CapacityProviderName`, `FunctionName` ou `InstanceType`) corretos.
### Não é possível localizar os logs do CloudWatch
**Problema:** sua função é executada com êxito, mas você não consegue encontrar os logs no CloudWatch Logs.
**Causa:** as instâncias gerenciadas do Lambda são executadas em sua VPC e exigem conectividade de rede para enviar logs para o CloudWatch Logs. Sem a configuração adequada de conectividade da VPC, suas funções não podem alcançar o endpoint do serviço CloudWatch Logs.
**Solução:**
Configure a conectividade da VPC para permitir que suas funções enviem logs para o CloudWatch Logs. Você tem três opções:
**Opção 1: endpoint da VPC para o CloudWatch Logs (recomendado para produção)**
1. Abra o console da Amazon VPC, em [console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. No painel de navegação, escolha **Endpoints**.
1. Escolha **Criar endpoint**.
1. Em **Categoria do serviço**, escolha **Serviços do AWS**.
1. Em **Nome do serviço**, selecione `com.amazonaws.region.logs` (substitua `region` por sua região da AWS).
1. Em **VPC**, selecione a VPC usada pelo seu provedor de capacidade.
1. Em **Sub-redes**, selecione as sub-redes nas quais deseja criar as interfaces de rede de endpoint. Para obter alta disponibilidade, selecione sub-redes em várias zonas de disponibilidade.
1. Em **Grupos de segurança**, selecione os grupos de segurança que permitem tráfego de HTTPS de entrada (porta 443) no grupo de segurança da sua função.
1. Habilite **DNS privado** para o endpoint
1. Escolha **Criar endpoint**.
**Opção 2: sub-rede pública com gateway da Internet**
Se o seu provedor de capacidade usa sub-redes públicas, certifique-se de que:
1. Um gateway da Internet esteja conectado à VPC.
1. A tabela de rotas encaminhe o tráfego para `0.0.0.0/0` ao gateway da Internet
1. Os grupos de segurança permitam tráfego de HTTPS de saída na porta 443
**Opção 3: sub-rede privada com gateway de NAT**
Se o seu provedor de capacidade usa sub-redes privadas, certifique-se de que:
1. Exista um gateway de NAT em uma sub-rede pública
1. A tabela de rotas da sub-rede privada encaminhe o tráfego para `0.0.0.0/0` ao gateway de NAT
1. A tabela de rotas da sub-rede pública encaminhe o tráfego para `0.0.0.0/0` a um gateway da Internet
1. Os grupos de segurança permitam tráfego de HTTPS de saída na porta 443
Para obter orientações detalhadas sobre as opções de conectividade de VPC, consulte [Conectividade de VPC para instâncias gerenciadas do Lambda](lambda-managed-instances-networking.md).
### Dificuldade em correlacionar logs de solicitações simultâneas
**Problema:** os logs de solicitações diferentes são intercalados, dificultando o rastreamento de solicitações individuais.
**Causa:** a intercalação de logs é esperada, e é o comportamento padrão em sistemas multissimultâneos.
**Solução:**
+ **Use registro em log estruturado com formato JSON:** inclua o ID da solicitação em todas as instruções de log
+ **Java:** use Log4j com `ThreadContext` para incluir automaticamente o ID da solicitação
+ **Node.js:** Use `console.log()` com formatação JSON e inclua `InvokeStore.getRequestId()`
+ **Python:** use o módulo de registro em log padrão com formatação JSON e inclua `context.request_id`
Para obter orientação detalhada, consulte as páginas de documentação específicas do runtime.
## Obter ajuda adicional
Se você continuar enfrentando problemas depois de tentar essas soluções:
1. **Analise as métricas do CloudWatch:** verifique as métricas do provedor de capacidade e do ambiente de execução para identificar restrições de recursos ou problemas de escalabilidade.
1. **Verifique os logs do AWS CloudTrail:** revise os logs do CloudTrail para obter informações detalhadas sobre chamadas de API e erros.
1. **Entre em contato com o suporte da AWS:** se você não conseguir resolver o problema, entre em contato com o suporte da AWS com detalhes sobre a configuração do seu provedor de capacidade, a configuração da função e as mensagens de erro específicas que você está encontrando.
## Próximas etapas
+ Saiba mais sobre [provedores de capacidade para instâncias gerenciadas do Lambda](lambda-managed-instances-capacity-providers.md)
+ Entenda a [escalabilidade para instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
+ Consulte os guias específicos de runtime para [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) e [Python](lambda-managed-instances-python-runtime.md)
+ Monitore instâncias gerenciadas do Lambda com [métricas do CloudWatch](lambda-managed-instances-monitoring.md)
+ Revise as [Práticas recomendadas para instâncias gerenciadas do Lambda](lambda-managed-instances-best-practices.md)