aws-messaging-and-streaming

AWS 消息与流服务

回答 AWS 消息与流相关问题时，请从服务专属技能或 AWS 官方文档中核实具体数值、版本、限制和行为细节。如有不确定之处，请搜索技能或文档，不要猜测。编造配置选项或提供错误的版本号，比承认不确定性更糟。

如果问题询问推荐配置（CloudWatch 警报设置、阈值、缺失数据处理方式），请搜索服务专属技能或文档，不要依赖一般最佳实践。

概述

此领域知识用于选择和使用在生产者与消费者之间传输数据的 AWS 服务。 本技能涵盖两种基本模式——消息传递和流处理——以及实现这两种模式的 AWS 服务。 本技能还划定了与客户通信的边界——即发送给人的消息，而非应用程序组件——并将相关问题引导至负责相应渠道的技能或 AWS 文档（参见 Customer Communications (Application-to-Person)）。 使用本技能可判断哪种模式适合某个工作负载、选择合适的服务，并了解各项服务如何相互集成。

有关各项 AWS 服务的具体指南，请参阅参考文件或服务专属技能。

流处理与消息传递

什么是消息传递？

消息传递支持组件之间解耦的异步通信。生产者发送消息；一个或多个消费者接收并处理消息。消息处理完成后，通常会被删除。消息传递服务负责投递保证、重试和死信路由。

主要特征：

• 消息被消费一次（点对点）或扇出（发布/订阅）后即被移除
• 不支持重放——消息一经确认便不复存在
• 专为命令/请求类工作负载、任务分发和事件通知而设计

什么是流处理？

流处理支持有序、持久、高吞吐量的连续数据流。生产者将记录追加到日志中；消费者从日志中的指定位置读取记录。无论是否被消费，记录都会在可配置的保留期内持久保存。

主要特征：

• 记录会被保留，并可在保留期内重放
• 分区/分片内严格有序
• 多个独立消费者可以从不同位置读取相同数据
• 专为事件溯源、实时分析、变更数据捕获和连续处理而设计

主要区别

维度	消息传递	流处理
数据生命周期	消费后删除	保留以供重放（数小时至无限期）
顺序	尽力保证（Standard）或按组保证（FIFO）	分区/分片内严格有序
消费者模式	竞争消费者（工作分发）	独立读取者（按位置扇出）
吞吐量模式	突发、可变	持续、高容量
重放	不支持（DLQ 重新驱动除外）	原生支持——可跳转至保留范围内的任意位置
典型延迟	毫秒级（推送或短轮询）	毫秒级至数秒内
扩展单位	并发度（消费者/轮询器）	分区或分片

消息传递的使用场景

• 使用请求/响应或命令模式解耦微服务
• 将工作分发给一组竞争消费者（任务队列）
• 扇出通知，让每个订阅者独立处理
• 突发性较强且能从队列缓冲中获益的工作负载
• 迁移现有 JMS/AMQP 应用程序（Amazon MQ）

流处理的使用场景

• 持续、高吞吐量的数据摄取（日志、指标、点击流、IoT 遥测数据）
• 事件溯源，其中消费者需要从任意时间点重放
• 多个独立消费者以不同方式处理相同数据
• 实时分析、窗口聚合或复杂事件处理
• 变更数据捕获（CDC）管道

消息传递服务

这些服务通常用于消息传递工作负载。 根据具体用例和要求，流式服务（Kinesis Data Streams、Managed Streaming for Apache Kafka）有时也会用于消息传递工作负载。

服务	最适合的场景	主要差异化优势
Amazon SQS	任务队列、解耦、缓冲	完全托管、无限吞吐量（Standard）、恰好一次（FIFO）、适用于多租户工作负载的公平队列
Amazon SNS	扇出、发布/订阅通知	向多个订阅者推送（SQS、Lambda、HTTP；电子邮件/SMS 终端适用于运营警报——面向客户的电子邮件或 SMS 请参阅客户通信（应用到个人））
Amazon EventBridge	事件路由、跨账户/SaaS 集成	基于内容的筛选、架构注册表、200 多种 AWS 源集成
Amazon MQ	迁移现有 JMS/AMQP/MQTT 应用	协议兼容性（ActiveMQ、RabbitMQ），适用于旧版应用迁移

流式服务

这些服务通常用于流式工作负载。

服务	最适合的场景	主要差异化优势
Amazon Kinesis Data Streams	使用 AWS 原生使用者进行实时数据摄取	按需 Advantage 模式（即时扩展，无需管理分片）、保留期为 1–365 天
Amazon Data Firehose	无需管理即可向存储/分析服务交付数据	自动扩展、缓冲、批处理并向目标交付数据
Amazon Managed Service for Apache Flink	复杂的流处理（联接、窗口、状态）	完整的 Apache Flink 运行时——支持用于有状态计算的 SQL、Java、Python API
Amazon MSK	Kafka 原生工作负载、生态系统兼容性	Apache Kafka API、Express 代理（与 Standard 代理相比，吞吐量提升 3 倍，扩展速度提升 20 倍）、广泛的连接器生态系统

客户通信（应用到个人）

上述服务在应用之间，以及同一应用的组件之间传输数据。 另有一组 AWS 服务用于应用到个人（A2P）通信：向应用之外的接收者（例如客户和订阅者）发送消息，或从他们那里接收消息。 这两组服务不可互换。

