Redshift支持跨区域查询S3数据湖：RG与Serverless可直接读取，传输费用和计算资源仍需核算

昨天 3阅读

2026年10月1日，AWS宣布Amazon Redshift可直接查询位于其他AWS区域的S3数据湖表，并扩展相关增强VPC路由能力。两者依赖运行在RG预置集群或Redshift Serverless自身计算资源上的集成数据湖查询引擎，适用范围是这些部署形态已提供服务的区域。

先看查询跑在哪种引擎上

官方文档区分两条路径：RG与Serverless使用集成数据湖引擎，计算发生在集群或工作组自己的资源中；RA3与DC2预置集群仍使用独立计算资源上的Redshift Spectrum。后者的数据湖查询仍要求集群与S3桶在同一区域，不能仅因为产品都叫Redshift就套用新跨区域能力。

集成引擎默认启用，无需再单独打开引擎开关。但这不等于数据目录、访问角色和网络路线都已准备完成。应用仍需要能解析外部表、读取对应对象，并满足数据管理中设定的权限。

AI模型生成的概念插图：查询从一个区域访问另一区域的数据，原始数据保留在原处；不是AWS网络拓扑，也不表示查询过程没有数据传输。

过去，为了集中分析分布在不同区域的数据，团队可能先维护副本或搬运链路。新能力允许直接读取远端S3表，减少预先复制的步骤，但官方明确跨区域查询仍收取标准数据传输费用。

因此，应分别理解原始对象的存放位置与查询时的信息流动。对象保留在原区域，并不能独自证明查询结果、扫描数据或中间处理都没有跨区。对有地域使用要求的数据，本文建议先画出存储、计算和结果接收位置，再判断是否适合这种访问方式，不能只依据“不需要复制”作结论。

对频繁重复的大范围扫描，还应比较持续跨区域读取与已有数据准备方式的成本。偶尔汇总一份远端数据和每分钟重扫同一大表，可能需要不同选择。更灵活的入口并不自动让所有分析任务都适合跨区域运行。

AWS说明，在集成引擎配合增强VPC路由时，S3与Redshift之间的数据湖查询流量按配置经过自己的VPC及AWS网络。官方连接指南同时强调，查询不只访问S3对象，还需要访问AWS Glue数据目录；使用Lake Formation管理的数据，还需要相应服务可达。

这给排错提供了具体顺序：若表名可以看见但读取失败，应分别核对数据目录、对象读取和网络条件，而不是只检查数据库连接。不同查询引擎的流量路径也不同，旧Spectrum部署的配置经验不能直接当成新集成引擎已经走通的证据。

集成引擎不再产生独立Spectrum查询收费，但会使用本身的集群或工作组计算。官方特别提示，部分场景中RG查询可能比使用独立Spectrum资源的RA3更慢，需要按负载评估计算容量。不能把“少一项收费”直接当成“总费用一定下降”。

本文建议挑选一条结果可核对的跨区域查询，固定输入时间范围和字段，记录返回结果、耗时、计算负载与传输量，再观察同一时段其他仓库查询是否受影响。确认单次读取成功之后，再测试并发和重复查询，避免把一次小样本结果推广成日常吞吐保证。

这次更新适合重新审视为了读取远端数据而维护的额外搬运流程。最终是否替换，应由数据使用范围、计算竞争、传输成本与查询新鲜度共同决定，先在代表工作负载上建立清楚的对照。

资料核对：2026年10月3日（北京时间）。本文未运行实际查询，成本与验收讨论为原创分析。