Your First AWS Account, Safely

In one line

The root user of a brand-new AWS account can do absolutely anything with zero restriction — the very first real action in any new account should be creating a genuinely restricted user and never using root again.

0/4 · 0%

Key ideas

01
Every new AWS account starts with exactly one identity: the ROOT USER, tied to the email address used to create the account — this identity has GENUINELY UNRESTRICTED access to everything in the account, with no possible permission boundary, exactly like Linux's own root superuser (that course's Phase 1.3) but for an entire cloud account rather than one machine.
02
The single most important first action in ANY new AWS account: enable MFA (Multi-Factor Authentication) on the root user IMMEDIATELY, then create a genuinely restricted IAM user (Phase 1 covers IAM in full depth) for actual day-to-day work, and STOP using the root user entirely except for the small handful of tasks that genuinely require it (like closing the account or changing the account's own billing settings).
03
This directly mirrors Linux's own course's exact same lesson about sudo versus logging in as root directly (that course's Phase 1.3) — using a restricted identity for everyday work dramatically shrinks the blast radius of any single mistake or compromised credential, while root's unrestricted access remains available, protected by MFA, for the rare cases that genuinely need it.
04
AWS's own FREE TIER offers a genuinely real, no-cost way to learn many services for a limited time or usage amount — but it's genuinely important to set up BILLING ALERTS immediately in a new account, since accidentally leaving a resource running past free-tier limits (or provisioning something never intended to be free at all) can produce a genuinely real, unexpected bill with no automatic warning otherwise.
05
AWS BUDGETS (configurable from day one) can send an automatic alert the moment actual or projected spending crosses a threshold YOU set — genuinely cheap, essential insurance for anyone learning AWS hands-on, where an accidentally-left-running resource is a real, common, and avoidable mistake.
06
The complete, correct first-hour checklist for any brand-new AWS account: enable MFA on root, create an IAM user with appropriate permissions for yourself (never using root for daily work again), set up a billing alert/budget, and only THEN start actually provisioning real resources to learn with.

Code & diagrams

first-account-checklist.shmarkdown

The complete, correct sequence for any brand-new AWS account — do this before anything else.

# 1. Enable MFA on the root user
#    (AWS Console: Account name (top right) -> Security credentials -> MFA)
#    Do this FIRST, before anything else, using an authenticator app or hardware key

# 2. Create an IAM user for yourself (Phase 1 covers IAM in depth) —
#    never use root for everyday work again after this point
aws iam create-user --user-name your-name
aws iam attach-user-policy --user-name your-name \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
# (a real production setup would scope this far more narrowly — Phase 1 covers exactly how)

# 3. Set up a billing alert BEFORE provisioning anything real
aws budgets create-budget --account-id YOUR_ACCOUNT_ID --budget '{
  "BudgetName": "monthly-safety-net",
  "BudgetLimit": { "Amount": "10", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}'

# 4. Confirm you're now using the IAM user, not root
aws sts get-caller-identity
# should show your IAM user's ARN, not the account's root user

Explain it without notes

Why is enabling MFA on the root user specifically the very first action recommended for any new AWS account, before anything else?

Why should you set up a billing alert before provisioning any real resources, rather than after?

Practice

If you have (or create) a genuinely new AWS account, walk through the complete first-hour checklist yourself: enable root MFA, create an IAM user, set up a billing budget alert.

Run aws sts get-caller-identity after switching to your new IAM user and confirm the returned ARN reflects your IAM user, not the account's root user.

Trade-offs

↔
Setting up MFA, a dedicated IAM user, and billing alerts takes a genuine few extra minutes before you can start actually experimenting with AWS — but skipping this setup to save those few minutes is exactly how a genuinely serious, avoidable mistake (a compromised root account, a surprising bill from an unmonitored resource) happens; this upfront cost is consistently one of the best time investments in this entire course.

Done when you can

I understand why the root user should never be used for everyday work after initial account setup.
I have (or would) enable MFA on root and create a restricted IAM user as the very first actions in a new account.
I understand why a billing alert should be configured before provisioning any real resources.