AWS Account and IAM: Identity and Access

Concept

IAM (Identity and Access Management) is the AWS service that controls logins and permissions. It answers one question: who is allowed to do what in your AWS account?

Every AWS action goes through IAM first. Launching a server, reading a file and deleting a database are all checked. If IAM does not clearly allow an action, it is denied.

Two words come up all the time. Authentication means proving who you are (a login). Authorization means checking what you may do after you are logged in. In one line: authentication asks “who are you?”, authorization asks “what may you do?”. IAM does both.

Why this matters

This lesson protects you from the most costly AWS mistakes. These are real problems that happen to new users:

• Access keys (a secret ID and password pair that lets a program use your account) are uploaded to a public GitHub repository. Bots find them within minutes. Someone uses your account to mine crypto coins, and a bill of several lakh rupees arrives by the weekend.
• A developer with full admin access deletes the production database by accident.
• One leaked key gives an attacker access to everything, because nobody set limits.

Each of these is a mistake in how IAM was set up. It is not a fault in AWS. Get this lesson right and the rest of the course is safe to practise.

The hotel — the whole idea in one story

Imagine you own a hotel. This single picture explains all of IAM.

Keep this hotel in mind for the rest of the lesson. Every term below is one of these six things.

The four building blocks

1. IAM User — the staff member

An IAM user is one person (or one program) with its own name and login inside your AWS account. Think of Rahul, your accountant. He gets his own ID badge and enters with it. In AWS, every developer gets a separate login.

Never share one login between two people. If something breaks, you need to know who did it. A shared login makes that impossible.

2. IAM Group — the department

An IAM group is a named list of users. You attach permissions to the group, and every user in it gets them. A hotel with 20 staff cannot manage 20 separate sets of keys. So you make departments and give the keys to the department.

When a new person joins, put them in the department. They get the right access at once. When someone leaves, remove them from the department. You never touch 20 individual key cards.

3. IAM Policy — the rule card

An IAM policy is a document that lists what is allowed or denied. In AWS it is a JSON file (a text file in a fixed format). It is covered in detail below.

4. IAM Role — the temporary key card

An IAM role is an identity with permissions that anyone (or any server) can wear for a short time. It has no password of its own. It is the most important block, so it has its own section below.

Owner vs staff — root user vs IAM user

When you sign up for AWS, you automatically get a root user. This is the login made from your sign-up email address. It has full power over the account, like the hotel owner with the master key.

A sensible hotel owner does not carry the master key around for everyday work. They keep it in the safe and use a normal badge instead.

The big idea — IAM roles

An IAM role is a set of permissions that a person, a server or a service can wear for a short time. The role hands out temporary credentials that expire by themselves. This is the most important idea in the lesson. It is what separates a developer who understands AWS from one who only clicks through it.

If you come from Vercel, you may want to put credentials in a .env file. On AWS this habit is wrong and dangerous.

With a role attached to the server, your code does not change. The AWS SDK (the library your code uses to call AWS) finds the temporary credentials by itself:

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const s3 = new S3Client({ region: "ap-south-1" });

// The SDK finds the credentials from the attached role by itself
await s3.send(new PutObjectCommand({
  Bucket: "myapp-pdfs",
  Key: "quotation-1024.pdf",
  Body: pdfBuffer,
}));

Policies — how permissions are written

A policy is a JSON document. JSON is a plain-text format made of names and values in curly brackets. Only three parts of a policy really matter.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:PutObject",
      "s3:GetObject"
    ],
    "Resource": "arn:aws:s3:::myapp-pdfs/*"
  }]
}

