Anunciando o timeout de função de 90 minutos no AWS Lambda Managed Instances

Por Tarun Rai Madan, Dan Slusariuc e Snehil Ameta.

O AWS Lambda agora oferece suporte a um timeout de função de 90 minutos para invocações assíncronas e event source mapping (ESM) no AWS Lambda Managed Instances (LMI), um recurso do AWS Lambda. Esse é um aumento de 6x em relação ao limite anterior de 15 minutos. Clientes que executam processamento de dados, transcodificação de mídia, cálculos financeiros, inferência de IA e workloads em lote agora podem usar funções Lambda para tarefas que exigem execução contínua mais longa, sem precisar reestruturar suas aplicações. Isso também se aplica a invocações dentro de funções duráveis do Lambda, que usam checkpoints para rastrear o progresso e se recuperar automaticamente de falhas por meio de replay, pulando o trabalho já concluído. Quando invocada de forma assíncrona, uma execução durável de várias etapas pode ser executada por até 1 ano.

Evolução do timeout de função no Lambda

O timeout de função do Lambda aumentou ao longo do tempo, de 5 minutos no lançamento em 2014 para 15 minutos em 2018. Conforme os clientes buscaram usar a simplicidade do Lambda para workloads intensivos em dados, o limite de timeout de 15 minutos forçou compromissos arquiteturais para aplicações em que os clientes precisavam de um tempo de execução contínua mais longo. Vários padrões surgiram:

• Processamento de mídia: transcrição de fala para texto e transcodificação de vídeo que rotineiramente precisam de mais de 15 minutos de execução contínua.
• Cálculos financeiros: simulações de Monte Carlo, precificação de títulos e análise de risco de portfólio que consomem muita memória e frequentemente exigem mais de 15 minutos.
• Processamento de dados e pipelines de ETL: jobs em lote que processam conjuntos de dados de vários gigabytes ou que agregam dados de fontes externas e excedem 15 minutos em picos de volume.
• Inferência de IA: jobs de teste e inferência de modelos (por exemplo, tarefas de raciocínio) que se encaixam no perfil de memória e CPU do Lambda, mas excedem seu timeout.
• Web scraping e transferência de arquivos: rastreamento de sites externos ou obtenção de grandes conjuntos de arquivos de fornecedores que excedem 15 minutos quando as fontes respondem lentamente.

Em cada caso, os clientes preferiam a simplicidade do Lambda, mas tinham que reestruturar a arquitetura quando os jobs atingiam o limite de 15 minutos.

Avançando para 2026, o Lambda oferece suporte a dois formatos: funções (orientadas a eventos, timeout de 15 minutos) e MicroVMs para código just-in-time gerado por usuário ou IA (orientado a HTTP, duração de 8 horas). Para permitir que os clientes se beneficiem da simplicidade da computação Serverless com a flexibilidade e o modelo de preços do EC2 para workloads em estado estável, estendemos o modo de capacidade sob demanda do Lambda para adicionar o Lambda Managed Instances (LMI). Com o Lambda Managed Instances, você pode processar várias solicitações simultâneas por instância, acessar configurações de computação especializadas e obter eficiência de custos por meio das vantagens de preços do EC2, sem gerenciar infraestrutura.

Também oferecemos suporte às funções duráveis do Lambda (com tecnologia do SDK de execução durável) tanto no modo de capacidade sob demanda quanto no LMI. As funções duráveis fornecem checkpoints no nível da aplicação e workflow-as-code: seu código salva o estado de execução usando as operações step() e wait() e se recupera com elegância de falhas de infraestrutura, retomando a partir do último checkpoint em vez de reiniciar do zero. Embora uma execução durável (o ciclo de vida completo de uma função durável) possa ser executada por até um ano, cada invocação ainda era limitada a 15 minutos.

Conforme os clientes migram mais workloads para a computação Serverless para se beneficiar de sua simplicidade, eles precisam de uma execução contínua mais longa para casos de uso intensivos em dados, como inferência de IA, transcodificação de mídia, modelagem científica e cálculos financeiros que não se encaixam nas restrições de duração de 15 minutos do Lambda. Hoje, estamos estendendo o timeout de função no Lambda Managed Instances para 90 minutos para invocações assíncronas e ESM. Isso inclui invocações dentro de uma função durável, em que uma aplicação de várias etapas pode continuar em execução por até 1 ano quando invocada de forma assíncrona.

