Visual overview
Identity, bucket, public-access, and encryption controls answer different questions.
Technical reference
Authorization, public-access guardrails, and encryption are separate S3 security layers.
Allows/denies S3 actions for IAM identities.
Attaches authorization directly to the bucket.
Prevents or constrains public exposure configurations.
KMS key authorization can be required in addition to S3 action permissions.
Access starts with identity and policy
S3 access can be controlled through identity-based IAM policies and resource-based policies such as bucket policies. Identity policies describe what a principal may do; bucket policies attach permissions and conditions directly to a bucket resource. Effective access is the result of the applicable policy evaluation, including any explicit denies. This makes S3 security a policy problem, not a checkbox that turns a bucket into a private or public folder.
Modern S3 designs usually manage access through policies rather than object ACLs. S3 Object Ownership can use the Bucket owner enforced setting to disable ACLs, and AWS recommends this model for most current use cases. With ACLs disabled, the bucket owner owns the objects and access is managed through policies, reducing a historical source of cross-account ownership complexity.
Block Public Access is a guardrail
S3 Block Public Access provides settings at access-point, bucket, account and organization scopes that help prevent policies or permissions from exposing S3 resources publicly. New buckets do not allow public access by default. AWS recommends keeping Block Public Access enabled unless public access is a deliberate requirement that has been reviewed and constrained.
A common architectural mistake is to make a bucket public simply because users need content from it. Services such as CloudFront can provide controlled content delivery while the S3 origin remains private. When direct public S3 access truly is required, the policy should expose only the intended resources and the decision should be treated as a security exception rather than normal bucket configuration.
Encryption and data protection are separate layers
S3 supports server-side encryption options and integrates with AWS Key Management Service (AWS KMS) when customers need control over encryption keys and key policies. Encryption at rest protects stored data; TLS protects data in transit. The required encryption design depends on security and compliance needs, including who must be able to use the relevant keys and whether cross-account workflows need additional KMS permissions.
Encryption does not replace authorization, and authorization does not replace recovery. A well-protected bucket combines least-privilege access, public-access guardrails, appropriate encryption and data-protection mechanisms such as versioning, replication or backups. These controls address different threats: disclosure, unauthorized modification, accidental deletion and operational recovery should be evaluated separately.
Key takeaways
- 01
IAM policies and bucket policies are primary tools for controlling who can perform S3 actions on which resources.
- 02
AWS recommends disabling ACLs with Bucket owner enforced Object Ownership for most modern use cases.
- 03
Block Public Access is a guardrail against unintended exposure and should normally remain enabled.
- 04
Encryption, authorization and recovery are complementary controls, not substitutes for one another.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.