# Playbook: Qual Serviço de IA da AWS Usar — A Árvore de Decisão

Bedrock, SageMaker, Amazon Q, AgentCore e self-hosted GPU resolvem problemas diferentes — mas o hype faz todo mundo começar pelo Bedrock por default. Este playbook entrega uma árvore de decisão, uma matriz de trade-offs e regras de bolso para você escolher pelo problema, não pelo modismo.

- URL: https://fernando.moretes.com/studies/playbook-qual-servico-de-ia-da-aws-usar

- Markdown: https://fernando.moretes.com/studies/playbook-qual-servico-de-ia-da-aws-usar/study.md?lang=pt

- Type: Playbook

- Domain: IA / AWS

- Date: 2026-02-10

- Tags: aws, bedrock, sagemaker, amazon-q, agentcore, genai, decision-tree, architecture

- Reading time: 9 min

---

A pergunta errada é 'qual serviço de IA da AWS é melhor?' A pergunta certa é 'qual problema estou resolvendo?' Cinco serviços, cinco contextos distintos — e a escolha errada custa meses de retrabalho, fatura inesperada ou um sistema que nunca deveria ter sido construído do zero.

## O que você vai decidir depois deste playbook

- Se você precisa treinar ou servir um modelo próprio → SageMaker AI
- Se você quer consumir um LLM/embedding pronto via API → Bedrock
- Se você está construindo um agente em produção (tools, memória, gateway, observabilidade) → Bedrock AgentCore
- Se o caso é produtividade interna sobre dados corporativos ou consoles AWS → Amazon Q
- Se volume, soberania de dados ou custo por token em escala são restrições duras → self-hosted EKS + GPU
- Como evitar os três anti-padrões mais comuns que eu vejo em projetos reais

## Referência Rápida — Serviços em Escopo

- **Serviços cobertos:** Amazon Bedrock, SageMaker AI, Amazon Q, Bedrock AgentCore, Self-hosted (EKS/EC2 GPU)
- **Domínio:** IA Generativa e ML na AWS
- **Modelo de custo Bedrock:** Pay-per-token (on-demand) ou Provisioned Throughput (capacidade reservada)
- **Modelo de custo SageMaker:** Por hora de instância (treinamento + inferência) + armazenamento S3/EBS
- **Modelo de custo Amazon Q Business:** Por usuário/mês (Lite ~$3, Pro ~$20 — verificar pricing atual)
- **Bedrock AgentCore:** GA 2025; runtime gerenciado para agentes com tools, memória, gateway e observabilidade nativa
- **Self-hosted GPU:** EC2 p4d/p5/g5 ou EKS + Karpenter; custo fixo alto, controle total

## O modelo mental que desbloqueia tudo: camadas de abstração vs. camadas de controle

Pense nos cinco serviços como um eixo único: de um lado, **máxima abstração e velocidade de entrega**; do outro, **máximo controle e eficiência de custo em escala**. Nenhum ponto do eixo é melhor que o outro — cada um é ótimo para um estágio de maturidade e um conjunto de restrições.

**Amazon Q** está no extremo da abstração: você não escreve código de IA, não gerencia modelos, não pensa em tokens. Você conecta fontes de dados, configura permissões e entrega produtividade. É o serviço certo quando o problema é *acesso a conhecimento corporativo*, não *construção de sistema de IA*.

**Amazon Bedrock** é o próximo degrau: você consome modelos de fundação via API (Anthropic Claude, Meta Llama, Mistral, Amazon Titan, Cohere, Stability AI e outros) sem gerenciar infraestrutura de inferência. O contrato é simples — você manda tokens, recebe tokens, paga por token. É o ponto de partida correto para a maioria dos casos de uso de LLM em produção.

