Chapter 61: AWS User Access

AWS User Access (officially: Identity & Access Management — or simply IAM + related identity services)

This is not just “creating a login”. This is the foundation of security, compliance, cost control, team collaboration, and auditability in your entire AWS account.

If you get user access wrong, you can:

• Accidentally give someone delete permissions on production S3 buckets
• Get a surprise ₹1 lakh bill from a compromised access key
• Fail RBI/DPDP Act compliance audit
• Have developers fighting over “who broke staging again?”
• Spend hours every week doing manual “please give me access” tickets

So let’s do this properly — like I’m your favorite teacher who actually wants you to never make those mistakes.

1. The Big Picture — Three Layers of “Who Can Do What” in AWS (2026)

AWS has evolved identity management quite a bit. In 2026 you basically deal with three main layers (most teams use all three):

2. Layer 1 — The Root User (The Most Dangerous Account)

• One per AWS account — created when you sign up
• Has unlimited permissions — can do literally anything
• Never use root for daily work (AWS strongly warns you about this)

What you should do with root (and nothing else):

1. Enable MFA immediately (virtual MFA or hardware key)
2. Add a strong password (not reused anywhere)
3. Create your first IAM admin user/role → log out of root forever
4. Use root only for:
   • Changing billing information
   • Closing the account
   • Certain rare account recovery actions

Real Hyderabad mistake (very common 2025–2026): A student/founder logs in with root every day → accidentally runs a Spot fleet with no termination policy → forgets about it → wakes up to ₹80,000 bill.

Rule #1 (memorize forever): Never log in as root after day 1. Never give root credentials to anyone. Ever.

3. Layer 2 — IAM Users & IAM Roles (The Workhorses)

These are the two different ways to give permissions inside one AWS account.

Golden rule in 2026 (most important sentence today):

In 2026, almost nobody should use long-lived IAM user access keys. Use IAM roles + IAM Identity Center (SSO) instead.

4. Layer 3 — AWS IAM Identity Center (The Modern Way — SSO)

This replaced the old “AWS SSO” service.

What it really does:

• Central login portal for all your AWS accounts
• Integrates with your company identity provider (Microsoft Entra ID, Okta, Google Workspace, OneLogin…)
• Developers log in once → get temporary role credentials
• No more long-lived access keys floating around
• One place to manage permissions across 10 or 100 AWS accounts

Typical flow for a Hyderabad startup in 2026:

1. Company uses Microsoft 365 / Google Workspace
2. Enable IAM Identity Center → connect to Microsoft Entra ID / Google
3. Create permission sets (roles)
   • “Developer” → read-only on dev accounts
   • “DevOps” → full admin on staging & prod
   • “BillingViewer” → only Billing console
4. Assign users/groups to permission sets + accounts
5. Developer logs in to https://yourcompany.awsapps.com/start
6. Chooses account + role → gets temporary credentials
7. Uses AWS CLI / Console / SDK with temporary role

→ No more “access key compromised” incidents → No more “I lost my key, create new one” tickets → One login for all 5–50 AWS accounts

5. Real Hyderabad Example — Full Access Setup (2026 Typical)

Your startup “TeluguBites” — 12 developers, 3 DevOps, 2 finance people, 5 AWS accounts (dev, staging, prod, analytics, security-audit)

Modern setup (recommended 2026):

1. Root account — only used once to enable IAM Identity Center + add MFA
2. IAM Identity Center enabled → connected to Google Workspace
3. Permission sets created:
   • DeveloperReadOnly — read access to dev & staging
   • DevOpsAdmin — admin on dev/staging/prod
   • FinanceBilling — Billing & Cost Explorer only
   • SecurityAuditor — read-only CloudTrail, GuardDuty, Config
4. Assign Google Workspace groups to permission sets + AWS accounts
5. Developers log in via https://telugubites.awsapps.com/start → Choose “dev account” → assume “DeveloperReadOnly” role → Get temporary credentials (valid 1–12 hours)

Result:

• No long-lived keys → impossible to leak permanent credentials
• One login for all accounts
• Finance can see bills without seeing prod resources
• Security team can audit without write access
• Compliance team loves the centralized audit trail

6. Quick Hands-On – Feel the Difference

1. Log in as root → enable MFA → create first IAM admin user (old way)
2. Switch to IAM Identity Center → enable it → connect to Google Workspace / Microsoft Entra
3. Create permission set → assign yourself → log out → log in via SSO portal
4. See how you get temporary credentials — no more permanent keys

Summary Table — AWS User Access Cheat Sheet (2026 – India Focus)

Teacher’s final note (real talk – Hyderabad 2026):

The single biggest security improvement you can make today is:

1. Put MFA on root and never log in again
2. Enable IAM Identity Center + connect to Google Workspace / Microsoft 365
3. Stop using IAM user access keys — switch to roles & SSO

Do these three things and you’ve already passed most security audits and avoided most credential-leak disasters.

Got it? This is the “who is allowed to touch what?” foundation lesson.

Next?

• Step-by-step: Set up IAM Identity Center + Google Workspace + permission sets?
• Deep dive: IAM role vs IAM user vs federated identity?
• Or how to create a least-privilege IAM role for a Lambda function?

Tell me — next whiteboard ready! 🚀🔑