Lambda vs ECS: o guia de decisão do arquiteto de compute na AWS

Pense no Lambda como um táxi por corrida: você chama, ele aparece, você paga pelo trajeto, ele some. A unidade de escala é a requisição/evento: cada invocação pode rodar num ambiente diferente, em paralelo, sem você gerenciar nada. O ECS (com Fargate ou EC2) é mais como um ônibus com linha fixa: o veículo fica de pé, aceita passageiros contínuos, e você paga pela hora do veículo, com ou sem passageiro.

Essa diferença determina quase tudo: custo em baixa carga (táxi ganha, você não paga parado), custo em alta carga constante (ônibus ganha, tarifa flat), latência de início (o ônibus já está rodando; o táxi pode demorar para chegar, cold start), e capacidade de manter estado entre chamadas (o ônibus tem porta-malas; o táxi descarta tudo ao fim da corrida).

Antes de escolher qualquer variante, responda: minha carga é event-driven e esporádica, ou contínua e previsível? Essa pergunta sozinha elimina metade das opções erradas.

1. Lambda padrão (ZIP/runtime gerenciado): o clássico. Pacote ZIP, runtime gerenciado (Node, Python, Java, Go…), até 15 min, 10 GB RAM, /tmp efêmero de 10 GB. Ideal para APIs finas, processamento de eventos, automações.

2. Lambda com imagem de contêiner: mesmo modelo de execução do Lambda padrão, mas empacotado como imagem Docker de até 10 GB. Você ganha o ecossistema de contêiner (Dockerfile, camadas, ferramentas) sem operar orquestrador. Ideal quando o time já tem pipelines de imagem ou a dependência é grande demais para ZIP.

3. Lambda@Edge / CloudFront Functions: lógica executada nos POPs da CloudFront, a centenas de milissegundos do usuário final. Use para rewrite de URL, autenticação na borda, personalização de resposta. Limitações severas de tempo e memória, não é para lógica complexa.

4. Provisioned Concurrency: pré-aquece N ambientes Lambda, eliminando cold start para aquelas N invocações simultâneas. Você paga por ambiente provisionado/hora, mesmo sem uso. Use quando p99 de latência é crítico e a carga é previsível.

5. SnapStart (Java/.NET): tira um snapshot do ambiente já inicializado e restaura a partir dele em cold starts futuros. Corta o cold start de segundos para dezenas de milissegundos em runtimes pesados. Sem custo adicional além do tempo de execução normal.

6. Lambda Managed Instances (lançado 2025): a AWS provisiona e gerencia instâncias EC2 dedicadas para rodar suas funções, lifecycle, patch, routing e autoscaling são da AWS. Libera tipos especializados (GPU, alto CPU) e até 32 GB/16 vCPUs por ambiente. Processa requisições paralelas por ambiente (melhor price-performance em carga intensa). Use para transcodificação, inferência de modelos, simulações, carga intensiva que precisa de hardware específico mas sem operar cluster.

7. Lambda MicroVMs (lançado jun/2026): sandboxes isolados com estado via Firecracker. Cada sessão tem seu próprio kernel, memória e disco, sem compartilhamento entre sessões de usuários diferentes. Preservam estado (memória, disco, processos) por até 8 horas; resume quase instantâneo via snapshot. Até 8h runtime / 16 vCPUs / 32 GB memória / 32 GB disco. Disponível em us-east-1, us-west-2, eu-west-1 e ap-northeast-1. O caso de uso central: executar código de usuário ou gerado por IA por sessão, code interpreters de agentes, sandboxes interativos, scanners de vulnerabilidade, game servers com scripts de usuário. Preenche a lacuna que o Lambda padrão (sandbox reusado, sem isolamento forte multi-tenant) e o Fargate (subir/derrubar tarefa por sessão é lento e caro) não resolviam.

1. Fargate: serverless de contêiner. Você declara CPU (0.25–16 vCPU) e memória (0.5–120 GB) por tarefa; a AWS provisiona, patcha e escala as VMs subjacentes. Você nunca vê instâncias EC2. Ideal para a maioria dos workloads: APIs long-running, workers, microserviços. Custo por vCPU-hora e GB-hora.

2. Fargate Spot: mesma experiência do Fargate, mas usando capacidade spot (interruptível). Até ~70% mais barato (estimativa de mercado). Use para batch tolerante a interrupção, processamento assíncrono, jobs de CI. Não use para APIs síncronas sem mecanismo de retry.

