IAM Users: Long-Term Named Identities
An IAM user represents a single person or application that needs long-term, persistent credentials to interact with AWS — a username, and optionally a password for console access and access keys for programmatic API calls. Each user is unique within an AWS account and by default has no permissions at all until you attach a policy. Because access keys are long-lived and easy to leak (accidentally committed to a public GitHub repo, for instance), AWS best practice pushes teams away from creating IAM users for everyday human access wherever possible, favoring federated identity through IAM Identity Center or roles assumed via SSO instead.
Cricket analogy: An IAM user is like a specific player issued a personal team ID card that grants them access to the dressing room and equipment — Rishabh Pant's card is his alone, and if it's lost and someone else uses it, the team has no way to tell who actually walked in.
IAM Groups: Bundling Permissions for People
A group is a named collection of IAM users, and policies attached to the group apply to every user who is a member. Groups exist purely for permission management convenience — you can't assign a group as the principal in a resource policy, and a group can't be a member of another group, but attaching a policy once to a 'Developers' group and adding or removing users from it is far more maintainable than attaching and re-attaching the same policy to each user individually as your team changes. Best practice is to grant permissions through group membership rather than attaching policies directly to individual users, since it makes audits and offboarding far simpler.
Cricket analogy: A group is like a franchise issuing all its bowlers the same training-ground access badge — add a new bowler to the squad and they automatically get everything bowlers get, without re-issuing individual permissions.
IAM Roles: Temporary Credentials for Trusted Principals
A role is not tied to a specific person; it's an identity with a permissions policy and a trust policy that defines who or what is allowed to assume it — an EC2 instance, a Lambda function, a user from another AWS account, or a federated identity from your corporate directory. When a trusted principal assumes a role, AWS's Security Token Service (STS) issues temporary credentials (an access key, secret key, and session token) that automatically expire, typically within an hour by default, dramatically reducing the blast radius if they're ever exposed compared to a long-lived IAM user access key. Roles are the recommended way to grant AWS resources like EC2 instances or Lambda functions permission to call other AWS services, and also underpin cross-account access and federated single sign-on.
Cricket analogy: A role is like a visiting player being issued a temporary match-day accreditation that expires at stumps — it grants exactly the field access needed for that day's game and then automatically stops working, unlike a permanent team badge.
// Trust policy on an IAM role, allowing an EC2 instance to assume it
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "ec2.amazonaws.com" },
"Action": "sts:AssumeRole"
}
]
}A role has two policies attached to it: the trust policy (who/what can assume the role) and one or more permissions policies (what the role can do once assumed). Confusing these is a common beginner mistake — editing the permissions policy doesn't change who can assume the role, and editing the trust policy doesn't change what the role is allowed to do.
- IAM users represent long-term identities for people or applications, with optional passwords and access keys.
- Groups bundle policies for multiple users, simplifying permission management and offboarding — they aren't principals for resource policies.
- A user or group can never be a member of another group.
- Roles are assumable identities with a trust policy (who can assume) and permissions policy (what they can do).
- Assuming a role via STS issues short-lived, auto-expiring temporary credentials.
- Roles are the recommended way for AWS services like EC2 and Lambda to access other AWS resources.
- Best practice favors roles and federated access over long-lived IAM user access keys for everyday access.
Practice what you learned
1. What permissions does a newly created IAM user have by default?
2. Which statement about IAM groups is correct?
3. What two components define an IAM role?
4. What service issues temporary credentials when a principal assumes an IAM role?
5. Why does AWS best practice discourage using long-lived IAM user access keys for everyday human access?
Was this page helpful?
You May Also Like
IAM Policies Explained
IAM policies are JSON documents that define permissions, and understanding their structure and evaluation logic is essential to securing an AWS account.
AWS KMS Basics
AWS Key Management Service (KMS) creates and controls the cryptographic keys used to encrypt data across AWS services, without exposing the underlying key material.
RDS Fundamentals
Amazon RDS is a managed relational database service that automates provisioning, patching, backups, and failover for engines like MySQL, PostgreSQL, and Aurora.