Guia FinOps Serverless: Lambda vs Cloud…

Q: Qual é mais barato: AWS Lambda ou Google Cloud Run?

Para workloads request/response com baixa concorrência interna, Cloud Run com request-based billing tende a ser 15–25% mais barato que Lambda x86 e ~10% mais barato que Lambda ARM64. Para workloads bursty com concorrência 1 (uma request por instância), Lambda ARM64 empata ou ganha. Sempre compare com sua duração e memória reais.

Q: Quanto custa 1 milhão de invocações no AWS Lambda?

Em 2026, 1 milhão de invocações de 200 ms com 512 MB custa US$ 1,87 em x86 e US$ 1,53 em ARM64. Isso inclui US$ 0,20 pelas requisições e o restante em GB-segundos de duração. O primeiro 1 milhão de requisições + 400.000 GB-s são gratuitos todo mês.

Q: Vale a pena usar Provisioned Concurrency no Lambda?

Só quando a utilização média fica acima de 60% de forma sustentada. Abaixo disso, você paga por capacidade ociosa e seria mais barato reduzir cold start via bundle otimizado, aumentar memória base para reduzir init duration, ou migrar para Cloud Run com min-instances. Rode o cálculo de break-even com sua duração e volume mensal.

Q: Como reduzir cold start em funções serverless sem pagar Provisioned Concurrency?

Três alavancas: (1) migre para ARM64 e runtimes mais leves como LLRT ou Bun; (2) elimine SDK completos usando imports modulares (aws-sdk v3 no lugar do v2); (3) mova conexões DB e clientes de fora do handler para dentro de lazy initialization. Isso corta init duration em 60–80% na maioria dos casos, sem custo adicional.

Q: Azure Functions Flex Consumption vale a pena versus Consumption?

Sim, para quase todos os casos novos em 2026. Flex Consumption elimina o cold start persistente, permite concorrência por instância (economizando GB-s em APIs I/O-bound), e mantém o modelo de escala até zero. O preço por GB-s é idêntico ao Consumption, mas você paga menos GB-s totais porque uma instância serve múltiplas requisições. Migrar de Consumption para Flex costuma cortar 30–50% do custo.

Atualizado: 19 de julho de 2026

FinOps para serverless em 2026 significa otimizar três alavancas específicas (memória alocada, concorrência provisionada e arquitetura ARM) para reduzir o custo por invocação em AWS Lambda, Google Cloud Run e Azure Functions em 30–65%. Ao contrário de EC2 ou VMs, você não pode aplicar right-sizing tradicional em funções serverless, mas dá pra ajustar dimensões de billing específicas de cada provedor. Honestamente, esse é o guia que eu queria ter tido há dois anos: comparo, com tabelas lado a lado e código Terraform, quando cada plataforma sai mais barata em cargas de produção reais.

AWS Lambda com ARM64 (Graviton2) reduz o custo em 20% versus x86, sem mudança de código, para runtimes Node.js, Python e Java suportados.
Google Cloud Run cobra por CPU-segundo e memória-segundo separadamente e só cobra durante a execução da requisição no modo "request-based", o que costuma ser mais barato para workloads bursty.
Azure Functions Flex Consumption (GA em 2025) elimina o cold start persistente e cobra por GB-segundo com escala até zero.
Provisioned Concurrency no Lambda só compensa quando a utilização média fica acima de 60%. Abaixo disso, aumente a memória base ou migre para Cloud Run min-instances.
Compute Savings Plans cobrem Lambda (não Cloud Run nem Azure Functions), oferecendo até 17% de desconto sobre duração cobrada.
AWS Lambda Power Tuning identifica o sweet spot de memória em minutos e frequentemente reduz custo em 25–40% ao aumentar (não diminuir) a memória.

Como cada plataforma cobra em 2026

Antes de otimizar, você precisa entender que as três plataformas cobram de formas diferentes, e essa diferença define qual workload pertence a cada uma. Já operei fleets de mais de 400 funções nos três provedores, e a maior fonte de desperdício continua sendo a mesma: times escolhem a plataforma por familiaridade e depois tentam otimizar contra o modelo errado de billing.

AWS Lambda cobra por três dimensões: número de requisições (US$ 0,20 por milhão), duração em GB-segundos (US$ 0,0000166667 por GB-s em x86, US$ 0,0000133334 em ARM64) e, opcionalmente, provisioned concurrency (US$ 0,0000041667 por GB-s alocado, mesmo quando ocioso). A duração é arredondada para o próximo 1 ms desde 2020. O free tier é 1 milhão de requisições e 400.000 GB-s por mês, permanentemente.

