Introduction

If an S3 bucket used by Elastic Beanstalk looks empty but deletion still returns Access Denied, the problem is usually permissions or hidden bucket state rather than visible files. The usual causes are bucket-policy denies, versioned objects, shared Elastic Beanstalk usage, or an IAM principal that can view the bucket but cannot fully remove it.

Confirm the Bucket Is Safe to Delete

Elastic Beanstalk often stores application versions in S3, and in many accounts there is a shared regional bucket rather than a separate bucket per environment. Before deleting anything, verify that no existing application versions still reference that bucket.

aws elasticbeanstalk describe-application-versions \
  --application-name my-app

If application versions still depend on the bucket, deleting it can break redeployments, rollbacks, or cleanup workflows. In many cases the right fix is to delete or migrate application versions first, not to remove the bucket itself.

Check IAM Permissions

The identity performing the delete needs enough S3 permissions to inspect and remove the bucket. Typical required permissions include:

• 's3:ListBucket'
• 's3:DeleteBucket'
• 's3:DeleteObject'
• 's3:DeleteObjectVersion'
• sometimes s3:GetBucketPolicy and s3:DeleteBucketPolicy

Example IAM policy fragment:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": [
7        "s3:ListBucket",
8        "s3:DeleteBucket",
9        "s3:DeleteObject",
10        "s3:DeleteObjectVersion",
11        "s3:GetBucketPolicy",
12        "s3:DeleteBucketPolicy"
13      ],
14      "Resource": [
15        "arn:aws:s3:::my-bucket",
16        "arn:aws:s3:::my-bucket/*"
17      ]
18    }
19  ]
20}

If any one of these permissions is missing, S3 can reject the delete even when the bucket appears empty in the console.

Check for an Explicit Bucket Policy Deny

Even broad IAM permissions do not override an explicit deny in the bucket policy. That is one of the most common reasons administrators see Access Denied despite having what looks like an admin role.

Inspect the bucket policy:

aws s3api get-bucket-policy --bucket my-bucket

If the policy contains an explicit deny for delete operations, for your principal, or for your network path, that must be changed before deletion can succeed. If appropriate, remove the policy:

aws s3api delete-bucket-policy --bucket my-bucket

Only do that if you are sure the policy is no longer needed.

The Bucket May Not Be Truly Empty

An S3 bucket can look empty and still contain versions or delete markers. If versioning was enabled, those hidden entries must be removed before the bucket itself can be deleted.

Check versioning:

aws s3api get-bucket-versioning --bucket my-bucket

Then list versions and delete markers:

aws s3api list-object-versions --bucket my-bucket

If that command returns entries, the bucket is not truly empty. You must delete the versions before deleting the bucket.

Ownership and Compliance Controls

In some environments, the bucket or its objects may be owned by a different AWS account, especially in cross-account CI or deployment setups. In that case, your principal may be able to inspect parts of the bucket but still lack permission to remove all object versions.

Also consider retention mechanisms such as Object Lock or organization-level controls. Those are less common in Elastic Beanstalk buckets, but they can still block deletion.

If a compliance rule is involved, repeated delete attempts will not help. You need to inspect the bucket's protective configuration first.

Practical Cleanup Sequence

A reliable manual flow is:

1. confirm Elastic Beanstalk no longer needs the bucket
2. verify IAM permissions for delete operations
3. inspect the bucket policy for explicit denies
4. inspect versioning and hidden object versions
5. retry bucket deletion

Example CLI sequence:

1aws s3api get-bucket-versioning --bucket my-bucket
2aws s3api list-object-versions --bucket my-bucket
3aws s3api get-bucket-policy --bucket my-bucket
4aws s3api delete-bucket --bucket my-bucket

If the bucket lives in a different region from your default CLI configuration, also verify that your CLI commands target the correct region.

Common Pitfalls

The biggest mistake is trusting the console's empty-bucket view too much. Versioned objects and delete markers can remain even when the file list looks empty.

Another common issue is trying to delete a shared Elastic Beanstalk bucket when the real goal is only to remove a specific application version. Those shared buckets often serve more than one deployment.

People also check IAM permissions but forget the bucket policy. In AWS, an explicit deny in the bucket policy wins.

Finally, do not forget object ownership. Cross-account uploads can leave behind versions that your current principal cannot remove.

Summary

• 'Access Denied usually means a policy or hidden-bucket-state problem, not just visible files.'
• Confirm Elastic Beanstalk no longer depends on the bucket before deleting it.
• Check IAM permissions and the bucket policy together.
• Inspect versioning and delete markers because an apparently empty bucket may still contain hidden objects.
• Delete the bucket only after permissions, policy, and retained object state are fully cleared.