AWS国际版 AWS Systems Manager 详解：集中管理 EC2 与云端服务器的配置实践与故障排查教程

用户搜索“AWS Systems Manager 详解：集中管理 EC2 与云端服务器”时，通常不是想看概念说明，而是已经进入实际操作阶段：要么刚创建了 EC2，希望不用公网 SSH 就能远程管理；要么已经有一批 Linux、Windows 实例，想批量执行命令、打补丁、收集清单；要么遇到了实例明明开着，却在 Systems Manager 控制台里显示未托管、Agent 离线、Session 连接失败、Run Command 无法下发命令等问题。

这篇文章直接围绕这些操作痛点展开，重点解决四类场景：第一，如何让 EC2 被 SSM 正常纳管；第二，如何通过 Session Manager 代替 SSH/RDP；第三，如何用 Run Command、Patch Manager、Automation 做批量运维；第四，出现权限、网络、Agent、端口或区域配置错误时怎么排查。

一、用户在实际决策时最关心的几个问题

在生产环境里，是否使用 AWS Systems Manager，往往取决于以下几个判断：

• 现有 EC2 是否必须绑定公网 IP，还是可以通过 Session Manager 直接运维。
• 多台服务器的脚本执行、补丁安装、参数统一下发，能否在控制台集中完成。
• 实例位于私有子网时，SSM 是否还能工作，需要哪些 VPC Endpoint。
• 混合云服务器或本地机房主机，能否统一接入到 AWS 里管理。
• 实例显示“Managed node”失败时，到底是 IAM 角色、Agent、网络还是区域配置有问题。

如果你的目标是减少堡垒机登录、降低开放 22/3389 端口的风险、提高批量运维效率，那么 Systems Manager 更适合作为“统一纳管入口”，而不是单纯的命令执行工具。

二、开始前必须确认的准备项

1. 账号与权限要求

操作 Systems Manager 时，常见失败不是服务本身问题，而是权限不完整。建议准备以下权限：

如果是企业环境，建议不要直接给操作员全部管理员权限，而是通过 IAM Identity Center 或 IAM Policy 限制可登录实例、可执行文档范围和可访问区域。

AWS国际版 2. 所需资源与前置条件

如果实例在私网且不走 NAT Gateway，至少要准备 3 个接口端点：ssm、ec2messages、ssmmessages。很多用户只建了一个 ssm 端点，结果 Session Manager 仍无法建立连接。

三、先把 EC2 正常纳管：这是后续所有操作的前提

步骤1：创建或检查实例角色

进入 AWS 控制台，打开 IAM，点击“Roles”，创建一个给 EC2 使用的角色。信任实体选择 EC2，权限策略至少附加 AmazonSSMManagedInstanceCore。

如果你的实例还要读取 S3 中的部署包、执行 CloudWatch Agent 日志采集，可补充以下策略：

• AmazonS3ReadOnlyAccess
• AWS国际版 CloudWatchAgentServerPolicy

注意事项：不要把 SSM 权限加在操作员 IAM 用户上就以为实例能被纳管。实例接入依赖的是“实例角色”，不是你的登录账号权限。

步骤2：把角色绑定到 EC2

进入 EC2 控制台，选择实例，点击“Actions”→“Security”→“Modify IAM role”，将上一步创建的角色绑定到实例。

如果是新购实例，建议在“Launch instance”时直接在“Advanced details”里指定 IAM instance profile，避免上线后再补配置。

步骤3：检查 Agent 状态

Linux 实例中，使用以下命令检查：

Amazon Linux / RHEL / CentOS：

sudo systemctl status amazon-ssm-agent

Ubuntu / Debian：

sudo snap services amazon-ssm-agent

如果未安装，可执行：

Ubuntu 示例：

sudo snap install amazon-ssm-agent --classic
sudo systemctl enable snap.amazon-ssm-agent.amazon-ssm-agent.service
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service

