This is the written version of the hands-on half of Episode 01 of AWS for Python Developers. By the end you’ll have a fresh AWS account configured the way a professional would run it: root user retired, an IAM admin user as your daily identity, MFA on both, and billing guardrails that email you before money becomes a problem.
Time: ~25 minutes · Cost: ₹0 (a ~₹2/$1 temporary card verification hold, refunded automatically)
You’ll need: an email address, a credit or debit card, a phone number for OTP, and an authenticator app on your phone (Google Authenticator, Authy, or similar).
Why this matters before you write any code
The email and password you sign up with become the root user. Root has unrestricted power over the account — it can change billing, close the account, and delete every resource — and no IAM policy can restrict it. Using it as your daily login means every session carries the maximum possible blast radius.
The fix is the same pattern every company uses: root is a break-glass identity you touch only for rare account-level tasks, and an IAM user with AdministratorAccess is your everyday driver — just as capable for building, but revocable, auditable, and deletable in seconds if it’s ever compromised.
Note for teams: AWS’s current recommendation for organizations and multi-account setups is IAM Identity Center. For a personal learning account, a single IAM admin user is the standard, pragmatic choice — and it’s what this series assumes. We’ll cover Identity Center later.
Step 1 — Create the account
- Go to aws.amazon.com → Create an AWS Account.
- Enter your email and choose an account name (e.g.
yourname-learning). Verify the email OTP. - Set the root user password. Make it long, unique, and stored in a password manager — you’ll rarely type it again after today.
- Choose Personal account type and fill in your details.
- Add your card. AWS places a small temporary hold (~₹2 in India, ~$1 elsewhere) to verify it — this is not a charge and reverses automatically.
- Verify your phone via OTP, then choose the Basic support plan (free).
Sign in to the console as root one time — the next three steps are the only real work root will ever do.
Step 2 — Enable MFA on the root user
- In the console search bar, open IAM. The dashboard will warn that root has no MFA — click Add MFA.
- Choose Authenticator app, scan the QR code with your phone, and enter two consecutive codes.
- Done. A leaked root password alone can no longer open your account.
While you’re here, note the Account ID (12 digits, top-right menu). You’ll use it to sign in as your IAM user.
Step 3 — Create your IAM admin user
- IAM → Users → Create user.
- Username: something you’ll actually type, e.g.
kunal-admin. - Tick Provide user access to the AWS Management Console, choose I want to create an IAM user, and set a custom password. Untick “user must create a new password at next sign-in” — this is you.
- On the permissions screen, choose Attach policies directly and attach
AdministratorAccess. - Create the user.
Yes, AdministratorAccess is broad. The point of this step isn’t least privilege — that’s Episode 02’s subject — it’s separating daily identity from account ownership. An admin IAM user can be constrained, monitored, and destroyed. Root can’t.
Step 4 — MFA on the admin user, then retire root
- Open the new user → Security credentials → Assign MFA device → authenticator app, same dance as root. (Most authenticator apps happily hold both entries.)
- Sign out of root.
- Sign back in choosing IAM user, entering your 12-digit Account ID, username, and password.
Optional quality-of-life: on the IAM dashboard, create an account alias (e.g. kunal-learning) so your sign-in URL becomes kunal-learning.signin.aws.amazon.com/console instead of a number.
From this moment, root only comes out for the short list of tasks that genuinely require it (changing the support plan, closing the account, certain billing/tax settings). Everything in this series happens as your IAM user.
Step 5 — Billing guardrails
Every AWS horror story — the $2,000 weekend bill — happens because nothing was watching. Three guardrails, five minutes.
5a. Free-tier alerts
- Billing and Cost Management → Billing preferences.
- Turn on AWS Free Tier alerts and PDF invoices by email.
5b. A zero-spend budget
- Billing and Cost Management → Budgets → Create budget.
- Use the template Zero spend budget, add your email, create.
This emails you the moment anything costs a single cent — the earliest possible tripwire while you’re inside the free tier.
5c. A monthly cost budget
- Create a second budget with the Monthly cost budget template.
- Set an amount you’d be comfortable losing to a mistake — $5–10 is plenty for this series.
- Keep the default alerts (actual and forecasted thresholds), add your email.
The zero-spend budget tells you when spending starts; the monthly budget tells you when it’s trending wrong.
5d. One habit
Every weekend, open Cost Explorer for two minutes and delete anything you’re not using. At learning scale, SQS, SNS, Lambda, and DynamoDB on-demand cost effectively nothing — the usual suspects for silent spend are running EC2 instances and NAT gateways.
Checkpoint
You now have:
- Root user: MFA-protected and retired from daily use
- IAM admin user: your daily driver, MFA on, sign-in via account alias
- Free-tier alerts + zero-spend budget + monthly budget: no surprise bills
That’s a more professional baseline than plenty of production accounts I’ve seen.
What’s next
In Episode 02 — IAM for Developers, we go deeper into the permission model behind what you just did: users vs roles vs policies, how least privilege actually works, setting up the AWS CLI with a named profile, and making your first boto3 call from Python against your own account.
If you hit anything unexpected during setup, ping me — every step above is exactly what I run on my own practice account.