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

Escolher entre Lambda e ECS não é sobre preferência — é sobre casar a unidade de escala com o padrão de carga. Este guia cobre todos os tipos de Lambda (incluindo MicroVMs e Managed Instances) e ECS (Fargate, EC2, Managed Instances), o framework de decisão que uso na prática e o impacto real na engenharia, no negócio e na experiência do cliente.

- URL: https://fernando.moretes.com/studies/lambda-vs-ecs-quando-usar

- Markdown: https://fernando.moretes.com/studies/lambda-vs-ecs-quando-usar/study.md?lang=pt

- Type: Guia / Deep Dive

- Domain: Serverless / Containers

- Date: 2026-06-28

- Tags: aws, lambda, ecs, fargate, serverless, containers, compute, architecture

- Reading time: 9 min

---

Você domina código, CI/CD e infraestrutura como código — mas quando o assunto é 'Lambda ou ECS?', a resposta costuma ser instintiva demais. Escolher errado custa dinheiro (cluster ocioso 24/7 para um job que roda 3 vezes por dia) ou prejudica o cliente (cold start de 4 segundos numa API de checkout). Este guia constrói o modelo mental correto: entenda a unidade de escala de cada opção, conheça cada variante disponível hoje — incluindo as novidades de 2025-2026 — e saia com um framework de decisão acionável.

## O que você vai aprender

- O modelo mental fundamental: unidade de escala de função vs. contêiner e por que isso determina quase tudo
- Catálogo completo dos tipos de Lambda — padrão, imagem de contêiner, @Edge, Provisioned Concurrency, SnapStart, Managed Instances e MicroVMs
- Catálogo completo dos tipos de ECS — Fargate, Fargate Spot, EC2, Managed Instances, ECS Anywhere e capacity providers
- Por que a fase INIT do Lambda passou a ser cobrada (ago/2025) e o que isso muda no cálculo de custo
- Framework de decisão: event-driven? duração? estado? isolamento? throughput? → recomendação concreta
- Impacto da decisão na engenharia, no negócio e — o que mais importa — na experiência do cliente

## Glossário rápido

- **AWS Lambda:** Serviço de compute event-driven: você sobe código (ou imagem), a AWS executa em resposta a um evento e cobra por milissegundo de execução. Sem servidor para operar.
- **Amazon ECS:** Orquestrador de contêineres gerenciado da AWS. Você define tarefas (task definitions) com imagens Docker; o ECS agenda, escala e reinicia contêineres.
- **AWS Fargate:** Camada de compute serverless para ECS (e EKS). Você declara CPU/memória por tarefa; a AWS provisiona, patcha e escala as VMs subjacentes. Você não vê instâncias EC2.
- **Capacity Provider:** Abstração do ECS que desacopla 'onde rodar' (Fargate, EC2 Auto Scaling Group) da definição da tarefa. Permite estratégias mistas: ex. 80% EC2 reservado + 20% Fargate para picos.
- **Cold Start:** Latência extra na primeira invocação de uma função Lambda quando não há ambiente pré-aquecido. Inclui download da imagem, inicialização do runtime e execução do código de init.
- **Scale-to-zero:** Capacidade de reduzir o compute a zero instâncias (e zero custo) quando não há carga. Lambda faz isso nativamente; Fargate pode fazer via escalonamento para 0 tarefas, mas há latência de cold start de tarefa.
- **MicroVM / Firecracker:** Máquina virtual ultraleve (kernel próprio, memória isolada) criada pelo Firecracker, tecnologia open-source da AWS. Lambda MicroVMs usa isso para dar isolamento de nível de VM por sessão.
- **INIT phase (Lambda):** Fase de inicialização do ambiente Lambda antes da primeira execução. Desde ago/2025, essa fase é cobrada como tempo de execução em cada cold start.

## O modelo mental: unidade de escala é tudo

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.

## Catálogo Lambda: sete sabores, um por um

**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.

## Catálogo ECS: cinco modos e o papel dos capacity providers

**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.

## Lambda padrão × Lambda MicroVMs × ECS Fargate × ECS EC2
| Critério | Dimensão | Lambda padrão | Lambda MicroVMs | ECS Fargate | ECS EC2 |
| --- | --- | --- | --- | --- | --- |
| Modelo de cobrança | Por ms de execução + req | Por ms de execução + req (sessão) | Por vCPU-hora + GB-hora por tarefa | Por instância EC2 (você paga a instância) | — |
| Granularidade de escala | Por invocação | Por sessão | Por tarefa | Por instância/tarefa | — |
| Scale-to-zero | Sim, nativo | Sim (sessão expira) | Sim (0 tarefas), com latência | Não (instância fica de pé) | — |
| Duração máxima | 15 minutos | 8 horas | Ilimitada (processo contínuo) | Ilimitada | — |
| Cold start | Sim; INIT cobrado desde ago/2025 | Sim, mas resume via snapshot (~ms) | Sim (subir tarefa: 10-30s típico) | Baixo (instância já de pé) | — |
| Estado por sessão | Não (sandbox pode ser reusado) | Sim (memória/disco por até 8h) | Sim (processo contínuo) | Sim | — |
| Isolamento multi-tenant | Sandbox reusado entre invocações | VM isolada por sessão (Firecracker) | Tarefa isolada; kernel compartilhado | Instância dedicada possível | — |
| Controle/customização | Baixo (runtime gerenciado) | Baixo-médio | Médio (imagem Docker livre) | Alto (tipo, AMI, rede) | — |
| Portabilidade | Baixa (API Lambda) | Baixa (API Lambda) | Alta (OCI image padrão) | Alta (OCI image padrão) | — |
| Carga operacional | Mínima | Mínima | Baixa (AWS gerencia infra) | Alta (você opera o cluster) | — |

