Amazon Bedrock AgentCore in July 2026: unified observability and 5,000-session scaling for production agents

Summary. On July 20, 2026 Amazon Bedrock AgentCore began delivering every agent trace, prompt and structured log to a single per-agent Amazon CloudWatch log group, and AWS documented the change on July 23, 2026. Three weeks earlier, on July 1, 2026, AWS raised the default runtime ceiling to 5,000 active concurrent sessions in US East (N. Virginia) and US West (Oregon), and 2,500 in every other supported Region, with all Regions now allowing 200 agent interactions per second and 25 new sessions per second. AgentCore runtime bills $0.0895 per vCPU-hour and $0.00945 per GB-hour at per-second granularity. For teams that shipped agents on the platform since its general availability across nine Regions in October 2025, these two changes decide how you debug an incident and how far a single deployment scales. This guide covers what moved, the exact configuration to migrate an existing runtime, and the capacity and cost math that follows.

The gap these changes close is the one every team hits after the demo works. Building an agent is now a weekend. Operating one that survives real traffic, real permissions and real bugs is the hard part, and it is where most agent projects stall. At AWS re:Invent 2025, Dr. Swami Sivasubramanian, AWS vice president of Agentic AI, put the observability case in one line: "you simply can't fix what you can't see." The July release is AWS acting on that, moving the platform's debugging surface from scattered to unified.

What changed in July 2026

Two separate announcements land in the same production workflow.

The first is unified observability, posted on July 23, 2026. Previously AgentCore split an agent's telemetry across destinations: trace spans went to a shared aws/spans log group, while event logs carrying prompts, inputs and outputs went to a separate resource-specific log group. Debugging one bad invocation meant searching across at least two log groups and stitching the timeline back together by hand. From July 20, 2026, all of an agent's telemetry, traces, prompts, structured logs and standard output, lands in a single per-agent log group named /aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>.

The second is the quota increase, posted on July 1, 2026. The default runtime limits moved to 5,000 active concurrent sessions in US East (N. Virginia) and US West (Oregon), 2,500 in all other supported Regions, plus 200 agent interactions per second and 25 new sessions per second everywhere. Those are defaults, not ceilings you have to file a support case to reach, so a new deployment handles high-throughput load out of the box.

Neither change alters your agent code. Both change how you run it. If you already read our walkthrough on how to build an AI agent on Amazon Bedrock AgentCore, treat this as the operations layer that sits on top.

Unified observability: one log group per agent

The old model failed in a specific way. When an agent produced a wrong answer, the reasoning trace (which tool it called, in what order, with what arguments) sat in the aws/spans group, and the actual prompt and model output sat elsewhere. Correlating them across a multi-agent system, where several agents interleave, was slow and error-prone. You also could not apply fine-grained access control or customer-managed key (CMK) encryption at the level of an individual agent, because the telemetry was pooled.

The unified model fixes all three problems at once. Because every signal for one agent now lands in one log group, you can:

• Correlate a trace and its prompt or output in a single place, without cross-referencing timestamps between groups.
• Scope AWS Identity and Access Management (IAM) policies and CMK encryption to an individual agent, so one team's prompts stay readable only to that team.
• Export everything by subscribing a single log group to a destination, instead of wiring up two subscriptions per agent.

For a multi-agent system, each agent's full execution history stays together, which is the difference between a 5-minute root-cause and a 50-minute one.

Before and after

Dimension	Before July 2026	After July 20, 2026
Trace spans destination	Shared aws/spans log group	Per-agent group /aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>
Prompts, inputs, outputs	Separate resource-specific log group	Same per-agent group
Cross-signal correlation	Manual, across ≥2 log groups	Single group, one query
Per-agent IAM and CMK scoping	Not possible on pooled telemetry	Supported per agent
Telemetry export	Multiple subscriptions	One subscription per agent

Migrating an existing agent

New agents created from July 20, 2026 in supported Regions use unified observability by default, with no configuration. Existing agents need two deliberate steps:

1. Set the environment variable UNIFIED_TRACES_DESTINATION_ENABLED=true on the agent runtime.
2. Upgrade the AWS Distro for OpenTelemetry (ADOT) to version 0.17.1 or later.

# On the agent runtime configuration
UNIFIED_TRACES_DESTINATION_ENABLED=true

# In your build (Python example): pin ADOT to a supported version
pip install "aws-opentelemetry-distro>=0.17.1"

The feature is available in all AWS commercial Regions where AgentCore Runtime is supported, per the AWS observability configuration guide. Because the log-group name is deterministic (/aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>), you can pre-provision CloudWatch metric filters, subscription filters and CMK grants in your infrastructure-as-code before you flip the flag, so the switch is a no-downtime change rather than a scramble.

One caveat worth planning for: unifying telemetry into one group means your prompts and model outputs now sit in the same place as your traces. That is convenient for debugging and a reason to get the per-agent IAM and CMK scoping right, especially where prompts carry personal data.

Scaling: the new quota ceilings and what they mean

The July 1, 2026 defaults change capacity planning for anyone sizing a fleet.

Quota	US East (N. Virginia), US West (Oregon)	Other supported Regions
Active concurrent sessions	5,000	2,500
Agent interactions per second	200	200
New sessions created per second	25	25
Billing granularity	Per second, 1-second minimum	Per second, 1-second minimum
Minimum memory billed	128 MB	128 MB

A "session" here is a live agent conversation holding state, not a single request. The interaction rate (200 per second) governs throughput within existing sessions; the new-session rate (25 per second) governs how fast you can open fresh ones. For a customer-support agent averaging, say, three-minute sessions, 25 new sessions per second implies a very large working set before you approach the 5,000 or 2,500 concurrent ceiling. Read the two limits together: a slow trickle of long sessions and a fast churn of short ones stress different quotas.

Two planning notes. First, the 5,000-session tier is US-only; every other Region, including Asia Pacific (Mumbai), sits at 2,500 by default, which matters if your data-residency choice pins you outside the United States. Second, these are per-Region defaults, so a multi-Region deployment multiplies headroom but also multiplies the number of log groups and metrics you now have to watch. The full table lives in the AgentCore quotas documentation.

What to actually instrument

Unified logs are the storage layer. The signal you watch on top of them is where operations gets real. AgentCore runtime and built-in tools publish an ActiveSessionCount metric to the AWS/Bedrock-AgentCore CloudWatch namespace, once per minute per service type, with a Service dimension whose values include AgentCore.Runtime, AgentCore.CodeInterpreter and AgentCore.Browser, per the AgentCore provided-metrics reference. That single gauge, plotted against the 5,000 or 2,500 ceiling, is your earliest capacity warning.

A workable production dashboard for an agent fleet tracks four things:

• ActiveSessionCount per Service dimension against the Region's concurrent-session limit, to see headroom before it runs out.
• New-session rate against the 25 per second limit, to catch throttling under launch spikes.
• Trace latency: AWS reduced put-to-get latency for complete traces (spans and logs) to under 10 seconds in a April 2026 update, so anything materially slower points at a problem.
• Tool-call error rate and token consumption per agent, read from the now-unified traces.

For teams running many agents across accounts, AgentCore's cross-account observability lets a central monitoring account link source accounts: each monitoring account can link up to 100,000 log groups, and each source account can share with up to five monitoring accounts. That is how a platform team gives itself one pane of glass without pulling every workload into one account. The evaluation side matters as much as the metrics side; our note on agent evals in CI/CD and silent failures covers the failure mode where an agent regresses quietly and no gauge moves.

If you standardise your tracing on open conventions, the migration is easier still. AgentCore emits through ADOT, so the same spans map onto the OpenTelemetry GenAI conventions for LLM and agent tracing you may already run for non-AWS models.

The cost angle: why unified logs help FinOps

Observability is also a billing story, because agent telemetry is verbose and CloudWatch charges for ingestion and storage. Two things in the July release change the cost picture.