**Bedrock AgentCore** é a camada de runtime para quando o Bedrock puro não basta: quando seu agente precisa de memória persistente entre sessões, orquestração de tools com retry e timeout, um gateway de segurança para chamadas de modelo, e observabilidade estruturada (traces, spans, métricas de latência por step). Sem o AgentCore, você constrói tudo isso na mão — e invariavelmente constrói errado na primeira vez.

**SageMaker AI** é onde você vai quando o modelo que você precisa não existe no catálogo do Bedrock, ou quando você precisa de fine-tuning com seus dados proprietários, ou quando a latência de inferência gerenciada não atende seu SLA. É uma plataforma de ML completa — experimentos, pipelines, feature store, registro de modelos, endpoints de inferência. Poderosa, mas cara em tempo de engenharia.

**Self-hosted EKS + GPU** é o extremo do controle: você opera o cluster, gerencia drivers CUDA, configura autoscaling de nós GPU, monitora utilização de VRAM. O custo por token pode ser uma fração do Bedrock em volumes altos, mas o custo operacional e o risco de disponibilidade são inteiramente seus. Faz sentido quando você tem um modelo específico que não está no Bedrock, restrições regulatórias que impedem dados saírem da sua VPC, ou volume tão alto que o pay-per-token se torna proibitivo.

## Por que o default 'vamos de Bedrock' é um atalho perigoso

O Bedrock é excelente — mas ele virou o 'React' do mundo de IA na AWS: todo mundo usa, independente do problema. Vejo três padrões de erro recorrentes em projetos reais:

**Erro 1 — Bedrock para produtividade interna que o Q já resolve.** Uma equipe passa semanas construindo um RAG customizado sobre documentação interna, integrando com Kendra ou OpenSearch, gerenciando chunking, embeddings e retrieval. O Amazon Q Business faz exatamente isso com conectores nativos para S3, SharePoint, Confluence, Salesforce e mais de 40 outras fontes — com controle de permissão baseado em IAM e grupos do Active Directory. O custo de construção não se justifica quando o produto já existe.

**Erro 2 — Bedrock puro para agentes complexos.** Você começa com um agente simples no Bedrock — uma tool, um prompt, funciona. Depois adiciona memória de sessão (você implementa no DynamoDB), depois adiciona retry em tools que falham (você implementa na aplicação), depois adiciona observabilidade (você instrumenta com X-Ray manualmente), depois adiciona rate limiting no gateway (você implementa no API Gateway). Em seis meses você construiu o AgentCore de forma artesanal, com bugs que o serviço gerenciado já resolveu. O AgentCore existe para evitar exatamente esse acúmulo de plumbing.

**Erro 3 — Self-hosted antes de validar o volume.** Times que estimam custo de Bedrock em escala e concluem que 'vai ficar caro' pulam direto para EKS + GPU sem ter validado o produto. O custo de operação de um cluster GPU em produção — com alta disponibilidade, atualizações de modelo, monitoramento de VRAM, gestão de spot interruptions — é real e contínuo. A regra: valide o produto no Bedrock, migre para self-hosted quando o custo mensal de Bedrock justificar o investimento em operação.

## Quando o SageMaker é inegociável

O SageMaker é frequentemente subestimado em discussões de GenAI porque o foco recente está em LLMs de fundação. Mas há quatro cenários onde ele é a única resposta correta:

**1. Fine-tuning com dados proprietários sensíveis.** Se você precisa adaptar um modelo com dados que não podem sair da sua conta AWS — dados médicos, financeiros, jurídicos — o SageMaker oferece treinamento dentro da sua VPC, com criptografia em repouso e em trânsito, sem que os dados trafeguem para infraestrutura de terceiros. O Bedrock oferece fine-tuning para alguns modelos, mas com menos controle sobre o ambiente de execução.

**2. Modelos que não estão no catálogo do Bedrock.** Se o seu caso de uso exige um modelo específico — um LLM de domínio especializado, um modelo de visão computacional customizado, um modelo de séries temporais para forecasting — o SageMaker é onde você treina e serve. O JumpStart acelera o ponto de partida com modelos pré-treinados de HuggingFace e outros repositórios.

