CloudWatch Security Monitoring

CloudWatch Security Monitoring uses CloudWatch metrics, logs, and alarms to detect and respond to security events across your AWS environment.

Security Metric Alarms

• Root account usage (any API call by root triggers alarm)
• Console sign-in failures (potential brute force)
• Unauthorized API calls (AccessDenied count above threshold)
• IAM policy changes (potential privilege escalation)
• Security group changes (network exposure risk)
• CloudTrail configuration changes (tamper detection)

CloudWatch Logs Insights

• Query CloudTrail logs for specific API calls, IP addresses, or user agents
• Investigate security incidents with SQL-like query language
• Dashboard visualizations for security metrics

CloudWatch Anomaly Detection

• ML-based anomaly detection on any CloudWatch metric
• Automatically learns normal patterns and alerts on deviations
• Useful for detecting unusual data transfer, API call volumes, or error rates

How It Goes Wrong in Practice

The most common failure in CloudWatch security monitoring is the alarm that fires into the void. The classic security alarms, root usage, IAM policy changes, CloudTrail configuration changes, are metric filters applied to a CloudWatch Logs log group that receives CloudTrail events; the CIS AWS Foundations Benchmark defines exactly this pattern in its monitoring controls. The chain has four links: CloudTrail must deliver into CloudWatch Logs, the metric filter must match the right log group and pattern, the alarm must reference the resulting metric, and the alarm's action must point at an SNS topic with a live subscription. Break any link and the dashboard still looks configured while nothing reaches a human. Real environments break every one of them: trails that were never integrated with CloudWatch Logs (so the filters match nothing, forever), filters recreated against a renamed log group, SNS topics whose only subscriber was an employee who left, and alarms sitting permanently in INSUFFICIENT_DATA state because their source metric has never emitted a datapoint. That last state deserves special attention: teams learn to ignore INSUFFICIENT_DATA as noise, but for a security metric filter it usually means the detection pipeline is disconnected, which is precisely the condition an attacker who tampers with logging wants you to normalize. Test the pipeline end to end: perform a benign matching event (a harmless security group description change, a sign-in failure on a test user), and verify a notification actually arrives. A detection you have never seen fire is a hypothesis, not a control.

Practical Check: Find Broken and Firing Alarms

Two views of the same command cover the audit. First, what is currently firing:

aws cloudwatch describe-alarms --state-value ALARM

Then, what may be silently broken:

aws cloudwatch describe-alarms --state-value INSUFFICIENT_DATA

The --state-value parameter accepts OK, ALARM, and INSUFFICIENT_DATA. For each security alarm in the second list, trace why the metric has no data: missing CloudTrail-to-CloudWatch Logs integration and deleted log groups are the usual suspects. You can also scope the check with --alarm-name-prefix if your security alarms share a naming convention.

Frequently Asked Questions

Do I still need CloudWatch alarms if I run GuardDuty?
They answer different questions. GuardDuty is managed threat detection over AWS telemetry with its own finding types; CloudWatch alarms are deterministic rules you define, which is what compliance frameworks ask for and what lets you alert on organization-specific events (your critical role being assumed, your specific bucket policy changing). Mature setups run both and route both into the same notification and response path.

Why does CIS care about these specific alarms?
Because they cover the actions attackers take in nearly every account compromise: using root, changing IAM policies, altering CloudTrail, and modifying network exposure. In older benchmark versions these are automated Security Hub checks; in versions 3.0.0 and 5.0.0 most are marked as manual checks, so you must verify and evidence them yourself rather than relying on a dashboard score.

What is the role of anomaly detection versus fixed thresholds?
Fixed-threshold alarms are right for events where any occurrence matters (root usage should alarm at count one). Anomaly detection earns its keep on volume metrics with no obvious threshold, such as API call rates, egress bytes, or error counts, where the interesting signal is deviation from the learned baseline. Use both: thresholds for the non-negotiables, anomaly bands for the noisy metrics you cannot threshold sensibly.

How do I investigate once an alarm fires?
Go from the metric to the events. Logs Insights lets you query the same CloudTrail log group the filter watched, so you can pull the exact matching events, then pivot on the identity, source IP, and access key involved, and widen the time window to see what else that principal did.