What Is an AWS Account? Root User, Billing, and Multi-Account Basics
An AWS account is the fundamental boundary for everything you do in AWS. It is the container that owns your resources, the entity that receives your bill, and the security perimeter that isolates your workloads from everyone else’s. Every EC2 instance, S3 bucket, and Lambda function you create belongs to exactly one account.
If you are new to AWS, understanding accounts is the first step to using the platform safely. This guide explains what an account is, how it works, when you need more than one, and how to set yours up without falling into common traps.
Simple explanation
An AWS account is like a rental agreement for a workshop. The workshop comes with its own address (account ID), its own master key (root user), and its own electricity bill. You bring in tools, build things, and the landlord (AWS) charges you based on what you use. Nothing inside your workshop is visible to anyone else’s workshop unless you explicitly unlock a door between them.
That is really all an account is: a walled-off space where your AWS resources live, with one bill attached to it.
Why AWS accounts matter
Accounts are not just an administrative detail. They are the strongest isolation boundary AWS offers. Resources in one account cannot see, access, or interfere with resources in another account unless you explicitly allow it. This makes accounts the natural way to separate:
- Security boundaries. A compromised development environment cannot touch production.
- Billing ownership. Each account gets its own cost breakdown, so you know exactly what each project or team spends.
- Blast radius. A misconfigured IAM policy or a runaway script affects only the account it runs in.
Mixing production and development in a single account is a common beginner shortcut. It works fine while you are learning, but creates real security and billing problems at scale. Getting this right early avoids painful migrations later.
How an AWS account works
Account ID
Every account gets a unique 12-digit number, like 123456789012. This ID
appears in resource ARNs, cross-account policies, and CLI output. It identifies your
account in every API call.
Resource ownership
Every resource you create (a virtual machine, a storage bucket, a database) belongs to the account that created it. Resources cannot be “moved” between accounts. If you need a resource in a different account, you recreate it there.
Billing boundary
All charges for resources in an account go to that account’s payment method by default. If you use AWS Organizations, you can consolidate billing so one management account pays for everything while still tracking costs per member account. For details on how charges accumulate, see How Billing Works in AWS.
IAM namespace
Each account has its own isolated set of
IAM users, roles, and policies.
A role named deploy-bot in Account A is completely separate from a role
with the same name in Account B. There is no global IAM directory across accounts.
Isolation between accounts
By default, Account A cannot read, write, or even discover resources in Account B. Cross-account access requires explicit trust: Account B creates an IAM role that says “Account A is allowed to assume this role.” The caller in Account A assumes that role and gets temporary credentials scoped to Account B. This is deliberate and auditable.
Think of account isolation like separate apartments in a building. Each tenant has their own lock and their own utility meter. Your neighbour cannot walk into your apartment, use your electricity, or see your belongings. If you want to let them in, you give them a temporary guest key that expires. That guest key is what cross-account IAM roles do.
What an AWS account contains
When you create an AWS account, you get:
- A unique 12-digit account ID
- A root user tied to the email address you signed up with
- An isolated default VPC in every region, ready for launching resources
- A billing relationship where all charges go to the payment method on file
- A fresh IAM namespace where users, roles, and policies exist only in this account
- A CloudTrail event history that logs the last 90 days of API activity for free
The default VPC is convenient for quick experiments, but production workloads should use a custom VPC with intentionally designed subnets, route tables, and security groups.
AWS account vs IAM user vs IAM role vs AWS Organizations
These four concepts get confused often. Here is how they relate:
| Concept | What it is | Scope | When you use it |
|---|---|---|---|
| AWS account | Billing and isolation boundary | Contains all resources, users, and roles | Always. You need at least one. |
| IAM user | A permanent identity inside an account | Exists in one account only | Legacy human access or service accounts (prefer Identity Center or roles instead) |
| IAM role | A set of permissions that anyone (or any service) can assume temporarily | Defined in one account, assumable from others | Services, cross-account access, and human access via federation |
| AWS Organizations | A management layer above accounts | Groups multiple accounts under one management account | When you have two or more accounts and want central billing and policy control |
An account is the container. IAM users and roles are identities inside the container. Organizations is the layer that groups containers together.
The root user
The root user is the identity tied to the email address that created the account. It has complete, unrestricted access to everything in the account. IAM policies cannot limit it.
The root user is like a master key that opens every door, overrides every lock, and cannot be restricted. If someone gets hold of it, they control your entire account. Treat root credentials the way you would treat the key to a safe deposit box: locked away, protected with MFA, and used only when nothing else will work.
AWS strongly recommends:
- Enable MFA on the root user immediately after account creation
- Do not create access keys for the root user
- Use the root user only for the small set of tasks that require it
- Store the root credentials in a secure location (password manager or vault)
Tasks that require root access: changing the account email, closing the account, restoring IAM access after a lockout, changing the support plan, and enabling certain S3 settings on older buckets. For everything else, use IAM Identity Center or an IAM role.
When to use one account vs multiple accounts
Solo learner or sandbox
One account is enough. You are experimenting, and everything is disposable. Set a billing budget so you catch forgotten resources before they cost real money.
Small team with a real project
Use at least two accounts: one for development and one for production. This prevents a bad deployment or an overly broad IAM policy in dev from affecting live users. AWS Organizations ties them together with consolidated billing.
Production workloads at scale
Follow the multi-account strategy that AWS Organizations enables. Create separate accounts for each environment (dev, staging, prod), shared services (logging, networking), and security tooling. Service Control Policies enforce guardrails across all accounts from a single management account.
A single AWS account is like one big room where everyone works together. It is fine when you are alone or in a small group. But as the team grows, you want separate rooms so that a paint spill in the art studio does not ruin the server rack next door. Multiple accounts give you those walls.
You do not need to plan for a dozen accounts on day one. Start with one account, split into two when you deploy something real, and grow from there. The important thing is to keep production isolated before it matters.
First steps after creating an AWS account
Enable MFA on the root user. Go to the IAM console, select the root user, and add a virtual MFA device. This single step blocks most account-takeover attacks.
Set a billing budget. Open the Billing console and create a budget with an email alert. Even a $5 threshold catches forgotten resources early. See Budgets and Billing Alerts for a walkthrough.
Set up IAM Identity Center. This is the modern way to create human access. It gives you a sign-in portal, temporary credentials, and role-based access without creating long-lived IAM users or access keys.
Enable CloudTrail. The free 90-day event history is on by default, but creating a trail that writes to S3 gives you a permanent, searchable audit log of every API call in the account.
Review default VPC security groups. The default security group allows all outbound traffic and all inbound traffic from resources in the same group. Understand what is open before you launch anything.
These five steps take less than 30 minutes. Completing them before you launch any resources prevents the most common security and billing surprises.
How to access AWS safely as a beginner
Older guides tell you to create an IAM user for yourself and generate long-lived access keys. That advice is outdated. Long-lived keys are static credentials that never expire on their own. If they leak (in a Git commit, a screenshot, or from a compromised laptop) an attacker has persistent access to your account until you manually revoke them. See Why Long-Lived Access Keys Are Dangerous for real-world examples.
The current best practice:
Console access: sign in through IAM Identity Center. It gives you a portal URL, you authenticate once, and you pick the account and role you want. No password-per-IAM-user needed.
CLI access: use
aws configure ssoto set up the AWS CLI with IAM Identity Center. When you run commands, the CLI retrieves temporary credentials that expire automatically. No access keys stored in~/.aws/credentials.Programmatic access for services: assign IAM roles with temporary credentials instead of embedding keys in code or environment variables.
# Set up CLI access through IAM Identity Center (one-time setup)
aws configure sso
# After setup, log in and get temporary credentials
aws sso login --profile my-profile
# Verify your identity (the output shows your assumed role, not root)
aws sts get-caller-identity
# {
# "UserId": "AROAXXXXXXXXX:your-name",
# "Account": "123456789012",
# "Arn": "arn:aws:sts::123456789012:assumed-role/AdminAccess/your-name"
# }If you are in a learning environment where IAM Identity Center is not available (for example, a single personal account without Organizations), create an IAM role with the permissions you need and assume it. This still gives you temporary credentials.
Account IDs and ARNs
Your 12-digit account ID shows up constantly in AWS:
ARNs (Amazon Resource Names) are the unique identifier for every resource. Example:
arn:aws:iam::123456789012:role/deploy-botCross-account policies reference the target account by its 12-digit ID when granting access.
Console URL includes your account ID or alias in the IAM sign-in link.
The account ID is not a secret, but treat it as semi-private. Knowing someone’s account ID does not grant access, but it is one data point an attacker can use in targeted phishing or social engineering. Avoid posting it publicly without reason.
# Get your current account ID and identity
aws sts get-caller-identity
# Output:
# {
# "UserId": "AROAXXXXXXXXX:session-name",
# "Account": "123456789012",
# "Arn": "arn:aws:sts::123456789012:assumed-role/MyRole/session-name"
# }Common mistakes
Using the root user for daily work. The root user should touch the console only for the handful of tasks that require it. Set up IAM Identity Center or an IAM role and use that for everything else.
Creating long-lived access keys. Static credentials are the most common source of AWS account compromises. Use temporary credentials through IAM Identity Center, role assumption, or STS instead.
Skipping the billing alert. AWS charges accumulate silently. Without a budget alert, you will not know about unexpected costs until the invoice arrives. A $5 budget takes two minutes to create and catches forgotten resources.
Using a personal email for the root account. If you leave a company or lose access to that email, recovering the account is difficult. Use a team inbox or a dedicated email alias from the start.
Mixing dev and production in one account. A misconfigured policy or a runaway script in development can take down production. Separate accounts give you hard isolation with no extra cost.
Next steps
Now that you understand what an account is and how to secure it, these guides cover the concepts you will work with next:
IAM in AWS covers how permissions work inside your account and why IAM is the foundation of AWS security.
AWS Resource Hierarchy explains how accounts, Organizations, OUs, and resources fit into a structured hierarchy.
IAM Users vs Roles breaks down when to use each and why roles with temporary credentials are the modern default.
How Billing Works in AWS walks through pay-as-you-go pricing, Free Tier limits, and how to read your bill.
Frequently asked questions
What is an AWS account ID?
An AWS account ID is a unique 12-digit number (like 123456789012) that identifies your account. It appears in resource ARNs, cross-account IAM policies, and some CLI commands. The account ID is not secret, but you should not share it publicly because it can be used in targeted attacks against your account.
Is the root user the same as an IAM user?
No. The root user is the identity tied to the email address that created the AWS account. It has full, unrestricted access that cannot be limited by IAM policies. An IAM user is a separate identity created inside the account with only the permissions you explicitly grant. AWS recommends using IAM Identity Center or IAM roles for daily work and reserving the root user for the handful of tasks that require it.
Do I need multiple AWS accounts?
Not immediately. A single account is fine for learning and personal projects. Once you run production workloads, separating environments into different accounts gives you hard isolation for security, billing, and blast-radius control. AWS Organizations makes managing multiple accounts straightforward.
Can one AWS account access resources in another?
Yes, through cross-account IAM roles. Account A creates an IAM role that trusts Account B. Users or services in Account B assume that role to get temporary credentials scoped to Account A. This is safer than sharing long-lived access keys because the credentials expire automatically.
How should beginners access AWS safely?
Enable MFA on the root user immediately and stop using it for daily work. Set up IAM Identity Center (the modern replacement for creating IAM users) and sign in through that. If you need CLI access, use temporary credentials through IAM Identity Center or role assumption instead of creating long-lived access keys.