Amazon Bedrock Managed Agents powered by OpenAI: running OpenAI on AWS, and why you might consolidate
Already running OpenAI, and wondering whether to pull it into AWS? We can help you scope the move.
As an AWS Partner, Devopsity helps teams consolidate scattered AI usage - OpenAI API keys, ad-hoc logging, data leaving your boundary - into one governed AWS estate: a single identity model, one audit trail, one bill. We can secure proof-of-concept funding to evaluate Bedrock Managed Agents on a real workload. Talk to us about consolidating OpenAI onto AWS.
What was announced
In its weekly roundup on 5 October 2026, AWS announced the public preview of Amazon Bedrock Managed Agents powered by OpenAI. The short version: you can now build agents optimised for OpenAI models that run inside AWS, wired into AWS resources, under the IAM roles, permissions, and governance controls your organisation already uses.
Two details matter more than the headline:
- It is built on a customised, AWS-native version of OpenAI’s Agents API. This is not a thin proxy to the public OpenAI endpoint. The Agents API has been engineered to run as an AWS-integrated service, so the agents behave like first-class AWS citizens rather than an external dependency you call out to.
- You choose the execution environment. Either self-hosted compute (an existing development machine, container, or compute environment you already run) or Amazon Bedrock AgentCore Runtime, which gives you managed runtime sessions and configurable storage in your own AWS account.
For the deep dive on AgentCore Runtime itself - what it is and what it costs - see our write-up on Amazon Bedrock AgentCore architecture, components, and pricing. Here, AgentCore is simply one of the two places your OpenAI agents can run.
Running OpenAI on AWS: the execution-environment choice
The feature does not force a single deployment model, which is the point. You pick based on where you already are:
- Self-hosted compute - run the agents on compute you already operate. This suits teams with an established platform (an EKS cluster, existing containers, a build-and-run environment) that want the OpenAI agents to sit alongside everything else, on infrastructure they already govern and pay for.
- Bedrock AgentCore Runtime - let AWS manage the runtime sessions and storage, inside your account. This suits teams that do not want to stand up and operate an agent runtime, and would rather consume it as a managed service with the storage staying in their own AWS boundary.
If you are weighing managed runtime against self-hosting more generally, we worked through that exact decision - managed AgentCore vs self-hosted on EKS vs a framework platform - in Bedrock AgentCore vs self-hosted vs frameworks. The same trade-offs apply here, with OpenAI as the model layer.
Deciding whether to run your OpenAI agents on AWS?
Book a free 30-min call
The benefits: why you might consolidate
The interesting question is not “can I run OpenAI on AWS” - it is “should I move the OpenAI usage I already have onto this?” For a lot of teams, OpenAI today means a direct API key, logging bolted on by hand, data flowing to an endpoint outside their cloud, and a separate invoice nobody in the AWS cost reporting sees. Managed Agents powered by OpenAI is the first clean answer to that sprawl.
| Dimension | OpenAI direct (typical today) | Bedrock Managed Agents powered by OpenAI |
|---|---|---|
| Identity | Separate API keys to issue, rotate, and leak-proof | Your existing AWS IAM roles and permissions |
| Governance / audit | Bolt-on logging; a second system to reason about | CloudTrail and the guardrails you already run |
| Data boundary | Requests leave for an external endpoint | Runs inside your AWS account; storage in your account |
| Billing | A separate invoice outside AWS cost reporting | One AWS bill, visible to your existing FinOps |
| Model choice | OpenAI only | OpenAI alongside Claude, Grok, and others on Bedrock |
Be honest about what this does not do. It does not automatically make the tokens cheaper - you are consolidating governance and operations, not negotiating a model discount. It is a public preview, so it is not something to put a production SLA behind yet. And model-version availability varies by region, so the specific OpenAI model you want may not be in your preferred region on day one. The win is control and consolidation, not a cost silver bullet.
The wider picture: Bedrock as the multi-provider control plane
OpenAI did not arrive on Bedrock alone. The same October announcement added a batch of frontier models to Bedrock - OpenAI GPT-6.1 Sol and a GPT-6 Astra UltraFast speed tier, Anthropic Claude Sonnet 5.5, and SpaceXAI Grok 4.7 (model line-ups as announced in October 2026; expect them to move).
The pattern underneath the news is the one worth acting on: Bedrock is becoming the place you reach every frontier model through one control plane, one set of permissions, one audit trail. OpenAI joining that set is exactly what makes consolidation a real option rather than a slogan - you are no longer choosing between “all-in on one provider” and “a mess of separate integrations.” For the model-hosting side of this picture - Bedrock vs SageMaker vs self-hosting your own inference - see running LLM inference on AWS.
When this is the right move, and when it is not
| It fits when... | It is not the obvious pick when... |
|---|---|
| Your infrastructure is already on AWS and you want OpenAI under the same governance | You are not on AWS and have no plan to be - the governance benefit is the whole point |
| You have OpenAI usage spread across keys, teams, and providers with no shared oversight | You run a single provider cleanly and already have the governance you need |
| Data boundary and audit matter for compliance, and you want requests inside your account | You need a production SLA today - this is a public preview |
| You want one bill and your existing FinOps to see the AI spend | Your required OpenAI model version is not yet available in your region |
A simple rule: this is strongest when the control around your AI usage matters - identity, audit, data boundary, cost visibility - and when AWS is already your home. If you are off AWS, or genuinely happy with a single clean OpenAI integration, there is less here for you today.
Governance at scale: the same story as agent sprawl
Consolidating providers is the same problem as consolidating agents, one layer up. We have written about agent sprawl - different teams shipping agents on different stacks with no shared oversight - and the answer there is a shared, governed way to build. Managed Agents powered by OpenAI is a provider-level version of the same move: instead of OpenAI living outside your governance as a special case, it comes inside the estate you already run. If you are thinking about this at organisation scale, our write-up on AWS Loom for governing AI agents covers the governance layer that sits above individual runtimes.
FAQ
Can I run OpenAI models on AWS now? Yes. Amazon Bedrock Managed Agents powered by OpenAI entered public preview in October 2026. It lets you build and run OpenAI-model agents inside your own AWS account, on an AWS-native version of OpenAI’s Agents API.
How is this different from calling the OpenAI API directly? Direct API usage lives outside your cloud: separate keys, bolt-on logging, data leaving for an external endpoint, and a separate bill. Running it through Bedrock puts the same models under your existing AWS IAM, CloudTrail, guardrails, data boundary, and billing.
How is it different from Azure OpenAI? Both let you reach OpenAI models inside a cloud’s governance. The difference is simply which cloud: if your estate, identity, and compliance already live in AWS, Bedrock Managed Agents keeps OpenAI in that same boundary rather than adding Azure as a second governed surface. It is a fit question, not a better/worse one.
Does my data leave my AWS account? The agents run inside your AWS account, and with AgentCore Runtime the runtime sessions and storage are configured in your account. As with any preview, confirm the current data-handling details in the AWS documentation for your region before putting regulated data through it.
Is it production-ready? It is a public preview. Treat it as something to evaluate and pilot, not to put a production SLA behind yet.
Do I have to use AgentCore Runtime? No. You can run the agents on your own self-hosted compute instead - an existing machine, container, or compute environment - or use AgentCore Runtime for a managed option. The choice is yours.
Summary
Amazon Bedrock Managed Agents powered by OpenAI is a small announcement with a big implication: OpenAI is now something you can run inside your own AWS governance, not just a separate API you call out to.
Three things to remember:
- It runs OpenAI inside your AWS account - your IAM, your audit trail, your data boundary, your bill - on an AWS-native build of OpenAI’s Agents API, with a choice of self-hosted compute or AgentCore Runtime.
- The real value is consolidation, not a discount. If your OpenAI usage is scattered across keys and providers today, this is the clean path to pull it into one governed estate. It does not make tokens cheaper, and it is still a public preview.
- It makes Bedrock the multi-provider control plane. OpenAI now sits alongside Claude and Grok behind one set of permissions - which is what turns “consolidate your AI usage” from a slogan into a concrete move.
Thinking about consolidating your OpenAI usage onto AWS?
Book a free 30-minute call. We help teams pull scattered AI usage into one governed AWS estate - identity, audit, data boundary, and cost visibility - and can secure proof-of-concept funding to evaluate Bedrock Managed Agents on a real workload.
![Amazon Bedrock AgentCore Pricing [2026]: Per-Component Rates + TCO](/img/blog/post/2026-08-11/360x220.webp)
