# Playbook: Onde Rodar IA na AWS — Lambda vs Fargate vs ECS/EKS (GPU)

Escolher o compute errado para workloads de IA na AWS é o erro mais caro que equipes cometem ao escalar de protótipo para produção. Este playbook mapeia Lambda, Fargate, ECS/EKS+GPU e Bedrock contra os eixos que realmente importam — duração, GPU, padrão de tráfego e custo por token — e entrega uma árvore de decisão acionável para cada cenário.

- URL: https://fernando.moretes.com/studies/playbook-onde-rodar-ia-na-aws-lambda-fargate-eks-gpu

- Markdown: https://fernando.moretes.com/studies/playbook-onde-rodar-ia-na-aws-lambda-fargate-eks-gpu/study.md?lang=pt

- Type: Playbook

- Domain: AWS / Compute

- Date: 2025-08-20

- Tags: aws, lambda, fargate, eks, gpu, inference, bedrock, ai-compute

- Reading time: 9 min

---

Todo time começa com Lambda porque é serverless, depois descobre que modelo de 7B não cabe em 10 GB de RAM e 15 minutos de timeout. O problema não é a ferramenta — é usar a ferramenta certa para a camada certa. Este playbook resolve exatamente isso: qual compute para qual papel no seu sistema de IA.

## O que você vai conseguir decidir depois de ler isso

- Lambda é para orquestração, glue e chamar Bedrock — não para hospedar modelo pesado.
- Fargate serve APIs de inferência CPU-bound com tráfego previsível; não resolve GPU dedicada barata em escala.
- ECS/EKS+GPU é o caminho para servir open-weights em volume — mas você paga em ops, não em tokens.
- Bedrock cobra por token com zero ops; existe um volume onde self-hosted vira mais barato — faça a conta com o SEU tráfego antes de decidir.
- O eixo escondido é custo por token total (infra + ops + latência de engenharia), não apenas preço de instância.
- Agentes LLM vivem bem em Lambda; o modelo que o agente chama não.

## Referências de Escala e Limites — AWS (2024/2025)

- **Timeout máximo Lambda:** 15 minutos
- **RAM máxima Lambda:** 10 GB (sem GPU)
- **Instâncias GPU AWS (família):** p3, p4d, p5, g4dn, g5, g6, inf2, trn1
- **Bedrock — modelo base (estimativa Claude 3 Sonnet):** $3/M tokens input, $15/M tokens output (verificar pricing atual)
- **Fargate — vCPU máxima por task:** 16 vCPU / 120 GB RAM (sem GPU nativa)
- **EKS + g5.12xlarge (4x A10G 24GB):** ~$16/h on-demand; ~$5-6/h spot (estimativa)
- **Cold start Lambda (container image):** 1–5 s típico; pode chegar a 10 s+ para imagens grandes

## O modelo mental que desbloqueia tudo: separe o agente do modelo

A confusão mais comum que vejo em times de IA na AWS é tratar o sistema como um bloco monolítico e tentar encaixar tudo no mesmo compute. Um sistema de IA moderno tem pelo menos duas camadas com características completamente diferentes:

**Camada de orquestração / agente**: recebe o request, monta o prompt, chama ferramentas (search, banco, APIs externas), gerencia o estado da conversa, faz retry, loga. Essa camada é *stateless entre requests*, tem execução de segundos a poucos minutos, e o gargalo é I/O — não CPU ou GPU. Lambda foi feito para isso. Um agente esperando resposta de tool call é exatamente o padrão de espera assíncrona que Lambda trata bem, especialmente com invocação assíncrona e Step Functions para fluxos longos.

**Camada de inferência / modelo**: carrega pesos (GB a dezenas de GB), faz forward pass em GPU ou CPU vetorizada, retorna tokens. Essa camada é *stateful em memória* (pesos ficam carregados), tem latência de centenas de ms a minutos dependendo do modelo, e o gargalo é compute intensivo. Lambda não tem GPU, tem limite de 10 GB de RAM e mata o processo após 15 minutos — três strikes para qualquer modelo sério.

Quando você mistura essas duas camadas no mesmo serviço, você paga o preço da camada mais cara em todos os requests, incluindo os que não precisam dela. Separe-as. Lambda orquestra. Bedrock, Fargate ou EKS+GPU servem o modelo. Essa separação é o fundamento de qualquer arquitetura de IA que escala sem surpresa na fatura.

## O eixo escondido: custo por token total, não preço de instância

