Amazon Bedrock AgentCore now delivers unified observability with traces and logs in a single log group
Debug AI agents faster — all traces, prompts, and logs now land in one per-agent CloudWatch log group with CMK and IAM scoping support.
View original announcement →Visual Summary
What's New
Amazon Bedrock AgentCore now consolidates all agent telemetry — including trace spans, prompts, structured logs, and standard output — into a single per-agent CloudWatch log group (/aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>). Previously, trace spans were routed to the shared aws/spans log group while event logs went to a separate resource-specific destination, forcing engineers to search across multiple locations during debugging. This unified observability model is enabled by default for all agents created on or after July 20, 2026.
How It Works
- All telemetry types (trace spans, prompts, inputs/outputs, structured logs, and stdout) are delivered to a single per-agent CloudWatch log group named
/aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>, eliminating cross-group correlation. - The AWS Distro for OpenTelemetry (ADOT) SDK is used to instrument agent code and emit observability data; the unified destination requires ADOT version 0.17.1 or later.
- For agents created on or after July 20, 2026, unified observability is the default behavior with no configuration required.
- For existing agents, operators must set the environment variable
UNIFIED_TRACES_DESTINATION_ENABLED=trueon the agent runtime and upgrade ADOT to v0.17.1 or later to opt in. - IAM policies and customer-managed key (CMK) encryption can now be scoped at the individual agent level, since each agent has its own isolated log group.
- CloudWatch Transaction Search must be enabled as a one-time setup step to view spans and traces in the CloudWatch console's GenAI Observability dashboard.
- For multi-agent architectures, each agent maintains its own complete execution history in its dedicated log group, enabling independent and correlated debugging across the system.
Why It's Important
- Debugging an agent invocation previously required searching across at least two separate log groups, significantly increasing mean time to resolution (MTTR) for production issues.
- Unified telemetry enables direct correlation of trace spans with the exact prompts and outputs that produced them, providing full causal context in a single view.
- Per-agent log groups unlock fine-grained IAM access control, allowing teams to restrict observability data access to only the agents relevant to their role — a critical requirement for enterprise security postures.
- CMK encryption can now be applied at the individual agent level, enabling compliance with data residency and encryption policies that require isolation between workloads.
- Exporting all telemetry (e.g., to S3 or a SIEM) is simplified to a single CloudWatch log group subscription per agent, reducing operational overhead.
- Multi-agent systems become significantly easier to debug end-to-end, as each agent's full execution history is self-contained and traceable without cross-referencing shared log groups.
How It's Different
- Previously, trace spans went to the shared
aws/spanslog group (shared across all agents and services), while event logs went to a separate resource-specific group — now both are co-located in one agent-scoped log group. - The old model made per-agent IAM scoping and CMK encryption impossible for trace data since it resided in a shared log group; the new model enables both at the individual agent level.
- Unlike the previous split-destination model, a single CloudWatch log subscription now captures the complete observability picture for an agent, simplifying data export pipelines.
- The new per-agent log group naming convention (
/aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>) provides a deterministic, programmatically discoverable destination, unlike the previously fragmented approach. - New agents get unified observability automatically with zero configuration, whereas the previous behavior required understanding and managing multiple telemetry destinations from the start.
When to Prefer It
- Use unified observability when operating multi-agent systems where tracing execution flow across coordinated agents requires correlating traces and logs without switching between log groups.
- Prefer this model when your organization has compliance requirements mandating per-workload CMK encryption or strict IAM-based data access isolation for AI agent telemetry.
- Adopt this feature when building production-grade AI agents where rapid root-cause analysis is critical and engineers cannot afford to manually join data from multiple CloudWatch log groups.
- This is the right choice when you need to export complete agent telemetry to external systems (e.g., Splunk, Datadog, S3 data lake) via a single, reliable CloudWatch subscription.
- Enable unified observability for existing agents when upgrading to ADOT v0.17.1 or later, as the migration is low-risk and immediately improves debuggability.
- Particularly valuable for teams using the CloudWatch GenAI Observability dashboard, where having all telemetry in one log group maximizes the fidelity of the visual trace and log correlation experience.
Availability
- GA Status: Generally available; no preview qualifier mentioned — unified observability is production-ready.
- Default Behavior: Automatically enabled for all new agents created on or after July 20, 2026, with no configuration required.
- Existing Agents: Opt-in by setting
UNIFIED_TRACES_DESTINATION_ENABLED=trueenvironment variable and upgrading ADOT to version 0.17.1 or later. - Supported Regions: Available in all AWS commercial regions where Amazon Bedrock AgentCore runtime is supported.
- Pricing: No separate charge is mentioned for unified observability itself; standard Amazon CloudWatch Logs ingestion, storage, and query pricing applies.
- Prerequisite: CloudWatch Transaction Search must be enabled (one-time setup) to view spans and traces in the CloudWatch GenAI Observability console dashboard.
- Limitation: Not available in AWS GovCloud or China regions unless AgentCore runtime itself is supported there.