运行ImageBuilder流水线时ssm:SendCommand为何报InvalidInstanceId错误？

排除IAM角色后的其他排查方向 #

• 验证实例的SSM Agent状态与版本
  就算VPC端点和安全组配置都正确，实例上的SSM Agent未运行或版本过旧，照样会触发InstanceId无效报错。可按以下方式检查：

  • 手动启动实例后，登录执行systemctl status amazon-ssm-agent（Linux），或在Windows服务列表中查看「Amazon SSM Agent」运行状态
  • 执行amazon-ssm-agent -version查看版本，旧版本可能存在与SSM服务的兼容性问题，必要时手动更新Agent

• 检查实例的EC2元数据访问配置
  实例需要访问EC2元数据服务（IMDS）获取自身实例ID和SSM所需凭证，若IMDS被禁用或配置限制，会导致Agent无法注册到SSM：

  • 进入EC2控制台实例详情的「元数据」标签，确认「元数据服务」处于启用状态
  • 若使用IMDSv2，需确保Agent版本支持（新版本默认兼容），且实例能正常获取元数据令牌

• 确认ImageBuilder流水线的实例配置

  • 检查流水线使用的AMI是否预装SSM Agent：部分自定义AMI可能未默认安装Agent，导致实例启动后无法被SSM识别
  • 验证流水线指定的实例类型在当前区域支持，且无资源配额限制（比如配额不足导致实例未成功创建，自然会出现InstanceId无效）
  • 检查流水线的VPC和子网配置：需确保子网为公有子网，或私有子网已配置NAT网关，保证实例能正常联网获取SSM Agent更新（若有需要）

• 检查SSM服务的区域一致性
  必须保证ImageBuilder流水线、SSM服务、VPC端点处于同一区域，跨区域调用会直接导致InstanceId无法被识别

User-Data脚本不生效的问题排查 #

• ImageBuilder的User-Data执行逻辑
  ImageBuilder每次运行流水线都会重新创建实例，使用的是流水线配置中设置的User-Data，手动在EC2控制台修改停止实例的User-Data完全无效，新实例不会继承该设置

• User-Data脚本的格式与权限

  • 脚本开头必须添加正确的shebang，比如Linux脚本需加#!/bin/bash
  • 脚本需具备执行权限，可在脚本内添加chmod +x $0，或确保流水线传递的脚本权限配置正确
  • 避免使用需要交互式输入的命令，ImageBuilder实例启动为无交互环境

• 查看脚本执行日志定位问题
  实例启动后可通过以下日志查看User-Data执行情况：

  • Linux：查看/var/log/cloud-init.log 和 /var/log/cloud-init-output.log
  • Windows：查看C:\ProgramData\Amazon\EC2-Windows\Launch\Logs\CloudInit.log
    从日志中可确认脚本是否被执行，以及具体报错信息

• 替代方案：使用ImageBuilder自定义组件
  与其依赖User-Data，直接创建ImageBuilder自定义组件更可靠。组件可灵活控制执行时机和步骤，且能与流水线生命周期深度集成，避免User-Data的执行顺序或环境兼容问题

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