The AI provider landscape changed twice in one week.
On April 28, OpenAI ended its exclusivity arrangement with Microsoft and announced expanded availability on AWS. On May 4, AWS made it concrete: GPT-5.5 and GPT-5.4 are now available through Amazon Bedrock in limited preview, Codex is on Bedrock as a CLI, desktop app, and VS Code extension, and a new Bedrock Managed Agents product wraps OpenAI's frontier models with AWS infrastructure for production agent workflows.
That's the news cycle. Here's the founder version: if you've been building an AI SaaS on the assumption that "OpenAI = Azure" and "Anthropic = AWS" — those defaults no longer hold. Both frontier providers now sit on AWS. Both also sit elsewhere. Your provider decisions just got more interesting and harder.
This post is about how to think through that, not which "winner" to pick.
<p>GPT-5.5 and GPT-5.4 are now on AWS Bedrock alongside Anthropic Claude — meaning AWS hosts both frontier providers in one place for the first time.</p>
<p>Codex on Bedrock means you can use OpenAI's coding agent inside an AWS account using AWS auth and AWS billing — instead of separate OpenAI API keys.</p>
<p>For most existing SaaS apps, this is more about future flexibility than an immediate "switch providers" decision.</p>
What Actually Got Announced
Three things, in plain language:
- OpenAI models on Amazon Bedrock (Limited preview). GPT-5.5 and GPT-5.4 — OpenAI's frontier models — are now callable through the Bedrock API with the same patterns you'd use for Anthropic Claude or Meta Llama. Same IAM auth, same VPC endpoints, same CloudWatch metrics, same Bedrock pricing model.
-
Codex on Amazon Bedrock (Limited preview). OpenAI's coding agent — the same one that ships as
codexCLI, a Codex desktop app, and a VS Code extension — can now run against Bedrock-hosted OpenAI models. For teams already inside an AWS environment, this means coding-agent traffic stays inside your AWS account boundary instead of going to a separate OpenAI account. - Amazon Bedrock Managed Agents (Limited preview). A new managed service that wraps OpenAI frontier models in AWS-hosted agent infrastructure. Memory, tool use, retrieval, evaluation — all the agent plumbing — managed by AWS instead of built by you.
All three are limited preview. Most teams won't have access on day one. The mid-term direction is clear: AWS becomes a place where you can use any major frontier model under one billing relationship, one IAM model, and one set of compliance certifications.
Why This Matters for AI SaaS Founders
Until April, the practical picture for founders building AI features looked like this:
- OpenAI = direct API or Azure OpenAI Service. Different auth, different SLAs, different regions.
- Anthropic = direct API or AWS Bedrock or Google Vertex AI. Easy to use on Bedrock.
- Google Gemini = direct API or Vertex AI.
- Meta Llama = AWS Bedrock or Vertex AI or self-hosted.
If you wanted to be multi-provider — calling OpenAI for one feature and Claude for another — you were managing at least two billing relationships, two auth flows, and two sets of SDKs. Most founders didn't bother. They picked one provider and stuck with it.
Bedrock now collapses that picture. Both OpenAI and Anthropic models live behind the same API surface. Switching between them — or A/B testing them on a per-feature basis — becomes a config change instead of a rewrite.
That sounds like a clean win, and for new builds it largely is. For existing SaaS apps, the calculation is more nuanced. The cost of changing your stack is real, and the benefit of "now I can switch" is mostly latent until you actually need to switch.
If your SaaS is already running on OpenAI direct API or Anthropic direct API and it's working, the right answer this week is probably: don't move yet. Watch for general availability, watch for pricing parity, then revisit.
If you're picking a stack for a new product right now, that's where this changes things.
The Provider Landscape in May 2026
Here's how I'd map it out today:
| Provider | Direct API | AWS Bedrock | Azure | Google Vertex | Self-host |
|---|---|---|---|---|---|
| OpenAI (GPT-5.x, Codex) | ✅ | 🟡 limited preview | ✅ Azure OpenAI | — | — |
| Anthropic (Claude) | ✅ | ✅ | — | ✅ | — |
| Google Gemini | ✅ | — | — | ✅ | — |
| Meta Llama | — | ✅ | ✅ | ✅ | ✅ |
| Mistral / Cohere / others | ✅ each | ✅ Bedrock | varies | varies | varies |
The headline: AWS Bedrock is now the only managed surface that hosts both OpenAI and Anthropic frontier models. Direct API from each provider is still the cheapest and lowest-latency path, but Bedrock is the only "neutral ground" for multi-provider architectures.
Anthropic's relationship with AWS is also worth flagging. In April, Amazon committed to investing up to $25B more in Anthropic, and Anthropic pledged $100B in cloud spending to AWS over time. That alignment isn't going away. Bedrock's bias toward Anthropic models — better region coverage, deeper integrations, longer-running availability — is structural.
OpenAI on Bedrock is real but newer and smaller. Treat that as the asymmetry it is.
For most SaaS founders, the practical takeaway from this map isn't "go multi-provider." It's "the cost of going multi-provider later is now lower than it used to be." That's a different kind of optionality.
Five Real Decisions This Forces You to Think About
If you're building or scaling an AI SaaS product, here are the actual questions worth a meeting:
1. Direct API or Bedrock?
Direct API wins on: lowest latency, lowest per-token cost, fastest access to new models (Bedrock typically lags by weeks to months on new model releases), simpler SDKs.
Bedrock wins on: unified billing under your AWS account, IAM-based auth (no API keys to manage), VPC isolation, CloudWatch monitoring out of the box, easier procurement for enterprise customers (your buyer doesn't have to onboard OpenAI as a separate vendor), shared infrastructure with the rest of your AWS workload.
For a solo founder or small team building a B2C product, direct API is almost always the right starting answer. For a B2B SaaS selling to enterprise — especially anyone in regulated industries — Bedrock removes a real procurement headache.
2. Are you ever going to actually be multi-provider?
A lot of teams say "we want optionality" without ever exercising it. Multi-provider architectures cost something — abstraction layers, extra testing, prompt drift between models, more runtime configuration.
Honest test: if your current provider had a 4-hour outage tomorrow, would you actually fail over to a different model, or would you just wait? If the answer is "wait" then you're not really multi-provider — you're paying the abstraction cost without getting the benefit.
If the answer is "fail over" then you should have built that path already, in which case Bedrock's unified API is genuinely useful.
3. Where do your customer's tokens live?
For B2B AI SaaS, your customer is increasingly going to ask: "where does my data go when I use your AI features, and who has it?"
Direct OpenAI API answer: "It goes to OpenAI servers. They have a data processing agreement we signed."
Bedrock answer: "It goes through your AWS account, which is already covered under your AWS BAA / DPA / [whichever framework]. AWS doesn't train on it. Neither does OpenAI through this surface."
Some enterprise customers care a lot about which answer they hear. Some don't care at all. Know which kind of customer you're selling to.
4. What's your latency budget?
Bedrock adds a hop. Calls go through AWS's regional Bedrock endpoint, which routes to the model provider's infrastructure. In practice this typically adds 50–200ms compared to direct API, depending on region.
For most SaaS workloads — chat features, summarization, search — that's invisible. For latency-critical features (real-time autocomplete, voice, agent loops with tight cycle times), it matters. If your AI feature lives in the user's hot path and the perceived speed is already a complaint, this is a real concern. If it's covered by a loading spinner anyway, it isn't.
This connects to the broader "your Next.js app feels slow after launch" pattern — the kind of work covered in Next.js Performance Optimization. AI latency is now part of total user-perceived latency, and it's easy to underestimate.
5. Are you using an AI Gateway?
The third option that doesn't show up in most "Bedrock vs direct API" debates: AI gateways — Vercel AI Gateway, OpenRouter, Portkey, Helicone. These sit between your app and any frontier provider, giving you observability, rate limiting, automatic provider failover, and a unified API across providers.
For solo founders and small teams, an AI gateway is often the better answer than either direct or Bedrock. You get most of the operational benefits of Bedrock without the AWS lock-in, and you get easy provider switching without writing your own abstraction layer.
If you're already on Vercel, the AI Gateway is the lowest-friction path. If you're already deep into AWS, Bedrock makes more sense.
The "right" answer is rarely "use the most powerful platform." It's "use the platform whose lock-in you're least worried about, given the way your product will actually evolve over the next 12 months."
What I Wouldn't Do Yet
A few things the news cycle is pushing that I'd push back on:
Don't migrate a working stack just because Bedrock has OpenAI now. If your SaaS already runs on OpenAI direct API and your billing, latency, and customer compliance are all fine, the cost of moving to Bedrock is real and the benefit is largely "future optionality." Migrate when you have a concrete reason to.
Don't bet on Codex on Bedrock for production yet. Codex CLI is a developer-experience tool, not a customer-facing API. The Bedrock version is limited preview. Use it for your own engineering workflow if you want, but don't build customer features that depend on it being generally available on a particular timeline.
Don't go multi-provider before you have one provider working well. Multi-provider abstractions are expensive to maintain and easy to over-engineer. Ship the single-provider version first. Add the abstraction the first time you have a real reason to switch — and not before.
Don't trust pricing comparisons that don't include egress and gateway costs. Bedrock's per-token pricing isn't the full picture. Your AWS networking costs, log storage costs, and Bedrock-specific markups all factor in. The honest comparison is your monthly AWS bill before vs after, not the rate card.
The Bigger Picture
Two patterns are clear from this week's announcements:
- The frontier-model business is consolidating around three hyperscalers — AWS, Azure, GCP — even while staying nominally multi-provider. The economic gravity is pulling everything toward managed surfaces. If you've been holding off on cloud commitments to "stay neutral," that's getting harder.
- Cloud-provider lock-in for AI SaaS is becoming structural. Once your AI traffic, your auth, your monitoring, and your customer's data residency commitments all live inside one AWS account, switching is no longer a code change. It's a compliance change.
This isn't necessarily bad. Concentration trades away some flexibility for a lot of operational simplicity, and for B2B SaaS especially, that's often the right trade. But it's worth making the trade consciously, not by default.
If you're picking a stack for a new AI SaaS right now, the questions worth answering first aren't "GPT-5.5 or Claude?" — they're:
- Where is your customer's data going to live?
- What does your auth and billing look like in 12 months when you have 10 features instead of 1?
- Is multi-provider real for your product, or aspirational?
Those questions matter more than the model picker. They're also exactly the kinds of decisions covered by SaaS MVP Development when the AI feature is the product, and AI SaaS Development when AI is one feature inside a broader product.
The teams I see make the best AI provider decisions are the ones that decide what they're optimizing for first — latency, cost, compliance, optionality — and then pick the stack that fits. The teams that make the worst decisions pick the stack first and figure out the tradeoffs later.
Frequently Asked Questions
Is OpenAI available on AWS Bedrock?
Yes, as of May 2026 — GPT-5.5 and GPT-5.4 are available through Amazon Bedrock in limited preview. Codex is also on Bedrock as a CLI, desktop app, and VS Code extension. General availability hasn't been confirmed yet, so production builds should plan for a waiting period.
Is AWS Bedrock cheaper than using the OpenAI API directly?
Not necessarily. Bedrock adds its own markup on top of the provider's base rate, plus you pay for AWS networking, CloudWatch logging, and Bedrock-specific costs. Direct API is usually cheaper for pure token cost. Bedrock's value is in the operational layer — unified billing, IAM auth, VPC isolation, compliance — not in per-token savings.
Can I use both OpenAI and Anthropic Claude on the same Bedrock account?
Yes. That's the main structural change from this announcement. Before May 2026, Bedrock hosted Anthropic, Meta, Mistral, and others — but not OpenAI. Now both major frontier providers (OpenAI and Anthropic) are callable through the same Bedrock API surface, with the same auth and billing.
Does AWS Bedrock support GPT-4?
Not currently. The models announced are GPT-5.5 and GPT-5.4, which are OpenAI's frontier-tier models as of 2026. Older GPT-4 variants aren't listed in the Bedrock catalog. For GPT-4-class workloads, the direct OpenAI API or Azure OpenAI Service remain the current paths.
How does OpenAI on Bedrock compare to Azure OpenAI Service?
Azure OpenAI has been available since 2023 and has broader model coverage and more enterprise deployment options. Bedrock's OpenAI offering is newer and in limited preview. If you're already on Azure or have an existing Azure OpenAI deployment, there's no reason to move. If you're already AWS-native, Bedrock is now a viable alternative to keep your AI traffic inside the same cloud account.
Final Thoughts
OpenAI on Bedrock is a real shift. It changes what's possible, especially for B2B SaaS selling into enterprise. It doesn't change what's necessary for most existing AI SaaS apps that are already shipping.
The right move this week is mostly "watch and read." The right move in three months — when limited preview turns into general availability, when pricing settles, when the integrations mature — will be more concrete.
If you're earlier in the journey and you haven't picked your provider yet, this is the moment to think harder about it than usual. The default of "use OpenAI direct" or "use Anthropic direct" is still defensible. But the calculus around Bedrock and AI gateways is shifting fast enough that the answer that was right last quarter may not be right next quarter.
Posts like Which AI Features Are Actually Worth Building in a SaaS Product Right Now cover the feature side of this question — what to build. This post covers the infrastructure side — where to build it. They go together.
If you'd rather have a single call to figure out what your specific SaaS actually needs first — direct API, Bedrock, or AI gateway — that's exactly what AI SaaS Development covers, and a 20-minute strategy call is usually enough to sort the first few decisions.
Top comments (0)