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 action

IAM 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ê chamou Query ou ela está totalmente ausente.
  • O recurso ARN não corresponde — a política permite table/Orders, mas você está consultando um índice (precisa de table/Orders/index/*) ou uma tabela diferente.
  • Um Deny explí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

  1. Conceda à ação exata os nomes das mensagens, para o recurso exato ARN. Inclua o índice ARNs (.../index/*) ao consultar um GSI/LSI.
  2. Verifique se há uma negação predominante — limites de permissão e permissões de batida de SCPs.
  3. Verifique se as condições detalhadas (dynamodb:LeadingKeys etc.) realmente correspondem à sua solicitação.
  4. 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: ⌘KAbrir 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

Fontes

Trabalhe com o DynamoDB sem o Console

Um cliente desktop rápido para DynamoDB que roda o SQL de verdade que o DynamoDB não consegue — JOINs, GROUP BY, agregações — com edição visual e um agente de IA com suas próprias chaves do Bedrock.

Teste grátis de 30 dias, sem cartão de crédito — depois o plano Grátis sem limite de tempo.