AWS Identity and Access Management
Using IAM (API Version 2010-05-08)
« PreviousNext »
View the PDF for this guide.Go to the AWS Discussion Forum for this product.Go to the Kindle Store to download this guide in Kindle format.Did this page help you?  Yes | No |  Tell us about it...

Overview of AWS IAM Policies


To assign permissions to a user, group, role, or resource, you create a policy, which is a document that explicitly lists permissions. In its most basic sense, a policy lets you specify the following:

  • Actions: what actions you will allow. Each AWS service has its own set of actions. For example, you might allow a user to use the Amazon S3 ListBucket action, which returns information about the items in a bucket. Any actions that you don't explicitly allow are denied.

  • Resources: which resources you allow the action on. For example, what specific Amazon S3 buckets will you allow the user to perform the ListBucket action on? Users cannot access any resources that you have not explicitly granted permissions to.

  • Effect: what the effect will be when the user requests access—either allow or deny. Because the default is that resources are denied to users, you typically specify that you will allow users access to resource.

Policies are documents that are created using JSON. A policy consists of one or more statements, each of which describes one set of permissions. Here's an example of a simple policy.

  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"

You can attach this policy to an IAM user or group. If that's the only policy for the user or group, the user or group is allowed to perform only this one action (ListBucket) on one Amazon S3 bucket (example_bucket).

To specify resource-based permissions, you can attach a policy to the resource, such as an Amazon SNS topic or Amazon S3 bucket. In that case, the policy has to include information about who is allowed to access the resource, known as the principal. (For user-based policies, the principal is the IAM user that the policy is attached to, or the user who gets the policy from a group.)

The following example shows a policy that might be attached to an Amazon S3 bucket and that grants permission to a specific AWS account to perform any Amazon S3 actions in mybucket. This includes both working with the bucket and with the objects in it. (Because the policy grants trust only to the account, individual users in the account must still be granted permissions for the specified Amazon S3 actions.)

  "Version": "2012-10-17",
  "Id": "S3-Account-Permissions",
  "Statement": [{
    "Sid": "1",
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root"]},
    "Action": "s3:*",
    "Resource": [

IAM policies control access regardless of the interface. For example, you could provide a user with a password to access the AWS Management Console, and the policies for that user (or any groups the user belongs to) would control what the user can do in the AWS Management console. Or, you could provide the user with AWS access keys for making API calls to AWS, and the policies would control what actions the user could call through a library or client that uses those access keys for authentication.

For basic example policies that cover common scenarios, see Example Policies for Administering AWS Resources, AWS Services That Support IAM, and the AWS Policy Examples page in the AWS Sample Code & Libraries section of the AWS website.

IAM policy templates and the policy generator are available from the IAM console of the AWS Management Console. For more information about creating policies in the console, see Managing IAM Policies. Also, you can use the AWS Policy Generator online to create policies for AWS products without accessing the console.


When you apply a custom policy, IAM checks its syntax. However, because IAM evaluates policies at run time using a specific request context (in which multiple policies might be in effect), it cannot check the validity of all resources, actions, and permissions in a custom policy at the time that you apply the policy. If you need help in creating a policy, we recommend using a policy template or the policy generator.

Multiple Statements and Multiple Policies

You can attach more than one policy to an entity. If you have multiple permissions to grant to an entity, you can put them in separate policies, or you can put them all in one policy.

Generally, each statement in a policy includes information about a single permission. If your policy includes multiple statements, a logical OR is applied across the statements at evaluation time. Similarly, if multiple policies are applicable to a request, a logical OR is applied across the policies at evaluation time.

Users often have multiple policies that apply to them (but aren't necessarily attached to them). For example, IAM user Bob could have policies attached to him, and other policies attached to the groups he's in. In addition, he might be accessing an Amazon S3 bucket that has its own bucket policy (resource-based policy). All applicable policies are evaluated and the result is always that access is either granted or denied. For more information about the evaluation logic we use, see IAM Policy Evaluation Logic.

Policy Structure

Each policy is a JSON document. As illustrated in the following figure, a policy includes:

  • Optional policy-wide information (at the top of the document)

  • One or more individual statements

Each statement includes the core information about a single permission. If a policy includes multiple statements, we apply a logical OR across the statements at evaluation time. If multiple policies are applicable to a request, we apply a logical OR across the policies at evaluation time.

General policy structure

The information in a statement is contained within a series of elements. For information about these elements, see IAM Policy Elements Reference.

Example Policy example 2

The following policy has two statements. Assume that the user or group that the policy is attached to is in AWS account 123456789012. (Policies can't reference resources in other accounts.) The policy lets the user do the following:

  • Manage the access keys for any user in the AWS account, starting on July 1, 2013

  • Allow users to describe, launch, stop, start, and terminate Amazon EC2 instances in the us-west-2 region.

  "Version": "2012-10-17",
  "Statement": [
      "Effect": "Allow",
      "Action": [
      "Resource": "arn:aws:iam::123456789012:user/*",
      "Condition": {"DateGreaterThan": {"aws:CurrentTime": "2013-07-01T00:00Z"}}
      "Effect": "Allow",
      "Action": [
      "Resource": "arn:aws:ec2:us-west-2:123456789012:instance/*"

The Resource element in each statement could instead be stated as *. AWS would determine the applicable resources based on which AWS account owns the policy and the actions specified.