## Árvore de decisão de compute

Siga as arestas respondendo cada pergunta. A recomendação final aparece nos nós terminais (hexágonos). Leia de cima para baixo.

### 🚦 Entrada / Entry

- Novo workload New workload (user)

### ❓ Pergunta 1 / Question 1

- Event-driven ou esporádico? or sporadic? (compute)

### ❓ Pergunta 2 / Question 2

- Duração > 15 min? Duration > 15 min? (compute)
- Carga constante ou streaming? Constant load or streaming? (compute)

### ❓ Pergunta 3 / Question 3

- Estado por sessão ou isolamento multi-tenant? Per-session state or multi-tenant isolation? (compute)
- Hardware especial (GPU/alto CPU)? Special hardware (GPU/high CPU)? (compute)
- Escala alta constante? Constant high scale? (compute)

### ❓ Pergunta 4 / Question 4

- Código não-confiável ou por usuário? Untrusted or per-user code? (security)
- Quer operar cluster EC2? Want to operate EC2 cluster? (compute)

### ✅ Recomendações / Recommendations

- Lambda padrão Standard Lambda (compute)
- Lambda MicroVMs (estado + isolamento) (state + isolation) (security)
- Lambda + store externo Lambda + external store (compute)
- ECS Fargate (long-running) (long-running) (compute)
- ECS/Lambda Managed Instances (GPU/CPU especial) (special GPU/CPU) (compute)
- ECS EC2 (controle total) (full control) (compute)

### Fluxos

- start -> q1: início
- q1 -> q2: Sim / Yes
- q1 -> q2b: Não (contínuo) / No (continuous)
- q2 -> q3b: Sim / Yes
- q2 -> q3: Não / No
- q3 -> q4: Sim / Yes
- q3 -> r_lambda: Não (stateless) / No (stateless)
- q4 -> r_microvms: Sim / Yes
- q4 -> r_lambda_state: Não / No
- q3b -> r_managed: Sim / Yes
- q3b -> r_fargate: Não / No
- q2b -> q3c: próxima pergunta
- q3c -> q4b: Sim / Yes
- q3c -> r_fargate: Não / No
- q4b -> r_ec2: Sim / Yes
- q4b -> r_managed: Não / No

## O framework de decisão: cinco perguntas, uma resposta

**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.

## Matriz de decisão: qual compute escolher

### Lambda padrão

**Pros**
- Scale-to-zero nativo — custo zero sem carga
- Zero operação de infra — foco total no código
- Escala automática para milhares de invocações paralelas

**Cons**
- Limite de 15 min de duração
- Cold start + INIT cobrado desde ago/2025
- Sem estado por sessão; sandbox pode ser reusado

**Verdict:** Use para APIs finas, processamento de eventos, automações, webhooks — cargas event-driven e stateless.

### Lambda MicroVMs

**Pros**
- Isolamento de nível de VM por sessão (Firecracker)
- Estado persistente por até 8h; resume via snapshot
- Simplicidade operacional de Lambda

**Cons**
- Disponível em apenas 4 regiões (jun/2026)
- Novo — ecossistema e documentação ainda amadurecendo
- Custo por sessão pode ser alto para sessões curtas e frequentes

**Verdict:** Use para code interpreters de IA, sandboxes por usuário, scanners de vulnerabilidade — onde isolamento forte + estado por sessão são obrigatórios.

### ECS Fargate

**Pros**
- Processo contínuo: sem limite de duração, conexões persistentes
- Imagem Docker padrão — alta portabilidade
- Sem operação de cluster EC2

**Cons**
- Custo por vCPU-hora mesmo com pouca carga
- Cold start de tarefa (10-30s típico) ao escalar do zero
- Menos econômico que EC2 em escala alta constante

**Verdict:** Use para APIs long-running, microserviços, workers com estado, WebSocket, gRPC, streaming — cargas contínuas sem querer operar EC2.

### ECS EC2 / Managed Instances

**Pros**
- Melhor custo em escala alta constante (instâncias reservadas)
- Acesso a hardware especializado: GPU, alto CPU, tipos customizados
- Managed Instances: flexibilidade de EC2 com operação estilo Fargate

**Cons**
- EC2 puro: você opera o cluster (patching, capacity planning)
- Maior carga operacional e on-call
- Superprovisionamento fácil se a carga for variável

