Amazon Bedrock AgentCore Unifies Agent Telemetry Into a Single CloudWatch Log Group

What the Old Model Cost You

Before this change, AgentCore split agent telemetry across multiple destinations. Trace spans landed in the shared aws/spans log group. Event logs containing prompts, inputs, and outputs went to a separate resource-specific log group. Debugging a single agent invocation required searching both. More critically, customers could not apply fine-grained IAM access control or customer-managed key encryption at the individual agent level. In regulated environments, that is a real compliance gap.

What Changed

All telemetry—traces, prompts, structured logs, and standard output—now lands in a single per-agent log group. The path follows the pattern /aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>. You subscribe once to export everything. You scope IAM policies and CMK encryption to that one group. For multi-agent systems, each agent's complete execution history stays together.

Agents created on or after July 20 in supported AWS Regions use unified observability by default. No configuration is required for new deployments.

What Existing Agents Require

This is where teams must act. To opt in an existing agent, set the UNIFIED_TRACES_DESTINATION_ENABLED=true environment variable on the agent runtime. That alone is not enough. The ADOT version requirement differs between sources: S1 specifies version 0.17.1 or later, while S4 specifies version 0.18.0 or later. Use 0.18.0 or later to satisfy both.

Earlier ADOT versions ignore the span destination configuration and deliver spans to the shared aws/spans log group.

Teams that set the variable but skip the ADOT upgrade will believe they have unified telemetry while actually they do not.

Two additional prerequisites apply. CloudWatch Transaction Search must be enabled in the account, with trace segments sent to Amazon CloudWatch Logs. Without it, AgentCore cannot route spans to the agent's log group. The agent's execution role also needs the logs:PutResourcePolicy action on the agent's log group, so AWS X-Ray can write spans there.

One boundary worth noting: changing the span destination does not move existing span data. Spans already written to aws/spans stay there.

Who Should Act and Why

Cloud platform owners, security leads, and application teams running agents in production each have a distinct concern here.

For platform owners, the single log group simplifies export pipelines and CloudWatch subscription filters. One subscription per agent replaces multiple.

For security and compliance teams, IAM policies and CMK encryption can now be scoped to individual agents rather than shared across all agents in the account. That changes what a data-classification or access-review audit needs to examine. If your agents handle sensitive prompts, this capability unlocks a control tier that was previously unavailable.

For application teams, end-to-end debugging of multi-agent workflows is now straightforward inside a single log group. Correlating a trace span with the prompt that triggered it no longer requires cross-group queries.

The feature is available in all AWS commercial regions where AgentCore runtime is supported. The AgentCore Developer Guide covers the full configuration steps.

The Action List

For new agents: confirm your deployment date is July 20 or later and verify the default is active.

For existing agents: set UNIFIED_TRACES_DESTINATION_ENABLED=true, upgrade ADOT to 0.18.0 or later to satisfy both S1 and S4, enable CloudWatch Transaction Search, and update the execution role policy. Then validate that spans are appearing in the per-agent log group, not the shared one.

For security teams: treat the unified log group as the new unit of access control. Update encryption and IAM reviews accordingly.