**3. Pipelines de ML tradicionais com features estruturadas.** Para modelos XGBoost, redes neurais sobre dados tabulares, modelos de recomendação — o SageMaker Pipelines, Feature Store e Model Monitor formam uma plataforma coesa que o Bedrock simplesmente não cobre.

**4. Latência de inferência com SLA agressivo.** Um endpoint SageMaker dedicado (não serverless) oferece latência P99 previsível porque você controla a instância. O Bedrock on-demand tem variabilidade de latência que pode ser inaceitável para casos como scoring em tempo real de transações financeiras. O Bedrock Provisioned Throughput mitiga isso, mas a um custo fixo que frequentemente torna o SageMaker competitivo.

A armadilha do SageMaker é o overhead de operação: você gerencia endpoints, monitora drift, atualiza modelos, configura auto-scaling. Para times sem MLOps maduro, esse custo operacional é subestimado sistematicamente.

## Comparação Direta: Os 5 Serviços em 6 Dimensões
| Critério | Dimensão | Bedrock | AgentCore | SageMaker AI | Amazon Q |
| --- | --- | --- | --- | --- | --- |
| Melhor para | Consumir LLMs/embeddings via API; prototipagem a produção rápida | Agentes em produção com tools, memória, gateway e observabilidade | Treinar/fine-tunar modelos próprios; ML tradicional; inferência com SLA agressivo | Produtividade interna: Q&A sobre docs corporativos, assistente de código, assistente AWS | Volume alto com custo por token proibitivo; soberania total de dados; modelos não disponíveis no Bedrock |
| Esforço de ops | Baixo — sem infraestrutura para gerenciar | Baixo-médio — runtime gerenciado, mas você configura tools e memória | Alto — endpoints, scaling, drift monitoring, atualizações de modelo | Muito baixo — configuração de conectores e permissões; sem código de IA | Muito alto — cluster GPU, CUDA, autoscaling, disponibilidade, segurança |
| Modelo de custo | Pay-per-token (variável) ou Provisioned Throughput (fixo por hora) | Pay-per-use do runtime + custo do modelo Bedrock subjacente | Por hora de instância (treinamento + inferência) + armazenamento | Por usuário/mês (previsível, SaaS-like) | Custo fixo de instância GPU (alto) + ops; melhor TCO em volume muito alto |
| Controle sobre o modelo | Baixo — você usa o modelo como está; fine-tuning disponível para alguns modelos | Baixo — controle sobre orquestração, não sobre o modelo | Alto — você treina, versiona, monitora e substitui o modelo | Nenhum — modelo gerenciado pela AWS | Total — você escolhe, opera e atualiza qualquer modelo |
| Quando NÃO usar | Quando você precisa de agente complexo (use AgentCore); quando o Q já resolve; quando volume torna custo por token proibitivo | Para chamadas simples de LLM sem orquestração; para produtividade interna (use Q) | Para consumir modelos de fundação sem customização (use Bedrock); para produtividade interna (use Q) | Para sistemas de IA customizados voltados a clientes externos; quando você precisa de controle sobre o modelo ou o fluxo de orquestração | Antes de validar o produto e o volume; quando o time não tem capacidade de operar infraestrutura GPU |
| Maturidade recomendada do time | Qualquer time com experiência em AWS e APIs | Time com experiência em sistemas distribuídos e design de agentes | Time com MLOps ou disposição para construir essa capacidade | Qualquer time; ideal para times sem engenheiros de ML | Time sênior com experiência em Kubernetes, GPU ops e segurança de cluster |

## Matriz de Decisão: Prós, Contras e Veredicto por Serviço

### Amazon Bedrock

**Pros**
- Catálogo amplo de modelos (Claude, Llama, Mistral, Titan, Cohere, Stability AI)
- Zero infraestrutura para gerenciar; escala automática
- Guardrails nativos, VPC endpoints, CloudTrail integrado
- Ponto de partida correto para 80% dos casos de uso de LLM

