Lesson 002 · AWS Learning Path

AWS 002: Personal AWS account ownership and learner responsibility

Anil Jalela · Published Jun 27, 2025 · 8 min read

The situation

You will use a personal AWS account. You control its root email, payment method, security settings, resources, and charges. The instructor cannot recover your account, reverse a bill, protect a credential that you publish, or clean up a resource that you leave running.

That ownership is useful because you learn on a real control plane. It also creates responsibilities that must be understood before the first resource lab.

What you will be able to do

By the end of this lesson, you can:

1. distinguish the AWS account root user from everyday administrative access;
2. protect the root user and its recovery channels;
3. verify primary and alternate contacts;
4. identify your account plan and credit status without assuming that "Free Tier" means every service is free;
5. create a redacted account-safety record;
6. explain what you must do if a credential or account is compromised.

Understand the ownership boundary

When an AWS account is created, AWS creates an account root user. It is identified by the account email address and has complete access to the account. Some root-user powers cannot be reduced with an ordinary IAM policy.

Use the root user only for tasks that require it. Do not use it for routine labs, administration, Console browsing, CLI work, SDKs, or applications.

Root user
  Purpose: account ownership and rare root-only tasks
  Protection: strong password, multiple MFA devices, protected recovery channels
  Programmatic keys: do not create
  Daily use: no

Everyday learner identity
  Purpose: normal Console and lab work
  Protection: MFA and temporary credentials where supported
  Permissions: enough for the lesson, reduced as the course progresses
  Daily use: yes

Workload role
  Purpose: permissions for EC2, Lambda, containers, and other workloads
  Credentials: temporary and automatically delivered
  Human sign-in: no

You will build the everyday identity deliberately in the identity foundation. Do not create random IAM users or access keys now.

Before you sign in

Prepare these items:

• access to the root email inbox;
• access to the primary account phone number;
• one primary MFA device and, preferably, a second independent MFA device;
• a password manager;
• a non-public location for your recovery notes;
• the payment method associated with the account.

Do not place the root password, MFA seed, recovery codes, or payment information in the course evidence directory.

Practical account-safety procedure

AWS Console labels can change. If a label is slightly different, search the Console for the named service and confirm that the page is on an aws.amazon.com domain.

Step 1: sign in as the root user for this setup only

1. Open the AWS sign-in page.
2. Choose Root user.
3. Enter the email address used to create the account.
4. Complete password and MFA authentication.
5. Confirm that you are in the intended account before changing anything.

Do not remain signed in as root after this procedure.

Step 2: verify root-user MFA

1. In the Console, choose the account menu in the upper-right corner.
2. Choose Security credentials.
3. Find Multi-factor authentication (MFA).
4. Confirm that at least one MFA device is assigned.
5. If none is assigned, choose Assign MFA device and follow the current AWS procedure.
6. Where possible, register a second MFA device stored independently from the first.

AWS recommends phishing-resistant MFA such as a passkey or security key where practical. AWS currently supports registering multiple MFA devices for the root user. Follow the current limit shown in the official MFA documentation rather than memorizing a static number.

Evidence: record only the MFA device type and the Console statement that MFA is assigned. Never capture a QR code, seed, one-time code, or device serial number that should remain private.

Step 3: confirm that root access keys do not exist

On the same Security credentials page:

1. Find Access keys.
2. Confirm that the root user has no active access key.
3. Do not choose Create access key.

If a root access key exists:

1. identify whether anything still depends on it;
2. replace that dependency with an IAM role or another temporary-credential method;
3. deactivate the key;
4. verify that the dependency still works;
5. delete the root access key.

Do not delete an in-use key blindly. Record the issue and remediate it safely.

Step 4: verify primary contact details

1. Open the account menu.
2. Choose Account.
3. Review the primary contact email, phone number, and mailing address.
4. Correct outdated information.

The root email and phone are recovery channels. Protect them as carefully as the AWS password. An attacker who controls a recovery channel may be able to interfere with account recovery.

Step 5: configure alternate contacts

On the Account page, find Alternate contacts and review:

• Billing contact;
• Operations contact;
• Security contact.

For a personal account, these may point to addresses you control. If you use different addresses, ensure that you actually monitor them. Do not invent an address merely to fill the field.