3. Launch type EC2 (você opera o cluster): você provisiona instâncias EC2, escolhe tipo/AMI/rede, e o ECS agenda contêineres nelas. Controle máximo: GPUs, instâncias reservadas, customização de rede. Melhor custo em escala constante e alta (você amortiza a reserva). Mas você opera: patching, capacity planning, on-call de instância.

4. ECS Managed Instances (lançado set/2025): híbrido. Você especifica o tipo de instância desejado (incluindo GPU); a AWS gerencia o lifecycle das instâncias (provisioning, patching, replacement). Você ganha a flexibilidade de EC2 com a operação no estilo Fargate. Ideal quando Fargate não tem o hardware que você precisa mas você não quer operar o cluster.

5. ECS Anywhere (External): roda contêineres on-premises ou em outro cloud usando o mesmo control plane do ECS. Útil para híbrido regulatório ou edge computing. Cite de passagem, não é o caso comum.

Capacity Providers e estratégias mistas: capacity providers desacoplam 'onde rodar' da definição da tarefa. Você pode ter até 20 providers numa estratégia, ex.: baseline em EC2 reservado (custo baixo) + overflow em Fargate (escala elástica). Essa é a forma recomendada pela AWS hoje, em vez de launch types fixos. O resultado: você paga pelo que usa, com o hardware certo, sem superprovisionar.

1. Padrão de carga: event-driven, esporádico, com picos imprevisíveis → Lambda. Long-running, conexões persistentes (WebSocket, gRPC), streaming → ECS. Essa é a pergunta mais importante.

2. Duração: mais de 15 minutos mata o Lambda padrão. Use Fargate, ECS EC2 ou Lambda MicroVMs (até 8h) para jobs longos.

3. Estado e isolamento: precisa de memória/disco por sessão com isolamento forte entre usuários diferentes → Lambda MicroVMs. Precisa de estado simples entre chamadas → use um store externo (DynamoDB, ElastiCache) com Lambda padrão. Processo contínuo com estado em memória → Fargate.

4. Throughput e custo: abaixo de ~50.000–150.000 req/dia (estimativa de mercado, não número oficial da AWS), o scale-to-zero do Lambda domina em custo. Acima disso, o flat-rate do Fargate, especialmente em ARM64/Graviton, tende a ser mais econômico. Faça a conta para o seu perfil real.

5. Custo de inicialização (novo desde ago/2025): a fase INIT do Lambda agora é cobrada em cada cold start. Inicialização pesada, carregar modelo de 500 MB, montar pool de conexões, aquecer cache, agora tem custo direto a cada cold start. No Fargate, a inicialização ocorre uma vez por tarefa e é amortizada ao longo de horas. Isso muda o cálculo para workloads com init caro e alta taxa de cold start: Provisioned Concurrency, SnapStart ou Fargate quente podem ser mais econômicos que Lambda padrão nesses casos.

Usando o Architecture Elevator de Gregor Hohpe: a decisão de compute parece técnica, mas seus efeitos sobem todos os andares.

Andar de engenharia: Lambda reduz a carga operacional drasticamente, sem cluster para operar, sem on-call de instância, blast radius menor (uma função quebrada não derruba o serviço inteiro). ECS EC2 exige capacity planning, patching e on-call de infra. Fargate fica no meio: você opera a imagem, não a instância.

Andar de negócio: Lambda acelera time-to-market para features novas, deploy de função é minutos. O TCO (custo total de propriedade) é menor em cargas esporádicas; em cargas constantes e altas, Fargate/EC2 com Graviton/ARM64 pode ser 30-50% mais barato (estimativa de mercado). A decisão errada queima dinheiro: um cluster ECS sempre de pé para um job que roda 3 vezes por dia pode custar 10× mais que Lambda para o mesmo resultado.

Andar do cliente (o que mais importa): cold start de Lambda padrão numa API de checkout: 2-4 segundos em Java sem SnapStart, é percebido pelo usuário como lentidão e aumenta abandono de carrinho. Fargate quente entrega latência consistente de p99. Por outro lado, Lambda com Provisioned Concurrency ou SnapStart entrega p99 comparável ao Fargate para APIs críticas, com custo menor em baixa carga. A regra de ouro: casa a unidade de escala com o padrão de carga → cliente não percebe a infra, que é o objetivo.