部署在VPC公有子网的Lambda同时访问EC2容器与Bedrock的问题

1. 用VPC端点（Interface类型）访问Bedrock（最优解） #

Lambda在VPC内调用Bedrock超时的核心原因是：公有子网内的Lambda默认没有直接访问AWS托管服务的合规路径（除非配置NAT网关或VPC端点）。无需创建6个NAT网关，直接为Bedrock创建Interface类型的VPC端点即可解决问题：

• 在VPC控制台中，创建Bedrock的Interface端点，仅选择Lambda所在的公有子网（无需覆盖全部6个子网）
• 确保Lambda的安全组允许向Bedrock端点的IP/安全组发起出站请求
• 配置完成后，Lambda可在VPC内部直接调用Bedrock，无需走公网，彻底解决超时问题，也无额外NAT成本

2. 自动化维护Lambda公网IP范围，安全开放容器端口 #

如果必须保留容器的公网访问权限，同时限制仅Lambda可访问，可通过自动化脚本定期更新EC2安全组规则：

• 编写一个辅助Lambda函数，定期拉取AWS发布的IP范围文件，过滤出当前区域下Lambda服务的IP段
• 用AWS SDK（如boto3）自动更新EC2容器所在安全组的入站规则，替换旧的Lambda IP段
• 给这个辅助Lambda配置每日触发的定时规则，确保IP范围随AWS的更新自动同步
• 这种方式既保证容器端口仅对Lambda开放，又避免了手动维护IP范围的繁琐

3. 调整EC2容器网络位置，实现VPC内闭环访问 #

将EC2实例迁移到VPC的私有子网，让Lambda和容器在VPC内部直接通信：

• 把运行Docker容器的EC2实例迁移到私有子网（保留原有容器配置）
• 给EC2的安全组添加入站规则，仅允许Lambda所在安全组访问容器端口
• 同时为Lambda配置Bedrock的VPC端点，实现所有流量都在VPC内部流转
• 该方案完全避免公网暴露，安全性最高，也无需处理IP范围的动态变更问题

最后：仅万不得已时考虑的方案 #

将Lambda迁移到同VPC的Docker容器中，确实会带来额外的容器化编码、运维扩缩容成本，除非上述所有方案均无法满足需求，否则不建议优先选择。

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