Right, let’s talk about the first thing you do when you move into a new house: you don’t start living out of the moving boxes in the master bedroom. You unpack, you find the toolbox, and you figure out where the main water shutoff valve is before a pipe bursts. In AWS, the root user account is that master bedroom. It’s the keys to the entire kingdom, and using it for daily work is like using a master keyring with 500 keys to open your front door—risky, clumsy, and frankly, a bit absurd.

When you first create an AWS account, the root user is all you have. This entity has unrestricted, god-like access to every single service and resource in your account. There is no door it cannot open, no check it cannot write. And that is precisely why it’s so dangerous. You should never, ever use it for your day-to-day console logins or for programming access. Why? Because if its credentials are compromised, the attacker owns everything. Game over. No take-backsies. The only things you should use the root user for are the few account-level tasks that absolutely require it, which we’ll get to in a moment.

The Anatomy of an IAM User

So, if we’re not using the root user, what do we use? We use IAM Users. An IAM User is an identity you create within your AWS account that has specific, tailored permissions. Think of it as creating a specific key that only unlocks the doors to the rooms that person needs to enter—the front door, the kitchen, but definitely not the secret vault behind the bookshelf.

You create a user for a person or an application that needs to make AWS API calls. Each user has a friendly name (like alice or prod-api-server) and an Amazon Resource Name (ARN) that uniquely identifies it across all of AWS. The two types of access you can grant a user are:

  1. Programmatic access: This provides an Access Key ID and a Secret Access Key for making API calls via the CLI, SDKs, or other tools. This is for code.
  2. AWS Management Console access: This provides a password, allowing the user to sign in to the web-based AWS console. This is for humans.

You’ll almost always want to enforce Multi-Factor Authentication (MFA) on users with console access. It’s the single most effective thing you can do to prevent account hijacking.

Here’s how you create a user with the AWS CLI. Notice I’m not using the root user’s credentials to do this; I’m assuming I already have an admin user set up (which you absolutely should).

# Create a new IAM user named 'alice'
aws iam create-user --user-name alice

# Now, let's create a console login profile and password for her.
# You'll be prompted to set a password. Make it strong.
aws iam create-login-profile --user-name alice --password-reset-required

# For programmatic access, we create an access key.
# The Secret Access Key is only shown once here. Save it somewhere secure IMMEDIATELY.
aws iam create-access-key --user-name alice

The output of that last command is your credentials. Lose the Secret Key, and you’ll have to rotate it (delete the old one and create a new one). It’s a hassle.

The Sacred and Few Duties of the Root User

The root user isn’t useless; its power is just reserved for a handful of nuclear options. You should log in as the root user only to perform these specific tasks:

  • Changing your AWS support plan (because it affects billing).
  • Changing your root user email address or password (the ultimate account recovery).
  • Enabling MFA on the root user account itself (do this immediately if you haven’t).
  • Reactivating closed accounts (a rare edge case).
  • Viewing certain tax and invoicing information.
  • Closing your AWS account (the final boss of account management).

Once these are done, log out. Seriously. Go ahead, I’ll wait. The best practice is to take the root user’s access keys—if it even has any—shred them in the IAM console, and store the password and MFA token in a ridiculously secure place like a physical vault or a password manager only the CTO can access.

The Inevitable “I Locked Myself Out” Scenario

Here’s a classic pitfall: you’re the only IAM admin, you’ve attached a poorly written policy to your user that denies all iam:* actions, and you’ve effectively sawed off the branch you’re sitting on. You can’t fix your own permissions. This is where you have to swallow your pride, break the glass, and log in as the root user to fix the mess. The root user is your ultimate safety net for IAM recovery. It’s a design choice by AWS that is occasionally infuriating but ultimately necessary. It means you can never truly, permanently lock yourself out of your own account. So, while you should dread using it, be very glad it exists.