AWS EC2服务器系统更新通知的非SMTP替代方案咨询

嗨，我来给你详细讲讲几个AWS原生的非SMTP方案，用来接收Ubuntu和Amazon Linux EC2实例的系统更新通知，顺便说说大规模部署下的管理思路：

1. 用Amazon SNS接收通知 #

这是最直接的AWS原生方案，SNS支持邮件、短信、Slack（通过Lambda中转）等多种通知渠道，完全不用自己搭建邮件服务器。

针对Amazon Linux（yum-cron）： #

• 先确保yum-cron已安装并启用：sudo yum install yum-cron -y && sudo systemctl enable --now yum-cron
• 修改yum-cron配置文件/etc/yum/yum-cron.conf，把emit_via的值改成command，然后在command_email字段指定自定义脚本路径，比如/usr/local/bin/send-sns-update-alert.sh
• 编写SNS通知脚本：

  #!/bin/bash
  UPDATE_LOG=$(tail -20 /var/log/yum.log)
  MESSAGE="EC2实例$(hostname)系统更新完成\n时间：$(date)\n更新详情：\n$UPDATE_LOG"
  aws sns publish --topic-arn "arn:aws:sns:你的AWS区域:你的账号ID:EC2-更新通知主题" --message "$MESSAGE" --subject "EC2系统更新提醒"
  

• 给脚本添加执行权限：sudo chmod +x /usr/local/bin/send-sns-update-alert.sh
• 给EC2实例绑定的IAM角色添加精细权限：不要直接用AmazonSNSFullAccess，而是创建仅允许向指定SNS主题发布消息的自定义策略，更安全。

针对Ubuntu（unattended-upgrades）： #

• 先配置自动更新：sudo apt install unattended-upgrades -y，编辑/etc/apt/apt.conf.d/50unattended-upgrades确保自动更新功能启用
• 创建触发钩子脚本，保存到/etc/apt/apt.conf.d/99update-notify-sns：

  DPkg::Post-Invoke {
      "if [ -f /var/run/reboot-required ]; then
          /usr/local/bin/send-sns-update-alert.sh reboot;
      else
          /usr/local/bin/send-sns-update-alert.sh update;
      fi";
  };
  

• 同样编写上面的SNS脚本，根据传入的参数调整通知内容，再给实例配置对应的IAM权限即可。

2. 用AWS Systems Manager（SSM）管理通知与状态 #

SSM是AWS的统一实例管理工具，特别适合大规模场景下的更新管控：

• 方案A：更新状态同步到SSM Parameter Store
  在更新脚本里把结果写入Parameter Store：aws ssm put-parameter --name "/ec2/updates/$(hostname)" --value "$更新详情" --type "String" --overwrite，然后通过CloudWatch Events监控参数变化，一旦更新完成就触发SNS通知。
• 方案B：SSM Automation批量更新+告警
  大规模部署时，用SSM Automation文档批量执行系统更新，执行完成后Automation会生成详细报告。你可以配置CloudWatch告警，监控Automation的执行状态，成功/失败时都能推送通知。

3. 用Elasticsearch+Kibana做日志告警 #

如果需要更深入的更新日志分析，可以用这套组合：

• 给EC2实例安装CloudWatch Agent，配置把/var/log/yum.log（Amazon Linux）或/var/log/unattended-upgrades/unattended-upgrades.log（Ubuntu）推送到CloudWatch Logs
• 将CloudWatch Logs的日志流导入Amazon Elasticsearch Service
• 在Kibana里创建告警规则，当检测到更新完成的日志条目时，触发SNS通知或者直接在Kibana界面弹出告警。

大规模数据中心的管理思路 #

在百级以上实例的场景中，绝不会逐个手动配置，通常会这么做：

• 用EC2启动模板或CloudFormation把更新脚本、IAM角色、CloudWatch Agent配置等打包成自定义镜像或启动配置，新实例启动时自动继承所有设置
• 用SSM Fleet Manager统一管控所有实例的更新策略，批量触发更新并集中收集结果
• 用基础设施即代码工具（比如Terraform、Ansible）批量部署更新脚本和监控配置，确保所有实例配置完全一致
• 集中化日志管理：把所有实例的更新日志统一收集到CloudWatch Logs或Elasticsearch，方便全局查看、分析和批量告警

这样不管是几台还是几百台实例，都能轻松搞定系统更新的通知和管控！

备注：内容来源于stack exchange，提问作者lony