Prioritize your AWS Health alerts using AWS User Notifications

使用 AWS 用户通知优先处理 AWS Health 警报 | AWS 架构博客

使用 AWS 用户通知优先处理 AWS Health 警报

如果您在 AWS 上运行关键业务负载（例如基于 Amazon Connect Customer 的联络中心、基于 Amazon Relational Database Service (Amazon RDS) 的数据库负载，或通过 AWS Direct Connect 的混合连接），服务健康事件需要您的关注。但并非所有事件都具有同等重要性。操作问题、计划维护窗口和埋藏在收件箱中的弃用通知会产生截然不同的影响。问题是它们都通过相同渠道传递，导致紧急程度难以判断。

AWS Health 为每个服务、每个账户、每个区域生成事件。该服务通过单一未分类的流传递持续问题、计划变更、账户通知和弃用通知。对于运维团队而言，这会带来一个熟悉的问题：要么将每个通知都视为紧急事项并承受不必要的分类噪音，要么开始忽略它们并冒着错过重要事项的风险。这两种路径都会导致响应时间变慢和不必要的升级。

本文将指导您使用 AWS 用户通知（AWS User Notifications）这一全托管服务，通过一种轻量级方法解决此问题。该服务可将 AWS 事件路由到您首选的传递渠道。此解决方案首先过滤健康事件，仅保留您需要接收通知的服务，然后将剩余事件分为两个优先级层级。关键事件会立即送达，信息类事件则以批量摘要形式送达。本文通过一个 AWS CloudFormation 模板和四种部署方式，帮助您在 AWS 环境中部署此解决方案。

解决方案概述

该设计遵循一个简单原则：先过滤，再按优先级分类。

第一层过滤噪音。事件规则仅匹配组织依赖的服务（如 AWS Direct Connect、Amazon Connect Customer 和 Amazon RDS）的健康事件。其他所有事件在到达收件箱前都会被静音。

第二层按紧急程度分类。两种通知配置处理不同优先级层级：

• CRITICAL — 匹配 eventTypeCategory 为 issue 或 scheduledChange 的事件。这些事件会立即以独立通知形式送达，不进行批量处理。
• INFORMATIONAL — 使用 any-but 过滤器（如 accountNotification）匹配所有其他事件。AWS 用户通知会在五分钟窗口内对这些事件进行批量处理，并以分组摘要形式送达。

在此解决方案中，CloudFormation 模板通过 DeploymentMode 参数支持四种部署模式：

| 模式 | 范围 | 包含内容 | |------------|------------------|--------------------------------------------------------------------------| | Linked（默认） | 单个账户 | 邮件联系人 + 用户通知事件规则 + 渠道关联 | | Payer | 整个组织或 OU | Linked 所有内容，加上针对根组织单元（OU）的组织单元关联 | | Combined | 所有 Linked 内容 + | Amazon EventBridge 规则和带有 [CRITICAL]/[INFORMATIONAL] 前缀的自定义邮件的 Amazon Simple Notification Service (Amazon SNS) 主题 | | PayerCombined | Linked 所有内容 + 组织关联 AND Amazon EventBridge 规则与 SNS 自定义邮件消息 |

下图展示了健康事件如何通过该解决方案流动：

图 1：架构图展示基于优先级的 AWS Health 警报系统使用 AWS 用户通知

部署内容

部署 CloudFormation 堆栈后，AWS 会创建以下资源：

• 优先级 AWS 服务 — AWS Direct Connect、Amazon Connect Customer 和 Amazon RDS 已预配置为监控服务。您可以在 CloudFormation 模板参数中直接自定义此列表。

• AWS 用户通知上的两个通知配置 — 一个用于 CRITICAL 事件（服务问题和计划变更），另一个用于 INFORMATIONAL 事件（账户通知），确保实现精准告警。

• 邮件投递通道 — AWS 会自动将两个通知配置与您在堆栈部署期间提供的电子邮件地址关联，使告警从第一天起即可触达相关人员。

通知流程工作原理

用户通知路径（所有部署模式）

• AWS Health 发布事件并发送到默认的 Amazon EventBridge 事件总线。

• 用户通知事件规则按服务 + 类别进行过滤 → 两个优先级层级。

• 通知配置路由：Critical 级别立即发送，Informational 级别每 5 分钟批量发送。

• 邮件联系人接收 AWS 标准格式的通知。

Amazon EventBridge + SNS 路径（仅 Combined 和 PayerCombined 模式）

与上述流程并行，第二条投递路径会激活：

• 相同的 AWS Health 事件发送到默认的 Amazon EventBridge 事件总线。

