IAM Policies

What are IAM Policies?

IAM policies are JSON documents that define permissions. They answer two questions: "who can do what" and "under what conditions." Think of them as contracts that specify exactly what actions are allowed or denied.

A policy might say: "User Alice can read and write objects in bucket my-app-data, but only from IP addresses in the office." That level of specificity is what makes IAM so powerful.

Policy Structure

Every policy has a few key elements:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

Effect is either Allow or Deny. Action specifies what operation is permitted. Resource specifies which AWS resources the action applies to. The ARN (Amazon Resource Name) uniquely identifies the resource.

Managed vs Inline Policies

Managed policies are standalone policies that you can attach to multiple users, groups, or roles. AWS provides many managed policies for common use cases — like PowerUserAccess or ReadOnlyAccess.

Inline policies are embedded directly in a user, group, or role. They're useful for one-off permissions that don't warrant a separate policy. Use managed policies for most cases; they're easier to manage and audit.

Policy Variables and Conditions

Policies support variables and conditions for dynamic permissions. For example, you can use ${aws:username} to reference the current user, or add conditions that check the current time, IP address, or whether MFA is enabled.

This lets you write policies like "users can only access their own resources" or "admin actions require MFA." It's like having smart locks that adapt based on who's knocking.

Testing Policies

AWS provides the IAM Policy Simulator in the console. It lets you test what actions are allowed or denied for a given user, group, or role. Use it before deploying policies to production.

The simulator is like a dress rehearsal — it shows you exactly what will happen without affecting real resources. It catches permission issues before they become problems. Always test your policies.