跨账号访问S3时Lambda可list_objects但download_file报Access Denied问题

• KMS密钥权限缺失：这是最常见的诱因。如果你的S3桶启用了SSE-KMS默认加密，或者待下载的对象是用KMS密钥加密的，列表操作（对应s3:ListBucket权限）不需要调用KMS接口，但是下载对象的GetObject操作需要对加密密钥有kms:Decrypt权限。需要确认账户B的Lambda执行角色，已经被添加到账户A对应KMS密钥的密钥策略允许列表中，授予解密权限。
• 对象路径/键名错误：S3出于安全防护逻辑，访问不存在的对象时，如果你有s3:ListBucket权限也可能返回AccessDenied避免对象被枚举，先确认你调用download_file时传入的对象键拼写、大小写完全和实际存储一致。
• Allow规则匹配异常：你桶策略中允许规则的触发条件是awsuserId匹配指定列表，Lambda使用角色发起请求时awsuserId的格式为[角色唯一ID]:[Lambda运行时会话名]，如果你配置的列表中仅写了角色ID没有添加通配符后缀（例如AROAXXXXXXXXXX:*），可能出现部分请求匹配失败的问题。

默认场景下不需要额外配置ACL。S3的权限评估优先级为：显式拒绝 > 桶策略/IAM策略显式允许 > ACL允许，只要桶策略已经明确授予了跨账号身份对应的操作权限，ACL的配置不会影响权限生效。
仅两种特殊场景需要额外配置ACL：

• 桶的对象所有权规则设置为「对象写入者拥有」：此时跨账号写入的对象默认归属写入方账号，桶所属账号默认无法访问，需要写入对象时设置bucket-owner-full-controlACL；如果将对象所有权调整为「桶所有者强制」模式，就可以完全不需要配置ACL。
• 你的权限体系是基于ACL实现的旧架构，这种情况才需要保留ACL配置，否则AWS官方现在推荐优先使用桶策略+IAM策略做权限管控，可直接关闭桶的ACL功能。

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