Almost every AWS account we assess has CloudTrail enabled. Almost none of them have an alarm attached to it. That gap is not an oversight by careless teams, it is structural: turning on a trail is one click and one line of Terraform, while turning that trail into an alert is a three-part chain most people never finish building. The CIS Amazon Web Services Foundations Benchmark v7.0.0, released in March 2026 with 70 recommendations, devotes its entire fifth section to closing that gap.
Key takeaway: CloudTrail is a recorder, not a smoke detector. Recording an intruder disabling your trail is worth very little if the recording is only read after someone else notices the breach.
The 15 Alarms at a Glance
Section 5 of the benchmark is titled Monitoring and contains 16 recommendations. Fifteen of them describe a CloudWatch metric filter and alarm; the sixteenth, 5.16, asks you to enable AWS Security Hub and is the only automated check in the section. Profile levels below are CIS's own classification. The priority column is our rating, not part of the benchmark, since CIS does not assign severity.
| CIS ID | What it alerts on | CIS profile | Our priority |
|---|---|---|---|
| 5.1 | Unauthorized API calls | Level 2 | Medium |
| 5.2 | Console sign-in without MFA | Level 1 | High |
| 5.3 | Root account usage | Level 1 | High |
| 5.4 | IAM policy changes | Level 1 | Medium |
| 5.5 | CloudTrail configuration changes | Level 1 | High |
| 5.6 | Console authentication failures | Level 2 | Medium |
| 5.7 | CMK disabled or scheduled for deletion | Level 2 | High |
| 5.8 | S3 bucket policy changes | Level 1 | Medium |
| 5.9 | AWS Config configuration changes | Level 2 | Medium |
| 5.10 | Security group changes | Level 2 | Medium |
| 5.11 | Network ACL (NACL) changes | Level 2 | Medium |
| 5.12 | Network gateway changes | Level 1 | Medium |
| 5.13 | Route table changes | Level 1 | Medium |
| 5.14 | VPC changes | Level 1 | Medium |
| 5.15 | AWS Organizations changes | Level 1 | High |
Nine of the fifteen are Level 1, which CIS treats as baseline rather than advanced hardening. All fifteen are marked Manual, and that single fact explains most of why they go unbuilt. More on that below.
1. Why a Trail Alone Alerts on Nothing
The chain has three links, and stopping after the first is the single most common monitoring failure in AWS.
First, CloudTrail writes API activity to an S3 bucket. That is the recording. Second, the trail has to reach somewhere queryable in near real time, normally a CloudWatch Logs group, where a metric filter watches the stream for a specific pattern and increments a metric when it matches. Third, a CloudWatch alarm on that metric fires to an SNS topic that reaches a human.
Miss the second link and your data sits in a bucket nobody reads until an incident. Miss the third and the metric quietly counts root logins into a graph nobody has opened. Notably, v7.0.0 accepts the alternative path explicitly: forward the trail to a SIEM that does the same job. What it does not accept is a bucket with no consumer.
2. The Five That Should Wake Someone Up
CIS does not rank these against each other, so this ordering is ours. Five of the fifteen have effectively no legitimate volume in a healthy account, which makes them the cheapest alarms you will ever run. If you do nothing else this quarter, do these.
Root account usage. Root should be effectively unused after setup, which is exactly what makes any root activity high signal. There is no tuning problem here and no alert fatigue, because the healthy baseline is zero.
Console sign-in without MFA. A console login with no second factor either breaks your policy or reveals an account your MFA rollout missed. Both need to be seen, and the second one is the reason this is worth alerting rather than reporting.
CloudTrail configuration changes. StopLogging, DeleteTrail and UpdateTrail are how an intruder blinds the investigation before doing anything worth investigating. This is the alarm that protects all the others, and it has to fire even though it looks like a legitimate administrative action.
CMK disabling or scheduled deletion. Data encrypted with a disabled or deleted customer managed key is unrecoverable once the waiting period elapses. The waiting period is the only thing standing between a destructive action and permanent loss, so the alert has to land inside it.
AWS Organizations changes. Moving an account between organisational units or detaching it from the organisation can lift every service control policy guardrail at once. One API call, and an account you believed was fenced in is not.
3. The Identity Signals
Privilege escalation shows up as a policy change before it shows up as anything else, which is why IAM policy changes are on the list. Create, delete and attach operations on policies are the paper trail of someone granting themselves more than they had.
Unauthorized API calls are the ordinary signature of two very different things: a misconfigured deployment, and an intruder probing what a stolen credential can actually reach. A rise in authorisation failures is worth a look either way, which is also why this one needs a threshold rather than a hair trigger.
Console authentication failures are the visible part of password guessing and credential stuffing. Alone they are noise; correlated with a successful sign-in from the same source, they are a story. This is a natural companion to watching token theft and session replay on the identity side.
4. The Data and Evidence Signals
S3 bucket policy changes get their own recommendation for a blunt reason: a bucket policy change is the shortest path between private data and public data. PutBucketPolicy and PutBucketAcl deserve an alert, not a weekly report, because the exposure window starts the moment the call succeeds.
AWS Config changes matter for the same reason CloudTrail changes do. Turning off the configuration recorder removes the record of resource state without producing any other visible effect. Nothing breaks, no user complains, and your ability to reconstruct what changed is simply gone.
5. The Network Path Signals
Five recommendations cover the network boundary, and they exist because the risky edit and the routine edit look identical in a log.
Security group changes alter what is reachable from the internet. NACL changes do the same thing one level up, at the subnet boundary, so a single change can expose an entire subnet. Network gateway changes create a path in or out of the VPC that did not exist before. Route table changes are the subtle one: routing can redirect traffic without touching a single security group or NACL, moving data silently past controls that all still look correct. VPC changes, including peering, alter the boundary that every other network control is defined against.
These are the classic cloud misconfigurations that read as clean in a posture snapshot taken ten minutes later, because someone opened a path and closed it again.
6. Why Almost Nobody Has Them
Here is the part worth internalising. In v7.0.0, all fifteen of these carry an assessment status of Manual, while the surrounding logging and encryption recommendations in section 4 are Automated.
That classification quietly shapes the market. Automated scanners are built to report on automated checks, so the manual ones get dropped from dashboards, dropped from the compliance percentage, and therefore dropped from the remediation queue. You can score well against CIS AWS and have precisely zero detective controls, because the fifteen recommendations that produce alerts were never counted.
It is a clean illustration of the difference between a benchmark score and a security posture. The controls that tell you an attack is happening are exactly the ones your compliance percentage is most likely to ignore.
What to Actually Do
- Finish the chain. Confirm your trail reaches CloudWatch Logs or a SIEM, then confirm at least one alarm has a live SNS subscription with a human on the other end. Send a test.
- Start with the five high severity alarms. Root usage, console sign-in without MFA, CloudTrail config changes, CMK deletion and Organizations changes. All five have near-zero legitimate volume, so they cost you almost nothing in noise.
- Deploy them as code, in every region. Fifteen metric filters clicked by hand in one region is how this decays. A module applied per account and per region is how it survives.
- Check the subscription, not just the alarm. An alarm in INSUFFICIENT_DATA state, or one whose SNS topic points at a departed employee's inbox, passes a config review and fails an incident.
- Treat manual controls as work, not as exempt. Ask any posture tool which CIS recommendations it does not evaluate, and read that list as your real gap analysis.
This is the principle SecValley builds to: a recommendation marked manual is still a control, and dropping it from the score does not remove the gap, it just moves it out of view. That is how our continuous posture assessment treats the manual recommendations across the Microsoft 365, Entra ID and Azure benchmarks we cover today, and it is the standard our AWS coverage is being built to.
Frequently Asked Questions
Do I need CloudWatch alarms if I already forward CloudTrail to a SIEM?
No, and v7.0.0 says so directly. The requirement is that the event reaches something that evaluates it and notifies a human, not that the mechanism is CloudWatch specifically. If your SIEM ingests the trail and has detection rules covering these fifteen patterns, you have satisfied the intent. The failure mode to check is different in that case: teams frequently forward the logs, then never write the rules, which leaves an expensive ingestion bill and the same blind spot.
Why does CIS mark these as manual if they can be checked with an API call?
Because verifying intent is harder than verifying existence. A tool can confirm a metric filter pattern and an alarm exist, but it cannot easily confirm the SNS topic reaches someone who acts, that the threshold is sensible for your volume, or that a SIEM rule elsewhere already covers it. CIS marks a recommendation manual when a passing configuration does not reliably prove the control works. That is a fair judgement, but in practice it means the check gets skipped entirely, which is worse than an imperfect automated check.
How many alarms will actually be noisy?
Fewer than people expect, if you sequence them properly. The five high severity ones are near-silent in a healthy account by design, since root usage, MFA-less console logins, trail tampering, key deletion and organisation changes should all be rare. The genuinely noisy candidates are security group changes, unauthorized API calls and console authentication failures in active environments, which is why those benefit from thresholds and from routing to a queue rather than a pager. Start with the quiet five, prove the delivery chain works, then add the noisy ones with tuning.
