Access Points and Object Ownership

Legacy ACLs (access control lists) let you grant object-level access, but they predate IAM and bucket policies and are hard to audit at scale.

The biggest danger is cross-account uploads: an object written by another account could be owned by that account, leaving the bucket owner unable to control it.

S3 Object Ownership settles who owns uploaded objects. Its recommended setting, Bucket owner enforced, disables ACLs entirely and makes the bucket owner own every object automatically.

With ACLs off, all access is governed cleanly by IAM and bucket policies — far easier to reason about and audit.

When Object Ownership is set to Bucket owner enforced, ACLs no longer apply and cannot grant access at all.

This is now the default for new buckets and the AWS-recommended best practice. It eliminates an entire class of confusing, error-prone cross-account ownership problems in one setting.

Imagine account A owns a bucket but account B uploads logs to it. Under old ACL behavior, B owns those objects, so A cannot read or delete its own bucket's contents.

Bucket owner enforced fixes this: A automatically owns every object regardless of who uploaded it, restoring full control to the bucket owner.

S3 Access Points are named network endpoints attached to a bucket, each with its own access policy.

Instead of one giant, tangled bucket policy serving every application, you create a dedicated access point per use case — each with a simple, scoped policy — making access far easier to manage and audit.

A single shared bucket policy grows complex and risky as more teams use the bucket. Access points decompose that into many small policies.

Each access point can be restricted to a VPC, given its own name and permissions, and revoked independently — so one team's needs never force you to loosen access for everyone.

An access point can be set to accept requests only from a specific VPC (Virtual Private Cloud). Then objects reached through it are unreachable from the public internet entirely.

This is a clean way to ensure sensitive data is only accessed by your internal workloads over a private network path.

Multi-Region Access Points give you a single global endpoint that routes to buckets in several regions.

From a security view, they simplify policy management for globally distributed data and provide automatic failover, so applications keep working without hardcoding regional bucket names.

For sharing across accounts, combine bucket policies, access points, and Object Ownership rather than ACLs.

Set Bucket owner enforced, grant the other account through a scoped bucket or access point policy, and you get auditable, revocable cross-account access without the ownership confusion ACLs cause.

Each access point carries its own access point policy, evaluated alongside the bucket policy. The bucket policy can even delegate to access points, granting access only through them.

This lets you keep one simple, restrictive bucket policy while expressing per-application permissions in small, independent access point policies that are easy to review and revoke.

The modern S3 access posture is clear: disable ACLs with Bucket owner enforced, govern access through IAM and bucket policies, and use access points to keep per-application policies small and scoped.

This combination is both more secure and dramatically easier to audit than the old ACL world.

Choose the cleanest fix.

Legacy ACLs cause cross-account ownership headaches and are hard to audit. Set S3 Object Ownership to Bucket owner enforced to disable ACLs and own every object cleanly, governing access through IAM and bucket policies. Use S3 Access Points to give each application a small, scoped, optionally VPC-restricted policy, and Multi-Region Access Points for global data. Together these replace ACLs with an auditable, least-privilege access model.