O blog da AWS
Crie aplicações multi-etapas e fluxos de trabalho de IA com funções duráveis do AWS Lambda
Por Donnie Prakoso, engenheiro de software e Principal Developer Advocate na AWS.
As aplicações modernas demandam cada vez mais coordenação complexa e de longa duração entre serviços, como processamento de pagamentos em várias etapas, orquestração de agentes de IA ou processos de aprovação aguardando decisões humanas. Desenvolver essas aplicações tradicionalmente exigia esforço significativo para implementar gerenciamento de estado, lidar com falhas e integrar múltiplos serviços de infraestrutura.
Agora você pode usar funções duráveis do AWS Lambda para desenvolver aplicações multi-etapas confiáveis diretamente dentro da experiência familiar do AWS Lambda. Funções duráveis são funções Lambda regulares com o mesmo manipulador de eventos e integrações que você já conhece. Você escreve código sequencial em sua linguagem de programação preferida, e as funções duráveis rastreiam o progresso, tentam novamente automaticamente em caso de falhas e suspendem a execução por até um ano em pontos definidos, sem pagar por computação ociosa durante as esperas.
As funções duráveis do AWS Lambda usam um mecanismo de *checkpoint* e *replay*, conhecido como execução durável, para fornecer esses recursos. Após ativar uma função para execução durável, você adiciona o novo SDK de execução durável de código aberto ao código da sua função. Em seguida, você usa primitivas do SDK como “*steps*” para adicionar *checkpointing* automático e novas tentativas à sua lógica de negócios e “*waits*” para suspender eficientemente a execução sem cobranças de computação. Quando a execução termina inesperadamente, o Lambda retoma do último *checkpoint*, reproduzindo seu manipulador de eventos desde o início enquanto ignora operações concluídas.
Primeiros passos com funções duráveis do AWS Lambda
Vou mostrar como usar funções duráveis.
Primeiro, crio uma nova função Lambda no console e seleciono Criar do zero. Na seção Execução durável, seleciono Ativar. Note que a configuração de função durável só pode ser definida durante a criação da função e atualmente não pode ser modificada para funções Lambda existentes.

Após criar minha função durável Lambda, posso começar com o código fornecido.

