默认VPC公有子网Lambda访问SQS超时及兼容方案咨询

核心原因 #

• Lambda部署到VPC内后，默认无公网访问能力（除非配置NAT网关/实例），直接访问SQS公网端点会超时。
• 新增SQS VPC终端节点后EC2无法访问SQS，大概率是终端节点的安全组、路由表或资源策略限制了EC2的流量。

具体解决方案 #

方案一：给Lambda配置NAT网关（无需改动现有终端节点） #

如果不想调整现有VPC终端节点，给Lambda所在子网配置NAT网关，让Lambda通过NAT访问公网SQS：

• 在Lambda所在子网的路由表中添加0.0.0.0/0指向NAT网关的路由条目。
• 确认NAT网关所在的公网子网已配置互联网网关（IGW）路由，且NAT网关状态正常。
• 这种方式不会影响EC2原有SQS访问逻辑，EC2仍使用原来的路径访问。

方案二：修复SQS VPC终端节点配置（推荐，更安全） #

若要保留VPC终端节点，调整配置让Lambda和EC2都能正常访问：

• 安全组调整：给SQS终端节点的安全组添加入站规则，允许Lambda、EC2所在安全组的TCP 443流量（SQS基于HTTPS通信）。
• 路由表调整：
  • 给Lambda所在子网的路由表添加条目：目标为SQS服务的前缀列表（可在VPC终端节点页面查看），下一跳指向SQS终端节点。
  • 确保EC2所在子网的路由表未被强制将0.0.0.0/0指向终端节点，保留原有公网路由或仅添加SQS前缀列表路由即可。
• 终端节点策略调整：检查SQS终端节点的资源策略，确保允许Lambda的执行角色、EC2实例的IAM角色执行sqs:*相关操作。

方案三：拆分Lambda网络配置（特殊场景） #

如果DB和SQS的访问需求可分离，可拆分Lambda：

• 一个部署在VPC内，专门处理DB访问。
• 一个部署在VPC外，专门处理SQS访问。
• 通过Lambda间调用串联业务逻辑，完全隔离网络，但会增加架构复杂度。

.NET Core代码注意事项 #

确保AWSSDK.SQS未强制指定公网端点，让SDK自动适配网络环境：

// 不要手动设置ServiceURL为公网地址，让SDK自动选择VPC终端节点或公网端点
var sqsClient = new AmazonSQSClient();

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