Saltar al contenido principal
AWS

AWS: AccessDenied — User is not authorized to perform this action

Cómo resolver el error AccessDenied en AWS. Configurar políticas IAM correctamente para S3, Lambda, EC2 y otros servicios de AWS.

Error: AccessDenied: User is not authorized to perform

¿Por qué ocurre?

AWS deniega la operación porque: - La política IAM del usuario/rol no incluye el permiso necesario - La política de recursos (bucket policy, resource-based policy) lo deniega explícitamente - Hay un SCP (Service Control Policy) en AWS Organizations que lo bloquea - La sesión tiene permisos temporales (AssumeRole) que no incluyen la acción - Las credenciales usadas son de un perfil diferente al esperado

Solución paso a paso

1. Leer el mensaje de error completo

AccessDenied: User: arn:aws:iam::123456789:user/mi-usuario
is not authorized to perform: s3:GetObject
on resource: arn:aws:s3:::mi-bucket/archivo.txt
El mensaje indica: - Quién intenta la acción (el ARN del usuario/rol) - Qué acción intenta (s3:GetObject) - Sobre qué recurso (arn:aws:s3:::mi-bucket/archivo.txt)

2. Crear o actualizar la política IAM

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::mi-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::mi-bucket"
    }
  ]
}

3. Verificar qué credenciales se están usando

# Ver identidad actual
aws sts get-caller-identity

# Resultado: # { # "UserId": "AIDAEXAMPLE", # "Account": "123456789012", # "Arn": "arn:aws:iam::123456789012:user/mi-usuario" # }

# Ver qué perfil está activo aws configure list echo $AWS_PROFILE

4. Usar el Policy Simulator de AWS En la consola AWS: IAM → Policy Simulator → Simular la acción específica O por CLI:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/mi-usuario \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::mi-bucket/archivo.txt

5. Roles en Lambda / EC2 — añadir permisos al rol

# Ver el rol asociado a la Lambda
aws lambda get-function-configuration --function-name mi-funcion \
  --query 'Role'

# Adjuntar política al rol aws iam attach-role-policy \ --role-name mi-rol-lambda \ --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

6. Política de bucket S3 (resource-based policy)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/mi-rol-lambda"
      },
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::mi-bucket/*"
    }
  ]
}

7. En código (SDK de AWS)

import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3'

const client = new S3Client({ region: 'eu-west-1', // Las credenciales se toman automáticamente de: // 1. Variables de entorno: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY // 2. ~/.aws/credentials // 3. Rol IAM de la instancia EC2/Lambda (en producción) })

try { const response = await client.send(new GetObjectCommand({ Bucket: 'mi-bucket', Key: 'archivo.txt', })) } catch (error) { if (error.name === 'AccessDenied') { console.error('Sin permisos. ARN:', error.$metadata) } }

Cómo evitarlo en el futuro

- Sigue el principio de mínimo privilegio: concede solo los permisos estrictamente necesarios - Usa roles IAM en lugar de credenciales de usuario para EC2, Lambda y ECS - Nunca hardcodees AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY en el código - Activa AWS CloudTrail para auditar todas las llamadas a la API y diagnosticar AccessDenied - Usa `aws iam simulate-principal-policy` antes de desplegar para verificar permisos

AWSIAMpermisospolíticasS3Lambda

¿Quieres que una IA te ayude? Genera el prompt perfecto para tu error:

Generador de Prompts

¿Necesitas desarrollo a medida?

Apps web, IA, módulos ERP — cuéntame tu proyecto.