As funções duráveis do Lambda introduzem duas primitivas principais que lidam com gerenciamento de estado e recuperação:
- Steps—O método
context.step()adiciona novas tentativas automáticas e *checkpointing* à sua lógica de negócios. Depois que uma etapa é concluída, ela será ignorada durante o *replay*. - Wait—O método
context.wait()pausa a execução por uma duração especificada, encerrando a função, suspendendo e retomando a execução sem cobranças de computação.
Além disso, as funções duráveis do Lambda fornecem outras operações para padrões mais complexos: create_callback() cria um *callback* que você pode usar para aguardar resultados de eventos externos como respostas de API ou aprovações humanas, wait_for_condition() pausa até que uma condição específica seja atendida, como fazer *polling* de uma API REST para conclusão de processo, e operações parallel() ou map() para casos de uso avançados de concorrência.
Construindo um fluxo de trabalho de processamento de pedidos pronto para produção
Agora expandiremos o exemplo padrão para construir um fluxo de trabalho de processamento de pedidos pronto para produção. Isso demonstra como usar *callbacks* para aprovações externas, lidar com erros adequadamente e configurar estratégias de nova tentativa. Manterei o código intencionalmente conciso para focar nesses conceitos principais. Em uma implementação de produção, você poderia aprimorar a etapa de validação com Amazon Bedrock para adicionar análise de pedidos alimentada por IA.
Veja como o fluxo de trabalho de processamento de pedidos funciona:
- Primeiro,
validate_order()verifica os dados do pedido para garantir que todos os campos obrigatórios estejam presentes. - Em seguida,
send_for_approval()envia o pedido para aprovação humana externa e aguarda uma resposta de *callback*, suspendendo a execução sem cobranças de computação. - Então,
process_order()completa o processamento do pedido. - Ao longo do fluxo de trabalho, o tratamento de erros try-catch distingue entre erros terminais que interrompem a execução imediatamente e erros recuperáveis dentro das etapas que acionam novas tentativas automáticas.
Aqui está o fluxo de trabalho completo de processamento de pedidos com definições de etapas e o manipulador principal:
import random
from aws_durable_execution_sdk_python import (
DurableContext,
StepContext,
durable_execution,
durable_step,
)
from aws_durable_execution_sdk_python.config import (
Duration,
StepConfig,
CallbackConfig,
)
from aws_durable_execution_sdk_python.retries import (
RetryStrategyConfig,
create_retry_strategy,
)
@durable_step
def validate_order(step_context: StepContext, order_id: str) -> dict:
"""Validates order data using AI."""
step_context.logger.info(f"Validating order: {order_id}")
# In production: calls Amazon Bedrock to validate order completeness and accuracy
return {"order_id": order_id, "status": "validated"}
@durable_step
def send_for_approval(step_context: StepContext, callback_id: str, order_id: str) -> dict:
"""Sends order for approval using the provided callback token."""
step_context.logger.info(f"Sending order {order_id} for approval with callback_id: {callback_id}")
# In production: send callback_id to external approval system
# The external system will call Lambda SendDurableExecutionCallbackSuccess or
# SendDurableExecutionCallbackFailure APIs with this callback_id when approval is complete
return {
"order_id": order_id,
"callback_id": callback_id,
"status": "sent_for_approval"
}
@durable_step
def process_order(step_context: StepContext, order_id: str) -> dict:
"""Processes the order with retry logic for transient failures."""
step_context.logger.info(f"Processing order: {order_id}")
# Simulate flaky API that sometimes fails
if random.random() > 0.4:
step_context.logger.info("Processing failed, will retry")
raise Exception("Processing failed")
return {
"order_id": order_id,
"status": "processed",
"timestamp": "2025-11-27T10:00:00Z",
}
@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> dict:
try:
order_id = event.get("order_id")
# Step 1: Validate the order
validated = context.step(validate_order(order_id))
if validated["status"] != "validated":
raise Exception("Validation failed") # Terminal error - stops execution
context.logger.info(f"Order validated: {validated}")
# Step 2: Create callback
callback = context.create_callback(
name="awaiting-approval",
config=CallbackConfig(timeout=Duration.from_minutes(3))
)
context.logger.info(f"Created callback with id: {callback.callback_id}")
# Step 3: Send for approval with the callback_id
approval_request = context.step(send_for_approval(callback.callback_id, order_id))
context.logger.info(f"Approval request sent: {approval_request}")
# Step 4: Wait for the callback result
# This blocks until external system calls SendDurableExecutionCallbackSuccess or SendDurableExecutionCallbackFailure
approval_result = callback.result()
context.logger.info(f"Approval received: {approval_result}")
# Step 5: Process the order with custom retry strategy
retry_config = RetryStrategyConfig(max_attempts=3, backoff_rate=2.0)
processed = context.step(
process_order(order_id),
config=StepConfig(retry_strategy=create_retry_strategy(retry_config)),
)
if processed["status"] != "processed":
raise Exception("Processing failed") # Terminal error
context.logger.info(f"Order successfully processed: {processed}")
return processed
except Exception as error:
context.logger.error(f"Error processing order: {error}")
raise error # Re-raise to fail the execution
Este código demonstra vários conceitos importantes:
- Tratamento de erros—O bloco try-catch lida com erros terminais. Quando uma exceção não tratada é lançada fora de uma etapa (como a verificação de validação), ela encerra a execução imediatamente. Isso é útil quando não há sentido em tentar novamente, como dados de pedido inválidos.
- Novas tentativas de etapas—Dentro da etapa
process_order, as exceções acionam novas tentativas automáticas com base naRetryStrategypadrão (etapa 1) ou configurada (etapa 5). Isso lida com falhas transitórias como indisponibilidade temporária de API. - Registro de *logs*—Uso
context.loggerpara o manipulador principal estep_context.loggerdentro das etapas. O *logger* de contexto suprime *logs* duplicados durante o *replay*.
Agora crio um evento de teste com order_id e invoco a função de forma assíncrona para iniciar o fluxo de trabalho do pedido. Navego até a aba Teste e preencho o Nome de execução durável opcional para identificar esta execução. Note que as funções duráveis fornecem idempotência integrada. Se invocar a função duas vezes com o mesmo nome de execução, a segunda invocação retorna o resultado da execução existente em vez de criar uma duplicata.

