TL;DR
O AWS Lambda é a base de arquiteturas serverless na AWS. O modelo de precificação evoluiu nos últimos 12 meses. A cobrança da fase INIT, a nova estrutura do CloudWatch e a expansão do SnapStart alteram o cálculo de custo de forma relevante.
Para ações imediatas de baixo esforço, consulte o artigo Quick Wins com AWS Lambda: 8 Otimizações Imediatas.
1. Modelo de Custo do Lambda
O custo do Lambda divide-se em três componentes: invocações, duração (compute) e recursos auxiliares como logs e storage efêmero.
MUDANÇA DE PRICING
Desde agosto de 2025, a AWS cobra a duração INIT para funções fora do SnapStart. Inclua esse custo na análise de cada função.
MUDANÇA DE PRICING
Desde maio de 2025, o CloudWatch Logs tem nova estrutura de preços por volume. Logs verbosos representam custo relevante em produção.
Memória e CPU são acoplados. A cada 1.769 MB, a função recebe 1 vCPU completo. O preço de invocações varia por região; sa-east-1 tem prêmio de 10 a 40% sobre us-east-1.
2. Otimização de Memória
A alocação de memória define o custo diretamente. CPU escala proporcionalmente à memória configurada.
RESULTADO
Lambda Power Tuning automatiza o teste de 7 configurações de memória. Reduções de 30 a 40% são comuns em funções CPU-bound.
A ferramenta testa configurações e aponta o ponto de menor custo.
A média mascara outliers que elevam o custo de forma silenciosa.
CPU adicional encurta a duração; o produto final pode ser menor.
Dependências novas alteram o perfil de consumo de CPU e memória.
3. ARM64 e Graviton2
Funções com arquitetura arm64 custam 20% menos que x86_64 com performance igual ou superior em cargas CPU-bound.
AWS CLI
aws lambda update-function-configuration \
--function-name minha-funcao \
--architectures arm64ATENÇÃO
Valide dependências nativas antes da migração. Pacotes com código C/C++ precisam ser recompilados para ARM64.
4. Cold Starts e SnapStart
Cold Start Tradicional
Fase INIT seguida de INVOKE. Em Java com Spring Boot: 3 a 10 segundos. Cobrado integralmente desde agosto de 2025.
SnapStart (2026)
Snapshot do estado inicializado reutilizado em cold starts. Fase INIT eliminada. Suporte a Java 17, Java 21, Python 3.12 e .NET 8.
NOTA
SnapStart reduz latência de cold start em até 90% para funções Java. Disponível sem custo adicional.
AWS CLI
aws lambda update-function-configuration \
--function-name minha-funcao \
--snap-start ApplyOn=PublishedVersions5. Padrões de Arquitetura que Reduzem Custo
Substituir chamadas síncronas por SNS ou SQS reduz tempo de execução e custo acumulado.
ElastiCache ou DAX elimina queries repetidas ao banco de dados, reduzindo duração média.
Processar eventos em lote reduz o número total de invocações cobradas.
Orquestração de curta duração com custo por transição de estado, não por tempo.
6. Monitoramento de Custo
Lambda Insights
Métricas de memória, duração e cold starts por função. Identifica candidatas a memory tuning.
Cost Anomaly Detection
Alertas automáticos para picos inesperados de custo Lambda em qualquer região.
AWS CLI
aws lambda update-function-configuration \
--function-name minha-funcao \
--layers arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:38Perguntas Frequentes
Vale a pena usar Provisioned Concurrency para todas as funções?
Não. Provisioned Concurrency tem custo fixo contínuo, independentemente do uso. Aplica-se a funções com SLA de latência estrito e tráfego previsível. Para funções de uso esporádico, SnapStart é mais eficiente e gratuito.
Compute Savings Plans cobrem o Lambda?
Sim. Compute Savings Plans aplicam desconto de até 17% sobre o preço on-demand do Lambda. O desconto se aplica automaticamente, sem necessidade de configuração por função. Também cobre EC2 e Fargate no mesmo compromisso.
Como calcular o ROI da migração para ARM64?
Multiplique o custo mensal atual de compute da função por 0,20. Esse é o valor de economia direta com a mudança de arquitetura. Para funções CPU-bound, adicione o ganho de performance; a função pode executar mais rápido e reduzir o custo além dos 20%.
Qual o impacto do timeout na conta?
Timeout alto permite que funções com erro consumam compute por mais tempo do que necessário. Uma função com timeout de 300 segundos pode gerar custo 20 vezes maior que a mesma função com timeout de 15 segundos, em caso de falha. Dimensione o timeout com base no P99 real observado.