Expected result: all required contact channels are current and reachable.

Step 6: identify your Free Tier or account-plan state

1. Search the Console for Billing and Cost Management.
2. Open Billing and Cost Management home.
3. Find the account-plan, credits, or Free Tier section shown for your account.
4. Record:

• account creation period;
• Free plan, Paid plan, or legacy Free Tier status;
• remaining credits, if displayed;
• credit expiration date, if displayed.

Do not record full payment information or an unredacted account ID.

Important:

• Accounts created on or after July 15, 2025 can use the newer Free plan or Paid plan structure.
• Older accounts can remain under legacy Free Tier rules.
• Credits, free usage limits, and account plans do not make every service free.
• A Paid plan can incur charges beyond eligible credits and free usage.
• A Free plan restricts some services and ends according to the current plan conditions.

Always inspect your own Billing page and current AWS terms.

Step 7: sign out of root

1. Open the account menu.
2. Choose Sign out.
3. Close the browser tab.
4. Do not use the root session for later course labs.

Create the redacted safety record

Use your Linux terminal:

mkdir -p "$HOME/nitwings-aws/evidence/aws-002"

Then create the checklist:

printf '%s\n' \
  'Root MFA assigned: YES/NO' \
  'Second MFA available: YES/NO' \
  'Root access keys present: NO/REMEDIATION REQUIRED' \
  'Primary contact verified: YES/NO' \
  'Billing contact verified: YES/NO' \
  'Operations contact verified: YES/NO' \
  'Security contact verified: YES/NO' \
  'Account plan identified: YES/NO' \
  'Root session closed: YES/NO' \
  > "$HOME/nitwings-aws/evidence/aws-002/account-safety.txt"

Open the file in a text editor and replace each YES/NO value with the true result. Do not claim YES without verification.

Display the result:

sed -n '1,20p' "$HOME/nitwings-aws/evidence/aws-002/account-safety.txt"

Your responsibility during every lab

Before creating a resource:

• confirm the account and Region;
• read the cost tier;
• check current pricing;
• understand the cleanup sequence;
• use the course naming and tags;
• set a timer for short-lived resources.

During the lab:

• do not widen permissions or firewall rules as a random fix;
• do not publish credentials or sensitive identifiers;
• record expected and actual behavior;
• stop if the observed cost model differs from the lesson.

After the lab:

• clean up in dependency order;
• verify that the resource is actually deleted, not merely stopped;
• check every Region used by the lesson;
• record intentionally retained resources and their cost;
• review Billing data when it becomes available.

What to do after a suspected compromise

Warning signs include an unfamiliar sign-in, unexpected resource, unknown access key, changed contact, security email, or unexplained charge.

Use this order:

1. preserve the notification and event details;
2. regain and protect account access;
3. contact AWS Support through official channels;
4. identify affected credentials and resources;
5. rotate or revoke exposed credentials;
6. isolate malicious resources without destroying needed evidence;
7. review activity and charges;
8. document what happened and how recurrence will be prevented.

Do not follow phone numbers or links from suspicious email. Navigate to AWS Support from the official AWS site.

Common mistakes

Knowledge check

1. Why is the root user different from an administrator role?
2. Should you create root access keys for this course?
3. Why must the root email account also have strong security?
4. What should you verify before relying on a Free Tier statement?
5. Who is responsible for cleaning up a resource in your personal account?

Expected answers

1. The root user is the account owner with powers that ordinary IAM permissions cannot fully constrain. An administrator role is an IAM identity used for delegated work.
2. No.
3. The email is part of account recovery and receives security communication.
4. Your account creation date, current plan, remaining credits, expiration, service eligibility, Region, quantity, duration, and current pricing.
5. You are.

Completion gate

You pass AWS 002 when:

• root MFA is assigned;
• no root access key exists, or a documented remediation is in progress;
• primary and alternate contacts are current;
• you have identified your account-plan and credit state;
• you signed out of root;
• account-safety.txt contains truthful, redacted evidence.

No AWS service resource was created, so no resource cleanup is required.

Official sources

• Root user best practices
• AWS sign-in security best practices
• AWS MFA recommendations
• Update alternate contacts
• AWS Free Tier plans
• AWS Free Tier documentation