O que é o Amazon Bedrock (e por que ele existe)
Ao terminar: Você explica o que o Bedrock resolve e o que ele não é, sem confundir com a API direta da Anthropic.
Você decidiu botar um LLM dentro do seu produto. Antes de escrever a primeira linha, aparecem duas dores que não têm a ver com prompt nenhum: como eu troco de modelo sem reescrever o app inteiro, e como eu garanto que meus dados não vão parar no treino de outra empresa. O Amazon Bedrock existe para resolver exatamente essas duas dores — e é por aí que a gente começa, não pelo hello world.
O problema, antes do Bedrock
Sem uma camada gerenciada, cada provedor de modelo (Anthropic, Meta, Mistral, a própria Amazon) tem SDK, autenticação, formato de request e billing próprios. Colocar isso em produção significa, na prática, carregar quatro problemas ao mesmo tempo:
- Lock-in de modelo: você acopla o código a um provedor e, quando sai um modelo melhor em 6 meses, a migração é um projeto.
- Credenciais espalhadas: uma API key por provedor, cada uma um segredo para rotacionar e vazar.
- Rede e compliance: mandar dado sensível para uma API pública na internet, sem VPC, sem trilha de auditoria unificada.
- Operação de GPU: se você for hospedar o modelo, entra no jogo de provisionar, escalar e pagar GPU ociosa.
O que é o Amazon Bedrock
Bedrock é um serviço totalmente gerenciado e serverless que expõe foundation models de vários provedores por trás de uma única API. Você chama o modelo por HTTP/SDK; a AWS opera a inferência, a escala e o ciclo de vida — você nunca vê uma GPU. Trocar da Claude para a Nova ou a Llama é, no melhor caso, mudar uma string (o modelId).
O que o Bedrock NÃO é
Não é um modelo (é a porta para muitos modelos). Não é um chatbot pronto (isso é o Amazon Q). Não é uma plataforma de treino de ML do zero (isso é o SageMaker). Bedrock é a camada de inferência gerenciada onde você constrói o SEU app de GenAI.
As portas do Bedrock (endpoints)
Entender que o Bedrock é dividido em endpoints ajuda a raciocinar sobre IAM e arquitetura desde o dia 1. São quatro famílias:
- → a chamada de inferência do dia a dia
- → administração, não inferência
- → seu conteúdo não é armazenado nem treina o modelo
- Compute
- IA e machine learning
- Rede e entrega
O que faz o time de segurança dormir está na coluna da direita: o software de inferência de cada provedor roda numa conta isolada operada pela AWS, à qual o provedor não tem acesso. Seus prompts não saem da sua conta para o dono do modelo.
- Onde a inferência acontece. O caminho do dia a dia é o data plane: Converse e InvokeModel. É a única porta que você chama em produção com frequência.
- As outras três portas. Control plane administra modelo, guardrail e capacidade. A porta de agent cobre RAG e orquestração. A de dialeto nativo fala a API do próprio provedor.
- O isolamento que responde ao comitê. Cada provedor roda numa conta de deployment separada, operada pela AWS. Ele não vê seus prompts, seus logs nem suas respostas — e o conteúdo da chamada não é armazenado.
- A porta escolhida define o conjunto de features. Converse dá o denominador comum entre famílias de modelo; o dialeto nativo dá o que só aquele provedor expõe. Escolher a porta é escolher entre trocar de modelo mexendo num identificador e usar um recurso que a API comum ainda não representa. Não há porta que dê as duas coisas.
- O isolamento do provedor não cobre a sua parte. A conta isolada responde pelo que o provedor poderia ver. O que a sua aplicação registra, por quanto tempo guarda e quem alcança esse registro continua sendo responsabilidade sua — inclusive o log de prompt, que é onde dado pessoal costuma parar sem ninguém decidir que pararia.
Três formas de pagar pela inferência
| Modo | Como funciona | Quando usar |
|---|---|---|
| On-demand | Paga por token, sem compromisso. Throughput limitado pela quota da região. | Default. Tráfego variável, dev, baixo/médio volume. |
| Batch | Jobs assíncronos (até ~24h) com ~50% de desconto. | Cargas não-interativas: embeddings em massa, classificação offline, enriquecimento de dados. |
| Provisioned Throughput | Capacidade dedicada em model units/hora, com commit de 1 ou 6 meses. | Throughput alto e constante, latência garantida, ou modelos customizados. |
Comece pelo on-demand
99% dos projetos começam (e ficam) no on-demand. Provisioned Throughput só ganha quando você satura a capacidade quase 24/7 — antes disso, é dinheiro parado.
Qual afirmação descreve melhor o que é o Amazon Bedrock?
Seus dados continuam seus
Esse é o argumento que faz o time de segurança dormir. Em cada região, o Bedrock roda o software de inferência de cada provedor dentro de uma Model Deployment Account isolada, operada pela AWS. O provedor do modelo não tem acesso a essa conta — não vê seus prompts, seus logs nem suas respostas.
Garantias de privacidade do Bedrock
Seus prompts e respostas NÃO são usados para treinar os modelos base. O Bedrock não armazena o conteúdo (texto, imagem, documento) que você envia numa chamada Converse — ele só usa para gerar a resposta. Tudo cifrado em trânsito (TLS 1.2+), com opção de KMS CMK no que fica em repouso (custom models, Knowledge Bases, avaliações).
Bedrock, SageMaker ou Amazon Q?
As três peças de IA da AWS confundem quem chega agora. A regra é pensar em quem é o dono do quê:
| Serviço | O que é | Você usa quando |
|---|---|---|
| Amazon Bedrock | Inferência gerenciada multi-modelo (API-first) | Quer construir SEU app/agent de GenAI rápido, sem operar ML |
| Amazon SageMaker AI | Plataforma end-to-end de ML (treinar/hospedar) | O modelo é o produto: fine-tune pesado, ML clássico, pesquisa |
| Amazon Q | Assistente de IA pronto (SaaS) | Quer produtividade pronta: Q Developer (código), Q Business (Q&A corporativo) |
📋 Preciso de um chatbot que responda sobre a base de conhecimento interna da empresa, em produção, o quanto antes.
Você quer inferência + RAG gerenciado (Knowledge Bases) + guardrails sem montar pipeline de ML nem operar GPU. É exatamente o sweet spot do Bedrock.
Alt: SageMaker — Poder demais para o problema: você acabaria construindo infra de ML que o Bedrock já entrega pronta.
Alt: Amazon Q Business — Resolve, mas você não controla prompt, modelo nem a lógica de retrieval — é caixa-preta gerenciada.
Quando usar (e quando pensar duas vezes)
Bedrock brilha quando
Você quer governança AWS (IAM/VPC/KMS), precisa poder trocar de modelo sem reescrever, tem tráfego variável, quer RAG/agents/guardrails gerenciados, e valoriza um único bill da AWS com dados que não treinam ninguém.
Pense duas vezes quando
Você precisa do recurso mais novo do provedor no dia do lançamento (a API direta costuma sair na frente), ou tem volume gigante e constante de um único modelo com time de MLOps (aí self-hosting pode ganhar em custo). Cobrimos esse trade-off no próximo módulo.
Perguntas frequentes
❓ O que é o Amazon Bedrock?
❓ Bedrock treina modelo com o meu dado?
❓ Bedrock é caro comparado à API direta?
Fixando
Um time de segurança pergunta: 'a Anthropic vai ver os prompts que mandamos para a Claude via Bedrock?'. Qual é a resposta correta?
Uma equipe de negócio quer um assistente pronto para consultar documentos internos, sem escrever código. Outra equipe quer construir um produto com foundation model. Quais serviços?
Próximo passo
Você já sabe o que é e por que existe. A pergunta natural agora é: se eu já poderia chamar a API da Anthropic direto, por que passar pelo Bedrock? É exatamente o próximo módulo — Bedrock vs API direta: quando usar cada um.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…