AWS IAM (Identity and Access Management) is the foundation of all things security in AWS. Whether you're a solo developer, part of a small team, or managing a large-scale infrastructure, IAM best practices can make or break your cloud security.
In this blog, Iโll cover:
IAM concepts you must understand
Real-world IAM configurations
Common mistakes to avoid
A practical security checklist
Hands-on examples for developers and DevOps engineers
Letโs turn your AWS account from โdefaultโ to bulletproof.
๐ง What is IAM?
IAM is the AWS service that helps you:
Authenticate who is making a request (identity)
Authorize what that identity can do (access)
It supports:
Users (humans with long-term credentials)
Roles (temporary access for AWS services or external identities)
Groups (collections of users)
Policies (documents that define permissions)
๐งฑ IAM Components Explained Simply
Component Use Case
User An engineer in your team
Group All backend developers
Role Give Lambda temporary access to S3
Policy โAllow reading from S3 bucket Xโ
Policies use JSON and follow this structure:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket/*"
}
]
}
๐ Step 1: Secure Your Root Account Immediately
Your AWS root user is the most powerful account. Here's what to do:
โ
Enable MFA (Multi-Factor Authentication)
โ
Donโt use it for daily tasks
โ
Create an IAM user with admin privileges for regular operations
Tip: Use a password manager to store root credentials safely.
๐ฅ Step 2: Create IAM Users and Groups (No Sharing)
Instead of sharing access keys:
Create a separate user for each team member
Assign users to groups like dev, ops, admin
Attach policies to groups โ not individual users
aws iam create-group --group-name developers
aws iam add-user-to-group --group-name developers --user-name alice
๐ก๏ธ Step 3: Use Roles for Services and Temporary Access
IAM Roles are not tied to a specific user. They are:
Assumed by AWS services (e.g., EC2, Lambda)
Used for federated identities (e.g., SSO or cross-account access)
Example: EC2 Instance Access to S3
Create a role with S3 read access
Attach role to EC2 instance
The EC2 instance automatically gets temporary credentials
๐ Step 4: Rotate Access Keys and Use IAM Roles for Apps
If youโre storing AWS access keys in:
โ Source code
โ GitHub
โ Hardcoded scripts
โฆ STOP!
Do this instead:
Use IAM roles with temporary credentials
Rotate keys via AWS Secrets Manager
Enable CloudTrail logging to audit credential usage
๐ Step 5: Follow the Principle of Least Privilege (PoLP)
Donโt give โAdminโ permissions to every resource.
โ
Give only the permissions the user or service needs
โ
Use IAM Access Analyzer to detect unused permissions
โ
Start with โread-onlyโ access and escalate if necessary
๐ Example: Read-only Policy for RDS
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:Describe*",
"cloudwatch:GetMetricData"
],
"Resource": "*"
}
]
}
Attach this to a user who only needs monitoring access.
๐จ Step 6: Enable MFA Everywhere
Use MFA for:
Root account
All IAM users
AWS CLI (aws configure + session-token)
SSO users via external identity providers
MFA options:
Virtual (Google Authenticator, Authy)
Hardware (Yubikey)
SMS (less secure)
๐ Step 7: Monitor IAM Activity
IAM changes are sensitive. Use these tools:
CloudTrail โ Logs every IAM action
IAM Access Analyzer โ Detects unused access
AWS Config โ Tracks config drift
Trusted Advisor โ Flags security risks
Example: Query who made a policy change in the last 24 hours:
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=PutUserPolicy
๐งช Step 8: Test Permissions Safely
Use the IAM Policy Simulator:
Test if a user/role has access before deploying
Avoid downtime due to incorrect permissions
Also:
Use DryRun in AWS CLI:
aws ec2 start-instances --instance-ids i-12345 --dry-run
๐งฐ Step 9: Use Service Control Policies (SCP) for Org-Wide Control
If you're using AWS Organizations:
SCPs allow you to restrict what accounts can do even if a user has admin
Great for child accounts (dev, test)
Example: Block EC2 usage in dev account:
{
"Effect": "Deny",
"Action": "ec2:",
"Resource": ""
}
๐งผ Step 10: Periodic IAM Cleanup
Donโt let your IAM become the โjunk drawerโ of AWS.
Schedule monthly cleanup tasks:
โ
Remove inactive users
โ
Revoke unused keys
โ
Rotate credentials
โ
Review attached policies
โ
Delete test roles
Use this script to find users who havenโt logged in:
aws iam get-user --user-name alice
aws iam generate-credential-report
๐งพ IAM Security Checklist
โ
Task Description
Root MFA Enabled Absolute must
IAM Users Created No sharing of credentials
Groups Used For scalable access control
Roles Used Temporary access only
Least Privilege No wide-open * policies
MFA Everywhere For users + services
Monitor Changes CloudTrail, Config, Access Analyzer
Rotate Keys At least every 90 days
Cleanup Old Users Monthly checkup
SCP Applied Restrict dev/test accounts
๐ Final Thoughts
IAM is not optional โ itโs the backbone of cloud security.
Whether youโre building apps, deploying ML models, or running Kubernetes clusters โ IAM determines what has access to what. A single misconfigured policy could expose your data, shut down your environment, or worse.
Start small, review regularly, and automate wherever possible.
๐ข Let's Chat
Have you implemented IAM best practices in your AWS environment?
What worked well โ and what didnโt?
Drop your experiences in the comments. Letโs make cloud security a habit, not an afterthought.
Top comments (0)