Amazon Bedrock

Você decidiu que a sua aplicação precisa de um modelo de fundação. Agora vêm as perguntas que ninguém gosta de responder: quais instâncias de GPU, quantas, em que região, quem aplica os patches, o que acontece às 3 da manhã quando o tráfego triplica e como você troca por um modelo melhor daqui a seis meses sem reconstruir tudo.

O Amazon Bedrock existe para você nunca responder a essas perguntas. A AWS o define como "um serviço totalmente gerenciado que fornece acesso seguro, de nível corporativo, a modelos de fundação de alto desempenho das principais empresas de IA, permitindo que você construa e escale aplicações de IA generativa".

Leia isso como uma lista de coisas que você deixa de fazer. Nenhum servidor para dimensionar. Nenhum peso de modelo para baixar. Nenhuma stack de inferência para operar. Você manda uma requisição para um endpoint de API e recebe texto gerado de volta, e a capacidade embaixo disso é problema de outra pessoa.

Uma API, muitos modelos

O Bedrock oferece mais de 100 modelos de fundação de provedores como Amazon, Anthropic, DeepSeek, MiniMax, Moonshot AI e OpenAI. O catálogo chama atenção, mas o catálogo não é o ponto. O ponto é o que fica na frente dele.

Cada um desses modelos é alcançado pelo mesmo serviço. Na prática você chama a Converse API, informa um model ID e passa as suas mensagens:

import boto3

client = boto3.client('bedrock-runtime', region_name='us-east-1')
response = client.converse(
    modelId='anthropic.claude-opus-4-7',
    messages=[
        {'role': 'user', 'content': [{'text': 'Resuma este ticket de suporte.'}]}
    ]
)

Agora troque o modelId por um modelo Amazon Nova. Nada mais naquela chamada muda. A sua autenticação, o seu SDK, o seu tratamento de erros, os seus logs e as suas políticas de IAM continuam funcionando.

Compare com a alternativa. Sem o Bedrock, cada provedor significa uma conta separada, uma API key guardada em algum lugar, um SDK com formato de requisição próprio, uma fatura separada e uma revisão de segurança separada. Adicionar um segundo provedor de modelo é um projeto. No Bedrock é uma string.

É por isso que a lição de escolha de modelo pôde chamar essa decisão de reversível. A reversibilidade não é propriedade geral da IA generativa. É propriedade de construir atrás de uma camada de abstração, e o Bedrock é essa camada.

Um limite honesto: a chamada é portável, o comportamento não. Um prompt ajustado para um modelo não produz saída idêntica em outro, e os modelos diferem em janela de contexto, tamanho máximo de saída e quais parâmetros de inferência aceitam. O Bedrock deixa a troca barata. Ele não dispensa a revalidação.

O que o Bedrock acrescenta em volta do modelo

Uma chamada de modelo crua não é uma aplicação. Entre "o modelo respondeu" e "a funcionalidade foi publicada" existe um conjunto de problemas que todo time encontra, e o Bedrock entrega respostas gerenciadas para quase todos.

As Knowledge Bases cuidam de retrieval augmented generation. A AWS descreve o propósito de forma direta: o RAG "usa informação de fontes de dados para melhorar a relevância e a exatidão das respostas geradas", e com as Knowledge Bases "você pode integrar informação proprietária às suas aplicações de IA generativa". Você aponta para os seus dados e ela cuida de ingestão, chunking, embedding, armazenamento e recuperação, devolvendo respostas com citações para que uma resposta possa ser rastreada até a origem. Uma Managed Knowledge Base deixa a AWS rodar esse pipeline inteiro; uma customer-managed permite trazer o seu próprio vector store, como Amazon OpenSearch Serverless, Amazon Aurora ou Amazon Neptune, e controlar a ingestão e a indexação você mesmo.

Os Guardrails são a camada de segurança de conteúdo. Eles fornecem "salvaguardas configuráveis para ajudar você a construir aplicações de IA generativa seguras", e vêm em seis tipos de política:

Dois detalhes sobre os Guardrails valem a memória. Eles avaliam tanto o prompt de entrada quanto a completion do modelo, não só um lado. E eles rodam sem modelo nenhum: a API ApplyGuardrail filtra conteúdo por conta própria, então você pode checar texto antes de ele entrar no seu pipeline.

