启用增强VPC路由的Redshift集群用Spectrum访问Glue遇S3超时错误

为什么UNLOAD正常但Spectrum查询失败？ #

Redshift的UNLOAD和Spectrum的流量路径完全不同：

• UNLOAD操作是Redshift集群节点直接发起请求到S3，你启用了增强VPC路由后，Redshift会通过S3的VPC终端节点走私有网络访问S3，只要终端节点、路由表、桶策略配置正确，就能正常工作。
• Spectrum查询是由Redshift托管的外部执行节点发起请求到S3和Glue。官方明确标注：预留集群的增强VPC路由不支持Spectrum——这意味着Spectrum的执行节点无法通过你的VPC终端节点访问私有S3，它会尝试走公网，但你的S3桶仅允许VPC终端节点访问，因此出现连接超时（错误码15007）。

私有S3+Glue+Redshift Spectrum的实践方案 #

方案1：切换到Redshift按需集群（长期推荐） #

官方文档明确支持按需集群的增强VPC路由与Spectrum兼容，迁移后：

• Spectrum执行节点会通过你的VPC终端节点访问S3和Glue，所有流量保持在私有网络内
• 完全符合S3桶的访问控制策略
  迁移步骤：创建按需集群，通过快照恢复数据，切换应用连接即可。

方案2：临时禁用增强VPC路由（仅测试/短期场景） #

如果业务允许临时调整，关闭增强VPC路由后，Spectrum会走公网访问S3和Glue，但需要：

• 更新S3桶策略，允许redshift-spectrum.amazonaws.com服务主体访问
• 确保Glue服务允许公网访问（或配置对应公网权限）
  注意：此方案会让Redshift的COPY/UNLOAD等操作也走公网，可能不符合私有网络要求，仅适合验证问题根源。

方案3：中间桶同步（折中方案） #

若无法切换集群类型，可创建一个允许Spectrum公网访问的中间S3桶，通过Lambda或Glue Job将私有桶的数据同步到中间桶，Spectrum查询中间桶的数据。但此方案会增加数据复制成本和同步延迟，仅适合特定场景。

方案4：排查VPC终端节点配置细节 #

即使预留集群不支持Spectrum的增强VPC路由，也可检查以下配置排除其他问题：

• 确认Glue的VPC终端节点（com.amazonaws.<region>.glue）已部署，路由表指向该节点，安全组允许Redshift和Spectrum访问
• 确认S3的网关终端节点已配置，路由表添加S3前缀列表指向该节点
• 检查S3桶策略是否正确允许Redshift集群IAM角色、Glue服务角色及Spectrum服务主体的访问

关键注意点 #

• 增强VPC路由对Redshift内部操作（COPY/UNLOAD）和Spectrum操作的支持是分离的，前者在预留集群中正常，后者是官方明确的限制
• 错误码15007（S3CurlException）核心原因是Spectrum无法建立到S3的有效网络连接，要么路由不通，要么访问权限被拒

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