Amazon Q+SNS+Slack

AWS Chatbot 已经更名为 Amazon Q Developer in chat applications。除了在聊天窗口中回答 AWS 相关问题，它还可以把 AWS 告警自动发送到 Slack，让团队直接在日常沟通频道中发现和处理故障。

本文关注的不是某一种基础设施代码，而是如何用 Amazon Q、Amazon SNS 和 Slack 建立一条自动化告警链路。

整体架构

AWS 服务或应用
      │
      ▼
CloudWatch Alarm
      │
      ▼
  Amazon SNS
      │
      ▼
Amazon Q Developer
      │
      ▼
 Slack Channel

各组件的职责很清晰：

CloudWatch Alarm 判断指标是否进入告警或恢复状态。
SNS 作为统一的消息入口，接收并分发告警。
Amazon Q Developer 订阅 SNS Topic，把 AWS 消息转换为适合聊天窗口阅读的通知。
Slack 承载告警通知、团队讨论和后续处置。

监控系统只需要知道应该向哪个 SNS Topic 发送消息，不需要知道 Slack Workspace、频道或聊天应用的配置。通知渠道发生变化时，告警本身不需要跟着修改。

为什么使用 Amazon Q，而不是直接调用 Slack Webhook

直接调用 Slack Webhook 当然也能发送消息，但需要自己处理凭证、消息格式、重试和 AWS 事件内容。

Amazon Q Developer 提供了 AWS 原生的连接方式：

直接接收 SNS 中的 AWS 服务通知；
识别并格式化 CloudWatch Alarm 等受支持的事件；
在 Slack 中展示告警状态、Region、时间和相关指标；
支持告警恢复通知；
可以在同一频道中询问 Amazon Q，辅助分析 AWS 资源；
在显式授权后，可以从聊天频道执行受限的 AWS 操作。

如果目标只是自动发送告警，可以只启用通知能力，不需要开放从 Slack 执行 AWS 命令的权限。

配置 Slack 与 Amazon Q

第一次接入需要 Slack Workspace 管理员参与授权：

在 Slack 中安装 Amazon Q Developer in chat applications。
打开 Amazon Q Developer in chat applications 控制台。
选择 Slack，并完成目标 Workspace 的授权。
在用于接收告警的 Slack 频道中邀请 Amazon Q。
回到 AWS 控制台，为该 Slack 频道创建 Channel Configuration。

建议先建立专用告警频道，例如按环境或严重级别区分频道，避免所有消息都进入同一个频道。

在 Amazon SNS 中创建用于告警通知的 Topic。Topic 是告警系统和 Slack 之间的边界，因此命名应该表达用途，而不是绑定某个具体应用。

常见的拆分方式包括：

critical-alerts  → 需要立即处理的告警
warning-alerts   → 性能、容量和趋势类告警

也可以按环境拆分 Topic，避免测试环境的告警进入生产频道。

创建 Topic 后，在 Amazon Q 的 Slack Channel Configuration 中把它添加为通知来源。一个频道可以关联多个 SNS Topic，同一个 Topic 也可以作为多个告警的发送目标。

将 CloudWatch Alarm 接入 SNS

创建或修改 CloudWatch Alarm 时，将前面创建的 SNS Topic 设置为通知目标。

建议同时配置两个状态动作：

ALARM：指标超过阈值时发送告警；
OK：指标恢复正常时发送恢复通知。

这样 Slack 中不仅会出现“发生了什么”，也能看到“问题是否已经恢复”。

这套链路不局限于某一种指标。常见场景包括：

ECS 服务没有运行中的 Task；
CPU 或内存持续超过阈值；
应用日志中出现严重错误；
队列积压或请求失败率升高；
AWS Budgets、Security Hub 或其他受支持服务产生通知。

对于应用自定义事件，可以先将事件转换成 Amazon Q 支持的通知格式，再发布到 SNS。

一条告警如何到达 Slack

当 CloudWatch Alarm 从 OK 变为 ALARM 时：

CloudWatch 将状态变化发布到 SNS Topic。
Amazon Q Developer 接收 SNS 消息。
Amazon Q 识别告警内容并生成结构化 Slack 消息。
Slack 频道收到告警，值班人员可以立即讨论和处理。
指标恢复后，CloudWatch 再次通过 SNS 发送 OK 状态。
Slack 收到恢复通知，形成完整的事件闭环。

整个过程不需要应用直接访问 Slack，也不需要在应用中保存 Slack Token 或 Webhook。

验证通知链路

配置完成后，先在 Amazon Q Developer 控制台选择对应频道并发送测试消息。确认 Slack 能收到测试消息后，再验证真实告警。

推荐按以下顺序检查：

Amazon Q 是否已经加入目标 Slack 频道；
Slack Workspace 是否已在 AWS 中完成授权；
Amazon Q 的频道配置是否关联了正确的 SNS Topic；
CloudWatch Alarm 的通知动作是否指向该 Topic；
Alarm 和 SNS Topic 是否位于预期的 AWS Region；
Amazon Q 的 CloudWatch Logs 中是否存在权限、格式或投递错误。

如果测试消息可以到达 Slack，但真实告警不能，问题通常位于 CloudWatch 到 SNS 这一段；如果 SNS 已经收到消息但 Slack 没有通知，则重点检查 Amazon Q 的 Topic 关联、事件格式和日志。

权限与安全

通知能力和聊天操作能力应该分开考虑。

只发送告警时，应使用最小权限的 Channel Role 和 Guardrail。不要因为 Amazon Q 支持在 Slack 中运行 AWS 命令，就默认授予频道管理员权限。

还应遵循以下原则：

不在文档或代码中记录真实的 AWS Account ID、Slack 标识和内部资源名称；
不让应用直接持有 Slack Token 或 Webhook；
按环境和严重级别隔离 SNS Topic；
限制可以加入运维频道的成员；
为 Amazon Q 启用错误日志，便于审计和排障；
只有在确有需要时，才开放从 Slack 执行 AWS 操作的权限。

总结

Amazon Q、SNS 和 Slack 组合起来，可以建立一条简单而清晰的 AWS 自动化告警链路：

告警产生 → SNS 分发 → Amazon Q 转换 → Slack 通知 → 团队响应

SNS 负责解耦告警和通知渠道，Amazon Q 负责理解 AWS 事件并连接 Slack，CloudWatch 等告警源只负责判断何时需要通知。

无论通过 AWS 控制台还是自动化工具完成配置，核心都是让告警统一发布到 SNS，再由 Amazon Q 将消息可靠地送到 Slack。