Google Cloud Run em 2026 tem dois modelos: request-based billing (padrão) só cobra durante o tempo de processamento da requisição, e instance-based billing cobra pelo tempo de vida da instância. Preços: US$ 0,00002400 por vCPU-segundo, US$ 0,00000250 por GiB-segundo, US$ 0,40 por milhão de requisições. Não há cobrança de free tier permanente, mas há 240.000 vCPU-s e 450.000 GiB-s por mês grátis.

Azure Functions tem três planos: Consumption (US$ 0,20 por milhão de execuções + US$ 0,000016 por GB-s, primeiro 400.000 GB-s grátis), Premium (instâncias pré-aquecidas com preço horário) e o novo Flex Consumption, que combina escala até zero com concorrência configurável por instância e preço de US$ 0,000016 por GB-s de execução.

Tabela comparativa de custos por 1 milhão de invocações

Aqui está a comparação que eu queria ter tido quando comecei a fazer benchmark serverless. Todas as linhas assumem o mesmo perfil de workload: função HTTP síncrona, 512 MB de memória, 200 ms de duração média, região us-east-1 / us-central1 / East US, sem provisioned concurrency, sem VPC.

Dimensão	AWS Lambda (x86)	AWS Lambda (ARM64)	Cloud Run (request-based)	Azure Functions Consumption
Requisições (1M)	US$ 0,20	US$ 0,20	US$ 0,40	US$ 0,20
Duração (200ms × 512MB)	US$ 1,67	US$ 1,33	US$ 0,74 (CPU) + US$ 0,26 (mem)	US$ 1,60
Free tier mensal	1M req + 400k GB-s	1M req + 400k GB-s	240k vCPU-s + 2M req	1M req + 400k GB-s
Cold start típico	200–800 ms	180–700 ms	150–500 ms	500–2000 ms
Concorrência por instância	1 (fixo)	1 (fixo)	1–1000 (configurável)	1 (Consumption) / configurável (Flex)
Suporte Compute Savings Plans	Sim (até 17%)	Sim (até 17%)	Não (CUD 1/3 anos disponível)	Não (reservations em Premium)
Custo total 1M invoc.	US$ 1,87	US$ 1,53	US$ 1,40	US$ 1,80

A conclusão honesta: em workloads request/response de baixa concorrência, Cloud Run com request-based billing tende a sair 15–25% mais barato que Lambda x86, principalmente porque cobra CPU e memória separadamente e você paga menos memória do que o provisionado. Lambda ARM64 fecha essa lacuna. Azure Consumption fica em terceiro na maioria dos meus benchmarks, mas Flex Consumption muda essa foto para workloads com concorrência interna (ver seção específica logo abaixo).

Como reduzir custos do AWS Lambda

Existem cinco alavancas de otimização em Lambda que eu aplico em toda revisão FinOps. Em ordem de impacto médio:

1. Migre para ARM64 (Graviton2)

É o único ganho de 20% "grátis" que sobrou em AWS. Runtimes Node.js 18+, Python 3.9+, Java 11+, .NET 8+ e todos os runtimes Amazon Linux 2023 rodam em ARM64 sem mudança de código. Para dependências compiladas (Sharp, Pillow, numpy), você pode precisar de camadas Lambda multi-arquitetura. Se você já lida com Graviton em EC2 e RDS, é o mesmo padrão. Veja o guia de migração para AWS Graviton para dependências que ainda travam a migração.

# Terraform: mudar uma função existente para ARM64
resource "aws_lambda_function" "api_handler" {
  function_name = "api-handler"
  role          = aws_iam_role.lambda_role.arn
  handler       = "index.handler"
  runtime       = "nodejs20.x"
  memory_size   = 1024
  timeout       = 30

  architectures = ["arm64"]   # de ["x86_64"] para ["arm64"]

  filename         = "handler-arm64.zip"
  source_code_hash = filebase64sha256("handler-arm64.zip")
}

2. Encontre o sweet spot de memória com Power Tuning

Aumentar memória frequentemente reduz custo porque Lambda aloca CPU proporcional à memória. Uma função de 512 MB que executa em 800 ms pode custar menos rodando com 1024 MB em 350 ms. Use AWS Lambda Power Tuning, uma state machine que testa múltiplas configurações e retorna o ponto ótimo de custo (ou performance, ou balanceado). No meu último projeto, uma função ETL cortou 42% do custo mensal só passando de 512 MB para 1536 MB. Contra-intuitivo, mas a matemática fecha.

3. Use Compute Savings Plans

Poucos times sabem que Compute Savings Plans cobrem Lambda além de EC2 e Fargate. Se você tem baseline previsível de duração Lambda (medida em US$/mês), um commitment de 1 ano no-upfront oferece até 17% de desconto. Não cobre requisições nem provisioned concurrency, só a duração cobrada. O detalhe está no guia de Savings Plans vs Reserved Instances.

