We all know that using the AWS root account is bad practice and that we should rely only on IAM users.

The ideal scenario

We should always protect the root account with a (possibly hardware) MFA device and close the MFA in a safe place and forget about it. One final step, we can reset the root account password with one we are not going to store or remember. And eventually retrieve a reset link by email if ever needed.

What about exceptions?

Unfortunately as for today there are still a few operations that require access to the root account including:

• Submitting Penetration Testing Forms
• Enable/Disable IAM User access to Billing Console
• Closing the accounts
• Adding sub accounts
• Adding/Removing Root MFA
• Setting up Consolidated Billing for sub accounts

Any other one?

If a couple of them are obvious and expected (closing the account for example), others are less so.

They are indeed not very common operations but it’s still useful to know they are exception as – almost all in case of distributed teams or distributed companies – is not very easy to go around them.

Think of a locked MFA device in a cabinet in a different office in a different continent when you need to submit a penetration request or setup consolidated billing.

Even if it might sound a positive feedback when you tell an audit company you cannot give them the OK for a penetration test as you have locked down your account so well you cannot even submit a request to AWS.