AWS Windows EC2实例启动时自动运行Python SQS订阅脚本的配置问题

• 触发逻辑认知偏差：带<persist>true</persist>标记的用户数据，仅在实例首次从AMI完成初始化的启动流程中被EC2Launch读取执行；如果是对已经运行过的旧实例修改用户数据、或是实例执行普通重启（未触发首次初始化流程），EC2Launch不会主动扫描执行用户数据，这是脚本不运行的核心原因。persist标记的实际作用是：当实例完成首次初始化后，后续每次重启时EC2Launch会重复执行已写入的持久化脚本，而非任何状态下的用户数据修改都会被触发。
• 语法格式错误：
  1. 若粘贴的用户数据中包含<、>这类HTML转义字符，系统无法识别合法的XML结构，会直接解析失败跳过整个用户数据内容，不会生成任何执行日志。你贴的示例代码是文档中经过HTML转义后的展示内容，实际输入到用户数据文本框时需要直接使用尖括号标签，不能保留转义字符。
  2. 直接用<script>包裹cmd命令时，部分版本的EC2Launch无法自动识别调用的解释器，需要在脚本块前显式指定调用cmd.exe /c，否则脚本会被静默跳过。
• 日志路径认知偏差：你查找的C:\ProgramData\Amazon\EC2-Windows\Launch\Log是EC2Launch v2版本的默认日志路径；如果实例搭载的是旧版EC2 Config服务（v1），日志默认存储在C:\Program Files\Amazon\Ec2ConfigService\Logs路径下，找错路径自然无法看到执行记录。

依赖带persist标签的EC2用户数据实现开机自启，不是匹配该需求的最优方案，主要短板包括：

• 触发时机不可控：用户数据脚本在实例启动的极早期阶段执行，此时网络栈、Python运行环境、依赖服务往往还未完全就绪，极易出现SQS连接失败、脚本路径加载异常等问题，且没有内置的等待就绪的机制。
• 维护灵活性差：后续修改自启脚本的逻辑、调整配置时，需要停止实例、修改用户数据配置、再重启实例，无法像系统本地配置那样直接在实例内部调整，运维成本高。
• 容错能力不足：用户数据执行的脚本没有内置崩溃自动重启、运行状态监控的能力，一旦Python脚本异常退出，没有机制会自动把进程拉起来，不符合长期运行的订阅端程序的可靠性要求。

• 将Python SQS订阅脚本封装为Windows系统服务
  通过nssm这类轻量工具，将Python脚本注册为后台系统服务，设置服务启动类型为“自动（延迟启动）”。该方式不仅可以实现实例开机、重启后自动运行脚本，还支持配置进程崩溃自动重启、固定运行权限、日志持久化输出，完全适配长期运行的服务类程序的需求，是Windows环境下跑后台脚本的最稳定方案。
• 配置Windows任务计划程序实现启动触发
  无需安装第三方工具，直接打开系统自带的任务计划程序，新建计划任务：触发条件设置为“系统启动时”，操作项指向Python解释器的绝对路径+订阅脚本的存储路径，勾选“不管用户是否登录都要运行”“进程启动失败后按间隔重试”选项。该方式可控性强，还可以灵活配置脚本运行的环境变量、权限要求，适合不想引入额外工具的场景。
• 修正后的用户数据配置（仅作为辅助逻辑使用）
  如果需要搭配用户数据完成初始化配置，需要满足两个前提：一是必须在实例首次创建时就把正确的用户数据写入配置，运行中修改的用户数据不会在普通重启时触发；二是修正语法为可被EC2Launch正确识别的结构，示例如下：

  <script>
  cmd.exe /c "echo Current date and time >> %SystemRoot%\Temp\test.log"
  cmd.exe /c "echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log"
  </script>
  <persist>true</persist>
  

  执行后需要根据实例上安装的EC2Launch版本，到对应路径下查看执行日志。

内容的提问来源于stack exchange，提问作者Marco Antonio Vélez