The first time you run a broken CloudTrail query, you don’t notice. The second time, it costs you hours. The third time, you start asking: why aren’t we auditing our CloudTrail query runbooks like we audit our code?
CloudTrail is a truth machine for AWS. Every API call is there, whether from users, services, or attackers. But logs mean nothing without discipline in how we query them. Queries drift. Filters rot. Fields change. And when a runbook query goes stale, you miss real signals and chase false alarms.
Auditing CloudTrail query runbooks is about more than checking syntax. It means validating that every query still delivers the insight it was designed for. It means testing against fresh events, confirming assumptions on AWS service behavior, and ensuring your parsing logic keeps up with AWS JSON schema changes. It means rewriting runbooks when the threat model changes.
Start with an inventory. List every stored query you run in detection, incident response, and compliance checks. Map each query to the events it’s meant to surface. Then use automated tests. Feed in controlled CloudTrail samples and verify the output matches expectations. When the detection scope changes—like a new region added, or a service adopting a different API action—update and re-test.