Module 03: The AWS Account & Root User

Learning Objectives

By the end of this module, you will be able to:

• Explain what an AWS account represents as both a security boundary and a billing boundary
• Identify the unique relationship between an email address, an account ID, and the account alias
• Describe the root user's exclusive capabilities and articulate why it must be secured immediately after account creation
• Differentiate between the three categories of AWS Free Tier offerings and identify the specific limits for key services
• Configure billing alerts and AWS Budgets to prevent unexpected charges
• Compare the five AWS Support plans and recommend the appropriate tier based on organizational requirements
• Execute the Day-1 security checklist for a newly created AWS account
• Explain how consolidated billing works within AWS Organizations at a conceptual level

Prerequisites

• Completion of Module 02: AWS Global Infrastructure
• An active AWS account with console access

Why This Matters

The AWS account is your security boundary. Not the VPC. Not the IAM policy. The account itself.

Every resource you create, every dollar you spend, every permission you grant exists within the scope of a single AWS account. If you misunderstand this boundary, nothing else you build is safe. A compromised root user means total loss of control. An unmonitored billing configuration means a $10 experiment can become a $10,000 invoice overnight.

As a Solutions Architect, one of the first questions you ask when inheriting any environment is: "Who has root access, and what controls are in place?" If the answer is vague, you have found your first critical risk. This module teaches the administrative foundation that every secure, well-governed AWS environment requires.

Concepts

What Is an AWS Account?

📊 Architecture Diagram: AWS account structure showing the root user, account ID, and the relationship between accounts and resources.

An AWS account is the fundamental unit of resource ownership, security isolation, and billing in AWS. It is not simply a login. It is a container that holds everything: your EC2 instances, your S3 buckets, your IAM users, your bill.

Security boundary: Resources in one account cannot access resources in another account unless you explicitly configure cross-account access. This isolation is enforced at the platform level. A security incident in Account A does not automatically compromise Account B.

Billing boundary: All charges within an account roll up to that account's payment method. One account, one bill (unless you use consolidated billing through AWS Organizations).

The Email-Account Relationship

Every AWS account is created with a single email address that serves as the root user login, receives billing and security notifications, cannot be shared across multiple accounts, and should be a distribution list (not a personal email) for organizational accounts.

⚠️Warning: If you lose access to the account email address, recovery becomes extremely difficult. Use a durable, organizational email for any account that matters.

Account ID and Alias

Every account receives a 12-digit account ID at creation (e.g., 123456789012). This number is permanent and globally unique. It appears in:

• Resource ARNs (Amazon Resource Names)
• Cross-account access policies
• The sign-in URL for IAM users: https://123456789012.signin.aws.amazon.com/console

Because 12-digit numbers are hard to remember, you can set an account alias, a friendly name that replaces the account ID in your IAM sign-in URL:

https://my-company-prod.signin.aws.amazon.com/console

Account aliases must be globally unique across all AWS accounts.

Accounts and Organizations (Preview)

In enterprise environments, a single AWS account is rarely sufficient. AWS Organizations allows you to group multiple accounts under a management account, apply organization-wide policies, and consolidate billing. This is covered in depth in Phase 8. For now, understand that individual accounts are the building blocks of larger organizational structures.

Check your understanding: A company has three teams, each running different workloads. Why might they choose three separate AWS accounts instead of one shared account with IAM permissions separating the teams?

The Root User

📊 Architecture Diagram: Root user security best practices including enabling MFA and avoiding daily use of root credentials.

The root user is the identity created when you first create an AWS account. It is authenticated by the account email and password set during creation. It has complete, unrestricted access to every resource and service in the account. No IAM policy can limit it. No permission boundary constrains it.

What Only the Root User Can Do

Most AWS tasks can be performed by IAM users with appropriate permissions. However, a small set of operations are exclusively reserved for the root user:

This is a deliberately short list. AWS designed it this way so you rarely need the root user.

Why You Must Lock It Down on Day 1

The root user cannot be restricted by IAM policies. If an attacker gains root credentials, they can delete every resource, create backdoor IAM users, change the account email to lock you out permanently, spin up expensive compute for crypto mining, and access all data, including encrypted content, if they rotate KMS keys. There is no recovery path that does not involve AWS Support intervention, time, and potential data loss.