Posso acompanhar a execução navegando até a aba Execuções duráveis no console do Lambda:

Aqui é possível ver o status e o tempo de cada etapa. A execução mostra CallbackStarted seguido por InvocationCompleted, o que indica que a função foi encerrada e a execução está suspensa para evitar cobranças ociosas enquanto aguarda o *callback* de aprovação.

Agora é possível concluir o *callback* diretamente do console escolhendo Enviar sucesso ou Enviar falha, ou programaticamente usando a API do Lambda.

Escolho Enviar sucesso.

Após o *callback* ser concluído, a execução é retomada e processa o pedido. Se a etapa process_order falhar devido à API instável simulada, ela tenta novamente automaticamente com base na estratégia configurada. Uma vez que todas as novas tentativas sejam bem-sucedidas, a execução é concluída com sucesso.

Monitorando execuções com Amazon EventBridge
Você também pode monitorar execuções de funções duráveis usando o Amazon EventBridge. O Lambda envia automaticamente eventos de mudança de status de execução para o barramento de eventos padrão, permitindo que você construa fluxos de trabalho downstream, envie notificações ou integre com outros serviços da AWS.
Para receber esses eventos, crie uma regra do EventBridge no barramento de eventos padrão com este padrão:
{
"source": ["aws.lambda"],
"detail-type": ["Durable Execution Status Change"]
}
Coisas a saber
Aqui estão pontos importantes a observar:
- Disponibilidade—As funções duráveis do Lambda estão agora disponíveis na Região da AWS US East (Ohio). Para a disponibilidade mais recente das Regiões, visite a página Capacidades da AWS por Região.
- Suporte a linguagens de programação—No lançamento, as funções duráveis do AWS Lambda suportam JavaScript/TypeScript (Node.js 22/24) e Python (3.13/3.14). Recomendamos agrupar o SDK de execução durável com o código da sua função usando seu gerenciador de pacotes preferido. Os SDKs estão em rápida evolução, então você pode facilmente atualizar dependências conforme novos recursos ficam disponíveis.
- Usando versões do Lambda—Ao implantar funções duráveis em produção, use versões do Lambda para garantir que o replay sempre aconteça na mesma versão do código. Se você atualizar o código da sua função enquanto uma execução está suspensa, o replay usará a versão que iniciou a execução, prevenindo inconsistências de mudanças de código durante fluxos de trabalho de longa duração.
- Testando suas funções duráveis—Você pode testar funções duráveis localmente sem credenciais da AWS usando o SDK de teste separado com integração pytest e a interface de linha de comando (CLI) do AWS Serverless Application Model (AWS SAM) para testes de integração mais complexos.
- SDKs de código aberto—Os SDKs de execução durável são de código aberto para JavaScript/TypeScript e Python. Você pode revisar o código-fonte, contribuir com melhorias e se manter atualizado com os recursos mais recentes.
- Preços—Para saber mais sobre os preços das funções duráveis do AWS Lambda, consulte a página de preços do AWS Lambda.
Comece a usar funções duráveis do AWS Lambda visitando o console do AWS Lambda. Para saber mais, consulte a página de documentação de funções duráveis do AWS Lambda.
Boa construção!
Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.
Autor
![]() |
Donnie Prakoso é engenheiro de software, barista autoproclamado e Principal Developer Advocate na AWS. Com mais de 17 anos de experiência na indústria de tecnologia, de telecomunicações, bancos a startups. Ele agora está focado em ajudar os desenvolvedores a entender variedades de tecnologia para transformar suas ideias em execução. Ele ama café e qualquer discussão sobre qualquer tópico, de microsserviços a IA / ML. |
Tradutores
![]() |
Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados. |
![]() |
Daniel Abib é arquiteto de soluções sênior 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 segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/ |


