Amazon Simple Queue Service (Amazon SQS) is a web service that gives you access to message queues that store messages waiting to be processed. With Amazon SQS, you can quickly build message queuing applications that can run on any computer.

Amazon SQS offers a reliable, secure, and highly-scalable hosted queuing service for storing messages in transit between computers. With Amazon SQS, you can move data between diverse, distributed application components without losing messages and without requiring each component to be always available. You can exchange sensitive data between applications using Amazon SQS server-side encryption (SSE) integrated with the AWS Key Management Service (KMS).

Amazon SQS can help you build a distributed application with decoupled components, working closely with the Amazon Elastic Compute Cloud (Amazon EC2) and other AWS infrastructure web services.

Amazon SQS offers two queue types for different application requirements:

Standard Queues
Amazon SQS offers standard as the default queue type. A standard queue lets you have a nearly-unlimited number of transactions per second. Standard queues guarantee that a message is delivered at least once. However, occasionally (because of the highly-distributed architecture that allows high throughput), more than one copy of a message might be delivered out of order. Standard queues provide best-effort ordering which ensures that messages are generally delivered in the same order as they are sent.

FIFO Queues - New!
The FIFO queue complements the standard queue. The most important features of this queue type are FIFO (first-in-first-out) delivery and exactly-once processing: the order in which messages are sent and received is strictly preserved and a message is delivered once and remains available until a consumer processes and deletes it; duplicates are not introduced into the queue. FIFO queues also support message groups that allow multiple ordered streams within a single queue. FIFO queues are limited to 300 transactions per second (TPS) per API action, but have all the capabilities of standard queues.


Get Started with AWS for Free

Create a Free Account
Or Sign In to the Console

AWS Free Tier includes 1 million requests with Amazon Simple Queue Service (SQS).

View AWS Free Tier Details »

Capital One shares how they are using Amazon SQS to migrate core banking applications to the cloud.


Amazon SQS can be easily accessed through the AWS Management Console, which gives users a point-and-click, web-based interface to setup and manage Amazon SQS.

Amazon SQS employs a simple interface that is easy to use and highly flexible. The following requests are provided:

Basic Message Operations

  • SendMessage: Send messages to a specified queue.
  • ReceiveMessage: Return one or more messages from a specified queue.
  • DeleteMessage: Remove a previously received message from a specified queue.
  • ChangeMessageVisibility: Change the visibility timeout of a previously received message.

Batch Message Operations

  • SendMessageBatch: Send multiple messages to a specified queue.
  • DeleteMessageBatch: Remove multiple previously received messages from a specified queue.
  • ChangeMessageVisibilityBatch: Change the visibility timeout of multiple previously received messages.

Basic Queue Management

  • CreateQueue: Create queues for use with your AWS account.
  • ListQueues: List your existing queues.
  • DeleteQueue: Delete one of your queues.
  • PurgeQueue: Delete all the messages in a queue.

Advanced Queue Management

  • SetQueueAttributes: Control queue settings such as the visibility timeout (amount of time that messages are locked after being read so they cannot be read again), a delay value, or dead letter queue parameters.
  • GetQueueAttributes: Get information about a queue such as the visibility timeout, number of messages in the queue, or the maximum message size.
  • GetQueueUrl: Get the queue URL.
  • AddPermission: Add queue sharing for another AWS account for a specified queue.
  • RemovePermission: Remove an AWS account from queue sharing for a specified queue.
  • ListDeadLetterSourceQueues: List the queues attached to a dead letter queue.

For more details, refer to the Amazon SQS API Reference.

