---
格式版本: 2
标题: "Amazon SQS turns 20: Two decades of reliable messaging at scale"
原文链接: "https://aws.amazon.com/cn/blogs/aws/amazon-sqs-turns-20-two-decades-of-reliable-messaging-at-scale/"
发布日期: "2026-07-13"
发布时间校准状态: "found"
发布时间需复核: "否"
发布时间来源: "llm:scrape:provider_published_at"
发布时间证据: "provider publishedAt: 2026-07-13"
发布时间校准原因: "最高优先级候选：Firecrawl/provider publishedAt 明确标识2026-07-13，且与article:published_time一致，为文章真实发布时间。正文中2006-…"
发布时间校准置信度: "1"
发布时间候选数量: 14
发布时间严格候选数量: 5
发布时间原页读取状态: "source template page reused from URL open"
发布时间未找到原因: ""
发布时间校准时间: "2026-08-10T15:38:59+08:00"
发布时间仲裁状态: "confirmed"
发布时间仲裁尝试次数: 1
发布时间仲裁耗时毫秒: 6368
发现时间: "2026-08-10T15:37:59+08:00"
入库时间: "2026-08-10T07:39:07.379Z"
来源平台: "固定入口"
搜索渠道: "fixed_url"
搜索词: "https://aws.amazon.com/blogs/aws/"
匹配关键词:
  - "delivery"
  - "performance"
  - "latency"
  - "throughput"
相关厂家:
  - "AWS"
相关专家:
  []
内容类型: "网页"
抓取工具: "Free Fetch + Defuddle"
清洗工具: "Defuddle Markdown + Defuddle/Readability 正文提取"
原始附件:
  []
AI优质: "否"
AI打分: 28
AI分档: "非优质"
AI质检状态: "不通过"
AI打分理由: "正文为Amazon SQS二十周年回顾，完全聚焦消息队列服务演进，未涉及超节点、AI Rack、机柜级AI基础设施、供电散热互连或量产落地等核心主题，仅末尾泛泛提及AI工作负载，无实质技术或商业信号。"
AI质检模型: "deepseek-v4-flash"
AI质检时间: "2026-08-10T15:39:12+08:00"
AI主题相关性: 0
AI来源权威性: 15
AI新颖性: 3
AI技术细节: 0
AI商业部署信号: 0
AI完整性: 10
采集批次: "2026年8月10日15点37分56秒"
采集批次ID: "20260810-153756-703"
去重键: "https://aws.amazon.com/cn/blogs/aws/amazon-sqs-turns-20-two-decades-of-reliable-messaging-at-scale"
---

