AWS IAM basics: root account, users, groups, roles and least privilege
In short: AWS IAM controls who can do what in your account. Protect the root user with MFA and stop using it day to day, give people access through IAM Identity Center and roles, avoid long-lived access keys, and write policies that grant only the actions and resources really needed.
Why IAM matters most
In the cloud, identity is the new perimeter. Anyone with valid credentials can reach the AWS API from anywhere. Most serious cloud breaches involve stolen keys or over-generous permissions, not clever network attacks. AWS Identity and Access Management (IAM) is therefore the first service to get right.
Protect the root user
The root user is the email address that created the account. It can do everything, including closing the account, and policies cannot restrict it inside its own account.
- Turn on multi-factor authentication (MFA), ideally a hardware security key.
- Delete any root access keys.
- Use a shared, monitored mailbox for the root email, not one person's inbox.
- Create an administrative identity for daily work and stop using root.
- Alert on any root sign-in using CloudTrail.
In AWS Organizations you can also centrally manage root access for member accounts, removing their root credentials entirely.
Users, groups, roles and policies
| Component | What it is | Good practice |
|---|---|---|
| IAM user | Long-term identity with password and/or access keys | Avoid for people; use only where nothing else works |
| Group | Collection of users sharing policies | Attach policies to groups, not individuals |
| Role | Identity assumed for temporary credentials via AWS STS | Use for EC2, Lambda, cross-account and federated access |
| Policy | JSON document of allowed or denied actions on resources | Grant specific actions and resource ARNs |
| IAM Identity Center | Single sign-on for people across many accounts | Connect to your identity provider and use permission sets |
A policy that lets a role read one bucket only:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": ["arn:aws:s3:::<your-bucket>", "arn:aws:s3:::<your-bucket>/*"]
}]
}How permissions are evaluated
Everything starts as denied. An explicit deny anywhere wins over any allow. Guardrails such as service control policies (SCPs) and permissions boundaries set the maximum possible permissions but never grant anything by themselves. The request is allowed only when an identity policy or resource policy allows it and nothing denies it.
Least privilege in practice
- Start from AWS managed policies for learning, then narrow to custom policies for production.
- Use IAM Access Analyzer to find resources shared outside your account and to generate policies from real activity.
- Review last-accessed data and remove permissions nobody uses.
- Never embed access keys in code or Git; use roles, and rotate any keys that must exist.
- Add conditions, for example requiring MFA or a specific source network for sensitive actions.
Tip: the IAM and MFA lab walks through securing a new account step by step on your own free-tier account.
Practice
Why should you not use the root user for daily tasks?
An EC2 instance needs to read from S3. Should you store an access key on it?
A user has an allow for s3:* and an SCP denies s3:DeleteBucket. Can they delete a bucket?
Key takeaways
- Identity is the main perimeter in the cloud.
- Lock down root: MFA, no keys, monitored sign-ins.
- Prefer Identity Center and roles over IAM users and long-lived keys.
- Explicit deny wins; everything not allowed is denied.
- Grant specific actions on specific resources and review regularly.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.