DynamoDB AccessDeniedException — el error "not authorized to perform dynamodb:..."

TL;DR — Tu usuario/rol de IAM no tiene permiso para la acción de DynamoDB sobre ese recurso. El mensaje indica la acción dynamodb: y el ARN exactos — añade esa acción para ese ARN de recurso a la política de IAM de la identidad (y revisa si hay un Deny o una condición que lo bloquee).

Qué 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 denegó la llamada. El mensaje es una lista de verificación: indica el principal, la acción y el recurso — los tres deben estar permitidos sin ningún Deny explícito. La cláusula final indica el tipo de política que denegó el acceso (política basada en identidad, SCP, límite de permisos, política de sesión, …). DynamoDB lo devuelve con estado HTTP 400 y no es reintentable — la misma solicitud falla hasta que cambie la política (o la identidad).

Por qué ocurre

La acción no está permitida — la política concede dynamodb:GetItem pero llamaste a Query, o falta por completo.
El ARN del recurso no coincide — la política permite table/Orders pero estás consultando un índice (necesita table/Orders/index/*) o una tabla diferente.
Un Deny explícito en algún lugar (un límite de permisos, una SCP o la propia política) anula el allow.
Una condición de política no se cumple (acceso detallado con dynamodb:LeadingKeys, IP de origen, MFA).
Credenciales incorrectas — el rol que asumiste no es el que tiene acceso.

Cómo solucionarlo

Concede la acción exacta que indica el mensaje, para el ARN de recurso exacto. Incluye los ARN de índice (.../index/*) cuando consultes un GSI/LSI.
Revisa si hay un Deny que anule — los límites de permisos y las SCP prevalecen sobre los allow.
Verifica las condiciones detalladas (dynamodb:LeadingKeys, etc.) que realmente coincidan con tu solicitud.
Confirma la identidad con aws sts get-caller-identity — asegúrate de que es el principal que crees.

Ejemplo 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/*"
      ]
    }
  ]
}

Ábrelo en DynoTable

DynoTable resuelve el mismo Perfil ~/.aws que usa tu CLI en cada conexión (Conectar una cuenta de AWS), así que cuando corrijas IAM o cambies de Perfil la app lo recoge sin reiniciar. Pulsa ⌘P para abrir el selector de Perfiles y confirmar qué identidad está activa — el punto de estado de credenciales se pone rojo con una acción Reconnect en línea cuando los tokens caducan a mitad de sesión.

Si tu política deniega dynamodb:ListTables pero permite lecturas en una tabla con nombre, DynoTable puede abrir esa tabla directamente: ⌘K → Open table by name omite la llamada de listado y va directo a GetItem/Query en la tabla que escribas. Una vez funcione el acceso, el query builder visual deriva Query vs Scan a partir de tus filtros para que puedas demostrar que la política permite la operación que necesitas. Si el error nombra un ARN de GSI/LSI, concede dynamodb:Query en table/YourTable/index/* — los permisos de índice son un fallo habitual cuando los allow a nivel de tabla parecen correctos.

Errores relacionados

The security token is invalid — credenciales incorrectas/caducadas (frente a credenciales válidas sin permiso).
Falta la región en la configuración
Aprende: Running DynamoDB Local — desarrolla en local, donde las políticas de IAM no aplican.

Fuentes

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.