Amazon Bedrock Agents Classic Enters Maintenance Mode: What to Do Before July 30, 2026

On July 30, 2026, AWS closes new-customer access to Amazon Bedrock Agents — the managed agent orchestration service that launched in November 2023. AWS has renamed it Bedrock Agents Classic and put it into maintenance mode. If you already have an agent running, the panic-inducing headlines are wrong: nothing breaks for you. If you're about to start a new Bedrock agent project, or you're standing up a fresh AWS account, the picture is different, and the exact mechanics of who's affected are easy to get wrong from the blog-post summaries circulating this week. This post works from AWS's own documentation, not the secondhand takes.

What "maintenance mode" actually means

AWS determines eligibility per AWS account, based on usage history, not a global cutoff:

• If your account has called Bedrock Agents APIs (created or invoked an agent) at any point in the preceding 12 months, your account is allowlisted. You keep full access, including CreateAgent, indefinitely.
• If your account has no Bedrock Agents usage in that window, starting July 30, 2026 it loses access to CreateAgent and InvokeInlineAgent. Every other API — GetAgent, ListAgents, DeleteAgent, PrepareAgent, InvokeAgent, action group APIs, alias APIs, knowledge base APIs — stays available to everyone, allowlisted or not.

This is not a shutdown. It's a freeze on new adoption. AWS is explicit that there is no planned end-of-life date for Bedrock Agents Classic and no forced migration deadline for existing workloads. What's actually frozen is the model catalog: any Bedrock model released after July 30, 2026 will not be addable to a Classic agent. New models only show up in AgentCore from that point forward.

If you try to create an agent on a non-allowlisted account after the cutoff, you'll get:

1Error Code: AccessDeniedException (HTTP 403)
2Message: "Bedrock Agents is in Maintenance Mode. New agent creation
3is not available for accounts without prior service usage."

There is no exception process. AWS determines the allowlist automatically from account activity — you can't file a support case to get an unallowlisted account added.

Why this matters even if your account is allowlisted

Three second-order effects that the FAQ buries but that change real decisions:

1. Multi-account setups break silently. If you provision fresh AWS accounts per environment (common in landing-zone and AWS Organizations setups) and your prod account has Agents history but your new staging or sandbox account doesn't, CreateAgent in the new account will 403 even though your org has been using Bedrock Agents for years. Allowlisting is per-account, not per-organization.
2. The model catalog freeze is the real forcing function. Existing agents keep working forever, but they're frozen on today's models. If you want Claude's or Amazon's next-generation models in an agent six months from now, that agent has to be on AgentCore — Classic won't get it.
3. IaC still works, but only for allowlisted accounts. CloudFormation, CDK, and Terraform templates that create AWS::Bedrock::Agent resources continue to function normally for accounts with prior usage. Point that same template at a brand-new account after July 30 and the stack creation fails with the same AccessDeniedException.

Migration path: AgentCore

AWS's recommended target is Amazon Bedrock AgentCore, and there are two ways to land there:

• AgentCore managed harness — the closest analog to Bedrock Agents Classic. You declare model, tools, and system prompt; AgentCore owns compute, memory, identity, and observability. Start here unless you have a specific reason not to.
• Code-defined agents on AgentCore — full control over the orchestration loop, for workloads that need multi-agent collaboration, custom orchestrators, or a specific framework (Strands, LangChain, OpenAI Agents SDK, Claude Agent SDK). Still runs on AgentCore's managed infrastructure, but you own the agent loop.

Feature mapping you'll actually need

The prompt-override and multi-agent rows are where migrations get real effort, not the happy-path model+tools+KB agents.

Manual migration with the AgentCore CLI

 1# 1. Create the harness
 2agentcore create --name my-research-agent
 3
 4# 2. Add tools (browser, code interpreter, or your existing action groups via gateway)
 5agentcore add tool --harness my-research-agent \
 6  --type agentcore_browser --name browser
 7
 8agentcore add tool --harness my-research-agent \
 9  --type agentcore_gateway --name my-gateway \
10  --gateway-arn arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gw
11
12# 3. Set model and system prompt
13agentcore add harness \
14  --name my-research-agent \
15  --model-id us.anthropic.claude-sonnet-4-6-20250514-v1:0 \
16  --system-prompt "You are a research assistant." \
17  --tools agentcore-browser,my-gateway
18
19# 4. Deploy and invoke
20agentcore deploy
21agentcore invoke --harness my-research-agent \
22  --session-id "$(uuidgen)" \
23  "Research tropical vacation options under $3k"

Memory is on by default and scoped per session. To isolate memory per end user, pass --actor-id:

1agentcore invoke --harness my-research-agent \
2  --session-id "$(uuidgen)" --actor-id alice \
3  "What did we discuss about the Portugal trip?"

You can also override the model on a single invocation without redeploying the harness — useful for A/B testing a new model against your production one:

1agentcore invoke --harness my-research-agent \
2  --model-id us.anthropic.claude-opus-4-5-20251101-v1:0 \
3  "Summarize this research paper"

The automated path

AWS ships an amazon-bedrock skill inside the agent toolkit for AWS that inspects an existing Bedrock Agent, checks migration eligibility, maps each component to its AgentCore equivalent, and drives the CLI to scaffold and deploy the harness. It does not modify your source agent, and it pauses for approval before deploying anything. If a feature has no validated harness path (most often stage-specific prompt overrides or full multi-agent routing), the skill stops and tells you rather than guessing. For a straightforward model + action groups + knowledge base agent, expect this to take hours, not days; the remaining effort is reviewing generated code and redeploying action groups behind the gateway.

Best practices

• Check allowlist status before you need to, not during an incident. Run CreateAgent in a low-stakes test in every AWS account your org actually provisions new environments in — don't assume org-wide history covers a brand-new account.
• Treat the model catalog freeze as your real deadline, not July 30 itself. If your roadmap assumes access to models released after that date, plan the AgentCore migration now regardless of allowlist status.
• Migrate simple agents first. Model + action groups + knowledge base agents map cleanly to the harness. Save the multi-agent and prompt-override migrations for when you've got one clean migration under your belt.
• Keep IaC pointed at Classic only where it's proven to work — for allowlisted accounts. For any new account provisioning, write the AgentCore resources into the template from day one rather than hitting the 403 in CI.

Common mistakes to avoid

• Assuming "maintenance mode" means "shut down." It doesn't. Don't panic-migrate a stable production agent that has no near-term need for new models — that's effort spent on schedule pressure that doesn't exist.
• Assuming allowlisting is account-wide across an AWS Organization. It's per-account. Verify each account individually.
• Skipping the eligibility check on Classic Bedrock resources in Terraform/CDK before provisioning a new environment. A stack that worked in your existing account can fail outright in a fresh one.
• Trying to replicate stage-specific prompt overrides with a single system prompt and expecting identical behavior. It won't be identical — budget review time for orchestration logic that depended on pre/post-processing hooks.

Troubleshooting

AccessDeniedException on CreateAgent in an account you believe should be allowlisted. Confirm the account (not the IAM role, not the organization) has actually invoked or created a Bedrock Agent within the trailing 12 months. Usage in a different account in the same org does not count.

IaC stack fails on AWS::Bedrock::Agent creation in a new account. This is expected post–July 30 behavior for non-allowlisted accounts, not a bug. Switch the template to provision AgentCore resources instead.

Migrated harness doesn't reproduce your old agent's pre-processing behavior. This is the known gap — Classic's stage-specific prompt overrides don't map directly to the harness's single system prompt. You'll need to either move that logic into your tool code or use code-defined agents on AgentCore instead of the harness.

FAQ

Do I have to migrate immediately? No. AWS states there is no migration deadline for existing agents and no planned end-of-life for Bedrock Agents Classic. The forcing function is the frozen model catalog, not a shutdown date.

Will my existing agents stop working on July 30? No. All existing agent APIs remain available to all customers regardless of allowlist status. Only CreateAgent and InvokeInlineAgent are restricted, and only for accounts without prior usage.

Does this affect Bedrock itself — models, Knowledge Bases, Guardrails? No. Amazon Bedrock continues to be fully supported and continues receiving new models. Only the Bedrock Agents Classic orchestration layer is affected.

Is there a cost difference for AgentCore? AgentCore uses consumption-based pricing with no separate orchestration charge. AWS notes the harness is more token-efficient than Classic's internal prompt scaffolding, so inference costs are often comparable or lower — but validate this against your own agent's actual token usage rather than assuming it.

What if AgentCore isn't available in my region yet? Continue running Bedrock Agents Classic in that region for allowlisted accounts while migrating new development to a supported region. Check the AgentCore regions list before committing to a migration timeline.

Key takeaways

Further Reading

• Amazon Bedrock AgentCore Goes GA: Build Smarter AI Assistants Now
• Amazon Bedrock AgentCore Runtime: Stateful MCP
• AWS Bedrock IAM Cost Allocation: Control Your AI Spending
• Amazon Bedrock Agents Classic maintenance mode — official AWS docs
• AgentCore Developer Guide