Quando alguém me mostra uma planilha comparando Bedrock com self-hosted e conclui que self-hosted é 10x mais barato, minha primeira pergunta é: você incluiu o custo de engenharia?

Bedrock cobra por token. Você não gerencia cluster, não configura autoscaling de GPU, não lida com driver CUDA, não monitora utilização de VRAM, não faz upgrade de versão de modelo. Para um time de 3 engenheiros construindo um produto, o custo de 2 semanas de um engenheiro sênior configurando EKS+GPU em produção pode superar meses de diferença de preço de token.

**A conta que você precisa fazer:**

```
Custo total Bedrock = tokens × preço/token

Custo total self-hosted = 
  (horas de GPU × preço/hora)
  + (horas de engenharia setup × custo/hora)
  + (horas de engenharia manutenção/mês × custo/hora × meses)
  + (custo de incidente quando o cluster cai às 3h)
```

O break-even real depende do seu tráfego, do modelo escolhido e da maturidade de MLOps do seu time. Para a maioria dos produtos em estágio inicial ou médio, Bedrock vence no custo total mesmo sendo mais caro por token. O ponto de inflexão geralmente aparece quando você tem tráfego alto e previsível o suficiente para justificar Reserved Instances ou Savings Plans em GPU, e um time de plataforma dedicado para absorver o overhead operacional.

Uma estimativa conservadora: se você está gerando menos de 500 milhões de tokens por mês com um modelo equivalente a Claude Haiku ou Llama 3 8B, o overhead operacional de self-hosted provavelmente anula a economia de token. Acima de 2-5 bilhões de tokens/mês com tráfego estável, a conversa muda. Faça a conta com seus números reais.

## Matriz de Decisão: Lambda vs Fargate vs EKS+GPU vs Bedrock

### AWS Lambda

**Pros**
- Zero infra para gerenciar; escala para zero automaticamente
- Ideal para orquestração de agente, glue code, chamar Bedrock/APIs externas
- Custo zero quando não há tráfego; ótimo para spikes imprevisíveis
- Integração nativa com Step Functions, SQS, EventBridge para fluxos assíncronos

**Cons**
- Sem GPU; RAM máxima 10 GB; timeout máximo 15 minutos
- Cold start pode ser problema para latência P99 em imagens grandes
- Não serve modelo pesado; não faz inferência local de LLM
- Custo por invocação pode surpreender em tráfego muito alto e constante

**Verdict:** Use para orquestração, agente, glue, webhooks, chamar Bedrock. Nunca para hospedar modelo.

### AWS Fargate (ECS/EKS)

**Pros**
- Serverless de container: sem gerenciamento de nó EC2
- Sem cold start de Lambda; container fica quente enquanto task está rodando
- Bom para API de inferência CPU-bound (modelos pequenos, embeddings, reranking)
- Isolamento de task por request; boa superfície de segurança

**Cons**
- Sem suporte a GPU nativa (Fargate não tem instâncias GPU)
- Mais caro que Lambda para tráfego muito spiky (paga por task ativa)
- Scale-to-zero mais lento que Lambda; latência de scale-out em minutos
- Para GPU você precisa de ECS/EKS com EC2, não Fargate puro

**Verdict:** Use para workers de RAG, APIs de embedding, serviços de reranking CPU, microserviços de IA sem GPU.

### ECS / EKS + GPU (EC2)

**Pros**
- Acesso a toda família de GPU AWS: g4dn, g5, p4d, p5, inf2, trn1
- Menor custo por token em volume alto com Reserved Instances ou Spot
- Controle total: modelo, versão, quantização, batching strategy
- Suporte a frameworks: vLLM, TGI, TensorRT-LLM, Triton

**Cons**
- Alto overhead operacional: cluster, drivers CUDA, autoscaling de GPU, monitoramento de VRAM
- Custo fixo alto mesmo com tráfego baixo (instância GPU rodando)
- Não adequado para protótipo ou tráfego imprevisível
- Requer MLOps maturity: CI/CD de modelo, rollback, A/B serving

**Verdict:** Use quando volume justifica a operação: >500M tokens/mês, tráfego estável, time de plataforma disponível.

### Amazon Bedrock

**Pros**
- Zero ops: sem cluster, sem driver, sem autoscaling para gerenciar
- Acesso a modelos frontier (Claude, Titan, Llama, Mistral, Stable Diffusion)
- Escala automática; sem cold start de modelo; SLA da AWS
- Custo total baixo para volumes pequenos e médios quando ops é incluído