• 自定义的 Amazon EventBridge 规则（由模板部署）会评估默认事件总线上的事件，并按与 AWS 用户通知事件规则相同的"服务 + 类别"标准进行过滤。

• InputTransformer 将事件重新格式化为带有 [CRITICAL] 和 [INFORMATIONAL] 前缀的可读消息。

• Amazon SNS 通过 Amazon SNS 主题将自定义格式的邮件发送给所有订阅者。

• 未成功投递的邮件会路由到 Amazon Simple Queue Service 死信队列，如果 Amazon SNS 投递失败，Amazon CloudWatch 告警会触发。

先决条件

要跟随本文操作，您需要：

• 一个有效的 AWS 账户。

• 部署 AWS CloudFormation 堆栈和创建 AWS 用户通知资源的权限。

• 对于全组织范围部署：管理（付费）账户的访问权限以及组织根 ID 或组织单元（OU）ID。

• （可选）已安装并配置的 AWS 命令行界面（AWS CLI），用于基于 CLI 的部署。

部署流程

本节将引导您完成部署、验证和测试解决方案的步骤。根据您的范围选择四种部署模式中的一种，然后按照后续步骤确认所有功能正常运行。

步骤 1：部署 AWS CloudFormation 堆栈

通过此示例 CloudFormation 模板下载并部署完整解决方案：

选择与您的需求匹配的部署选项：

#### 选项 A：单账户（Linked 模式）

使用 AWS CLI 部署：

aws cloudformation deploy \
    --template-file prioritize-aws-health-notifications.yaml \
    --stack-name prioritize-aws-health-notifications \
    --parameter-overrides \
    DeploymentMode=Linked \
    NotificationEmail=ops-team@example.com \
    NotificationRegions=us-east-1,us-west-2
    NotificationHubAlreadyEnabled=No

注意：如果您的 AWS 账户已在 AWS 用户通知中启用了通知中心，请将 NotificationHubAlreadyEnabled=Yes。

或通过 AWS CloudFormation 控制台部署：

• 打开 CloudFormation 控制台并选择 创建堆栈。

• 上传 prioritize-aws-health-notifications.yaml 模板文件。

• 对于 Stack name，请输入 health-notifications。

• 对于 DeploymentMode，请选择 Linked。

• 对于 NotificationEmail，请输入通知的电子邮件地址。

• 对于 NotificationRegions，请输入要监控的区域（逗号分隔）。

• 对于 NotificationHubAlreadyEnabled，请选择 Yes/No。

• 选择 Submit。

#### 选项 B：组织范围（付款人模式）

部署前，请从付款人账户运行以下命令，以授予 AWS Health 服务访问您组织的权限：

aws health enable-health-service-access-for-organization

然后部署：

aws cloudformation deploy \
    --template-file prioritize-aws-health-notifications.yaml \
    --stack-name prioritize-aws-health-notifications-org \
    --parameter-overrides \
    DeploymentMode=Payer \
    NotificationEmail=ops-team@example.com \
    NotificationRegions=us-east-1,us-west-2 \
    NotificationHubAlreadyEnabled=No
    OrgRootId=r-xxxx

将 r-xxxx 替换为您的组织根 ID 以覆盖所有账户，或使用 OU ID（例如，ou-xxxx-xxxxxxxx）以限定到特定单元。

#### 选项 C：单账户搭配自定义 SNS 邮件（混合模式）

aws cloudformation deploy \
    --template-file prioritize-aws-health-notifications.yaml \
    --stack-name prioritize-aws-health-notifications-combined \
    --parameter-overrides \
    DeploymentMode=Combined \
    NotificationEmail=ops-team@example.com \
    NotificationRegions=us-east-1,us-west-2
    NotificationHubAlreadyEnabled=No

#### 选项 D：组织范围搭配自定义 SNS 邮件（付款人混合模式）

aws cloudformation deploy \
    --template-file prioritize-aws-health-notifications.yaml \
    --stack-name prioritize-aws-health-notifications-full \
    --parameter-overrides \
    DeploymentMode=PayerCombined \
    NotificationEmail=ops-team@example.com \
    NotificationRegions=us-east-1,us-west-2 \
    NotificationHubAlreadyEnabled=No
    OrgRootId=r-xxxx

预期结果：
堆栈在 2–3 分钟内达到 CREATE_COMPLETE 状态。

图2：CloudFormation 控制台显示 CREATE_COMPLETE 状态。

第2步：确认电子邮件订阅

堆栈部署完成后，请检查部署期间指定的电子邮件收件箱。您将收到一封来自 AWS 用户通知的订阅确认邮件。

• 打开确认邮件。

• 选择 Confirm subscription（确认订阅）。