Ativando o timeout de função de 90 minutos

Agora você pode configurar qualquer função Lambda em execução em um Managed Instance com um timeout de até 90 minutos (5.400 segundos) para invocações assíncronas e ESM. As invocações síncronas mantêm o máximo existente de 15 minutos. A função é executada exatamente como antes: mesmo runtime, mesmo handler, mesma função de execução do IAM, mesma configuração de virtual private cloud (VPC). A única diferença é que sua função agora oferece suporte a uma execução contínua mais longa. Seu código de inicialização (fase Init) ainda é limitado a 15 minutos no Lambda Managed Instances.

Para definir o timeout, atualize a configuração da sua função usando a AWS CLI:

aws lambda update-function-configuration \
    --function-name my-data-processor \
    --timeout 5400 \
    --region us-east-1

Ou no AWS CloudFormation / AWS Serverless Application Model (AWS SAM):

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    FunctionName: my-data-processor
    Runtime: python3.12
    Handler: app.handler
    Timeout: 5400
    MemorySize: 10240

Você não precisa alterar nenhum código. Você também pode atualizar o timeout no console do Lambda em Configuration > General Configuration (Figura 1), ou configurá-lo por meio de prompts em linguagem natural em seus assistentes de codificação de IA (como Claude Code ou Kiro) instalando o Agent Toolkit for AWS.

A alteração entra em vigor nas invocações subsequentes após a atualização do timeout da função. Para event source mappings, aguarde alguns minutos para que a nova configuração seja propagada. Sua configuração de observabilidade existente continua funcionando como esperado: as métricas do Amazon CloudWatch, o AWS CloudTrail e o AWS X-Ray capturam o ciclo de vida completo da invocação sem nenhuma alteração. Para obter detalhes, consulte monitoramento de funções Lambda e monitoramento de funções duráveis.

Não há cobrança adicional pelo uso do timeout de 90 minutos. Aplica-se o preço padrão do Lambda Managed Instances.

Timeout de 90 minutos e funções duráveis

O timeout de função de 90 minutos e as funções duráveis são complementares. O timeout de função (--timeout) controla por quanto tempo cada invocação individual pode ser executada, enquanto o timeout de execução durável (ExecutionTimeout em --durable-config) controla o tempo total decorrido desde o início da execução até a conclusão. As funções duráveis usam checkpoints para rastrear o progresso e se recuperar automaticamente de falhas por meio de replay, executando novamente desde o início e pulando o trabalho já concluído. Com o lançamento de hoje, cada invocação assíncrona em uma função durável em execução em um Managed Instance agora pode ser executada continuamente por até 90 minutos, enquanto a execução durável correspondente pode ser executada por até 1 ano. Para invocações síncronas e event source mapping, tanto a invocação quanto a execução durável correspondente são limitadas a 90 minutos.

Para jobs idempotentes (por exemplo, uma etapa de pipeline de ETL acionada pelo SQS), o timeout estendido por si só pode ser suficiente. Se o host falhar, a mensagem retorna à fila e uma nova invocação é iniciada. Para jobs em que a nova execução é custosa (por exemplo, uma execução de inferência de 40 minutos que já está 30 minutos em andamento), combine os dois recursos. Ative as funções duráveis para fazer checkpoints periodicamente, de forma que uma falha no minuto 35 seja retomada a partir do último checkpoint em vez de reiniciar do zero.

Comportamento de invocação: assíncrono, event source mappings e síncrono

Invocações assíncronas (até 90 minutos): se a função falhar ou exceder o timeout, o Lambda aplica sua política de nova tentativa configurada (até duas novas tentativas por padrão) e encaminha eventos com falha para sua dead-letter queue ou destino de falha.

Event source mappings (até 90 minutos): para o SQS, configure o timeout de visibilidade da fila para ser no mínimo seis vezes o timeout da função. Isso dá ao Lambda tempo suficiente para tentar novamente se uma função for limitada (throttled) enquanto processa um lote anterior. O Lambda valida isso no momento da criação do event source mapping, mas não impede alterações subsequentes nas configurações da fila ou da função que possam criar uma incompatibilidade.

Para o Amazon Kinesis e o Amazon DynamoDB Streams, configure a janela máxima de agrupamento em lote e o fator de paralelização para levar em conta tempos de processamento mais longos por lote.