**Cons**
- Custo por token mais alto que self-hosted em volume muito grande
- Sem controle de versão de modelo (AWS pode deprecar); sem fine-tuning arbitrário
- Dados saem do seu VPC para o endpoint Bedrock (considerar PrivateLink)
- Rate limits por conta/região; pode ser gargalo em burst alto

**Verdict:** Default para a maioria dos produtos até o volume justificar self-hosted. Combine com Lambda para orquestração.

## Comparação por Eixos Práticos de Workload de IA
| Critério | Eixo | Lambda | Fargate | EKS + GPU | Bedrock |
| --- | --- | --- | --- | --- | --- |
| Padrão de tráfego ideal | Spiky / imprevisível | Constante / previsível | Alto volume / estável | Qualquer (gerenciado pela AWS) | — |
| Duração máxima de execução | 15 min (hard limit) | Ilimitada (task ativa) | Ilimitada (pod ativo) | Depende do modelo (streaming disponível) | — |
| Suporte a GPU | ❌ Não | ❌ Não (Fargate puro) | ✅ Sim (g4dn, g5, p4d, p5, inf2, trn1) | ✅ Sim (gerenciado) | — |
| Custo em baixo tráfego | ⭐ Melhor (escala a zero) | Médio (task mínima rodando) | Alto (GPU ociosa = $ queimando) | ⭐ Bom (paga só o que usa) | — |
| Custo em alto volume | Médio-alto (por invocação) | Médio (por vCPU/GB-hora) | ⭐ Melhor (RI/Spot + batching) | Alto (preço por token não cai com volume) | — |
| Overhead operacional | ⭐ Mínimo | Baixo-médio | Alto (cluster, CUDA, autoscaling, VRAM) | ⭐ Zero (AWS gerencia) | — |
| Cold start / latência de warmup | 1–10 s (imagem container) | 30 s – 2 min (nova task) | Minutos (novo nó GPU) | ~100–500 ms (modelo já carregado) | — |
| Caso de uso primário de IA | Agente, orquestração, chamar Bedrock | API de embedding, reranking, RAG worker | Servir LLM open-weights, batch inference | Inferência de modelo frontier, protótipo, produção sem ops | — |

## Quando cada camada faz sentido: os padrões reais

**Padrão 1 — Agente com Bedrock (o mais comum e correto para 80% dos casos)**

Lambda recebe o request do usuário, monta o contexto, chama `bedrock:InvokeModel` ou `bedrock-runtime:InvokeModelWithResponseStream`, processa a resposta, chama ferramentas se necessário (outras Lambdas, APIs, DynamoDB), e retorna. Para fluxos que excedem 15 minutos ou têm muitos passos, Step Functions Express Workflows são o complemento natural. Custo: Lambda + Bedrock por token. Ops: zero. Time to market: dias.

**Padrão 2 — RAG Service com Fargate**

Um serviço de RAG que recebe query, faz embedding (modelo pequeno como `all-MiniLM` ou `bge-small`), busca no OpenSearch/pgvector, faz reranking, e retorna contexto. Esse serviço roda bem em Fargate com 4-8 vCPU e modelos de embedding em CPU. O modelo de embedding de 80-400 MB cabe confortavelmente em memória e não precisa de GPU para latência aceitável em throughput moderado. Custo: Fargate por vCPU/hora. Ops: baixo (ECS service com ALB e autoscaling por CPU).

**Padrão 3 — Self-hosted LLM em EKS+GPU**

Você tem um modelo open-weights (Llama 3 70B, Mistral, Qwen) e tráfego suficiente para justificar a operação. Você roda vLLM ou TGI em pods com `nvidia.com/gpu: 1` no EKS, com Karpenter para provisionar nós GPU sob demanda e escalar para zero quando o tráfego cai (cuidado: scale-to-zero em GPU tem latência de 3-8 minutos para novo nó). Você usa Spot Instances para batch e On-Demand para real-time. O autoscaling é por métrica customizada (tokens/segundo, tamanho de fila) não por CPU. Custo: GPU hora + ops. Ops: alto. Requer: CUDA drivers no AMI, node selector/taints no Kubernetes, monitoramento de VRAM, graceful shutdown para não perder requests em flight.

**Padrão 4 — Batch Inference Assíncrono**

Processamento offline de documentos, geração de embeddings em bulk, avaliação de dataset. Use SQS + Lambda para orquestrar, e ECS Tasks (não Fargate, use EC2 com GPU) para processar cada batch. Ou use AWS Batch com instâncias GPU para jobs de longa duração. Bedrock também tem Batch Inference API para esse caso sem precisar gerenciar nada.

