AWS S3 Permissions

S3 permissions can look simple until you combine identity policies, bucket policies, public access controls, and legacy ACLs. The safest default is to assume every bucket should be private unless there is a clear business reason to expose content publicly. AWS’s Block Public Access setting exists for exactly that reason and should remain enabled in most environments.

Bucket policies and IAM policies solve related but different problems. IAM policies answer what a principal is allowed to do across AWS resources. Bucket policies live on the bucket and answer who can access that specific bucket and under what conditions. Many real-world setups use both: a role is allowed to read S3 generally, and the bucket policy narrows access to the right principals or network conditions.

AWS now recommends disabling ACLs in many cases because bucket owner enforced object ownership simplifies access management. That leaves policies as the primary control model. Pre-signed URLs are a good exception pattern when you want temporary access to one object without making the bucket public or creating a permanent user.

The most common mistake is assuming a bucket stays private because no one meant to expose it. S3 access should be explicit and reviewed. Public buckets can be valid for static websites or downloadable assets, but they should be intentionally configured, monitored, and limited to only the content meant for the public.

Pair this lesson with AWS IAM because S3 permission issues often span both identity and bucket-level controls.

aws s3api get-public-access-block --bucket example-devops-lesson-bucket
aws s3api get-bucket-policy --bucket example-devops-lesson-bucket
aws s3 presign s3://example-devops-lesson-bucket/reports/build.txt --expires-in 900

Operational note

S3 tends to become shared infrastructure quickly, so naming, ownership tags, encryption defaults, and lifecycle rules are worth standardizing early. Small governance choices prevent later confusion when dozens of applications depend on buckets for artifacts, logs, backups, and temporary data exchange. Recovery drills are useful too, especially when versioning or lifecycle retention is part of your safety model. Shared standards like this make future environments easier to launch, review, and support.