返回列表

亚马逊云代金券 AWS EC2 自动化运维教程：补丁管理、远程命令执行与配置维护实操指南

亚马逊aws / 2026-10-21 16:07:28

搜索“AWS EC2 自动化运维：补丁管理、远程命令与配置维护”的用户，通常已经有一批 EC2 在运行，当前痛点不是怎么开机，而是怎么少登录服务器、少手工操作、少漏打补丁，并且在需要批量改配置时能快速落地。

实际决策中，用户最关心的往往是这几个问题：现有 EC2 能不能直接接入自动化运维；要不要开公网；Linux 和 Windows 能不能统一管理；补丁是否会导致业务中断；远程命令失败后怎么排查；多账号多区域如何保持配置一致。下面直接进入操作层面的配置实践。

用户最关心的决策点：先判断你的 EC2 是否适合接入自动化运维

在开始前，先不要急着创建补丁任务。建议先确认这 4 个关键判断项，否则后面大概率会卡在实例不在线、命令无法下发或补丁基线不生效。

检查项	建议值	不满足时的表现
实例系统	Amazon Linux 2、Amazon Linux 2023、Ubuntu、RHEL、CentOS、Windows Server	部分旧版系统不支持完整补丁策略
SSM Agent	已安装并正在运行	实例不会出现在托管节点列表
IAM 实例角色	附加 AmazonSSMManagedInstanceCore	命令下发失败，状态为 AccessDenied 或 Not available
网络连通性	可访问 SSM、EC2Messages、SSMMessages 端点	实例显示离线或长时间无响应

如果你的目标是减少 SSH 或 RDP 的使用频率，那么推荐优先走 Systems Manager，而不是继续依赖堡垒机手动维护。对于没有公网 IP 的私网 EC2，这套方式更适合。

准备工作：账号、权限、网络和实例前置条件

账号与权限要求

控制台操作账号至少需要以下能力：查看 EC2、创建或修改 IAM Role、使用 Systems Manager、查看 CloudWatch Logs。若由运维团队统一管理，建议为操作人员单独分配最小权限策略，而不是直接使用管理员账户。

所需资源清单

至少 1 台 EC2 实例，建议先用测试环境验证
一个可绑定到 EC2 的 IAM Role
Systems Manager 可用区域
若实例无公网访问能力，需要配置 VPC Interface Endpoint
可选：CloudWatch Logs 日志组，用于保存命令输出

网络前置条件

很多人误以为 EC2 自动化运维必须开放 22 或 3389 端口，实际上使用 Systems Manager 时，实例不需要暴露 SSH 或 RDP 到公网。真正要保证的是实例能访问以下服务端点。

服务	用途	必需性
ssm	Systems Manager 主服务通信	必需
ec2messages	接收任务与状态消息	必需
ssmmessages	交互式消息通道	必需
logs	写入 CloudWatch Logs	建议
s3	部分补丁与文档分发	建议

如果 EC2 在私有子网中，建议在对应 VPC 下创建 Interface Endpoint，并在安全组中允许实例到这些端点的 443 出站访问。很多“SSM 连不上”的问题，本质上都是端点或路由没配好。

步骤一：为 EC2 开启 Systems Manager 托管能力

1. 创建或检查 IAM 实例角色

进入 AWS 控制台，打开 IAM，选择“角色”，点击“创建角色”。受信任实体选择 EC2，权限策略至少附加 AmazonSSMManagedInstanceCore。如果你希望命令输出写入 CloudWatch Logs，另外补充日志写入权限。

角色创建完成后，进入 EC2 控制台，选择目标实例，在“操作”中点击“安全”或“IAM 角色”，把该角色关联到实例。

2. 检查 SSM Agent 状态

Amazon Linux 2 和大部分新镜像默认已安装 SSM Agent，但不代表一定在运行。你可以通过以下方式检查。

系统	检查命令	启动命令
Amazon Linux / RHEL / CentOS	systemctl status amazon-ssm-agent	systemctl enable --now amazon-ssm-agent
Ubuntu	snap services amazon-ssm-agent 或 systemctl status amazon-ssm-agent	snap start amazon-ssm-agent 或 systemctl enable --now amazon-ssm-agent
Windows Server	服务管理器中查看 Amazon SSM Agent	启动该服务并设为自动

如果实例是自定义镜像导入，或历史环境较老，常见情况是 Agent 根本没装。此时不要先排查 IAM，优先确认 Agent 是否存在。

3. 在 Systems Manager 中确认实例上线

