AWS

Como reduzir custos de AWS Lambda: cold start, memória e Provisioned Concurrency

Guia prático para arquitetos e times de plataforma: auditar funções Lambda, dimensionar memória, Graviton e quando Provisioned Concurrency compensa — ou não.

LambdaAWSCost OptimizationFinOps

Lambda parece barato até a fatura chegar. O custo vem de invocações, GB-segundo, Provisioned Concurrency e efeitos colaterais (API Gateway, logs, data transfer). Este guia organiza uma auditoria que aplico antes de sugerir Provisioned Concurrency — nem sempre ela é a resposta.

Como a AWS cobra Lambda

ComponentePreço de referência (us-east-1)O que pesa
Invocações~US$ 0,20 / 1MAPIs de alto volume
Duração~US$ 0,0000166667 / GB-sMemória × tempo
Provisioned ConcurrencyCobrança por GB-s provisionadoBaseline sempre quente
Ephemeral storageAcima de 512 MBI/O temporário pesado

Memória aloca CPU proporcional. Aumentar MB muitas vezes reduz duração total — o custo final pode cair mesmo com mais GB-s nominal.

Passo 1: auditar funções

Liste funções acima de 128 MB e exporte métricas:

aws lambda list-functions \
  --query 'Functions[].[FunctionName,MemorySize,Architectures[0]]' \
  --output table

No CloudWatch (14 dias), por função crítica:

  • Duration (p50, p95, p99)
  • Errors e Throttles
  • InitDuration (indica cold start)
  • ConcurrentExecutions

Passo 2: right-sizing de memória

Método prático:

  1. Escolha a função mais cara (custo ≈ invocações × duração × memória).
  2. Teste em staging: 128 → 256 → 512 → 1024 MB.
  3. Meça custo por 1000 invocações (não só duração).
  4. Fixe o ponto onde p95 de latência estabiliza sem pagar memória ociosa.

Ferramentas como Lambda Power Tuning (open source) automatizam esse sweep.

Passo 3: arquitetura arm64 (Graviton)

Para runtimes compatíveis (Node 16+, Python 3.9+, Java 11+), arm64 costuma entregar ~20% de economia com rebuild/deploy. Valide dependências nativas (sharp, bcrypt, etc.) antes de migrar produção.

Passo 4: reduzir cold start (sem PC)

Antes de Provisioned Concurrency:

  • Pacote menor — tree-shaking, layers enxutos, evitar deps desnecessárias.
  • SnapStart (Java) onde disponível.
  • Warmup controlado — só se latência p99 for crítica e tráfego previsível (cuidado: warmup mal feito vira custo fixo oculto).

Passo 5: quando Provisioned Concurrency compensa

Use PC quando todas forem verdadeiras:

  • Latência p99 por cold start afeta receita ou SLA contratual.
  • Tráfego relativamente estável (não vale para função esporádica).
  • O custo de PC foi comparado com alternativas (API always-on pequena, ECS Fargate mínimo).

PC não elimina cold start de forma gratuita — você paga capacidade reservada. Funções com picos raros quase sempre ficam mais baratas On-Demand puro.

Passo 6: logs e rede

  • Retenção CloudWatch Logs: 7–14 dias em dev, 30+ só onde compliance exige.
  • Evite log verboso em loop quente (custo de ingestão).
  • Lambda em VPC: custo de NAT pode superar economia na função — avalie VPC endpoints.

Calculadora de ROI

Estime economia com base em invocações, memória e duração média:

Plano de 30 dias

SemanaFoco
1Inventário + top 5 funções por custo
2Power tuning + arm64 em staging
3Deploy gradual + alarmes de erro/latência
4Revisar PC apenas nas funções com SLA rígido

Leitura complementar


Por Mauricio Nascimento de Oliveira. Valores AWS mudam por região; confira a página oficial de preços.

Publicar no LinkedIn

Abre o LinkedIn com título, início do artigo e link. Você pode editar antes de publicar.

Ver texto da publicação
Como reduzir custos de AWS Lambda: cold start, memória e Provisioned Concurrency

Lambda parece barato até a fatura chegar. O custo vem de invocações, GB-segundo, Provisioned Concurrency e efeitos colaterais (API Gateway, logs, data transfer). Este guia organiza uma auditoria que aplico antes de sugerir Provisioned Concurrency — nem sempre ela é a resposta.

👉 Leia o artigo completo: https://finopspro.com.br/blog/como-economizar-lambda

— FinOps Pro
Publicar no LinkedIn Só o link

Artigos Relacionados