Bedrock Managed Agents, powered by OpenAI, moved to public preview on 29 September 2026, according to AWS's What's New post. It's available in three US regions, and it follows an April limited preview with no regions or pricing attached. Our verdict: worth a sandbox test now, not a production commitment. AWS itself says preview functionality and APIs can change, and the limits below are real. For the wider picture of how releases like this affect your stack, see AI model releases and pricing: what changes for engineering teams.
This isn't a first launch, so don't read it as one. AWS announced "Amazon Bedrock now offers OpenAI models, Codex, and Managed Agents (Limited Preview)" on 28 April 2026. The September post is the step to public preview, with regions and a pricing statement.
What Bedrock Managed Agents is
AWS describes it as a customized version of OpenAI's Agents API, running through Bedrock. A session holds the conversation and the model calls. The tools don't run there. Per the preview user guide, tools execute in the compute environment you provide, either self-hosted or on AgentCore Runtime.
So "managed" covers the agent loop, not your tool code. If your agent runs shell commands or hits an internal API, that runs in your account, on your compute, under your network rules. That's a sensible split, and it also means most of your risk sits in code you own.
Requests are signed with the endpoint's Region and the signing service bedrock-mantle. AWS's quotas and limitations page (covered below) is also blunt that OpenAI-hosted Agents APIs and Managed Agents don't necessarily expose the same features or change at the same time. If you've built against OpenAI's hosted API, check feature parity before assuming a port. AWS hasn't published a supported-model list for the preview, so don't assume any particular OpenAI model is available. For what OpenAI's current flagship costs, our GPT-6 Astra release: pricing, context, API changes write-up has the numbers. This page covers the AWS layer.
What AWS teams get versus calling OpenAI directly
The pitch is that the agent becomes an AWS workload rather than a vendor integration.
The announcement describes per-agent IAM. In the user guide, each session runs under an IAM role you supply, passed as role_arn. Authentication uses SigV4, and per AWS's security documentation, you don't need an OpenAI API key. For a team whose security review stalls on "another third-party secret in the pipeline," that's the main selling point. The April announcement also says usage "can be applied toward existing AWS cloud commitments," which matters if procurement already has an AWS commitment and doesn't want a new vendor.
The announcement says supported API activity is recorded in CloudTrail. The security guide doesn’t mention CloudTrail, so treat the announcement as the source and confirm the events in your own account (more on that below).
The IAM model involves three identities, and mixing them up is the likeliest early mistake:
- The caller, which creates the session. It needs
iam:PassRoleon the session role. - The session role, passed in as
role_arn, which defines what the agent itself can do. - The execution environment, where your tools run, with whatever permissions that compute has.
Scope each one separately. A tight session role doesn't help if the compute underneath can reach everything. Teams working out how to write those permissions may also want our piece on agent governance for engineering teams, which covers a similar governance question (permissions, audit, cost) in another tool.
One gap between the announcement and the docs deserves attention. The announcement mentions human approval before consequential actions. The security guide says that for actions with external effects, you should enforce authorization and any required human review in the application or tool implementation. Read that literally: approval gating is something you build or configure in your own code, not a documented service switch. Don't plan around a built-in approval UI.
What the preview does not give you
The limits come from AWS's quotas and limitations page.
| Area | Preview status |
|---|---|
| Regions | us-east-1, us-west-2, us-east-2 only |
| Cross-Region inference profiles | Not supported by this workflow |
| Subagents | Not supported |
| Session input | Documented surface is text |
| Customer-managed KMS key | Not exposed |
| MCP | Environment-based STDIO servers |
| API stability | Preview functionality and APIs can change |
AWS's security documentation also notes that deleting a session doesn't remove copies of data held in customer-managed files or external tools. If your tools write transcripts or artifacts somewhere, you own that cleanup.
EU and data residency
No EU region is in the preview. The source lists US East (N. Virginia), US West (Oregon) and US East (Ohio), and that's it. Cross-Region inference profiles aren't supported in this workflow either, so there's no EU-routed workaround through them.
EU teams have no in-region option today. Add the missing customer-managed KMS key setting for session data, and anything regulated is a poor fit for now.
Some secondary coverage claims data never leaves AWS. The preview user guide doesn't state a residency guarantee, so we won't repeat one. What the docs do support is IAM, SigV4 signing, and customer-owned compute and storage for tools. Whether session data stays in a given geography is a question to put to AWS before you send anything personal through it. If you're weighing the same question for another provider, our note on DeepSeek V4.1 Flash and EU data shows what a data-handling check looks like.
What it costs
During preview, AWS says there's no additional charge for Managed Agents itself, beyond the underlying AWS resources your agents consume. AWS also says pricing is subject to change at general availability, so don't build a business case on "free."
That doesn't make a session free. The user guide's Charges section says: "You incur charges for model inference and the AWS resources that your application uses." So you pay for every model call, plus the infrastructure around it. The AgentCore example creates a NAT gateway, and a deployed stack can continue to incur charges when no turn is running. A forgotten test stack costs money while doing nothing.
What to test now
- Create a session with a tightly scoped role, and confirm the caller really needs
iam:PassRoleand nothing broader. - Check CloudTrail for the events you expect. The announcement says they exist, so verify it for your audit needs.
- Run an environment-based STDIO MCP server, since that's the documented route.
- Check which models are available in your Region and account. Don't assume a list. If you also run Claude on Bedrock, our Claude Sonnet 5.5 migration notes cover its breaking API changes and Bedrock availability.
- Build and test the human-review path in your own tool code, with a case where the reviewer says no.
- Tear down the example stack, NAT gateway included, when you're done.
FAQ
Is Bedrock Managed Agents generally available?
No. It's in public preview as of 29 September 2026, after a limited preview announced in April. Preview functionality and APIs can change.
Which regions support it?
US East (N. Virginia), US West (Oregon) and US East (Ohio), which are us-east-1, us-west-2 and us-east-2.
Is there an extra charge?
Not for Managed Agents itself during preview. You still pay for model inference and the AWS resources your application uses. AWS says pricing is subject to change at general availability.
Does it work in the EU?
Not in-region. No EU region is in the preview, and cross-Region inference profiles aren't supported in this workflow. The docs don't state a residency guarantee.
Do I need an OpenAI API key?
No. The security documentation says these agents don't require one. Requests are signed with SigV4 instead.
Does it support subagents?
No. The quotas and limitations page lists subagents as not supported in the preview.