AWS Health Aware – 为组织和个人 AWS 账户自定义 AWS 健康警报

AWS 致力于实现高可用性，大多数服务的正常运行时间为 99.9%。 但是，在极少数情况下确实会有事故发生，客户应做好应对准备。 AWS Health 是沟通服务降级、计划更改和资源影响问题的主要渠道。 对于运行关键应用程序的客户，能够访问主动和实时警报是改进其整体事件补救流程和保持卓越运营的关键。 在监控健康事件和维护在 AWS 上运行的客户应用程序的可靠性和可用性方面，速度和敏捷性对我们的客户至关重要。

AWS Health Aware – AHA 是一个事件管理和通信框架，用于从 AWS Health 向客户的首选通信渠道引入主动和实时警报。 使用 AWS Organizations的客户可以从其组织内受影响的账户中获得汇总的活动账户级别警报。 警报可以配置到终端节点，例如 Slack、Microsoft Teams、Amazon Chime 和电子邮件警报。 AHA 还可以在配置期间与广泛的其他终端节点集成。 这些警报旨在为客户提供事件可见性和指导，以帮助快速诊断和解决影响客户应用程序或工作负载的问题。

AHA的好处

AHA 采用 AWS Health API，该 API 仅适用于拥有商业或企业支持计划的 AWS 客户。

这些客户可以利用以下功能：

1. 与 Slack、Amazon Chime、Microsoft Teams 和电子邮件等通信平台集成，以实现 AWS 事件的自动实时警报。
2. 与 Amazon EventBridge 集成，能够将组织和非组织警报提取到事件总线。 这有助于让客户与超过 35 个 SaaS 合作伙伴集成，包括 NewRelic/DataDog/PagerDuty 等。
3. AWS Health 提供的带有规范性指导的聚合 PHD 警报。
4. 对受 PHD 警报影响的 AWS 账户和资源的可见性。
5. 能够通过选择特定区域来过滤掉不需要的警报。

范围

在开始部署之前，让我们看一下 AHA 的功能和架构，以更好地了解它们是如何协同工作的。 在图 1 中，根据客户是否使用 AWS Organizations 概述了可用的 AWS Health API 事件。

架构概述

 

下图展示了模拟无服务器单/多区域设置的 AHA 架构。

用户将 AWS CloudFormation 模板 (CFT) 上传到 AWS 账户。 CFT 从 Amazon S3 存储桶中获取解决方案。 然后，CFT 部署 Amazon IAM 角色、 Amazon EventBridge 计划、AWS Lambda 函数、AWS Secrets Manager 中的 webhook URL 和 Amazon DynamoDB 表。

单个区域

此架构使用户能够在给定的单个 AWS 区域上部署 AHA。

多区域

使用这种架构，用户可以在主动-主动区域模型中部署 AHA。 这将 AHA 部署集中在多个区域以保持响应并防止在 AWS 事件期间可能发生的任何中断。

在此表中，我们列出了 AHA 架构中的资源及其用途。

资源	描述
DynamoDDBTable	用于存储事件 ARN、更新和 TTL 的 DynamoDB 表
ChimeChannelSecret	存储在 AWS Secrets Manager 中的 Amazon Chime 的 Webhook URL
EventBusNameSecret	存储在 AWS Secrets Manager 中的 Amazon EventBridge 的 EventBus ARN
LambdaExecutionRole	用于 LambdaFunction 的 IAM 角色
LambdaFunction	从 AWS Health API 读取、发送到配置的 webhook URL 并写入 DynamoDB 的主要 Lambda 函数
LambdaSchedule	每分钟运行一次以调用 LambdaFunction 的 Amazon EventBridge 规则
LambdaSchedulePermission	用于 LambdaSchedule 的 IAM 角色
MicrosoftChannelSecret	存储在 AWS Secrets Manager 中的 Microsoft Teams 的 Webhook URL
SlackChannelSecret	存储在 AWS Secrets Manager 中的 Slack 的 Webhook URL

EventBridge 可扩展性

Amazon EventBridge 通过提供来自自定义源、Amazon Web Services (AWS) 和软件即服务 (SaaS) 应用程序的实时数据流，可以轻松地将应用程序连接在一起。
之后可以将数据发送到各种目标，例如 AWS Lambda、AWS Step Functions、Amazon Kinesis 等等。
Amazon EventBridge 还使您能够将您的应用程序与一系列 SaaS 合作伙伴连接起来，而无需担心构建和维护自定义基础设施。 客户正在使用这些功能通过构建事件驱动架构而不是紧密的服务耦合来提高其应用程序的可扩展性和可靠性。
随着越来越多的客户开始构建与 EventBridge 的端到端集成，AHA 希望为客户提供有关开始使用事件源和事件类型的各种不同可能性的最佳方式的指导。

这些用例包括：

