Cloud Parts

Amazon SQS

AWS’s fully managed message queue: no brokers to run, billed per request.

What it is
Message queues
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
5 October 2026
Website

What it is

An SQS queue is an HTTPS endpoint with three main calls: SendMessage, ReceiveMessage and DeleteMessage. There are no brokers, partitions or capacity to size. A received message is hidden for the visibility timeout (30 seconds by default, up to 12 hours); if the consumer doesn’t delete it in time, it becomes visible again for another worker. After a set number of receives, a redrive policy moves it to a dead-letter queue. Messages are kept for 4 days by default and up to 14 days, and each can be up to 1 MiB.

Standard queues have nearly unlimited throughput but deliver at least once and only roughly in order. FIFO queues, whose names end in .fifo, keep strict order within each message group and drop duplicate sends within a five-minute window. They allow 300 API calls per second per partition (3,000 messages with batches of 10), or far more in high-throughput mode.

Why teams pick it

  • Nothing to operate: queues scale from idle to very high throughput, and you pay per request
  • Dead-letter queues, per-message delays of up to 15 minutes and long polling of up to 20 seconds are built in
  • Lambda can poll a queue for you and scale the number of consumers with the backlog
  • Fair queues: tag messages in a standard queue with a MessageGroupId per tenant, and one noisy tenant no longer delays the others

Watch out for

  • Standard queues can deliver a message twice, so consumers must be idempotent
  • A deleted message is gone: no replay, and at most 14 days of retention
  • Each message goes to one consumer; fanning out to several needs SNS or EventBridge in front
  • Payloads over 1 MiB must go to S3, with only a pointer in the message

Alternatives

What all message queues have in common →
BullMQOpen sourceThe Node.js job queue on Redis, Bull’s successor, with ports to other languages and, since v6, a Postgres backend.Cloudflare QueuesCommercialA message queue built into Cloudflare Workers: Workers send messages through a binding, and Queues delivers them in batches to a consumer Worker or to any HTTP client that pulls them, at least once.pgmqOpen sourceAn SQS-style message queue made of SQL functions and tables inside Postgres.PgQueOpen sourceSkype’s PgQ engine repackaged as one SQL file: a zero-bloat event log inside any Postgres 14+.PgQueuerOpen sourceA Python background-job library that uses Postgres as the broker: `SKIP LOCKED` to claim, LISTEN/NOTIFY to wake.RabbitMQOpen sourceA widely used open-source message broker that routes messages to queues through exchanges.

How it fits with other technologies

What uses Amazon SQS

Create a queue, send a job, then receive and delete it · bash

aws sqs create-queue --queue-name thumbnails \
  --attributes VisibilityTimeout=120,MessageRetentionPeriod=1209600
QUEUE_URL=$(aws sqs get-queue-url --queue-name thumbnails --query QueueUrl --output text)

aws sqs send-message --queue-url "$QUEUE_URL" \
  --message-body '{"image": "s3://acme-uploads/cat.jpg"}'

# long-poll for up to 20 s; each message stays hidden for 120 s
aws sqs receive-message --queue-url "$QUEUE_URL" \
  --wait-time-seconds 20 --max-number-of-messages 10

# delete it once the work is done, or it comes back
aws sqs delete-message --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE"

See it in a real stack

CQRS with a static read side →
Live model
What you’re watchingCommands pass API Gateway to a Lambda handler that writes PostgreSQL; each change’s event waits in SQS until the projector function renders the two JSON files it affects into S3. Shoppers load product and category pages from CloudFront, mostly as cache hits, and misses read the file from S3. No read touches PostgreSQL.
Background jobs with a queueThe API drops slow work onto SQS and returns at once; a pool of Fargate workers drains the queue at a steady pace.AWS LambdaAmazon SQSAWS FargateAmazon S3

Worth exploring

Article· August 2025lambda to eks pod migrationAWS re:Post community questionA short Q&A on what replaces Lambda’s built-in triggers, SQS polling and scaling when functions move to EKS pods. The useful answer points to KEDA (with Karpenter) for scaling pods on queue depth; the longer answer is an unreviewed AI-generated checklist from AWS’s own assistant, so treat it as a starting list, not guidance.
Article· May 2021Spice up Your Kubernetes Environment with AWS LambdaLiav Yona, MediumShows how a Lambda function triggered by SQS or SNS can forward events to an internal (ClusterIP) service in EKS through the Kubernetes API server’s service proxy, using IAM-to-RBAC mapping instead of exposing an endpoint, with code on GitHub. A clever pattern, but written for 2021-era EKS: it maps the IAM role through the aws-auth ConfigMap, and it routes application traffic through the cluster’s control plane.
All resources →
Where it came from2004–2025

In 2002 the whole Amazon.com website still ran as a single program that took 45 minutes to link after each change, and Amazon was splitting it into separate services. Services that called each other directly failed together: if one was slow or down, every caller stalled. As AWS later put it, Amazon had “learned firsthand that distributed systems need a reliable way to pass messages between components without creating tight dependencies.” Maxim Fateev’s team (he later co-founded Temporal) built the internal messaging that grew into SQS.

Amazon offered that queue to outside developers before almost anything else. SQS opened for beta testing in November 2004, more than a year before S3, which makes it the first AWS infrastructure service, and became generally available in July 2006 as one of AWS’s first three services, with S3 and EC2. Messages could be 8 KB, and you paid for what you sent. Behind the small API, SQS keeps three copies of each message, spread across Availability Zones.

SQS set the template for cloud messaging: no broker to install or size, billing per request, and an API any program can call over HTTPS. The same basic calls carried a record 47.7 million messages per second during Prime Day 2021.

Why it’s built this way

Three calls over HTTP: send, receive, delete
Any program that could make a web request could use a queue, with no client library, broker protocol or server to run.
A visibility timeout instead of locks or sessions
A received message is only hidden until the consumer deletes it. If a worker crashes, the message reappears for another worker, so the service never has to track which consumers are alive.
At-least-once, roughly ordered delivery in standard queues
Keeping several copies of each message on many servers keeps queues available through failures, but means a message can occasionally arrive twice or out of order. Strict order and deduplication came later as a separate FIFO queue type with lower throughput.
Delete on success, no history
A queue exists to move work, not to store it, so a processed message is gone. That keeps the model simple; fan-out and replay are left to SNS, EventBridge and Kinesis.

Timeline

  1. 2004

    Beta opens in November, the first AWS infrastructure service

  2. 2006

    Generally available in July, with messages of up to 8 KB

  3. 2014

    Dead-letter queues catch messages that keep failing

  4. 2016

    FIFO queues add strict ordering and deduplication

  5. 2018

    Lambda can consume SQS queues directly

  6. 2021

    High-throughput mode for FIFO queues

  7. 2025

    Fair queues for multi-tenant workloads; messages grow to 1 MiB

Sources12 · facts checked 5 October 2026

Improve this page on GitHub