Metric Filters for Security Events

Raw logs are rich but passive. A metric filter scans incoming log events in a log group, matches a pattern you define, and turns each match into a numeric data point in a CloudWatch metric. This bridges text logs and the metric world, where you can graph trends and, crucially, trigger alarms.

Security signals are often buried in ordinary logs: a failed login, an unauthorized API call, a console sign-in without MFA. A metric filter extracts exactly those lines and counts them. Once a security event is a metric, it becomes something you can watch and alert on automatically instead of hoping a human notices it scrolling by.

The filter pattern defines what to match. For plain text it can be simple terms, and for JSON logs it can match specific fields, such as { $.errorCode = "AccessDenied*" }. CloudTrail events delivered to CloudWatch are JSON, so JSON filter patterns let you target precise event names and error codes.

When a log event matches, the filter emits a value to a metric you name, placed in a metric namespace. Usually each match increments the metric by one, but you can also publish a numeric field from the log. You also set a default value so the metric reports zero when no events match, which keeps alarms healthy.

AWS publishes recommended filters for CIS-style monitoring: unauthorized API calls, sign-in without MFA, root account usage, IAM policy changes, security group changes, and CloudTrail configuration changes. These map directly to high-value detection points. Building this set gives you broad coverage of the riskiest control-plane actions in an account.

A classic filter matches events where the errorCode is AccessDenied or UnauthorizedOperation. A sudden spike in these often means an attacker is probing what a stolen credential can do. Counting them as a metric lets you alarm when the rate crosses a threshold, catching reconnaissance early.

Changes to security groups, network ACLs, or route tables can quietly open a path for an attacker. A metric filter on event names like AuthorizeSecurityGroupIngress or CreateRoute surfaces these. Because legitimate changes happen too, the alarm tells you to verify the change matches an approved request rather than that something is definitely wrong.

CloudWatch Logs Insights is for ad-hoc, after-the-fact querying you run by hand. Metric filters are continuous and proactive: they evaluate every event as it arrives and feed alarms. Use Insights to explore and metric filters to detect. The exam often contrasts reactive investigation with proactive alerting.

Filters only apply to new events after the filter is created; they do not retroactively scan old logs. You also have a limit on the number of metric filters per log group. Plan your detection set up front, and remember that historical analysis still belongs to Insights or Athena over archived data.

A metric filter alone just counts. Its value appears when you attach a CloudWatch alarm that watches the metric and notifies you through SNS when a threshold is breached. Metric filter plus alarm plus SNS is the standard pattern for turning a suspicious log line into a real-time page to your security team.

Design your filters around the actions that matter most: identity changes, denied calls, network edits, and root activity. Give each a sensible threshold so normal noise does not page anyone, and route alerts to a channel your team actually watches. Well-tuned metric filters are the difference between detection and discovering a breach months later.

Check your understanding of metric filters.

A metric filter matches a filter pattern against incoming log events and converts hits into a CloudWatch metric. JSON patterns target CloudTrail fields like errorCode and eventName. Cover unauthorized calls, MFA-less logins, root use, and network changes. Filters act only on new events, and they shine when wired to an alarm and SNS for real-time detection.