DEV Community: Eduardo Garcia

AWS Lambda Durable Functions: primeiras impressões

Eduardo Garcia — Wed, 04 Mar 2026 02:06:55 +0000

Arquitetura serverless é uma pauta que não para de crescer, especialmente quando falamos da Amazon Web Services. Nos últimos anos, a plataforma vem apresentando uma série de inovações pensadas para escalabilidade, resiliência e redução da complexidade operacional, permitindo que equipes foquem cada vez mais na lógica de negócio.

Durante muito tempo, um dos principais limites do modelo serverless esteve associado ao tempo máximo de execução das funções. No caso do AWS Lambda, esse limite sempre foi de 15 minutos, o que naturalmente restringia o tipo de problema que poderia ser resolvido diretamente com funções.

Nos últimos meses, a AWS passou a explorar de forma mais madura um conceito já conhecido em outras plataformas: orquestrações duráveis. Neste artigo, utilizo o termo Durable Functions para me referir a um padrão de arquitetura(e não a um serviço específico) que permite a construção de workflows de longa duração sobre o Lambda, capazes de se estender por dias, meses ou até um ano, sem que nenhuma função precise permanecer em execução contínua.

O problema que as orquestrações duráveis resolvem

Em fluxos tradicionais, a execução ocorre de forma contínua e está diretamente limitada ao ciclo de vida da função. Isso funciona bem para tarefas curtas, mas se torna um obstáculo em cenários que exigem mais controle e maior tempo de processamento, como:

pipelines de dados long-running;
fluxos que envolvem múltiplas integrações externas;
processos que dependem de interação humana;
workloads relacionados a IA e machine learning.

Para atender esse tipo de necessidade, o padrão de Durable Functions introduz o conceito de execução orquestrada baseada em eventos e estado persistente. Na prática, isso significa que um processo pode avançar, pausar, aguardar eventos externos e ser retomado posteriormente, sempre preservando seu contexto.

Importante destacar: a função Lambda não fica rodando por todo esse período. O que é durável é o workflow, não a execução contínua.

Como funciona a orquestração durável na prática

O funcionamento desse padrão se baseia em alguns pilares fundamentais do ecossistema serverless:

Execuções curtas e idempotentes;
Persistência de estado fora da função;
Comunicação via eventos.

Cada passo do fluxo é disparado por eventos e, ao finalizar sua execução, a função persiste o estado necessário para continuidade do processo. Um identificador único da orquestração garante que, ao receber um novo evento, o fluxo seja retomado exatamente do ponto correto.

Esses eventos podem ser emitidos:

pela própria aplicação;
por outros serviços;
ou até por usuários externos, como em um cenário de aprovação manual.

Essa abordagem permite construir workflows extremamente flexíveis, sem violar as premissas do modelo serverless.

Durable Functions vs Step Functions

Nesse ponto, surge naturalmente a comparação com o AWS Step Functions. Embora ambos resolvam problemas de orquestração, a principal diferença está no nível de controle via código:

Durable Functions:

Fluxo definido integralmente em código;
Maior flexibilidade e dinamismo;
Versionamento do workflow junto à aplicação;
Ideal para lógicas complexas e altamente customizadas.

Step Functions

Fluxo declarativo, baseado em estados;
Excelente visualização e observabilidade;
Menor complexidade operacional;
Ótima escolha para fluxos previsíveis e bem definidos.

Ou seja, Durable Functions não substituem o Step Functions. Elas atendem a um conjunto diferente de problemas, onde o controle fino do fluxo diretamente no código é um requisito.

Arquitetura baseada em eventos

A execução baseada em eventos é um conceito já bem conhecido por quem trabalha com serverless. Em orquestrações duráveis, ela se torna ainda mais central.

Serviços como Amazon EventBridge permitem desacoplar completamente os passos do workflow, enquanto bancos como Amazon DynamoDB podem ser usados para persistir estado e metadados da execução.

Esse modelo garante:

alta resiliência;
recuperação automática em caso de falhas;
escalabilidade praticamente ilimitada.

Evolução do ecossistema e perspectivas futuras

Com a evolução constante dos runtimes suportados pelo Lambda (importante ressaltar que até o momento Durable Functions aceita apenas linguagem Python e Node.js) e os avanços contínuos da biblioteca boto3, é natural que padrões mais avançados de orquestração via código ganhem cada vez mais espaço dentro do ecossistema AWS.

À medida que aplicações serverless amadurecem, cresce também a necessidade de fluxos mais longos, controlados e resilientes — e é exatamente nesse cenário que o conceito de Durable Functions se encaixa.

Conclusão

Durable Functions representam um passo importante na evolução da arquitetura serverless na AWS. Elas não surgem como substitutas de soluções já consolidadas, mas como uma alternativa poderosa para cenários que exigem maior controle, flexibilidade e duração de execução.

Entender quando aplicar esse padrão (e quando optar por soluções mais simples) é fundamental para tirar o máximo proveito do ecossistema serverless.

Fontes:

Lambda Durable Functions Introducing
Docs Lambda

AWS Lambda + Secrets Manager

Eduardo Garcia — Tue, 21 Oct 2025 21:29:11 +0000

Funções AWS Lambda são opções extremamente práticas que simplificam todo o processo de disponibilização de aplicações serverless.
Ao mesmo tempo que geram praticidade, também podem criar péssimos hábitos em nós, desenvolvedores.

Um desses maus costumes é a exposição de chaves de API externas ou conexões de banco de dados diretamente dentro do corpo de uma função Lambda. São incontáveis as vezes em que encontrei códigos semelhantes ao mostrado abaixo:

Nem é preciso dizer o quão ruim é manter suas configurações assim! Essa exposição de chaves é extremamente prejudicial por alguns fatores, dentre eles:

Vulnerabilidade da aplicação: qualquer vazamento de código, seja em um repositório público ou por um ataque, expõe suas credenciais ao mundo externo;
Falta de escalabilidade: caso seja necessário trocar de conexão com a base ou atualizar um par de API Keys, será preciso publicar novamente o código para que ele funcione. Em uma única Lambda isso é simples, mas quando falamos de funções críticas com múltiplas conexões, a situação complica.

Pensando nesses pontos, a melhor forma de manter suas chaves seguras é externalizar o armazenamento e o gerenciamento delas.
E é exatamente para isso que a AWS disponibiliza o AWS Secrets Manager, um serviço voltado para o controle e a centralização de credenciais de forma segura.

1. Configurando um conjunto de chaves na AWS

Em sua conta da AWS, acesse o serviço AWS Secrets Manager e escolha a opção “Store a new secret”;
Em Secret Type, selecione “Other type of secret” e preencha todas as chaves necessárias. Para este exemplo, foram criadas apenas duas. Em seguida, pressione Next.

Na próxima tela, escolha um nome descritivo para o conjunto de chaves.

Depois, basta confirmar as etapas seguintes. O conjunto de secrets ficará disponível instantaneamente e pode ser acessado no console em Overview → Retrieve Secret Value.

Simples assim: suas secrets estão criadas e já podem ser usadas — seja em aplicações via SDK, seja através do CLI.

2. Buscando as chaves dentro da Lambda

Dentro de uma função Lambda, o uso das chaves é muito simples. No exemplo abaixo, estou utilizando o framework AWS SAM, configurado com Python 3.10 — uma versão que já inclui o SDK da AWS.

Com o pequeno bloco de código a seguir, é possível acessar as chaves configuradas:

O parâmetro principal da função parameters.get_secret() é o nome atribuído ao conjunto de chaves. Os outros dois parâmetros são opcionais: um define o formato dos dados retornados e o outro o tempo de cache em segundos.

Tudo certo, certo? Quase!
Provavelmente, ao rodar sua Lambda — seja no ambiente de desenvolvimento ou em produção — você receberá um erro de permissão negada.

Isso acontece porque é necessário conceder à função permissão para ler chaves no Secrets Manager.

Essa permissão pode ser adicionada diretamente no template.yaml (no caso do AWS SAM), ou atribuída ao usuário/role que executa a função localmente via CLI. Na imagem abaixo, temos um exemplo de política que permite à função acessar o Secrets Manager:

3. Conclusão

Com esse setup feito, você está pronto para usar suas chaves de forma segura em funções Lambda! O uso do AWS Secrets Manager traz um ganho significativo de controle e escalabilidade, centralizando as credenciais dentro de um ambiente seguro e fácil de manter.

Além disso, o serviço permite configurar rotação automática de chaves, reduzindo o risco de vazamentos e simplificando ainda mais o gerenciamento de credenciais sensíveis.

Vale lembrar que, como todo serviço da AWS, o Secrets Manager possui um custo.

Antes de implementá-lo em larga escala, consulte os valores nesta página.

Abaixo está o link para meu repositório no GitHub, onde disponibilizo um projeto de exemplo com o uso do Secrets Manager em uma função Lambda criada com AWS SAM:

🔗 Eudu4rdo/AWS-SAM-Projects

Em resumo:

Ao adotar o Secrets Manager, você não apenas protege suas credenciais, mas também eleva o nível de segurança, profissionalismo e maturidade do seu ambiente serverless.

Deploy de funções AWS Lambda com GitHub Actions usando Organizations

Eduardo Garcia — Tue, 05 Aug 2025 00:34:24 +0000

Nos últimos meses, tenho trabalhado bastante com funções serverless na AWS. Para isso, venho utilizando o framework AWS SAM, que tem tornado o desenvolvimento com Lambda muito mais prático.

Graças ao modelo já estruturado do SAM, é possível disponibilizar uma API simples em questão de minutos. No entanto, como nada é perfeito, enfrentei uma dificuldade comum: criar um ambiente de testes sem impactar a produção.

A ideia de manter dois ambientes separados, mas com a capacidade de testar diferentes versões da API de forma segura, me fez buscar alternativas. Conversando com um amigo, ele sugeriu uma abordagem que resolveu meu problema de forma elegante: usar múltiplas contas da AWS com o AWS Organizations, combinadas com automação via GitHub Actions.

O AWS Organizations é um recurso da própria AWS que permite gerenciar várias contas em uma única estrutura, com controle centralizado de faturamento e permissões. Isso facilita a segmentação de ambientes e aumenta a segurança, mantendo produção e testes bem separados.

Com as contas criadas, meu primeiro passo foi gerar em cada uma delas um usuário com permissão para realizar deploys de funções Lambda. Em seguida, salvei as credenciais (ACCESS_KEY e SECRET_KEY) e configurei-as como secrets no repositório do GitHub.

Dessa forma, automatizei todo o processo de deploy com GitHub Actions. A pipeline agora possui um fluxo que ao ser iniciado, solicita o ambiente desejado e realiza o deploy na conta e ambiente apropriados — sem riscos à produção.

Para quem quiser ver isso funcionando na prática, deixo aqui o link para o repositório com o exemplo completo:

🔗SAM Deploy With Pipeline

A implementação foi simples, e o ganho de confiabilidade, segurança e agilidade no meu fluxo de trabalho foi enorme. Recomendo fortemente para quem está enfrentando os mesmos desafios!