Windows 实例中，打开 Services，检查 Amazon SSM Agent 是否为 Running；也可以在 PowerShell 中执行：

Get-Service AmazonSSMAgent

步骤4：确认网络连通

如果实例在公有子网，能通过 NAT 或公网访问 AWS API，通常可直接注册到 SSM。如果实例在私有子网，建议配置下表中的端点：

端点安全组必须允许实例到端点 ENI 的 443 流量。很多“Agent 在线但无法 Session”的问题，最后都是 VPC Endpoint 安全组没放通。

步骤5：在 Systems Manager 中确认托管状态

打开 Systems Manager 控制台，进入“Fleet Manager”或“Managed nodes”，查看实例是否已出现。正常情况下，绑定角色、Agent 运行且网络可达后，数分钟内就会注册。

如果超过 10 分钟仍未出现，优先检查三个点：实例角色、Agent 日志、区域是否看错。

四、用 Session Manager 连接 Linux 和 Windows，替代 SSH 与 RDP

步骤1：启用 Session Manager 基本配置

进入 Systems Manager → Session Manager → Preferences。这里建议做两项设置：

• 启用会话日志，输出到 S3 或 CloudWatch Logs，满足审计要求。
• 设置 KMS 加密，避免会话记录明文存储。

如果是企业运维，建议强制所有会话写日志，不要只依赖个人终端留痕。

步骤2：连接 Linux 实例

在 EC2 控制台选择实例，点击“Connect”，切换到“Session Manager”，如果实例状态正常，会看到“Connect”按钮。

点击后会直接打开浏览器终端。此方式不需要：

• 公网 IP
• 开放 22 端口
• 本地保存 SSH 私钥

如果按钮不可用，通常说明实例还没被托管，或者当前登录账号没有 ssm:StartSession 权限。

步骤3：连接 Windows 实例

Windows 服务器也可以通过 Session Manager 进入 PowerShell 环境，用于服务排查、补丁检测、日志收集等。对于必须图形化操作的场景，可以保留 RDP，但建议优先通过 SSM 执行日常维护，减少 3389 暴露。

AWS国际版 对于必须使用远程桌面的环境，可采用“先通过 Session Manager 建立端口转发，再本地 RDP”的方式，避免直接开放公网端口。

五、批量执行命令：Run Command 的控制台操作方法

步骤1：选择文档

进入 Systems Manager → Run Command → Run command。常用文档包括：

步骤2：指定目标实例

可以按实例 ID 选择，也可以按 Tag 批量选择。例如给所有打了 Environment=prod 且 Role=web 的实例下发命令。生产环境建议优先按 Tag 管理，这样扩容后的新实例也能自动纳入批处理范围。

步骤3：填写命令参数

例如在 Linux 上检查磁盘与内存：

df -h
free -m
top -b -n 1 | head -20

执行时建议设置：

• Concurrency：10% 或固定数量，避免瞬时打满所有实例
• Error threshold：1 或 2，防止错误扩散
• Output options：输出到 S3 或 CloudWatch Logs，便于回溯

很多批量变更事故，问题不在命令本身，而在没有限制并发和失败阈值。

AWS国际版 六、补丁管理与定时维护：适合长期运维而不是一次性操作

步骤1：创建 Patch Baseline

进入 Systems Manager → Patch Manager，按操作系统选择默认基线或新建自定义基线。重点不是“全量自动更新”，而是控制补丁类别和审批延迟。

步骤2：创建 Patch Group

给实例打 Tag，例如 Patch Group=web-prod，然后把该组绑定到 Patch Baseline。这样可以对不同业务线采用不同补丁策略。

步骤3：使用 Maintenance Window 定时执行

进入 Systems Manager → Maintenance Windows，创建维护时间，例如每周三凌晨 02:00-04:00。然后注册目标实例、添加任务，任务可以是 Run Command、Automation 或 Lambda。

建议把补丁安装和实例重启拆成两个任务，中间留 10-15 分钟观察窗口，避免服务直接中断。

