Signing Into AWS and Setting Up Your First IAM User

The first few minutes inside a new AWS account trip up more people than they should — starting with a sign-in screen that assumes information you don't have yet. Here's how I get past it, sort out IAM from IAM Identity Center, and set up a non-root user so I'm not doing everyday work from the root account.

The sign-in screen nobody warns you about

If you've just created an AWS account and gone looking for the sign-in page, you've probably hit a small but genuinely confusing wall. The default AWS sign-in form asks for an account ID or alias and an IAM username — neither of which you have yet if this is your first time in. There's no IAM user, because you haven't created one, and you may not have bothered to memorize or alias your twelve-digit account ID.

The way through is the option most people skip past: signing in as the root user, using the email address you used to create the account. It's usually a toggle or a secondary link on the sign-in page rather than the default path, which is exactly why it trips people up — the form's default assumes you're a returning IAM user, not someone logging in for the very first time.

I want to flag this explicitly because it's the kind of thing that seems obvious in hindsight but genuinely stalls people out at the very first step of using AWS. If you're staring at a login form asking for details you don't have, you're not missing something — you're just on the wrong tab of the form. Switch to root user sign-in, enter the email tied to the account, and continue.

Logging in as root — and a word about MFA

Once you're on the correct sign-in path, logging in as root is straightforward: email, password, and you're in. If you set up multi-factor authentication when you created the account, you'll be prompted for it here. If you didn't, the login will just go through without any extra step.

That second scenario is worth pausing on. It's easy to treat a clean, uninterrupted login as a sign that everything's fine — no MFA prompt, no friction, no problem. But the absence of a prompt isn't a green light; it just means the account isn't protected the way AWS strongly recommends it should be. The root user has unrestricted access to everything in your account, including billing, and it's the one identity you can't scope down with a permissions policy the way you can with an IAM user. AWS's own guidance is to enable MFA on the root account specifically because of that unlimited blast radius — a compromised root login with no second factor is about as bad as an AWS security incident gets.

So if you got into your account without an MFA prompt, don't read that as a sign of a job well done. Treat it as a to-do item: go into your account settings and set up MFA on root before you go much further, ideally before you start attaching real resources, billing, or production workloads to the account. It takes a few minutes with an authenticator app or a hardware key, and it closes off one of the more serious ways a new AWS account can go wrong. I'd genuinely recommend doing this before you even continue with the rest of what's below — everything else in this walkthrough matters less than not leaving root wide open.

Finding IAM — and sorting it out from IAM Identity Center

Once you're in the console, the fastest way to get anywhere in AWS is the search bar at the top. Type "IAM" and you'll get a short list of results, and this is where a second point of confusion shows up: there are two services with almost identical names sitting right next to each other — IAM, and IAM Identity Center.

IAM, or Identity and Access Management, is the foundational service for controlling who and what can do what inside a single AWS account (or a small set of accounts you manage directly). It's where you create users, groups, roles, and policies. This is the one most people need first, and it's the one this walkthrough focuses on.

IAM Identity Center is a related but distinct service, generally associated with managing workforce access across multiple AWS accounts under an AWS Organization — think centralized sign-on for a company with several linked accounts, rather than a single standalone account. If that's not your situation, you can safely set it aside for now.

I'll say plainly that this is a simplified way of drawing the line between the two, and it's worth double-checking against AWS's own documentation if you're making an architectural decision rather than just getting your first account set up. The two services solve different problems — IAM Identity Center is really about centralizing identity across an organization of accounts, not just a matter of "more than one organization" — and if you're ever operating in a multi-account setup, it's worth understanding Identity Center properly rather than working from a one-line summary. But if you've got a single account and you're trying to get your first non-root user set up, IAM is the door you want, and the search bar is the fastest way to it.

Creating a user so you can stop using root

Inside IAM, the left-hand navigation has a "Users" section, and that's where the real work of this setup happens. If you click into it, you may see an existing example user already listed — useful as a quick preview of what the finished result looks like, with a name, an ARN, and whatever access it's been granted.

The actual goal here is to create a new user for yourself, specifically so that day-to-day work — logging in, managing resources, running the AWS CLI, whatever it ends up being — doesn't happen through the root account. This is one of the more consistently repeated pieces of AWS guidance for a reason: root access is meant to be reserved for a small number of account-level tasks (closing the account, changing support plans, certain billing actions), not the account you reach for every morning. A dedicated IAM user, scoped to only the permissions it needs, is the standard way to work instead.

Creating the user itself is the easy part — give it a name, decide whether it needs console access, and move on to assigning permissions, which is really its own step and worth treating carefully rather than rushing through. What matters most right now is the shift in habit: once this user exists, root goes back in the drawer, used only when something specifically requires it, and everyday work moves to an identity that can be scoped, monitored, and revoked without touching the keys to the whole account.

Conclusion

Getting through these first few screens — finding the right sign-in path, logging in as root, telling IAM apart from IAM Identity Center, and creating a non-root user — clears out most of the friction that makes a brand-new AWS account feel harder than it needs to be. If you haven't already, the one thing worth doing before anything else is turning on MFA for your root account; it's a small step now that closes off a genuinely serious risk later. From there, the natural next move is going back into your new IAM user and working through what permissions it actually needs.