Standard Queues
Nearly unlimited throughput, best-effort ordering, at-least-once delivery.
The default SQS queue type. Use it when you need maximum throughput and can tolerate duplicates and out-of-order messages.
What it is
Standard queues are the default Amazon SQS queue type. They offer maximum throughput, best-effort ordering, and at-least-once delivery — copies of messages are stored on multiple servers for redundancy and high availability.
At-least-once delivery
Amazon SQS stores copies of your messages on multiple servers. On rare occasions, a server storing a copy might be unavailable when you receive or delete a message. If that happens, you might receive that message copy again on a later receive.
- Design applications to be idempotent — processing the same message twice must not cause incorrect side effects.
- Duplicates can occur even without consumer failures due to distributed storage.
Best-effort ordering
Messages are generally delivered in the order they are sent, but ordering is not guaranteed. Under high load or when servers are unavailable, messages may arrive out of order.
- If two messages have a strict dependency, encode that dependency in your application logic.
- Do not rely on SQS alone to enforce cross-message ordering for standard queues.
Throughput and scale
Standard queues support a nearly unlimited number of transactions per second per API action (SendMessage, ReceiveMessage, DeleteMessage). SQS scales transparently without provisioning.
- No practical TPS ceiling for most workloads.
- In-flight message limit: ~120,000 messages (varies with traffic).
When to choose standard over FIFO
Choose standard queues when throughput matters more than strict ordering, when duplicates are acceptable with idempotent consumers, or when you need per-message delay timers.
- Background job processing, email queues, log ingestion.
- Fan-out via SNS where each subscriber has its own standard queue.
- !Duplicates can occur even without failures — design every consumer to be idempotent.
- !Don't assume FIFO ordering. If two messages depend on each other, model the dependency explicitly.
- !Short polling can return empty responses even when messages exist — use long polling instead.