Amazon Bedrock Agents is now Bedrock Agents Classic and is closed to new customers from July 30, 2026. Existing agents do not stop on that date, but a new AWS account can receive HTTP 403 from CreateAgent or InvokeInlineAgent, and the Classic model catalog is frozen. A safe migration starts with an account inventory, maps behavior rather than resource names, chooses between the AgentCore harness and a code-defined runtime, and proves equivalence with replayable evaluations before traffic moves.

Who is actually affected by maintenance mode?

The AWS maintenance-mode guide defines a narrow but operationally important rule. An account with Bedrock Agents activity during the previous 12 months is allowlisted. An account without prior use receives AccessDeniedException with HTTP 403 when it calls CreateAgent or InvokeInlineAgent. The decision is per account; it does not automatically flow from an AWS Organization, payer account, or active production account.

That makes the first failure more likely in dormant staging, disaster recovery, a newly provisioned customer account, or a project account created by Control Tower than in a busy production environment. The same IaC can succeed in an established account and fail in a fresh one without any change to its IAM policy.

Maintenance mode is also not an end-of-life event. AWS currently states that there is no migration deadline and no planned EOL date. Existing APIs for invoking, updating, listing, aliases, action groups, and knowledge bases remain available. However, the Classic model catalog is frozen at the effective date. Models released later are available through AgentCore, while core Amazon Bedrock inference, Knowledge Bases, and Guardrails continue to receive new models.

Environment Near-term exposure Sensible response
Active production account Existing agents continue running Register the risk and review quarterly
Dormant staging or DR account Twelve-month usage evidence may be unclear Inventory and test in a controlled window
New customer or project account Creation or inline invocation can return 403 Gate account provisioning before deployment
Workload that needs newer models Classic orchestration cannot select them Evaluate AgentCore now

How should you inventory accounts without harming production?

Start with a matrix, not a create call. Record the account, Region, existing agents, most recent verified activity, IaC owner, business criticality, and recovery objective. Default CloudTrail event history may not cover the full twelve-month decision window, so an empty search is not proof that the account is ineligible.

Use a read-only list operation to identify existing resources. The following command is an example of the shape of the check; this article did not run it against an AWS account:

aws bedrock-agent list-agents \
  --region us-west-2 \
  --max-results 20

Reserve an actual admission probe for a purpose-built sandbox. CreateAgent creates a durable resource. InvokeInlineAgent avoids leaving an agent resource, but it can still exercise permissions, model access, and billable inference. A probe therefore needs an approved account, Region, model, budget, and cleanup rule.

Classify the result as confirmed eligible, confirmed maintenance restriction, historical evidence only, or unverified. Do not label every AccessDeniedException as maintenance mode. Service control policies, IAM, Region support, model access, and malformed parameters can also produce authorization failures. Require the documented status and message before assigning the maintenance cause.

If the tool boundary itself still needs hardening, use the existing MCP server security checklist to review approvals, least privilege, and auditability. Admission testing and real business traffic should never share credentials or side-effect permissions.

Should you choose the AgentCore harness or a code-defined runtime?

Map observable behavior before mapping resources. Action groups, knowledge retrieval, sessions, memory, guardrails, code execution, prompt overrides, custom orchestration, and multi-agent collaboration are not a set of one-to-one names.

The AgentCore harness fits a relatively standard agent loop and teams that want a declarative managed experience. A code-defined runtime is a better fit when the current system depends on stage-specific prompts, a custom orchestrator, complex supervisor or router behavior, provider switching, or framework-level control.

Classic dependency Migration question Likely destination
Simple action group Is its contract platform-neutral? Gateway tool or code tool
Knowledge Base Are retrieval and citation semantics explicit? Gateway fronting or a retrieval tool
AMAZON.UserInput Who owns the pause and reply loop? Explicit inline function tool and client control
Four-stage prompt overrides Can one system prompt preserve behavior? Often a code-defined agent or explicit stages
Supervisor or router Is agent-as-tool sufficient? Custom orchestration for complex routing
Custom orchestrator Is a declarative harness still appropriate? AgentCore runtime

The durable design choice is not an SDK. Business goals, tool schemas, idempotency, failure classes, retrieval contracts, and evaluation cases should live outside the vendor adapter. The A2A 1.0 migration guide makes a similar distinction between protocol objects and business state; the same separation reduces risk here.

What does a rollback-safe migration look like?

1. Freeze an evaluation baseline, not feature development

Select representative, sanitized tasks. For each case, record the input, allowed tools, expected business outcome, prohibited actions, and human-review policy. Do not save only the final prose. Preserve tool selection, arguments, authorization decisions, citations, and stop reason so that a behavioral change is visible.

Your baseline should include straightforward successes, missing information, tool timeouts, permission denials, prompt injection attempts, partial downstream failures, and requests that must be refused. A migration that only passes happy-path demos has not tested the most expensive failures.

2. Introduce a platform-neutral runtime boundary

This skeleton illustrates the boundary; it is not a runnable AWS implementation:

class AgentRuntime(Protocol):
    def run(self, task: Task, tools: list[ToolSpec]) -> RunResult: ...

class ClassicAdapter:
    ...

class AgentCoreAdapter:
    ...

