# Solução de problemas no Lambda Os tópicos a seguir fornecem orientações para a solução de erros e problemas que você pode encontrar ao usar a API, o console ou as ferramentas do Lambda. Se encontrar um problema que não esteja listado aqui, você poderá usar o botão **Feedback** desta página para relatá-lo. Para obter mais orientações sobre solução de problemas e respostas a perguntas comuns de suporte, acesse a [Central de Conhecimento da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda). Para obter mais informações sobre depuração e solução de problemas de aplicações do Lambda, consulte [Debugging](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops) no Serverless Land. **Topics** + [Solucionar problemas de configuração no Lambda](troubleshooting-configuration.md) + [Solucionar problemas de implantação no Lambda](troubleshooting-deployment.md) + [Solucionar problemas de invocação no Lambda](troubleshooting-invocation.md) + [Solucionar problemas de execução no Lambda](troubleshooting-execution.md) + [Solucionar problemas de mapeamento de origens de eventos no Lambda](troubleshooting-event-source-mapping.md) + [Solucionar problemas de redes no Lambda](troubleshooting-networking.md) # Solucionar problemas de configuração no Lambda As configurações de configuração da sua função podem ter um impacto no desempenho geral e no comportamento da sua função do Lambda. Isso pode não causar erros reais na função, mas pode gerar tempos limite e resultados inesperados. Os tópicos a seguir fornecem orientações para a solução de problemas comuns que você pode encontrar relacionados a configurações de funções do Lambda. **Topics** + [Configurações de memória](#memory-config) + [Configurações que dependem da CPU](#cpu-bound-config) + [Tempos limite](#timeouts) + [Vazamento de memória entre invocações](#memory-leakage) + [Resultados assíncronos retornados para uma invocação posterior](#asynchronous-results) ## Configurações de memória Você pode configurar uma função do Lambda para usar entre 128 MB e 10.240 MB de memória. Por padrão, qualquer função criada no console recebe a menor quantidade de memória. Muitas funções do Lambda apresentam bom desempenho nessa configuração mais baixa. Porém, se você estiver importando grandes bibliotecas de código ou executando tarefas que consomem muita memória, 128 MB não serão suficientes. Se as suas funções estiverem sendo executadas muito mais lentamente do que o esperado, o primeiro passo é aumentar a configuração de memória. Para funções que dependem de memória, isso resolverá o gargalo e poderá melhorar a performance da função. ## Configurações que dependem da CPU Para operações de computação intensiva, se a sua função tiver um desempenho mais lento que o esperado, isso pode ser devido ao fato de ela estar vinculada à CPU. Nesse caso, a capacidade computacional da função não consegue acompanhar o trabalho. Embora o Lambda não permita que você modifique a configuração da CPU diretamente, a CPU é indiretamente controlada por meio das configurações de memória. O serviço Lambda aloca proporcionalmente mais CPU virtual à medida que você aloca mais memória. Com 1,8 GB de memória, uma função do Lambda tem uma vCPU inteira alocada e, acima desse nível, ela tem acesso a mais de um núcleo de vCPU. Com 10.240 MB, ela tem 6 vCPUs disponíveis. Em outras palavras, você pode melhorar a performance aumentando a alocação de memória, mesmo que a função não use toda a memória. ## Tempos limite Os [tempos limite](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html) de funções do Lambda podem ser definidos entre 1 e 900 segundos (15 minutos). Por padrão, o console do Lambda define o tempo limite como 3 segundos. O valor do tempo limite é uma medida de segurança para garantir que as funções não sejam executadas por tempo indefinido. Quando o valor de tempo limite é atingido, o Lambda interrompe a invocação da função. Se o valor do tempo limite for definido próximo da duração média de uma função, há um risco maior de que a função atinja o tempo limite inesperadamente. A duração de uma função pode variar dependendo da quantidade de transferência e processamento de dados, e da latência de qualquer serviço com o qual a função interaja. Causas comuns de tempo limite incluem: + Ao baixar dados de buckets do S3 ou de outros armazenamentos de dados, o download é maior ou demora mais do que a média. + Uma função faz uma solicitação a outro serviço, que leva mais tempo para responder. + Os parâmetros fornecidos a uma função exigem mais complexidade computacional na função, o que faz com que a invocação leve mais tempo. Ao testar sua aplicação, certifique-se de que os testes reflitam exatamente o tamanho e a quantidade de dados, bem como valores de parâmetros realistas. É importante usar conjuntos de dados nos limites superiores do que é razoavelmente esperado para sua workload. Além disso, implemente limites superiores na sua workload sempre que possível. Nesse exemplo, a aplicação pode usar um limite máximo de tamanho para cada tipo de arquivo. Em seguida, você pode testar a performance da sua aplicação para uma variedade de tamanhos de arquivo esperados, incluindo os limites máximos. ## Vazamento de memória entre invocações Variáveis globais e objetos armazenados na fase INIT de uma invocação do Lambda retêm seu estado entre invocações quentes. Eles são completamente redefinidos somente quando o ambiente de execução é executado pela primeira vez (também conhecido como “inicialização a frio”). Todas as variáveis armazenadas no manipulador são destruídas quando o manipulador é encerrado. É uma prática recomendada usar a fase INIT para configurar conexões de banco de dados, carregar bibliotecas, criar caches e carregar ativos imutáveis. Ao usar bibliotecas de terceiros em várias invocações no mesmo ambiente de execução, verifique a documentação relevante quanto ao uso em um ambiente de computação com tecnologia sem servidor. Algumas bibliotecas de conexão e registro de banco de dados podem salvar resultados de invocação intermediários e outros dados. Isso faz com que o uso de memória dessas bibliotecas aumente com as invocações quentes subsequentes. Se esse for o caso, você poderá descobrir que a função Lambda está ficando sem memória, mesmo que o código personalizado esteja descartando as variáveis corretamente. Esse problema afeta as invocações que ocorrem em ambientes de execução quente. Por exemplo, o código a seguir cria um vazamento de memória entre as invocações. A função do Lambda consome memória adicional com cada invocação aumentando o tamanho de uma matriz global: ``` let a = [] exports.handler = async (event) => { a.push(Array(100000).fill(1)) } ``` Configurada com 128 MB de memória, após invocar essa função mil vezes, a guia **Monitoramento** da função do Lambda mostra as mudanças típicas nas invocações, na duração e nas contagens de erros quando ocorre um vazamento de memória: ![\[operações de depuração figura 4\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-4.png) 1. **Invocações**: uma taxa de transação estável é interrompida periodicamente, pois as invocações demoram mais para serem concluídas. Durante o estado estável, o vazamento de memória não está consumindo toda a memória alocada da função. À medida que a performance diminui, o sistema operacional faz a paginação do armazenamento local para acomodar o aumento de memória exigido pela função, o que resulta na conclusão de menos transações. 1. **Duração**: antes que a função fique sem memória, ela finaliza as invocações em uma taxa constante de dois dígitos em milissegundos. Conforme a paginação ocorre, a duração demora uma ordem de magnitude maior. 1. **Contagem de erros**: quando o vazamento de memória excede a memória alocada, a função por fim apresenta erro porque a computação excede o tempo limite ou porque o ambiente de execução interrompe a função. Após o erro, o Lambda reinicia o ambiente de execução, o que explica por que os três gráficos mostram um retorno ao estado original. A expansão das métricas do CloudWatch por duração fornece mais detalhes sobre as estatísticas de duração mínima, máxima e média: ![\[operações de depuração figura 5\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-5.png) Para encontrar os erros gerados nas mil invocações, você pode usar a linguagem de consulta do CloudWatch Insights. A consulta seguinte exclui os logs informativos para relatar somente os erros: ``` fields @timestamp, @message | sort @timestamp desc | filter @message not like 'EXTENSION' | filter @message not like 'Lambda Insights' | filter @message not like 'INFO'  | filter @message not like 'REPORT' | filter @message not like 'END' | filter @message not like 'START' ``` Quando executado no grupo de logs dessa função, o resultado mostra que os tempos limite foram responsáveis pelos erros periódicos: ![\[operações de depuração figura 6\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-6.png) ## Resultados assíncronos retornados para uma invocação posterior Para código de função que usa padrões assíncronos, é possível que os resultados de retorno de chamada de uma invocação sejam retornados em uma invocação futura. Este exemplo usa o Node.js, mas a mesma lógica pode ser aplicada a outros runtimes usando padrões assíncronos. A função usa a sintaxe tradicional de retorno de chamada em JavaScript. Ela chama uma função assíncrona com um contador incremental que rastreia o número de invocações: ``` let seqId = 0 exports.handler = async (event, context) => { console.log(`Starting: sequence Id=${++seqId}`) doWork(seqId, function(id) { console.log(`Work done: sequence Id=${id}`) }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` Quando invocados várias vezes em sequência, os resultados dos retornos de chamada ocorrem nas invocações subsequentes: ![\[operações de depuração figura 7\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-7.png) 1. O código chama a função `doWork`, fornecendo uma função de retorno de chamada como o último parâmetro. 1. A função `doWork` leva algum tempo para ser concluída antes de invocar o retorno de chamada. 1. O registro de log da função indica que a invocação está terminando antes da função `doWork` concluir a execução. Além disso, depois de iniciar uma iteração, os retornos de chamada de iterações anteriores estão sendo processados, conforme mostrado nos logs. Em JavaScript, os retornos de chamada assíncronos são tratados com um [loop de eventos](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop). Outros runtimes usam mecanismos diferentes para lidar com a simultaneidade. Quando o ambiente de execução da função termina, o Lambda o ambiente até a próxima invocação. Depois de retomado, o JavaScript continua processando o loop de eventos, que, nesse caso, inclui um retorno de chamada assíncrono de uma invocação anterior. Sem esse contexto, pode parecer que a função está executando código sem motivo e retornando dados arbitrários. Na verdade, trata-se de um artefato de como a simultaneidade do runtime e os ambientes de execução interagem. Isso cria a possibilidade de que dados privados de uma invocação anterior apareçam em uma invocação subsequente. Há duas maneiras de evitar ou detectar esse comportamento. Primeiro, o JavaScript fornece as [palavras-chave async e await](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) para simplificar o desenvolvimento assíncrono e para forçar a execução do código a aguardar a conclusão de uma chamada assíncrona. A função acima pode ser reescrita usando essa abordagem da seguinte maneira: ``` let seqId = 0 exports.handler = async (event) => { console.log(`Starting: sequence Id=${++seqId}`) const result = await doWork(seqId) console.log(`Work done: sequence Id=${result}`) } function doWork(id) { return new Promise(resolve => { setTimeout(() => resolve(id), 4000) }) } ``` O uso dessa sintaxe impede que o manipulador seja encerrado antes que a função assíncrona seja concluída. Nesse caso, se o retorno de chamada demorar mais do que o tempo limite da função do Lambda, a função vai gerar um erro, em vez de retornar o resultado do retorno de chamada em uma invocação posterior: ![\[operações de depuração figura 8\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-8.png) 1. O código chama a função assíncrona `doWork` usando a palavra-chave await no manipulador. 1. A função `doWork` leva algum tempo para ser concluída antes de resolver a promessa. 1. A função atinge o tempo limite porque `doWork` demora mais do que o limite tempo permitido, e o resultado do retorno de chamada não é retornado em uma invocação posterior. Geralmente, você deve garantir que todos os processos em segundo plano ou retornos de chamadas no código sejam concluídos antes que o código seja encerrado. Se isso não for possível em seu caso de uso, você pode usar um identificador para garantir que o retorno de chamada pertença à invocação atual. Para fazer isso, você pode usar *awsRequestId* fornecido pelo objeto de contexto. Ao passar esse valor para o retorno de chamada assíncrono, você pode comparar o valor passado com o valor atual para detectar se o retorno de chamada foi originado de outra invocação: ``` let currentContext exports.handler = async (event, context) => { console.log(`Starting: request id=$\{context.awsRequestId}`) currentContext = context doWork(context.awsRequestId, function(id) { if (id != currentContext.awsRequestId) { console.info(`This callback is from another invocation.`) } }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` ![\[operações de depuração figura 9\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-9.png) 1. O manipulador da função do Lambda usa o parâmetro context, que fornece acesso a um ID de solicitação de invocação exclusivo. 1. O `awsRequestId` é passado para a função doWork. No retorno de chamada, o ID é comparado com o `awsRequestId` da invocação atual. Se esses valores forem diferentes, o código executará a ação apropriada. # Solucionar problemas de implantação no Lambda Quando você atualiza a função, o Lambda implanta a alteração executando novas instâncias da função com o código ou as configurações atualizados. Erros de implantação impedem que a nova versão seja usada e podem surgir de problemas com o pacote de implantação, o código, as permissões ou as ferramentas. Ao implantar atualizações na função diretamente com a API do Lambda ou com um cliente, como a AWS CLI, é possível visualizar os erros do Lambda diretamente na saída. Se você usar serviços como o AWS CloudFormation, o AWS CodeDeploy ou o AWS CodePipeline, procure a resposta do Lambda nos logs ou no fluxo de eventos desses serviços. Os tópicos a seguir fornecem orientações para a solução de erros e problemas que você pode encontrar ao usar a API, o console ou as ferramentas do Lambda. Se encontrar um problema que não esteja listado aqui, você poderá usar o botão **Feedback** desta página para relatá-lo. Para obter mais orientações sobre solução de problemas e respostas a perguntas comuns de suporte, acesse a [Central de Conhecimento da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda). Para obter mais informações sobre depuração e solução de problemas de aplicações do Lambda, consulte [Debugging](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops) no Serverless Land. **Topics** + [Geral: A permissão foi negada/Não é possível carregar esse arquivo](#troubleshooting-deployment-denied) + [Geral: Ocorre um erro ao acionar o updateFunctionCode](#troubleshooting-deployment-updatefunctioncode) + [Amazon S3: Código de erro PermanentRedirect.](#troubleshooting-deployment-PermanentRedirect) + [Geral: Não é possível localizar, não é possível carregar, não é possível importar, classe não encontrada, o arquivo ou diretório não existe](#troubleshooting-deployment-functionHandler1) + [Geral: Handler de método indefinido](#troubleshooting-deployment-functionHandler2) + [Geral: limite de armazenamento de código do Lambda excedido](#troubleshooting-deployment-CodeStorageExceeded) + [Lambda: falha na conversão de camadas](#troubleshooting-deployment-LayerConversionFailed) + [Lambda: InvalidParameterValueException ou RequestEntityToolargeException](#troubleshooting-deployment-InvalidParameterValueException1) + [Lambda: InvalidParameterValueException](#troubleshooting-deployment-InvalidParameterValueException2) + [Lambda: simultaneidade e cotas de memória](#troubleshooting-deployment-quotas) + [Lambda: configuração de alias inválida para simultaneidade provisionada](#troubleshooting-deployment-provisioned-concurrency) ## Geral: A permissão foi negada/Não é possível carregar esse arquivo **Erro:** *EACCES: permissão negada, abra '/var/task/index.js'* **Erro:** *não é possível carregar esse arquivo -- função* **Erro:** *[Errno 13] Permissão negada: '/var/task/function.py'* O runtime do Lambda precisa de permissão para ler os arquivos no pacote de implantação. Na notação octal de permissões do Linux, o Lambda precisa de 644 permissões para arquivos não executáveis (rw-r--r--) e 755 permissões (rwxr-xr-x) para diretórios e arquivos executáveis. No Linux e no MacOS, use o comando `chmod` para alterar as permissões de arquivo em arquivos e diretórios do seu pacote de implantação. Por exemplo, para dar a um arquivo não executável as permissões corretas, execute o comando a seguir. ``` chmod 644 ``` Para alterar as permissões de arquivo no Windows, consulte [Set, View, Change, or Remove Permissions on an Object](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10)) na documentação do Microsoft Windows. **nota** Se você não conceder ao Lambda as permissões necessárias para acessar diretórios no seu pacote de implantação, o Lambda definirá as permissões desses diretórios como 755 (rwxr-xr-x). ## Geral: Ocorre um erro ao acionar o updateFunctionCode **Erro:** *ocorreu um erro (RequestEntityTooLargeException) ao chamar a operação UpdateFunctionCode* Quando você faz upload de um pacote de implantação ou de um arquivamento de camada diretamente no Lambda, o tamanho do arquivo ZIP é limitado a 50 MB. Para fazer upload de um arquivo maior, armazene-o no Amazon S3 e use os parâmetros S3Bucket e S3Key. **nota** Quando você faz upload de um arquivo diretamente com a AWS CLI, o AWS SDK ou de outra forma, o arquivo ZIP binário é convertido em base64, o que aumenta o tamanho dele em cerca de 30%. Para permitir isso e o tamanho de outros parâmetros na solicitação, o limite do tamanho real da solicitação que o Lambda aplica é maior. Por isso, o limite de 50 MB é aproximado. ## Amazon S3: Código de erro PermanentRedirect. **Erro:** *Ocorreu um erro ao GetObject. Código de erro S3: PermanentRedirect. Mensagem de erro do S3: O bucket está nesta Região: us-east-2. Use essa região para repetir a solicitação* Ao carregar o pacote de implantação de uma função de um bucket do Amazon S3, o bucket deve estar na mesma Região que a função. Esse problema pode ocorrer ao especificar um objeto do Amazon S3 em uma chamada para [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) ou usar o pacote e implantar comandos na AWS CLI ou na CLI do AWS SAM. Crie um bucket de artefato de implantação para cada Região em que você desenvolve aplicativos. ## Geral: Não é possível localizar, não é possível carregar, não é possível importar, classe não encontrada, o arquivo ou diretório não existe **Erro:** *não é possível localizar o módulo "function"* **Erro:** *não é possível carregar esse arquivo -- função* **Erro:** *não é possível importar o módulo "function"* **Erro:** *classe não encontrada: function.Handler* **Erro:** *fork/exec /var/task/function: nenhum arquivo ou diretório* **Erro:** *não é possível carregar o tipo "Function.Handler" do assembly "Function".* O nome do arquivo ou classe na configuração do handler da função não corresponde ao seu código. Para obter mais informações, consulte a seção a seguir. ## Geral: Handler de método indefinido **Erro:** *index.handler está indefinido ou não foi exportado* **Erro:** *Handler "handler" ausente no módulo "function"* **Erro:** *método indefinido "handler" para \$1* **Erro:** *nenhum método público chamado handleRequest com a assinatura de método apropriada encontrada na classe function.Handler* **Erro:** *não foi possível encontrar o método "handleRequest" no tipo "Function.Handler" do assembly "Function"* O nome do método do handler na configuração do handler da função não corresponde ao seu código. Cada runtime define uma convenção de nomenclatura para os handlers, como *filename*.*methodname*. O handler é o método no código da função que é executado pelo runtime quando a função é invocada. Para alguns idiomas, o Lambda fornece uma biblioteca com uma interface que espera que um método de handler tenha um nome específico. Para obter detalhes sobre a nomenclatura de handlers para cada idioma, consulte os tópicos a seguir. + [Criar funções do Lambda com Node.js](lambda-nodejs.md) + [Criar funções do Lambda com Python](lambda-python.md) + [Construir funções do Lambda com Ruby](lambda-ruby.md) + [Construir funções do Lambda com Java](lambda-java.md) + [Criar funções do Lambda com Go](lambda-golang.md) + [Construir funções do Lambda com C\$1](lambda-csharp.md) + [Construir funções do Lambda com o PowerShell](lambda-powershell.md) ## Geral: limite de armazenamento de código do Lambda excedido **Erro:** *limite de armazenamento de código excedido.* O Lambda armazena o código da função em um bucket interno do S3 privativo da sua conta. Cada conta da AWS recebe 75 GB de armazenamento em cada região. O armazenamento de códigos inclui o armazenamento total usado pelas camadas e as funções do Lambda. Se atingir a cota, você receberá uma *CodeStorageExceededException* ao tentar implantar novas funções. Gerencie o espaço de armazenamento disponível, limpando versões antigas de funções, removendo códigos não utilizados ou utilizando camadas do Lambda. Além disso, é uma boa prática [usar contas da AWS separadas para workloads distintas](concepts-application-design.md#multiple-accounts), a fim de ajudar a gerenciar as cotas de armazenamento. É possível ver o uso total do armazenamento no console do Lambda, no submenu **Painel**: ![\[monitoramento e observabilidade figura 26\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/monitoring-observability-figure-26.png) ## Lambda: falha na conversão de camadas **Erro:** *falha na conversão de camadas do Lambda. Para obter orientação sobre como resolver esse problema, consulte a página Solucionar problemas de implantação no Lambda no Guia do usuário do Lambda.* Quando você configura uma função do Lambda com uma camada, o Lambda mescla a camada com seu código de função. Se esse processo não for concluído, o Lambda retornará esse erro. Se você se deparar com esse erro, faça o seguinte: + Exclua todos os arquivos não utilizados da sua camada + Exclua todos os links simbólicos em sua camada + Renomeie todos os arquivos que tenham o mesmo nome de um diretório em qualquer uma das camadas da sua função ## Lambda: InvalidParameterValueException ou RequestEntityToolargeException **Erro:** *InvalidParameterValueException: o Lambda não conseguiu configurar as variáveis de ambiente porque as variáveis de ambiente fornecidas excederam o limite de 4 KB. Cadeia de caracteres medida: \$1"A1":"uSFeY5cyPiPn7AtnX5BsM...* **Erro:** *RequestEntityTooLargeException: a solicitação deve ser menor do que 5.120 bytes para a operação UpdateFunctionConfiguration* O tamanho máximo do objeto de variáveis que é armazenado na configuração da função não deve exceder 4096 bytes. Isso inclui nomes de chaves, valores, aspas, vírgulas e colchetes. O tamanho total do corpo da solicitação HTTP também é limitado. ``` { "FunctionName": "my-function", "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Runtime": "nodejs24.x", "Role": "arn:aws:iam::123456789012:role/lambda-role", "Environment": { "Variables": { "BUCKET": "amzn-s3-demo-bucket", "KEY": "file.txt" } }, ... } ``` Neste exemplo, o objeto tem 39 caracteres e ocupa 39 bytes quando é armazenado (sem espaços em branco) como a string `{"BUCKET":"amzn-s3-demo-bucket","KEY":"file.txt"}`. Caracteres ASCII padrão em valores de variáveis de ambiente usam um byte cada. Caracteres ASCII e Unicode estendidos podem usar entre 2 bytes e 4 bytes por caractere. ## Lambda: InvalidParameterValueException **Erro:** *InvalidParameterValueException: o Lambda não conseguiu configurar as variáveis de ambiente porque as variáveis de ambiente fornecidas contêm chaves reservadas que atualmente não têm suporte para modificação.* O Lambda reserva algumas chaves de variáveis de ambiente para uso interno. Por exemplo, `AWS_REGION` é usada pelo runtime para determinar a região atual e não pode ser substituída. Outras variáveis, como `PATH`, são usadas pelo runtime, mas podem ser estendidas na configuração de função. Para obter uma lista completa, consulte [Variáveis de ambiente com runtime definido](configuration-envvars.md#configuration-envvars-runtime). ## Lambda: simultaneidade e cotas de memória **Erro:*** ConcurrentExecutions especificado para a função diminui UnreservedConcurrentExecution da conta para um valor abaixo do mínimo* **Error:*** O valor de “MemorySize” não atende à restrição: o valor de Member (Membro) deve ser menor ou igual a 3008* Esses erros ocorrem ao exceder a simultaneidade ou as [cotas](gettingstarted-limits.md) de memória da conta. As novas contas da AWS reduziram as cotas de simultaneidade e de memória. Para resolver erros relacionados à simultaneidade, é possível [solicitar um aumento de cota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). Não é possível solicitar aumentos de cota de memória. + **Simultaneidade:** é possível receber um erro se tentar criar uma função usando simultaneidade reservada ou provisionada ou se sua solicitação de simultaneidade por função ([PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)) exceder a cota de simultaneidade da conta. + **Memória:** os erros ocorrerão se a quantidade de memória alocada para a função exceder a cota de memória da conta. ## Lambda: configuração de alias inválida para simultaneidade provisionada **Erro:*** configuração de alias inválida para simultaneidade provisionada* Esse erro ocorre quando você tenta atualizar o código ou a configuração de uma função do Lambda enquanto um alias com simultaneidade provisionada está apontando para uma versão com problemas. O Lambda pré-inicializa ambientes de execução para simultaneidade provisionada e, se esses ambientes não puderem ser inicializados adequadamente devido a erros de código, restrições de recursos ou pilha e alias afetados, a implantação falhará. Se você se deparar com esse problema, faça o seguinte: 1. **Reverta o alias:** atualize temporariamente o alias para apontar para a versão que estava funcionando anteriormente. ``` aws lambda update-alias \ --function-name \ --name \ --function-version ``` 1. **Corrija o código de inicialização do Lambda:** garanta que o código de inicialização executado fora do manipulador não tenha nenhuma exceção não detectada e inicialize os clientes e as conexões. 1. **Implante novamente a segurança:** implante o código corrigido e publique uma nova versão. Em seguida, atualize o alias para apontar para a versão corrigida. Opcionalmente, reative a [simultaneidade provisionada](provisioned-concurrency.md), se necessário. Se estiver usando AWS CloudFormation, atualize a definição da pilha `FunctionVersion:!GetAtt version.Version` para que o alias aponte para a versão de trabalho: ``` alias: Type: AWS::Lambda::Alias Properties: FunctionName: !Ref function FunctionVersion: !GetAtt version.Version Name: BLUE ProvisionedConcurrencyConfig: ProvisionedConcurrentExecutions: 1 ``` # Solucionar problemas de invocação no Lambda Quando você invoca uma função do Lambda, o Lambda valida a solicitação e verifica a capacidade de escalabilidade antes de enviar o evento para a função ou, na invocação assíncrona, para a fila de eventos. Erros de invocação podem ser causados por problemas com os parâmetros da solicitação, a estrutura do evento, as configurações da função, as permissões do usuário, as permissões de recursos ou os limites. Se você invocar a função diretamente, verá todos os erros de invocação na resposta do Lambda. Se invocar a função de forma assíncrona, com um mapeamento de origem de evento ou por meio de outro serviço, você poderá encontrar erros em logs, em uma fila de mensagens mortas ou em um destino de evento com falha. As opções de tratamento de erros e o comportamento de repetição variam dependendo de como você invoca a função e do tipo de erro. Para obter uma lista de tipos de erro que a operação `Invoke` pode retornar, consulte [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html). **Topics** + [Lambda: a função atinge o tempo limite durante a fase inicial (Sandbox.Timedout)](#troubleshooting-timeouts) + [IAM: lambda:InvokeFunction não autorizado](#troubleshooting-invocation-noauth) + [Lambda: não foi possível encontrar um bootstrap válido (Runtime.InvalidEntrypoint)](#troubleshooting-invocation-bootstrap) + [Lambda: A operação não pode ser executada ResourceConflictException](#troubleshooting-invocation-ResourceConflictException) + [Lambda: A função está paralisada em Pendente](#troubleshooting-invocation-pending) + [Lambda: Uma função está usando toda a simultaneidade](#troubleshooting-invocation-allconcurrency) + [Geral: Não é possível invocar a função com outras contas ou serviços](#troubleshooting-invocation-cannotinvoke) + [Geral: A invocação da função está em loop](#troubleshooting-invocation-loop) + [Lambda: Roteamento de alias com simultaneidade provisionada](#troubleshooting-invocation-alias) + [Lambda: As inicializações a frio começam com simultaneidade provisionada](#troubleshooting-invocation-coldstart) + [Lambda: As inicializações a frio começam com novas versões](#troubleshooting-invocation-newversion) + [Lambda: saída inesperada do Node.js em runtime (Runtime.NodejsExit)](#troubleshooting-invocation-nodejs-exit) + [EFS: A função não pôde montar o sistema de arquivos do EFS](#troubleshooting-invocation-efsmount) + [EFS: A função não pôde se conectar ao sistema de arquivos do EFS](#troubleshooting-invocation-efsconnect) + [EFS: A função não pôde montar o sistema de arquivos do EFS devido ao tempo limite](#troubleshooting-invocation-efstimeout) + [Lambda: O Lambda detectou um processo de E/S que estava demorando muito](#troubleshooting-invocation-ioprocess) + [Contêiner: erros CodeArtifactUserException](#troubleshooting-deployment-container-artifact) + [Contêiner: erros InvalidEntrypoint](#troubleshooting-deployment-container-entrypoint) ## Lambda: a função atinge o tempo limite durante a fase inicial (Sandbox.Timedout) **Erro:** *Task timed out after 3,00 seconds* Quando a fase de [inicialização](lambda-runtime-environment.md#runtimes-lifecycle-ib) atingir o tempo limite, o Lambda inicializará o ambiente de execução novamente ao executar a fase de `Init`quando a próxima solicitação de invocação chegar. Isso se chama [inicialização suprimida](lambda-runtime-environment.md#suppressed-init). No entanto, se a função estiver configurada com uma [duração de tempo limite](configuration-timeout.md) curta (geralmente em torno de três segundos), a inicialização suprimida poderá não ser concluída durante o tempo limite alocado, fazendo com que a fase de `Init` atinja o tempo limite novamente. Como alternativa, a inicialização suprimida é concluída, mas não há tempo suficiente para que a fase de [invocação](lambda-runtime-environment.md#runtimes-lifecycle-invoke) seja concluída, fazendo com que a fase de `Invoke` atinja o tempo limite. Para reduzir os erros de tempo limite, use uma ou mais das seguintes estratégias: + **Aumentar a duração do tempo limite da função**: estenda o [tempo limite](configuration-timeout.md) para que as fases de `Init` e `Invoke` sejam concluídas com êxito. + **Aumentar a alocação de memória da função**: mais [memória](configuration-memory.md) também significa mais alocação proporcional da CPU, o que pode acelerar as fases de `Init` e `Invoke`. + **Otimizar o código de inicialização da função**: reduza o tempo necessário para a inicialização para garantir que as fases de `Init` e `Invoke` possam ser concluídas dentro do tempo limite configurado. ## IAM: lambda:InvokeFunction não autorizado **Erro:** *usuário: arn:aws:iam::123456789012:user/developer não tem autorização para executar: lambda:InvokeFunction no recurso: my-function* Seu usuário, ou o perfil que você assume, deve ter permissões para invocar uma função. Esse requisito também se aplica a funções do Lambda e a outros recursos de computação que invocam funções. Adicione a política gerenciada pela AWS **AWSLambdaRole** ao seu usuário ou adicione uma política personalizada que permita a ação `lambda:InvokeFunction` na função de destino. **nota** O nome da ação do IAM (`lambda:InvokeFunction`) refere-se à operação da API `Invoke` do Lambda. Para ter mais informações, consulte [Gerenciando permissões no AWS Lambda](lambda-permissions.md) . ## Lambda: não foi possível encontrar um bootstrap válido (Runtime.InvalidEntrypoint) **Erro:** *não foi possível encontrar bootstrap(s) válido(s): [/var/task/bootstrap /opt/bootstrap]* Esse erro normalmente ocorre quando a raiz do pacote de implantação não contém um arquivo executável denominado `bootstrap`. Por exemplo, se você estiver implantando uma função `provided.al2023` com um arquivo .zip, o arquivo `bootstrap` deverá estar na raiz do arquivo .zip e não em um diretório. ## Lambda: A operação não pode ser executada ResourceConflictException **Erro:** *ResourceConflictException: não é possível executar a operação neste momento. A função está atualmente no seguinte estado: Pendente* Quando você conecta uma função a uma virtual private cloud (VPC) no momento da criação, a função entra em estado `Pending` enquanto o Lambda cria interfaces de rede elástica. Durante esse período, não será possível invocar ou modificar sua função. Se conectar sua função a uma VPC após a criação, você poderá invocá-la enquanto a atualização estiver pendente, mas não poderá modificar seu código ou configuração. Para ter mais informações, consulte [Estados da função do Lambda](functions-states.md) . ## Lambda: A função está paralisada em Pendente **Erro:** *uma função está presa no estado `Pending` há vários minutos.* Se uma função ficar paralisada no estado `Pending` por mais de seis minutos, chame uma das operações da API a seguir para desbloqueá-la: + [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) + [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) + [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) O Lambda cancela a operação pendente e coloca a função no estado `Failed`. Em seguida, você pode tentar outra atualização. ## Lambda: Uma função está usando toda a simultaneidade **Problema:** *uma função está usando toda a simultaneidade disponível, fazendo com que outras funções fiquem limitadas.* Para dividir a simultaneidade disponível da sua conta da AWS em uma região da AWS em grupos, use a [simultaneidade reservada](configuration-concurrency.md). A simultaneidade reservada garante que uma função sempre possa escalar para a sua simultaneidade atribuída, e que ela não escale além da simultaneidade atribuída. ## Geral: Não é possível invocar a função com outras contas ou serviços **Problema:** *você consegue invocar sua função diretamente, mas ela não é executada quando outro serviço ou conta a invoca.* Você concede a [outros serviços](lambda-services.md) e contas permissão para invocar uma função na [política baseada em recursos](access-control-resource-based.md)da função. Se o invocador estiver em outra conta, esse usuário também precisará da permissão [ para invocar funções](access-control-identity-based.md). ## Geral: A invocação da função está em loop **Problema:** *a função é invocada continuamente em um loop.* Isso geralmente ocorre quando a sua função gerencia recursos no mesmo serviço da AWS que o aciona. Por exemplo, é possível criar uma função que armazena um objeto em um bucket do Amazon Simple Storage Service (Amazon S3) que é configurado com uma [notificação que invoca a função novamente](with-s3.md). Para interromper a execução da função, reduza a [simultaneidade](lambda-concurrency.md) disponível para zero, o que controla a utilização de todas as invocações futuras. Em seguida, identifique o caminho de código ou erro de configuração que gerou a invocação recursiva. O Lambda detecta e interrompe automaticamente loops recursivos para alguns serviços e SDKs da AWS. Para obter mais informações, consulte [Usar a detecção de loop recursivo do Lambda para evitar loops infinitos](invocation-recursion.md). ## Lambda: Roteamento de alias com simultaneidade provisionada **Problema:** *Chamadas de spillover de simultaneidade provisionadas durante o roteamento de alias.* O Lambda usa um modelo probabilístico simples para distribuir o tráfego entre as duas versões de função. Em níveis de tráfego baixos, você pode ver uma alta variação entre a porcentagem configurada e real de tráfego em cada versão. Se sua função usa simultaneidade provisionada, você pode evitar[Invocações de transbordamento](monitoring-metrics-types.md#invocation-metrics)configurando um número maior de instâncias de simultaneidade provisionadas durante o tempo em que o roteamento de alias está ativo. ## Lambda: As inicializações a frio começam com simultaneidade provisionada **Problema:** *Você vê inicializações a frio depois de habilitar a simultaneidade provisionada.* Quando o número de execuções simultâneas em uma função é menor ou igual ao [nível configurado de simultaneidade provisionada](provisioned-concurrency.md), não deve haver nenhuma inicialização a frio. Para ajudar a confirmar se a simultaneidade provisionada está operando normalmente, faça o seguinte: + [Verifique se a simultaneidade provisionada está habilitada](provisioned-concurrency.md) na versão ou alias da função. **nota** A simultaneidade provisionada não é configurável na [versão da função](configuration-versions.md) não publicada (\$1LATEST). + Certifique-se de que seus gatilhos invoquem a versão ou alias correto da função. Por exemplo, se você estiver usando o Amazon API Gateway, verifique se ele invoca a versão ou o alias da função com simultaneidade provisionada, e não a \$1LATEST. Para confirmar se a simultaneidade provisionada está em uso, você pode verificar a [métrica ProvisionedConcurrencyInvocations do Amazon CloudWatch](monitoring-concurrency.md#provisioned-concurrency-metrics). Um valor diferente de zero indica que a função está processando invocações em ambientes de execução inicializados. + Determine se a simultaneidade da função excede o nível configurado de simultaneidade provisionada verificando a [métrica ProvisionedConcurrencySpilloverInvocations do CloudWatch](monitoring-concurrency.md#provisioned-concurrency-metrics). Um valor diferente de zero indica que toda a simultaneidade provisionada está em uso e que ocorreu alguma invocação com inicialização a frio. + Verifique a sua [frequência de invocação](gettingstarted-limits.md#api-requests) (solicitações por segundo). Funções com simultaneidade provisionada apresentam uma taxa máxima de dez solicitações por segundo por simultaneidade provisionada. Por exemplo, uma função configurada com 100 casos de simultaneidade provisionada pode lidar com 1.000 solicitações por segundo. Se a taxa de invocação exceder 1.000 solicitações por segundo, podem ocorrer algumas inicializações a frio. ## Lambda: As inicializações a frio começam com novas versões **Problema:** *Você vê inicializações a frio ao implantar novas versões da sua função.* Quando você atualiza um alias da função, o Lambda automaticamente muda a simultaneidade provisionada para a nova versão com base nos pesos configurados no alias. **Erro:** *KMSDisabledException: o Lambda não conseguiu descriptografar as variáveis de ambiente porque a chave do KMS usada está desabilitada. Verifique as configurações da chave do KMS da função.* Esse erro pode ocorrer se a sua chave do AWS Key Management Service (AWS KMS) estiver desabilitada ou se a concessão que permite que o Lambda use a chave for revogada. Se a concessão estiver ausente, configure a função para usar outra chave. Em seguida, reatribua a chave personalizada para recriar a concessão. ## Lambda: saída inesperada do Node.js em runtime (Runtime.NodejsExit) **Problema:** *o cliente de runtime do Lambda detectou um código de saída Node.js inesperado.* Esse erro ocorre quando sua função é encerrada antes que todas as promessas sejam liquidadas, por exemplo, devido a um bug de código. Também pode ocorrer quando o Node.js detecta um impasse que impede que as promessas sejam resolvidas. Esse erro afeta somente manipuladores de estilo assíncrono, e não manipuladores de estilo de retorno de chamada. **Runtimes afetados:** Node.js 18 e posteriores. **Para resolver esse problema:** 1. Verifique seu código de função para ver se há promessas não resolvidas em manipuladores assíncronos. 1. Certifique-se de que todas as promessas sejam devidamente liquidadas (resolvidas ou rejeitadas) antes que a função seja concluída. 1. Revise seu código para possíveis condições de corrida em operações assíncronas. Para obter mais informações sobre os códigos de saída do Node.js e o encerramento de processos, consulte a [documentação do Node.js](https://nodejs.org/docs/latest/api/process.html#exit-codes). ## EFS: A função não pôde montar o sistema de arquivos do EFS **Erro:** *EFSMountFailureException: a função não pôde montar o sistema de arquivos do EFS com o ponto de acesso arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd.* A solicitação de montagem para o [sistema de arquivos](configuration-filesystem.md) da função foi rejeitada. Verifique as permissões da função e confirme se o sistema de arquivos e o ponto de acesso existem e estão prontos para uso. ## EFS: A função não pôde se conectar ao sistema de arquivos do EFS **Erro:** *EFSMountConnectivityException: a função não pôde se conectar ao sistema de arquivos do Amazon EFS com o ponto de acesso arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd. Verifique a configuração de rede e tente novamente.* A função não pôde estabelecer uma conexão com o [sistema de arquivos](configuration-filesystem.md) da função com o protocolo NFS (TCP porta 2049). Verifique a [configuração do grupo de segurança e de roteamento](https://docs.aws.amazon.com/efs/latest/ug/network-access.html) das sub-redes da VPC. Se você receber esses erros após atualizar as configurações de VPC da função, tente desmontar e remontar o sistema de arquivos. ## EFS: A função não pôde montar o sistema de arquivos do EFS devido ao tempo limite **Erro:** *EFSMountTimeoutException: A função não pôde montar o sistema de arquivos do EFS com o ponto de acesso \$1arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd\$1 devido ao tempo limite da montagem.* A função pôde se conectar ao [sistema de arquivos](configuration-filesystem.md) da função, mas a operação de montagem atingiu o tempo limite. Tente novamente após um breve intervalo e considere limitar a [simultaneidade](configuration-concurrency.md) da função para reduzir a carga no sistema de arquivos. ## Lambda: O Lambda detectou um processo de E/S que estava demorando muito *EFSIOException: esta instância de função foi interrompida porque o Lambda detectou um processo de E/S que estava demorando muito.* Uma invocação anterior atingiu o tempo limite e o Lambda não conseguiu finalizar o handler de funções. Esse problema pode ocorrer quando um sistema de arquivos anexado fica sem crédito de intermitência e a throughput de linha de base é insuficiente. Para aumentar o throughput, você pode aumentar o tamanho do sistema de arquivos ou usar o throughput provisionado. ## Contêiner: erros CodeArtifactUserException **Erro:** *mensagem de erro CodeArtifactUserPendingException* O CodeArtifact está pendente de otimização. A função passa para o [estado ativo](functions-states.md) quando o Lambda conclui a otimização. Código da resposta HTTP 409. **Erro:** *mensagem de erro CodeArtifactUserDeletedException* O CodeArtifact está programado para ser excluído. Código da resposta HTTP 409. **Erro:** *Mensagem de erro CodeArtifactUserFailedException* O Lambda falhou em otimizar o código. Você precisa corrigir o código e carregá-lo novamente. Código da resposta HTTP 409. ## Contêiner: erros InvalidEntrypoint **Erro:***Runtime.ExitError ou "errorType": "Runtime.InvalidEntrypoint"* Verifique se o ENTRYPOINT para sua imagem de contêiner inclui o caminho absoluto como o local. Verifique também se a imagem não contém um link simbólico (symlink) como ENTRYPOINT. **Erro:** *You are using an CloudFormation template, and your container ENTRYPOINT is being overridden with a null or empty value. (Você está usando um modelo do CloudFormation e o ENTRYPOINT do contêiner está sendo substituído por um valor nulo ou vazio.)* Revise o recurso [ImageConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-lambda-function-imageconfig.html) no modelo do CloudFormation. Se você declarar um recurso `ImageConfig` em seu modelo, deverá fornecer valores não vazios para todas as três propriedades. # Solucionar problemas de execução no Lambda Quando o runtime do Lambda executa o código de função, o evento pode ser processado em uma instância da função que esteja processando eventos por algum tempo, ou pode exigir que uma nova instância seja inicializada. Podem ocorrer erros durante a inicialização da função, quando o código do manipulador processa o evento, ou quando a função retorna (ou falha ao retornar) uma resposta. Erros de execução de função podem ser causados por problemas com o código, a configuração de função, recursos de downstream ou permissões. Se invocar sua função diretamente, você verá erros de função na resposta do Lambda. Se invocar a função de forma assíncrona, com um mapeamento de origem de evento ou por meio de outro serviço, você poderá encontrar erros em logs, em uma fila de mensagens mortas ou em um destino em caso de falha. As opções de tratamento de erros e o comportamento de repetição variam dependendo de como você invoca a função e do tipo de erro. Quando o código de função ou o runtime do Lambda retornar um erro, o código de status na resposta do Lambda será 200 OK. A presença de um erro na resposta é indicada por um cabeçalho chamado`X-Amz-Function-Error`Os códigos de status das séries 400 e 500 são reservados para[Erros de invocação](troubleshooting-invocation.md). **Topics** + [Depure depuração remota com o Visual Studio Code](#troubleshooting-execution-remote-debugging) + [Lambda: A execução leva muito tempo](#troubleshooting-execution-toolong) + [Lambda: Carga útil inesperada do evento](#troubleshooting-execution-unexpected-payload) + [Lambda: Tamanhos de carga útil inesperadamente grandes](#troubleshooting-execution-large-payload) + [Lambda: erros de codificação e decodificação JSON](#troubleshooting-execution-json-encoding) + [Lambda: Os logs ou rastreamentos não aparecem](#troubleshooting-execution-logstraces) + [Lambda: nem todos os logs da função aparecem](#troubleshooting-execution-missinglogs) + [Lambda: A função retorna antes da conclusão da execução](#troubleshooting-execution-unfinished) + [Lambda: execução de um alias ou versão da função não intencional](#unintended-function) + [Lambda: Detecção de loops infinitos](#infinite-loops) + [Geral: indisponibilidade do serviço de downstream](#downstream-unavailability) + [AWS SDK: versões e atualizações](#troubleshooting-execution-versions) + [Python: As bibliotecas carregam incorretamente](#troubleshooting-execution-libraries) + [Java: Sua função demora mais para processar eventos após a atualização do Java 11 para o Java 17](#troubleshooting-execution-java-perf) + [Kafka: problemas de tratamento de erros e novas tentativas de configuração](#troubleshooting-kafka-error-handling) ## Depure depuração remota com o Visual Studio Code **Problema:** *dificuldade em solucionar o comportamento complexo da função do Lambda no ambiente real da AWS* O Lambda fornece um atributo de depuração remota por meio do AWS Toolkit for Visual Studio Code. Para configuração e instruções gerais, consulte [Depure remotamente as funções do Lambda com o Visual Studio Code](debugging.md). Para obter instruções detalhadas sobre solução de problemas, casos de uso avançados e disponibilidade regional, consulte [Depuração remota de funções do Lambda](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html) no Guia do usuário do AWS Toolkit for Visual Studio Code. ## Lambda: A execução leva muito tempo **Problema:** *a execução da função leva muito tempo.* Se o código demorar muito mais tempo para ser executado no Lambda do que na sua máquina local, ele poderá ser restrito pela memória ou pela potência de processamento disponível para a função. [Configure a função com memória adicional](configuration-memory.md) para aumentar a memória e a CPU. ## Lambda: Carga útil inesperada do evento **Problema:** *erros de função relacionados a um JSON malformado ou validação de dados imprópria.* Todas as funções do Lambda recebem uma carga útil de evento no primeiro parâmetro do manipulador. A carga útil do evento é uma estrutura JSON que pode conter matrizes e elementos aninhados. O JSON malformado pode ocorrer quando fornecido por serviços upstream que não usam um processo robusto para verificar estruturas JSON. Isso ocorre quando os serviços concatenam strings de texto ou incorporam entradas de usuários que não foram limpas. O JSON também é frequentemente serializado para transmissão entre serviços. Sempre analise estruturas JSON como produtora e consumidora de JSON para garantir que a estrutura seja válida. Da mesma forma, deixar de verificar os intervalos de valores na carga útil do evento pode resultar em erros. Este exemplo mostra uma função que calcula uma retenção de impostos: ``` exports.handler = async (event) => { let pct = event.taxPct let salary = event.salary // Calculate % of paycheck for taxes return (salary * pct) } ``` Essa função usa um salário e uma alíquota de imposto da carga útil do evento para realizar o cálculo. No entanto, o código não consegue verificar se os atributos estão presentes. Ele também não consegue verificar os tipos de dados nem garantir limites, como assegurar que a porcentagem do imposto esteja entre 0 e 1. Como resultado, valores fora desses limites produzem resultados sem sentido. Um tipo incorreto ou um atributo ausente causa um erro de runtime. Crie testes para garantir que sua função consegue lidar com tamanhos maiores de carga útil. O tamanho máximo da carga útil de um evento do Lambda é 1 MB. Dependendo do conteúdo, cargas úteis maiores podem significar mais itens passados para a função ou mais dados binários incorporados em um atributo JSON. Em ambos os casos, isso pode resultar em mais processamento para uma função do Lambda. Cargas úteis maiores também podem causar tempos limite. Por exemplo, uma função do Lambda processa um registro a cada 100 ms e tem um tempo limite de 3 segundos. O processamento é bem-sucedido para 0 a 29 itens na carga útil. No entanto, quando a carga útil contém mais de 30 itens, a função atinge o tempo limite e gera um erro. Para evitar isso, certifique-se de que os tempos limite sejam definidos para lidar com o tempo de processamento adicional para o número máximo de itens esperado. ## Lambda: Tamanhos de carga útil inesperadamente grandes **Problema:** *funções estão atingindo o tempo limite ou causando erros devido a cargas úteis grandes.* Cargas maiores podem causar tempos limite e erros. Recomendamos criar testes para garantir que sua função lide com as maiores cargas úteis esperadas e que o tempo limite da função seja definido corretamente. Além disso, determinadas cargas úteis de eventos podem conter ponteiros para outros recursos. Por exemplo, uma função do Lambda com 128 MB de memória pode executar o processamento de imagens em um arquivo JPG armazenado como um objeto no S3. A função funciona conforme o esperado com arquivos de imagem menores. No entanto, quando um arquivo JPG maior é fornecido como entrada, a função do Lambda gera um erro devido à falta de memória. Para evitar isso, os casos de teste devem incluir exemplos dos limites superiores dos tamanhos de dados esperados. O código também deve validar os tamanhos das cargas úteis. ## Lambda: erros de codificação e decodificação JSON **Problema:** *exceção NoSuchKey ao analisar entradas JSON.* Verifique se você está processando os atributos JSON corretamente. Por exemplo, para eventos gerados pelo S3, o atributo `s3.object.key` contém um nome de chave de objeto codificado em URL. Muitas funções processam esse atributo como texto para carregar o objeto do S3 referenciado: **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: event.Records[0].s3.object.key }).promise() ``` Esse código funciona com o nome da chave`james.jpg`, mas gera um erro `NoSuchKey` quando o nome é `james beswick.jpg`. Como a codificação de URL converte espaços e outros caracteres em um nome de chave, você deve garantir que as funções decodifiquem as chaves antes de usar esses dados: **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " ")) }).promise() ``` ## Lambda: Os logs ou rastreamentos não aparecem **Problema:** *Os logs não aparecem no CloudWatch Logs.* **Problema:** *os rastreamentos não aparecem no AWS X-Ray.* Sua função precisa de permissão para chamar o CloudWatch Logs e o X-Ray. Atualize a [função de execução](lambda-intro-execution-role.md) para conceder permissão a ela. Adicione as políticas gerenciadas a seguir para habilitar logs e rastreamento. + **AWSLambdaBasicExecutionRole** + **AWSXRayDaemonWriteAccess** Ao adicionar permissões à sua função, faça também uma atualização simples em seu código ou configuração. Isso força as instâncias em execução da função, com credenciais desatualizadas, a serem encerradas e substituídas. **nota** Pode levar de 5 a 10 minutos para que os logs apareçam após uma invocação de função. ## Lambda: nem todos os logs da função aparecem **Problema:** *os logs de funções estão ausentes no CloudWatch Logs, mesmo que minhas permissões estejam corretas* Se sua Conta da AWS atingir os [limites de cota do CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html), o CloudWatch controlará a utilização do registro em log de funções. Quando isso acontece, alguns dos logs gerados pelas funções podem não aparecer no CloudWatch Logs. Se a função gerar logs em uma taxa muito alta para o Lambda processá-los, isso também pode fazer com que os logs não apareçam no CloudWatch Logs. Quando o Lambda não consegue enviar logs para o CloudWatch na velocidade em que a função os produz, ele descarta logs para impedir que a execução da função fique mais lenta. Espere observar consistentemente logs descartados quando o throughput de log exceder 2 MB/s para um único fluxo de logs. Se sua função estiver configurada para usar [logs no formato JSON](monitoring-cloudwatchlogs-logformat.md), o Lambda tentará enviar um evento [`logsDropped`](telemetry-schema-reference.md#platform-logsDropped) para o CloudWatch Logs ao descartar os logs. No entanto, quando o CloudWatch controla a utilização do registro de log da sua função, esse evento pode não chegar ao CloudWatch Logs; por isso, você nem sempre verá um registro quando o Lambda descartar os logs. Para verificar se sua Conta da AWS atingiu os limites de cota do CloudWatch Logs, faça o seguinte: 1. Abra o [console do Service Quotas](https://console.aws.amazon.com/servicequotas). 1. No painel de navegação, escolha **Serviços da AWS**. 1. Na lista **Serviços da AWS**, procure Amazon CloudWatch Logs. 1. Na lista **Service Quotas**, escolha as cotas `CreateLogGroup throttle limit in transactions per second`, `CreateLogStream throttle limit in transactions per second` e `PutLogEvents throttle limit in transactions per second` para visualizar sua utilização. Também é possível definir alarmes do CloudWatch para receber um alerta quando a utilização da sua conta exceder o limite especificado para essas cotas. Consulte [Criar um alarme do CloudWatch com base em um limite estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) para saber mais. Se os limites de cota padrão do CloudWatch Logs não forem suficientes para seu caso de uso, você poderá [solicitar um aumento de cota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). ## Lambda: A função retorna antes da conclusão da execução **Problema: (Node.js)** *a função retorna antes que o código termine de ser executado* Muitas bibliotecas, incluindo o AWS SDK, operam de forma assíncrona. Ao fazer uma chamada de rede ou executar outra operação que exija aguardar uma resposta, as bibliotecas retornam um objeto chamado de promessa que rastreia o progresso da operação em segundo plano. Para aguardar que a promessa seja resolvida em uma resposta, use a palavra-chave `await`. Isso impedirá que o código do handler seja executado até que a promessa seja resolvida em um objeto que contenha a resposta. Se não precisar usar os dados da resposta em seu código, você poderá retornar a promessa diretamente ao runtime. Algumas bibliotecas não retornam promessas, mas podem ser encapsuladas em um código que retorne. Para obter mais informações, consulte [Definir o manipulador de função do Lambda em Node.js](nodejs-handler.md). ## Lambda: execução de um alias ou versão da função não intencional **Problema:** *versão ou alias de função não invocado* Quando você publica novas funções do Lambda no console ou usa o AWS SAM, a versão mais recente do código é representada pelo alias `$LATEST`. Por padrão, invocações que não especificam uma versão ou alias são direcionadas automaticamente para a versão `$LATEST` do código de função. Se você utiliza versões ou aliases de funções específicas, essas são versões publicadas imutáveis de uma função, além de `$LATEST`. Ao solucionar essas funções, primeiro determine se o chamador invocou a versão ou o alias pretendido. É possível fazer isso verificando seus logs de funções. A versão da função que foi invocada sempre é exibida na linha de log START: ![\[operações de depuração figura 1\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-1.png) ## Lambda: Detecção de loops infinitos **Problema:** *padrões de loop infinitos relacionados a funções do Lambda* Existem dois tipos de loops infinitos nas funções do Lambda. O primeiro está dentro da função, causado por um loop que nunca termina. A invocação é finalizada somente quando o tempo limite da função se esgota. É possível identificá-los monitorando os tempos limite e depois corrigindo o comportamento de loop. O segundo tipo de loop está entre as funções do Lambda e outros recursos da AWS. Eles ocorrem quando um evento de um recurso, como um bucket do S3, invoca uma função do Lambda, que então interage com o mesmo recurso de origem para acionar outro evento. Isso invoca a função novamente, o que cria outra interação com o mesmo bucket do S3 e assim por diante. Esses tipos de loops podem ser causados por várias origens diferentes de eventos da AWS, incluindo filas do Amazon SQS e tabelas do DynamoDB. É possível usar a [detecção de loops recursivos](invocation-recursion.md) para identificar esses padrões. ![\[operações de depuração figura 2\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-2.png) É possível evitar esses loops garantindo que as funções do Lambda gravem em recursos que não sejam iguais ao recurso de consumo. Se precisar publicar dados de volta no recurso consumidor, certifique-se de que os novos dados não acionem o mesmo evento. Outra opção é usar a [filtragem de eventos](invocation-eventfiltering.md). Por exemplo, estas são duas soluções propostas para loops infinitos com recursos do S3 e DynamoDB: + Se você escrever de volta no mesmo bucket do S3, use um prefixo ou sufixo diferente do acionador do evento. + Se você gravar itens na mesma tabela do DynamoDB, inclua um atributo que uma função do Lambda consumidora possa filtrar. Se o Lambda encontrar o atributo, este não resultará em outra invocação. ## Geral: indisponibilidade do serviço de downstream **Problema:** *os serviços downstream dos quais a sua função do Lambda depende estão indisponíveis* Para as funções do Lambda que chamam endpoints de terceiros ou outros recursos subsequentes, garanta que elas possam lidar com erros e tempos limite de serviço. Esses recursos downstream podem ter tempos de resposta variáveis ou podem ficar indisponíveis devido a interrupções no serviço. Dependendo da implementação, esses erros de downstream podem aparecer como exceções ou tempos limite do Lambda, se a resposta de erro do serviço não for tratada no código da função. Sempre que uma função depender de um serviço downstream, como uma chamada de API, implemente a lógica apropriada de tratamento de erros e nova tentativa. Para serviços essenciais, a função do Lambda deve publicar métricas ou logs no CloudWatch. Por exemplo, se uma API de pagamento de terceiros ficar indisponível, uma função do Lambda poderá registrar essas informações em log. Em seguida, é possível configurar os alarmes do CloudWatch para enviar notificações relacionadas a esses erros. Como o Lambda pode ser dimensionado rapidamente, os serviços de downstream sem servidor podem ter dificuldades para lidar com picos de tráfego. Há três abordagens comuns para lidar com isso: + **Cache**: considere armazenar em cache o resultado dos valores retornados por serviços de terceiros caso eles não mudem com frequência. É possível armazenar esses valores em variáveis globais na sua função ou em outro serviço. Por exemplo, os resultados de uma consulta de lista de produtos de uma instância do Amazon RDS podem ser salvos por um período na função para evitar consultas redundantes. + **Enfileiramento**: ao salvar ou atualizar dados, adicione uma fila do Amazon SQS entre a função do Lambda e o recurso. A fila persiste os dados de forma durável enquanto o serviço downstream processa as mensagens. + **Proxies**: onde normalmente são usadas conexões de longa duração, como para instâncias do Amazon RDS, use uma camada de proxy para agrupar e reutilizar essas conexões. Para bancos de dados relacionais, o [Amazon RDS Proxy](https://github.com/aws-samples/s3-to-lambda-patterns/tree/master/docrepository) é um serviço projetado para ajudar a melhorar a escalabilidade e a resiliência em aplicações com base no Lambda. ## AWS SDK: versões e atualizações **Problema:** *o AWS SDK incluído no runtime não é da versão mais recente* **Problema:** *o AWS SDK incluído no runtime é atualizado automaticamente* Os runtimes para linguagens interpretadas incluem uma versão do AWS SDK. O Lambda atualiza periodicamente esses runtimes para usar a versão mais recente do SDK. Para encontrar a versão do SDK que está incluída no seu runtime, consulte as seguintes seções: + [Versões do SDK incluídas no runtime (Node.js)](lambda-nodejs.md#nodejs-sdk-included) + [Versões do SDK incluídas no runtime (Python)](lambda-python.md#python-sdk-included) + [Versões do SDK incluídas no runtime (Ruby)](lambda-ruby.md#ruby-sdk-included) Para usar uma versão mais recente do AWS SDK ou para bloquear suas funções em uma versão específica, agrupe a biblioteca com seu código de função ou [crie uma camada do Lambda](chapter-layers.md). Para obter detalhes sobre como criar um pacote de implantação com dependências, consulte os seguintes tópicos: ------ #### [ Node.js ] [Implantar funções do Lambda em Node.js com arquivos .zip](nodejs-package.md) ------ #### [ Python ] [Trabalhar com arquivos .zip para funções do Lambda em Python](python-package.md) ------ #### [ Ruby ] [Implantar funções do Lambda em Ruby com arquivos .zip](ruby-package.md) ------ #### [ Java ] [Implantar funções do Lambda em Java com arquivos .zip ou JAR](java-package.md) ------ #### [ Go ] [Implantar funções do Lambda em Go com arquivos .zip](golang-package.md) ------ #### [ C\$1 ] [Criar e implantar funções do Lambda em C\$1 com arquivos .zip](csharp-package.md) ------ #### [ PowerShell ] [Implantar funções do Lambda para PowerShell com arquivos .zip](powershell-package.md) ------ ## Python: As bibliotecas carregam incorretamente **Problema:** (Python) *algumas bibliotecas não carregam corretamente do pacote de implantação* Bibliotecas com módulos de extensão escritos em C ou C\$1\$1 devem ser compiladas em um ambiente com a mesma arquitetura de processador que o Lambda (Amazon Linux). Para obter mais informações, consulte [Trabalhar com arquivos .zip para funções do Lambda em Python](python-package.md). ## Java: Sua função demora mais para processar eventos após a atualização do Java 11 para o Java 17 **Problema:** (Java): *Sua função demora mais para processar eventos após a atualização do Java 11 para o Java 17* Ajuste seu compilador usando o parâmetro `JAVA_TOOL_OPTIONS`. Os runtimes do Lambda para Java 17 e versões posteriores do Java alteram as opções padrão do compilador. A mudança melhora os tempos de inicialização a frio para funções de curta duração, mas o comportamento anterior é mais adequado para funções computacionalmente intensivas e de execução mais longa. Defina `JAVA_TOOL_OPTIONS` como `-XX:-TieredCompilation` para reverter ao comportamento do Java 11. Para obter mais informações sobre o parâmetro `JAVA_TOOL_OPTIONS`, consulte [Entender a variável de ambiente `JAVA_TOOL_OPTIONS`](java-customization.md#java-tool-options). ## Kafka: problemas de tratamento de erros e novas tentativas de configuração **Problema:** *o mapeamento da origem do evento do Kafka falha ao definir configurações de nova tentativa ou destinos em caso de falha* As configurações de nova tentativa do Kafka e os destinos em caso de falha só estão disponíveis para mapeamentos da origem do evento com o modo provisionado habilitado. Certifique-se de ter configurado `MinimumPollers` em seu `ProvisionedPollerConfig` antes de tentar definir configurações de nova tentativa. Erros de configuração comuns: + **Tentativas infinitas com lote bisseccionado**: não é possível habilitar `BisectBatchOnFunctionError` quando `MaximumRetryAttempts` está definido como -1 (infinito). Defina um limite finito de novas tentativas ou desabilite o lote bisseccionado. + **Recursão do mesmo tópico**: o tópico de destino em caso de falha do Kafka não pode ser igual a nenhum dos seus tópicos de origem. Escolha um nome de tópico diferente para seu tópico de mensagens não entregues. + **Formato de destino do Kafka inválido**: use o formato `kafka://` ao especificar um tópico do Kafka como um destino em caso de falha. + **Problemas de permissão kafka:WriteData**: certifique-se de que seu perfil de execução tenha permissões `kafka-cluster:WriteData` para o tópico de destino. O tópico não existe, exceções de tempo limite ou problemas de controle de utilização da API de gravação podem exigir o aumento dos limites da conta. # Solucionar problemas de mapeamento de origens de eventos no Lambda Problemas no Lambda relacionados a um [mapeamento de origem de evento](invocation-eventsourcemapping.md) podem ser mais complexos, pois envolvem depuração em vários serviços. Além disso, o comportamento da origem do evento pode ser diferente com base na origem do evento exata utilizada. Esta seção lista problemas comuns que envolvem mapeamentos de origens de eventos e fornece orientação sobre como identificá-los e solucioná-los. **nota** Ela usa uma origem de eventos do Amazon SQS como ilustração, mas os princípios se aplicam a outros mapeamentos de origens de eventos que enfileiram mensagens para funções do Lambda. ## Identificação e gerenciamento do controle de utilização No Lambda, o controle de utilização ocorre quando você atinge o limite de concorrência da sua função ou conta. Considere o exemplo abaixo, em que uma função do Lambda lê mensagens de uma fila do Amazon SQS. Essa função do Lambda simula invocações de 30 segundos e tem um tamanho de lote de 1. Isso significa que ela processa apenas 1 mensagem a cada 30 segundos: ``` const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms)) exports.handler = async (event) => { await doWork(30000) } ``` Com um tempo de invocação tão longo, as mensagens começam a chegar na fila com mais rapidez do que são processadas. Se a simultaneidade não reservada da sua conta for 100, o Lambda escalará até 100 execuções simultâneas e, em seguida, ocorrerá o controle de utilização. Você pode conferir esse padrão nas métricas do CloudWatch para a função: ![\[operações de depuração figura 10\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-10.png) As métricas do CloudWatch para a função não mostram erros, mas o gráfico **Execuções simultâneas** mostra que a simultaneidade máxima de 100 foi atingida. Como resultado, o gráfico **Controle de utilização** mostra o controle de utilização em vigor. Você pode detectar o controle de utilização com alarmes do CloudWatch e configurando um alarme sempre que a métrica de controle de utilização de uma função for maior que 0. Depois de identificar o problema de controle de utilização, você tem algumas opções de resolução: + Solicite um aumento de simultaneidade ao AWS Support nesta região. + Identifique problemas de performance na função para aumentar a velocidade de processamento e, portanto, melhorar o throughput. + Aumentar o tamanho do lote da função, para que mais mensagens sejam processadas por cada invocação. ## Erros na função de processamento Se a função de processamento gerar erros, o Lambda retornará as mensagens para a fila do SQS. O Lambda impede que sua função seja escalada para evitar erros em grande escala. As métricas a seguir do SQS no CloudWatch indicam um problema com o processamento de filas: ![\[operações de depuração figura 11\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-11.png) Em particular, tanto a idade da mensagem mais antiga quanto o número de mensagens visíveis estão aumentando, enquanto nenhuma mensagem é excluída. A fila continua crescendo, mas as mensagens não estão sendo processadas. As métricas do CloudWatch para a função do Lambda de processamento também indicam que há um problema: ![\[operações de depuração figura 12\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-12.png) A métrica **Contagem de erros** é diferente de zero e está aumentando, enquanto o valor de **Execuções simultâneas** reduziu e o controle de utilização foi interrompido. Isso mostra que o Lambda parou de escalar sua função devido a erros. Os logs do CloudWatch da função fornecem detalhes do tipo de erro. Você pode resolver esse problema identificando a função que está causando o erro e, em seguida, localizando e resolvendo o erro. Depois que você corrigir o erro e implantar o novo código da função, as métricas do CloudWatch deverão mostrar a recuperação do processamento: ![\[operações de depuração figura 13\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-13.png) Aqui, o valor da métrica **Contagem de erros** cai para zero e o valor da métrica **Taxa de sucesso** retorna a 100%. O Lambda começa a escalar a função novamente, conforme mostrado no gráfico **Execuções simultâneas**. ## Identificação e tratamento de contrapressão Se um produtor de eventos gerar consistentemente mensagens para uma fila do SQS mais rápido do que uma função do Lambda é capaz de processá-las, ocorre uma contrapressão. Nesse caso, o monitoramento do SQS deve mostrar a idade da mensagem mais antiga crescendo linearmente, juntamente com o número aproximado de mensagens visíveis. Você pode detectar contrapressão nas filas usando os alarmes do CloudWatch. As etapas para resolver a contrapressão dependem da sua workload. Se o objetivo principal for aumentar a capacidade de processamento e o throughput por meio da função do Lambda, existem algumas opções: + Solicite um aumento de simultaneidade ao AWS Support na região específica. + Aumentar o tamanho do lote da função, para que mais mensagens sejam processadas por cada invocação. # Solucionar problemas de redes no Lambda Por padrão, o Lambda executa suas funções em uma Virtual Private Cloud (VPC) interna com conectividade aos serviços da AWS e à Internet. Para acessar os recursos da rede local, é possível [configurar sua função para se conectar a uma VPC em sua conta](configuration-vpc.md). Ao usar esse recurso, você gerencia o acesso da função à Internet e a conectividade de rede com recursos da Amazon Virtual Private Cloud (Amazon VPC). Os erros de conectividade de rede podem ser originados de problemas na configuração de roteamento de sua VPC, regras de grupo de segurança, permissões de função do AWS Identity and Access Management (IAM), NAT ou disponibilidade de recursos, como endereços IP ou interfaces de rede. Conforme o problema, será possível ver um erro específico ou tempo limite se a solicitação não puder chegar ao destino. **Topics** + [VPC: A função perde o acesso à Internet ou atinge o tempo limite](#troubleshooting-networking-cfn) + [VPC: falha intermitente da conexão de TCP ou UDP](#troubleshooting-networking-tcp-udp) + [VPC: a função precisa de acesso aos Serviços da AWS sem usar a Internet](#troubleshooting-networking-access) + [VPC: Elastic network interface limit reached (VPC: limite da interface de rede elástica atingido)](#troubleshooting-networking-limit) + [EC2: interface de rede elástica com o tipo “lambda”](#troubleshooting-networking-eni) + [DNS: falha ao conectar a hosts com UNKNOWNHOSTEXCEPTION](#troubleshooting-networking-dns-tcp) ## VPC: A função perde o acesso à Internet ou atinge o tempo limite **Problema:** *a função do Lambda perde o acesso à Internet após se conectar a uma VPC.* **Erro:** *Erro: conexão ETIMEDOUT 176.32.98.189:443* **Erro:** *Erro: a tarefa expirou após 10,00 segundos* **Erro:** *ReadTimeoutError: Read timed out. (read timeout=15)* (Tempo limite excedeu) Ao conectar uma função a uma VPC, todas as solicitações de saída passam pela VPC. Para se conectar à Internet, configure a VPC para enviar tráfego de saída da sub-rede da função para um gateway NAT em uma sub-rede pública. Para obter mais informações e exemplos de configurações de VPC, consulte [Habilitar o acesso à Internet para funções do Lambda conectadas à VPC](configuration-vpc-internet.md). Se algumas conexões de TCP estiverem expirando, consulte [VPC: falha intermitente da conexão de TCP ou UDP](#troubleshooting-networking-tcp-udp) se sua sub-rede está usando uma lista de controle de acesso à rede (NACL). Caso contrário, isso provavelmente se deve à fragmentação de pacotes. As funções Lambda não podem lidar com o recebimento de solicitações TCP fragmentadas, pois o Lambda não oferece suporte à fragmentação de IP para TCP nem para ICMP. ## VPC: falha intermitente da conexão de TCP ou UDP **nota** Esse problema se aplicará apenas se sua sub-rede usar uma [lista de controle de acesso (ACL) à rede](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html#nacl-basics). Não são exigidas ACLs de rede para o Lambda se conectar às sub-redes. **Problema:***o Lambda perde intermitentemente a conexão com as sub-redes da VPC, para as quais você configurou uma lista de controle de acesso (ACL) à rede .* Para funções do Lambda habilitadas para VPC, a AWS cria [ENIs de hiperplano](configuration-vpc.md#configuration-vpc-enis) na conta do cliente e usa as portas efêmeras de `1024` a `65535` para conectar o Lambda à VPC do cliente. Se você usar ACLs de rede na sub-rede de destino, deverá alocar o intervalo de portas de `1024` a `65535` para TCP e UDP. Não alocar esse intervalo de portas inteiro pode causar falhas de conexão intermitentes. ## VPC: a função precisa de acesso aos Serviços da AWS sem usar a Internet **Problema:** *a função do Lambda precisa acessar os Serviços da AWS sem usar a Internet.* Para conectar uma função aos Serviços da AWS de uma sub-rede privada sem acesso à Internet, use os endpoints da VPC. ## VPC: Elastic network interface limit reached (VPC: limite da interface de rede elástica atingido) **Erro:** *ENILimitReachedException: o limite de interface de rede elástica foi atingido para a VPC da função.* Quando você conecta uma função do Lambda a uma VPC, o Lambda cria uma interface de rede elástica para cada combinação de sub-rede e grupo de segurança anexado à função. A cota de serviço padrão é de 250 interfaces de rede por VPC. Para solicitar aumento de cota, use o [console do Service Quotas](https://console.aws.amazon.com/servicequotas/home/services/lambda/quotas/L-9FEE3D26). ## EC2: interface de rede elástica com o tipo “lambda” **Código de erro:** *Client.OperationNotPermited* **Mensagem de erro:** *o grupo de segurança não pode ser modificado para esse tipo de interface* Você receberá esse erro se tentar modificar uma interface de rede elástica (ENI) gerenciada pelo Lambda. O `ModifyNetworkInterfaceAttribute` não está incluído na API do Lambda para operações de atualização em interfaces de rede elástica criadas pela Lambda. ## DNS: falha ao conectar a hosts com UNKNOWNHOSTEXCEPTION **Mensagem de erro:** *UNKNOWNHOSTEXCEPTION* As funções do Lambda são compatíveis com até 20 conexões TCP simultâneas para resolução de DNS. Sua função pode estar esgotando esse limite. As solicitações de DNS mais comuns são feitas por UDP. Se a função só estiver fazendo conexões de DNS por UDP, é improvável que o problema seja esse. Esse erro geralmente ocorre devido a configurações incorretas ou infraestrutura degradada. Portanto, antes de examinar em profundidade o tráfego de DNS, confirme que a infraestrutura de DNS está configurada corretamente e está íntegra, e que a função do Lambda está referenciando um host especificado no DNS. Se você diagnosticar que o problema está relacionado ao limite máximo da conexão por TCP, observe que não é possível solicitar um aumento desse limite. Se a função do Lambda estiver fazendo fallback para o DNS por TCP devido a grandes cargas de DNS, confirme que a sua solução está usando bibliotecas compatíveis com o EDNS. Para obter mais informações sobre o EDNS, consulte [o padrão RFC 6891](https://datatracker.ietf.org/doc/html/rfc6891). Se suas cargas de DNS excederem consistentemente os tamanhos máximos do EDNS, sua solução ainda poderá esgotar o limite de DNS por TCP.