Skip to main content
In this lesson you’ll learn how to use Amazon CloudWatch with Amazon Bedrock to gain practical observability into what your Bedrock-based application is doing. CloudWatch gives you measurable visibility into usage, performance, and failures so you can detect, diagnose, and resolve problems faster. Lesson plan:
  • Problem: lack of visibility into Bedrock applications
  • Solution: use CloudWatch for observability
  • Workflow: CloudWatch Metrics and CloudWatch Logs
  • Results: clear visibility and faster troubleshooting
  • Summary and next steps (including a lab exercise)
A slide titled "Lecture Flow" showing a flowchart: Problem (No visibility into Bedrock apps) → Solution (Use CloudWatch) → Workflow (CloudWatch metrics & logs) → Results (Clear visibility).
Problem: no visibility into Bedrock apps When observability is missing, you may only see symptoms—rising latency, token-usage spikes, or higher error rates—without understanding the root cause. Metrics can tell you that something is wrong, but they often don’t explain why. To troubleshoot effectively you need both:
  • Inputs (prompts, request size)
  • Model responses (results, error codes)
  • The sequence of events that produced the metric behavior
A presentation slide titled "Problem: No visibility Into Bedrock Apps" that contrasts "What is actually happening?" (latency increases) with "What you might see" (token usage spikes). The slide notes that metrics show issues but don’t explain the cause.
Solution: an observability plan using CloudWatch A robust observability strategy for Bedrock includes both metrics and logs. Amazon CloudWatch supports both and lets you correlate them for faster root-cause analysis.
  • CloudWatch Metrics: aggregated, time-series data such as invocation counts, token counts, latencies, and errors.
  • CloudWatch Logs: detailed request/response capture (invocation logging) plus application logs you emit from your code.
A presentation slide titled "Solution: Monitor Bedrock With CloudWatch" showing three colored panels labeled "CloudWatch Metrics," "CloudWatch Logs," and "Together," each with brief bullet points about tracking metrics, capturing logs, and combining them for observability.
Why combine metrics and logs? Metrics tell you “what” changed—e.g., higher latency, more tokens consumed—while logs tell you “why” by providing contextual data (request payloads, error traces, upstream failures). For example, an increase in latency could be caused by:
  • Bedrock throttling
  • Upstream network timeouts
  • Large prompts or unexpected input patterns that increase token usage and cost
Using metrics and logs together gives you both the effect and the cause.
Invocation logging captures complete request and response data. If you enable it, be mindful of potentially sensitive information (PII) and the storage/cost implications of logging full payloads.
Invocation logging and application logs Bedrock supports optional invocation logging (request/response capture). Enable it only when needed for debugging or audit, and sanitize or redact sensitive data before writing logs if possible. Your application should also emit structured application logs (for example, from Lambda functions or containerized services) to CloudWatch Logs. Useful application log entries include:
  • When a Bedrock call is initiated
  • The model and parameters used for the request
  • Response status or error details
  • Business-level context to help correlate with metrics
Because CloudWatch Logs can contain both Bedrock invocation logs and your application logs, correlation between an invocation metric and the actual request/response is straightforward. CloudWatch Metrics: what to monitor CloudWatch metrics are organized by namespace (one namespace per AWS service). Bedrock-specific metrics appear under the Bedrock namespace if you have activity in the account. How to view Bedrock metrics:
  1. Open the CloudWatch console and go to Metrics.
  2. Select the Bedrock namespace.
  3. Choose metrics and filter by dimensions (model, region, etc.).
  4. Add them to a chart or custom dashboard and set the desired time range.
Key Bedrock metrics to track Token-based metrics are especially important because Bedrock pricing is often token-based. Monitoring InputTokenCount and OutputTokenCount helps you detect cost trends and decide on mitigations (prompt engineering, rate limits, provisioned throughput). Here’s an example from the CloudWatch console showing the Bedrock namespace and several Bedrock-specific metrics. Note that metrics only appear once you’ve generated Bedrock usage in the account.
A screenshot of an AWS CloudWatch Metrics dashboard titled "Workflow: CloudWatch Metrics," showing a line chart of metrics and a table listing metric names like InputTokenCount, OutputTokenCount, Invocations, and their alarm statuses.
Best practices for using metrics
  • Use namespaces and dimensions to scope metrics to the relevant model, region, or environment.
  • Build focused dashboards (per application, team, or business unit) that surface only actionable metrics.
  • Adjust time ranges for near real-time monitoring or retrospective troubleshooting.
  • Create CloudWatch Alarms on critical signals (high latency, increased error rate, token spikes) to trigger notifications or automated remediation.
  • Remember that CloudWatch metrics are aggregated before visualization; the charts refresh as new data points arrive rather than continuously streaming.
Practical workflow: metrics → logs → remediation
  1. Alert fires on a metric (e.g., latency or token spike).
  2. Open the associated dashboard and check dimensions to narrow affected models/regions.
  3. Inspect correlated logs (invocation logs + application logs) to find the root cause: throttling, upstream failures, or large request payloads.
  4. Apply remediation: tweak prompts, increase capacity, add retries/backoff, or redact PII in logs.
Summary and next steps
  • Combine CloudWatch Metrics and CloudWatch Logs to see both the “what” and the “why.”
  • Enable invocation logging only when needed; consider privacy and cost implications.
  • Instrument your app to emit contextual logs that can be correlated with Bedrock invocations.
  • Build dashboards and alarms to detect and respond to issues quickly.
Next: a hands-on lab that shows how to enable Bedrock invocation logging, configure CloudWatch metrics and dashboards, and create example alarms. Links and references

Watch Video