Skip to main content

What Is Amazon SQS? Queue Types and Message Operations

Tags:

When components in an application communicate directly, there's a risk of data loss if either side goes down. Amazon SQS provides a queue that temporarily holds messages, enabling loose coupling between components. This post covers the basics of SQS — from core concepts to creating queues and sending and receiving messages.

What Is Amazon SQS?

SQS (Simple Queue Service) is a fully managed message queuing service provided by AWS. Producers send messages to a queue, and consumers pull messages from it — allowing components to communicate asynchronously without direct connections.

Because the queue acts as a buffer, messages aren't lost even if the consumer goes down temporarily. You can also scale throughput by running multiple consumers in parallel.

Key Features

SQS has several characteristics unique to managed services. Let's take a look at each one.

FeatureDescription
Fully managedAWS handles infrastructure management and redundancy, reducing operational overhead
High availabilityMessages are automatically replicated across multiple Availability Zones, eliminating single points of failure
Unlimited throughputStandard queues support nearly unlimited messages per second (TPS)
Flexible retentionMessage retention can be set from 1 minute to 14 days (default: 4 days)
Pay-as-you-goCharged based on the number of messages sent and received, with 1 million requests free per month

Once a message is received, it becomes invisible to other consumers for a period called the visibility timeout. If the consumer doesn't delete the message after processing, it becomes available again after the timeout — be aware that this can lead to reprocessing.

SQS is often compared to Amazon SNS, but the two serve different roles. SNS is a pub/sub service that delivers messages to multiple subscribers, while SQS is a queuing service that temporarily holds messages. A common pattern combines the two — fanning out from an SNS topic to multiple SQS queues.

SQS can also serve as a Lambda event source: when a message arrives in the queue, it automatically invokes a Lambda function. This removes the need to implement your own polling logic, making it a natural fit for serverless architectures.

Queue Types

SQS offers two queue types: standard and FIFO. Choose the one that fits your use case.

Standard QueueFIFO Queue
ThroughputNearly unlimitedUp to 3,000 TPS (with batching)
Message orderingBest-effort (not guaranteed)Strictly preserves FIFO order
Duplicate deliveryOccasionally possibleNo duplicates
Use casesLog aggregation, notifications, bulk processingOrder processing, payments, inventory updates

Standard queues prioritize throughput, so message ordering isn't guaranteed and the same message may occasionally be delivered more than once. Design your consumers to be idempotent (producing the same result when processing a message multiple times) to handle this safely.

FIFO queues guarantee message ordering and deduplication, but come with throughput limits. Queue names must end with .fifo.

Dead-Letter Queues

A dead-letter queue (DLQ) is a mechanism that moves messages to a separate queue when they repeatedly fail to be processed.

When a consumer fails to process a message and doesn't delete it, the message becomes available again after the visibility timeout. If it exceeds the configured maximum receive count (maxReceiveCount), it's automatically moved to the DLQ. Inspecting and reprocessing DLQ messages makes it easier to track problematic ones.

The SQS console also provides a "DLQ Redrive" feature to move messages from the DLQ back to the original queue.

Message Attributes and Size Limits

Besides the message body, SQS lets you attach message attributes — key-value pairs carrying metadata such as sender information or details needed for processing. A single message can have up to 10 attributes. Since consumers can route messages based on attributes alone without parsing the body, this is useful when you need to branch processing by message type.

There's also a limit on message body size: a message can be at most 1,048,576 bytes (1 MiB). If you need to handle larger payloads, a common pattern is to store the actual data in S3 and include only a reference to the S3 object in the message body. This is supported natively via the Amazon SQS Extended Client Library, which is useful when working with messages larger than 1 MiB.

Try SQS with the AWS CLI

Let's walk through the basic flow using the AWS CLI — from creating a queue to sending, receiving, and deleting messages.

Create a Queue

Start by creating a standard queue. Specify the queue name with --queue-name.

❯ aws sqs create-queue --queue-name exrecord-queue
{
"QueueUrl": "https://sqs.us-east-1.amazonaws.com/123456789012/exrecord-queue"
}

Save the URL to a variable for use in subsequent commands.

QUEUE_URL="https://sqs.us-east-1.amazonaws.com/123456789012/exrecord-queue"

You can list all queues already created in your account with the following command.

❯ aws sqs list-queues
{
"QueueUrls": [
"https://sqs.us-east-1.amazonaws.com/123456789012/exrecord-queue"
]
}

Send a Message

Send a message to the queue. Specify the message content as a string with --message-body.

❯ aws sqs send-message \
--queue-url "$QUEUE_URL" \
--message-body 'This is a test message from SQS.'
{
"MD5OfMessageBody": "4b999f2b9ac63a0e8c4a2bea7ae2e12b",
"MessageId": "ca0330b3-c5e5-44d3-85a4-4062ef5dd0f5"
}

Receive a Message

Retrieve a message from the queue. The received message becomes invisible to other consumers for the duration of the visibility timeout.

❯ aws sqs receive-message --queue-url "$QUEUE_URL"
{
"Messages": [
{
"MessageId": "ca0330b3-c5e5-44d3-85a4-4062ef5dd0f5",
"ReceiptHandle": "AQEBwJnKyrHigUMZj...",
"MD5OfBody": "4b999f2b9ac63a0e8c4a2bea7ae2e12b",
"Body": "This is a test message from SQS."
}
]
}

If you call receive-message while no message has arrived yet, it returns an empty response immediately. To avoid this, enable long polling with --wait-time-seconds, which waits up to the specified number of seconds for a message to arrive before responding, reducing the number of wasted requests.

❯ aws sqs receive-message --queue-url "$QUEUE_URL" --wait-time-seconds 10

Delete a Message

Once processing is complete, delete the message from the queue. If you don't delete it, it will be redelivered after the visibility timeout expires.

❯ aws sqs delete-message \
--queue-url "$QUEUE_URL" \
--receipt-handle "AQEBwJnKyrHigUMZj..."

Check Queue Attributes

To check a queue's current settings and state, use get-queue-attributes. Passing --attribute-names All returns everything at once, including the visibility timeout, message retention period, and the approximate number of messages in the queue.

❯ aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names All
{
"Attributes": {
"ApproximateNumberOfMessages": "0",
"VisibilityTimeout": "30",
"MaximumMessageSize": "1048576",
"MessageRetentionPeriod": "345600"
}
}

If you want to check whether unprocessed messages are piling up, keep an eye on the ApproximateNumberOfMessages value.

Delete the Queue

Delete the queue when it's no longer needed. All messages in the queue will also be deleted, so confirm that processing is complete beforehand.

❯ aws sqs delete-queue --queue-url "$QUEUE_URL"

Summary

This article covered the basics of Amazon SQS, queue types, and basic operations using the AWS CLI. Since SQS makes the connections between components more flexible and improves the availability of your system as a whole, keep the following points in mind as you bring it into the parts of your architecture that need asynchronous processing.

  • Amazon SQS is a fully managed message queuing service that loosely couples application components
  • Standard queues offer nearly unlimited throughput; FIFO queues provide ordering guarantees and deduplication
  • During the visibility timeout, a message is hidden from other consumers
  • Messages that repeatedly fail processing can be moved to a dead-letter queue for easier tracking and reprocessing
  • Message bodies are limited to 1 MiB; if you need more, consider combining SQS with S3
  • Long polling reduces wasted requests, so it's worth enabling in your consumer implementation