Se o seu lote contiver vários registros e você quiser evitar reprocessar o lote inteiro quando um registro falhar, ative o relatório de falha parcial de lote. Esse recurso está disponível para event source mappings do SQS, Kinesis, DynamoDB Streams, Amazon Managed Streaming for Apache Kafka (Amazon MSK) e Apache Kafka autogerenciado. Com as falhas parciais de lote ativadas, apenas os registros com falha são reprocessados, não o lote inteiro.

Observe que as invocações para Amazon MQ ESM e Amazon DocumentDB (com compatibilidade com MongoDB) ESM permanecem limitadas a 15 minutos.

Invocações síncronas (máximo de 15 minutos): as invocações síncronas mantêm o timeout máximo existente de 15 minutos. Se você definir o timeout da sua função para um valor maior que 15 minutos e invocá-la de forma síncrona, o Lambda continuará aplicando o timeout de 15 minutos. A API GetFunctionConfiguration informa o valor de timeout configurado.

Para ver quais fontes de eventos invocam funções Lambda de forma síncrona ou assíncrona, consulte a documentação do Lambda.

Considerações e práticas recomendadas

Como suas funções agora oferecem suporte a uma execução contínua mais longa, considere estas práticas recomendadas para componentes que podem ter natureza efêmera, como conexões de rede e credenciais.

Rede: certifique-se de que os timeouts de conexão inativa nos serviços downstream (RDS, Amazon ElastiCache, APIs externas) acomodem a duração total da função. Se sua função rotear tráfego por meio de um NAT Gateway, envie pacotes keep-alive para evitar que conexões inativas sejam descartadas (timeout de inatividade de 350 segundos). Respeite os valores de TTL de DNS para resolução de nomes de host externos. O AWS SDK trata isso automaticamente, mas clientes HTTP personalizados podem armazenar em cache registros DNS além do seu TTL.

Credenciais: se sua função adquirir credenciais ou tokens temporários, verifique se eles permanecem válidos durante toda a duração da execução ou renove-os em segundo plano.

Idempotência: o Lambda não garante processamento exatamente uma vez. Com funções de execução mais longa, a janela para novas tentativas e entregas duplicadas aumenta. Você pode usar o Powertools for AWS Lambda para implementar idempotência no código da sua função, de modo que operações como pagamentos ou gravações em banco de dados produzam o mesmo resultado mesmo que sejam executadas mais de uma vez. Se você usar funções duráveis do Lambda, as etapas têm semântica de execução pelo menos uma vez por padrão. O SDK ignora etapas concluídas durante o replay, mas etapas que falham antes do checkpoint podem ser executadas novamente. Você pode usar nomes de execução como chaves de idempotência para funções duráveis.

Conclusão

O timeout de função de 90 minutos no Lambda Managed Instances atende a uma das necessidades mais comuns dos clientes para criar aplicações intensivas em dados no AWS Lambda. Workloads de processamento de dados, transcodificação de mídia, inferência de IA e computação financeira que excedem 15 minutos agora podem ser executados no Lambda sem alterações de código ou soluções alternativas de arquitetura. Esperamos ouvir de você caso precise de um timeout mais longo para invocações síncronas, ou para o modo de capacidade sob demanda, em nossa página do GitHub do AWS Lambda Roadmap.

Para começar, atualize a configuração de timeout da sua função e implante. Para um passo a passo detalhado, consulte Primeiros passos com o Lambda Managed Instances. Para código de exemplo demonstrando funções de longa duração com checkpoints duráveis, consulte exemplos de funções duráveis. Para saber mais sobre o AWS Lambda, visite aws.amazon.com/lambda.

Este conteúdo foi traduzido a partir da publicação original do blog, que pode ser encontrada aqui.

Autores

	Tarun Rai Madan é Principal Product Manager – Tech na Amazon Web Services.
	Dan Slusariuc é Software Development Manager na Amazon Web Services.
	Snehil Ameta é Software Development Engineer na Amazon Web Services.

Tradutores

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/

Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Atualmente está habilitando empresas do ramo de ISV (Independent Software Vendors) simplificando a operação na nuvem e otimizando os custos em cloud. Sua área de interesse são tecnologias serverless. https://www.linkedin.com/in/nicolastarzia