Amazon SQS includes methods to share your queues so others can use them, using permissions set in an access control policy. A permission gives access to another user to use your queue in some particular way. A policy is the actual document that contains the permissions you've granted.
Amazon SQS offers two methods for setting a policy: a simple API and an advanced API. In the simple API, Amazon SQS generates an access control policy for you. In the advanced API, you create the access control policy.
Simple API for Shared Queues
The simple API for sharing a queue has two operations:
With the simple API, Amazon SQS writes the policy in the required language for you based on
the information you include in the
AddPermission operation. However, the
policy that Amazon SQS generates is limited in scope. You can grant permissions to
principals, but you can't specify restrictions.
Advanced API for Shared Queues
With the advanced API, you write the policy yourself directly in the access policy language
and upload the policy with the
operation. The advanced API allows you to deny access or to apply finer access
restrictions (for example, based on time or based on IP address).
If you choose to write your own policies, you need to understand how policies are structured. For complete reference information about policies, see Creating Custom Policies Using the Access Policy Language. For examples of policies, see Access Policy Examples.
Understanding Resource-Level Permissions
A permission is the type of access you give to a principal (the user
receiving the permission). You give each permission a label that identifies that
permission. If you want to delete that permission in the future, you use that
label to identify the permission. If you want to see what permissions are on a
queue, use the
GetQueueAttributes operation. Amazon SQS returns the entire
policy (containing all the permissions). Amazon SQS supports the permission types
shown in the following table.
To allow anonymous access, you must write your own policy.
|This permission type grants the following actions to a principal on a shared queue: change a message's visibility, delete messages, get a queue's attributes, get a queue's URL, receive messages, and send messages.|
|This grants permission to extend or terminate the read lock timeout
of a specified message. |
|This grants permission to delete messages from the queue.
|This grants permission to get all of the queue attributes except the policy, which can
only be accessed by the queue's owner. For more information, see the
|This grants permission to get a queue's URL. For more information, see the |
|This grants permission to receive messages in the queue. For more information, see the
|This grants permission to send messages to the queue. |
Setting permissions for
ChangeMessageVisibility also sets permissions for the corresponding
batch versions of those actions:
Setting permissions explicitly on
Permissions for each of the different permission types are considered separate permissions by
Amazon SQS, even though
* includes the access provided by the other
permission types. For example, it's possible to grant both
SendMessage permissions to a user, even though a
includes the access provided by
This concept applies when you remove a permission. If a principal has only a
* permission, requesting to remove a
permission does not leave the principal with an "everything but" permission. Instead, the
request does nothing, because the principal did not previously possess an explicit
If you want to remove
* and leave the principal with just the
ReceiveMessage permission, first add the
then remove the
You give each permission a label that identifies that permission. If you want to delete that permission in the future, you use that label to identify the permission.
If you want to see what permissions are on a queue, use the
GetQueueAttributes operation. The entire policy (containing all
the permissions) is returned.
Granting Anonymous Access to a Queue
You can allow shared queue access to anonymous users. Such access requires no signature or Access Key ID.
To allow anonymous access you must write your own policy, setting the
*. For information about writing your own policies, see Creating Custom Policies Using the Access Policy Language.
Keep in mind that the queue owner is responsible for all costs related to the queue. Therefore you probably want to limit anonymous access in some other way (by time or IP address, for example).