Menu
AWS Identity and Access Management
User Guide

Example Policies for Administering AWS Resources

This section shows some examples of policies that control access to resources in AWS services. For examples of policies that show how to let IAM users administer IAM resources—for example, to allow users to change their own access keys—see Example Policies for Administering IAM Resources.

Allow Users to Access a Specific Bucket in Amazon S3

The following policy can be attached to an IAM user or an IAM group. It gives the user or group members access to a specific bucket and to all the objects in it. Users can also list all the buckets in the account (the s3:ListAllMyBuckets permission); this permission lets the user perform the other actions using the Amazon S3 console.

Note

In the following policy, you need to replace EXAMPLE-BUCKET-NAME with the name of your bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::EXAMPLE-BUCKET-NAME"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::EXAMPLE-BUCKET-NAME/*"
    }
  ]
}

Allow Users to Access a Personal "Home Directory" in Amazon S3

The following policy can be attached to an IAM group. It lets an IAM user in that group use the AWS Management Console access a "home directory" in Amazon S3 that matches their user name. For example, user Bob can access s3://BUCKET-NAME/home/Bob/, but he cannot access s3://BUCKET-NAME/home/Alice/. Inside his or her "home directory," each user can perform all Amazon S3 actions, such as GetObject, ListBucket, PutObject, and DeleteObject.

Note

In the following policy, you need to replace BUCKET-NAME with the name of a bucket under which you have created a home folder and folders for individual users.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::BUCKET-NAME",
      "Condition": {"StringLike": {"s3:prefix": [
        "",
        "home/",
        "home/${aws:username}/*"
      ]}}
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::BUCKET-NAME/home/${aws:username}",
        "arn:aws:s3:::BUCKET-NAME/home/${aws:username}/*"
      ]
    }
  ]
}

The previous example policy uses a policy variable (${aws:username}) that is evaluated at run time and contains the friendly name of the IAM user who made the request.

Console-based access is granted by the statements that include the ListAllMyBuckets, GetBucketLocation, and ListBucket actions; these actions are required in order to be able to get to the bucket listings in the AWS Management Console. When the preceding policy is attached to a group, each user in the group can read, write, and list objects only in their home directory. The policy also lets the user see that other user directories exist in the bucket, but users cannot list, read, nor write the contents of the other users' directories.

Allow Users Signed In with Amazon Cognito to Access their Own Amazon S3 Folder

Amazon Cognito is an easy way to use web identity federation in your mobile app. Using Amazon Cognito, you can provide access to AWS resources for users who have signed in to your app using a third-party identity provider like Login with Amazon, Facebook, Google, or any Open-ID Connect (OIDC) compatible identity provider instead of using an IAM user. To use Amazon Cognito for web identity federation, you create a role that determines what permissions the federated user will have. You can create one role for authenticated users. If your app allows unauthenticated (guest) users, you can create a second role that defines the permissions for those users.

For more information about Amazon Cognito, see the following:

The following example shows a policy that might be used for a mobile app that uses Amazon Cognito. The condition makes sure that the user has access to objects in the Amazon S3 bucket represented by EXAMPLE-BUCKET-NAME only if the object's name includes a provider name (here, cognito), the friendly name of the application (here, mynumbersgame), and the federated user's ID.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::EXAMPLE-BUCKET-NAME"],
      "Condition": {"StringLike": {"s3:prefix": ["cognito/mynumbersgame/"]}}
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::EXAMPLE-BUCKET-NAME/cognito/mynumbersgame/${cognito-identity.amazonaws.com:sub}",
        "arn:aws:s3:::EXAMPLE-BUCKET-NAME/cognito/mynumbersgame/${cognito-identity.amazonaws.com:sub}/*"
      ]
    }
  ]
}

Allow Users to Access All Actions on a DynamoDB Table Whose Name Matches the User Name

The following policy can be attached to an IAM group and gives a user permission to programmatically access an DynamoDB table whose name matches the user's name. For example, user Bob can perform any DynamoDB actions in the table named Bob. The policy can be attached to a group that contains users who are allowed to each manage their own DynamoDB table.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "dynamodb:*",
    "Resource": "arn:aws:dynamodb:AWS-REGION-IDENTIFIER:ACCOUNT-ID-WITHOUT-HYPHENS:table/${aws:username}"
  }]
}

The policy uses a policy variable (${aws:username}) that is evaluated at run time and contains the friendly name of the IAM user who made the request.

