Amazon S3 access control lists (ACLs) enable you to manage access to buckets and objects. Eachbucket and object has an ACL attached to it as a subresource. It defines which AWS accounts or groups are granted access and the type of access. When a request is receivedagainst a resource, Amazon S3 checks the corresponding ACL to verify that the requester hasthe necessary access permissions.

S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to both control ownership of the objects that are uploaded to your bucket and to disable or enable 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 them exclusively by using access-management policies.

A majority of modern use cases in Amazon S3 no longer require the use of ACLs. We recommend that you keep ACLs disabled, except in circumstances where you need to control access for each object individually. With ACLs disabled, you can use policies to control access to all objects in your bucket, regardless of who uploaded the objects to your bucket. For more information, seeControlling ownership of objects and disabling ACLsfor your bucket.

When you create a bucket or an object, Amazon S3 creates a default ACL that grants the resourceowner full control over the resource. This is shown in the following sample bucket ACL(the default object ACL has the same structure):

<?xml version="1.0" encoding="UTF-8"?><AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">  <Owner>    <ID>*** Owner-Canonical-User-ID ***</ID>    <DisplayName>owner-display-name</DisplayName>  </Owner>  <AccessControlList>    <Grant>      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"                xsi:type="Canonical User">        <ID>*** Owner-Canonical-User-ID ***</ID>        <DisplayName>display-name</DisplayName>      </Grantee>      <Permission>FULL_CONTROL</Permission>    </Grant>  </AccessControlList></AccessControlPolicy>

The sample ACL includes anOwner element that identifies the owner by theAWS account's canonical user ID. For instructions on finding your canonical user ID,seeFinding an AWS account canonical userID. TheGrant element identifies the grantee (either an AWS account or apredefined group) and the permission granted. This default ACL has oneGrant element for the owner. You grant permissions by addingGrant elements, with each grant identifying the grantee and thepermission.

Who is a grantee?

A grantee can be an AWS account or one of the predefined Amazon S3 groups. You grantpermission to an AWS account using the email address or the canonical user ID.However, if you provide an email address in your grant request, Amazon S3 finds thecanonical user ID for that account and adds it to the ACL. The resulting ACLs alwayscontain the canonical user ID for the AWS account, not the email address of theAWS account.

When you grant access rights, you specify each grantee as atype="value"pair, wheretype is one of thefollowing:

x-amz-grant-read: emailAddress="xyz@example.com", emailAddress="abc@example.com"

Finding an AWS account canonical userID

The canonical user ID is associated with your AWS account. This ID is a longstring of characters, such as:

79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be

For information about how to find the canonical user ID for your account, seeFind the canonical user ID for your AWS account in theAWS Account Management Reference Guide.

You can also look up the canonical user ID of an AWS account by reading theACL of a bucket or an object to which the AWS account has access permissions.When an individual AWS account is granted permissions by a grant request, agrant entry is added to the ACL with the account's canonical user ID.

Amazon S3 predefinedgroups

Amazon S3 has a set of predefined groups. When granting account access to a group, you specifyone of the Amazon S3 URIs instead of a canonical user ID. Amazon S3 provides the followingpredefined groups:

What permissions can I grant?

The following table lists the set of permissions that Amazon S3 supports in an ACL. The set ofACL permissions is the same for an object ACL and a bucket ACL. However, dependingon the context (bucket ACL or object ACL), these ACL permissions grant permissionsfor specific buckets or object operations. The table lists the permissions anddescribes what they mean in the context of objects and buckets.

For more information about ACL permissions in the Amazon S3 console, seeConfiguring ACLs.

Mapping of ACL permissions and access policypermissions

As shown in the preceding table, an ACL allows only a finite set of permissions, comparedto the number of permissions that you can set in an access policy (seePolicy actions for Amazon S3).Each of these permissions allows one or more Amazon S3 operations.