First, per-agent log groups make per-agent cost attribution possible. When every trace, prompt and log for one agent lands in one deterministically-named group, you can tag, budget and charge back at the agent level instead of guessing. That answers the question every platform owner eventually asks: which agent is costing me the most?

Second, the runtime pricing model rewards the design AgentCore already encourages. Runtime bills $0.0895 per vCPU-hour and $0.00945 per GB-hour, per second, and CPU is charged only on active use, so the idle time an agent spends waiting on a model response or a tool call accrues no CPU charge. Memory, though, is billed on peak footprint for the full session duration, so a leaky agent that holds a large working set across long sessions pays for that memory even while it waits. Gateway adds $0.005 per 1,000 tool invocations.

Component	Rate (as of July 2026)	Billed on
Runtime CPU	$0.0895 per vCPU-hour	Active CPU only, per second
Runtime memory	$0.00945 per GB-hour	Peak footprint, full session
Gateway tool calls	$0.005 per 1,000 invocations	Per invocation
Minimum memory	128 MB	Per session
Model tokens	Priced separately	Amazon Bedrock model rates

The FinOps read: measure memory peak per agent, not just CPU, and use the unified log group to attribute both. The single largest lever is usually session lifetime, because memory bills for the whole session even during I/O wait. Teams sizing an Indian cloud budget can pair this with our guidance on cloud FinOps for Indian teams, where the same "measure before you cut" discipline applies.

A migration checklist

For an existing AgentCore deployment, the July 2026 changes come down to a short, ordered list:

1. Pin ADOT to 0.17.1 or later in every agent build.
2. Pre-provision the per-agent log group name in infrastructure-as-code, plus its metric filters, subscription filters and CMK grants.
3. Set UNIFIED_TRACES_DESTINATION_ENABLED=true on each runtime and roll it out per agent, verifying telemetry lands in the new group before removing old subscriptions.
4. Add ActiveSessionCount alarms per Service dimension, thresholded against your Region's concurrent-session limit (5,000 or 2,500).
5. Re-check your Region choice against the session ceiling and your data-residency requirement.
6. Add per-agent cost attribution using the new log-group boundary, watching memory peak as closely as CPU.

Governance sits alongside this. The per-agent IAM and CMK scoping the release enables is a control you should actually use, not just a capability; our write-up on enterprise AI agent governance layers maps where telemetry access fits in a wider control set. If you are still on the older Bedrock Agents stack, the sequencing question is covered in Bedrock Agents Classic maintenance mode and the AgentCore migration.

India-specific considerations

For teams building in or for India, three points follow directly from the July changes.

The Asia Pacific (Mumbai) Region has been a general-availability AgentCore Region since October 2025, so you can keep agent runtime, tools and observability in-country. That helps where the Digital Personal Data Protection Act, 2023 (DPDP) shapes where personal data can sit. The tradeoff is the quota tier: Mumbai carries the 2,500 concurrent-session default, half of the 5,000 available in the two US Regions, so a large India-resident fleet plans capacity against the lower number or spreads across Regions.

Unified observability raises a DPDP-relevant design point. Because prompts and outputs now share a log group with traces, and agent prompts often contain personal data, the per-agent CMK encryption and IAM scoping are the controls that keep that log group defensible. We design applications aligned with DPDP requirements rather than claiming certification, and the encryption-at-the-agent boundary is exactly the kind of control that makes an alignment argument concrete.

Finally, grounding. AWS made a managed Web Search tool generally available for AgentCore on June 17, 2026, as a Model Context Protocol (MCP) connector on AgentCore Gateway, returning snippets, source URLs, titles and publication dates with zero data egress from your AWS environment. At launch it is available only in US East (N. Virginia), so an India-resident agent that needs grounded web answers has an architecture decision to make between residency and that specific tool.

FAQ

What actually changed in Amazon Bedrock AgentCore in July 2026?