重要提示：在确认电子邮件联系人之前，通知将不会被发送。

预期结果：在 AWS 用户通知控制台中，电子邮件联系人显示为 Verified（已验证）。

图3：AWS 用户通知控制台显示已验证的电子邮件联系人。

第3步：验证通知配置

打开 AWS 用户通知控制台，确认以下资源是否已创建：

• 导航到通知配置 — 您应该看到两个条目：Health-Critical-Notifications — 限定为 issue 和 scheduledChange 事件类型。Health-Informational-Notifications — 使用 anything-but 过滤器匹配除 issue 和 scheduledChange 以外的所有事件类别。

• 选择每个配置并验证：事件规则列出您选择的服务（AWS Direct Connect、Amazon Connect Customer、Amazon RDS）。传递渠道显示您确认的电子邮件联系人。

预期结果：可见两个通知配置，每个配置的事件规则均匹配您监控的服务，并关联电子邮件通道。

图4：AWS 用户通知控制台显示两个通知配置。

第4步：测试解决方案

验证已部署资源，请使用 AWS CLI：

aws notifications list-notification-configurations

预期结果：返回两个配置及其 ARN 和聚合设置 —— CRITICAL 无聚合（NONE）和 INFORMATIONAL 带有 5 分钟聚合窗口（SHORT）。

为验证端到端交付，请在 AWS Health Dashboard 中检查监控区域是否有任何活动事件。当发生匹配事件时：

• CRITICAL（问题或计划变更）：电子邮件立即送达，包含事件详情、受影响资源和建议操作。

• INFORMATIONAL（账户通知）：电子邮件在 5 分钟内以分组摘要形式送达。

预期结果：收到电子邮件通知，且传递模式符合预期 —— CRITICAL 独立发送，INFORMATIONAL 批量发送。

您将收到的内容

规则很简单：独立邮件表示需要立即关注。批量摘要表示可以按自己的时间表查看的常规更新。电子邮件格式由 AWS User Notifications 控制，无法自定义。优先级区分来源于传递模式，而非邮件正文中的文本标签。

对于使用 AWS Chatbot（Slack 或 Microsoft Teams）或控制台通知中心的团队，配置名称 [CRITICAL] 和 [INFORMATIONAL] 会直接显示在通知中，提供明确的优先级上下文。

图 5：来自 AWS User Notifications 的 CRITICAL 电子邮件通知示例，与 ISSUE 相关。

图 6：来自 AWS User Notifications 的 INFORMATIONAL 消息摘要电子邮件示例，与 accountNotification 相关。

自定义解决方案

您可以通过调整监控的服务和覆盖的区域来根据环境定制该方案。

添加或移除监控服务

此模板默认监控 AWS Direct Connect、Amazon Connect Customer 和 Amazon RDS。要监控其他服务，请更新两个事件规则中 EventPattern 的服务数组。例如，添加 Amazon Elastic Compute Cloud（Amazon EC2）：

"service": ["DIRECTCONNECT", "CONNECT", "RDS", "EC2"]

更新堆栈后，新服务将立即被覆盖。

多区域监控

要获取其他 AWS 区域的通知，请在 NotificationRegions 参数中传递多个区域：

NotificationRegions=us-east-1,us-west-2,eu-west-1

无论工作负载运行在何处，始终包含 us-east-1。AWS Health 全局事件（如 AWS Identity and Access Management（IAM）、Amazon Route 53 和 Amazon CloudFront 的事件）会发送到 us-east-1。如果排除该区域，您将错过全局事件。

添加传递渠道

该方案默认使用电子邮件，但无需修改核心事件规则或通知配置即可扩展：

• 更多电子邮件收件人：创建额外的 EmailContact 资源，并将其与现有的 CRITICAL 和 INFORMATIONAL 配置关联。

• Slack 或 Microsoft Teams：在聊天应用中设置 AWS Chatbot 通道，并创建 ChannelAssociation 将其与通知配置关联。

• 移动推送：安装 AWS Console Mobile App 并登录。User Notifications 会自动发送到移动应用 —— 不需要额外的 CloudFormation 资源。

• 基于团队的路由：仅将网络团队的电子邮件与CRITICAL配置相关联，而将一般运维团队与CRITICAL和INFORMATIONAL都相关联。这是通过频道关联实现的——无需更改事件规则。

与现有方法的比较

存在多种用于路由AWS Health事件的工具，每种工具都针对不同的运维需求进行了设计。本解决方案并不是所有工具的替代品——它填补了一个特定的空白。

