AWS Run Command与本地运行差异及反向执行失败等问题咨询

我之前在做混合云自动化部署时也碰到过几乎一模一样的场景，咱们一步步拆解你的疑问：

一、反向send-command失败的核心原因 #

你提到手动运行批处理正常，但通过Run Command触发就失败，大概率是执行上下文的差异导致的：

• 权限与环境变量隔离：SSM Agent是以系统服务身份（Windows下是Local System，Linux下是ssm-user或root）运行Run Command的，这个上下文和你手动登录EC2时的用户上下文完全不同。即便你配置了IAM权限，Agent运行的用户可能没有加载到你本地用户的环境变量（比如AWS CLI的配置文件、Bamboo相关的认证信息），导致反向调用Bamboo的send-command时缺少必要的认证或配置。
• 会话生命周期限制：Run Command的执行会话是临时的，命令执行完成后会话会被销毁。如果你的批处理里的反向调用依赖于会话的某些资源（比如临时端口、会话级别的网络连接），会话销毁后这些资源就失效了，导致命令无法送达。
• 静默执行的输出/错误捕获问题：Run Command默认会捕获标准输出，但如果反向调用的错误信息没有输出到标准流，你可能看不到日志里的错误——比如Bamboo的API调用返回了401未授权，但你的批处理没有把这个错误打印出来，导致你误以为没有日志错误。

二、为什么Run Command总是让程序在后台运行？ #

这是SSM Agent的设计特性：

• 非交互式会话执行：Run Command本质是通过SSM Agent发起的非交互式远程执行，不会绑定到任何终端会话。不管是Windows的批处理还是Linux的脚本，都会在Agent的后台进程组里运行，不会像你手动登录那样有可见的窗口或终端。
• 服务级别的执行上下文：Agent作为系统服务运行，它启动的子进程默认就是后台进程，不受用户登录会话的影响——即使用户注销EC2，Run Command启动的程序也会继续运行，这是为了保证命令执行的稳定性，但也导致了你看到的“后台运行”现象。

三、可行的解决建议 #

针对你的场景，我建议试试这几个方案：

• 显式加载环境变量：在批处理开头手动加载你本地用户的环境变量（比如Windows下可以调用call "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\aws.cmd"，或者直接指定AWS CLI的配置文件路径：aws configure set aws_access_key_id YOUR_KEY --profile default），确保反向调用时的上下文和手动运行一致。
• 改用SSM Session Manager执行：如果你的批处理需要交互式上下文，用Session Manager连接到EC2后再执行批处理，这样会话和你手动登录的上下文一致，反向调用大概率能正常工作。
• 添加详细日志输出：在批处理里给反向send-command的命令加上>> log.txt 2>&1（Windows），把所有输出和错误都写入日志文件，这样就能排查到底是命令没执行、认证失败还是网络问题。
• 检查Bamboo的入站规则：虽然你说权限没问题，但还是要确认Bamboo Server的安全组/防火墙是否允许EC2的SSM Agent所在的IP（或者EC2的公网IP）发起请求——有时候手动运行用的是EC2的用户会话网络，而Run Command用的是Agent的服务网络，可能存在细微差异。

内容的提问来源于stack exchange，提问作者J_sdev