渠道	服务	技能
电子邮件	Amazon SES	amazon-ses
WhatsApp	AWS End User Messaging Social	aws-social-messaging
SMS、MMS、RCS、语音	AWS End User Messaging SMS	aws-sms-voice
移动推送	AWS End User Messaging Push	无

本节可直接回答两类问题：某个工作负载属于哪一组，以及哪个服务负责某个渠道。 对于其他所有客户通信问题——设置渠道、通过渠道发送消息或排查投递问题——请勿依据此技能作答：加载表格中列出的技能并据此回答。 AWS MCP 服务可用时，使用 aws___retrieve_skill(skill_name="<skill>") 并填入表格中的确切名称来加载技能；或者从 Agent Toolkit 中读取技能文档 skills/<skill>/SKILL.md。 如果表格中的值为无，或者无法加载指定技能，请说明这一点；然后在文档工具（aws___search_documentation、aws___read_documentation）可用时使用这些工具回答，否则请参考相应服务的 AWS 文档。

常见集成注意事项

• SQS 系统属性与用户消息属性：AWSTraceHeader（由 X-Ray / EventBridge / Pipes 在发送消息到 SQS DLQ 时设置）、SenderId 和 SentTimestamp 等属性属于 SQS 系统属性，而非用户消息属性。默认情况下，ReceiveMessage 永远不会返回这些属性——需要通过 AttributeNames=[...]（或 MessageSystemAttributeNames）明确请求；这与获取用户属性的 MessageAttributeNames 分开。对于 DLQ，这一点很重要：跟踪标头通过系统属性传递，而用户属性位置则包含服务的故障元数据（例如 EventBridge 的 RULE_ARN、ERROR_CODE）。

• SNS → Firehose → S3 记录分隔符： 对于使用 firehose 协议并将数据写入 S3 的 SNS 订阅，记录默认已由换行符分隔（NDJSON）。请勿启用 Firehose 的 AppendDelimiterToRecord——SNS 会自行输出换行符，启用该处理器会产生双换行符。

• EventBridge 规则目标 DLQ 和 SNS 订阅 DLQ 都需要 DLQ 队列策略。 仅关联 DLQ 并不足够——在队列策略允许服务主体访问之前，DLQ 会静默丢弃消息。EventBridge：使用 DeadLetterConfig.Arn=<DLQ> 调用 PutTargets，并为 SQS 配置策略，允许 Service: events.amazonaws.com 执行 sqs:SendMessage，且 aws:SourceArn 为规则 ARN。SNS：使用 RedrivePolicy={"deadLetterTargetArn":"<DLQ>"} 调用 SetSubscriptionAttributes，并为 SQS 配置策略，允许 Service: sns.amazonaws.com，且范围限定为主题 ARN。

• SQS 生产环境默认设置：长轮询和客户管理加密。 新队列默认使用短轮询（ReceiveMessageWaitTimeSeconds=0）和 SSE-SQS（由 AWS 拥有的密钥）。在生产环境中，请使用 ReceiveMessageWaitTimeSeconds=20（长轮询）和 KmsMasterKeyId=<customer-managed key id/ARN> 调用 SetQueueAttributes，不要保留 alias/aws/sqs。

• 代理和 Kafka 凭证应存储在 Secrets Manager 中，而不是连接字符串中。 不要在应用配置、环境变量、JAAS 文件或 IaC 中硬编码用户名、密码或 SASL/SCRAM 凭证。对于 Amazon MQ（ActiveMQ/RabbitMQ），请将代理用户凭证存储为密钥并在启动时获取；Amazon MQ 的 Lambda 事件源映射要求以 Secrets Manager 密钥 ARN（BASIC_AUTH）提供代理凭证，而不是内联提供。对于 MSK SASL/SCRAM，密钥不可省略：其名称必须带有 AmazonMSK_ 前缀，并使用客户管理的 KMS 密钥加密（使用默认 aws/secretsmanager 密钥创建的密钥无法与集群关联），然后通过 BatchAssociateScramSecret 进行关联。MSK（SASL/SCRAM 或 mTLS）和自管理 Kafka 的 Lambda 事件源映射也应引用 Secrets Manager 密钥 ARN，而不是内联凭证。启用轮换，并将 IAM 读取权限（secretsmanager:GetSecretValue）限制为仅限使用该密钥的角色。请参阅 AWS Well-Architected 中的 SEC02-BP03 安全地存储和使用密钥。

• 服务主体资源策略需要设置 aws:SourceArn / aws:SourceAccount 条件。 当队列或主题策略向 events.amazonaws.com、sns.amazonaws.com 或 s3.amazonaws.com 等服务主体授予 sqs:SendMessage 或 sns:Publish 权限时，若省略来源条件，就会留下混淆代理漏洞——任何 AWS 账户中的规则、主题或存储桶都可以触发写入。每条此类策略语句都应通过 aws:SourceArn（指定规则、主题、存储桶或管道 ARN；若 ARN 尚未完全确定，可使用 ArnLike 和 *）和 aws:SourceAccount（你的账户 ID）限定范围。对于 S3 事件通知，必须同时设置这两个键，因为 S3 存储桶 ARN 不包含账户 ID，因此仅使用 aws:SourceArn 无法限定账户。同样的做法也适用于 EventBridge 规则和 EventBridge Pipes 使用的 IAM 角色的角色信任策略（主体为 events.amazonaws.com / pipes.amazonaws.com，aws:SourceArn 为规则或管道 ARN），而不仅限于上文提到的 DLQ 场景。请参阅 IAM 用户指南中的混淆代理问题。