AWS account structure and the Free Tier — organizing a real account safely

When you first create an AWS account, you sign in as the root user — an identity with unrestricted access to literally everything in the account, including billing, and with no way to meaningfully restrict what it can do. AWS's own guidance is direct about this: use the root user only for the small number of tasks that genuinely require it (closing the account, changing the support plan, a handful of billing settings), and for everything else — including your own daily work — create an IAM user (or better, use IAM Identity Center / federated access) with only the permissions actually needed.

The practical first steps after creating an account: enable MFA on the root user immediately, create an IAM user (or admin role) for yourself with MFA, and then stop signing in as root for anything routine. A root user with no MFA and a weak password is, in a very literal sense, the single point of failure for an entire AWS account — full control over every resource, every dollar of spend, and the ability to delete anything.

The Free Tier isn't a single flat allowance — it comes in three distinct shapes, and confusing them is the single most common source of an unexpected first bill:

The recurring surprise: someone spins up a "free" EC2 instance in month 2, forgets about it, and it's still running in month 14 — quietly billing at full price for two months before anyone notices, because nothing in the console loudly announces "your free allowance for this specific resource just ended."

AWS Budgets lets you set a spending threshold and get notified (email, SNS) when actual or forecasted spend crosses it — and setting this up is one of the first things worth doing in a new account, not something to configure after a surprising bill arrives.

A $10/month budget alert on a learning/side-project account costs nothing to set up and catches exactly the "forgot to shut down an instance" scenario before it becomes a real number.

A few specific, non-obvious cost sources worth knowing about before they surprise you:

A single AWS account is the right starting point for learning and small projects — everything in this domain's early lessons assumes one account. Once real production workloads and multiple environments (dev/staging/prod) enter the picture, splitting into multiple accounts under AWS Organizations becomes the standard pattern, covered later in this domain once the individual services (IAM, VPC, and the rest) are familiar enough for that structural conversation to make sense.