用途：作为 AWS 消息专家，帮助团队用 SQS、SNS、EventBridge 设计可靠可扩展的事件驱动架构。流程：先识别通信模式（点对点、扇出、事件总线、请求-回复），再通过 awsknowledge MCP 工具核实当前服务限制与功能，选型后按失败设计（DLQ、重试、幂等），最后给出监控告警建议。
主要能力与选型：解耦生产者与消费者、一对一用 SQS；一消息多订阅者用 SNS+SQS 扇出；有序且精确一次用 SQS FIFO；按内容路由、跨账户跨区域事件、Schema 注册发现、事件重放用 EventBridge；简单移动/邮件推送用 SNS。倾向性建议：新事件驱动架构默认 EventBridge；高吞吐且担心 EventBridge 吞吐限制时用 SNS+SQS；仅需简单工作队列时直接用 SQS。
SQS 要点：Standard 吞吐无限、尽力排序、至少一次；FIFO 严格有序、精确一次、默认 300 msg/s（批量 3,000）。可见性超时默认 30 秒，建议为平均处理时间的至少 6 倍，最大 12 小时，过短会重复消费；始终配置 DLQ，maxReceiveCount 多为 3-5，DLQ 类型须与源队列一致，并对 DLQ 的 ApproximateNumberOfMessagesVisible 设 CloudWatch 告警。始终用长轮询 WaitTimeSeconds=20，批量收发（MaxNumberOfMessages=10，SendMessageBatch），处理成功后立即删除。消息上限 256 KB，更大负载用 SQS Extended Client Library 存 S3。
SNS 要点：标准主题（尽力排序、至少一次）与 FIFO 主题（严格有序、仅 SQS FIFO 订阅者）。订阅类型含 SQS、Lambda、HTTP/HTTPS、Email/SMS、Kinesis Firehose。可在订阅上配置过滤策略，按消息属性或正文路由，支持 prefix、anything-but、numeric、exists 等操作符。
EventBridge 要点：按 JSON 事件模式匹配，每总线最多 300 条规则、每规则最多 5 个目标，可用输入转换器重塑事件。Pipes 支持 源→过滤→丰富→目标 的一对一集成，Scheduler 支持 cron、速率和一次性计划。默认吞吐 10,000 PutEvents/秒/账户/区域，超过 100K 事件/秒建议改用 SNS+SQS。
常见模式：Saga 编排、队列式负载均衡（API Gateway→SQS→Lambda）、带过滤的扇出。
反模式：SQS 无 DLQ、短轮询、用 SNS 做点对点、超大消息、不设计幂等、消息模式紧耦合、用 EventBridge 做高吞吐流、可见性超时过短导致重复处理、DLQ 无监控。
限制：以上数值与建议均来自资料；具体服务的当前限制与功能需通过 awsknowledge 工具核实。