Step-by-Step: Securing the Root User

Complete these actions immediately after creating any AWS account:

1. Enable MFA on the root user. Use a hardware security key (FIDO2) or virtual MFA app (not SMS). Navigate to IAM > Security Credentials > Assign MFA device. MFA documentation

2. Delete root access keys if they exist. Root should never have programmatic access. Navigate to IAM > Security Credentials > Access keys. Deactivate and delete any that exist. Access key documentation

3. Create an IAM admin user. Attach the AdministratorAccess managed policy. Log out of root. Log in as this admin. IAM admin setup

4. Store root credentials securely. Place the password in a hardware-encrypted vault or secrets manager requiring multi-person authorization to retrieve.

5. Never use root again for daily operations. Log in as root only for the specific tasks listed in the table above.

⚠️Warning: Using root for daily work is the single most dangerous practice in AWS account management. Every month, AWS sees accounts compromised because the root user had active access keys posted in a GitHub repository or stored in a shared spreadsheet.

Common Mistakes

• Using root to create resources because "it's easier than setting up IAM"
• Sharing root credentials via email or chat
• Skipping MFA because "it's just a test account" (attackers love unprotected accounts with billing enabled)
• Reusing a password from another service

AWS Free Tier

📊 Architecture Diagram: AWS account billing boundaries and how each account acts as an isolation container for resources.

The AWS Free Tier lets you use specific services at no charge within defined limits. Understanding these limits precisely prevents surprise bills.

Three Categories

Key Services and Limits

Monitoring Free Tier Usage

Navigate to Billing Dashboard > Free Tier to see your usage against each limit as a percentage. AWS also sends email alerts when you approach 85% of a Free Tier limit (if billing alerts are enabled).

To enable Free Tier usage alerts:

1. Navigate to Billing > Billing Preferences
2. Check "Receive Free Tier Usage Alerts"
3. Confirm the email address for notifications

✅Tip: Set up a billing alarm (covered in the next section) on Day 1, even if you plan to stay within Free Tier. Services like NAT Gateways, Elastic IPs not attached to running instances, and forgotten EBS volumes are not covered by Free Tier and accumulate charges silently.

Common Mistakes That Lead to Unexpected Charges

• Leaving a NAT Gateway running ($0.045/hour = ~$32/month regardless of traffic)
• Public IPv4 addresses ($0.005/hour per address = ~$3.60/month each, charged whether attached or not since February 2024)
• Launching a t2.small instead of t2.micro (no Free Tier coverage for the small)
• Running instances in multiple Regions (Free Tier limits are global, not per-Region)
• Not terminating lab resources after completing exercises

AWS Billing & Cost Management

📊 Architecture Diagram: Setting up account-level protections including alternate contacts, billing alerts, and account recovery options.

AWS billing operates on a pay-as-you-go model. Charges vary by service: per second, per hour, per request, or per gigabyte.

The Billing Dashboard

The Billing Dashboard provides:

• Month-to-date charges broken down by service
• Forecasted end-of-month charges based on current usage trends
• Free Tier usage tracking with percentage indicators
• Bills with line-item detail for every charge
• Payment methods and tax settings

AWS Budgets

AWS Budgets lets you set custom spending thresholds and receive alerts when actual or forecasted costs exceed your limits. You can create cost budgets (dollar thresholds), usage budgets (service consumption), and reservation budgets (RI usage).

Your first budget should be a simple cost budget: navigate to Billing > Budgets > Create budget, select "Cost budget," set a monthly amount ($10 for a learning account), add alert thresholds at 50%, 80%, and 100%, then configure email notifications.

✅Tip: AWS Budgets is free for the first two budgets. For a learning account, two budgets (one at $5, one at $20) provide adequate protection.

Cost Allocation Tags

Cost allocation tags are key-value pairs attached to resources that appear in billing reports. They answer: "Which project, team, or environment caused this charge?"

At enterprise scale, tags are non-negotiable. Without them, a $50,000/month bill is just a number. With them, you trace every dollar to the workload that generated it.