七、接入本地机房或其他云厂商服务器时，最容易忽略的地方

如果你不只管理 EC2，还要纳管本地 VMware、IDC 物理机或其他云平台的 Linux/Windows 服务器，可以在 Systems Manager 的 Hybrid Activations 中创建激活码。

关键操作点

• 在 Systems Manager → Hybrid Activations 创建 Activation code 和 ID。
• 在目标服务器安装 SSM Agent。
• 执行注册命令，把该服务器注册为 managed instance。
• 确保服务器能访问 SSM、ec2messages、ssmmessages 相关公网端点或通过代理访问。

此场景下最常见的问题不是安装失败，而是企业出口防火墙限制了 443 到特定 AWS 域名，导致 Agent 启动后一直无法注册。

八、不同业务场景下的配置建议

九、实际故障排查：哪些问题最常见，应该先看哪里

案例1：实例在线，但不出现在 Managed nodes

优先检查顺序：

• AWS国际版 实例是否绑定 AmazonSSMManagedInstanceCore 角色
• SSM Agent 服务是否运行
• 实例所在区域是否与控制台当前区域一致
• 私网实例是否可访问 3 个 SSM 端点

Linux 日志路径常用：

/var/log/amazon/ssm/amazon-ssm-agent.log

AWS国际版 案例2：Session Manager 连接按钮灰色

常见原因有三类：用户没有 StartSession 权限、实例未被纳管、ssmmessages 端点不通。企业网络里最容易漏掉的是端点安全组。

案例3：Run Command 显示 Success，但命令没生效

这通常是脚本本身写法问题，例如服务重启命令兼容性不一致，或 Shell 环境变量与交互终端不同。建议在命令里显式指定路径，如 /usr/bin/systemctl，而不要依赖 PATH。

案例4：Windows 实例能看到，但 PowerShell 命令执行失败

重点检查文档是否选错。Windows 应使用 AWS-RunPowerShellScript，而不是 AWS-RunShellScript。其次查看实例的执行策略、脚本编码、是否调用了本地不存在的模块。

案例5：补丁任务执行后实例异常重启

应在补丁策略里确认是否允许自动重启。对数据库、中间件、状态服务，建议拆分为“扫描”“安装”“人工确认重启”三个阶段，不要一次性全自动执行。

十、上线后的优化建议

安全优化

• 优先用 Session Manager，逐步关闭公网 SSH 和 RDP。
• 会话日志写入 CloudWatch Logs 或 S3，并启用 KMS 加密。
• 通过 IAM 限制可访问实例的 Tag 范围，例如仅允许运维组连接 Environment=dev。

性能优化

• 大规模 Run Command 时限制并发，避免批量任务导致 CPU、磁盘 IO 峰值。
• 补丁与脚本分时段执行，特别是高峰期不要对整组实例同时操作。
• 对常用巡检命令做 Automation 文档，减少人工重复登录。

成本优化

• 使用 Session Manager 后，可减少堡垒机、公网带宽和弹性 IP 使用量。
• AWS国际版 私网实例若原本仅为远程运维而配置 NAT，可评估是否改用 VPC Endpoint 降低长期成本。
• 日志保留周期按业务要求设置，不要无限期留存 CloudWatch Logs。

稳定性优化

• 所有实例统一打 Tag，便于补丁、命令、清单、自动化任务分组管理。
• 生产环境先做一组灰度实例，再扩大到全量。
• 对关键实例启用 State Manager，确保 Agent、日志采集、基础配置持续一致。

如果你的目标是“集中管理 EC2 与云端服务器”，真正决定成败的不是会不会点控制台，而是三件事是否提前设计好：实例角色是否统一、私网网络是否打通、批量操作是否有灰度和回滚策略。只要这三点处理到位，AWS Systems Manager 在日常巡检、免公网远程运维、批量执行、补丁管理上的落地会顺畅很多。