Managed AWS services fail against limits the application cannot see. A gp3 volume enforces provisioned IOPS and provisioned throughput as separate ceilings, so a PostgreSQL replica can throttle hard on MB/s while IOPS sits at 21 percent of what was paid for, and every dashboard reading IOPS shows headroom. ECS refuses to place a task and reports it as a stopped task rather than as a constraint violation. ElastiCache accepts connections until it does not, and the client sees a generic timeout. The incidents collected here span storage, compute placement, caching, and the metrics layer itself, including one page where the alarm was the only thing that was actually broken.
ECS AZ rebalancing failed to place a replacement task with TaskFailedToStart: MemberOf placement constraint unsatisfied. CPU burst hit 115.22% at 10:03Z, but app logs showed normal operation. Service entered churned state (desired=2, running=2, pending=1) with no confirmed full outage.
gp3 data volume hit transient storage throttling after write throughput exceeded provisioned 750 MB/s (peaked 862.8 MB/s). Queue depth rose from ~11 to 17.89 and read latency doubled to 1,042 ms. Average IOPS stayed at 21% of provisioned 30,000, ruling out IOPS exhaustion.
HPA-driven pod churn on eaze-channels pushed CurrConnections from ~280 to 1,788 on Redis for one 5-minute bucket. Cache health stayed normal; transient connection fan-out from scaling, not a deploy or resource saturation.
Celery worker hit 91% of 1Gi memory limit as task backlog grew during a concurrent Aurora PostgreSQL load surge. Pod was evicted for Underutilized (not OOMKilled); surviving replica still at 87%. Thin headroom, not a crash.
WebSocket reconnect/reject loop on eaze-channels drove CurrConnections from ~370 to 1,988 on Redis. Cache health stayed normal; root cause was WSREJECT on /ws/expert_availability causing client-side churn.
Short-lived write spike from upstream application caused a WriteIOPS alarm. Investigation confirmed no customer impact: transient burst from a batch job.
Start by naming the exact dimension that saturated, not the service. Every AWS limit is per-dimension: IOPS and throughput are provisioned separately on gp3, connection count and CPU are separate ceilings on ElastiCache, and burst credits deplete on a schedule of their own. A resource can be at 100 percent on one dimension and 20 percent on three others, which is why "the volume looks fine" is usually a statement about the wrong graph. Next, decide whether the client or the service moved. Connection storms on a cache are frequently caused by pod churn, deploys, or an HPA cycling replicas, and the cache is the place where a workload-side event first becomes visible. Then check whether the alarm reflects a customer-visible symptom at all. Compare the alarm period, statistic, and missing-data treatment against latency and error rates from the request path: a CloudWatch counter can spike from a maintenance operation, a snapshot, or a batch job while nothing a user touches gets slower. Placement failures are the exception to all of this and read best backwards, from the scheduler event to the constraint that could not be satisfied at that moment, since AZ rebalancing changes the answer to a placement question that succeeded an hour earlier.