CodeDeploy蓝绿部署失败求助：原环境EC2实例启动异常

一、挖掘EC2实例启动的底层日志信息 #

• 查看EC2系统日志：在EC2控制台定位故障实例，进入「监控」->「获取系统日志」，这里会记录实例启动阶段的内核加载、AMI初始化、启动脚本执行等细节，CodeDeploy控制台日志未覆盖的启动问题通常能在此找到线索。
• 检索CloudTrail事件：搜索该实例相关的RunInstances、StartInstances事件，排查是否存在IAM权限不足、资源配额（如vCPU、内存）耗尽等问题，这类故障不会在CodeDeploy日志中直接体现。
• 检查SSM Agent日志（若实例已安装）：登录实例后查看/var/log/amazon/ssm/amazon-ssm-agent.log，验证实例启动后与AWS服务的连接状态，异常连接可能导致CodeDeploy生命周期钩子执行失败。

二、排查蓝绿部署策略的配置细节 #

• 验证部署组原环境保留规则：确认蓝绿部署的「原环境终止行为」是否为「保留」或「延迟终止」，若设置为立即终止，可能导致原环境实例被强制终止后重启失败；同时检查部署组的生命周期钩子，是否存在未正确配置的钩子在实例启动阶段触发异常。
• 检查Auto Scaling Group（ASG）策略：若原环境实例属于ASG，确认ASG的实例替换、健康检查阈值设置是否合理，过严的健康检查可能导致实例刚启动就被判定为不健康，触发重启循环。

三、验证部署包与启动脚本的兼容性 #

• 检查应用启动脚本权限与依赖：确认部署包中的启动脚本是否具备执行权限，是否存在依赖缺失（如系统库、第三方工具），即使AMI配置正常，脚本执行失败也会导致实例无法进入健康状态，被CodeDeploy标记为故障。
• 手动模拟启动流程：手动创建一台与原环境同配置（AMI、安全组、网络）的EC2实例，手动执行部署包中的启动步骤，复现原环境实例的启动过程，以此排除CodeDeploy流程本身的问题。

四、排查AWS服务间的依赖问题 #

• 确认CodeDeploy服务角色权限：检查服务角色是否包含ec2:DescribeInstances、autoscaling:DescribeAutoScalingGroups、ssm:SendCommand等必要权限，权限缺失会导致CodeDeploy无法正确监控实例状态，误判启动失败。
• 验证VPC端点配置：若实例位于私有VPC，确认已配置EC2 Messages、SSM、CodeDeploy的VPC端点，网络连通性问题会导致实例无法与CodeDeploy通信，进而被标记为故障。

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