进入 Systems Manager 控制台，点击“Fleet Manager”或“Managed Nodes”。如果目标实例已经显示为托管节点且状态在线，说明自动化运维基础条件已经满足。

如果没有显示，按下面顺序排查更快：

先看 IAM Role 是否已附加到实例
再看 Agent 是否运行
最后检查网络是否可访问 SSM 相关端点

步骤二：使用 Patch Manager 管理 EC2 补丁

补丁管理最容易出问题的地方，不是“怎么点”，而是“什么时候打、打哪些、失败后怎么回滚”。生产环境建议先从扫描模式开始，不要直接大规模安装。

1. 创建补丁基线或使用默认基线

进入 Systems Manager，选择“Patch Manager”，先查看当前区域默认 Patch Baseline。对于大多数 Linux/Windows 环境，可以先使用 AWS 预置基线做初始验证；如果你有严格维护窗口要求，再自定义批准规则。

参数	建议填写	说明
操作系统	按实例系统分别创建	不要把 Linux 和 Windows 混在一个基线里
自动批准延迟	测试环境 0-2 天，生产环境 7-14 天	避免补丁刚发布就进生产
严重级别	优先 Critical、Security	先保安全修复，再扩展普通更新
拒绝列表	已知业务冲突补丁编号	适合有兼容性要求的业务

2. 给实例打标签，避免误操作全量服务器

建议在 EC2 上至少打这几类标签：Env=dev/test/prod、App=xxx、PatchGroup=linux-web。后续补丁扫描、安装、命令下发都尽量基于标签，而不是手动选实例 ID。这样能减少漏选或误选。

3. 先执行补丁扫描

亚马逊云代金券 在 Patch Manager 中创建补丁操作时，Operation 先选择 Scan。目标选择标签，例如 PatchGroup=linux-web。并发数建议先控制在 10%-20%，错误阈值设置为 1 或 2 台，先观察结果。

扫描完成后，查看 Missing count、Installed count、Failed count。若缺失补丁过多，先在测试实例验证安装影响，再扩大范围。

4. 再执行补丁安装

确认测试通过后，把 Operation 改为 Install。对于生产实例，建议在维护窗口执行，并提前确认是否允许重启。Windows 更新更容易触发重启，Linux 内核补丁同样可能需要重启才能生效。

亚马逊云代金券 实操建议：

Web 集群先逐台滚动更新，不要同时更新全部节点
数据库节点先做快照或备份，再执行安装
和 Auto Scaling 绑定的实例，确认更新后是否会触发健康检查替换

步骤三：通过 Run Command 远程执行批量命令

当你需要批量改配置、重启服务、清理日志、同步脚本时，Run Command 比 SSH 一台台登录更高效。最常见的问题是命令执行了但没人知道输出在哪里，或者脚本在某些实例上失败却没发现。

1. 创建命令任务

进入 Systems Manager，点击“Run Command”，选择文档。Linux 常用 AWS-RunShellScript，Windows 常用 AWS-RunPowerShellScript。

目标实例建议仍然按标签选择，例如：

Env=prod
App=nginx
Role=web

2. 填写命令内容

下面是一个 Linux 维护示例：更新配置文件后重载 Nginx。

命令示例	作用
cp /opt/config/nginx.conf /etc/nginx/nginx.conf	覆盖配置
nginx -t	先校验配置语法
systemctl reload nginx	平滑重载服务

建议不要把“改配置”和“重启服务”写成一步不可回退的大脚本。更稳妥的方式是先校验，再执行重载。如果 nginx -t 失败，命令应直接退出，避免把错误配置推到线上。

亚马逊云代金券 3. 配置并发与错误阈值

这一步非常关键。很多用户命令执行失败，不是脚本错，而是一次打到了太多实例。

场景	最大并发	最大错误
测试环境	50%	5
中小规模生产	10%	1
核心业务集群	1 台或 5%	1

亚马逊云代金券 如果你的服务后面挂了负载均衡，建议先在目标组中摘除节点，再执行命令，验证正常后重新加入。这样比直接对在线实例操作更稳。

4. 保存输出日志

在 Run Command 中开启 CloudWatch Logs 或写入 S3。否则等命令完成后，很难统一追踪执行结果。尤其是脚本依赖路径、权限、环境变量时，日志是定位失败原因的唯一依据。

步骤四：用 State Manager 维护长期配置一致性

如果你反复执行相同命令，比如确保 CloudWatch Agent 持续安装、时区不被改动、某个配置文件始终存在，那么不要继续用临时命令，直接改用 State Manager。

