Amazon CloudWatch is AWS's monitoring service: services publish numeric metrics into it, and you build dashboards and alarms on top. Bedrock participates in this system — Claude in Amazon Bedrock emits its operational telemetry to CloudWatch (and its audit events to CloudTrail) — so the monitoring stack your operations team already runs for the rest of AWS extends to your Claude workload without new tooling. This article covers what to watch and how to assemble a first dashboard. For the exact metric names and dimensions available in your region and on your Bedrock surface, check the official Bedrock monitoring documentation; the categories below are the ones that matter operationally.
The four signal groups that matter
Invocation volume. How many model calls you make, per model, over time. This is your baseline: cost scales with it, quota consumption follows it, and a sudden change in either direction — a runaway agent loop or an integration silently failing — shows up here first.
Errors and throttles. Failed invocations, split by cause. The split matters: client errors point at your request construction, throttling points at quota pressure (see quota dimensions), and server-side errors point at the service. A throttle-rate graph trending upward over weeks is your early warning to file a quota increase before users notice.
Latency. How long invocations take. For generative models, averages mislead — response time scales with output length, so track percentiles and remember that a latency regression can simply mean your prompts started producing longer answers. Streaming workloads care most about how quickly output starts; batchy workloads care about total duration.
Token throughput. Input and output token counts over time. Tokens are the unit of both billing and quotas, so this group ties the operational picture to the financial one: tokens per minute against your TPM quota is the single most useful capacity graph for a Claude workload.
A token pipeline you can build today
One concretely documented path for token-level visibility is model invocation logging. When enabled to CloudWatch Logs, every logged call on the bedrock-runtime endpoint produces a structured record including modelId, operation, the caller's identity.arn, input.inputTokenCount, and output.outputTokenCount, plus optional caller-supplied requestMetadata. CloudWatch Logs can turn fields like these into queryable data — per-team token consumption, tokens by model, top callers by volume — using log queries and metric filters. If you tag requests with team or feature identifiers in requestMetadata, you get cost- and capacity-attribution for free. Setup is covered in the invocation logging guide; note it captures the runtime endpoint only, not bedrock-mantle calls.
Assembling the dashboard
A serviceable first Bedrock dashboard is one screen with four rows, matching the signal groups above: volume (invocations per model), health (error and throttle counts), speed (latency percentiles), and consumption (token counts vs. your known TPM quota). Add three alarms:
| Alarm | Why |
|---|---|
| Throttle rate above a low threshold | Quota pressure — act before hard failure |
| Error rate above baseline | Integration or service problem |
| Invocation volume far above or below normal | Runaway loop, or a silently dead integration |
The "below normal" alarm is the one teams skip and later wish they hadn't: an AI feature that stops being called fails silently from the platform's point of view.
What CloudWatch won't tell you
Metrics are aggregates. They will not tell you which request failed or what a bad response contained — that's the job of invocation logging — and they won't tell you who had access, which is CloudTrail's territory. Nor do they measure answer quality; a workload can be green on every graph while producing unhelpful output. Treat CloudWatch as the operational layer of a three-layer story: metrics for health, logs for content, trails for access.
Where to go next
Wire up the content layer with invocation logging, then set up log-based alerts for the failure modes metrics can't see.