IAM Policies
What is AWS IAM Policies?
AWS policies are JSON documents used to define permissions. They answer the question:
"Who can do what, on which resources, under what conditions?"
They are used to allow or deny access to AWS resources.
Basic Concept:
Imagine you're running a shoe store. You have staff (users), rooms (resources), and roles (e.g., cashier, manager).
🔐 A policy is like a rule: ➤ "Only the cashier can access the cash register."
In AWS:
👤 Users/Roles = People/Systems
📦 Resources = AWS services (S3 buckets, EC2, etc.)
🛡️ Policy = Access rule
Types of Policies:
Identity Policy
User / Group / Role
What the identity can do
Resource Policy
S3, KMS, Lambda, etc.
Who can access the resource
Trust Policy
IAM Role
Who can assume the role
Service Control Policy
AWS Account / OU
Limits max permissions for an account
Session Policy
Temporary Sessions
Restrict access for a session
Where Are AWS Policies Applied?
AWS policies are mainly applied to:
🔹 Identities (Users, Groups, Roles)
🔐 These are called Identity-Based Policies
✅ Attached to:
IAM Users
IAM Groups
IAM Roles
📌 Effect: Defines what actions that identity is allowed/denied to perform on specific AWS resources.
🧠 Example:
"Allow user Bob to list all S3 buckets."
These are called Resource-Based Policies
Attached directly to:
S3 Buckets
SQS Queues
SNS Topics
KMS Keys
Lambda functions
Secrets Manager
📌 Effect: Grants access to the resource from other AWS accounts, services, or roles.
🧠 Example: Allow another AWS account to access an S3 bucket:
IAM Roles — via Trust Policies
These are Trust Policies that define who can assume a role.
✅ Attached to IAM roles only
📌 Effect: Says which identity/service can assume the role using sts:AssumeRole.
🧠 Example:
Entire AWS Accounts (Only with AWS Organizations)
These are Service Control Policies (SCPs)
✅ Attached to:
AWS Accounts inside an Organization
Organizational Units (OUs)
📌 Effect: Apply a "guardrail" across the entire account — no user can override it.
🧠 Example:
Block the use of EC2 in an entire account:
Temporary Sessions
These are Session Policies
✅ Applied to:
Temporary credentials created via
AssumeRole,Federation, or AWS SSO
📌 Effect: Temporarily limits permissions during that session
🧠 Example: A federated user can only access DynamoDB for 1 hour
Not Applied To:
Specific AWS Regions (but you can restrict access to a region using Condition)
Identity Policy
User / Group / Role
What the identity can do
Resource Policy
S3, KMS, Lambda, etc.
Who can access the resource
Trust Policy
IAM Role
Who can assume the role
Service Control Policy
AWS Account / OU
Limits max permissions for an account
Session Policy
Temporary Sessions
Restrict access for a session
Policy Structure:
"Version"
Policy language version (always use "2012-10-17" — it's the latest stable)
"Statement"
Main section containing permission rules (can be one or many)
"Effect"
Allow or Deny
"Action"
What action is allowed/denied (e.g., s3:GetObject, ec2:StartInstances)
"Resource"
What resource it applies to (like a specific S3 bucket)
"Principal"
(only in trust or resource policies) Who the policy applies to
"Condition"
(optional) Add extra filters like time, IP, tags
Inline vs Managed Policies:
Inline Policy
Attached directly to one user/role, tightly bound
Managed Policy
Reusable and attachable to multiple identities
AWS Managed
Provided by AWS (e.g., AmazonS3ReadOnlyAccess)
Customer Managed
You create and manage it
Permission Boundarie
Acts like a "fence" that limits what a role/user can do even if a policy allows it.
🔐 Use case: Let junior admins create EC2s, but restrict them from deleting.
Restrict what accounts in your AWS Organization can do, even if a user has Admin rights.
Example:
Block entire account from using S3:
Advanced Conditions
Conditions let you fine-tune access:
Combine 2-3 conditions to enforce secure access
Examples of IAM Policies:
Last updated