AWS Root Account Best Practices

AWS (Amazon Web Services) root user best practices are similar to those for any AWS user with high-level permissions. However, as the root user is a particularly high-level user, it requires extra care and oversight to keep it safe.

At Logicata, we frequently help our customers secure their AWS accounts as part of our InfrAssure-managed AWS service. Over the years, we have developed a set of AWS account management guidelines with a specific focus on the root user. We share the details in this article.

AWS root account, root user and administrator users: key differences

The account you first create when signing up for AWS has a single user: the root user, which has ownership and access to all the resources in your AWS environment. In this article, we use the terms root user and root account interchangeably.

The root user account has access to everything you configure in AWS, so if it gets deleted or you lose access to it, you risk losing your entire AWS infrastructure, including virtual machines, customer data, backups, and billing history.

Administrator accounts, however, are regular AWS Identity and Access Management (IAM) user accounts that can be used to perform administrative tasks. They are safer to use, as there’s no risk of performing root-only actions, such as deleting your account.

Administrator accounts are also usually created for a particular person, so if someone within your company performs an unintended action, you can track who did it.

There are only ten tasks in AWS that require root user credentials, so administrator accounts can be used for the vast majority of AWS configuration and maintenance.

Why is it important to follow best practices for your AWS root account?

Because of the level of control over an AWS environment that the root account offers, root user credentials can be a high-profile target for malicious actors.

Additionally, it is worth investing the effort to protect yourself against classic human errors that can cause almost as much havoc as a deliberately malicious actor, like forgetting your password and getting permanently locked out of your account.

If you’re hoping to get certified as compliant with ISO 27001, SOC 2, or CIS, you will need to demonstrate good security practices, including for your AWS root account.

Following the tips in this article will help you improve the security of your AWS account and make it easier for auditors and compliance officers to see how your company keeps track of technical changes.

The benefits of a multi-account strategy

While you can only have one root user for each AWS account, your organization doesn’t need to have everything on AWS running within a single AWS account.

In fact, the opposite is true: having multiple AWS accounts within a single organization allows you to segregate different business functions, such as different team functions, billing, and security.

A multi-account setup keeps users from interacting with AWS resources and settings that they should not have access to, limiting any unintentional or deliberate damage.

AWS Organizations allows you to tie multiple AWS accounts together and logically group accounts into different organizational units (OUs). Once created, you can convert your new, empty AWS account into an AWS Organizations account.

This account becomes the management account for your organization and can be used for billing purposes and managing other accounts within your company.

You can then create additional accounts within the AWS Organizations area or invite existing AWS accounts to become part of your organization.

In order to make an AWS Organizations account easier to manage, we recommend that our clients use AWS Control Tower. Control Tower is a highly useful way of managing your AWS Organizations if you have plans to scale the number of accounts beyond more than a handful.

Control Tower creates an AWS Organization for you with existing accounts for management, log archival, and auditing. Control Tower allows you to group accounts into OUs; by default, the logging and auditing accounts fall under a security OU. You can then add extra OUs and accounts for different projects and teams.

As you create more accounts, it can be useful to give each account an alias to make it easier for users to identify which account they’re logging in to. A multi-account architecture that we recommend for most companies is shown below.

Monitoring your AWS root account usage

Setting up automated monitoring for AWS root account usage can help you get ahead of any unauthorized or unexpected sign-ins with root credentials. You can use services like Amazon GuardDuty or AWS CloudTrail to send automated email alerts any time the root account is accessed.

This ensures that if someone with root credentials is trying to secretly access the root account, their activity won’t stay secret for long.

AWS Config is another service that can be helpful for tracking root account actions. AWS Config allows your organization to track changes in its AWS account so that it is always clear which account has made changes to resources.

AWS Config also offers change management tools that you can use to evaluate your existing configuration against desired configurations.

Preventing unauthorized access to an AWS root account

When creating your first AWS account (which will be your root account), you must enforce multi-factor authentication (MFA) on the account. To keep your account even more secure, you can use a physical hardware MFA device such as a YubiKey instead of the standard authenticator phone apps.

Once your AWS account is set up, immediately create an administrator account, and use that instead of the root account for virtually everything going forward.

Do not add a programmatic access key to the root account because this creates one extra way for a hacker to gain access, and as the root account will almost never be used for API access, there is no need for that account to have API permissions. If your root account has an API token associated with it, delete it.

To ensure that no one with root access uses the account when they don’t need to, you can set up AWS policies to restrict what the root account is allowed to do. If you decide to use AWS Control Tower, you should know that it has its own predefined policies called guardrails.

The guardrail names are written in plain English, making them easier to use. You can also set up your own guardrails—for example, you could define an “allow list” of IP addresses that may access the root account. (You can use this to specify that anyone using the root account must be on the corporate VPN.)

It’s also possible to set up guardrails so that an administrator is alerted if there is a guardrail violation.

Avoiding unintended changes at the root level

You should only make your AWS root account credentials available to a small group of tech professionals. If the size of your company allows it, more than one person should have access because one person could become incapacitated, leave the company, or decide to sabotage the system.

Three people is a good number, as the third person can cast a deciding vote in any decisions regarding the root user. You should regularly review who has and who should have access to the root account.

It is a good practice to follow the principle of least privilege. This means giving users the level of access they require to perform a task but no higher. You can also temporarily elevate someone’s permissions if they only need a higher level of access for a short amount of time.

It can be tempting to cave into demands for root access from demanding users (even your CEO or CTO!), but it is perfectly possible to give them sufficient access to any systems they need without giving up the root password.

Ensuring you can recover your root account if you lose access

Make sure you add account contacts with valid email addresses and phone numbers so that AWS support agents can get in touch with your team if you get locked out of your AWS root account. Regularly review your account details and keep them up to date.

Although it can be tempting, you should never completely block access to the root account, as you will need it if something ever goes wrong with the administrator accounts below it.

What to do when a root account user leaves your company

A good offboarding procedure is essential when a team member who had access to AWS root account credentials leaves the company. You’ll need to revoke their access to MFA tokens, change the root account password, and revoke access to any email addresses or phone numbers associated with the root account.

When initially setting up your AWS account, we recommend creating a separate email address on your corporate domain specifically for use as the AWS root account (for example, aws@example.com).

This way, if an employee responsible for the account leaves, it is not tied to their personal email address, and access can be given immediately to another person on the team.

It’s vital to maintain control over not only the AWS root account’s email address but also your domain registration and associated email DNS records.

You can do this by keeping your domain registration with a registrar other than AWS—this way, if anything happens to your AWS account, you still control the domain and just need to recreate all your AWS resources.

Final thoughts

There are many suggestions in this article that you can consider for securing your AWS root account. Tools such as AWS Control Tower can provide a useful structure for following many of the best practices that will help you with compliance, particularly as your infrastructure scales.