An ARN (Amazon Resource Name) is the unique ID that AWS gives to every resource, like a full postal address. In the policy above, myapp-pdfs is an S3 bucket (a storage folder in AWS) and the /* at the end means every file inside it. The policy says: this identity may upload and download files, only in the myapp-pdfs bucket, and nothing else anywhere.

Two default behaviours to remember

• Everything is denied by default. No policy means no access. This is like a hotel where every door stays locked unless your card is set up for it.
• An explicit Deny always wins, even if another policy says Allow. A “staff not allowed” sign beats the master key.

Least privilege

Least privilege is the main rule of IAM: give the minimum access needed to do the job, and nothing more.

You would not give the room service boy a master key just because it is easy. Use the same care in AWS.

Real example — setting up a team

1. Create groups, one per job function

   In the console: IAM → User groups → Create. Make Developers (mostly read-only: can look, cannot change production) and DevOps (can build infrastructure, but cannot manage IAM itself).

2. Attach policies to the group, never to individual users

   An AWS-managed policy is a ready-made policy that AWS writes and updates for you. Give Developers ReadOnlyAccess (read everything, change nothing). Give DevOps PowerUserAccess (do everything except manage IAM and account settings). You never write these by hand.

3. Create a user and put them in a group

   One person, one identity. Create rahul and add him to Developers. He now gets everything that group allows, and nothing else.

4. Check who has what

   IAM's user list shows every identity and the groups each one is in. The Access advisor tab shows which services a user really used recently. Use it to spot permissions that nobody needs.

For real teams — IAM Identity Center

For people, AWS recommends IAM Identity Center (older name: AWS SSO, where SSO means single sign-on) instead of creating IAM users. It is a service where each person logs in once and can reach several AWS accounts.

It gives each person temporary credentials instead of permanent access keys. This is the same safety benefit as roles, but for people. It is also free.

For solo learning, plain IAM users are fine. For a team of twenty, use Identity Center.

The step you must not skip

Set up a billing alert today, before Lesson 7, when you start creating real resources. A billing alert is an email that AWS sends when your spending reaches a limit you chose. It lets you learn without worry.

Access key hygiene

An access key is a pair of values (an ID and a secret) that lets a program or the AWS CLI act as an IAM user. If you must use access keys, for example for the AWS CLI on your own laptop, follow these rules:

• Never commit them to Git. Add .env and *.pem to .gitignore on day one.
• Rotate them every 90 days. (To rotate means to replace an old key with a new one.)
• Delete unused keys at once.
• Turn on MFA for any user that has keys.

Rotating a key takes two steps. First create a new key and switch your CLI to it. Then delete the old key after you check that everything still works. IAM shows when each key was last used, so you know which keys are safe to delete.

Cost

IAM users, groups, roles, policies and Identity Center are all completely free. CloudWatch billing alarms are free for the first ten.

Practice task before Lesson 6

Everything here is free. At the end, your account is set up like a real team's account, even if you are the only member.

1. Confirm you are an IAM user, never root (Lesson 0): aws sts get-caller-identity.
2. In the console, create a Developers group with ReadOnlyAccess, and a user reader in it with one access key.
3. Create a policy myapp-pdfs-rw using the policy.json above: one bucket, two actions, nothing else.
4. See least privilege in action. Add the reader's key as a second CLI profile (a named set of login details), then try:
   as the readerCopy

   aws configure --profile reader                            # paste reader's keys
   aws iam list-users --profile reader                       # works: ReadOnlyAccess allows it
   aws iam create-group --group-name Hack --profile reader   # AccessDenied — as designed

5. Create the role EC2 will wear in Lesson 7: IAM → Roles → Create role → trusted entity AWS service: EC2 → attach myapp-pdfs-rw → name it myapp-ec2-role. The trust document is a small JSON file that says who may wear the role. Picking “EC2” writes it for you.
6. Delete the reader's access key. Keep the group, policy and role — Lesson 7 uses them.
7. Billing → Budgets → Create → ₹800 / month → your email. This one protects your wallet.

Then answer these in your own words:

1. Step 4 gave an AccessDenied error. Which of the two default behaviours caused it? Would a second policy with Deny on iam:CreateGroup change anything?
2. Explain the difference between the policy in step 3 and the role's trust document in step 5. Which one says what is allowed, and which one says who may wear the role?
3. Your EC2 server needs to upload PDFs to S3. List three ways to give it access. Rank them from worst to best, with one reason each.
4. A developer leaves the company. What single step do you take (hint: it is about groups)? Why is it one step and not twenty?

Conclusion

IAM is the hotel's key-card system. The root user is the owner's master key kept in the safe. Users are staff badges. Groups are departments. Policies are the rule cards. Roles are temporary key cards for visitors and machines. Every door is locked until a card is set up for it.

• Root: MFA on, no access keys, never used for daily work.
• Groups, not users: attach policies to groups and put people in the groups. Joining and leaving become one small step.
• Roles for machines: anything running inside AWS (EC2, Lambda, a GitHub Actions deploy) wears a role with temporary credentials. Long-lived keys in a .env file on a server are the most expensive mistake in this course.
• Policies: Effect, Action, Resource. Everything is denied by default, and an explicit Deny always wins. Least privilege means writing a narrow policy instead of using AdministratorAccess.
• Billing alert: set it before Lesson 7. It is the one alarm that protects your bank account instead of your uptime.

Identity is ready. Next we build the network where these identities will work: the VPC.

End of Lesson 5. Next: Lesson 6 — VPC: Subnets, Route Tables, Security Groups.

Also read: GitHub Access Control — The Same Idea as IAM →