The 2006 launch
Amazon SQS went live on July 13, 2006, as one of the first three services available to AWS customers, alongside S3 and EC2. The motivation was a problem Amazon had already lived through internally. Distributed systems need a reliable way to pass messages between components without creating tight dependencies. If one service called another directly and that service was slow or unavailable, failures cascaded through the entire system. Message queuing solved this by letting services communicate asynchronously. A producer could drop a message into a queue and move on. A consumer picked it up when ready. Individual service failures stopped affecting the rest of the system.
When SQS launched publicly in July 2006, it made this pattern available to every AWS customer. Twenty years later, that core function (decoupling producers from consumers) remains the reason customers use SQS. The scale, performance, and operational controls around it look very different now.
The first 15 years
Marc Brooker covered the first 15 years of SQS milestones in his retrospective post, from the original 8 KB message limit in 2006 through FIFO queues, server-side encryption, and Lambda integration. The early years were about the basics: longer messages, longer retention, visibility timeouts, dead-letter queues. The middle years were about the operational features that turned SQS from "a queue you could use" into "a queue you could run a business on."
The last five years: scale and security
Over the last five years, SQS has continued to scale. High-throughput mode for FIFO queues launched in general availability, supporting up to 3,000 transactions per second per API action, a tenfold increase over the previous limit. The ceiling kept rising: 6,000 TPS, then 9,000, then 18,000, and finally 70,000 TPS per API action in select regions.
Security defaults moved in the same direction. Server-side encryption with SQS-managed keys (SSE-SQS) was introduced as an option, then made the default for all newly created queues. Customers no longer need to enable encryption explicitly. The change closed a class of compliance gaps that customers were quietly getting wrong.
Dead-letter queue recovery, which started as a console-only redrive to source queue, expanded to the AWS SDK and CLI through new APIs, and later added redrive support for FIFO queues. ABAC (attribute-based access control) followed, giving customers the ability to configure access permissions based on queue tags rather than static policies, which matters at scale when resources are constantly being created and destroyed.
The recent additions
Two additions close out the recent story. JSON protocol support in the AWS SDK reduced end-to-end message processing latency by up to 23% for a 5 KB payload and lowered client-side CPU and memory usage. The Extended Client Library, previously Java-only, came to Python, allowing messages up to 2 GB to be sent through SQS by storing the payload in S3 and passing a reference through the queue.
The queue-direct EventBridge Pipes integration lets users connect a queue to a broad range of AWS service targets without writing custom integration code, which is the kind of plumbing that used to be the developer's job and is now a one-click configuration.
Why this matters
SQS doesn't make the front page of cloud news. It never has. The reason it matters anyway is that the decoupling pattern it embodies is the reason AWS-scale distributed systems work at all. Every other AWS service that processes events, every serverless architecture, every microservice that doesn't want to call another microservice synchronously, is standing on the foundation SQS laid in 2006. Twenty years in, the foundation is still the same shape. The scale is just bigger.