已配置AmazonDynamoDBFullAccess权限，执行DynamoDB批量写入仍遇AccessDeniedException

这种explicit deny的问题其实挺棘手的，哪怕你给用户加了AmazonDynamoDBFullAccess全权限也没用——因为IAM权限体系里，明确拒绝（Explicit Deny）的优先级是最高的，只要有任何一条策略（不管是用户直接附加的、组的、组织SCP还是资源策略）包含拒绝规则，都会直接阻止操作。我帮你梳理几个必查的方向：

1. 检查用户直接附加的IAM策略 #

先去IAM控制台找到你的Mehran用户，查看所有直接绑定的策略。重点找有没有包含Deny动作的策略，尤其是针对dynamodb:BatchWriteItem或者arn:aws:dynamodb:us-east-1:********:table/History这个资源的拒绝规则。有些自定义策略可能藏得比较深，比如限制IP访问、特定时间段操作的策略，刚好触发了拒绝条件。

2. 检查所属IAM组的策略 #

如果你的用户属于某个IAM组，一定要检查组上的所有策略。组策略和用户直接策略的优先级是平等的，只要组里有一条明确拒绝，同样会生效。别漏掉这一步，很多人会忽略组层面的权限限制。

3. 排查AWS组织的服务控制策略（SCP） #

如果你的账号是AWS组织的成员账号，那组织层面的SCP（服务控制策略）可能会锁死权限。SCP是作用于整个账号的，会覆盖用户/组的所有权限配置。去AWS Organizations控制台，查看当前账号的SCP列表，看看有没有包含DynamoDB:BatchWriteItem的拒绝规则，或者更宽泛的拒绝策略（比如拒绝所有DynamoDB写入操作）。

4. 检查DynamoDB表的资源策略 #

除了IAM用户/组策略，DynamoDB表本身也可以设置资源策略。去DynamoDB控制台找到History表，切换到「权限」标签，查看表的资源策略。如果里面有针对你的用户ARN（arn:aws:iam::********:user/Mehran）的拒绝条目，也会导致这个错误。

5. 验证临时凭证的会话策略（如果使用的话） #

如果你是通过STS获取临时凭证来执行CLI命令，那会话策略里的拒绝规则也会生效。哪怕你的用户本身有权限，会话策略的明确拒绝会直接覆盖。可以检查一下生成临时凭证时附带的策略内容。

快速定位问题的工具 #

推荐用AWS CLI的权限模拟命令来快速定位哪条策略导致了拒绝：

aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::********:user/Mehran --action-names dynamodb:BatchWriteItem --resource-arns arn:aws:dynamodb:us-east-1:********:table/History

这个命令会返回所有影响该权限的策略，包括允许和拒绝的条目，你能直接看到是哪条策略触发了Explicit Deny。

找到对应的拒绝策略后，要么修改策略移除拒绝规则，要么调整条件（比如如果是IP限制，确保你的CLI请求IP在允许范围内），就能解决这个问题了。

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