Amazon Bedrock plugs into the same monitoring stack you already use for the rest of AWS. Claude activity on Bedrock shows up in three places: CloudWatch (metrics and logs), CloudTrail (API audit events), and — if you turn it on — model invocation logging, which captures the full request and response detail of each call. Anthropic's documentation confirms that Claude in Amazon Bedrock emits logs to both CloudWatch and CloudTrail. This article covers how to turn that raw telemetry into alerts.
Three signals worth alarming on
For most enterprise Claude deployments, three conditions justify waking someone up (or at least posting to a channel):
| Signal | What it usually means | Where the data lives |
|---|---|---|
| Error-rate spike | Bad deploy, revoked permissions, model access issue | CloudWatch metrics; CloudTrail error codes |
| Throttle count rising | You are hitting a tokens-per-minute or requests-per-minute quota | CloudWatch metrics; 429 responses in application logs |
| Token consumption spike | Runaway loop, oversized prompts, or genuine growth | Model invocation logs (token counts per call) |
Bedrock publishes service metrics to CloudWatch that you can alarm on directly; check the Bedrock monitoring documentation for the current metric names and dimensions rather than hard-coding names from memory — they differ by endpoint and can change. For anything the built-in metrics do not cover, metric filters over your invocation logs fill the gap.
Metric filters: turning log lines into numbers
A CloudWatch metric filter scans a log group for a pattern and increments a custom metric each time the pattern matches. You can then attach a standard CloudWatch Alarm to that custom metric. This is the most flexible way to alert on Bedrock behavior, because model invocation logging writes rich, structured JSON you can filter on.
Model invocation logging is disabled by default. Once enabled (console Settings, or the PutModelInvocationLoggingConfiguration API), it captures full request data, response data, and metadata for InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream calls, delivered to CloudWatch Logs and/or S3 in the same account and region. Each log record includes fields such as modelId, operation, identity.arn, input.inputTokenCount, and output.outputTokenCount, plus optional caller-supplied requestMetadata. Two practical notes: request and response bodies over 100 KB are diverted to S3 rather than inlined, and only calls through the bedrock-runtime endpoint are captured — calls to the newer bedrock-mantle endpoint (the "Claude in Amazon Bedrock" surface) are not currently covered by invocation logging.
With that log group in place, useful metric filters include:
Token spikes per model. Filter on modelId and publish input.inputTokenCount as the metric value. Alarm when the per-minute sum exceeds a threshold comfortably below your quota — Bedrock's bedrock-runtime quotas count input and output tokens together against a per-model tokens-per-minute limit, and there is also a per-day token quota, so an early-warning alarm buys you time to request an increase before users see 429s.
Per-team consumption. If your applications pass requestMetadata on each call, filter on those caller-supplied fields to get a metric per team or application, and alarm on unusual growth.
Unexpected callers or models. Filter on identity.arn or modelId values outside your approved list, and alarm on any occurrence at all.
bedrock-runtime limits go through the Service Quotas console; bedrock-mantle increases require an AWS Support case naming the endpoint, region, model, and quota — neither is instant, so early warning matters.CloudTrail as the audit backstop
CloudTrail records every Bedrock API call — who called, from which source IP, and when. InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream are logged as management events, which means they are captured by default. Crucially, prompt and completion content is not in the CloudTrail record — the documented example shows only the modelId in request parameters — so CloudTrail is safe to route into broad security tooling. You can forward CloudTrail events to a CloudWatch log group and build metric filters there too, for example counting AccessDeniedException errors, which often indicate a missing model-access prerequisite or an IAM change. Amazon GuardDuty also analyzes Bedrock CloudTrail activity for suspicious behavior, such as guardrail removal.
Where to go next
Pair alarms with the cost side: see cost allocation tags for Bedrock and the general cost monitoring guide. For handling the throttles themselves in code, see retries and fallbacks.