从Redshift读取S3 Table型Iceberg表时间歇性出现403错误

问题场景 #

通过IAM角色登录（本地SQL Workbench使用JDBC且groupfederation=true，或AWS查询控制台选择“使用IAM身份的临时凭证”），执行以下INSERT语句从Iceberg S3表导入数据到原生Redshift表：

insert into myschema.mytable
select * from "dev-raw-data@s3tablescatalog".myschema.mytable;

操作间歇性失败，报错信息：

Forbidden: HTTP response error code: 403 Message: AccessDenied S3 Tables does not support presigned URLs

重试一段时间后可恢复正常。已确认：

• IAM角色配置了正确的S3 Table、Lake Formation访问权限，且在Lake Formation中拥有超级权限
• Iceberg表由具备Lake Formation权限的Lambda函数通过PyIceberg填充

关键反常点：S3 Tables本应通过Lake Formation短期临时凭证访问，而非预签名URL，怀疑是Redshift Bug，但希望先排查其他可能。

排查方向 #

• 临时凭证生命周期冲突：检查IAM角色临时凭证的过期时间，以及Redshift会话中凭证的刷新逻辑。若凭证快过期时发起请求，可能触发Redshift异常 fallback 到预签名URL的逻辑。可尝试缩短Redshift会话时长，或确保操作期间凭证处于有效期内。
• Lake Formation权限缓存延迟：Lake Formation的权限策略可能存在缓存延迟，导致间歇性权限校验异常。尝试重新应用角色权限策略，手动触发权限同步，观察报错频次是否降低。
• Redshift集成版本/配置问题：确认Redshift集群版本是否支持最新Iceberg集成特性，检查JDBC连接参数是否遗漏Lake Formation相关配置。同时排查集群级S3访问配置是否存在冲突（比如全局强制预签名URL的逻辑）。
• 并发操作冲突：Lambda函数的PyIceberg表填充操作，若与Redshift的INSERT操作并发，可能在表元数据更新时触发异常访问路径。尝试错开两个操作的时间窗口，观察报错是否消失。
• Redshift会话状态异常：间歇性问题可能与会话状态有关，报错后重建会话（比如重新连接SQL Workbench、新开控制台查询窗口），若能立即恢复，可辅助判断为会话级异常。

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