Amazon Bedrock na prática: IA como parte da arquitetura, não como dependência externa
Sumário
Tem um momento específico que eu me lembro até hoje.
Era tarde da noite, eu estava tentando fazer um PDF virar um JSON estruturado. Campos específicos extraídos do documento, validados com Zod, output limpo. Eu tinha chamadas pra OpenAI funcionando, o pipeline bonito. Aí chegou a fatura do mês. E junto com ela, uma pergunta que eu não queria responder: se isso escalar, quanto vai custar?
Foi nesse momento que eu parei e olhei pro que eu tinha construído. ECS, SQS, SNS, Cognito, RDS. Tudo dentro do ecossistema AWS. E a inteligência artificial, que era o core do produto, rodava numa API externa que eu não controlava, com uma chave que podia vazar e um custo que eu não conseguia prever. Não fazia sentido.
O que é o Bedrock, afinal?
A forma mais direta de explicar: Bedrock é um gateway gerenciado de modelos de IA dentro da AWS. Você não precisa hospedar nenhum modelo, não precisa de GPU, não precisa de infraestrutura. Você chama uma API, escolhe o modelo e recebe a resposta.
A diferença fundamental em relação a chamar a OpenAI direto é que você está dentro da AWS. O Bedrock usa o mesmo IAM Role do seu ECS Task pra autenticar. Sem chave de API exposta. Sem segredo pra rotacionar. Sem OPENAI_API_KEY no .env que alguém pode commitar por acidente. É permissão de IAM, a mesma que você já usa pra acessar S3, SQS, RDS. Você só precisa de bedrock:InvokeModel na policy e pronto.
Dentro do Bedrock você tem vários modelos disponíveis: Claude da Anthropic, Llama da Meta, Titan da própria Amazon, Stable Diffusion, e a lista cresce. Você pode trocar de modelo sem mudar sua arquitetura, sem mudar seu sistema de auth, sem criar conta em outro lugar. Pra mim, que estava construindo tudo dentro da AWS de propósito, como laboratório de aprendizado e como escolha arquitetural deliberada, isso fez com que tudo passasse a rodar no mesmo ecossistema.
Por que escolhi o Bedrock em vez de ficar na OpenAI
Teve três coisas que pesaram nessa decisão.
A primeira foi controle. Credenciais via IAM Role significa que o worker que roda no ECS nunca precisa de uma chave estática. O token é temporário, rotacionado automaticamente pela AWS. Você elimina o risco de exfiltração de chave.
A segunda foi consistência. O produto usa Haiku pra tarefas simples e Sonnet pra raciocínio complexo, e a diferença de custo entre os dois é de aproximadamente 10x. Ter ambos no mesmo gateway, com o mesmo padrão de chamada, sem precisar gerenciar duas integrações diferentes, simplificou muito a operação.
A terceira foi billing. Toda a infraestrutura já rodava na AWS, então consolidar a IA no mesmo billing, com a mesma visibilidade de custos do resto da stack, me deu previsibilidade. Não tinha mais fatura surpresa de provider externo no final do mês. Sobre preço unitário por token, o gpt-4o-mini da OpenAI ainda é mais barato que o Haiku no Bedrock. Mas o custo do Haiku pra tarefas estruturadas como extração e classificação de documentos é baixo o suficiente pra que a diferença não justifique manter uma dependência externa no core do produto.
Haiku vs Sonnet: a decisão que mais impacta o custo
No começo, eu coloquei Sonnet em tudo. Minha lógica era simples: “é o modelo mais capaz, então é mais seguro usar ele.” Na prática, Sonnet é mais caro, mais lento, e pra extração estruturada de texto onde o output é JSON predefinido, ele não entrega resultado proporcionalmente melhor que o Haiku.
Hoje a separação que eu faço é por tipo de tarefa. Tudo que é extração e classificação roda no Haiku: documento pra JSON, categorização de campos, normalização de dados não estruturados. O Haiku resolve isso com precisão alta e custo baixo, algo em torno de ~$0.001 por documento processado.
O Sonnet entra quando a tarefa exige raciocínio real. Análises que cruzam múltiplas fontes de dados e precisam priorizar resultados, geração de conteúdo que sintetiza contexto de diferentes inputs, conversas multi-turn com feedback contextualizado. Essas tarefas precisam de um modelo mais capaz, e aí o custo do Sonnet se justifica.
A diferença de custo entre os dois é de aproximadamente 10x. Usar Sonnet onde Haiku resolve é gastar dinheiro sem necessidade em escala. Eu sempre começo pelo Haiku e só subo quando ele falha numa tarefa real, não por precaução.
O contexto: o SaaS que motivou essa decisão
Estou construindo um SaaS onde a IA não é feature secundária, é o core do produto. O usuário envia um documento, a plataforma processa, analisa e devolve resultados personalizados. Toda a inteligência roda via Bedrock, sem nenhuma chave de API da OpenAI, sem dependência externa além da AWS.
Toda decisão de modelo e de arquitetura foi pensada nesse contexto: um produto inteiro construído dentro da AWS, com IA como core e não como acessório. Se você acompanha o processo de construção desse produto, escrevi sobre como uso Spec-Driven Development pra estruturar as decisões técnicas com IA como par de desenvolvimento.
A opinião honesta
O Bedrock não é a plataforma mais fácil pra começar. A documentação é boa mas espalhada. LocalStack não emula Bedrock. STS pra dev local é um atrito. A configuração de IAM Role no ECS Task pra ter permissão de bedrock:InvokeModel exige entender IAM Trust Policies, e isso tem uma curva de aprendizado real.
Mas quando você passa dessa curva, o que você tem é um ambiente onde não existe chave de API estática pra proteger, o billing fica consolidado no mesmo lugar do resto da infra, trocar de modelo não exige mudar código de autenticação, streaming funciona nativamente pra experiências interativas, e Titan Embeddings se integra direto com pgvector.
Pra quem está construindo um produto inteiro dentro da AWS, e não só usando AWS pra hospedar, Bedrock faz sentido como escolha estratégica. Você mantém o ecossistema coeso. Você não adiciona uma dependência externa crítica em algo que é o core do seu produto. Essa foi a minha escolha, e até agora não tive motivo pra reconsiderar.
No próximo artigo, mostro como esse pipeline funciona na prática: assincronia com SQS, o problema de rodar Bedrock em paralelo com LocalStack, embeddings com Titan, streaming com SSE, e os erros que você só descobre em produção.