The following table shows how each ACL permission maps to the corresponding access policypermissions. As you can see, access policy allows more permissions than an ACLdoes. You use ACLs primarily to grant basic read/write permissions, similar tofile system permissions. For more information about when to use an ACL, seeIdentity and Access Management for Amazon S3.

For more information about ACL permissions in the Amazon S3 console, seeConfiguring ACLs.

Condition keys

When you grant access policy permissions, you can use condition keys to constrain thevalue for the ACL on an object using a bucket policy. The following context keyscorrespond to ACLs. You can use these context keys to mandate the use of aspecific ACL in a request:

For example policies that involve ACL-specific headers, seeGranting s3:PutObject permission with a condition requiring the bucket owner to get full control. For a complete list ofAmazon S3 specific condition keys, seeActions, resources, and condition keys for Amazon S3 in theService Authorization Reference.

For more information about the permissions to S3 API operations by S3 resource types, seeRequired permissions for Amazon S3 API operations.

aclRequired values for common Amazon S3requests

To identify Amazon S3 requests that required ACLs for authorization, you can use theaclRequired value in Amazon S3 server access logs or AWS CloudTrail. TheaclRequired value that appears in CloudTrail or Amazon S3 server access logsdepends on which operations were called and certain information about the requester,object owner, and bucket owner. If no ACLs were required, or if you are setting thebucket-owner-full-control canned ACL, or if the requests areallowed by your bucket policy, theaclRequired value string is"-" in Amazon S3 server access logs and is absent in CloudTrail.

The following tables list the expectedaclRequired values in CloudTrail orAmazon S3 server access logs for the various Amazon S3 API operations. You can use thisinformation to understand which Amazon S3 operations depend on ACLs for authorization. Inthe following tables, A, B, and C represent the different accounts associated withthe requester, object owner, and bucket owner. Entries with an asterisk (*) indicateany of accounts A, B, or C.

The following table shows theaclRequired values for CloudTrail.

The following table shows theaclRequired values for Amazon S3 server access logs.

Sample ACL

The following sample ACL on a bucket identifies the resource owner and a set ofgrants. The format is the XML representation of an ACL in the Amazon S3 REST API. Thebucket owner hasFULL_CONTROL of the resource. In addition, the ACLshows how permissions are granted on a resource to two AWS accounts, identified bycanonical user ID, and two of the predefined Amazon S3 groups discussed in the precedingsection.

<?xml version="1.0" encoding="UTF-8"?><AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">  <Owner>    <ID>Owner-canonical-user-ID</ID>    <DisplayName>display-name</DisplayName>  </Owner>  <AccessControlList>    <Grant>      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">        <ID>Owner-canonical-user-ID</ID>        <DisplayName>display-name</DisplayName>      </Grantee>      <Permission>FULL_CONTROL</Permission>    </Grant>        <Grant>      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">        <ID>user1-canonical-user-ID</ID>        <DisplayName>display-name</DisplayName>      </Grantee>      <Permission>WRITE</Permission>    </Grant>    <Grant>      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">        <ID>user2-canonical-user-ID</ID>        <DisplayName>display-name</DisplayName>      </Grantee>      <Permission>READ</Permission>    </Grant>    <Grant>      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">        <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI>       </Grantee>      <Permission>READ</Permission>    </Grant>    <Grant>      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">        <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI>      </Grantee>      <Permission>WRITE</Permission>    </Grant>  </AccessControlList></AccessControlPolicy>

Canned ACL

Amazon S3 supports a set of predefined grants, known ascanned ACLs. Eachcanned ACL has a predefined set of grantees and permissions. The following tablelists the set of canned ACLs and the associated predefined grants.

You specify a canned ACL in your request by using thex-amz-acl requestheader. When Amazon S3 receives a request with a canned ACL in the request, it adds thepredefined grants to the ACL of the resource.

Thanks for letting us know we're doing a good job!

If you've got a moment, please tell us what we did right so we can do more of it.

Thanks for letting us know this page needs work. We're sorry we let you down.

If you've got a moment, please tell us how we can make the documentation better.