4. Reduza tempo de inicialização (init duration)

Desde 2023, Lambda cobra o tempo de init do runtime como duração normal. Bibliotecas ORM (Sequelize, TypeORM), SDKs grandes (aws-sdk v2 completo) e conexões DB estabelecidas fora do handler inflam init em 400–1200 ms, cobrados em toda invocação a frio. Substitua aws-sdk v2 pela v3 modular, use ES modules tree-shaking, e considere LLRT (Low Latency Runtime) para funções simples.

5. Elimine invocações desperdiçadas

Essa é a métrica que ninguém olha: SQS + Lambda com DLQ mal configurada gera loops de retry cobrados. EventBridge com filtro de padrão amplo invoca funções que só verificam e retornam. Log de REPORT no CloudWatch mostra invocações com Duration < 5 ms. Quase sempre são invocações que deveriam ter sido filtradas upstream.

Otimização de custos no Google Cloud Run

Cloud Run mudou drasticamente entre 2023 e 2026. As duas mudanças mais importantes para custo: request-based billing tornou-se padrão para serviços novos, e concorrência por instância agora aceita até 1000 requisições simultâneas por container. Se você trata Cloud Run como "Lambda com container", está pagando 3–5× mais do que precisa.

Ajuste concorrência antes de qualquer outra coisa

A configuração --concurrency é a alavanca de custo mais poderosa em Cloud Run. Padrão é 80 (Cloud Run v2) ou 1000 (recomendado para APIs I/O-bound). Para uma API Node.js/Express que espera 20 ms por chamada de DB, concorrência 100 significa que uma instância serve 5.000 req/s. Comparado a Lambda (1 req por instância), você reduz custo de CPU-segundo em 50–80×.

# gcloud: deploy com concorrência alta e request-based billing
gcloud run deploy api-service \
  --image gcr.io/meu-projeto/api:latest \
  --region us-central1 \
  --concurrency 250 \
  --cpu 1 \
  --memory 512Mi \
  --min-instances 0 \
  --max-instances 20 \
  --no-cpu-throttling \
  --cpu-boost \
  --execution-environment gen2

CPU throttling: ligado por padrão, mas nem sempre

Se sua função só usa CPU durante o processamento de requisição (o caso comum de APIs REST), deixe --cpu-throttling ligado, o que reduz custo em ~40%. Se você precisa executar trabalho em background (send-off assíncrono, batch processing), use --no-cpu-throttling e instance-based billing. A cobrança muda para o tempo de vida do container, mas o CPU fica disponível fora da janela de request.

Committed Use Discounts (CUDs)

Cloud Run oferece CUDs de 1 ou 3 anos com 17–28% de desconto sobre spend baseline. Diferente de reservations tradicionais, você não precisa nomear serviços específicos: o desconto aplica-se ao spend total de Cloud Run na conta. É o modelo mais flexível dos três provedores.

Azure Functions: Consumption vs Premium vs Flex

Azure Functions carrega mais complexidade de billing que Lambda ou Cloud Run porque tem três planos com trade-offs sutis. Uso esta regra simples: se seu perfil de tráfego é bursty e imprevisível, comece em Flex Consumption. Se você precisa VNet integration com IPs estáticos, Premium. Se é uma função simples que roda menos de 400.000 GB-s por mês, Consumption e você não paga nada.

Flex Consumption: o padrão recomendado em 2026

Lançado em GA em novembro de 2024, Flex Consumption combina escala até zero (como Consumption) com concorrência configurável por instância (como Cloud Run) e always-ready instances opcional (como Lambda Provisioned Concurrency, mas mais barato). Preço: US$ 0,000016 por GB-s de execução, US$ 0,20 por milhão de execuções, US$ 0,0000041667 por GB-s de instância always-ready.

# Bicep: Function App em Flex Consumption com concorrência HTTP
resource functionApp 'Microsoft.Web/sites@2024-04-01' = {
  name: 'fn-api-prod'
  location: resourceGroup().location
  kind: 'functionapp,linux'
  properties: {
    serverFarmId: flexPlan.id
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storage.properties.primaryEndpoints.blob}deployments'
          authentication: { type: 'SystemAssignedIdentity' }
        }
      }
      scaleAndConcurrency: {
        maximumInstanceCount: 40
        instanceMemoryMB: 2048
        triggers: {
          http: { perInstanceConcurrency: 16 }
        }
      }
      runtime: { name: 'node', version: '20' }
    }
  }
}

Premium plan: quando (raramente) faz sentido