**Cons**
- Custo por token escala linearmente — sem economia de escala automática
- Latência variável no on-demand; Provisioned Throughput tem custo fixo alto
- Controle limitado sobre o modelo; fine-tuning disponível para poucos modelos

**Verdict:** Default correto para a maioria dos projetos. Comece aqui.

### Bedrock AgentCore

**Pros**
- Runtime gerenciado para agentes: tools, memória, gateway, observabilidade out-of-the-box
- Elimina plumbing que você construiria manualmente (e errado) no Bedrock puro
- Integração nativa com o ecossistema Bedrock (modelos, guardrails, Knowledge Bases)

**Cons**
- Serviço relativamente novo (GA 2025) — menos casos de uso documentados em produção
- Adiciona custo de runtime sobre o custo do modelo Bedrock
- Abstração pode limitar customizações muito específicas de orquestração

**Verdict:** Use quando seu agente tem mais de uma tool ou precisa de memória. Não reinvente o AgentCore.

### Amazon SageMaker AI

**Pros**
- Plataforma ML completa: treinamento, feature store, pipelines, registro de modelos, inferência
- Controle total sobre o modelo e o ambiente de execução
- Latência de inferência previsível com endpoints dedicados
- Fine-tuning com dados que ficam inteiramente na sua conta

**Cons**
- Alto overhead de operação — você gerencia endpoints, scaling, drift, atualizações
- Curva de aprendizado íngreme para times sem MLOps
- Custo de instância corre mesmo quando não há tráfego (endpoints dedicados)

**Verdict:** Inegociável para modelos customizados e ML tradicional. Não use para consumir LLMs de fundação.

### Amazon Q

**Pros**
- Zero código de IA — conectores nativos para 40+ fontes de dados corporativos
- Controle de acesso baseado em IAM e grupos do AD — usuário só vê o que tem permissão
- Amazon Q Developer: assistente de código integrado ao IDE e ao console AWS
- Custo previsível por usuário/mês — fácil de justificar para RH/financeiro

**Cons**
- Sem customização do fluxo de IA — você aceita o produto como está
- Não serve para sistemas de IA voltados a clientes externos
- Dependência de conectores disponíveis — fontes muito customizadas exigem desenvolvimento

**Verdict:** Vastamente subutilizado. Se o problema é produtividade interna, o Q provavelmente já resolve.

## Árvore de Decisão: Qual Serviço de IA da AWS Usar

Cada nó é uma pergunta de qualificação. Siga as arestas até a folha — o serviço recomendado. As perguntas estão ordenadas por especificidade: do mais restritivo (treinamento próprio) ao mais geral (consumo de LLM).

### 🚦 Entrada / Entry

- Novo caso de uso de IA New AI use case (user)

### ❓ Perguntas de Qualificação / Qualification Questions

- Q1: Precisa treinar ou fine-tunar modelo próprio? Need to train/fine-tune custom model? (compute)
- Q2: Caso de uso é produtividade interna (docs, código, console)? Internal productivity use case? (compute)
- Q3: Agente com tools, memória ou orquestração complexa? Agent with tools, memory, or complex orchestration? (compute)
- Q4: Volume alto + soberania de dados ou custo por token proibitivo? High volume + data sovereignty or prohibitive token cost? (compute)

### ✅ Serviços Recomendados / Recommended Services

- SageMaker AI Treinar · Servir · MLOps Train · Serve · MLOps (ai)
- Amazon Q Business / Developer Produtividade interna Internal productivity (ai)
- Bedrock AgentCore Runtime de agentes Agent runtime (ai)
- Self-hosted EKS + GPU Controle total Full control (compute)
- Amazon Bedrock API de LLM/Embeddings LLM/Embeddings API (default correto correct default) (ai)

