The AWS Root User: What It Can Do and Why You Lock It Away

The problem this concept solves

You sign up for AWS with an email address and a password. That is it — you now have an account, and the identity you just created can do absolutely anything inside it: launch servers, read every file, change the billing details, or delete the whole thing.

That identity is the account root user, and it is the single most dangerous credential you will ever hold on AWS. Understanding why, and what to do about it, is foundational to cloud security and reliably tested on the Cloud Practitioner exam.

What it means in plain English

The root user is the identity created automatically when an AWS account is opened. It signs in with the email address used at sign-up, rather than a username, and it has complete, unrestricted access to every service and resource in that account.

Crucially, you cannot restrict the root user with permissions policies. Every other identity in AWS starts with no access and gets exactly what you grant it. The root user starts with everything, and no policy you write can take that away. This is why AWS's advice is not "limit the root user" but "stop using it."

A useful comparison is a building's master key. It opens every door, including the ones you forgot existed. You would not carry that key daily or hand copies to colleagues. You would put it in a safe and issue everyone ordinary keys for the doors they actually need.

Why it is such a risk

If root credentials leak, an attacker does not get some access — they get all of it, and you cannot revoke their permissions because the root user's power is not permission-based. The realistic consequences:

• Resource destruction. Databases, backups, and servers can be deleted outright.
• Runaway cost. A common pattern is attackers launching expensive compute across many Regions for cryptocurrency mining, generating very large bills quickly.
• Data exposure. Every object in every bucket becomes readable.
• Lockout. An attacker can change the account email and password, making recovery slow and painful.

Tasks only the root user can perform

This is the part the exam tests most directly. A small set of account-level operations genuinely requires root, which is why you keep it rather than delete it. They include:

• Changing the account name, root email address, or root password.
• Changing or cancelling the AWS Support plan.
• Closing the AWS account.
• Restoring IAM user permissions when an administrator has accidentally revoked their own access.
• Enabling MFA Delete on an Amazon S3 bucket.
• Registering as a seller in the Reserved Instance Marketplace.
• Signing up for AWS GovCloud.

Notice the shape of this list: these are things done to the account itself, not day-to-day work. Launching an EC2 instance, creating an S3 bucket, and querying a database are all ordinary tasks that an IAM user or role should do instead.

How to protect it

• Enable multi-factor authentication (MFA) on the root user. This is the single highest-value security action on a new AWS account. Even a stolen password is not enough to sign in.
• Do not create root access keys. Long-term programmatic keys for root serve no legitimate purpose. If any exist, delete them.
• Create an administrative IAM user or use IAM Identity Center for daily work, then stop signing in as root.
• Use a strong, unique password and store it in a password manager.
• Make sure AWS CloudTrail is enabled so every root action is recorded and auditable.
• Keep the root email address monitored. Use an address a team can access, not one person's personal inbox, so account recovery does not depend on one individual.

Hypothetical scenario: A student club opens an AWS account for a class project. The treasurer signs up, immediately turns on MFA for the root user, creates an IAM user with administrator permissions for herself, and shares the root password only through the club's password manager. For the rest of the semester nobody signs in as root — until the club closes the account at the end of the year, which only root can do.

Do not confuse these concepts

• Root user: Created automatically with the account, signs in by email, has unrestricted access that cannot be limited by policy.
• IAM user with AdministratorAccess: Looks powerful, but its permissions come from an attached policy — which means they can be scoped, audited, or revoked. It still cannot perform the root-only tasks listed above.

Quick recall

	Root user	IAM user
Created	Automatically, with the account	Manually, by you
Signs in with	Account email address	Username within the account
Permissions	Unlimited; cannot be restricted by policy	Only what its policies grant
Can be deleted	No	Yes
Intended use	Initial setup and a few account-level tasks	All day-to-day work
Protection priority	Enable MFA immediately, then stop using it	Least privilege, MFA, rotate credentials

Key takeaways

• The root user is created with the account, has unrestricted power, and cannot be limited by permissions policies.
• A short list of account-level tasks — changing the Support plan, closing the account, enabling S3 MFA Delete — genuinely requires root; everything else should use an IAM identity.
• Protect it by enabling MFA, deleting any access keys, and using an IAM user or IAM Identity Center for daily work.

Check your understanding

1. Why can you not simply attach a restrictive policy to the root user to make it safer?
2. Name two tasks that only the root user can perform.
3. What is the first security action you should take on a newly created AWS account?

Suggested answers

1. The root user's access is inherent to the account rather than granted by a permissions policy, so IAM policies cannot reduce it. This is why the recommended approach is to secure and stop using the root user rather than trying to limit it.
2. Any two of: changing the account name, root email, or root password; changing or cancelling the AWS Support plan; closing the AWS account; restoring accidentally revoked IAM administrator permissions; enabling S3 MFA Delete; registering as a seller in the Reserved Instance Marketplace; signing up for AWS GovCloud.
3. Enable multi-factor authentication on the root user, so a stolen password alone cannot be used to sign in. Creating an IAM identity for daily work and deleting any root access keys follow closely behind.

Continue learning

• Best practices to protect your AWS account root user – AWS
• Tasks that require root user credentials – AWS