Application code depends on AgentRuntime. Tool definitions remain independent and adapters translate them into an action group, MCP tool, or framework tool. Vendor-specific session identifiers and trace formats stay at the edge rather than leaking into business records.

3. Shadow before you canary

Let AgentCore consume the same sanitized requests with side effects disabled. Compare task completion, tool choice, arguments, refusal behavior, latency, token use, and error class. A shadow result must not update customer state and must not reuse an idempotency key that a real executor could consume.

Prompt behavior deserves special attention. Classic stage-level overrides may have performed validation, planning, retrieval response shaping, or post-processing implicitly. Moving those steps into a single system prompt can look correct on easy cases while weakening a boundary on ambiguous ones.

4. Define explicit rollout gates

At minimum, gate on critical-task success, zero prohibited actions, schema-valid tool arguments, latency and cost budgets, citation quality where retrieval is involved, and a tested return to Classic or a manual process. Thresholds must come from your workload. Vendor migration estimates and sample metrics are not production evidence.

5. Give only one runtime the right to act

The worst migration defect is not different wording; it is two runtimes both sending mail, charging a card, deleting a resource, or starting a deployment. During shadowing, only the incumbent executor can produce effects. During canarying, use a shared operation ID and downstream idempotency rules so a retry or failover cannot execute twice.

Observability must move with the workload. The FastAPI OpenTelemetry production guide shows how to carry context across requests and background work. Apply the same principle across the inbound request, agent run, tool call, and durable job, while excluding secrets and sensitive prompt content.

How should IaC change for a multi-account estate?

Do not react to the 403 by broadening IAM. Make the target runtime an explicit deployment input and resolve account capability before the resource phase:

Parameters:
  AgentRuntimeMode:
    Type: String
    AllowedValues: [classic, agentcore]

Use Classic only for an established environment whose eligibility has been verified. Default new environments to the AgentCore path. Both paths can consume the same business configuration, tool schemas, and evaluation data, but their infrastructure resources should be isolated. This avoids a conditional template creating half of each runtime when account state is uncertain.

Region checks must also be component-specific. The official AgentCore Region table separates Runtime, Gateway, Identity, Memory, Observability, Evaluations, and other capabilities. “AgentCore is in this Region” is insufficient if one required component is absent.

For disaster recovery, test the recovery account itself. Production eligibility does not prove that a dormant secondary account can create Classic resources. A recovery plan that relies on creating an agent after the incident needs either confirmed eligibility or a prebuilt AgentCore path.

Which failure modes deserve a review item?

  • Treating maintenance admission as IAM. Teams expand permissions while the per-account rule remains unchanged.
  • Assuming running production proves recoverability. The DR account may have no Classic history.
  • Migrating resources without migrating behavior. Prompt stages, elicitation, return of control, and multi-agent routing drift silently.
  • Allowing the shadow to execute tools. Two runtimes create duplicate external effects.
  • Deleting Classic before the observation window ends. A successful demo is not a rollback test.
  • Converting vendor estimates into a delivery promise. AWS's hours-scale description applies to relatively direct configurations, not every workload.
  • Recording entire prompts for debugging. A useful trace can become a credential and personal-data leak.

AWS publishes the agent toolkit for AWS as migration assistance. Treat it like any privileged automation: pin the reviewed version, run with least privilege, inspect its plan, and keep deletion of source agents outside its authority.

Production migration checklist

  • [ ] Every relevant account and Region has a recorded Classic status.
  • [ ] New-account IaC no longer assumes Classic creation is available.
  • [ ] The harness versus code-defined choice has a written rationale.
  • [ ] Tool schemas, idempotency, timeouts, retries, and approvals are vendor-neutral.
  • [ ] Prompt overrides, user elicitation, multi-agent behavior, and custom orchestration are mapped.
  • [ ] Only one runtime can execute side effects during shadow and canary phases.
  • [ ] Workload-specific quality, safety, latency, cost, and observability gates pass.
  • [ ] Every required AgentCore component is available in the target Region.
  • [ ] A rollback has been exercised before any source resource is removed.

FAQ

Do existing Bedrock agents stop on July 30, 2026?

No. The documented change closes new-customer access and puts Classic into maintenance mode. Existing supported use does not automatically stop on that date, and AWS currently states that no EOL is planned. The frozen catalog and new-account limitation still create a growing architecture constraint.

Can a broader IAM policy fix the 403 in a fresh account?

Not when the response is the documented maintenance-mode admission failure. Verify the message and account history, then separately rule out SCP, IAM, Region, and model-access problems. Granting broad permissions is neither a valid diagnostic nor a workaround for the allowlist.

Must every existing customer migrate immediately?

No. A stable workload with no new-account expansion and no need for newer models can first register the risk and set a review cadence. A long-lived product that provisions new accounts, needs continuing model access, or changes its orchestration frequently has a stronger case for early migration.

When is it safe to delete Classic resources?

Only after real canary traffic, a defined observation period, and a successful rollback exercise. The fact that a migration tool leaves the source untouched does not prove that the surrounding IaC or operator role cannot delete it.

The actionable lesson is larger than one AWS error. A managed orchestration layer needs an explicit replacement boundary. Once account eligibility, tool contracts, behavioral evidence, side-effect ownership, and rollback are visible, maintenance mode becomes a controlled migration rather than a surprise deployment outage.