On July 13, 2006, Amazon Simple Queue Service (SQS) launched as one of the first three AWS services, alongside EC2 and S3. We had learned from experience that distributed systems require a dependable way to pass messages between components without creating rigid dependencies. A direct call to a slow or failed service could cascade failures; message queuing solved this by enabling asynchronous communication. Producers could drop a message into a queue and proceed, while consumers retrieved it when ready—isolating individual service failures from the rest of the system.
When Amazon SQS became publicly available that day, it made this pattern accessible to every AWS customer. Two decades later, the core purpose—decoupling producers from consumers—remains the reason customers choose SQS. What has changed dramatically is the scale, performance, and operational controls surrounding it.
Jeff Barr covered the first 15 years of SQS milestones in his 15th anniversary post, from the original 8 KB message limit in 2006 through FIFO queues, server-side encryption, and Lambda integration. Over the last five years, we’ve continued to scale SQS, tighten security defaults, and introduce capabilities for increasingly complex workload patterns.
Key milestones between 2021 and 2026
High throughput mode for FIFO queues (2021): In May 2021, we made high throughput mode generally available for FIFO queues, supporting up to 3,000 transactions per second (TPS) per API action—a tenfold increase over the previous limit. We continued raising the bar: 6,000 TPS in October 2022, 9,000 TPS in August 2023, 18,000 TPS in October 2023, and reaching 70,000 TPS per API action in select Regions by November 2023.
Server-side encryption with SSE-SQS (2021): In November 2021, we introduced server-side encryption using Amazon SQS-managed encryption keys (SSE-SQS), providing an encryption option that required no key management. In October 2022, we made SSE-SQS the default for all newly created queues, so customers no longer needed to enable it explicitly.
Dead-letter queue redrive enhancements (2021): We progressively expanded message recovery from dead-letter queues. In December 2021, we added DLQ redrive to the source queue directly within the SQS console. In June 2023, we extended this capability to the AWS SDK and CLI through new APIs: StartMessageMoveTask, CancelMessageMoveTask, and ListMessageMoveTasks. And in November 2023, we brought redrive support to FIFO queues.
Attribute-based access control (ABAC) (2022): ABAC arrived in November 2022, allowing customers to configure access permissions based on queue tags rather than managing static policies as resources scale.
JSON protocol support (2023): In November 2023, we added JSON protocol support in the AWS SDK, reducing end-to-end message processing latency by up to 23% for a 5 KB payload while also lowering client-side CPU and memory usage.
Amazon EventBridge Pipes console integration (2023): We also made it possible to connect an SQS queue directly to Amazon EventBridge Pipes from the SQS console, routing messages to a wide range of AWS service targets without writing custom integration code.
Extended Client Library for Python (2024): In 2024, we brought the Extended Client Library—previously available only for Java—to Python developers. This allows messages up to 2 GB to travel through SQS by storing the payload in Amazon S3 and passing a reference through the queue.
FIFO in-flight message limit increase (2024): Also in 2024, we raised the in-flight message limit for FIFO queues from 20,000 to 120,000 messages, so consumers can process significantly more messages concurrently without being constrained by the previous ceiling.
Fair queues for multi-tenant workloads (2025): In 2025, we introduced fair queues to mitigate the noisy neighbor problem in multi-tenant standard queues. By including a message group ID when sending messages, customers can prevent a single tenant from delaying message delivery for others—no changes required on the consumer side.
1 MiB maximum message payload size (2025): We increased the maximum message payload from 256 KiB to 1 MiB for both standard and FIFO queues in 2025, enabling customers to send larger messages without offloading data to external storage. The AWS Lambda event source mapping for SQS was updated in parallel to support the new payload size.
Despite two decades of feature additions, the fundamental use case for SQS hasn’t shifted. Customers still rely on it to decouple services, absorb traffic bursts, and build resilient systems that hold up when individual components fail. That same pattern now extends to AI workloads: SQS queues buffer requests to large language models, manage inference throughput, and coordinate communication between autonomous AI agents operating as independent services. For a practical example of this architecture, see \”Creating asynchronous AI agents with Amazon Bedrock.\”
To learn more about Amazon SQS, visit the Amazon SQS product page, review the developer guide, or explore recent updates on the AWS Blogs.
— Esra
Esra Kayabali is a Principal Solutions Architect at AWS, specializing in analytics, including data warehousing, data lakes, big data analytics, batch and real-time data streaming, and data integration. She has more than ten years of software development and solution architecture experience. She is passionate about collaborative learning, knowledge sharing, and guiding the community in their cloud technologies journey.
