A media company's Amazon Bedrock workload is slow, and operators need invocation latency and error counts for the model calls. They do not need a cost report. Which place should they instrument and watch?
Select an answer to reveal the explanation.
Short Explanation
A slow model call shows up as latency and errors, not as a line on the bill. You watch CloudWatch for those invocation metrics and the application logs around them. Cost Explorer can tell you what you spent after the fact, which is not the outage you are in.
Full Explanation
Bedrock publishes invocation metrics to CloudWatch, including latency and errors, which is the operational view this team asked for. Application logs next to those metrics show which call was slow. Cost Explorer summarizes spend; it is not the latency graph, and the stem says a cost report is not the need. The AMI catalog has nothing to do with a managed model invocation. A Route 53 query log shows DNS questions for a name, not model latency. Caveat: if the application calls Bedrock through its own retry loop, also log the request id so a CloudWatch error lines up with one call and not with the retries. Operational check: graph the invocation latency and error metrics for the model, then open one slow request in the application log and confirm the timestamps match. Invocation metrics are per model and per Region, so a graph in the wrong Region stays empty while users are slow. Pair the metric with the application's request id so you can tell a throttled call from a slow model response. A cost view can wait until the latency is explained; it will not name the cold invocation.