AWS Lambda: o sonho de consumo de muitas pessoas. Claro que, geralmente, é como uma paixão. Parece ser perfeito no primeiro momento. Porém, com o tempo, você vai descobrindo que existem desafios. E desafios que, muitas vezes, você nem conhecia, porque até então estava acostumado com uma arquitetura mais tradicional, com servidores ou containers.
Apesar de muitos dizerem “serverless é demais porque você não gerencia servidores”, ele nos dá a impressão de que realmente você não precisa fazer nada. Parece que tudo é infinito. Mas a realidade é: as coisas são finitas.
Se é finito, logo, temos que gerir coisas que antes não precisávamos. Não é mais sobre comprar e configurar servidores, mas sobre entender os limites da plataforma e projetar sua aplicação com isso em mente.
Nessa matéria, quero te mostrar 10 cuidados essenciais ao usar AWS Lambda.
1. Recurso é finito: Concurrency Limits
Lambda escala, mas até um certo ponto. Existem soft limits (limites por conta que podem ser ajustados) e limites de concorrência reservada. Esses valores precisam ser monitorados e, quando necessário, reservados para garantir que funções críticas não fiquem sem capacidade de execução.
Exemplo: um e-commerce em dia de promoção especial teve falhas no checkout porque uma função Lambda que processava pagamentos bateu no limite de concorrência da conta e começou a sofrer throttling.
2. Tempo de aquecimento: Provisioned Concurrency
Ao invocar um Lambda pela primeira vez (ou depois de um tempo inativo), ele precisa ser “aquecido”. Esse tempo de inicialização (cold start) pode ser um problema em workloads sensíveis. Usar Provisioned Concurrency é uma forma de manter funções sempre prontas.
Exemplo**:** uma API de login que não usava provisioned concurrency sofria atrasos de 1 segundo no primeiro acesso do usuário após um período ocioso — o que comprometia a experiência.
3. Idle Time: Cuidado com esperas desnecessárias
Ficar esperando dentro de um Lambda (como em um loop esperando uma instância EC2 subir) pode sair caro. Você paga por milissegundo. Nesses casos, prefira processamento assíncrono com filas e delays.
Exemplo: um Lambda que checava status de serviços externos com sleep() gerava custos altos. A solução foi substituí-lo por eventos agendados via EventBridge para fazer o polling.
4. Memória vs. CPU: Nem sempre mais é melhor
No Lambda, quando você aumenta a memória, ganha também mais CPU e rede. Mas isso não significa que mais memória trará mais performance. Use ferramentas como o Lambda Power Tuning para encontrar o melhor custo-benefício.
Exemplo: uma função com 3GB de memória custava o triplo e rodava quase no mesmo tempo que a mesma função com 1.5GB, segundo o Power Tuning. O ajuste economizou 40% no custo.
5. Retries automáticos e comportamento em erros
Lambdas assíncronos têm retries automáticos por padrão (normalmente 2). Se você não quer esse comportamento, é preciso configurar corretamente ou usar DLQ e idempotência para evitar efeitos colaterais.
Exemplo: um sistema de envio de e-mails estava disparando mensagens duplicadas porque não tratava corretamente retries automáticos. O uso de DLQ e idempotência resolveu o problema.
6. Um Lambda pode concorrer com o limite da conta
Se você tem várias funções rodando ao mesmo tempo, todas elas compartilham o limite de concorrência da conta. Sem controle, uma função pode afetar a outra. Use reserved concurrency e account limit monitoring.
Exemplo: um Lambda de processamento em lote derrubou outras APIs críticas porque consumiu toda a concorrência disponível da conta. Reservar limites teria evitado.
7. Observabilidade complexa
Não é tão simples monitorar um Lambda quanto uma instância EC2. Mesmo com ferramentas como X-Ray e CloudWatch Logs, a visibilidade exige mais preparo e entendimento da plataforma. Sim, é poderoso, mas requer mais atenção.
Exemplo: uma função estava falhando silenciosamente porque os logs não estavam sendo corretamente exportados e monitorados. A equipe implementou X-Ray e alarmes no CloudWatch para corrigir.
8. Pode sair mais caro que EC2 ou container
Dependendo do volume de execuções e da forma como a função é usada, Lambda pode custar mais caro que uma instância EC2 sempre ligada. A análise precisa considerar tempo de execução, memória usada e volume de invocações.
Exemplo: um crawler que rodava 24×7 foi migrado para Lambda e a conta disparou. Reverter para EC2 com agendamento via cron cortou o custo pela metade.
9. 15 minutos é o limite
Lambda não é para tudo. A execução tem um limite de 15 minutos. Se você tem workloads maiores, talvez Lambda não seja o caminho. Vale considerar Step Functions ou outras soluções.
Exemplo: uma função de ETL que processava arquivos grandes estourava o tempo de execução. Dividir o processamento em partes com Step Functions resolveu.
10. Operação mais rápida que EC2? Nem sempre
Sim, é mais simples fazer deploy, mudar runtime ou escalar. Mas quando falamos de limites, previsibilidade, latência e custo, EC2 pode ser mais fácil de controlar dependendo do contexto.
Exemplo: uma aplicação de trading de alta frequência sofria latências variáveis em Lambda. A migração para EC2 otimizou a performance com previsibilidade.
Conclusão
Lambda é uma ferramenta poderosa. Mas como toda ferramenta, exige compreensão. Entender os limites e armadilhas é o que diferencia uma arquitetura elegante de uma que vai dar dor de cabeça.
Se você quer aprender mais sobre a AWS, arquitetura serverless e sistemas resilientes, se inscreve no canal, segue a gente no Instagram e vem com a gente na jornada!
Bora aprender! 🚀
