Introduction

If you need an IAM user that can fully manage exactly one S3 bucket, the right solution is a bucket-scoped IAM policy. The important detail is that S3 permissions are split between the bucket itself and the objects inside it, so the policy usually needs both resource ARNs.

What “Full Access to One Bucket” Usually Means

For most programmatic use, “full access” means the user can do things like these within one bucket:

• list objects
• upload objects
• download objects
• delete objects
• manage object metadata

That usually requires actions on both:

• the bucket ARN, such as arn:aws:s3:::my-bucket
• the object ARN pattern, such as arn:aws:s3:::my-bucket/*

If you include only one of those, some operations will still fail.

A Practical IAM Policy

This policy gives broad S3 access within one bucket only:

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

That is enough for many CLI and SDK workflows focused on one bucket.

Attach the Policy to an IAM User

Create an IAM user only if you really need long-lived user credentials. In many AWS environments, an IAM role is better. But if the requirement is specifically a user, the steps are:

1. create the IAM user
2. choose programmatic access if the user will use CLI or SDK credentials
3. attach the custom policy above
4. store the access key securely

Then test with the AWS CLI:

aws s3 ls s3://my-bucket
aws s3 cp report.txt s3://my-bucket/report.txt
aws s3 rm s3://my-bucket/report.txt

If those succeed and access to other buckets fails, the policy scope is working as intended.

Optional Console Access Consideration

If the user also needs the AWS Management Console, the experience can be confusing. The console often tries to show general S3 information that requires permissions outside the single bucket.

For strict single-bucket console usage, you may need to add narrowly scoped supporting permissions or accept that CLI and SDK access are cleaner than console access for this case.

Watch for KMS and Bucket Policies

S3 permissions are not always the whole story.

If the bucket uses SSE-KMS, the user may also need KMS permissions such as these:

• 'kms:Decrypt'
• 'kms:Encrypt'
• 'kms:GenerateDataKey'

Also remember that bucket policies, service control policies, or organization-level guardrails can still deny access even when the IAM user policy looks correct.

Prefer Roles When Possible

If this access is for an EC2 instance, ECS task, Lambda function, or another AWS service, use an IAM role instead of an IAM user. Roles avoid long-lived access keys and are easier to rotate and audit.

Use an IAM user only when a real external identity needs direct AWS credentials.

Common Pitfalls

A common mistake is granting access only to arn:aws:s3:::my-bucket/* and forgetting the bucket ARN itself. That often breaks ListBucket.

Another mistake is using AmazonS3FullAccess, which grants far more than one-bucket access.

A third issue is debugging only the IAM policy while ignoring KMS settings or restrictive bucket policies. S3 authorization is often the combination of several policy layers.

Summary

• Use a custom IAM policy scoped to one bucket ARN and one object ARN pattern
• Bucket-level and object-level permissions are both usually required
• Test with CLI operations to confirm the scope is correct
• If the bucket uses KMS, add matching key permissions too
• Prefer IAM roles over IAM users when the caller is an AWS workload, not a human or external system