亚马逊云风控解除 亚马逊云 AWS 账号服务消息推送
别再让 AWS 告警在角落吃灰：你的账号消息推送，可能根本没活过来
你有没有过这种体验？某天早上打开 AWS 控制台，发现 EC2 实例挂了 17 小时，RDS 主节点已自动故障转移三次，而你的 Slack 还安静得像凌晨三点的便利店——连个气泡都没冒过。你点开「服务健康状态」，才发现早在昨天下午 3:23，AWS 就发过一条橙色横幅：“us-east-1 区域 EBS 卷延迟升高（已恢复）”。你揉揉眼：这算通知？这叫考古预告片。
先泼一盆冷水：AWS 控制台里的“通知”，不是通知，是橱窗陈列
AWS 控制台右上角那个小铃铛图标，长得像通知中心，实则是“今日份云服务文艺汇演”预告栏。它只展示最近 7 天内平台级事件（比如区域中断、服务降级），且不支持自定义过滤、不触发动作、不发短信不发微信不推钉钉。它存在的意义，大概是让你在咖啡续命失败后，有地方可叹一句：“哦……原来昨天它就病了。”
真正能救命的三大推送引擎：SNS、EventBridge、CloudWatch Events
别慌，AWS 其实早把“消息主动出击权”悄悄塞进你账户里了——只是藏得比你在旧电脑里找毕业论文还深。核心三件套如下：
- SNS（Simple Notification Service）：老牌广播站，擅长“一对多群发”。适合发告警摘要、成本超支提醒、CI/CD 构建结果；
- EventBridge（原 CloudWatch Events）：智能调度员，能监听 几乎所有 AWS 服务的底层事件流（比如 Lambda 执行失败、IAM 用户创建、S3 对象上传完成），还能接入自家应用或第三方 SaaS 的自定义事件；
- CloudWatch Alarms + Actions：指标哨兵，专注“数值越界就开火”。CPU 持续 95% 超过 5 分钟？立刻调用 Lambda 或发 SNS。
三者不是非此即彼，而是黄金三角组合拳：EventBridge 抓事件 → CloudWatch 判阈值 → SNS 做分发。我们来拆解一个真实场景。
实战：当你的生产 RDS 被误删，如何 15 秒内手机震醒你？
假设某位同事手抖，在 Terraform apply 前忘了加 -dry-run，直接执行了 aws rds delete-db-instance --db-instance-identifier prod-main --skip-final-snapshot……
- EventBridge 捕获删除动作：创建规则，匹配事件源
aws.rds，事件类型DeleteDBInstance，且detail.status == "deleting"； - 触发目标：SNS 主题：该规则绑定到一个 SNS 主题（如
prod-rds-deletion-alert）； - 亚马逊云风控解除 SNS 多端分发：向该主题订阅：① 企业微信机器人 Webhook URL；② 钉钉群机器人（需加签校验）；③ 你手机号（启用 SMS）；④ 一个 Lambda 函数（用于自动创建紧急工单并 @值班人）。
整个链路耗时约 8–12 秒——比你从工位摸到咖啡机还快。
避坑指南：那些让你白配 3 小时的“优雅陷阱”
- 权限黑洞：EventBridge 默认无法向 SNS 发送消息。必须给 EventBridge 服务角色（
AWSServiceRoleForEvents）附加SNS:Publish权限。别信文档说“自动授权”，那是 AWS 对你的温柔谎言； - SMS 地域限制：SNS 短信仅支持部分国家/地区（中国内地不支持直连发送！）。国内团队请改用钉钉/企微/Webhook + 云短信网关（如腾讯云 SMS）中转；
- 事件格式迷雾：RDS 删除事件的
detail.dbInstanceIdentifier是字符串，但 CloudTrail 日志里却是requestParameters.dbInstanceIdentifier。别抄错路径，否则 Lambda 收到 null； - 告警疲劳陷阱：别把所有
EC2 Instance State-change都推微信。建议加条件：仅state == "terminated"且instance-id匹配^i-prod-前缀。
进阶玩法：让推送学会“看人下菜碟”
值班表不是摆设。用 Lambda + DynamoDB 做轻量级轮值系统：每天零点更新当前 on-call 人信息。SNS 推送前先查表，自动替换接收方——张三今晚值班？告警只推他手机+钉钉；李四休年假？他的 Slack 订阅静音 48 小时。再配上 EventBridge 的 Schedule 规则，每周一早 9 点自动发周报：“上周 S3 存储费用上涨 12%，主因 dev-bucket 日志未开启生命周期策略”。
最后说句掏心窝子的话
消息推送不是技术炫技，是责任前置。当你把“谁在什么情况下收到什么消息”写进 IaC 模板（Terraform/CDK），当新同事入职第一天就能看到清晰的告警路由图，当 CFO 突然问“上月 AWS 账单为什么跳涨”，你能秒调出关联的 Auto Scaling 事件流——那一刻，你不是在配 SNS 主题，你在给整朵云装上神经末梢。
所以，别再让告警躺在控制台里等考古了。现在就打开 AWS 控制台，找到 EventBridge，新建第一条规则。哪怕只监听自己的 IAM 用户登录事件——毕竟，第一个真正属于你的云上心跳，值得被听见。