Consolidated Billing with Organizations

When multiple accounts are grouped under AWS Organizations, all charges roll up to the management account's payment method. This provides a single bill, volume discounts across combined usage (e.g., S3 tiered pricing), and simplified financial management. Expanded in Phase 8.

AWS Support Plans

AWS offers five support tiers with escalating response times, access channels, and advisory services.

Decision Framework

Check your understanding: A financial services company runs their trading platform on AWS. Their system generates $2 million in revenue per hour. Which Support plan should they choose, and why does the cost of the plan become irrelevant compared to the cost of downtime?

Account Best Practices (The Day-1 Checklist)

When you create a new AWS account, complete these steps before doing anything else. Treat this as a security prerequisite, not optional housekeeping.

Enabling CloudTrail

AWS CloudTrail records every API call made in your account: who made the call, from what IP, at what time, and what happened. Without CloudTrail, you have no forensic capability if something goes wrong. It provides 90 days of event history for free. For long-term retention, create a trail that delivers logs to S3. Enable it in all Regions so that activity in any Region is captured.

Setting the IAM Password Policy

Navigate to IAM > Account settings > Password policy. Configure minimum 14-character length and require mixed case plus numbers and symbols. Note: NIST SP 800-63B recommends against mandatory periodic password rotation unless there is evidence of compromise, as forced rotation often leads to weaker passwords. If your organization's compliance framework requires rotation, set it to 90 days and prevent reuse of the last 24 passwords. Otherwise, enforce strong passwords with MFA rather than relying on expiration.

✅Tip: These six required steps take approximately 15 minutes to complete. Those 15 minutes are the difference between a hardened account and one that is trivially compromisable. The lab for this module walks you through each step hands-on.

Instructor Notes

Estimated lecture time: 60 minutes

Common student questions:

• Q: Can I have multiple root users on one account? A: No. Each account has exactly one root user, tied to the account's email address. For shared administration, create IAM users or roles with appropriate permissions.

• Q: What happens if I exceed Free Tier limits? A: You are charged standard on-demand rates for usage beyond Free Tier limits. There is no automatic cutoff. This is why billing alarms are essential from Day 1.

• Q: Is the Developer support plan worth $29/month for a learner? A: For most learners, Basic (free) is sufficient. Developer is worthwhile if you want to ask AWS technical questions or have a small production workload.

• Q: Can I change my account email address later? A: Yes, but it requires root login and MFA verification. Plan your email address choice carefully during account creation.

Teaching tips:

• Open the Billing Dashboard live. Students retain billing concepts better when they see real interface elements rather than screenshots.
• Show Trusted Advisor checks on Basic vs. Business plans side by side. The visual difference makes the value proposition concrete.
• Use the physical-key analogy for root: master key to a building. Lock it in a safe, use floor-specific keys daily.
• Connect CloudTrail to a security narrative: "If someone deletes your production database at 3 AM, CloudTrail tells you who, when, from where, and how."

Pause points:

• After root user: ask students to list three consequences of a compromised root user that could not happen with a compromised IAM admin.
• After Free Tier: scenario with three t2.micro instances. Do they exceed Free Tier? (Yes: 3 x 750 = 2,250 hours exceeds the 750/month global limit.)
• After Support plans: present two fictional companies and ask students to recommend a plan with justification.

Key Takeaways

• An AWS account is simultaneously a security boundary and a billing boundary. Treat it as the outermost perimeter of your environment.
• The root user has unrestricted access and cannot be limited by IAM. Secure it with MFA on Day 1, delete access keys, and never use it for daily operations.
• AWS Free Tier has three categories (Always Free, 12 Months Free, Trials). Know the limits for services you use and set billing alarms to catch overages early.
• AWS Budgets and billing alarms are your financial guardrails. A $5 alarm costs nothing to set up and can save you hundreds in unexpected charges.
• Support plan selection is a risk decision. Match the plan to your organization's tolerance for downtime and need for technical guidance.
• The Day-1 checklist (MFA, IAM admin, billing alarm, CloudTrail, password policy) takes 15 minutes and establishes the security foundation for everything you build afterward.