Amazon CloudWatch
Metrics, logs, and alarms for everything you run.
❓ What is it?
The observability backbone: metrics from every service, log aggregation, alarms, dashboards, and anomaly detection — including model-invocation metrics from Bedrock and endpoint metrics from SageMaker.
💡 Why does it exist?
AI systems fail operationally before they fail statistically: latency spikes, throttles, error bursts. CloudWatch is where those signals surface and turn into alerts instead of user complaints.
⏱️ When should you use it?
Monitor Bedrock invocation counts/latency/token usage, SageMaker endpoint latency and errors, and pipeline job failures; alarm on thresholds and wire them to SNS or auto-scaling.
🗺️ Where does it fit?
Beside every runtime component: services emit metrics automatically; applications add custom metrics (e.g. answer quality scores); dashboards give the single pane.
🔌 How do you integrate it?
Use built-in metrics, publish custom ones via PutMetricData, create alarms with SNS actions, and enable Bedrock model-invocation logging to capture prompts/responses for review.
🧩 Commonly integrated with
🎯 Exam angle (AIF-C01)
- Bedrock model-invocation LOGGING (prompts + completions to CloudWatch/S3) is the answer for "review what the model was asked and answered".
- Operational monitoring = CloudWatch; model-quality drift = SageMaker Model Monitor. Different layers.