Messages that are stored in Amazon SQS have a lifecycle that is easy to manage but ensures that all messages are processed.

  1. A system that needs to send a message will select an Amazon SQS queue, and use SendMessage to send a new message to it.
  2. A different system that processes messages needs more messages to process, so it calls ReceiveMessage, and this message is returned.
  3. Once a message has been returned by ReceiveMessage, it will not be returned by any other ReceiveMessage until the visibility timeout has passed. This keeps multiple consumers from processing the same message at once.
  4. If the system that processes messages successfully finishes working with this message, it calls DeleteMessage, which removes the message from the queue so no one else will ever process it. If this system fails to process the message, then it will be read by another ReceiveMessage call as soon as the visibility timeout passes.
  5. If you have associated a Dead Letter Queue with a source queue, messages will be moved to the Dead Letter Queue after the maximum number of delivery attempts you specify have been reached.
  • Developers can create any number of Amazon SQS queues with an unlimited number of messages.
    • A queue can be created in any region.
    • The message payload can contain up to 256KB of text in any format. Each 64KB ‘chunk’ of payload is billed as 1 request. For example, a single API call with a 256KB payload will be billed as four requests.
    • Messages can be sent, received or deleted in batches of up to 10 messages or 256KB. Batches cost the same amount as single messages, meaning SQS can be even more cost effective for customers that use batching.
    • To send messages larger than 256KB, you can use the Amazon SQS Extended Client Library for Java, which uses Amazon S3 to store the message payload.  A reference to the message payload is sent using SQS.
    • Long polling reduces extraneous polling to help you minimize cost while receiving new messages as quickly as possible. When your queue is empty, long-poll requests wait up to 20 seconds for the next message to arrive. Long poll requests cost the same amount as regular requests.
    • Messages can be retained in queues for up to 14 days.
    • Messages can be sent and read simultaneously.
  • When a message is received, it becomes “locked” while being processed. This keeps other computers from processing the message simultaneously. If the message processing fails, the lock will expire and the message will be available again. In the case where the application needs more time for processing, the “lock” timeout can be changed dynamically via the ChangeMessageVisibility operation.
  • Developers can securely share Amazon SQS queues anonymously or with specific AWS accounts. Queue sharing can also be restricted by IP address and time-of-day.
  • NEW! Server-side encryption (SSE) protects the contents of messages in Amazon SQS queues using keys managed in the AWS Key Management Service (AWS KMS). SSE encrypts messages as soon as Amazon SQS receives them. The messages are stored in encrypted form and Amazon SQS decrypts messages only when they are sent to an authorized consumer.
  • When combined with Amazon Simple Notification Service (SNS), developers can 'fanout' identical messages to multiple standard SQS queues. With fanout, a message published to an SNS topic is distributed to a number of SQS standard queues in parallel.  Using fanout, developers can build applications that take advantage of parallel, asynchronous processing.  For example, developers could publish a message to a topic every time a new image is uploaded.  Independent processes, each reading from a separate queue, could generate thumbnails, perform image recognition, and store metadata about the image. SNS does not currently support FIFO ordering, and as such fanout to FIFO queues is not supported.
  • Developers can handle stuck messages (messages that have not been successfully processed by a consumer) with Dead Letter Queues. When the maximum receive count is exceeded for a message it will be moved to the Dead Letter Queue (DLQ) associated with the original queue. Developers can setup separate consumer processes for DLQs which can help analyze and understand why messages are getting stuck. DLQs must be of the same type as the source queue (standard or FIFO).

Amazon SQS message queuing can be used with other AWS Services such as Redshift, DynamoDB, RDS, EC2, ECS, Lambda, and S3, to make distributed applications more scalable and reliable. Below are some common design patterns:

  • Work Queues: Decouple components of a distributed application that may not all process the same amount of work simultaneously.
  • Buffer and Batch Operations: Add scalability and reliability to your architecture, and smooth out temporary volume spikes without losing messages or increasing latency.
  • Request Offloading: Move slow operations off of interactive request paths by enqueing the request.
  • Fanout: Combine SQS with Simple Notification Service (SNS) to send identical copies of a message to multiple queues in parallel.
  • Priority: Use separate queues to provide prioritization of work.
  • Scalability: Because message queues decouple your processes, it’s easy to scale up the send or receive rate of messages - simply add another process. 
  • Resiliency: When part of your system fails, it doesn’t need to take the entire system down. Message queues decouple components of your system, so if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers.

Your use of this service is subject to the Amazon Web Services Customer Agreement.