Menu
Amazon Simple Queue Service
Developer Guide

Using Identity-Based Policies (IAM) Policies for Amazon SQS

This topic provides examples of identity-based policies in which an account administrator can attach permissions policies to IAM identities (users, groups, and roles).

Important

We recommend that you first review the introductory topics that explain the basic concepts and options available for you to manage access to your Amazon Simple Queue Service resources. For more information, see Overview of Managing Access Permissions to Your Amazon Simple Queue Service Resource.

Writing an Amazon SQS Policy

The following examples provide an introductory breakdown of a permission policy.

Example 1: Allow a User to Create Queues

In the following example, we create a policy for Bob that lets him access all Amazon SQS actions, but only with queues whose names are prefixed with the literal string bob_queue_.

Amazon SQS doesn't automatically grant the creator of a queue permission to use the queue. Therefore, we must explicitly grant Bob permission to use all Amazon SQS actions in addition to CreateQueue action in the IAM policy.

{
   "Version": "2012-10-17",
   "Statement":[{
      "Effect":"Allow",
      "Action":"sqs:*",
      "Resource":"arn:aws:sqs:*:123456789012:bob_queue_*"
      }
   ]
}

Example 2: Allow Developers to Write Messages to a Shared Queue

In the following example, we create a group for developers and attach a policy that lets the group use the Amazon SQS SendMessage action, but only with the queue that belongs to the specified AWS account and is named CompanyTestQueue.

{
   "Version": "2012-10-17",
   "Statement":[{
      "Effect":"Allow",
      "Action":"sqs:SendMessage",
      "Resource":"arn:aws:sqs:*:123456789012:CompanyTestQueue"
      }
   ]
}

Example 3: Allow Managers to Get the General Size of Queues

In the following example, we create a group for managers and attach a policy that lets the group use the Amazon SQS GetQueueAttributes action with all of the queues that belong to the specified AWS account.

{
   "Version": "2012-10-17",
   "Statement":[{
      "Effect":"Allow",
      "Action":"sqs:GetQueueAttributes",
      "Resource":"*"   
     }
   ]
}

Example 4: Allow a Partner to Send Messages to a Specific Queue

You can accomplish this task using an Amazon SQS policy or an IAM policy. Using an Amazon SQS policy might be easier if your partner has an AWS account. However, anyone in the partner's company who possesses the AWS security credentials can send messages to the queue. If you want to limit access to a particular user or application, you must treat the partner like a user in your own company and use an IAM policy instead of an Amazon SQS policy.

In the following example, we perform the following actions:

  1. Create a group called WidgetCo to represent the partner company.

  2. Create a user for the specific user or application at the partner's company who needs access.

  3. Add the user to the group.

  4. Attach a policy that gives the group access only to the SendMessage action for only the queue named WidgetPartnerQueue.

{
   "Version": "2012-10-17",
   "Statement":[{
         "Effect":"Allow",
         "Action":"sqs:SendMessage",
         "Resource":"arn:aws:sqs:*:123456789012:WidgetPartnerQueue"
      }
   ]
}

Customer-Managed Policy Examples

This section shows example policies for common Amazon SQS use cases.

You can use the console to verify the effects of each policy as you attach the policy to the user. Initially, the user doesn't have permissions and won't be able to do anything in the console. As you attach policies to the user, you can verify that the user can perform various actions in the console.

We recommend that you use two browser windows: one to grant permissions and the other to sign into the AWS Management Console using the user's credentials and verify permissions as you grant them to the user.

Example 1: Grant One Permission to One AWS Account

The following example policy grants AWS account number 111122223333 the SendMessage permission for the queue named 444455556666/queue1 in the US East (Ohio) region.

{
  "Version": "2012-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement": [
    {
      "Sid":"Queue1_SendMessage",
	  "Effect": "Allow",
	  "Principal": {
	    "AWS": "111122223333"
	  },
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:us-east-2:444455556666:queue1"
    }
  ]  
}

Example 2: Grant Two Permissions to One AWS Account

The following example policy grants AWS account number 111122223333 both the SendMessage and ReceiveMessage permission for the queue named 444455556666/queue1.

{
  "Version": "2012-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement": [
    {
      "Sid":"Queue1_Send_Receive",
      "Effect": "Allow",
      "Principal": {
        "AWS": "111122223333"
      },
      "Action": ["sqs:SendMessage","sqs:ReceiveMessage"],
      "Resource": "arn:aws:sqs:*:444455556666:queue1"
    }
  ]
}

