亚马逊云科技中国区 Health Event 集中 IM 通知方案
内容提要
亚马逊云科技中国区暂不支持Health Organizational View，多账号健康事件分散难管理。本文提出基于EventBridge跨账号转发的集中通知方案，采用Hub-Spoke架构聚合各账号Health Event，经InputTransformer格式化后由Lambda推送至飞书、钉钉、Teams、企业微信、Slack等平台。方案Serverless无固定成本，CloudFormation一键部署，支持灵活扩展与安全控制。
延伸解读
为什么需要跨账号转发
亚马逊云科技中国区暂不支持 Health Organizational View，多账号下的 Personal Health Dashboard 事件无法在组织层面集中查看。运维人员需逐一登录各账号，效率低且易遗漏。本方案利用 EventBridge 跨账号事件转发，将各账号的 aws.health 事件汇聚到集中账号，实现类似 Organizational View 的集中监控能力，解决了中国区功能缺失带来的管理痛点。
Hub-Spoke 架构的扩展与安全
方案采用 Hub-Spoke 模式：集中账号部署自定义事件总线、规则和 Lambda，推送账号仅需一条转发规则。新增账号时只需部署转发规则，无需修改通知逻辑，也可通过 StackSets 自动部署。安全上，集中账号的事件总线通过资源策略精确控制允许推送的账号或组织，防止未授权访问。这种设计兼顾了灵活扩展与访问控制。
消息格式化与多平台适配
消息格式化在 EventBridge 规则层通过 InputTransformer 完成，Lambda 仅负责发送。修改通知模板只需更新 CloudFormation 中的 InputTemplate，无需改动代码。Lambda 根据 Webhook URL 特征自动识别目标平台（如飞书、钉钉、Teams、企业微信、Slack），并构造对应格式的消息，实现了多平台自适应，降低了维护成本。
部署与成本考量
方案提供 CloudFormation 模板，可一键部署 Hub 和 Spoke 栈。部署前需准备各平台的 Webhook 地址和 Lambda Layer 包。Serverless 架构无需预置资源，按事件触发付费，无固定成本。测试时可通过 put-events 模拟健康事件验证流程。对于多账号环境，建议结合 StackSets 自动化部署，并利用 CloudWatch Logs 审计通知记录。
Q&A
亚马逊云科技中国区为什么需要集中管理Health Event？
因为中国区暂不支持Health Organizational View，多账号环境下健康事件分散，运维人员需逐一登录各账号查看，响应效率低，且通知渠道不统一，缺乏集中视图。
这个集中通知方案的整体架构是怎样的？
采用Hub-Spoke模式：集中通知账号（Hub）部署EventBridge自定义事件总线、规则（含InputTransformer）和Lambda通知函数；推送账号（Spoke）部署EventBridge规则，将Health Event转发到集中账号。
Health Event从产生到发送IM通知的完整流程是什么？
Amazon Health产生事件 → 推送账号EventBridge规则匹配 → 跨账号转发到集中账号自定义事件总线 → InputTransformer格式化消息 → 触发Lambda → 自动识别平台并发送Webhook通知。
这个方案支持哪些即时通讯平台？如何识别不同平台？
支持飞书、钉钉、Teams、企业微信、Slack等。Lambda通过Webhook URL特征自动识别目标平台，并构造对应格式发送，例如飞书用msg_type: text，钉钉用msgtype: text，Teams用Adaptive Card，企业微信用msgtype: markdown，Slack用text。
部署这个方案需要哪些前置准备和步骤？
前置准备：获取目标平台的Webhook地址，并准备Lambda Layer包（安装requests库）。部署步骤：先部署集中通知账号（Hub），上传Lambda Layer并创建CloudFormation栈；再在每个推送账号（Spoke）中部署CloudFormation栈；最后通过put-events测试验证。
这个方案有哪些设计亮点和扩展方向？
设计亮点：集中管理、灵活扩展、多平台自适应、消息模板可配置、安全可控、无固定成本。扩展方向：多Webhook支持、更多平台与通知方式（如飞书加急消息）、事件过滤、自定义消息模板、通知审计、通知来源和方式扩展。
