DynamoDB AccessDeniedException — o erro "not authorized to perform dynamodb:..."
TL;DR — Seu usuário IAM/role não tem permissão para a ação DynamoDB nesse recurso. A mensagem nomeia a ação dynamodb: exata e ARN — adicione essa ação para esse recurso ARN à política IAM da identidade (e verifique se há uma Negação ou uma condição que a bloqueie).
O que significa
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 negou a chamada. A mensagem é uma lista de verificação: ela nomeia o principal, a ação e o recurso — todos os três devem ser permitidos sem nenhuma negação explícita. A cláusula final nomeia o tipo de política que negou o acesso (política baseada em identidade, SCP, limite de permissões, política de sessão,…). DynamoDB retorna com status HTTP 400 e não é possível tentar novamente – a mesma solicitação falha até que a política (ou a identidade) seja alterada.
Por que isso acontece
- A ação não é permitida — a política concede
dynamodb:GetItem, mas você chamouQueryou ela está totalmente ausente. - O recurso ARN não corresponde — a política permite
table/Orders, mas você está consultando um índice (precisa detable/Orders/index/*) ou uma tabela diferente. - Um
Denyexplícito em algum lugar (um limite de permissão, SCP ou a própria política) substitui a permissão. - Uma condição de política não foi atendida (acesso refinado
dynamodb:LeadingKeys, IP de origem, MFA). - Credenciais erradas — a função que você assumiu não é aquela com acesso.
Como corrigir
- Conceda à ação exata os nomes das mensagens, para o recurso exato ARN. Inclua o índice ARNs (
.../index/*) ao consultar um GSI/LSI. - Verifique se há uma negação predominante — limites de permissão e permissões de batida de SCPs.
- Verifique se as condições detalhadas (
dynamodb:LeadingKeysetc.) realmente correspondem à sua solicitação. - Confirme a identidade com
aws sts get-caller-identity— certifique-se de que é o principal que você pensa que é.
Exemplo de política
{
"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/*"
]
}
]
}Abra no DynoTable
DynoTable resolve o mesmo perfil ~/.aws que sua CLI usa em todas as conexões
(Conecte uma conta AWS), então quando você consertar IAM ou trocar
perfis, o aplicativo o seleciona sem reiniciar. Pressione ⌘P para abrir o
alternador de perfil e confirme qual identidade está ativa - o ponto de status da credencial
fica vermelho com uma ação embutida Reconectar quando os tokens expiram no meio da sessão.
Se sua política negar dynamodb:ListTables, mas permitir leituras em uma tabela nomeada,
DynoTable ainda pode abrir essa tabela diretamente: ⌘K → Abrir tabela por
nome pula a chamada da lista e vai direto para GetItem/Query na tabela
você digita. Assim que o acesso funcionar, o visual construtor de consultas
deriva Query-vs-Scan de suas pílulas de filtro para que você possa provar que a política permite
a operação que você precisa. Se o erro nomear um GSI/LSI ARN, conceda dynamodb:Query
no table/YourTable/index/* – permissões de índice são uma falha comum quando em nível de tabela
permite parecer correto.
Erros relacionados
- O token de segurança é inválido — credenciais /expired ruins (vs. credenciais válidas sem permissão).
- Região ausente na configuração
- Aprenda: Executando o DynamoDB Local — desenvolva localmente onde as políticas do IAM não se aplicam.
Fontes
- Solucionar problemas de mensagens de erro de acesso negado - Guia do usuário IAM (verificado em 13/07/2026)
- Uso das condições da política IAM para controle de acesso refinado — Guia do desenvolvedor do Amazon DynamoDB (verificado em 13/07/2026)
- Tratamento de erros com DynamoDB — Guia do desenvolvedor do Amazon DynamoDB (verificado em 13/07/2026)