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/* — 表級索引許可權是一個常見的缺失允許看起來正確。
相關錯誤
- 安全權杖無效——憑證錯誤/過期（相對於有效憑證但沒有許可權）。
- 設定中缺少區域
- 學習：Running DynamoDB Local——在 IAM 策略不適用的本地環境中開發。