"Why isn't my EC2 working?!"
"AccessDenied for s3:GetObject?! I gave full permissions!"
If AWS feels like it's gatekeeping your services, you're not alone. IAM (Identity and Access Management) is one of the most powerful โ and confusing โ parts of AWS for beginners.
But hereโs the good news: You donโt need to be a security engineer to master IAM policies. You just need the right mental model, some good examples, and a few pro tips.
Letโs dive into how IAM policies really work โ and how to write and apply them like a cloud-native pro. ๐ง ๐ช
๐ง What Are IAM Policies (In Plain English)?
IAM policies are like permission slips for your AWS resources.
Real-world analogy: Imagine youโre organizing a hackathon in a coworking space. You give Dev A access to the main door, Dev B access to the kitchen, and Dev C access to the stage.
IAM policies do the same โ they grant (or deny) access to services like S3, EC2, Lambda, etc.
They come in two types:
- Identity-based policies โ attached to users, groups, or roles
- Resource-based policies โ attached directly to resources (e.g., S3 bucket policies)
๐ง Basic Structure of an IAM Policy
Hereโs a typical identity-based policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mybucket/*"
}
]
}
Letโs Break That Down:
-
Version: Always use2012-10-17 -
Effect:AlloworDeny -
Action: What the user can do (e.g.,s3:PutObject) -
Resource: The target (like an S3 bucket or specific file)
Pro Tip: AWS evaluates explicit denies first, then allows. So if there's a
Deny, it wins every time.
๐ Common IAM Policy Examples (With Use Cases)
โ Read-Only Access to S3 Bucket
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::mybucket",
"arn:aws:s3:::mybucket/*"
]
}
โ Start and Stop EC2 Instances Only
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*"
}
โ Full Access to DynamoDB (Dev Only)
{
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyDevTable"
}
Always scope down
*when you go to production.
๐ง Pro Tips for Writing and Debugging Policies
โ
Start with AWS Managed Policies
Theyโre prebuilt and safer for beginners. Example: AmazonS3ReadOnlyAccess
โ
Use the IAM Policy Simulator
Check what your policy actually allows: https://policysim.aws.amazon.com
โ
Avoid Wildcards in Production
Replace * in Action and Resource with specific permissions and ARNs.
โ
Use Conditions to Tighten Access
"Condition": {
"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
}
This ensures the action only works from a specific IP range.
โ
Never Attach Policies to Individual Users in Prod
Use Groups or Roles for cleaner and more scalable permissions.
โ ๏ธ IAM Mistakes to Avoid
- โ Using
AdministratorAccessfor everyone - โ Leaving default
*resources in policies - โ Ignoring
Denystatements - โ Not using MFA with IAM users
- โ Pushing access keys to GitHub (use roles and profiles instead!)
๐ฆ Bonus: Create a Custom IAM Policy in AWS Console
- Go to IAM > Policies > Create Policy
- Choose JSON tab and paste your policy
- Review โ Name it โ Create
- Attach it to a Group, Role, or User
And thatโs it โ your permissions are live! ๐ฅ
๐ง TL;DR โ IAM Policy Cheatsheet
| Concept | Meaning |
|---|---|
Effect |
Allow or Deny |
Action |
What can be done (e.g., s3:PutObject) |
Resource |
Where (e.g., arn:aws:s3:::mybucket) |
Condition |
Optional filters (IP, time, tag) |
๐ฌ Letโs Make IAM Simple โ Together
AWS IAM doesnโt have to be scary. Once you learn the pattern, youโll see the power โ and the beauty โ in how AWS protects your apps.
๐ Have you written a tricky policy lately? Want me to debug it with you?
Drop your JSON in the comments. Hit โค๏ธ if this helped, and share with someone new to AWS. Letโs empower more devs to build โ safely. ๐งก
Top comments (0)