Controlling ownership of objects and disabling ACLs for your bucket
S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to control ownership of objects uploaded to your bucket and to disable or enable access control lists (ACLs). By default, Object Ownership is set to the Bucket owner enforced setting and all ACLs are disabled. When ACLs are disabled, the bucket owner owns all the objects in the bucket and manages access to data exclusively using access management policies.
A majority of modern use cases in Amazon S3 no longer require the use of ACLs, and we recommend that you keep ACLs disabled except in unusual circumstances where you must control access for each object individually. With ACLs disabled, you can use policies to more easily control access to every object in your bucket, regardless of who uploaded the objects in your bucket.
Object Ownership has three settings that you can use to control ownership of objects uploaded to your bucket and to disable or enable ACLs:
ACLs disabled
-
Bucket owner enforced (default) – ACLs are disabled, and the bucket owner automatically owns and has full control over every object in the bucket. ACLs no longer affect permissions to data in the S3 bucket. The bucket uses policies to define access control.
ACLs enabled
-
Bucket owner preferred – The bucket owner owns and has full control over new objects that other accounts write to the bucket with the
bucket-owner-full-control
canned ACL. -
Object writer – The AWS account that uploads an object owns the object, has full control over it, and can grant other users access to it through ACLs.
For the majority of modern use cases in S3, we recommend that you keep ACLs disabled by applying the Bucket owner enforced setting and using your bucket policy to share data with users outside of your account as needed. This approach simplifies permissions management. You can disable ACLs on both newly created and already existing buckets. For newly created buckets, ACLs are disabled by default. In the case of an existing bucket that already has objects in it, after you disable ACLs, the object and bucket ACLs are no longer part of an access evaluation, and access is granted or denied on the basis of policies. For existing buckets, you can re-enable ACLs at any time after you disable them, and your preexisting bucket and object ACLs are restored.
Before you disable ACLs, we recommend that you review your bucket policy to ensure that it
covers all the ways that you intend to grant access to your bucket outside of your account. After you
disable ACLs, your bucket accepts only PUT requests that do not specify an ACL or
PUT
requests with bucket owner full control ACLs, such as the
bucket-owner-full-control
canned ACL or equivalent forms of this ACL
expressed in XML. Existing applications that support bucket owner full control ACLs see no
impact. PUT
requests that contain other ACLs (for example, custom grants to
certain AWS accounts) fail and return a 400
error with the error code
AccessControlListNotSupported
.
In contrast, a bucket with the Bucket owner preferred setting continues to accept and
honor bucket and object ACLs. With this setting, new objects that are written with the
bucket-owner-full-control
canned ACL are automatically owned by the bucket
owner rather than the object writer. All other ACL behaviors remain in place. To require all
Amazon S3 PUT
operations to include the bucket-owner-full-control
canned ACL, you can add a bucket
policy that allows only object uploads using this ACL.
To see which Object Ownership settings are applied to your buckets, you can use Amazon S3 Storage Lens metrics. S3 Storage Lens is a cloud-storage analytics feature that you can use to gain organization-wide visibility into object-storage usage and activity. For more information, see Using S3 Storage Lens to find Object Ownership settings.
Note
For more information about using the Amazon S3 Express One Zone storage class with directory buckets, see What is S3 Express One Zone? and Directory buckets.
Object Ownership settings
This table shows the impact that each Object Ownership setting has on ACLs, objects, object ownership, and object uploads.
Setting | Applies to | Effect on object ownership | Effect on ACLs | Uploads accepted |
---|---|---|---|---|
Bucket owner enforced (default) | All new and existing objects | Bucket owner owns every object. |
ACLs are disabled and no longer affect access permissions to your bucket. Requests to set or update ACLs fail. However, requests to read ACLs are supported. Bucket owner has full ownership and control. Object writer no longer has full ownership and control. |
Uploads with bucket owner full control ACLs or uploads that don't specify an ACL |
Bucket owner preferred | New objects | If an object upload includes the
bucket-owner-full-control canned ACL, the bucket owner
owns the object. Objects uploaded with other ACLs are owned by the writing account. |
ACLs can be updated and can grant permissions. If an object upload includes the
|
All uploads |
Object writer | New objects | Object writer owns the object. |
ACLs can be updated and can grant permissions. Object writer has full control access. |
All uploads |
Changes introduced by disabling ACLs
When the Bucket owner enforced setting for Object Ownership is applied, ACLs are disabled and you automatically own and take full control over every object in the bucket without taking any additional actions. Bucket owner enforced is the default setting for all newly created buckets. After the Bucket owner enforced setting is applied, you will see three changes:
-
All bucket ACLs and object ACLs are disabled, which gives full access to you, as the bucket owner. When you perform a read ACL request on your bucket or object, you will see that full access is given only to the bucket owner.
-
You, as the bucket owner, automatically own and have full control over every object in your bucket.
-
ACLs no longer affect access permissions to your bucket. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, VPC endpoint policies, and Organizations SCPs.
![Diagram showing what happens when you apply the Bucket owner enforced setting to disable ACLs.](/images/AmazonS3/latest/userguide/images/bucket-owner-enforced.png)
If you use S3 Versioning, the bucket owner owns and has full control over all object versions in your bucket. Applying the Bucket owner enforced setting does not add a new version of an object.
New objects can be uploaded to your bucket only if they use bucket owner full control ACLs or don't specify an ACL. Object uploads fail if they specify any other ACL. For more information, see Troubleshooting.
Because the following example PutObject
operation using the AWS Command Line Interface
(AWS CLI) includes the bucket-owner-full-control
canned ACL, the object can
be uploaded to a bucket with disabled ACLs.
aws s3api put-object --bucket
amzn-s3-demo-bucket
--keykey-name
--bodypath-to-file
--acl bucket-owner-full-control
Because the following PutObject
operation doesn't specify an ACL, it also
succeeds for a bucket with disabled ACLs.
aws s3api put-object --bucket
amzn-s3-demo-bucket
--keykey-name
--bodypath-to-file
Note
If other AWS accounts need access to objects after uploading, you must grant additional permissions to those accounts through bucket policies. For more information, see Walkthroughs that use policies to manage access to your Amazon S3 resources.
Re-enabling ACLs
You can re-enable ACLs by changing from the Bucket owner enforced setting to another Object Ownership setting at any time. If you used object ACLs for permissions management before you applied the Bucket owner enforced setting and you didn't migrate these object ACL permissions to your bucket policy, after you re-enable ACLs, these permissions are restored. Additionally, objects written to the bucket while the Bucket owner enforced setting was applied are still owned by the bucket owner.
For example, if you change from the Bucket owner enforced setting back to the Object writer setting, you, as the bucket owner, no longer own and have full control over objects that were previously owned by other AWS accounts. Instead, the uploading accounts again own these objects. Objects owned by other accounts use ACLs for permissions, so you can't use policies to grant permissions to these objects. However, you, as the bucket owner, still own any objects that were written to the bucket while the Bucket owner enforced setting was applied. These objects are not owned by the object writer, even if you re-enable ACLs.
For instructions on enabling and managing ACLs using the AWS Management Console, AWS Command Line Interface (CLI), REST API, or AWS SDKs, see Configuring ACLs.
Prerequisites for disabling ACLs
Before you disable ACLs for an existing bucket, complete the following prerequisites.
Review bucket and object ACLs and migrate ACL permissions
When you disable ACLs, permissions granted by bucket and object ACLs no longer affect access. Before you disable ACLs, review your bucket and object ACLs.
If your bucket ACLs grant read or write permissions to others outside of your account, you must migrate these permissions to your bucket policy before you can apply the Bucket owner enforced setting. If you don't migrate bucket ACLs that grant read or write access outside of your account, your request to apply the Bucket owner enforced setting fails and returns the InvalidBucketAclWithObjectOwnership error code.
For example, if you want to disable ACLs for a bucket that receives server access logs, you must migrate the bucket ACL permissions for the S3 log delivery group to the logging service principal in a bucket policy. For more information, see Grant access to the S3 log delivery group for server access logging.
If you want the object writer to maintain full control of the object that they upload, object writer is the best Object Ownership setting for your use case. If you want to control access at the individual object level, bucket owner preferred is the best choice. These use cases are uncommon.
To review ACLs and migrate ACL permissions to bucket policies, see Prerequisites for disabling ACLs.
Identify requests that required an ACL for authorization
To identify Amazon S3 requests that required ACLs for authorization, you can use the
aclRequired
value in Amazon S3 server access logs or AWS CloudTrail. If the
request required an ACL for authorization or if you have PUT
requests
that specify an ACL, the string is Yes
. If no ACLs were required, or if
you are setting a bucket-owner-full-control
canned ACL, or if the
requests are allowed by your bucket policy, the aclRequired
value
string is "-
" in Amazon S3 server access logs and is absent in CloudTrail. For
more information about the expected aclRequired
values, see aclRequired values for common Amazon S3
requests.
If you have PutBucketAcl
or PutObjectAcl
requests with headers
that grant ACL-based permissions, with the exception of the
bucket-owner-full-control
canned ACL, you must remove those headers
before you can disable ACLs. Otherwise, your requests will fail.
For all other requests that required an ACL for authorization, migrate those ACL permissions to bucket policies. Then, remove any bucket ACLs before you enable the bucket owner enforced setting.
Note
Do not remove object ACLs. Otherwise, applications that rely on object ACLs for permissions will lose access.
If you see that no requests required an ACL for authorization, you can proceed to disable ACLs. For more information about identifying requests, see Using Amazon S3 server access logs to identify requests and Identifying Amazon S3 requests using CloudTrail.
Review and update bucket policies that use ACL-related condition keys
After you apply the Bucket owner enforced setting to disable ACLs, new objects can be uploaded to your bucket only if the request uses bucket owner full control ACLs or doesn't specify an ACL. Before disabling ACLs, review your bucket policy for ACL-related condition keys.
If your bucket policy uses an ACL-related condition key to require the
bucket-owner-full-control
canned ACL (for example,
s3:x-amz-acl
), you don't need to update your bucket policy. The
following bucket policy uses the s3:x-amz-acl
to require the
bucket-owner-full-control
canned ACL for S3 PutObject
requests. This policy still requires the object
writer to specify the bucket-owner-full-control
canned ACL. However,
buckets with ACLs disabled still accept this ACL, so requests continue to succeed
with no client-side changes required.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Only allow writes to my bucket with bucket owner full control", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::
111122223333
:user/ExampleUser
" ] }, "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket
/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } } ] }
However, if your bucket policy uses an ACL-related condition key that requires a
different ACL, you must remove this condition key. This example bucket policy
requires the public-read
ACL for S3 PutObject
requests and
therefore must be updated before disabling ACLs.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Only allow writes to my bucket with public read access", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::
111122223333
:user/ExampleUser
" ] }, "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket
/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "public-read" } } } ] }
Object Ownership permissions
To apply, update, or delete an Object Ownership setting for a bucket, you need the
s3:PutBucketOwnershipControls
permission. To return the
Object Ownership setting for a bucket, you need the
s3:GetBucketOwnershipControls
permission. For more information, see
Setting Object Ownership when you create
a bucket and Viewing the Object Ownership setting for
an S3 bucket.
Disabling ACLs for all new buckets
By default, all new buckets are created with the Bucket owner enforced setting applied and ACLs are disabled. We recommend keeping ACLs disabled. As a general rule, we recommend using S3 resource-based policies (bucket policies and access point policies) or IAM policies for access control instead of ACLs. Policies are a simplified and more flexible access control option. With bucket policies and access point policies, you can define rules that apply broadly across all requests to your Amazon S3 resources.
Replication and Object Ownership
When you use S3 replication and the source and destination buckets are owned by
different AWS accounts, you can disable ACLs (with the Bucket owner enforced setting
for Object Ownership) to change replica ownership to the AWS account that owns the
destination bucket. This setting mimics the existing owner override behavior without the
need of the s3:ObjectOwnerOverrideToBucketOwner
permission. All objects
that are replicated to the destination bucket with the Bucket owner enforced setting are
owned by the destination bucket owner. For more information about the owner override
option for replication configurations, see Changing the replica owner.
Setting Object Ownership
You can apply an Object Ownership setting by using the Amazon S3 console, AWS CLI, AWS SDKs, Amazon S3 REST API, or AWS CloudFormation. The following REST API and AWS CLI commands support Object Ownership:
REST API | AWS CLI | Description |
---|---|---|
PutBucketOwnershipControls | put-bucket-ownership-controls |
Creates or modifies the Object Ownership setting for an existing S3 bucket. |
CreateBucket | create-bucket |
Creates a bucket using the x-amz-object-ownership
request header to specify the Object Ownership setting. |
GetBucketOwnershipControls | get-bucket-ownership-controls |
Retrieves the Object Ownership setting for an Amazon S3 bucket. |
DeleteBucketOwnershipControls | delete-bucket-ownership-controls |
Deletes the Object Ownership setting for an Amazon S3 bucket. |
For more information about applying and working with Object Ownership settings, see the following topics.