### Fluxos

- start -> q1: início
- q1 -> sagemaker: SIM / YES
- q1 -> q2: NÃO / NO
- q2 -> amazonq: SIM / YES
- q2 -> q3: NÃO / NO
- q3 -> agentcore: SIM / YES
- q3 -> q4: NÃO / NO
- q4 -> selfhosted: SIM + volume
validado / YES +
validated volume
- q4 -> bedrock: NÃO / NO
(default)
- agentcore -> bedrock: usa Bedrock
como modelo base
uses Bedrock
as base model

## Checklist de Qualificação: 7 Perguntas Antes de Escolher o Serviço

1. **1. O modelo que preciso existe no catálogo do Bedrock?** — Verifique em aws.amazon.com/bedrock. Se não existe e você não pode treinar um alternativo, vá para SageMaker ou self-hosted. Se existe, continue.

2. **2. O caso de uso é interno ou externo?** — Interno (funcionários, devs, operações): avalie o Amazon Q antes de construir qualquer coisa. Externo (clientes, parceiros, APIs públicas): Q não se aplica — continue a qualificação.

3. **3. Preciso de fine-tuning com dados que não podem sair da minha conta?** — Se sim: SageMaker é a opção mais segura. O Bedrock oferece fine-tuning para alguns modelos, mas com menos controle sobre o ambiente. Documente o requisito de soberania antes de decidir.

4. **4. O sistema tem orquestração de múltiplas tools ou memória persistente?** — Se sim: avalie o Bedrock AgentCore antes de construir orquestração customizada. Teste se as abstrações do AgentCore atendem seu caso — na maioria dos casos, atendem.

5. **5. Qual é o volume estimado de tokens/mês?** — Calcule o custo mensal no Bedrock com o modelo alvo (aws.amazon.com/bedrock/pricing). Se o custo for aceitável, use Bedrock. Se for proibitivo, compare com o TCO de self-hosted (instância GPU + ops + eng). Só migre se o delta justificar.

6. **6. Há restrições regulatórias de soberania de dados (LGPD, GDPR, setor financeiro)?** — Bedrock opera dentro da sua região AWS e não usa seus dados para treinar modelos (por padrão). Para restrições mais duras (dados que não podem sair da VPC em hipótese alguma), self-hosted ou SageMaker com VPC endpoint são as opções.

7. **7. O time tem capacidade de operar o serviço escolhido?** — Seja honesto. Self-hosted sem time de plataforma sênior é dívida técnica garantida. SageMaker sem MLOps é endpoint órfão em 6 meses. Escolha o serviço que o time consegue operar com excelência, não o que parece mais sofisticado.

> **Anti-padrões que eu vejo repetidamente em produção:** **1. 'Vamos de Bedrock' como default irrefletido.** Bedrock é o ponto de partida correto para LLMs — mas não para produtividade interna (use Q), não para agentes complexos sem AgentCore (você vai reinventar o runtime), e não para ML tradicional (use SageMaker). A pergunta não é 'Bedrock ou não?' — é 'qual problema estou resolvendo?'

**2. Construir RAG customizado quando o Q já resolve.** Vi times gastarem 6+ semanas construindo pipelines de ingestão, chunking, embedding e retrieval para documentação interna — quando o Amazon Q Business com um conector S3 ou SharePoint teria entregue em dias. Antes de construir RAG, responda: 'O Q Business atende esse caso?' Na maioria das vezes, atende.

**3. Self-hosted antes de validar volume e produto.** Times que estimam custo de Bedrock em escala e pulam para EKS + GPU sem ter validado que o produto tem tração. O custo de operar um cluster GPU em produção — HA, atualizações, segurança, CUDA — é subestimado sistematicamente. Valide o produto no Bedrock. Migre quando a fatura mensal justificar o investimento em operação.

