Por que escolhi Amazon Bedrock em vez de OpenAI no meu SaaS
Sumário
Tem um momento específico que eu me lembro até hoje.
Era tarde da noite, eu estava tentando fazer um currículo em PDF virar um JSON estruturado com nome, skills, experiências, senioridade. Eu tinha chamadas pra OpenAI funcionando, tudo validando com Zod, 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 pensei: eu estou construindo um produto na AWS. ECS, SQS, SNS, Cognito, RDS. Tudo dentro do ecossistema AWS. Por que a inteligência artificial o core do produto tá rodando numa API externa que eu não controlo, com uma chave que pode vazar, e com um custo que eu não consigo prever?
Foi aí que eu fui conhecer o Amazon Bedrock de verdade.
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.
Mas tem uma diferença fundamental em relação a chamar a OpenAI direto: você está dentro da AWS. Isso significa que 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.
Tem mais: 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 fechou um ciclo.
Por que escolhi o Bedrock em vez de ficar na OpenAI
Não foi dogma. Foi custo, controle e consistência.
Custo: O Claude 3.5 Haiku no Bedrock custa uma fração do gpt-4o-mini pra tarefas estruturadas. Extração de currículo, parsing de vaga, classificação de skill level tudo isso é trabalho de Haiku. Texto curto, output JSON, sem raciocínio complexo. O Haiku faz isso com precisão alta e custo baixo. Estimativa: ~$0.001 por extração de currículo.
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ê não adiciona risco de exfiltração de chave.
Consistência: Já que o produto usa Haiku pra tarefas simples e Sonnet pra raciocínio complexo e a diferença de custo entre os dois é ~10x ter ambos no mesmo gateway, com o mesmo padrão de chamada, sem precisar gerenciar duas integrações diferentes, simplificou muito a cabeça.
Haiku vs Sonnet: a decisão que mais impacta o custo
Essa foi uma das aprendizagens mais importantes: modelo errado na tarefa errada = dinheiro jogado fora.
No começo, eu coloquei Sonnet em tudo. “É melhor, então é mais seguro.” Errado. Sonnet é mais caro, mais lento, e pra extração estruturada de texto onde o output é JSON predefinido ele não entrega resultado proporcionalmente melhor.
Haiku pra tarefas estruturadas:
- Extrair currículo → JSON
- Parsear descrição de vaga → JSON
- Classificar senioridade → enum
Sonnet pra raciocínio:
- Gap analysis: dado esse perfil e essa vaga, onde estão os gaps, qual a prioridade de cada um, o que ele deve aprender primeiro?
- Geração de roadmap: síntese de dados de mercado + lacunas + objetivo de carreira → plano personalizado
- Entrevistas simuladas: conversa multi-turn com feedback contextualizado
A diferença de custo entre os dois é ~10x. Usar Sonnet onde Haiku resolve é queimar dinheiro em escala.
A regra que ficou: comece sempre pelo Haiku. Só sobe pra Sonnet quando ele falhar em uma tarefa real, não em medo preventivo.
O contexto: o SaaS que motivou essa decisão
Estou construindo uma plataforma de carreira pra devs. Você envia um currículo em PDF, a plataforma analisa, gera um gap analysis comparando com vagas de mercado, e devolve um roadmap personalizado de aprendizado. Tudo com IA.
A IA processa currículo, analisa vaga, calcula gap, gera roadmap, simula entrevista — tudo via Bedrock. Nenhuma chave de API da OpenAI. Nenhuma dependência externa além da AWS.
Toda decisão de modelo, toda escolha 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 que é uma curva de aprendizado real.
Mas quando você passa dessa curva, o que você tem é poderoso:
- Sem chave de API estática pra proteger
- Billing consolidado no mesmo lugar do resto da infra
- Troca de modelo sem mudar código de autenticação
- Streaming nativo pra experiências interativas
- Titan Embeddings integrado nativamente pro 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.
Isso foi uma escolha. E até agora, foi a certa.
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.