Example 3: Grant All Permissions to Two AWS Accounts

The following example policy grants two different AWS accounts numbers (111122223333 and 444455556666) permission to use all actions to which Amazon SQS allows shared access for the queue named 123456789012/queue1 in the US East (Ohio) region.

{
  "Version": "2012-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement": [
    {
      "Sid":"Queue1_AllActions",
      "Effect": "Allow",
      "Principal": {
        "AWS": ["111122223333","444455556666"]
      },
      "Action": "sqs:*",
      "Resource": "arn:aws:sqs:us-east-2:123456789012:queue1"
    }
  ]
}

Example 4: Grant a Role and a User Name Cross-Account Permission

The following example policy grants role1 and username1 under AWS account number 111122223333 cross-account permission to use all actions to which Amazon SQS allows shared access for the queue named 123456789012/queue1 in the US East (Ohio) region.

{
  "Version": "2012-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement": [
    {
      "Sid":"Queue1_AllActions",
      "Effect": "Allow",
      "Principal": {
        "AWS": ["arn:aws:iam::111122223333:role/role1","arn:aws:iam::111122223333:user/username1"]
      },
      "Action": "sqs:*",
      "Resource": "arn:aws:sqs:us-east-2:123456789012:queue1"
    }
  ]
}

Example 5: Grant a Permission to All Users

The following example policy grants all users ReceiveMessage permission for the queue named 111122223333/queue1.

{
  "Version": "2012-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement": [
    {
      "Sid":"Queue1_AnonymousAccess_ReceiveMessage",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "sqs:ReceiveMessage",
      "Resource": "arn:aws:sqs:*:111122223333:queue1"
    }
  ]
}

Example 6: Grant a Time-Limited Permission to All Users

The following example policy grants all users ReceiveMessage permission for the queue named 111122223333/queue1, but only between 12:00 p.m. (noon) and 3:00 p.m. on January 31, 2009.

{
  "Version": "2012-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement": [
    {
      "Sid":"Queue1_AnonymousAccess_ReceiveMessage_TimeLimit",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "sqs:ReceiveMessage",
      "Resource": "arn:aws:sqs:*:111122223333:queue1",
      "Condition" : {
        "DateGreaterThan" : {
          "aws:CurrentTime":"2009-01-31T12:00Z"
        },
        "DateLessThan" : {
          "aws:CurrentTime":"2009-01-31T15:00Z"
        }
      }
    }
  ]
}

Example 7: Grant All Permissions to All Users in a CIDR Range

The following example policy grants all users permission to use all possible Amazon SQS actions that can be shared for the queue named 111122223333/queue1, but only if the request comes from the 192.168.143.0/24 CIDR range.

{
  "Version": "2012-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement": [
    {
      "Sid":"Queue1_AnonymousAccess_AllActions_WhitelistIP",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "sqs:*",
      "Resource": "arn:aws:sqs:*:111122223333:queue1",
      "Condition" : {
        "IpAddress" : {
          "aws:SourceIp":"192.168.143.0/24"
        }
      }
    }
  ]
}

Example 8: Whitelist and Blacklist Permissions for Users in Different CIDR Ranges

The following example policy has two statements:

  • The first statement grants all users in the 192.168.143.0/24 CIDR range (except for 192.168.143.188) permission to use the SendMessage action for the queue named 111122223333/queue1.

  • The second statement blacklists all users in the 10.1.2.0/24 CIDR range from using the queue.

{
  "Version": "2012-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement": [
    {
      "Sid":"Queue1_AnonymousAccess_SendMessage_IPLimit",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:*:111122223333:queue1",
      "Condition" : {
        "IpAddress" : {
          "aws:SourceIp":"192.168.143.0/24"
        },
        "NotIpAddress" : {
          "aws:SourceIp":"192.168.143.188/32"
        }
      }
    },
    {
      "Sid":"Queue1_AnonymousAccess_AllActions_IPLimit_Deny",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "sqs:*",
      "Resource": "arn:aws:sqs:*:111122223333:queue1",
      "Condition" : {
        "IpAddress" : {
          "aws:SourceIp":"10.1.2.0/24"
        }
      }
    }
  ]
}