**4. Ignorar o AgentCore e construir orquestração na mão.** Memória de sessão no DynamoDB, retry de tools no Lambda, rate limiting no API Gateway, traces manuais no X-Ray — você está construindo o AgentCore artesanalmente, com bugs que o serviço gerenciado já resolveu. Se seu agente tem mais de uma tool, avalie o AgentCore antes de escrever código de plumbing.

> **Regra de Bolso:** **Comece no Bedrock. Suba para o AgentCore quando virar agente. Vá para SageMaker ou self-hosted só quando custo ou controle justificarem com números reais.** E antes de qualquer coisa: se o problema é produtividade interna, pergunte se o Q já resolve — na maioria dos casos, resolve.

> **Minha Leitura Sênior:** Depois de 16 anos construindo sistemas em produção — incluindo plataformas financeiras onde custo, latência e soberania de dados são restrições duras — o que mais me surpreende no espaço de IA generativa é a velocidade com que times pulam para a solução mais complexa sem qualificar o problema.

O Amazon Q Business é o serviço mais subutilizado que conheço na AWS hoje. A maioria das empresas tem um problema de acesso a conhecimento interno — documentação dispersa, wikis desatualizadas, onboarding lento — e a resposta instintiva é 'vamos construir um RAG com Bedrock'. O Q resolve isso com conectores nativos, controle de permissão granular e zero código de IA. O custo de oportunidade de não avaliar o Q antes de construir é real.

No outro extremo, vejo times que chegam ao self-hosted antes de ter 1000 usuários ativos. O argumento é sempre 'o custo por token vai escalar'. Sim, vai — mas o custo de operar um cluster GPU com alta disponibilidade, atualizações de modelo, segurança de cluster e gestão de spot interruptions também escala, e é um custo fixo que você paga independente do tráfego. Faça o cálculo de break-even com honestidade antes de comprometer o time com operação de infraestrutura GPU.

O Bedrock AgentCore é a adição que mais muda a equação para times construindo agentes em 2025. Antes dele, a escolha era entre Bedrock puro (você constrói o runtime) e frameworks externos como LangChain ou LlamaIndex (você gerencia dependências e versões). O AgentCore resolve o runtime gerenciado com observabilidade nativa — e para sistemas financeiros ou regulados, a rastreabilidade de cada step do agente não é opcional.

Minha recomendação prática: use a árvore de decisão deste playbook como checklist em toda reunião de inception de projeto de IA. As cinco perguntas de qualificação levam menos de 10 minutos e evitam meses de retrabalho.

## Veredicto

Não existe serviço de IA da AWS universalmente correto — existe o serviço certo para o problema certo, operado pelo time certo. A árvore de decisão é simples: produtividade interna vai para o Q; LLM via API vai para o Bedrock; agente com orquestração vai para o AgentCore; modelo customizado vai para o SageMaker; volume extremo com soberania vai para self-hosted. O erro não é escolher o serviço errado por ingenuidade — é escolher por hype, sem fazer as cinco perguntas de qualificação. Escolha pelo problema. O serviço certo é aquele que o seu time consegue operar com excelência e que resolve o problema do usuário com o menor custo total — não o mais sofisticado, não o mais recente, não o que apareceu no último re:Invent.

## Referências

- [AWS — Amazon Bedrock](https://aws.amazon.com/bedrock/)
- [AWS — Amazon SageMaker AI](https://aws.amazon.com/sagemaker/)
- [AWS — Amazon Q](https://aws.amazon.com/q/)
- [AWS — Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
- [Amazon Bedrock — Pricing](https://aws.amazon.com/bedrock/pricing/)

## Fontes do caso

- [AWS — Amazon Bedrock](https://aws.amazon.com/bedrock/)
- [AWS — Amazon SageMaker AI](https://aws.amazon.com/sagemaker/)
- [AWS — Amazon Q](https://aws.amazon.com/q/)
- [AWS — Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
- [Amazon Bedrock — Pricing](https://aws.amazon.com/bedrock/pricing/)