Amazon Bedrock's model invocation logging writes full Claude request and response records to CloudWatch Logs, S3, or both. Like any delivery pipeline, it can break: an S3 bucket policy gets "tightened" by a well-meaning security sweep, an IAM role is deleted, a KMS key policy changes, a bucket moves accounts. The invocations keep succeeding — your application notices nothing — but the log records stop arriving. For a team that enabled logging to satisfy a compliance or misuse-investigation requirement (Anthropic recommends at least a 30-day rolling log), a silent gap is precisely the failure mode that hurts most.
AWS publishes six delivery-health metrics so you never have to discover a gap by looking for a record that isn't there.
The six metrics
All six live in the AWS/Bedrock CloudWatch namespace, reported under the "Across all model IDs" dimension — they describe the logging pipeline as a whole, not any particular model:
| Metric pair | What it tracks |
|---|---|
ModelInvocationLogsCloudWatchDeliverySuccess / ...Failure | Delivery of log records to your CloudWatch Logs destination. |
ModelInvocationLogsS3DeliverySuccess / ...Failure | Delivery of the gzipped JSON batch files to your S3 destination. |
ModelInvocationLargeDataS3DeliverySuccess / ...Failure | Delivery of the overflow objects — request/response bodies over the 100 KB embed cap, and binary data such as images, which always go to S3 as separate objects. |
The third pair deserves emphasis because it fails independently of the other two. A team logging only to CloudWatch can have healthy record delivery while every oversized conversation body is failing to land in S3 — meaning your longest, most complex Claude interactions are exactly the ones missing their content. (See the log schema walkthrough for how the 100 KB cap and overflow references work.)
What failures look like and what causes them
A failure shows up as a non-zero count on the relevant ...Failure metric. The usual culprits map to the pipeline's documented plumbing requirements:
- S3 destinations need a bucket policy that allows the
bedrock.amazonaws.comservice principal tos3:PutObject, withSourceAccount/SourceArnconditions. Policy edits, bucket deletion, or encryption-key changes break this. - CloudWatch destinations need an IAM role trusted by
bedrock.amazonaws.comwithlogs:CreateLogStreamandlogs:PutLogEventson theaws/bedrock/modelinvocationslog stream. Role deletion or trust-policy changes break this. - Same-account, same-Region rule: the destination must be in the same AWS account and Region as the logging configuration — reorganizations that centralize buckets cross-account are a classic way to break delivery.
Alarms that beat the retention clock
The goal is to detect and fix a delivery failure before the gap becomes an unrecoverable hole in your retention window. A practical alarm set:
- Alarm on any failure:
SUMof each...Failuremetric ≥ 1 over a short period (e.g. 5 minutes). Delivery failures are never normal; treat one as actionable, not as noise to threshold away. - Alarm on silence: failures require Bedrock to attempt delivery. If logging was accidentally disconnected further upstream (configuration deleted, wrong Region), you may see neither successes nor failures. Pair the failure alarms with a "success went to zero while
Invocations> 0" check — CloudWatch'sbreachingtreatment for missing data, or metric math comparingModelInvocationLogsCloudWatchDeliverySuccessagainstInvocations, covers this. - Cover all three pairs. Teams routinely alarm the first two pairs and forget large-data delivery. If you handle images or long documents with Claude, the third pair is where your gaps will be.
- Repeat per Region. Logging configuration is per account and Region; so are these metrics and so should be the alarms.
One scope reminder: this whole pipeline — and therefore these metrics — belongs to the bedrock-runtime surface. Invocation logging does not capture calls on the current bedrock-mantle endpoint, so delivery-health alarms tell you nothing about that traffic; its audit trail is CloudTrail data events.
Where to go next
Log-based alerts on Bedrock covers alerting on log content; this article's alarms cover the pipeline itself. For the wider metric set, see Bedrock CloudWatch metrics.