When setting up Cross-Service workflows like CloudTrail → S3 → SQS → Splunk, many engineers encounter the frustrating "AccessDenied" error despite seemingly correct IAM configurations. Let's dissect this specific scenario where AssumeRole fails within the same AWS account.

Based on your setup, we need to verify three key components:

// 1. The Role's Permission Policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:GetQueueAttributes",
                "sqs:ListQueues",
                "sqs:ReceiveMessage",
                "sqs:GetQueueUrl",
                "sqs:DeleteMessage",
                "s3:Get*",
                "s3:List*",
                "s3:Delete*"
            ],
            "Resource": "*"
        }
    ]
}

// 2. The Trust Relationship (Missing closing brackets in original)
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::XXXXXXXXXXXX:user/username"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

// 3. User's AssumeRole Permission
{
    "Sid": "VisualEditor0",
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::XXXXXXXXXXXX:role/roleforsplunk"
}

The configuration appears correct, but the error suggests the EC2 instance isn't actually assuming the role. When using AWS CLI with access keys, you must explicitly assume the role:

# First assume the role and get temporary credentials
aws sts assume-role --role-arn arn:aws:iam::XXXXXXXXXXXX:role/roleforsplunk --role-session-name splunk-session

# Then export the temporary credentials
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

# Now try S3 operations
aws s3 ls

For EC2 instances, a more elegant solution is using instance profiles:

1. Create an instance profile attached to your EC2 instance
2. Assign the role directly to the instance profile
3. Remove the need for access keys completely

# No need for aws configure when using instance profiles
aws s3 ls

If you still face issues:

# Check current identity
aws sts get-caller-identity

# Verify role assumptions
aws iam get-role --role-name roleforsplunk
aws iam list-attached-role-policies --role-name roleforsplunk

When setting up the CloudTrail → S3 → SQS → Splunk pipeline, many developers hit a frustrating roadblock: even after configuring IAM roles and policies correctly on paper, API calls still return AccessDenied errors. Let's dissect this systematically.

// The role trust relationship (often the first culprit)
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:user/splunk-integration-user"
    },
    "Action": "sts:AssumeRole"
  }]
}

The error An error occurred (AccessDenied) when calling the ListBuckets operation typically indicates one of these scenarios:

• The EC2 instance credentials aren't actually assuming the role
• The assumed role lacks S3 permissions despite the policy attachment
• The trust relationship doesn't allow the specific user/EC2 instance

1. Verify actual assumed credentials:

aws sts get-caller-identity
// Compare output with expected role ARN

2. Check effective permissions:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/roleforsplunk \
  --action-names s3:ListBuckets

Here's a verified configuration that works for S3/SQS access:

// Role policy
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets",
        "s3:GetBucketLocation"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::your-cloudtrail-bucket",
        "arn:aws:s3:::your-cloudtrail-bucket/*"
      ]
    }
  ]
}

// User policy
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::123456789012:role/roleforsplunk"
  }
}

• Always specify S3 bucket ARNs instead of wildcards when possible
• Use condition keys for additional security: "Condition": {"StringEquals": {"aws:RequestedRegion": "us-east-1"}}
• Enable CloudTrail logs for STS events to audit role assumptions