On July 13, 2006, Amazon Simple Queue Service went live as one of the first three services AWS ever offered to customers. The problem it solved was one Amazon had already run into building its own systems: when one service calls another directly and that dependency is slow or unavailable, the failure cascades through everything downstream. Message queuing broke that chain by letting a producer drop a message into a queue and move on, while a consumer picked it up whenever it was ready, insulating the rest of the system from any single component's bad day.
The fundamentals haven't shifted in twenty years. What's changed dramatically is the scale, security posture, and flexibility built around that core idea, especially over the last five years.
Throughput has climbed steadily. High-throughput mode for FIFO queues launched with support for up to 3,000 transactions per second per API action, a tenfold jump over the earlier limit, and that ceiling kept rising over the following years, eventually reaching 70,000 TPS per API action in select regions. Encryption defaults tightened alongside that scale: server-side encryption with SQS-managed keys arrived as an option requiring no key management on the customer's part, and was later made the default for all newly created queues so nobody had to remember to turn it on.
Recovery tooling matured in stages too. Dead-letter queue redrive started as a console-only feature, then expanded to the AWS SDK and CLI through dedicated APIs, and eventually gained support for FIFO queues specifically. Attribute-based access control gave customers a way to manage permissions through queue tags rather than maintaining a growing pile of static policies as their resource count scaled up. On the performance side, JSON protocol support in the AWS SDK cut end-to-end message processing latency by up to 23 percent for a 5 KB payload while also reducing client-side CPU and memory overhead.
Other additions targeted specific friction points reported by customers running SQS at scale. A direct connection from a queue to EventBridge Pipes let messages route to a wide range of AWS service targets without custom integration code. The Extended Client Library, previously Java-only, was ported to Python, letting messages up to 2 GB pass through SQS by storing the payload in S3 and passing only a reference through the queue itself. The in-flight message limit for FIFO queues rose sixfold, from 20,000 to 120,000 messages, removing a ceiling that had constrained how many messages consumers could process concurrently. Fair queues addressed the noisy-neighbor problem in multi-tenant standard queues, letting a message group ID prevent one tenant's traffic from delaying delivery for everyone else sharing the queue, with no changes required on the consumer side. And the maximum message payload grew from 256 KiB to 1 MiB for both standard and FIFO queues, letting more workloads skip the extra step of offloading large payloads to external storage.
What hasn't changed is why people reach for SQS in the first place. Decoupling services, absorbing bursts of traffic, and keeping a system resilient when one component fails is exactly the job it was built for in 2006, and that same pattern now extends naturally into AI infrastructure. Teams increasingly use SQS queues to buffer requests headed to large language models, manage inference throughput under uneven load, and coordinate communication between autonomous AI agents that operate as independent services talking to one another asynchronously, rather than assuming every call will succeed on the first try.
Twenty years is a long run for any piece of cloud infrastructure to stay this central to how engineers build distributed systems. The steady stream of scaling and security improvements suggests AWS isn't treating SQS as a legacy service coasting on inertia, but as foundational plumbing worth continuing to invest in as the workloads running on top of it keep changing shape.