Exam-style
A production Bedrock application needs alerting when invocation latency or throttling climbs, and the compliance team separately wants to inspect the exact prompt and response behind a specific customer complaint. What combination covers both needs?
Reveal the answer
B. CloudWatch metrics and alarms for latency and throttling, plus model invocation logging for the content
The two needs take two mechanisms. Bedrock publishes Invocations, InvocationLatency, InvocationThrottles, InputTokenCount and OutputTokenCount to CloudWatch under the AWS/Bedrock namespace, dimensioned by ModelId, and an alarm evaluates those. Model invocation logging is the separate feature that records request body, response body and invocation metadata to S3, to CloudWatch Logs, or to both. It is off by default, and once enabled it covers every model invocation made through the bedrock-runtime endpoint in that account and Region; bodies over 100 KB and binary data land as separate S3 objects rather than inline, and reaching S3 from a CloudWatch Logs destination needs a large-data location configured. CloudTrail logs InvokeModel and Converse as management events, naming the caller, the time and the model ID, with no prompt, no response and no latency, and its data event selectors cover resources such as agent aliases, knowledge bases, flows and guardrails, recording which resource was called rather than the payload. X-Ray annotations take only string, number and Boolean values and X-Ray indexes at most 50 of them per trace, so a prompt and a response would have to sit in unindexed metadata inside a segment document capped at 64 KB, and the SDK debug route scatters sensitive content wherever a developer sent it. Config records the configuration of Bedrock resources such as guardrails and knowledge bases, and has no record of an individual invocation.
Q. What gives you operational visibility into a production Bedrock app?
A. CloudWatch metrics in the AWS/Bedrock namespace: Invocations, InvocationLatency, InvocationThrottles, and input and output token counts, with alarms on them. Model invocation logging, off by default, captures the prompt and the response. CloudTrail records the call and the model ID, not the payload.
Why? Rate metrics and payload records come from separate mechanisms, so a production app turns on both.