1. 近乎实时的审计和历史业务运营事件的存档。
2. 用于商业智能和运营目的的事件可视化和分析。
3. 应用程序、服务和基础设施系统的自动警报和修复。
4. 将自定义工作流与下游消费者和遗留或本地应用程序连接起来。

图 3 中描绘的可视化说明了 AHA 通过 AWS EventBridge 集成的可扩展性选项：

图 3

总体先决条件

配置终端节点

AHA 可以发送到多个终端节点（webhook URL、电子邮件或 EventBridge）。 要使用其中任何一个，您需要事先进行设置，因为其中一些是在第三方方网站上完成的。 我们将在这里讨论一些常见的用例。

• 创建 Amazon Chime Webhook URL（需要权限；Amazon Chime 房间访问权限、管理 Webhook 的能力）

1. 1. 为事件创建一个新的聊天室（即 aws_events）
   2. 在步骤 1 中创建的聊天室中，在齿轮图标上，然后单击管理 webhook 和机器人
   3. 单击添加webhook
   4. 键入机器人的名称（即 AHA）并单击创建
   5. 单击复制 URL，我们将需要它进行部署

• 创建 Slack Webhook URL（需要权限；在 Slack 中添加新频道和应用程序）

1. 1. 为事件创建新频道（即 aws_events）
   2. 在您的浏览器中转到：workspace-name.slack.com/apps 其中 workspace-name 是您的 Slack 工作区的名称
   3. 在搜索栏中，搜索：Incoming Webhooks 并点击它
   4. 单击添加到 Slack
   5. 从下拉菜单中单击您在步骤 1 中创建的频道，然后单击添加传入 Webhooks 集成
   6. 在此页面中，您可以更改 webhook 的名称（即 AWS Bot）、要使用的图标/表情符号等。
   7. 对于部署，我们需要用到 Webhook URL

• 创建 Microsoft Teams Webhook URL（需要权限 – 在 Microsoft Teams 中添加新频道和应用程序）

1. 1. 为事件创建新频道（即 aws_events）
   2. 在您的 Microsoft 团队中转到应用程序
   3. 在搜索栏中，搜索：Incoming Webhook 并点击它
   4. 点击加入团队
   5. 在您在步骤 1 中创建的频道上输入您的名称，然后单击设置连接器
   6. 在此页面中，您可以更改 webhook 的名称（即 AWS Bot）、要使用的图标/表情符号等。完成后单击创建
   7. 对于部署，我们将会用到需要提供的 webhook URL

• 配置电子邮件

1. 1. 您将能够向一个或多个地址发送电子邮件警报。 但是，您必须首先在简单电子邮件服务 (SES) 控制台中验证电子邮件。
   2. AHA 使用 Amazon Simple Email Service (SES)，因此您只需输入收件人：地址和发件人：地址。
   3. 您可能必须在您的环境中允许一个规则，以便于让电子邮件不会被您的电子邮件客户端标记为垃圾邮件。

• 创建 Amazon EventBridge – EventBus

1. 1. 在 https://console.aws.amazon.com/events/  打开 Amazon EventBridge 控制台
   2. 在导航窗格中，选择事件总线
   3. 选择创建事件总线
   4. 输入新事件总线的名称
   5. 选择创建

有关详细信息，请参阅文档。

设置

AHA Github 上提供了详细的部署步骤。

新功能？

我们很高兴地宣布推出新的 AHA 增强功能。 请试用它们并继续向我们发送您的反馈！

1. Terraform 部署选项（适用于单区域、多区域）
2. 多区域部署 – 适用于所有类型的部署（有组织，无组织）
3. 能够过滤账户（有关如何从 AHA 通知中排除账户的更多信息，请参阅 AccountIDs CFN 参数）
4. 能够在 PHD 警报中查看给定帐户 ID 的帐户名称
5. 如果您在非组织模式下运行 AHA，如果适用于给定警报，AHA 将发送帐户编号和资源影响
6. 能够在成员账户上以 Org 模式部署 AHA
7. 支持新的健康事件类型——“调查”

 

支持与贡献

AWS Health Aware 解决方案已在 Github AWS 示例存储库中可用。 此解决方案的构建者在尽最大努力帮助解决 AHA 问题或功能请求。

企业支持客户可以就任何进一步的问题或功能请求与他们的 TAM 联系。 欢迎在 Github 中对这个项目做出任何贡献，并且可以通过 Github 拉取请求来请求！

总结

在这篇文章中，您了解了如何使用 AWS Health API 来提醒客户有关影响他们的 AWS Health 事件的最新信息。 您可以通过 AWS CloudFormation 部署一个无服务器基础设施，该基础设施将这些警报发送到您首选的通信渠道。 您现在应该能够主动监控您的个人和/或 AWS Organizations 账户的 AWS Health 事件并做出反应。 要开始使用，请访问 aws-samples Github 存储库并下载 AWS Health Aware (AHA)。

本篇作者

校译作者