The alarm went off at 2:14 a.m. A production API had slowed to a crawl. The dashboards looked clean. CPU, memory, network — all green. But traffic was vanishing into a black hole.
In the log streams, the pattern emerged. A single load balancer had started rejecting requests. CloudTrail told the rest of the story: a quiet configuration change buried under dozens of harmless events. By the time the team found it, the SLA had already been breached.
Load balancer failures are silent killers. They don’t scream in metrics until the incident is already burning. CloudTrail records the truth, but the sheer volume of events turns it into a swamp. Without a precise way to query those events, you’re left scrolling, guessing, and losing time.
That’s where targeted CloudTrail queries for load balancer events cut through the noise. The recipe is simple: isolate the event source, narrow by API action, filter by resource ARNs, and constrain time windows. For example, elasticloadbalancing.amazonaws.com with ModifyLoadBalancerAttributes, RegisterTargets, or DeleteListener becomes your shortlist of high-risk events. Pairing these filters with runbooks turns static queries into a live tool you can use in every incident.