## Como Tomar a Decisão: 7 Perguntas em Ordem

1. **1. Você está servindo um modelo ou orquestrando chamadas?** — Se é orquestração (agente, glue, router, webhook): Lambda ou Step Functions. Pare aqui. Se é servir modelo: continue.

2. **2. O modelo precisa de GPU?** — Modelos de embedding pequenos (< 500M params), rerankers e classificadores leves rodam bem em CPU. Qualquer LLM gerador com >1B params precisa de GPU para latência aceitável em produção. Se CPU: Fargate ou Lambda (se couber em 10 GB). Se GPU: EKS+GPU ou Bedrock.

3. **3. O modelo é proprietário/frontier ou open-weights?** — Claude, GPT-4, Titan, Stable Diffusion gerenciado: use Bedrock (ou API direta do provider). Llama, Mistral, Qwen, Falcon, modelos fine-tunados seus: self-hosted em EKS+GPU.

4. **4. Qual é o seu volume mensal de tokens?** — < 100M tokens/mês: Bedrock quase sempre vence no custo total. 100M–1B: faça a conta (inclua ops). > 1B com tráfego estável: self-hosted começa a fazer sentido financeiro. Esses são limiares orientativos — use seus números reais.

5. **5. Qual é o padrão de tráfego?** — Spiky/imprevisível (ex: produto B2C com viral spikes): Bedrock ou Lambda+Bedrock. Constante e previsível (ex: pipeline de processamento de documentos): Fargate ou EKS+GPU com Reserved Instances. Batch/offline: AWS Batch + GPU ou Bedrock Batch API.

6. **6. Seu time tem capacidade operacional para GPU?** — EKS+GPU requer: alguém que entenda Kubernetes, CUDA, autoscaling por métrica customizada, monitoramento de VRAM, e esteja disponível para incidente às 3h. Se não tem esse perfil no time hoje, não comece com EKS+GPU. Bedrock ou SageMaker Endpoints são o caminho.

7. **7. A inferência dura mais de 15 minutos?** — Geração de vídeo, processamento de documento longo, batch de embeddings: não use Lambda diretamente. Use SQS + Lambda para enfileirar + ECS Task ou AWS Batch para processar. Ou Step Functions com callback pattern para fluxos longos com Lambda.

## Árvore de Decisão de Compute para IA na AWS

Fluxo de decisão do request de IA até o compute correto. Leia de cima para baixo seguindo as condições.

### 🚦 Entry

- AI Workload Request (user)

### 🔀 Decision Layer

- Servindo modelo ou orquestrando? (compute)
- Precisa de GPU? (compute)
- Open-weights ou frontier? (compute)
- Volume > 500M tokens/mês? (compute)
- Tráfego estável e time de ops? (compute)
- Duração > 15 min? (compute)

### ✅ Compute Targets

- Lambda + Step Functions (compute)
- Fargate ECS CPU inference (compute)
- Amazon Bedrock Managed inference (ai)
- EKS + GPU (g5/p4d/inf2) (compute)
- AWS Batch + GPU / SQS (compute)

### 📦 Model Layer

- Bedrock API Claude/Titan/Llama (ai)
- vLLM / TGI open-weights (ai)
- Embedding Model CPU (MiniLM/BGE) (ai)

### Fluxos

- req -> q1
- q1 -> lambda: Orquestração / agente
- q1 -> q2: Servindo modelo
- q2 -> q6: Não (CPU)
- q2 -> q3: Sim (GPU)
- q6 -> fargate: < 15 min
- q6 -> batch: > 15 min
- q3 -> bedrock: Frontier (Claude, Titan...)
- q3 -> q4: Open-weights
- q4 -> bedrock: < 500M tok/mês
- q4 -> q5: > 500M tok/mês
- q5 -> bedrock: Sem ops / spiky
- q5 -> eksgpu: Estável + ops disponível
- lambda -> bedrockapi: InvokeModel
- bedrock -> bedrockapi
- eksgpu -> vllm
- fargate -> embed

> **Anti-padrão: Jogar tudo em Lambda 'porque é serverless':** Este é o erro mais frequente que vejo em times que estão começando com IA na AWS. O raciocínio é: 'Lambda é serverless, escala automaticamente, não preciso gerenciar servidor — vou colocar o modelo aqui também.' O resultado é uma Lambda com imagem de 8 GB tentando carregar um modelo de 4 GB em RAM, cold start de 30 segundos, timeout estourando em requests longos, e custo por invocação absurdo porque a função fica no limite de memória.

