Get Into AWS Safely
Create your account, learn who can act inside it, and lock down identity the right way, root, MFA, IAM, Identity Center, and how the CLI actually authenticates.
From your mentor
We do the easy, obvious thing first, see exactly why it's dangerous, then climb one safe step at a time. By the end you'll have a locked-down account and a real mental model of AWS identity, not just clicked buttons.
Getting into AWS safely is just one habit: don’t use the master key for daily work.
In 10 minutes you’ll know who should log in, how, and why. You do NOT need to memorize IAM policy JSON yet.
Pick your way in, same idea, 5 doors
When you open an AWS account you get one all-powerful login, the root user. It’s the master key to the whole building. The entire game is simple: lock that key in a drawer, and make smaller, limited keys for everyday work.
Create your account (and pick the right plan)
The very first screen already asks you to make a decision. Here's how to get it right.
Creating the account takes about five minutes. Here’s the whole flow, then the one decision in it that actually matters.
- 1
Go to aws.amazon.com
Choose “Create an AWS account.”
- 2
Email + password
These become your root account credentials.
- 3
Add a card
For identity & overflow only, not charged on the Free plan.
- 4
Choose a plan
Free or Paid. This is the decision.
- 5
Verify & sign in
You land in the console as the root user.
That fourth step is new, since July 2025, AWS makes you pick a plan at sign-up, and it trips up beginners. Here’s the whole choice in two cards:
Free plan
Learning, and everything in this course
- Up to $200 in credits ($100 at sign-up + $100 as you use key services)
- Free for up to 6 months, or until your credits run out
- Keeps 30+ “always free” services within monthly limits
Paid plan
Real production apps that outgrow credits
- Pay-as-you-go once credits or always-free limits are exceeded
- Also eligible for up to $200 in credits
- No 6-month cap, meant for ongoing workloads
Pick the Free plan
It’s free for months and keeps the 30+ always-free services where most of our hands-on lives. We’ll add a billing alarm in Section 7, so there are zero surprises. (The full Free Tier mechanics get their own lesson next.)Verify your email and sign in. AWS drops you onto the console as the root user, so before we touch anything, let’s understand exactly what that means.
Who can actually act in your account
Every AWS action is taken by a principal, an identity AWS can authenticate. There are four you'll meet, and picking the right one is the whole game.
Before changing anything, get the mental model. The difference between these four identities, and which one you reach for, is most of what “securing AWS” really means.
| Principal | What it is | Credentials | Lifetime | Reach for it when |
|---|---|---|---|---|
| Root user | The owner identity tied to the account email | Email + password (+ MFA) | Permanent | Only the handful of root-only tasks (next section) |
| IAM user | A named identity created inside the account | Password and/or long-lived access keys | Until you rotate/delete it | A person or app needing standing access, use sparingly |
| IAM role | Permissions any trusted principal can assume | Temporary, auto-expiring (via STS) | Minutes–hours | Apps on EC2/Lambda, CI (OIDC), cross-account, no stored secret |
| Identity Center user | A workforce identity in the SSO directory | Short-lived session credentials | Session-bound | Humans signing in to one or many accounts |
Notice the direction of travel
The whole industry is moving away from permanent credentials (root, IAM access keys) and toward temporary ones (roles, Identity Center sessions). Every ladder in this course climbs that same way, so once you see it here, it repeats everywhere.The root user, and the few things only it can do
Root isn't just 'admin'. It's the account's owner, with a short list of powers no IAM identity has. Knowing that list is what lets you safely lock it away.
Root can do anything, and a handful of tasks only root can do. So the rule is simple: learn the short list, do those as root, and do everything else as an IAM identity or through Identity Center.
| Area | Tasks that require the root user |
|---|---|
| Account | Change the root email, password, or access keys (standalone accounts); close the account |
| Account | Restore permissions if your only IAM admin locks themselves out |
| Billing | Turn on IAM access to the Billing console; view certain tax invoices |
| S3 / SQS | Fix a bucket/queue policy that denies all principals; enable S3 MFA Delete |
| EC2 | Register as a seller in the Reserved Instance Marketplace |
| KMS | Recover an otherwise-unmanageable KMS key (via AWS Support) |
| Other | Sign up for AWS GovCloud (US); link a Mechanical Turk Requester account |
If it isn't on that list, it isn't a root task
Launching an EC2 instance, creating a bucket, writing a policy, none of that needs root. Treat root as break-glass: used rarely, protected by MFA, and alerted on.The break-glass setup, concretely: secure the root email inbox, give root a long unique password in a password manager, add MFA, delete any root access keys (root should never have programmatic keys), and set an alert on root sign-in, an EventBridge rule on the console login event is the common pattern.
MFA: which type, and why AWS now forces it
AWS enforces MFA on the root user, but not all MFA is equal. Here's what to choose and the enforcement timeline you're living in.
| Type | What it is | Phishing-resistant? | Best for |
|---|---|---|---|
| Passkey (FIDO2) | Synced cryptographic key (phone, browser, password manager) | Yes | Default choice, strong and easy |
| Security key (FIDO2) | Physical key (e.g. YubiKey) | Yes | Highest assurance; shared/break-glass root |
| Authenticator app (TOTP) | 6-digit rotating codes from an app | No, phishable | Acceptable fallback |
| Hardware TOTP token | Physical code-generating fob | No, phishable | Legacy / regulated environments |
Prefer a passkey or security key
FIDO2 is phishing-resistant, the credential is bound to the real AWS domain, so a fake login page can’t replay it. TOTP codes can be phished or relayed. You can register up to 8 MFA devices per user, add two, so a lost phone doesn’t lock you out.The enforcement is already rolling out, you’re not choosing whether to do this, only when:
| When | What changed |
|---|---|
| May 2024 | MFA required for AWS Organizations management-account root users |
| Jun 2024 | Required for standalone-account root users; FIDO2 passkeys launched |
| Nov 2024 | Centralized root-access management introduced for Organizations |
| Jun 17, 2025 | Extended to member-account root users, set up MFA within 35 days of console sign-in |
The access climb, console and CLI
You're signed in as root right now, Rung 0. Here's the climb for both surfaces, where each console step pairs with its command-line equivalent.
Root is convenient on day one and catastrophic on day two. So we climb off it, on the console and the command line together, because they reach the same summit: short-lived, MFA-protected access.
Work as the root user
Sign in with your account email and do everything as root.
If that email/password leaks, the attacker owns the entire account, no limits, all or nothing.
IAM admin user + MFA
Make a user for yourself with admin permissions and MFA; do daily work as that user.
A scoped identity you can rotate, restrict, or delete. Root gets locked in a drawer.
IAM Identity Center
Sign in through SSO that hands you short-lived credentials.
No standing admin to leak; centralized, MFA-protected, auto-expiring. AWS’s recommended way to sign in today.
MFA on root is enforced now
Add it immediately, prefer a passkey or security key, then stop logging in as root unless a task truly requires it (the short list in Section 3).Both ladders end in the same place
Console or CLI, the destination is identical: short-lived, MFA-protected credentials from IAM Identity Center. You’re climbing two paths to one summit.How the CLI decides who you are
When you run an `aws` command, the CLI walks a fixed list of credential sources top to bottom and uses the first it finds. Knowing this order saves hours of 'why is it using the wrong account?'
| # | Source | Notes |
|---|---|---|
| 1 | Command-line options | --profile, --region, override everything |
| 2 | Environment variables | AWS_ACCESS_KEY_ID, AWS_PROFILE, AWS_REGION… |
| 3 | Assume role | role_arn in config, or sts assume-role |
| 4 | Assume role with web identity | OIDC, e.g. GitHub Actions in CI |
| 5 | IAM Identity Center (SSO) | ~/.aws/config; activated by aws sso login |
| 6 | Credentials file | ~/.aws/credentials (written by aws configure) |
| 7 | Custom process | credential_process, sourced externally |
| 8 | Config file | ~/.aws/config |
| 9 | Container credentials | ECS task role |
| 10 | EC2 instance profile | IMDS on the instance |
The #1 beginner footgun
A staleAWS_ACCESS_KEY_ID or AWS_PROFILE environment variable silently wins over the nice --profile you passed (it’s higher in the list). When something looks wrong, ask the CLI who it thinks you are:That one command is the fastest way to confirm which identity and account you’re actually operating as:
$ aws sts get-caller-identity --profile learn
{
"UserId": "AIDA...",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:user/your-name-admin"
}Two files do different jobs. ~/.aws/credentials holds long-term keys; ~/.aws/config holds profiles, region, and SSO settings. aws configure writes both; aws configure sso sets up the SSO blocks.
[profile learn] sso_session = my-sso sso_account_id = 123456789012 sso_role_name = AdministratorAccess region = eu-west-1 output = json [sso-session my-sso] sso_start_url = https://my-org.awsapps.com/start sso_region = eu-west-1AWS docs: configuration & credential files
[learn] aws_access_key_id = AKIA... aws_secret_access_key = ... # long-term keys only, prefer SSO above
Billing guardrails (so there are no surprises)
Identity is locked down, now make sure a stray resource can't run up a silent bill. Three tools, increasing usefulness.
| Tool | What it watches | Best for |
|---|---|---|
| Free Tier usage alerts | % of free-tier limits consumed | Knowing you’re nearing a free limit |
| CloudWatch billing alarm | Estimated charges crossing a threshold | A simple “ping me at $5” alarm |
| AWS Budgets | Cost/usage vs a budget, with forecasts + multiple alerts | The real tool, set this one |
Set a budget today, before you run anything
Create an AWS Budget for a few dollars now. On the Free plan you won’t be charged, the point is to prove the alert fires before you ever launch a real resource. (Billing gets its own deep lesson next.)How this shows up in interviews
“You've just been given a brand-new AWS account. How do you secure it?”
How to answer it
Answer it as a prioritized climb, first 5 minutes, then the first hour, and say why each step exists, not just what it is.
- 1First 5 minutes: add MFA to the root user (passkey or hardware key), then stop using root entirely, it becomes break-glass only.
- 2Give myself access the right way: set up IAM Identity Center and assign an admin permission set, so I sign in via SSO with short-lived credentials instead of a standing IAM user.
- 3If Identity Center is overkill for a solo account, at minimum an IAM admin user with MFA, and delete root’s access keys outright.
- 4No long-lived keys for automation: use IAM roles (instance profiles, OIDC for CI) so nothing carries a static secret that can leak.
- 5Day-one guardrails: a budget + billing alarm so a misconfigured resource can’t run up a silent bill, and CloudTrail on for an audit log.
Green flags
- Locks down root + MFA first, treats it as break-glass
- Prefers IAM Identity Center / short-lived credentials
- Mentions billing alarms and least privilege unprompted
Red flags
- Does everything as root
- Hardcodes long-lived access keys
- “I’d just give myself AdministratorAccess and move on”
Q.What can the root user do that an IAM admin can’t?
A.Only a short, fixed list of account-level tasks. Everything else should go through IAM or Identity Center.
- Change the account email/password, or close the account.
- Restore a locked-out IAM admin, and turn on IAM access to Billing.
- Fix a resource policy that denies every principal (e.g. an S3 bucket or SQS queue).
- Enable S3 MFA Delete, plus a few sign-ups (Marketplace seller, GovCloud).
They’re checking: That you treat root as ~a handful of break-glass tasks, not a daily login.
Q.IAM user vs IAM role, when each?
A.Prefer roles (temporary, no stored secret); use users only for break-glass or legacy tools.
They’re checking: That you default to roles and can name long-lived keys as the risk.
Q.The CLI is using the wrong account, how do you debug it?
A.Run aws sts get-caller-identity to see who you really are, then walk the precedence chain top-down.
- Order: the --profile flag, then environment variables, then the ~/.aws/config & credentials files.
- Usual culprit: a stale AWS_ACCESS_KEY_ID or AWS_PROFILE, env vars outrank the profile files.
They’re checking: That you know env vars override the profile files, not the other way round.
Q.Why are passkeys/security keys better than an authenticator app?
A.FIDO2 passkeys/security keys are phishing-resistant; prefer them over TOTP codes.
They’re checking: That you know WHY FIDO2 wins (domain binding), not just that it’s newer.
Your turn, in a real AWS account
Reading isn't enough. Open your own account and climb the first rungs, about 20 minutes, all inside the Free plan.
Now do it in your own account
Sign in to the account you created in Section 1, then work through these in order. Everything here stays inside the Free plan.
Before you start
3 to have readyThe AWS account you created in Section 1 of this lesson.
An MFA device: a passkey/security key (best) or an authenticator app.
AWS CLI v2 installed (for the last three steps).
aws --version- 1
Add MFA to the root user, then sign out of root.
Free tierConsole → IAM → Security credentials → MFA
You should see: root shows a registered MFA device; your next root sign-in asks for it.
Register a second device as backup so you can’t lock yourself out.
- 2
Create an IAM admin user for yourself with console access + AdministratorAccess.
Free tierConsole → IAM → Users → Create user
You should see: the user appears with the AdministratorAccess policy attached.
- 3
Add MFA to that IAM user, and sign in as it from now on.
Free tierConsole → IAM → Users → (your user) → Security credentials
You should see: you can sign in as the IAM user with MFA, no more daily root.
- 4
Confirm root has no access keys.
Free tierConsole → IAM → (root) Security credentials
You should see: Access keys: None. Root should have zero programmatic credentials.
- 5
Set a low AWS Budget so a bill can never surprise you.
Free tierYour terminal
aws cli
AWS docs: budgets create-budget$ aws budgets create-budget --account-id <acct> --budget file://budget.jsonYou should see: the budget appears under Billing → Budgets.
- 6
Store credentials under a named CLI profile (never in a file you’d commit).
Free tierYour terminal
You should see: a [profile learn] block in ~/.aws/config.
- 7
Confirm exactly who the CLI thinks you are.
Free tierYour terminal
You should see: the ARN is your new IAM admin user, not root.
Last step: tear it down
Once you’ve seen it work, remove everything so nothing keeps billing.
Nothing here costs money: IAM users, MFA, and a budget are all free.
If you spun up any test resources while exploring, delete them now.
Store your root credentials securely offline; you should rarely need them again.
Next up
Lesson 2, Free Tier & what AWS actually charges for
Always-free vs 12-month vs credits, and the handful of dimensions (data transfer, idle resources, NAT) that quietly run up a beginner's bill.