On a fixed-performance instance (M/C/R) the CPU ceiling is 100%, so `CPUUtilization` near 100% means saturated. On a burstable T-instance (T2/T3/T3a/T4g) the **effective** ceiling collapses to the **baseline %** once CPU credits are exhausted — so `CPUUtilization` becomes an unreliable saturation signal. The instance can be fully starved while reporting low CPU%. **The trap:** `CPUUtilization` sits flat at, say, 20% — looks like abundant headroom — but the instance is pinned at baseline with work queuing. Raw CPU% hides it; only the credit balance reveals it. **Read `CPUUtilization` against two other signals:** - `CPUCreditBalance` sloping down → sustained load above baseline. - Balance at zero **and** `CPUUtilization` flat at the baseline % → throttling (standard mode). That flat line is saturation, not idle. - Balance at zero **and** `CPUSurplusCreditsCharged` rising → unlimited mode; saturation converts to dollars, not latency. **Confirming true demand:** CloudWatch `CPUUtilization` cannot show *queued* work. Install the CloudWatch agent for OS-level load average / run-queue depth. Load average > vCPU count while `CPUUtilization` is flat at baseline = confirmed throttled and saturated. This is the same multi-signal, timeline-alignment discipline as `Confirming a DB-Saturating Query — Performance Insights + APM`: one metric in isolation misleads, overlap confirms. Decision: persistent baseline-pinning means right-size up, keep unlimited mode on (and pay), or move to a fixed-performance family. See [[EC2 Burstable CPU Credit Monitoring]] for the credit metrics themselves. --- *Source: [[AWS EC2 Burstable Performance Instances (AWS Docs)]] — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html*