**Verdict:** Use para cargas intensivas constantes (ML training, transcodificação, simulações), GPU, ou quando o custo de Fargate em escala justifica operar EC2.

## Subindo o elevador: impacto na engenharia, no negócio e no cliente

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.

## Como escolher em 60 segundos: regras de bolso

- Event-driven e esporádico → comece com Lambda padrão. Adicione Provisioned Concurrency ou SnapStart se p99 for crítico.
- Duração > 15 min → Lambda está fora. Use Fargate, ECS EC2 ou Lambda MicroVMs (até 8h).
- Código de usuário ou IA por sessão, isolamento forte obrigatório → Lambda MicroVMs.
- Long-running, WebSocket, gRPC, streaming, estado em memória → ECS Fargate.
- GPU, alto CPU, escala alta constante, controle de rede → ECS EC2 ou Managed Instances.
- Init pesado (modelo ML, pool de conexões) + alta taxa de cold start → cuidado com custo de INIT desde ago/2025; prefira SnapStart, Provisioned Concurrency ou Fargate quente.

> **Minha leitura sênior:** Depois de 16 anos tomando decisões de compute — de sistemas financeiros a plataformas de dados em tempo real — o erro que vejo com mais frequência não é escolher a tecnologia errada: é não ter um modelo mental claro sobre a unidade de escala antes de decidir. Times escolhem Lambda porque 'é serverless e moderno', e depois sofrem com cold start em APIs críticas ou com o custo de INIT em funções que carregam modelos de ML. Times escolhem Fargate porque 'é mais confiável', e depois pagam por tarefas ociosas 22 horas por dia. A pergunta certa é sempre: qual é o padrão de carga? A partir daí, a decisão quase se toma sozinha. Lambda MicroVMs e Managed Instances são adições genuinamente úteis — preenchem lacunas reais que existiam há anos. Mas não são bala de prata: MicroVMs ainda têm cobertura regional limitada e estão amadurecendo. Managed Instances fazem sentido quando você precisa de hardware específico sem operar cluster. Capacity providers no ECS são a forma correta de trabalhar hoje — estratégias mistas com baseline reservado e overflow em Fargate são o padrão que recomendo para a maioria dos sistemas com carga variável. E sim: num sistema bem arquitetado, Lambda e ECS coexistem. Não é uma escolha binária.

> **Próximo estudo: ECS vs EKS:** Você escolheu contêineres — mas qual orquestrador? No próximo estudo: ECS vs EKS — quando a simplicidade do ECS basta e quando a potência do Kubernetes justifica a complexidade operacional. Capacity providers, service mesh, multi-cluster e o custo real de operar Kubernetes em produção.

## Veredicto

Não existe 'Lambda é melhor que ECS' ou vice-versa — existe a unidade de escala certa para o padrão de carga certo. Lambda padrão vence em event-driven e stateless; Fargate vence em long-running e contínuo; Lambda MicroVMs resolve o caso específico de isolamento forte por sessão que nenhum dos dois resolvia bem; ECS EC2 e Managed Instances vencem em escala constante com hardware especializado. O framework de decisão é simples: padrão de carga → duração → estado/isolamento → throughput/custo → carga operacional do time. A mudança de cobrança da fase INIT (ago/2025) é real e muda o cálculo para funções com init pesado — não ignore. E lembre: num sistema bem arquitetado, Lambda e ECS coexistem, cada um na carga para a qual foi feito. O cliente final não sabe — e não deveria saber — qual compute está rodando. Ele só sente a latência e a disponibilidade. Essa é a métrica que importa.

## Referências

- [AWS — Decision guide: Fargate or Lambda?](https://docs.aws.amazon.com/decision-guides/latest/fargate-or-lambda/fargate-or-lambda.html)
- [AWS Blog — Run isolated sandboxes with full lifecycle control: Lambda MicroVMs](https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/)
- [AWS Blog — Introducing AWS Lambda Managed Instances](https://aws.amazon.com/blogs/aws/introducing-aws-lambda-managed-instances-serverless-simplicity-with-ec2-flexibility/)
- [Amazon ECS — Launch types and capacity providers](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/capacity-launch-type-comparison.html)
- [AWS Fargate — Product page](https://aws.amazon.com/fargate/)
- [AWS Lambda — Product page](https://aws.amazon.com/lambda/)

## Fontes do caso

- [AWS — Decision guide: Fargate or Lambda?](https://docs.aws.amazon.com/decision-guides/latest/fargate-or-lambda/fargate-or-lambda.html)
- [AWS — Run isolated sandboxes with full lifecycle control: Lambda MicroVMs](https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/)
- [AWS — Introducing Lambda Managed Instances](https://aws.amazon.com/blogs/aws/introducing-aws-lambda-managed-instances-serverless-simplicity-with-ec2-flexibility/)
- [Amazon ECS — Launch types and capacity providers](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/capacity-launch-type-comparison.html)
- [AWS Fargate](https://aws.amazon.com/fargate/)
- [AWS Lambda](https://aws.amazon.com/lambda/)