AWS Athena联邦查询PostgreSQL报GENERIC_USER_ERROR连接超时

报错核心是部署在VPC内的Athena PostgreSQL连接器Lambda无法访问S3服务，具体关联两个配置问题：

1. 网络配置错误：你将Lambda部署在数据库所属的私有子网中，该子网既没有配置S3 VPC网关端点，也没有绑定NAT网关提供公网出口，Lambda发起的到s3.eu-central-1.amazonaws.com:443的请求无法路由，触发连接超时。此前可以正常浏览数据库元数据，是因为元数据浏览逻辑仅需访问同VPC内的PostgreSQL实例，不需要调用S3接口，一旦执行查询触发元数据拉取、大结果集落盘spill逻辑，就会因S3访问失败报错。
2. Spill存储桶配置无效：你将spill_bucket参数值设置为athena-spill，但S3控制台不存在同名存储桶。S3桶名是全局唯一资源，athena-spill这类通用名称早已被其他用户占用，你无法直接使用该名称作为自己的spill桶，即使网络连通后也会因桶不存在触发后续报错。

• 修复S3网络连通性，二选一即可：
  • 优先选择配置S3网关类型VPC端点：在VPC控制台创建S3网关端点，关联Lambda部署的所有子网，给Lambda绑定的安全组放开443端口到S3端点的出站权限，关联的路由表会自动将S3请求转发到AWS内部网关，无需公网访问、无额外流量费用。
  • 备选方案配置公网出口：如果需要通过公网访问S3，给Lambda所在私有子网绑定NAT网关，配置路由表将0.0.0.0/0的流量指向NAT网关，同时确认安全组、网络ACL未拦截443端口出站流量，该方案会产生NAT网关的实例与流量费用。
• 修正spill桶配置：
  • 在eu-central-1区域创建名称自定义、全局唯一的S3桶，例如data-prod-athena-spill-nina，禁止使用athena-spill这类已被占用的通用名称。
  • 给Lambda执行角色添加该S3桶的读写权限，允许连接器上传spill临时数据、读取缓存元数据。
  • 回到Lambda配置页，将spill_bucket参数更新为你新建的桶的真实名称，spill_prefix可保留默认值或自定义为桶内的路径前缀，无需与桶名保持一致。
• 验证修复：配置完成后重新执行select * from tests_summary limit 10;测试查询即可。

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