Allow Users to Manage Amazon EBS Volumes and Amazon EC2 Instances That Have the Specified Tag

The following example policy allows users to attach Amazon EBS volumes that have the tag volume_user=IAM user name to Amazon EC2 instances that have the tag department=dev, and to detach the volumes from those instances. When you attach this policy to an IAM group, the ${aws:username} policy variable resolves to the user name of the IAM user, and thus the policy grants each IAM user in the group permission to attach or detach volumes that have a tag named volume_user that has his or her IAM user name as a value.

For more information about creating IAM policies to control access to Amazon EC2 resources, see Controlling Access to Amazon EC2 Resources in the Amazon EC2 User Guide for Linux Instances.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:AttachVolume",
        "ec2:DetachVolume"
      ],
      "Resource": "arn:aws:ec2:AWS-REGION-IDENTIFIER:ACCOUNT-ID-WITHOUT-HYPHENS:instance/*",
      "Condition": {"StringEquals": {"ec2:ResourceTag/department": "dev"}}
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:AttachVolume",
        "ec2:DetachVolume"
      ],
      "Resource": "arn:aws:ec2:AWS-REGION-IDENTIFIER:ACCOUNT-ID-WITHOUT-HYPHENS:volume/*",
      "Condition": {"StringEquals": {"ec2:ResourceTag/volume_user": "${aws:username}"}}
    }
  ]
}

Allow only a specific Amazon EC2 Instance to Run Certain AWS Commands

AWS commands called from an Amazon EC2 instance run with the permissions granted to the role that is attached to the instance profile. The following example policy, if attached to that role, allows commands from the instance to attach or detach volumes associated with that same instance. The identity of the instance is specified with an ARN in the Condition element. Adding the SourceInstanceArn condition to one statement in a policy that otherwise grants permissions for many Amazon EC2 instances enables you to specify one instance in a fleet as a an exception that can perform a unique task that others with the same attached policy cannot perform. In the example that follows, only the instance identified by instance-id can attach or detach volumes to instances in the account, including its own. Other statement elements that might exist in the policy are not impacted by the restriction of this one statement.

For more information about creating IAM policies to control access to Amazon EC2 resources, see Controlling Access to Amazon EC2 Resources in the Amazon EC2 User Guide for Linux Instances.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:AttachVolume",
        "ec2:DetachVolume"
      ],
      "Resource": [
        "arn:aws:ec2:region:account-id:volume/*",
        "arn:aws:ec2:region:account-id:instance/*"
      ],
      "Condition": {
        "ArnEquals": {
          "ec2:SourceInstanceARN": "arn:aws:ec2:region:account-id:instance/instance-id"
        }
      }
    }
  ]
}

Use Conditions to Restrict When Permissions Are Allowed

The following example policy allows users to perform all Amazon EC2 actions on all Amazon EC2 resources, but only when the user has authenticated using multifactor authentication (MFA), and only when the action occurs between the 20th of April 2015 and the 24th of April 2015 (UTC), inclusive. This policy shows an example of multiple conditions, which are evaluated using a logical AND.

{
  "Version": "2012-10-17",
  "Statement": {
    "Action": "ec2:*",
    "Effect": "Allow",
    "Resource": "*",
    "Condition": {
      "Bool": {"aws:MultiFactorAuthPresent": true},
      "DateGreaterThan": {"aws:CurrentTime": "2015-04-20T00:00:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2015-04-24T00:00:00Z"}
    }
  }
}

For more information about adding conditions to policies, see Condition in the Policy Element Reference.

Deny All Access Except to a Specific Set of AWS Products and Resources

The following policy gives users access to only the following:

  • The DynamoDB table whose name is represented by EXAMPLE-TABLE-NAME.

  • The AWS account's corporate Amazon S3 bucket whose name is represented by EXAMPLE-BUCKET-NAME and all the objects it contains.

The policy includes an explicit deny ("Effect":"Deny"). In conjunction with the NotAction and NotResource elements, this helps to ensure that the users can't use any AWS actions or resources except those specified in the policy, even if permissions have been granted in another policy. (An explicit deny statement takes precedence over an allow statement.) For more information, see IAM Policy Evaluation Logic.

Note

