DynamoDB AccessDeniedException — "not authorized to perform dynamodb:..."
TL;DR — 你的 IAM 用户/角色没有对该资源执行相应 DynamoDB 操作的权限。消息会指明确切的 dynamodb: 操作和 ARN——把该操作针对该资源 ARN 添加到该身份的 IAM 策略中（并检查是否存在阻断它的 Deny 或条件）。
含义
AccessDeniedException: User: arn:aws:iam::123456789012:user/app is not authorized to
perform: dynamodb:Query on resource: arn:aws:dynamodb:us-east-1:123456789012:table/Orders
because no identity-based policy allows the dynamodb:Query actionIAM 拒绝了这次调用。这条消息就是一份清单：它指明了主体、操作和资源——三者都必须被允许且没有显式 Deny。末尾的从句指明了拒绝访问的策略类型（基于身份的策略、SCP、权限边界、会话策略……）。DynamoDB 以 HTTP 状态码 400 返回它，且不可重试——在策略（或身份）改变之前，同样的请求会一直失败。
为什么会发生
- 操作未被允许——策略授予了
dynamodb:GetItem，但你调用的是Query，或者根本没有授予。 - 资源 ARN 不匹配——策略允许
table/Orders，但你查询的是一个索引（需要table/Orders/index/*）或另一张表。 - 某处存在显式
Deny（权限边界、SCP 或策略本身）覆盖了 allow。 - 某个策略条件未被满足（
dynamodb:LeadingKeys细粒度访问、源 IP、MFA）。 - 凭证不对——你担任的角色并不是有访问权限的那个。
如何修复
- 授予消息中指明的确切操作，针对确切的资源 ARN。查询 GSI/LSI 时要包含索引 ARN（
.../index/*）。 - 检查是否存在覆盖性的 Deny——权限边界和 SCP 会压过 allow。
- 核实细粒度条件（
dynamodb:LeadingKeys等）确实与你的请求匹配。 - 用
aws sts get-caller-identity确认身份——确保它就是你以为的那个主体。
Example policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:PutItem"],
"Resource": [
"arn:aws:dynamodb:us-east-1:123456789012:table/Orders",
"arn:aws:dynamodb:us-east-1:123456789012:table/Orders/index/*"
]
}
]
}在 DynoTable 中打开
DynoTable 解析 CLI 在每个连接上使用的相同 ~/.aws 配置文件
(Connect an AWS account)，所以当你修复 IAM 或切换时配置文件应用程序无需重新启动即可拾取它。按⌘P打开配置文件切换器并确认哪个身份处于活动状态 - 凭证状态点当令牌在会话中失效时，会通过内联 重新连接 操作变为红色。如果你的策略拒绝 dynamodb:ListTables 但允许读取指定表，
DynoTable 仍然可以直接打开该表： ⌘K → 打开表
name 跳过list调用，直接到桌子上的GetItem/Query
你输入。一旦访问成功，视觉query builder
从你的过滤药丸中得出 Query-vs-Scan，以便你可以证明政策允许你需要的操作。如果错误命名为 GSI/LSI ARN，则授予 dynamodb:Query
on table/YourTable/index/* — 表级索引权限是一个常见的缺失允许看起来正确。
相关错误
- 安全令牌无效——凭证错误/过期（相对于有效凭证但没有权限）。
- 配置中缺少 region
- 学习：Running DynamoDB Local——在 IAM 策略不适用的本地环境中开发。