**O que acontece na prática:**
- Modelo de 7B quantizado em INT4 precisa de ~4 GB de VRAM. Lambda não tem VRAM. Em CPU, precisa de ~4-8 GB de RAM e leva 30-120 segundos para gerar 200 tokens. Isso não é produção.
- Cold start de Lambda com imagem de 8 GB pode levar 10-15 segundos só para inicializar o container, antes de carregar o modelo.
- O timeout de 15 minutos parece muito até você ter um usuário com prompt longo e contexto de 32K tokens.
- Você paga por GB-segundo. Uma Lambda de 10 GB rodando por 5 minutos custa ~$0.083 por invocação — compare com uma chamada Bedrock Claude Haiku que custa frações de centavo.

**A regra:** Lambda é para chamar o modelo, não para ser o modelo. Use Lambda para orquestrar, fazer glue, chamar Bedrock ou seu endpoint de inferência. O modelo fica em outro lugar.

> **Regra de Bolso:** **Lambda orquestra. Bedrock infere. EKS+GPU escala em volume. Fargate preenche o meio.**

Ou, mais direto: se você está escrevendo código que chama um modelo, use Lambda. Se você está escrevendo código que É o modelo, use outra coisa. E antes de montar cluster de GPU, faça a conta do custo total — token price × volume versus (GPU hora × horas) + (engenheiro × horas). Na maioria dos casos até 500M tokens/mês, Bedrock ganha quando você inclui ops na equação.

> **Minha Perspectiva Sênior:** Depois de 16 anos construindo sistemas distribuídos — incluindo plataformas financeiras onde cada centavo de custo operacional é auditado — o que me impressiona nos projetos de IA é como times experientes repetem os erros de 2012 com microserviços: escolhem a tecnologia mais 'poderosa' antes de entender o padrão de acesso.

Minha abordagem padrão hoje: começo com **Lambda + Bedrock** para qualquer coisa nova. Zero ops, tempo de mercado em dias, custo proporcional ao uso real. Quando o produto encontra tração e o volume de tokens começa a aparecer na fatura de forma significativa, aí faço a análise de break-even com os números reais do sistema — não estimativas de planilha.

Para a maioria dos produtos que acompanhei, esse momento de break-even vem depois de escala significativa, e quando chega, o time já tem maturidade operacional para lidar com EKS+GPU de forma responsável. Tentar pular essa etapa 'para economizar' geralmente resulta em gastar mais em engenharia do que se teria gasto em tokens.

O único caso onde eu pulo direto para self-hosted é quando há requisito regulatório de que os dados não podem sair do ambiente controlado (ex: dados de saúde, financeiro com PII sensível) e PrivateLink + Bedrock não é suficiente para o compliance. Nesse caso, EKS+GPU com modelo open-weights dentro do VPC é a resposta — mas a decisão é de compliance, não de custo.

Uma coisa que raramente vejo nos documentos de arquitetura: o custo do tempo de engenharia de configurar e manter GPU em produção é real e recorrente. Coloque isso na planilha antes de apresentar a decisão.

## Veredito

Não existe compute de IA correto — existe compute correto para o papel, o volume e a maturidade operacional do seu time hoje. Lambda é o melhor orquestrador de agente que existe na AWS; é um péssimo servidor de modelo. Bedrock é a escolha racional para a maioria dos produtos até escala significativa, porque o custo real inclui ops, não só tokens. EKS+GPU é poderoso e caro de operar — use quando o volume justifica e o time está pronto, não como primeiro passo. Fargate preenche o espaço do meio para serviços de IA CPU-bound que precisam de mais do que Lambda oferece sem a complexidade de GPU. A decisão certa é a que você consegue operar, escalar e depurar às 3 da manhã — não a que parece mais impressionante no diagrama.

## Referências

- [AWS Lambda — Product Page](https://aws.amazon.com/lambda/)
- [AWS Fargate — Product Page](https://aws.amazon.com/fargate/)
- [Amazon EKS — Product Page](https://aws.amazon.com/eks/)
- [Amazon Bedrock — Pricing](https://aws.amazon.com/bedrock/pricing/)
- [AWS — GPU / Accelerated Computing Instance Types](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)

## Fontes do caso

- [AWS Lambda](https://aws.amazon.com/lambda/)
- [AWS Fargate](https://aws.amazon.com/fargate/)
- [Amazon EKS](https://aws.amazon.com/eks/)
- [Amazon Bedrock — Pricing](https://aws.amazon.com/bedrock/pricing/)
- [AWS — GPU instances (Accelerated computing)](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)