| 方法 | 功能 | 权衡 | |------|------|------| | AWS Health Aware (AHA) | 基于Lambda、DynamoDB、Secrets Manager的开源框架。支持Slack、Teams、Chime和电子邮件，并具备事件去重功能。 | 需要Business或Enterprise Support计划。需要维护部署的组件。 | | HEIDI | / | / | | CID Health Events Dashboard | 使用Amazon QuickSight、Amazon Athena和Amazon S3进行历史分析和趋势可视化。 | 设计用于运维规划和事后回顾——不支持实时告警。需要Business或Enterprise Support计划。 | | 自定义Amazon EventBridge + Lambda + SNS | 完全灵活的路由和转换功能。 | 需要编写、测试和维护应用程序代码。 | | 第三方工具（PagerDuty、Datadog） | 升级、值班路由和确认工作流程。 | 许可证成本和供应商依赖。 |

本解决方案

实现优先级分离的实时健康告警的最简单路径。一个堆栈，无需代码、无需计算资源、无需支持计划。

无去重功能、无升级/确认机制、无历史存储。

本文中的方法在光谱上处于不同的位置。它作为独立解决方案适用于需要简单告警的团队，同样也适合作为更高级工具的基础层，随着运维需求的增长进行扩展。

您可以从本解决方案开始立即获得覆盖，然后考虑通过订阅Amazon SNS主题（组合模式）添加PagerDuty以实现升级和值班路由，或与HEIDI配合使用以进行历史趋势分析。

需要考虑的事项

本解决方案有意设计得轻量级，这伴随着需要理解的权衡：

• 邮件格式：AWS User Notifications控制邮件正文和主题行。默认情况下，您无法在邮件本身中添加自定义文本，如“[CRITICAL]”。优先级信号是传递模式——独立传递表示关键，批量传递表示信息性。对于需要在电子邮件中明确优先级标签的团队，组合部署模式添加了Amazon EventBridge + SNS层，使用InputTransformer在邮件正文前添加“[CRITICAL]”或“[INFORMATIONAL]”。

• 传递监控（组合模式）：Amazon EventBridge + SNS层内置可靠性。死信队列（DLQ）保留失败传递14天用于故障排除，如果SNS无法传递通知，CloudWatch警报会触发。这意味着您不仅会收到AWS Health问题的告警，还会收到通知管道本身故障的告警。

• 无去重功能：AWS Health事件具有生命周期——创建、更新、解决。每次更新都会触发新通知。单个事件可能在事件进展过程中生成2-4封电子邮件。对于严格的去重需求，建议与AHA配合使用或添加一个轻量级Lambda函数。

• 无升级或确认机制：此方案仅发送通知，但不会跟踪是否有人员采取了行动。如需实现值班路由和升级链，请通过SNS主题与PagerDuty或OpsGenie等事件管理工具集成。

• 无历史存储：通知实时发送但不会存储以供后续分析。如需进行事件后审查和趋势报告，请与HEIDI或CID Health Events Dashboard配合使用。

该方案的优势在于不会将您锁定在单一路径上。随着您逐步添加更多功能，通知配置和事件规则仍可保持原样。

清理

如果不再需要健康通知资源，请删除CloudFormation堆栈：

aws cloudformation delete-stack --stack-name prioritize-aws-health-notifications

注意：AWS CloudFormation会在删除堆栈后保留设置了DeletionPolicy: Retain策略的资源（通知配置、事件规则、电子邮件联系人和通道关联）。要完全删除这些资源，请通过AWS用户通知控制台或AWS CLI手动删除这些资源。

预期结果：堆栈将在2-3分钟内达到DELETE_COMPLETE状态。

结论

在本文中，我们介绍了如何通过AWS用户通知和单个CloudFormation模板设置基于优先级的AWS健康告警。该解决方案过滤出对组织至关重要的服务健康事件，然后将剩余事件分为需要立即处理的严重告警和批量信息摘要。

核心价值在于简单性。无需修补Lambda函数，无需管理DynamoDB表，无需维护代码。一个堆栈可在几分钟内部署，覆盖单个账户或整个组织。由于该方案仅使用原生AWS服务且无需支持计划，任何团队都可以根据当前工具或支持层级采用该方案。

该方案可作为独立的告警解决方案使用。同时也可以作为起点，通过AWS Chatbot在聊天应用中集成Slack和Microsoft Teams，通过PagerDuty或OpsGenie实现升级工作流，通过HEIDI或CID实现历史分析。

要开始使用，请从GitHub仓库下载CloudFormation模板。如需更多信息，请参阅AWS用户通知用户指南和AWS健康用户指南。

如果您有任何问题或需要帮助在组织中实施此解决方案，请联系您的AWS账户团队或访问AWS联系我们页面。

作者简介