Getting Started with Observability for Amazon Bedrock AgentCore
Introduction
Building an AI agent is only half the challenge. Once your agent is running in production, you need visibility into what it is doing: which tools it calls, how long each step takes, how many tokens it uses, and where errors occur. Without observability, debugging agent behavior becomes guesswork.
Amazon Bedrock AgentCore Observability is a managed service that provides tracing, metrics, and logging for all AgentCore resources. It integrates with Amazon CloudWatch and supports the OpenTelemetry (OTEL) standard, giving you detailed visualizations of each step in the agent workflow. You can inspect execution paths, audit intermediate outputs, track token usage, and debug performance bottlenecks.
This article is part of a series exploring Amazon Bedrock AgentCore components. Here, we focus on enabling observability for your AgentCore resources (Harness, Gateway, Browser, Code Interpreter) so you can monitor and debug your agents effectively. For the full series, see:
- Getting Started with Amazon Bedrock AgentCore Harness and Runtime
- Getting Started with Amazon Bedrock AgentCore Code Interpreter
- Getting Started with Amazon Bedrock AgentCore Gateway
What is AgentCore Observability?
AgentCore Observability provides built-in metrics for all AgentCore resource types: Runtime, Harness, Memory, Gateway, Built-in tools (Browser, Code Interpreter), and Identity. This data is available in Amazon CloudWatch through the GenAI Observability dashboard.
What You Get
- Traces and spans — End-to-end visibility into agent execution, including tool calls with inputs, outputs, and timing
- Metrics — Session count, latency, duration, token usage, and error rates
- Logs — Structured logs from agent sessions
- Custom attributes — Add business metadata to traces for filtering and analysis
How It Works
AgentCore emits telemetry in OpenTelemetry (OTEL) format. The one-time setup required is enabling CloudWatch Transaction Search, which activates span ingestion into CloudWatch Logs. After that, all AgentCore resources automatically send their observability data to CloudWatch.
For agents hosted on AgentCore Runtime (including Harness), observability is automatically enabled with no additional code changes. For agents hosted outside of AgentCore, you need to add the AWS Distro for OpenTelemetry (ADOT) SDK to your agent code.
Prerequisites
- AWS account with credentials configured
- At least one AgentCore resource already created (Harness, Gateway, or Runtime from previous articles in this series)
- AWS Region where AgentCore is available (us-east-1, us-west-2, ap-southeast-2, or eu-central-1)
Step 1: Enable Observability
Enabling observability for AgentCore resources requires two configurations. Both are mandatory for full visibility into your agent’s behavior.
1.1 Enable CloudWatch Transaction Search
CloudWatch Transaction Search is a one-time setup per AWS account and region. It activates span ingestion into CloudWatch Logs, which is required to view traces and spans from AgentCore resources.
1.1.1. Open the Amazon CloudWatch console
1.1.2. In the left navigation pane, expand Application Signals (APM) and choose Transaction Search
1.1.3. Click the Enable Transaction Search button
1.1.4. On the configuration page, enable the Enable Transaction Search toggle. This starts ingesting all spans as structured logs in the OpenTelemetry format.
1.1.5. Click Save
Alternatively, you can enable Transaction Search via the AWS CLI using aws logs put-resource-policy and aws xray update-trace-segment-destination. For details, see Enabling CloudWatch Transaction Search.
1.2 Enable Log Delivery and Tracing for Your Resources
Transaction Search alone does not activate log delivery for individual resources. AgentCore does not configure log destinations automatically for Gateway, Memory, or Built-in tools. You need to enable two things on each resource you want to monitor:
- Log delivery — Structured logs of operations: tool invocations, request/response content, errors. Use these for detailed debugging when you need to inspect the exact payload of a tool call.
- Tracing — Distributed tracing in OpenTelemetry format. Shows the end-to-end flow of a request: duration of each step, tool call timeline, latency breakdown, and error identification. Spans are stored in the
aws/spanslog group.
There are two approaches to enable these:
- Per-resource (recommended for cost control) — You configure log delivery and tracing only for the specific resources you want to monitor. This is what we use in this tutorial.
- Account-level (via CloudWatch > Ingestion > Data Sources) — Enables ingestion for all current and future resources of a given type. This is more convenient but may generate unwanted costs if you have many resources. This approach also requires enabling “resource discovery” in CloudWatch first.
In this article, we use the per-resource approach to keep costs minimal.
Enable log delivery:
1.2.1. Navigate to Amazon Bedrock AgentCore > Gateways in the AWS Console
1.2.2. Select your Gateway (e.g., LuckyNumberGateway)
1.2.3. In the Log delivery section, click Add log delivery and select To Amazon CloudWatch Logs
1.2.4. The console pre-populates a default log group name with the pattern /aws/vendedlogs/bedrock-agentcore/gateway/APPLICATION_LOGS/<gateway-id>. Accept the default value.
1.2.5. Click Add and verify the status shows Delivery active
Enable tracing:
1.2.6. On the same Gateway details page, scroll to the Tracing section
1.2.7. Click Edit
1.2.8. Toggle tracing to Enable and click Save
After completing both configurations, the Observability section on the Gateway page will no longer show the message “Resource doesn’t have Log deliveries added and Traces enabled.” You will see metrics (invocations, latency, error rate, throttle) and confirmation that both logs and tracing are active.
Get Carlos Biagolini’s stories in your inbox
Join Medium for free to get updates from this writer.
Repeat this process for any other resource you want to monitor (Browser, Code Interpreter, Memory). The steps are the same: add a log delivery destination and enable tracing on the resource’s details page. For the full reference, see Configure log destinations and tracing delivery.
Step 2: Invoke the Gateway to Generate Observability Data
With observability enabled, you need at least one invocation to generate data. Let us repeat the same test from the previous article to produce traces and logs.
2.1. Navigate to Amazon Bedrock AgentCore > Harness
2.2. Click on your Harness name (car_agent)
2.3. Click the Test Harness button
2.4. Enter the following prompt:
Hi! My name is Alice. Can you give me a lucky number for today?2.5. Wait for the agent to respond. The agent will invoke the Gateway’s get_lucky_number tool and return a result.
After the invocation completes, observability data (logs and traces) will start appearing in CloudWatch. Note that it may take a few minutes for the data to become available.
You can verify that everything is working by returning to the Gateway details page. The Observability section will now show metrics (total invocations, latency, error rate, throttle rate) and the Log deliveries and tracing section will confirm that both log delivery and tracing are active.
Step 3: View Traces and Metrics
Once observability is enabled and you have invoked your agent at least once, you can view the data in CloudWatch.
3.1 Access the GenAI Observability Dashboard
3.1.1. Open the Amazon CloudWatch GenAI Observability page
3.1.2. You will see an overview of your AgentCore resources with key metrics: invocation count, latency, token usage, and error rates
3.2 View Traces
3.2.1. In the CloudWatch console, navigate to Application Signals (APM) > Transaction search
3.2.2. Select the Logs Insights QL tab and run the following query to list recent traces:
filterIndex @data_format = 'AWS-OTEL-TRACE-V1'
| FIELDS traceId,name,@timestamp,attributes.aws.local.service as service,attributes.aws.local.environment as environment,attributes.http.response.status_code as statusCode,durationNano,spanId,@message,@log as accountId
| SORT @timestamp ASC
| LIMIT 100003.2.3. Click Run query. The results will show spans from your AgentCore resources, including the Gateway invocations from Step 2.
3.2.4. Click on a trace to see the full execution timeline, including:
- Each tool call with input parameters and output
- Time spent in each step
- Token usage per model invocation
- Error details if any step failed
3.3 What to Look For
When reviewing traces, each span includes:
- Service name — Which AgentCore resource generated the span (e.g.,
harness_car_agent.DEFAULT) - Operation name — What action was performed (e.g., GET, InternalOperation)
- Duration — How long the operation took (in nanoseconds)
- Status code — HTTP response status (200, 500, etc.)
- Remote service — What external service was called (e.g., Gateway endpoint, model endpoint)
This data helps you identify latency bottlenecks, failed operations, and the overall flow of your agent’s execution. For more guidance on how to leverage this data effectively, see AWS observability best practices.
Conclusion
In this article, you enabled observability for your Amazon Bedrock AgentCore resources:
- CloudWatch Transaction Search is a one-time setup that activates span ingestion. Without it, you cannot view traces or spans from AgentCore.
- Resource-level observability enables log delivery and tracing for individual resources (Gateway, Browser, Code Interpreter).
- The GenAI Observability dashboard provides a unified view of metrics, traces, and spans across all your AgentCore resources.
Observability is essential for production agents. It gives you confidence that your agent is calling the right tools, responding within acceptable latency, and handling edge cases gracefully. As you add more tools and complexity to your car dealership agent in future articles, these traces will be the primary way to debug and optimize behavior.
References
Stay Connected
If you found this article helpful and want to learn more about AWS, cloud architecture, AI, infrastructure as code, and cloud security, follow the author for future content and tutorials:
- LinkedIn: https://www.linkedin.com/in/biagolini
- Medium: https://medium.com/@biagolini
- GitHub: https://github.com/biagolini
- YouTube (PT-BR): https://www.youtube.com/@BiagoliniTech
- AWS Builder Center (PT-BR): https://builder.aws.com/community/@cbiagolini
Stay tuned for more practical walkthroughs and solutions for cloud infrastructure and DevOps challenges.
Happy building on AWS! 🚀☁️
