Managing the AWS root user and admin access for a team

The AWS root user isn’t meant for a team to share day to day, and AWS strongly recommends against using it for everyday work. Give your everyday admins their own sign-ins. Protect the root user with MFA (multi-factor authentication: a second check after the password), and make sure each use leaves a record.

What the root user is

When you create an AWS account, you start with one sign-in that has complete access to every service and resource in it. That sign-in is the root user. It uses the email address and password that created the account.

AWS enforces MFA for the root user by default. If MFA isn’t already on, it has to be registered within 35 days of the first sign-in attempt. After that, the root user can’t open the AWS Management Console until MFA is registered. What is a privileged account? shows where the root user sits among other admin accounts.

Tasks only the root user can do

AWS keeps a list of tasks that require the root user. Many are about the account itself and billing; the rest belong to specific services.

• Account settings. For a standalone account that isn’t part of AWS Organizations, changing the root email address, root password and root access keys, and closing the account. Reopening a standalone account you closed yourself also needs it.
• Recovery. If the only IAM admin accidentally removes their own permissions, the root user can sign in and restore them.
• Billing. Letting IAM users and roles into the Billing and Cost Management console, plus some other billing tasks and certain tax invoices.
• Specific services. Fixing an Amazon S3 bucket policy or SQS queue policy that locks everyone out, seller registration in the Reserved Instance Marketplace, and signing up for AWS GovCloud (US).

Other work doesn’t need the root user. If your team uses it for routine changes, you can move that work to personal sign-ins, as the next section describes.

Give everyday admins their own sign-in

For daily tasks, AWS recommends setting up an admin user in AWS IAM Identity Center. IAM Identity Center is AWS’s service for connecting your staff to AWS accounts and apps. You can connect your existing identity provider, such as Okta or Microsoft Entra ID, and sync users and groups from it. You can also create users directly in IAM Identity Center. If you use AWS Organizations to group several AWS accounts, permission sets let you define the rights for a job, such as admin, once. You then give that set to people and groups across your accounts.

AWS’s IAM best practices point the same way. People should sign in through an identity provider and get credentials that expire, rather than long-term passwords and keys. The list also asks you to require MFA, grant only the permissions a task needs, and regularly remove users, roles and permissions nobody uses. IAM users keep long-term passwords and access keys, so AWS recommends them only where expiring credentials won’t work. With personal sign-ins, AWS’s records show which person acted and with which rights.

Handling the root user when several people need it

Each AWS account has one root user, so every person who handles it uses the same login. AWS’s root user best practices say how to manage that.

• Share the root password, MFA and access keys only with people who have a strict business need. Log and monitor access to the password and where it’s stored. Consider making access to that storage need approval from at least two people.
• Don’t store the root password in a tool that depends on AWS services in the same account. If you lose the password, you lose the tool too.
• Where you can, give the password to one group of admins and the MFA to another. Signing in then takes one person from each group (AWS calls this multi-person approval).
• Use an email address that your business manages and that forwards to a group of people. AWS can then reach someone even when a person is on vacation, out sick, or gone. Don’t use that address for anything else.
• Don’t create root access keys. Those keys let scripts and command-line tools act as the root user.
• Register more than one MFA device, up to eight. If one is lost or damaged, you can sign in with another.
• Have one group manage the recovery email inbox and a different group manage the phone number. Both can reset the root password, so no one person should hold both.

If you group accounts with AWS Organizations, you can also remove root user credentials from member accounts centrally. Those member accounts then can’t sign in as the root user or recover its password, unless you allow password recovery. Once centralized root access is on, accounts you create inside Organizations start out with no root user credentials. The management account, or a delegated admin, can perform some root-only tasks on member accounts.

Recording who used the root user

AWS CloudTrail records actions by a user, a role or an AWS service as events, whether they came from the console, the command line or code. Its Event history lets you search and download the last 90 days of management events for each AWS Region, at no charge. To keep events longer, create a trail, which stores them in an Amazon S3 bucket. AWS also recommends alerts on every root sign-in and use. Have a procedure so whoever gets the alert can check whether the use was expected and escalate if not.

Everyone who uses the root user signs in with the same email address and password. So CloudTrail can show that the root user acted, but not which person it was. AWS’s advice to log access to where the password is kept fills that gap. That log, along with the approval record if you require two people, ties each use to a person. For other ways to run admin logins that stay shared, see Managing privileged accounts.