Serverless: vantagens, limites e custos ocultos

Alguém na sprint de arquitetura disse "a gente bota serverless, não tem servidor pra gerenciar". Três meses depois, a fatura da AWS tinha triplicado e o time estava debugando cold starts às 2h da manhã num Lambda que teoricamente era simples. Não é história rara.

Serverless resolve problemas reais — e cria outros que o marketing não menciona. Este post é sobre os dois lados, sem cheerleading.

O que serverless realmente entrega

A premissa é legítima: você escreve uma função, o provedor cuida de tudo — provisioning, scaling, patching, disponibilidade. Não tem servidor ocioso. Você paga por execução, não por hora de instância rodando.

Para workloads com tráfego irregular, isso é genuinamente bom. Um webhook que recebe 50 chamadas por hora durante o dia e zero à noite? Serverless. Um job de processamento que roda uma vez por hora por 30 segundos? Serverless. Você não está pagando por t3.micro idle às 3h da manhã.

O scaling automático também funciona. Uma função Lambda escala para milhares de execuções paralelas sem você tocar em nada. Para picos imprevisíveis, isso tem valor real — especialmente comparado ao horror de provisionar capacidade manualmente em instâncias EC2 antes de uma campanha de marketing.

Resumindo o que funciona bem:

• Workloads event-driven: webhooks, processamento de filas, triggers de S3
• APIs com tráfego variável e imprevisível
• Jobs esporádicos: relatórios, exportações, ETL leve
• Prototipagem e MVPs: zero overhead operacional no começo

Cold start: o problema que não foi embora

Cold start é o delay que acontece quando uma função não tem uma instância quente disponível. O provedor precisa subir o container, carregar o runtime, inicializar sua aplicação — e só depois executar sua lógica.

Os números variam bastante:

Java e .NET são os piores offenders porque a JVM/CLR demora para inicializar. Se você tem um serviço de aprovação de pagamento em Java rodando no Lambda, um cold start de 5s em produção não é aceitável. O contorno mais comum — invocar a função periodicamente para mantê-la "quente" — é gambiarra com custo extra. É literalmente pagar para simular um servidor.

# "Solução" clássica de keepalive — evite chegar aqui
# EventBridge rule: rate(5 minutes) → Lambda
def handler(event, context):
    if event.get("source") == "keepalive":
        return {"status": "warm"}
    # lógica real aqui

AWS mitigou com Provisioned Concurrency, mas aí você está pagando por capacidade reservada — o que começa a se parecer com uma instância convencional, só que mais cara.

Vendor lock-in: mais fundo do que parece

O contrato implícito do serverless é mais invasivo do que parece na primeira sprint.

Sua função Lambda usa variáveis de ambiente específicas da AWS, triggers do API Gateway, integração nativa com SQS, CloudWatch Logs com a estrutura deles. Você migrar isso para Google Cloud Functions ou Azure Functions não é copy-paste — é reescrita.

O problema não é só a função em si. É o ecossistema:

• Logs: CloudWatch tem uma DSL própria. Migrar para outra plataforma significa migrar dashboards, alertas, queries de observabilidade.
• Permissões: IAM roles e policies são específicas da AWS. A granularidade de permissão no GCP é diferente.
• Triggers nativos: um trigger de S3 que chama Lambda não tem equivalente direto em outras nuvens.

Isso não é motivo para não usar serverless. É motivo para ser deliberado sobre onde você usa. Uma função de background job com I/O simples tem lock-in tolerável. Uma arquitetura inteira de microsserviços serverless com dezenas de funções interligadas por serviços nativos do provedor — aí o lock-in se torna dependência estrutural.

Para uma visão mais ampla sobre como os modelos de cloud se comparam nesse aspecto, o post cloud pública, privada e híbrida tem a perspectiva estratégica que complementa este.

Os custos que a calculadora não mostra

O marketing foca no custo por execução. O problema é que execução é só uma linha da fatura.

Egress e transferência de dados

Cada vez que sua função Lambda chama um serviço externo ou retorna dados, há potencial custo de transferência. Dentro da mesma região, muita coisa é gratuita. Mas se sua função processa imagens e retorna dados para um CDN em outra região, ou integra com um banco RDS em outra AZ, o egress aparece.

Observabilidade

Lambda + CloudWatch Logs é gratuito até certo ponto. Mas se você tem funções em produção com alto volume, o custo de logs e métricas detalhadas escala. X-Ray (tracing distribuído) cobra por trace registrado. Para uma arquitetura com 20 funções se chamando, o custo de observabilidade pode ser comparável ao custo de execução.

