Free lesson · AWS Fundamentals

Setting up a learning account safely

Easy6 min read

Why This Topic Exists

You cannot learn AWS by reading about it. At some point you need an account, and the account is a live billing relationship with a company that will charge you for what you leave running.

The stories about surprise bills are real, and they almost always come from the same small set of causes. Fifteen minutes of setup eliminates nearly all of them. Do this before you launch anything.

The Setup Checklist

graph TD
    A[Create account] --> B[Secure the root user]
    B --> C[Create a daily working identity]
    C --> D[Set a budget with alerts]
    D --> E[Enable cost visibility]
    E --> F[Pick and stick to one Region]
    F --> G[Learn the teardown habit]
    G --> H[Safe to experiment]

This diagram shows a seven-step setup sequence for a new AWS learning account. First create the account, then secure the root user, then create a daily working identity, then set a budget with alerts, then enable cost visibility, then pick and stick to one Region, then learn the teardown habit. Only after all seven steps is the account safe to experiment in.

Step 1 - Secure The Root User

Every account has a root user tied to the email address you signed up with. It can do anything, including things IAM policies cannot restrict. Compromising it means losing the account.

Set a strong, unique password stored in a password manager
Enable MFA immediately. A hardware key or authenticator app.
Create no access keys for root. If any exist, delete them.
Use an email address you control long-term and monitor

Then stop using it. After the initial setup you should sign in as root perhaps once or twice a year, for the handful of operations that genuinely require it - closing the account, changing the payment method, changing the account name.

Important: Root access keys are the single most dangerous credential in AWS. They cannot be scoped, cannot be restricted by any policy, and are frequently what turns a leaked repository into a five-figure cryptocurrency mining bill. There is no legitimate reason for them to exist.

Interactive animation: Secure the root user - MFA on and no access keys, then stop using it for daily work.

Step 2 - Create A Daily Working Identity

Do not do daily work as root.

For a personal learning account, create an IAM user with administrator permissions, MFA enabled, and a password. Use that.

For anything shared or professional, set up IAM Identity Center and federate. This is what real organisations do, and it is worth learning early - Module 02 covers it properly.

For programmatic access, prefer short-lived credentials over long-lived access keys wherever possible. If you must create an access key for CLI use, treat it like a password: never in a repository, never in a shared document, rotated when you are done.

Warning: Access keys committed to public repositories are found by automated scanners within minutes, not days. AWS runs its own scanners and will quarantine an exposed key, but not always before it has been used. Add a pre-commit secret scanner before your first commit, not after your first incident.

Step 3 - Set A Budget With Alerts

This is the step that protects you.

Create an AWS Budget with a monthly amount you would be uncomfortable exceeding. For a learning account, something in the range of a small monthly figure is usually right.
Set alert thresholds at multiple points - for example at 50%, 80%, and 100% of budget, plus a forecast alert.
Send alerts to an email address you actually read.

Important: A Budget alerts. It does not stop spending. Nothing in a standard AWS account automatically halts charges at a threshold. If you want an actual hard stop, you have to build it - a budget action that attaches a restrictive policy, or an automation that terminates resources. For a learning account, the alert plus the teardown habit below is usually enough. Just do not believe the budget will save you if you ignore the email.

Step 4 - Understand The Free Tier Properly

Three kinds, and confusing them is expensive:

Kind	Behaviour
12-month free tier	Expires 12 months after account creation. Includes the well-known EC2 and S3 allowances.
Always free	Does not expire. Lambda requests, DynamoDB storage, CloudWatch basics, and others.
Trials	Short, service-specific, usually starting on first use of that service.

Two things people get wrong:

The free tier is a discount, not a cap. Exceeding it produces a real charge silently. There is no warning at the boundary.

Many of the most useful services are not in it at typical usage. NAT Gateways, load balancers, provisioned RDS instances, Elastic IPs that are not attached to a running instance, and idle EKS control planes all charge from the first hour. These are also exactly the things a tutorial tells you to create and rarely tells you to delete.

Step 5 - Pick One Region And Stay There

Resources are Region-scoped and the console shows you one Region at a time. Creating something in eu-west-1 while your console sits in us-east-1 is how forgotten resources are born, and forgotten resources are how bills happen.

Pick one Region - usually the one closest to you, or us-east-1 if you want maximum service availability - and do everything there while learning. When you deliberately need a second Region for a multi-Region exercise, note it down.

Tip: Two exceptions worth knowing now. Billing and Cost Explorer are global but presented through us-east-1. ACM certificates for CloudFront must be requested in us-east-1 regardless of where the rest of your stack lives. Both catch people, and neither is a mistake in your setup.

Step 6 - The Teardown Habit

The single most valuable operational habit for a learning account: destroy what you build, the same day you build it.

Prefer infrastructure as code - a CloudFormation stack or a Terraform configuration - so teardown is one command instead of hunting through consoles. Module 09 covers this.
If you used the console, write down what you created before you walk away.
End each session with a sweep: running instances, load balancers, NAT Gateways, RDS instances, EKS clusters, unattached Elastic IPs, unattached EBS volumes.
Check the bill weekly for the first month. It builds intuition about what things actually cost, which is worth the exercise on its own.

Warning: The resources that most commonly survive a cleanup and quietly accrue charges: NAT Gateways, Application and Network Load Balancers, unattached Elastic IPs, provisioned RDS and Aurora instances, EKS control planes, unattached EBS volumes, old EBS and RDS snapshots, and NAT-adjacent data processing. Almost none of them appear in the EC2 instance list, which is the only place most people think to look.

Optional But Recommended

Enable Cost Explorer on day one. It takes up to 24 hours to populate, so turning it on before you need it matters.

Enable CloudTrail. A single-Region trail is inexpensive and gives you a record of every API call. When something behaves unexpectedly, this is where the answer is.

Turn on IAM Access Analyzer. Free, and it tells you when something you created is reachable from outside your account.

Consider a separate account per major experiment if you are working through several tracks. Account-level isolation makes teardown trivial - close the account. This is also good practice for the multi-account model in Module 01 Topic 7.

Practice

Exercise: Starter. Complete steps 1 through 5. Verify by confirming: MFA is on for root, no root access keys exist, you have a working non-root identity, and a budget alert email has arrived at the test threshold.

Intermediate. Create a small resource through the console, find the corresponding charge in Cost Explorer 24 hours later, then delete it and confirm the charge stops.

Advanced. Build the same small stack twice - once through the console, once as a CloudFormation template or Terraform configuration. Time the teardown for each. The difference is the argument for infrastructure as code, and you should experience it rather than be told it.