Why I Chose Amazon Bedrock Over OpenAI in My SaaS
Table of contents
There’s a specific moment I still remember clearly.
It was late at night, and I was trying to turn a PDF résumé into structured JSON name, skills, experience, seniority level. I had OpenAI calls working, everything validating with Zod, the pipeline looking clean. Then the monthly bill arrived. And with it, a question I didn’t want to answer: if this scales, how much is it going to cost?
That’s when I stopped and thought: I’m building a product on AWS. ECS, SQS, SNS, Cognito, RDS. Everything inside the AWS ecosystem. So why is the AI the core of the product running on an external API I don’t control, with a key that can leak, and with costs I can’t predict?
That’s when I finally took a serious look at Amazon Bedrock.
What Is Bedrock, Exactly?
The most direct way to explain it: Bedrock is a managed AI model gateway inside AWS. You don’t need to host any model, you don’t need GPUs, you don’t need infrastructure. You call an API, pick a model, and get a response.
But there’s one fundamental difference from calling OpenAI directly: you’re inside AWS. That means Bedrock authenticates using the same IAM Role as your ECS Task. No exposed API key. No secret to rotate. No OPENAI_API_KEY in .env that someone can accidentally commit.
It’s IAM permissions the same ones you already use to access S3, SQS, RDS. You only need bedrock:InvokeModel in the policy and you’re done.
There’s more: inside Bedrock you have several models available. Anthropic’s Claude. Meta’s Llama. Amazon’s own Titan. Stable Diffusion. And the list keeps growing. You can switch models without changing your architecture, without changing your auth system, without signing up anywhere else.
For me building everything inside AWS on purpose, both as a learning lab and as a deliberate architectural choice this closed the loop.
Why I Chose Bedrock Instead of Staying With OpenAI
It wasn’t dogma. It was cost, control, and consistency.
Cost: Claude 3.5 Haiku on Bedrock costs a fraction of gpt-4o-mini for structured tasks. Résumé extraction, job description parsing, seniority classification all of this is Haiku territory. Short text, JSON output, no complex reasoning. Haiku handles it with high accuracy and low cost. Estimate: ~$0.001 per résumé extraction.
Control: Credentials via IAM Role means the worker running on ECS never needs a static key. The token is temporary, automatically rotated by AWS. You add no key exfiltration risk.
Consistency: Since the product uses Haiku for simple tasks and Sonnet for complex reasoning and the cost difference between them is ~10x having both on the same gateway, with the same call pattern, without managing two separate integrations, simplified a lot of cognitive overhead.
Haiku vs Sonnet: The Decision That Impacts Cost the Most
This was one of the most important lessons: wrong model on the wrong task = money wasted.
At first, I put Sonnet on everything. “It’s better, so it’s safer.” Wrong. Sonnet is more expensive, slower, and for structured text extraction where the output is predefined JSON it doesn’t deliver proportionally better results.
Haiku for structured tasks:
- Extract résumé → JSON
- Parse job description → JSON
- Classify seniority → enum
Sonnet for reasoning:
- Gap analysis: given this profile and this job posting, where are the gaps, what’s the priority for each, what should they learn first?
- Roadmap generation: synthesis of market data + skill gaps + career goal → personalized plan
- Simulated interviews: multi-turn conversation with contextualized feedback
The cost difference between the two is ~10x. Using Sonnet where Haiku is enough means burning money at scale.
The rule I settled on: always start with Haiku. Only move up to Sonnet when it actually fails on a real task, not out of preventive fear.
Context: The SaaS Behind This Decision
I’m building a career platform for developers. You upload a PDF résumé, the platform analyzes it, generates a gap analysis by comparing it against real job postings, and returns a personalized learning roadmap. All with AI.
The AI processes the résumé, analyzes job postings, calculates gaps, generates roadmaps, simulates interviews all through Bedrock. No OpenAI API key. No external dependency outside AWS.
Every model decision, every architectural choice, was made in this context: a product built entirely inside AWS, with AI as the core and not as an accessory. If you follow the build process, I also wrote about how I use Spec-Driven Development to structure technical decisions with AI as a development partner.
The Honest Opinion
Bedrock isn’t the easiest platform to start with. The documentation is good but scattered. LocalStack doesn’t emulate Bedrock. STS for local dev is friction. Configuring the IAM Role in the ECS Task to have bedrock:InvokeModel permission requires understanding IAM Trust Policies which is a real learning curve.
But once you get past that curve, what you have is powerful:
- No static API key to protect
- Billing consolidated in the same place as the rest of the infra
- Model switching without touching authentication code
- Native streaming for interactive experiences
- Titan Embeddings integrated natively with pgvector
For anyone building an entire product inside AWS not just “using AWS to host” Bedrock makes sense as a strategic choice. You keep the ecosystem coherent. You don’t add a critical external dependency to something that is the core of your product.
This was a choice. And so far, it was the right one.
In the next article, I’ll show how this pipeline works in practice: async processing with SQS, the challenge of running Bedrock in parallel with LocalStack, embeddings with Titan, streaming with SSE, and the errors you only discover in production.