Fargate vs Lambda: containers ou functions?
O Fargate roda containers serverless sem limite de tempo; o Lambda roda functions serverless de curta duração cobradas por invocação e duração.
O Lambda se destaca em cargas orientadas a eventos e de curta duração, com cobrança por requisição e custo ocioso quase zero, mas limita o tempo de execução e o tamanho do pacote. O Fargate roda containers de longa duração (com ECS ou EKS) para serviços estáveis ou de execução prolongada sem gerenciar servidores, usando suas imagens de container existentes. O Lambda favorece cargas de eventos com picos; o Fargate favorece serviços persistentes em containers.
| Fargate | Lambda | |
|---|---|---|
| Unidade | Task de container | Function |
| Duração | Sem limite rígido | Até 15 min |
| Cobrança | vCPU/memória por segundo | Por requisição + duração |
| Cold start | Inicialização da task | Rápido, mitigável |
| Melhor para | Serviços de longa duração | Orientado a eventos com picos |
Caso de uso e custo
O Lambda se encaixa em APIs, processamento de eventos e tráfego com picos, onde você paga apenas quando está rodando. O Fargate se encaixa em serviços que rodam continuamente, excedem os limites do Lambda ou já são entregues como containers. Para alta utilização estável, o Fargate (ou EC2) costuma custar menos; para cargas com picos ou muito ociosas, o Lambda vence.
Em CI e deploy
O Lambda faz deploy via imagens zip/container; o Fargate via push de imagens para o ECR mais atualizações de task-definition, tudo a partir do CI com OIDC. Qualquer um faz deploy a partir de runners gerenciados, onde runners mais rápidos encurtam o empacotamento, os builds de imagem e os rollouts.
O veredito
Cargas de curta duração, orientadas a eventos ou com picos e custo ocioso quase zero: Lambda. Serviços de longa duração baseados em containers ou qualquer coisa além dos limites do Lambda: Fargate. Muitas arquiteturas combinam os dois - Lambda para eventos e cola, Fargate para serviços persistentes.