Originally published at unifiedpathmedia.com.
The short version: Most AWS (Amazon Web Services) tutorials sprint straight to launching an EC2 (Elastic Compute Cloud) instance, a virtual server. That means most people’s accounts start with a security setup nobody chose on purpose. Before you build anything, spend five minutes on what matters most: lock down the root user with MFA, create a proper IAM (Identity and Access Management) admin user for daily work, and set a billing alarm. Do these three first and everything you build afterward sits on a foundation that isn’t on fire.
← Part of the AWS Foundations series
Published September 2, 2026.
Last verified November 5, 2026 against AWS’s IAM documentation on root user MFA and root user best practices.
Who this is for: anyone who has just opened an AWS account, or is about to. You’ll need first: nothing. This is step one.
Opening a new account? Read AWS Free Tier in 2026 first. New accounts now run on credits instead of 12 months free, and this series walks through the classic (advanced) sign-up path.
Most AWS tutorials skip straight to the fun part. This one covers the five minutes of setup that matter more than almost anything else you’ll do in AWS: the boring five minutes that save you a very exciting afternoon later.
Lock down the root account first
The root account is created with your AWS account. It has unrestricted access to everything, and there’s no way to dial back its permissions. It’s the master key to the entire building, and you can’t make it any less powerful, so the move is to secure it and then leave it alone.
The most important thing you can do in AWS is turn on MFA (multi-factor authentication) for the root account right away, before you create anything else. AWS now requires MFA on the root user for every account. It gives you 35 days from your first sign-in to register it, so you may as well do it on day one. After that, root should almost never be used for daily work. Its job is limited to the few actions that require it, such as closing a standalone account or changing the root user’s email address or password. Everything else goes through an IAM user or role. Think of root as the deed to the house: you keep it in a safe, you don’t carry it around.
The root account and IAM hierarchy: what should (and shouldn’t) use the root user.
Create your first IAM admin user
Right after securing root, create an IAM user with administrator permissions for your day-to-day work. The alternative is IAM Identity Center, which AWS now recommends for people signing in, even if it’s just you, because it hands out short-lived credentials instead of long-lived access keys. An IAM user is the simpler path for a personal learning account, and it’s what this series uses. Treat its access keys like a password and never put them in code. This is the identity you’ll log in as, build from, and create access keys from if you need them.
Then put the root credentials away for real. Change the password to something long and unmemorable, store it somewhere secure, never create access keys for root, and don’t touch it again unless you must. Using root for daily work is the AWS equivalent of doing your grocery shopping in a tuxedo: technically possible, wildly unnecessary, and you’ll regret it the moment something spills.
Once that is done, a quick check confirms the CLI (command line interface) is running as your IAM user, not root. The Arn (Amazon Resource Name, the unique ID AWS gives every resource) should end in a user, never :root:
$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: ****************EXAMPLE
Default region name [None]: us-east-1
Default output format [None]: json
$ aws sts get-caller-identity
{
"UserId": "AIDACKCEVSQ6C2EXAMPLE",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:user/jose-admin"
}
Set billing alerts before you build anything
Open AWS Budgets and set a budget with an alert before you create a single resource. A simple alert at $20 or $50 (pick your own comfort level) means you hear about unexpected spend within a day. Without it, you find out at the end of the month, when there’s nothing left to do but pay. This one step prevents the most common bad first experience with any cloud: the surprise bill from a resource you forgot was running.
Why this order matters
Do all of this before building anything else, and everything you create from here on sits on a reasonably secure foundation: made by an IAM identity instead of root, with cost visibility already switched on. You can retrofit this after you’ve got a dozen resources running. It’s just more annoying, like childproofing the house after the toddler has already learned to run.
Next: AWS Part 2: IAM Basics — Users, Roles & Least Privilege
← Back to the AWS Foundations series
I write a free, plain-English cloud lesson every week at Unified Path Media. Next step after this post: set a spending alarm in ten minutes with FinOps Foundations Part 1.
Top comments (0)