如何调试AWS Elastic Beanstalk中部署超时的.NET Core应用实例？

问题现象 #

AWS发起部署后，实例无响应，约15分钟后超时，错误信息如下：

WARN The following instances have not responded in the allowed
command timeout time (they might still finish eventually on their own): [instanceID]

操作随即终止。应用规模小、资源需求低，启动速度快，但无法从Elastic Beanstalk或CloudWatch获取终止实例的日志，调试陷入困境。

已尝试操作 #

• 重建EB环境初始失败，将实例从t2.micro升级为t2.small后环境上线，但部署旧版本应用仍失败；
• 确认AWS服务状态正常；
• 尝试更换部署类型：一次性全部部署、不可变部署、滚动部署；
• 检查安全组配置，未发现异常；
• 使用示例.NET Core应用+默认配置创建新环境，仍遇相同问题，改为t2.small后可运行，但未尝试更换应用版本。

调试过程（补充信息） #

1. 禁用EB环境滚动更新后，SSH登录正常实例观察部署过程，发现应用未上传，eb-engine.log无新日志，但cfn-hup.log出现超时错误：

2023-02-27 06:13:23,281 [INFO] command processing is alive.
2023-02-27 06:14:23,282 [WARNING] Timeout of 60 seconds breached
2023-02-27 06:14:23,282 [ERROR] Client-side timeout
Traceback (most recent call last):
  File "\/usr\/lib\/python3.7\/site-packages\/cfnbootstrap\/util.py", line 193, in _retry
    return f(*args, **kwargs)
  File "\/usr\/lib\/python3.7\/site-packages\/cfnbootstrap\/util.py", line 267, in _timeout
    "Execution did not succeed after %s seconds" % duration)
cfnbootstrap.util.TimeoutError
2023-02-27 06:15:24,249 [WARNING] Timeout of 60 seconds breached
2023-02-27 06:15:24,249 [ERROR] Client-side timeout
Traceback (most recent call last):
  File "\/usr\/lib\/python3.7\/site-packages\/cfnbootstrap\/util.py", line 193, in _retry
    return f(*args, **kwargs)
  File "\/usr\/lib\/python3.7\/site-packages\/cfnbootstrap\/util.py", line 267, in _timeout
    "Execution did not succeed after %s seconds" % duration)
cfnbootstrap.util.TimeoutError

2. 定位根源：配置的Lambda与SQS通信的VPC端点导致CloudFormation的cfn-hup服务超时（该服务负责响应实例配置变更）。删除端点后部署恢复正常，但存在两个疑问：
   • 删除VPC端点后，Lambda是否还能正常工作？
   • VPC已配置互联网网关，为何当初需要配置这个VPC端点？

问题解答 #

关于调试终止实例的方法 #

无法直接启动已终止的EC2实例，但可以通过以下方式获取调试信息：

• 启用Elastic Beanstalk的实例日志留存：在EB环境配置中开启日志持久化，将实例日志同步到S3，即使实例终止也能查看；
• 使用不可变部署：这种部署方式会创建新实例，失败时旧实例不会被终止，可SSH登录新实例排查；
• 手动创建EC2实例，复制EB环境的IAM角色、安全组、VPC配置，部署应用并调试。

VPC端点相关疑问解答 #

1. Lambda与SQS通信的VPC端点作用
   当Lambda运行在VPC内时，访问SQS有两种方式：

• 通过互联网网关：Lambda需绑定公有子网，或私有子网配置NAT网关访问公网SQS；
• 通过VPC端点：无需公网访问，直接在VPC内通过AWS私有网络连接SQS，更安全且避免公网带宽成本。
  你之前配置端点可能是为了让VPC内的Lambda无需公网即可访问SQS，但端点配置可能存在路由冲突或权限问题，导致cfn-hup服务无法正常与CloudFormation通信。

2. 删除端点后Lambda能否正常工作

• 若Lambda运行在公有子网且安全组允许出站访问公网，同时互联网网关配置正常，Lambda可以通过公网访问SQS；
• 若Lambda运行在私有子网，则需要配置NAT网关才能通过互联网访问SQS，否则会无法连接。

3. 如何解决cfn-hup超时与Lambda访问SQS的矛盾

• 检查VPC端点的路由表配置：确保仅SQS的流量通过VPC端点，cfn-hup需要的CloudFormation服务流量仍通过互联网网关或配置CloudFormation的VPC端点；
• 配置端点的安全组：允许EC2实例（EB环境）与端点的通信，同时确保cfn-hup能访问CloudFormation服务；
• 验证端点的策略：确保权限配置正确，不会拦截必要的服务通信。

内容的提问来源于stack exchange，提问作者Ben Zuill-Smith