Two things. On July 20, 2026 AgentCore began sending every agent trace, prompt and log to a single per-agent CloudWatch log group, documented on July 23. On July 1, 2026 AWS raised default runtime limits to 5,000 concurrent sessions in two US Regions and 2,500 elsewhere.

Do I need to change my agent code for unified observability?

No. The change is operational, not code-level. New agents created from July 20, 2026 use the single log group by default. Existing agents need the environment variable UNIFIED_TRACES_DESTINATION_ENABLED=true on the runtime and the AWS Distro for OpenTelemetry upgraded to version 0.17.1 or later.

Where does AgentCore now send agent telemetry?

Everything for one agent, its traces, prompts, inputs, outputs and standard output, goes to a per-agent log group named /aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>. Previously trace spans went to a shared aws/spans group while prompts and outputs sat in a separate resource-specific group, which made correlation slow.

What are the new AgentCore concurrency limits?

The default limits are 5,000 active concurrent sessions in US East (N. Virginia) and US West (Oregon), and 2,500 in all other supported Regions. All Regions allow 200 agent interactions per second and 25 new sessions created per second. These are per-Region defaults you get without filing a case.

How much does AgentCore runtime cost?

As of July 2026, runtime bills $0.0895 per vCPU-hour and $0.00945 per GB-hour at per-second granularity, with a 1-second minimum and 128 MB minimum memory. CPU is charged on active use only, so I/O wait accrues no CPU charge. Gateway adds $0.005 per 1,000 tool invocations.

Which metric should I watch to avoid hitting the session ceiling?

Watch ActiveSessionCount, published to the AWS/Bedrock-AgentCore CloudWatch namespace once per minute per service type, with a Service dimension for Runtime, Code Interpreter and Browser. Plot it against your Region's concurrent-session limit of 5,000 or 2,500, and alarm before you approach it.

Does the Mumbai Region get the same limits as the US?

No. Asia Pacific (Mumbai) has been a general-availability AgentCore Region since October 2025, but it carries the 2,500 concurrent-session default, half the 5,000 available in US East (N. Virginia) and US West (Oregon). Plan India-resident fleet capacity against the lower ceiling or spread across Regions.

How do the July changes help control cost?

Per-agent log groups make per-agent cost attribution possible, so you can tag, budget and charge back by agent instead of guessing. Because runtime memory bills on peak footprint for the full session while CPU bills only on active use, watching memory peak per agent through the unified log group is the main lever.

How eCorpIT can help

eCorp Information Technologies (eCorpIT) is a Gurugram-based, senior-led engineering organisation, ISO 27001:2022 certified and assessed at CMMI Level 5, that takes AI agents from prototype to dependable production on AWS. We wire up per-agent observability, ActiveSessionCount alarms, per-agent cost attribution and DPDP-aligned encryption boundaries so an agent fleet stays debuggable and within budget as it scales. If you are moving agents onto AgentCore or hardening ones already there, talk to our team about an operations and FinOps review.

References

1. Amazon Bedrock AgentCore now delivers unified observability with traces and logs in a single log group — AWS What's New (July 23, 2026)
2. Amazon Bedrock AgentCore increases default runtime quota limits — AWS What's New (July 1, 2026)
3. Release notes for Amazon Bedrock AgentCore — AWS Documentation
4. Amazon Bedrock AgentCore provided observability metrics — AWS Documentation
5. Configure observability for Amazon Bedrock AgentCore — AWS Documentation
6. Amazon Bedrock AgentCore quotas and limits — AWS Documentation
7. Announcing Web Search on Amazon Bedrock AgentCore — AWS What's New (June 17, 2026)
8. Announcing Web Search on Amazon Bedrock AgentCore: ground your AI agents in current, accurate web knowledge — AWS Blog
9. Amazon Bedrock AgentCore pricing — AWS
10. Amazon Bedrock pricing — AWS
11. Amazon Bedrock AgentCore Regions — AWS Documentation
12. Swami's AWS re:Invent keynote lays out a full-stack vision for agentic AI — BigDATAwire (December 7, 2025)

Last updated: July 28, 2026.