Amazon SQS Turns 20: Two Decades of Reliable Messaging at Scale

Amazon Simple Queue Service (Amazon SQS) launched on July 13, 2006, as one of the first three services available to AWS customers, alongside Amazon EC2 and Amazon S3. The launch responded directly to a problem observed in operating distributed systems: when one component invokes another through a direct, synchronous call, the caller remains blocked until the callee responds. If the callee is slow, degraded, or unavailable, the caller's downstream work stalls, and the failure propagates upstream. In a system with many interdependent services, these point-to-point dependencies allow a single failing component to cascade into whole-system outages.

Message queuing breaks that coupling. Instead of calling a service directly, a producer writes a message to a queue and moves on. A consumer retrieves the message when it is ready to handle it. The producer does not wait for the consumer, and the consumer does not need to be available at the exact moment the message is sent. The queue acts as a reliable buffer between the two, absorbing differences in latency and availability.

Consider an order-processing system. Without a queue:

• The front-end service calls the payment service synchronously and waits for a response.
• If the payment service is slow, the front-end thread blocks, and request throughput drops.
• If the payment service is unavailable, the front-end returns errors to users, and retries amplify load on the failing service.

With a queue, the front-end writes an order message and returns immediately. The payment service consumes messages at its own pace; if it fails, messages remain in the queue and are processed after recovery. Individual component failures no longer take down the rest of the system.

This decoupling pattern, introduced by SQS in 2006, remains the core reason customers use the service. Scaling limits, encryption defaults, and redrive capabilities have evolved substantially, but the fundamental model of asynchronous, queue-based communication has not shifted.

The primary architectural utility of message queuing remains the decoupling of service components. In a synchronous distributed system, a direct request between services creates a tight dependency; if the downstream service is unresponsive or experiencing latency, the failure propagates upstream, potentially exhausting resources or causing cascading outages. By implementing a message queue as a mediator, the system transforms into an asynchronous architecture.

In this pattern, a producer process transmits a message to a queue and immediately returns to its own execution path, agnostic of the consumer's state. The message persists in the queue until a consumer is prepared to retrieve and process it. This decoupling provides several operational advantages for enterprise systems:

• Load Leveling: Queues act as a buffer, smoothing out traffic spikes. During periods of intense demand, the queue absorbs requests, allowing consumers to process messages at their maximum sustainable rate without being overwhelmed.
• Fault Tolerance: If a consumer component fails, the message remains safely in the queue. Because producers and consumers operate independently, system integrity is maintained even if specific components are taken offline for maintenance or due to unexpected errors.
• Asynchronous Processing: Tasks that do not require an immediate response—such as image processing, generating reports, or coordinating AI agent workflows—can be offloaded, reducing end-to-end latency for the primary user request.

This pattern is now frequently applied to modern, resource-intensive workloads, such as managing throughput for large language model (LLM) inference or orchestrating communication between autonomous AI agents. By placing a queue between an AI service request and the inference engine, developers can control concurrency and prevent service-level saturation. Whether handling simple background jobs or complex distributed AI orchestration, the core mechanism—placing a message into a durable queue to be processed at the consumer's pace—remains the fundamental strategy for building resilient, scalable enterprise software.

Between 2021 and 2026, Amazon SQS made substantial changes to its throughput ceilings, payload limits, concurrency allowances, and wire protocol. These changes affect capacity planning, consumer concurrency, and latency-sensitive integration design.

High throughput mode for FIFO queues launched in May 2021 at 3,000 transactions per second (TPS) per API action, a tenfold increase over the prior FIFO limit. AWS subsequently raised the ceiling: 6,000 TPS in October 2022, 9,000 TPS in August 2023, 18,000 TPS in October 2023, and 70,000 TPS in select Regions by November 2023. TPS is measured per API action, meaning operations such as SendMessage, ReceiveMessage, and DeleteMessage each count separately. A workload previously capped at 300 TPS for sends could, after migrating to high throughput mode, issue 3,000 SendMessage calls per second.

In 2024, the in-flight message limit for FIFO queues increased from 20,000 to 120,000 messages. In-flight messages are those received by a consumer but not yet deleted after processing. This increase allows more consumers or higher per-consumer concurrency before hitting the receive-side limit. For example, a fleet of 1,200 consumers can each hold 100 in-flight messages without exhausting the queue.

In 2023, AWS added support for the JSON protocol in the AWS SDK. For a 5 KB payload, this reduced end-to-end message processing latency by up to 23% while also lowering client-side CPU and memory usage. The JSON protocol replaces the earlier query-based protocol with a more compact serialization format, reducing bandwidth and parse overhead.

In 2025, SQS increased the maximum message payload from 256 KiB to 1 MiB for both standard and FIFO queues. AWS Lambda event source mappings were updated in parallel to support the larger payload. This reduces the need to offload payloads to Amazon S3 for messages between 256 KiB and 1 MiB, though the Extended Client Library remains relevant for payloads up to 2 GB.

When planning new workloads, consider matching your concurrency model to the current in-flight limit and using high throughput mode for FIFO queues that require sustained send/receive rates. For latency-sensitive integrations, test the JSON protocol with representative payload sizes. For payloads above 256 KiB, evaluate whether direct 1 MiB delivery or S3-backed storage better satisfies durability and consumer memory constraints.