Custo por execução em alta escala

A promessa "pague pelo uso" vira armadilha quando o uso é alto e constante. Lambda cobra por GB-segundo. Uma função com 512MB de memória rodando por 1 segundo custa $0,0000083325. Parece pouco. Mas 10 milhões de execuções por mês = ~$83. 100 milhões = ~$830. Uma instância EC2 t3.medium (2 vCPU, 4GB) custa ~$30/mês.

Break-even aproximado (Lambda 512MB vs t3.medium $30/mês):
30 / 0,0000083325 ≈ 3,6 milhões de execuções/mês de 1s cada

Acima disso: EC2 pode ser mais barato.

Isso não considera que EC2 precisa de ops, auto-scaling configurado, etc. Mas o ponto é: serverless não é barato na alta escala, é barato na baixa e média escala com tráfego irregular.

O custo de debugging

Funções serverless são mais difíceis de debugar localmente. Você não tem um processo rodando que você pode attachar um debugger. Reproduzir um problema que acontece em produção requer simular o ambiente de execução, variáveis de ambiente, permissões IAM — e mesmo assim não é garantia.

Quando não usar serverless

Casos onde serverless piora as coisas:

Workloads com conexão persistente a banco de dados. Lambda abre e fecha conexões a cada execução. Com RDS PostgreSQL, isso significa connection pool problemático. A solução é RDS Proxy — que tem custo adicional e adiciona latência.

Aplicações com estado em memória. Se sua lógica depende de cache local, sessão em memória ou estado acumulado entre requisições, cada instância de função começa do zero. Você precisa externalizar esse estado para Redis ou DynamoDB, adicionando latência e custo.

Processamento de longa duração. Lambda tem timeout de 15 minutos. Se seu job de processamento de dados às vezes leva 20 minutos dependendo do volume, você tem um problema estrutural.

Serviços com latência crítica e tráfego constante. Para APIs que recebem tráfego constante e têm SLA de latência, o cold start e o custo de Provisioned Concurrency fazem uma instância convencional ser mais simples e mais barata.

Perguntas frequentes

Serverless e containers são concorrentes?

Não necessariamente. Muitas arquiteturas usam os dois: containers para serviços com tráfego constante e estado, funções serverless para jobs event-driven e processing assíncrono. O Lambda atualmente suporta execução de containers, então a linha ficou ainda mais tênue. A escolha é sobre padrão de acesso e workload, não sobre ideologia.

Cold start ainda é um problema em 2026?

Melhorou, mas não resolveu. AWS SnapStart (para Java) reduziu cold starts de segundos para centenas de milissegundos em muitos casos. Runtimes mais leves como Node.js e Python têm cold starts toleráveis para a maioria dos casos. O problema persiste para runtimes pesados e para funções com pacotes de dependências grandes. Se latência é crítica e tráfego é irregular, Provisioned Concurrency resolve — mas tem custo.

É possível testar serverless localmente?

Sim, mas com fricção. AWS SAM CLI e LocalStack simulam o ambiente. O problema é que a fidelidade não é 100%: comportamentos de retry, limites de timeout, comportamento de cold start real — esses detalhes só aparecem no ambiente real. Para desenvolvimento, isso adiciona overhead que uma API convencional não tem.

Por que minha fatura explodiu sem eu saber?

Serverless não tem teto de custo por padrão. Um loop mal configurado ou um ataque de DDoS que dispara suas funções pode gerar uma fatura gigante antes de você perceber. AWS tem AWS Cost Anomaly Detection e você pode configurar orçamentos com alertas — mas é responsabilidade sua configurar. Por padrão, não tem limitador.

O tradeoff que vale a pena entender

Serverless não é melhor nem pior que containers ou instâncias. É uma troca diferente: você abre mão de controle e previsibilidade em favor de zero overhead operacional e scaling automático. Isso é ótimo para os casos certos.

O problema é quando serverless é adotado como dogma arquitetural — "vamos serverless em tudo" — sem analisar o padrão de acesso de cada serviço. A conta aparece depois, junto com os cold starts e o lock-in.

Use serverless onde o padrão de acesso é irregular e o workload é stateless. Use containers ou instâncias onde o tráfego é constante, a latência é crítica ou o processamento é longo. Para verificar latências e headers de resposta das suas APIs, o HTTP Status Codes pode ser útil para entender o que está acontecendo entre cliente e função.

A decisão não é binária, e não precisa ser permanente.