Detecting Root Account Usage

The root user is the account owner identity created when an AWS account is opened, and it has unrestricted access to every action and resource. It cannot be limited by IAM policies or SCPs. Because of this power, any use of the root user is a high-signal security event worth alerting on immediately.

AWS guidance is to use the root user only for the handful of tasks that require it, then never again. You should enable MFA on root, remove its access keys entirely, and create IAM identities or Identity Center users for daily work. After lock-down, legitimate root activity should be rare and planned.

Because root should almost never sign in, an unexpected root login is a strong indicator of compromise or policy violation. Detecting it is one of the canonical CIS Benchmark monitoring controls and a frequent exam scenario: the expected answer is a CloudTrail-fed metric filter and alarm, not a manual review.

The detection uses three pieces you already know: CloudTrail records the sign-in and API events, CloudWatch Logs receives those events when CloudTrail is configured to deliver to a log group, and a metric filter plus alarm turns root events into an instant notification. Each piece must be in place for the chain to work.

In a CloudTrail event, the userIdentity.type field equals Root when the root user performs the action. A metric filter can match this field. To avoid noise from routine automated events, filters often also exclude AWS service events so only genuine human root actions trigger the alert.

By default CloudTrail writes to S3, not CloudWatch Logs. To alarm in near real time you must configure the trail to also deliver events to a CloudWatch Logs group. This requires an IAM role that lets CloudTrail write to the log group. Without this delivery step, the metric filter has nothing to match.

Create a metric filter on the CloudTrail log group with a pattern matching userIdentity.type = Root. Map each match to a metric such as RootAccountUsageCount with a value of one. Now every root action increments a metric you can watch, converting a buried JSON field into a measurable signal.

Attach a CloudWatch alarm to the metric with a threshold of one over a single short period, so it fires on the very first root event. Point the alarm at an SNS topic subscribed by your security team. The result is a near-instant page the moment root is used.

In an organization, each member account has its own root user. An organization trail can centralize CloudTrail across all accounts, and you can build the detection once against the central log group. This ensures no member account's root activity slips by unmonitored, a key governance requirement.

When the alarm fires, treat it as an incident until proven otherwise. Confirm whether the activity was a planned, authorized task. If not, secure the account: rotate the root password, verify MFA is intact, review recent root actions in CloudTrail, and check for new IAM identities or keys an attacker may have created.

Detecting root usage ties together CloudTrail, CloudWatch Logs, metric filters, alarms, and SNS in one realistic control. Expect questions where the wrong answers suggest manual review, IAM policies on root, or SCPs. The right answer is always automated detection plus immediate notification, because root cannot be restricted, only watched.

Test the root-usage detection pattern.

The root user is unrestricted and should be locked away with MFA and no access keys. Any use is a high-signal event. Detect it by delivering CloudTrail to CloudWatch Logs, adding a metric filter on userIdentity.type = Root, and firing a CloudWatch alarm to an SNS topic. In organizations, an organization trail centralizes this detection across every account.