I'm trying to access an S3 bucket via the AWS CLI and my Python Boto3 script, but I keep receiving a <Code>AccessDenied</Code> error message. I have already attached the AmazonS3FullAccess policy to my IAM user, but the connection still fails. Could this be related to an S3 Bucket Policy, Public Access Block settings, or perhaps a missing permission in my VPC Endpoint? How can I systematically debug where the permission chain is breaking?
3 answers
The "AccessDenied" error in S3 is often tricky because AWS evaluates permissions across multiple layers. Even if your IAM user has Full Access, an explicit "Deny" in the S3 Bucket Policy will always take precedence. You should first check if "Block Public Access" is enabled at the account or bucket level, as this can override permissions. Additionally, check for Service Control Policies (SCPs) if you are in an AWS Organization. If you are accessing S3 from an EC2 instance within a private subnet, ensure your VPC Endpoint has a policy that allows the action. A great way to debug this is using the AWS Policy Simulator or checking the CloudTrail logs to see exactly which identity is being denied and by which specific policy type.
Are you using server-side encryption with AWS KMS keys on that bucket? I’ve spent hours debugging Access Denied errors only to find out the IAM user had S3 permissions but lacked the kms:Decrypt permission for the specific key used to encrypt the objects.
Check the S3 Bucket Policy specifically. Often, a policy intended to restrict access to a specific IP range inadvertently blocks everyone else, including the bucket owner if not configured carefully.
I agree with Robert. I once locked myself out by adding a "Deny" rule that didn't exclude my own IAM role. Always test policies in a staging environment before applying them to production buckets to avoid these connectivity headaches.
Michael, that is a fantastic catch! KMS permissions are a silent killer in S3 automation. If the bucket has default encryption set to a Customer Managed Key (CMK) instead of the standard AWS Managed Key, the user needs explicit access to that key. Without the kms:GenerateDataKey and kms:Decrypt actions in the KMS key policy, S3 will return a 403 Access Denied error even if the S3 bucket itself is technically wide open to that user.