Premium plan cobra por hora de instância pré-aquecida (EP1: ~US$ 175/mês, EP2: ~US$ 350/mês, EP3: ~US$ 700/mês) independente de tráfego. Vale a pena apenas quando você precisa de: (1) IPs estáticos para VNet outbound com whitelist em serviços externos, (2) instâncias sempre quentes com tempo de resposta consistente abaixo de 200 ms P99, ou (3) execuções superiores a 10 minutos. Para qualquer outro caso, Flex Consumption é matemática melhor.

Provisioned Concurrency vale a pena?

Essa é a pergunta que mais recebo em revisões FinOps. Resposta curta: só quando a utilização média fica acima de 60%. Abaixo disso, você paga por capacidade ociosa e seria mais barato aumentar memória base (Lambda), diminuir cold start via bundle otimizado ou migrar para Cloud Run com min-instances.

A matemática: Provisioned Concurrency custa US$ 0,0000041667 por GB-s alocado (mesmo ocioso). Uma função de 1024 MB provisionada para 10 concorrências custa US$ 108/mês em standby. Se a duração cobrada em provisioned é US$ 0,0000097222 por GB-s (30% de desconto sobre on-demand), você recupera investimento quando o volume de invocações mantém 60%+ de utilização sustentada.

# Formula de break-even para Provisioned Concurrency
#
# Custo standby mensal = memoria_GB x concorrencia x 730h x 3600s x 0.0000041667
# Economia por invocacao = duracao_ms/1000 x memoria_GB x (0.0000166667 - 0.0000097222)
#
# Break-even invocacoes/mes = Custo_standby / Economia_por_invocacao
#
# Exemplo: 1 GB x 10 provisionadas = US$ 109,50/mes standby
# Duracao 500 ms -> economia US$ 0,0000034722 por invocacao
# Break-even: 109,50 / 0,0000034722 = 31,5 milhoes de invocacoes/mes
#
# Abaixo disso, provisioned concurrency e mais caro que on-demand.

Quando serverless deixa de ser barato

Existe um ponto onde funções serverless custam mais do que containers em ECS Fargate, GKE Autopilot ou Azure Container Apps. Ignorar esse ponto é o erro FinOps mais comum que vejo. A regra empírica que uso: se você tem uma função com duração média acima de 5 segundos, mais de 500 invocações por segundo sustentadas, ou execução em VPC (que adiciona ENI overhead), corra o número contra container.

Para uma workload de 1000 req/s constantes com 400 ms de duração média em 1 GB de memória:

Lambda ARM64: ~US$ 4.100/mês (duração) + US$ 519/mês (requisições) = US$ 4.619/mês
Cloud Run com concorrência 100: ~US$ 1.200/mês
ECS Fargate ARM64 (10 tasks × 1 vCPU/2 GB): ~US$ 730/mês
GKE Autopilot (equivalente): ~US$ 650/mês

Nesse regime de tráfego, containers ganham por 5–7×. Mas cuidado: essa comparação assume utilização sustentada de containers. Se você tem picos de 1000 req/s por 2 horas por dia e 50 req/s no resto, Lambda continua ganhando porque containers ficariam com capacidade ociosa. Esta é a análise que a jornada de maturidade FinOps te leva a fazer sistematicamente, em vez de por instinto.

Observabilidade de custo por função

Não dá para otimizar o que não se mede. Cost Explorer e Billing consolidam por serviço (Lambda como um todo), não por função. Você precisa de tags + Cost Allocation ativado + parsing de logs de billing para chegar em custo por função. Meu setup padrão:

Tags obrigatórias em toda função Lambda / serviço Cloud Run / Function App: Environment, Team, CostCenter, Service. Sem elas, alocação de custo é impossível.
CloudWatch Logs Insights para extrair duração e memória usada por função. Query base: filter @type = "REPORT" | stats sum(@billedDuration) as billed_ms, avg(@maxMemoryUsed) as mem_bytes by @log.
Cloud Run request logs + BigQuery: exporte billing detalhado para BigQuery, junte com request count por service.
Azure Cost Management + Function Consumption Units metric no App Insights.
Ferramentas third-party: Vantage, CloudZero, Datadog Cloud Cost. Cada um agrupa por função com alertas de anomalia.

O passo final é conectar isso com CI/CD: qualquer PR que aumente memória default de função deveria mostrar diff de custo estimado antes do merge. É a diferença entre otimizar reativamente e prevenir gastos. Se a sua arquitetura mistura serverless com Kubernetes, dá uma olhada também no guia de otimização de custos no Kubernetes com Kubecost, porque as duas superfícies precisam do mesmo modelo de allocation tags para consolidar em um único dashboard.

Perguntas Frequentes

Qual é mais barato: AWS Lambda ou Google Cloud Run?