我来帮你梳理下这个跨账户S3权限的常见问题点，大概率是几个容易忽略的细节导致的：

1. 资源路径的通配符错误 #

你策略里的Resource字段写的是"arn:aws:s3:::bucket-name/..."，这里的...是无效的通配符——AWS S3策略只认可*作为全匹配符号。要授予整个桶+桶内所有对象的权限，必须明确写两个资源：

• 桶本身：arn:aws:s3:::bucket-name
• 桶内所有对象：arn:aws:s3:::bucket-name/*

2. 跨账户访问的身份验证逻辑 #

你用了角色ARN作为Principal，但要注意：对方账户的用户不能直接用自己的IAM身份访问，必须先通过sts:AssumeRole操作切换到你创建的这个角色，获取临时凭证后才能访问S3。如果对方直接用自身用户权限尝试下载，肯定会被拒绝。

3. 存储桶公共访问阻止的冲突 #

检查S3存储桶的「Block Public Access」设置，尤其是以下两项：

• Block public access to buckets and objects granted through any access control lists (ACLs)
• Block public access to buckets and objects granted through new access control lists (ACLs)
  如果这两项处于开启状态，可能会和你的桶策略权限冲突，导致权限不生效。

4. ARN与策略语法正确性 #

• 确认角色ARN里的账户ID是正确的（比如arn:aws:iam::123456789012:role/user1里的123456789012是对方的真实账户ID）
• 用IAM控制台的「策略验证器」检查JSON语法是否有错误（比如逗号缺失、括号不配对等）

5. 对象级ACL的优先级 #

如果桶内的文件是之前上传的，它们默认的ACL可能只有上传者拥有权限。你可以：

• 上传一个新的测试文件，验证桶策略是否生效
• 批量修改现有对象的ACL，让桶的所有者（你的账户）拥有完全控制权限，这样桶策略的权限才能覆盖到对象

修正后的示例桶策略 #

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountFullAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::ACCOUNT-ID-1:role/user1",
          "arn:aws:iam::ACCOUNT-ID-2:role/user2"
        ]
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::bucket-name",
        "arn:aws:s3:::bucket-name/*"
      ]
    }
  ]
}

对方账户用户的访问方式示例（AWS CLI） #

对方需要先执行角色切换命令获取临时凭证：

aws sts assume-role --role-arn "arn:aws:iam::YOUR-ACCOUNT-ID:role/user1" --role-session-name "S3AccessSession"

然后用返回的AccessKeyId、SecretAccessKey、SessionToken作为临时凭证，再执行S3下载操作。

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