A customização de modelos cobre três métodos. Supervised fine-tuning treina sobre exemplos rotulados de entrada e saída. Reinforcement fine-tuning aprende a partir de funções de recompensa que você define em vez de pares rotulados. Distillation transfere conhecimento de um modelo teacher grande para um modelo student menor, mais rápido e mais barato. O Domínio 3 cobre quando cada um é a escolha certa.

As avaliações pontuam modelos com os seus próprios dados, de forma programática, com um judge model ou com revisores humanos. Você viu isso na lição de escolha de modelo.

O AgentCore transforma um modelo em um agente que planeja e age. Isso é um assunto por si só, e a próxima lição pega essa linha.

O padrão em todas essas peças é o mesmo: cada uma é um problema que você resolveria com infraestrutura própria, oferecido como configuração.

A pergunta sobre dados, respondida de forma concreta

Toda organização faz alguma versão desta pergunta: se mandarmos texto de clientes para o modelo de um terceiro, o que esse terceiro passa a ver?

Para o Bedrock, a AWS responde com arquitetura em vez de promessa. Em cada região onde o Bedrock está disponível existe uma conta de implantação de modelo por provedor. Essas contas pertencem ao time do serviço Bedrock e são operadas por ele. Quando um provedor entrega um modelo, a AWS faz uma cópia profunda do software de inferência e treinamento do provedor para dentro dessas contas. E então vem a frase que importa: "Como os provedores de modelos não têm acesso a essas contas, eles não têm acesso a logs do Amazon Bedrock nem a prompts e completions de clientes."

Ou seja, chamar um modelo de terceiro no Bedrock não é a mesma coisa que chamar a API pública desse provedor. O seu prompt vai para uma conta operada pela AWS, não para o provedor. O provedor forneceu o modelo; ele não recebe o tráfego.

Em cima disso você tem os controles habituais da AWS: criptografia com AWS KMS, conectividade privada por Amazon VPC e AWS PrivateLink para que as requisições nunca atravessem a internet pública, IAM para decidir quem pode invocar qual modelo e CloudTrail para o registro de auditoria.

Esse é o fato mais útil da lição para uma questão de cenário. Quando um enunciado menciona setor regulado, regra de residência de dados ou uma revisão de segurança que precisa aprovar o fornecedor, o isolamento por conta de implantação é a base da resposta.

Onde o Bedrock para

O Bedrock é um bom padrão, e um padrão não é resposta universal. Ele serve e customiza modelos que já existem. Três situações ficam de fora.

Você quer treinar um modelo do zero, com arquitetura própria e loop de treinamento próprio. O Bedrock não tem porta de entrada para isso.

Você precisa de um modelo que não está no catálogo, ou de controle total do ambiente de serving, como um container de inferência específico, um tipo de instância específico ou implantação dentro da sua VPC em hardware escolhido por você.

Você está fazendo machine learning clássico em vez de IA generativa. Um modelo de detecção de fraude sobre dados tabulares de transações é uma árvore com gradient boosting, não um modelo de fundação, e o Bedrock não tem nada a oferecer para ele.

Cada um desses pontos aponta para o mesmo serviço, que é o assunto da próxima lição.

Dicas para o exame

• O Bedrock é o caminho totalmente gerenciado e serverless para modelos de fundação. Palavras de cenário como "sem infraestrutura para gerenciar", "caminho mais rápido para produção" ou "não queremos rodar GPUs" apontam para cá.
• Uma API para muitos provedores é o diferencial a guardar. Qualquer questão sobre trocar de modelo barato, ou comparar modelos sem reescrever a aplicação, está cobrando isso.
• Ligue a capacidade ao problema: dados proprietários nas respostas significa Knowledge Bases; bloquear conteúdo nocivo ou fora do assunto significa Guardrails; detectar resposta sem base na fonte significa contextual grounding checks especificamente.
• Guardrails avaliam entrada e saída, e o ApplyGuardrail funciona sem invocar modelo. Opções afirmando que guardrails só veem saída estão erradas.
• "Treinar um modelo do zero" é a frase que tira o Bedrock da mesa. "Precisamos de controle total do container de serving" também.
• O isolamento por conta de implantação é a resposta para qualquer questão sobre se provedores de modelos veem os seus prompts. Não veem.
• Um modelo customizado exige Provisioned Throughput para servir. Guarde o par; a lição de custo explica por que ele dói.

A ideia para levar adiante é que o Bedrock troca controle por velocidade, e essa troca costuma ser a certa. A próxima lição é sobre os casos em que ela não é, e sobre o serviço que fica logo abaixo.