AWS CLI执行aws s3 ls报AccessDenied 控制台访问正常问题

• 最常见的诱因是CLI本地凭证和你授权的IAM用户不匹配：既然用该IAM用户登录控制台可以正常查看桶列表，说明你策略里s3:ListAllMyBuckets的授权本身是生效的。CLI调用ListBuckets报AccessDenied，基本都是本地CLI默认加载的凭证不是这个IAM用户的——比如default配置存的是其他无权限用户/角色的AK/SK、凭证已过期，执行命令时又没指定对应profile。
• 你写的IAM策略本身有冗余错误：s3:PutObject、s3:GetObject、s3:DeleteObject都是对象级操作，授权时资源只需要填桶内对象路径arn:aws:s3:::bucket-name/*就够了，把桶本身的ARNarn:aws:s3:::bucket-name加到资源列表里属于无效写法，不会影响权限逻辑，但没必要留。
• 小概率触发场景：如果确认凭证没问题，排查下该IAM用户有没有配置权限边界、所属AWS Organization有没有配置SCP策略——这类策略如果对s3:ListAllMyBuckets加了访问来源、UA的条件限制，很容易出现控制台放行、CLI调用被拒的情况。如果本地CLI走S3网关端点访问，也要同步检查端点策略有没有放通对应操作。

1. 先确认CLI当前调用身份：执行aws sts get-caller-identity，看返回的ARN是不是你授权的目标IAM用户。如果身份不对，修改本地AWS凭证文件（Linux/macOS路径为~/.aws/credentials，Windows路径为C:\Users\<你的用户名>\.aws\credentials）的配置，或者执行S3命令时加上--profile 对应配置名参数指定身份。
2. 修正IAM策略的冗余配置，删除第二条权限语句里的桶ARN，修正后的参考策略如下：

{
    "Statement": [
        {
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation",
                "s3:ListAllMyBuckets"
            ],
            "Effect": "Allow",
            "Resource": "*",
            "Sid": "AllowAppsS3ListAccess"
        },
        {
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::bucket-name/*"
            ],
            "Sid": "AllowAppsS3Access"
        }
    ],
    "Version": "2012-10-17"
}

3. 如果身份校验正确、策略更新后还是报错，执行aws s3 ls --debug查看完整请求日志，确认请求携带的身份、会话参数符合预期，再逐一排查权限边界、SCP、VPC端点策略的拒绝规则即可。

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