AWS IAM Polices and their structure
3 min read
📜 IAM Policies
JSON documents that define permissions.
Answer: Who can do What on Which resources
Types:
Managed Policies (AWS or customer-managed)
Inline Policies (attached directly to one user, group, or role)
Attached to:
IAM Users
IAM Groups
IAM Roles
Use the least privilege principle: only give what’s needed
📜 IAM Policies: Managed vs Inline
✅ Managed Policies
Standalone policies you can reuse across multiple identities
Types:
AWS Managed → Predefined by AWS (e.g.
AmazonS3ReadOnlyAccess)Customer Managed → Created and controlled by you
Easy to update centrally and apply to many users/groups/roles
🔒 Inline Policies
Embedded directly into a specific user, group, or role
One-to-one relationship (cannot be reused)
Use when:
A policy is unique to a single identity
You want tight control or specific tracking
✍️ Quick Tip for Exam
Prefer Managed Policies for scalability
Use Inline Policies for tightly scoped or unique needs
IAM Policy Structure
{
"Version": "2012-10-17",
"Id": "OptionalPolicyIdentifier",
"Statement": [
{
"Sid": "OptionalStatementID",
"Effect": "Allow" | "Deny",
"Principal": "Who the policy applies to",
"Action": "service:operation",
"Resource": "ARN of the target resource",
"Condition": {
"OptionalConditions": "Based on context"
}
}
]
}
// Sample Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3ReadAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-example-bucket",
"arn:aws:s3:::my-example-bucket/*"
]
}
]
}
🔍 Key Elements to Understand:
Version: Always use
"2012-10-17"Statement: Main permission block
Sid: Optional statement ID (good for clarity)
Effect:
"Allow"or"Deny"Principal: Who/what the policy applies to (used mostly in resource-based policies)
Action: What can be done (e.g.
s3:PutObject)Resource: Where actions can be done
Condition (Optional): Adds extra logic (e.g., IP-based rules)
Key Elements in detail
🗓️ Version
Tells AWS which version of the policy language you’re using.
Always use:
"2012-10-17"(most up-to-date)
🆔 Id (optional)
A name/identifier for the whole policy.
Useful for tracking or referencing the policy.
📜 Statement
The heart of the policy — what it allows or denies.
Can be one or many blocks inside a policy.
🧩 Sid (optional)
Statement ID — like a label for each rule inside your policy.
Helpful for organizing if your policy has multiple statements.
✅ Effect
Says what happens:
"Allow"→ Grants permission"Deny"→ Explicitly blocks permission
⚠️ Deny always wins, even if another policy says "Allow".
👤 Principal
Who the policy applies to (user, account, service, etc.)
Mostly used in resource-based policies (like S3 bucket policies).
Example:
"Principal": { "AWS": "arn:aws:iam::123456789012:user/Alice" }
⚙️ Action
What the principal is allowed (or denied) to do.
Format:
service:operation- e.g.,
s3:PutObject,ec2:StartInstances,dynamodb:*
- e.g.,
📦 Resource
The specific resource the action applies to.
Format: ARN (Amazon Resource Name)
e.g.,
arn:aws:s3:::my-bucket/*Can be
"*"to mean “all resources” (be careful with this!)
🎯 Condition (optional)
Adds extra rules or filters.
e.g., allow access only from a specific IP address
e.g., allow access only if MFA is used
Very powerful for fine-grained control