Server-side encryption with Amazon SQS-managed encryption keys (SSE-SQS) was introduced in November 2021 as a built-in encryption layer that removes key-management overhead entirely. When enabled, SQS encrypts message bodies at rest using keys that the service creates, stores, and rotates on the customer's behalf. This differs from SSE-KMS, where each queue references a customer-managed AWS KMS key, requiring separate key policies, grants, and per-request KMS API calls. SSE-SQS offers equivalent protection at rest without those dependencies. In October 2022, SSE-SQS became the default for all newly created queues, meaning a queue provisioned without explicit encryption configuration is no longer stored in plaintext. The default does not prevent customers from choosing SSE-KMS when they need dedicated key control; it simply makes unencrypted queues an intentional, non-default decision.

Attribute-based access control (ABAC) became available in November 2022. Traditional IAM policies for SQS are resource-based: each policy statement enumerates the queue ARNs it applies to, so granting access to a new queue requires a policy update. ABAC replaces this model with tag-based conditions. A single policy can allow actions on any queue whose tag set matches the principal's tag set, evaluated dynamically at request time. For example, a policy can grant sqs:SendMessage when the queue tag environment equals the caller's environment tag, and data-classification equals pii. As queues scale to hundreds or thousands, no policy edits are needed for each new resource, provided tagging conventions are enforced at creation time.

• Encryption posture: Treat SSE-SQS as the baseline for new queues. Reserve SSE-KMS for workloads with explicit key rotation, audit, or separate-permission requirements.
• ABAC design: Define a strict tag schema (e.g., environment, team, data-classification) before rollout, and enforce it through infrastructure-as-code validation or service control policies.
• Policy consolidation: Use one ABAC policy per action set across many queues instead of maintaining per-queue resource policies.
• Audit note: Tags are mutable metadata; verify write access to tags is restricted to authorized roles so permission boundaries cannot be altered indirectly.

For enterprise adoption, rely on the SSE-SQS default to establish consistent encryption at rest, and adopt ABAC where queue counts make static policy maintenance impractical. Both features reduce the operational surface of security configuration, shifting the focus from per-resource setup to organization-wide tagging and key-governance standards.

Dead-letter queues (DLQs) act as safety buffers for messages that cannot be processed successfully, preventing poison-pill messages from blocking consumer progress. Operational maturity in managing these queues has evolved from manual inspection to automated, API-driven lifecycle management.

For programmatic control, the message move task APIs enable engineers to integrate error recovery directly into monitoring workflows:

• StartMessageMoveTask: Initiates the transfer of messages from a DLQ back to the source queue or a custom destination.
• CancelMessageMoveTask: Stops an active redrive operation if conditions change.
• ListMessageMoveTasks: Provides visibility into the status of ongoing or historical move operations.

These capabilities, which now include support for FIFO queues, allow for precise control over unconsumed message handling. Engineers can now orchestrate redrive tasks using standard SDKs or CLI tools rather than relying on console-based manual intervention.

Beyond redrive mechanics, architectural integration has been simplified through the Amazon EventBridge Pipes console integration. This feature enables routing SQS messages to downstream AWS services without the overhead of maintaining custom integration code or polling consumers. For example, messages can be pushed directly to a target service by defining pipes in the console, offloading the ingestion and routing logic from the compute layer.

For applications requiring large data payloads, the Extended Client Library for Python facilitates the management of messages exceeding standard limits. By leveraging Amazon S3 for storage, this library handles the orchestration of payload offloading: it saves the message body to an S3 bucket and transmits only the reference pointer through SQS. This mechanism enables the transmission of payloads up to 2 GB, allowing engineers to bypass message size constraints while maintaining the decoupling benefits of the queuing architecture.

The decoupling pattern that defined Amazon Simple Queue Service (SQS) at launch remains the core architectural principle for asynchronous workloads. In an AI context, the producer is a client or orchestration layer submitting prompts; the consumer is a worker that invokes a large language model (LLM). Because model inference latency is variable and throughput is often rate-limited, direct synchronous calls create tight coupling: a slow or saturated model backend can block the entire caller. SQS eliminates that dependency by buffering requests and letting consumers pull work at a sustainable rate.

Buffering also addresses inference throughput management. A queue decouples the rate at which requests arrive from the rate at which the model endpoint can process them. For larger payloads, SQS supports a 1 MiB maximum message payload, while the Extended Client Library for Python stores messages up to 2 GB in Amazon S3 and passes only a reference through the queue. Practical applications include:

• Buffering prompt submissions to an LLM so bursts of user traffic do not overwhelm the inference endpoint.
• Controlling consumer concurrency to match the model endpoint's throughput limits.
• Using FIFO queues to preserve order in agent workflows where message sequence matters.
• Connecting queues to downstream AWS services through EventBridge Pipes without custom integration code.

Autonomous AI agents operating as independent services require coordination without synchronous coupling. Each agent can act as a producer, emitting messages that represent tasks, observations, or outcomes, while other agents consume and respond asynchronously. This supports long-running, multi-step processes where individual agents may be slow or temporarily unavailable. The AWS architecture pattern "Creating asynchronous AI agents with Amazon Bedrock" demonstrates this approach in practice, using SQS to pass work between agents and the Bedrock runtime.

Operational controls have matured accordingly. Server-side encryption with SQS-managed keys is a default for newly created queues; attribute-based access control lets permissions follow queue tags as resources scale; and fair queues use message group IDs to prevent a single tenant in a multi-tenant standard queue from delaying delivery for others. Dead-letter queue redrive enables operators to recover unconsumed messages after downstream failures are resolved.

The constant underneath all change remains: SQS is a simple, reliable messaging service at any scale.