The following policy works only for API access. For more information about granting bucket access through the AWS Management Console, see An Example: Using IAM Policies to Control Access to your Bucket in the Amazon Simple Storage Service Developer Guide.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:*",
        "s3:*"
      ],
      "Resource": [
        "arn:aws:dynamodb:AWS-REGION-IDENTIFIER:ACCOUNT-ID-WITHOUT-HYPHENS:table/EXAMPLE-TABLE-NAME",
        "arn:aws:s3:::EXAMPLE-BUCKET-NAME",
        "arn:aws:s3:::EXAMPLE-BUCKET-NAME/*"
      ]
    },
    {
      "Effect": "Deny",
      "NotAction": [
        "dynamodb:*",
        "s3:*"
      ],
      "NotResource": [
        "arn:aws:dynamodb:AWS-REGION-IDENTIFIER:ACCOUNT-ID-WITHOUT-HYPHENS:table/EXAMPLE-TABLE-NAME",
        "arn:aws:s3:::EXAMPLE-BUCKET-NAME",
        "arn:aws:s3:::EXAMPLE-BUCKET-NAME/*"
      ]
    }
  ]
}

Block Requests That Don't Come From an Approved IP Address or Range

You might find this policy useful to apply to an IAM group that all the users in your company belong to. The policy denies access to all actions in the account when the request comes from outside the IP range 192.0.2.0 to 192.0.2.255 or 203.0.113.0 to 203.0.113.255. (The policy assumes the IP addresses for your company are within the specified ranges.) Use this policy in combination with other policies that allow specific actions. Regardless of which actions are allowed to a user or group via another policy, this policy ensures that all actions will be denied if the request originates from outside your company's IP address ranges.

Important

The aws:SourceIp condition key works only in an IAM policy if you are calling the tested API directly as a user. If you instead use a service to call the target service on your behalf, the target service sees the IP address of the calling service rather than the IP address of the originating user. This can happen, for example, if you use AWS CloudFormation to call Amazon EC2 to construct instances for you. There is currently no way to pass the originating IP address through a calling service to the target service for evaluation in an IAM policy. For these types of service API calls, do not use the aws:SourceIp condition key.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {"NotIpAddress": {"aws:SourceIp": [
      "192.0.2.0/24",
      "203.0.113.0/24"
    ]}}
  }
}

Restrict Access to the Policy Simulator APIs

The policy simulator APIs GetContextKeyForPrincipalPolicy and SimulatePrincipalPolicy can return information about the permissions granted to an IAM user, group, or role to the user calling the APIs. You might want to grant permissions to these APIs only to approved users. Others users can still call GetContextKeyForCustomPolicy and SimulateCustomPolicy because they only evaluate policies provided by that user as strings; there is no disclosure of sensitive information.

The following example shows how to allow access to the less sensitive "custom" APIs. The "principal" APIs are restricted by the default implicit deny, and so the user cannot simulate policies attaches to entities.

{
    "Version": "2012-10-17",
    "Statement": [{
        "Action": [
            "iam:GetContextKeysForCustomPolicy",
            "iam:SimulateCustomPolicy"
        ],
        "Effect": "Allow",
        "Resource": “*"
    }]
}

The following example allows the user to simulate policies only for those users that have the path developers.

{
    "Version": "2012-10-17",
    "Statement": [{
        "Action": [
            "iam:GetContextKeysForPrincipalPolicy",
            "iam:SimulatePrincipalPolicy"
        ],
        "Effect": "Allow",
        "Resource":"arn:aws:iam::123456789012:user/developers/*"
    }]
}

The following example allows the user to simulate any policy that is attached to any user in the current AWS account.

{    
    "Version" : "2012-10-17",   
    "Statement" : [{           
        "Action" : [           
            "iam:GetContextKeysForCustomPolicy",           
            "iam:GetContextKeysForPrincipalPolicy",           
            "iam:SimulateCustomPolicy",           
            "iam:SimulatePrincipalPolicy"           
        ],           
        "Effect" : "Allow",           
        "Resource" : “*"       
    }]
}

Enable Users to Upload Server Certificates and Use them with Elastic Load Balancing

The following example allows the user to upload and manage SSL/TSL server certificates and to attach them to an Elastic Load Balancing balancer.

{
    "Version" : "2012-10-17",
      "Statement" : [{
          "Effect" : "Allow",
          "Action" : [
              "iam:DeleteServerCertificate",               
              "iam:GetServerCertificate",               
              "iam:ListServerCertificates",               
              "iam:UpdateServerCertificate",               
              "iam:UploadServerCertificate"          
              "elasticloadbalancing:SetLoadBalancerListenerSSLCertificate"           
          ],           
          "Resource": [ "*" ]
    }]
}