1. 创建 Association

进入 Systems Manager，点击“State Manager”，创建 Association。可选择现成文档，例如安装 CloudWatch Agent，或者使用脚本型文档持续校验文件内容、服务状态、软件包版本。

亚马逊云代金券 2. 设定执行频率

适合做长期维护的配置有：

固定日志采集配置
统一时区、NTP 设置
核心进程存活检查
安全基线脚本
定期同步业务脚本或证书文件

执行频率不宜过密。普通配置巡检可设置为 30 分钟到 24 小时一次；频率过高会增加 Agent 负载，也会让日志过多，影响排查效率。

3. 版本控制建议

配置脚本不要直接内嵌大量逻辑。建议把脚本放到代码仓库或 S3 中，文件名带版本号，例如 deploy-nginx-v3.sh，Association 只负责下发和执行。这样出现配置异常时，能快速回退到上一个版本，而不是在线改脚本。

亚马逊云代金券不同使用场景的配置建议

用户类型	推荐方案	重点关注
个人开发者	1-5 台 EC2，使用默认 Patch Baseline + Run Command	先跑通补丁扫描和日志输出
企业用户	按环境与业务标签分组，维护窗口分批更新	审批流程、回滚方案、CloudWatch 监控
跨境业务	按区域独立基线与维护窗口	不同地域补丁窗口、网络延迟、端点可达性
网站应用	Web 层滚动更新，负载均衡配合摘流	Nginx/Apache 配置校验、发布顺序
数据库业务	先快照备份，再补丁和配置维护	重启窗口、IO 抖动、备份一致性

如果你的 EC2 还承担数据库角色，不建议把系统补丁、数据库参数修改、磁盘扩容放在同一维护窗口里处理。分开执行，故障面更小，定位也更快。

常见故障排查：为什么自动化运维任务执行不了

实例在 Systems Manager 中不显示

优先检查 IAM Role 是否正确附加，实例是否运行 SSM Agent，其次检查出站网络。私有子网中最容易漏的是没有配置 SSM 相关 VPC Endpoint。

Run Command 显示 Success，但业务没生效

通常是脚本执行了，但目标路径、systemd 服务名或运行用户不对。例如你以 root 下发命令，但应用实际读取的是其他目录配置。处理方法是把关键输出写入日志，并在命令中增加 pwd、whoami、ls 等验证步骤。

补丁安装后实例需要重启，业务中断

说明补丁策略没有和业务窗口对齐。对于生产实例，应先扫描，再确认是否包含内核或 Windows 重启型更新；必要时先做 AMI 或快照，并按可用区分批滚动执行。

命令部分实例成功、部分失败

多半不是脚本本身有问题，而是实例基础状态不一致，例如系统版本不同、磁盘满、Agent 版本不同、依赖包缺失。建议先用 Run Command 执行只读检查脚本，统一收集版本、磁盘、内存、服务状态，再做正式变更。

CloudWatch Logs 没有命令输出

检查 Run Command 是否启用了日志输出，实例角色是否有写日志权限，日志组是否存在，以及区域是否一致。很多人是在 us-east-1 执行任务，却去另一个区域找日志。

优化建议：让 EC2 自动化运维更稳、更省、更好排查

安全优化

尽量用 Systems Manager 替代直接开放 22/3389
IAM 角色按最小权限配置，不要让实例拥有多余管理权限
敏感脚本参数放入 Parameter Store，而不是硬编码在命令中
补丁、命令、配置变更全部落日志，方便审计

性能优化

大型补丁任务分批执行，避免同一时间大量实例下载更新
命令脚本先做前置检查，减少失败重试
对高 IO 服务器，补丁窗口避开备份和批处理任务

成本优化

先对低频变更场景使用 Run Command，不必一开始就上复杂编排
日志保留期按需设置，避免 CloudWatch Logs 长期堆积
测试环境复用默认补丁基线，减少过度定制维护成本

稳定性优化

所有批量任务先以标签锁定小范围实例验证
生产变更统一通过维护窗口执行
关键实例变更前做 EBS 快照或 AMI
同类实例保持镜像、Agent 版本、目录结构一致

如果你当前正在评估 AWS EC2 自动化运维的落地顺序，最实用的实施路径是：先让实例全部接入 Systems Manager，再用 Run Command 做只读检查，之后上线 Patch Manager 扫描，最后把高频重复任务收敛到 State Manager。这样推进，风险最小，排障路径也最清晰。