On July 13, 2006, we [launched](https://aws.amazon.com/blogs/aws/amazon_simple_q/) [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) as one of the first three services available to customers, alongside [Amazon EC2](https://aws.amazon.com/blogs/aws/amazon_ec2_beta/) and [Amazon S3](https://aws.amazon.com/blogs/aws/amazon_s3/). We had learned firsthand that 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, while a consumer picked it up when ready. This approach kept individual service failures from affecting the rest of the system.

When Amazon 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 though.

covered the first 15 years of SQS milestones in his [15th anniversary post](https://aws.amazon.com/blogs/aws/amazon-sqs-15-years-and-still-queueing/), from the original 8 KB message limit in 2006 through FIFO queues, server-side encryption, and Lambda integration. Over the last five years, we have continued to scale SQS, added stronger security defaults, and introduced new capabilities that address increasingly complex workload patterns.

**Key milestones between 2021 and 2026**  
**High throughput mode for FIFO queues (2021):** In [May 2021](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-sqs-now-supports-a-high-throughput-mode-for-fifo-queues/), we launched general availability of high throughput mode 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 this ceiling over the following two years: to 6,000 TPS in [October 2022](https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-sqs-increased-throughput-quota-fifo-high-throughput-ht-mode-6000-transactions-per-second-tps/), to 9,000 TPS in [August 2023](https://aws.amazon.com/about-aws/whats-new/2023/08/amazon-sqs-increased-throughput-quota-fifo-high-throughput-mode/), and to 18,000 TPS in [October 2023](https://aws.amazon.com/about-aws/whats-new/2023/10/amazon-sqs-increased-throughput-quota-fifo-high-throughput-mode/), before reaching 70,000 TPS per API action in select Regions by [November 2023](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sqs-throughput-quota-fifo-high-throughput-mode/).

**Server-side encryption with SSE-SQS (2021):** In [November 2021](https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-sqs-server-side-encryption-keys-sse/), we introduced server-side encryption with Amazon SQS-managed encryption keys (SSE-SQS), giving customers an encryption option that required no key management. In [October 2022](https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-sqs-announces-server-side-encryption-ssq-managed-sse-sqs-default/), we made SSE-SQS the default for all newly created queues, so customers no longer needed to explicitly enable it.

**Dead-letter queue redrive enhancements (2021):** We progressively expanded how customers recover unconsumed messages from dead-letter queues. In [December 2021](https://aws.amazon.com/about-aws/whats-new/2021/12/amazon-sqs-dead-letter-queue-management-experience-queues/), we added DLQ redrive to source queue directly in the SQS console. In [June 2023](https://aws.amazon.com/about-aws/whats-new/2023/06/amazon-sqs-dead-letter-queue-redrive-aws-sdk-cli/), we extended this capability to the AWS SDK and CLI through new APIs, including `StartMessageMoveTask`, `CancelMessageMoveTask`, and `ListMessageMoveTasks`. In [November 2023](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sqs-fifo-dead-letter-queue-redrive/), we added redrive support for FIFO queues.

**Attribute-based access control, ABAC (2022):** In [November 2022](https://aws.amazon.com/about-aws/whats-new/2022/11/amazon-sqs-attribute-based-access-control-abac-flexible-scalable-access-permissions/), we introduced ABAC, giving customers the ability to configure access permissions based on queue tags rather than maintaining static policies as resources scaled.

**JSON protocol support (2023):** In [November 2023](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sqs-support-json-protocol/), we added support for the JSON protocol in the AWS SDK, reducing end-to-end message processing latency by up to 23% for a 5 KB payload and lowering client-side CPU and memory usage.

**Amazon EventBridge Pipes console integration (2023):** We [added](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sqs-eventbridge-pipes-console-integration/) the ability to connect a queue directly to EventBridge Pipes from the SQS console, routing messages to a broad range of AWS service targets without writing custom integration code.

**Extended Client Library for Python (2024):** We [brought](https://aws.amazon.com/about-aws/whats-new/2024/02/amazon-sqs-extended-client-library-python-payloads/) the Extended Client Library, previously available for Java, to Python developers, allowing messages up to 2 GB to be sent through SQS by storing the payload in Amazon S3 and passing a reference through the queue.

**FIFO in-flight message limit increase (2024):** We [increased](https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-sqs-increases-in-flight-limit-fifo-queues/) 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):** We [introduced](https://aws.amazon.com/about-aws/whats-new/2025/07/amazon-sqs-introduces-fair/) 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, without any changes required on the consumer side.

**1 MiB maximum message payload size (2025):** We [increased](https://aws.amazon.com/about-aws/whats-new/2025/08/amazon-sqs-max-payload-size-1mib/) the maximum message payload from 256 KiB to 1 MiB for both standard and FIFO queues, helping customers send larger messages without offloading data to external storage. AWS Lambda event source mapping for SQS was updated in parallel to support the new payload size.

**The constant underneath the change**  
Despite two decades of feature additions, the fundamental use case for SQS has not shifted. Customers use it to decouple services, buffer bursts of traffic, and build systems that stay resilient when individual components fail. That same pattern now extends to AI workloads. Customers use SQS queues to buffer requests to large language models, manage inference throughput, and coordinate communication between autonomous AI agents operating as independent services. For an example of this architecture in practice, read [Creating asynchronous AI agents with Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/creating-asynchronous-ai-agents-with-amazon-bedrock/).

To learn more about Amazon SQS, visit the [Amazon SQS product page](https://aws.amazon.com/sqs/), review the [developer guide](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html), or explore recent updates on the [AWS Blogs](https://aws.amazon.com/blogs/compute/category/messaging/amazon-simple-queue-service-sqs/).

[— Esra](https://www.linkedin.com/in/esrakayabali/)