Share Your AWS re:Post Experience - Quick 3 Question Survey
Help us improve AWS re:Post! We're interested in understanding how you use re:Post and its impact on your AWS journey. Please take a moment to complete our brief 3-question survey.
How do I add the bucket-owner-full-control ACL to my objects in Amazon S3?
I want to add the bucket-owner-full-control access control list (ACL) to objects stored in an Amazon Simple Storage Service (Amazon S3) bucket.
Short description
When you create a new bucket in Amazon S3, the bucket's S3 Object Ownership setting is set to Bucket owner enforced by default. This setting turns off ACLs and grants ownership of all objects in the bucket to the AWS account that owns the bucket. After you do this, the bucket account owner has full control of all objects in the bucket, even objects that were uploaded by other accounts.
Important: You can't grant cross-account access through bucket and object ACLs for buckets that have S3 Object Ownership set to Bucket owner enforced. In most cases, you don't need ACLs to grant permissions to objects and buckets. Instead, use AWS Identity Access and Management (IAM) policies and S3 bucket policies to grant permissions to objects and buckets, even for cross-account requesters.
For buckets that have ACLs turned on, you must add the bucket-owner-full-control ACL to have full control of objects that are uploaded by other accounts. The bucket-owner-full-control ACL is also required when the destination bucket has S3 Object Ownership set to ACLs enabled.
For objects written to your bucket by another account, the object owner must update the object's ACL to grant full control to the bucket owner. To update the object's ACL, the object writer can perform a PutObjectAcl API operation or reupload the object with a bucket-owner-full-control canned ACL. You can specify a bucket-owner-full-control canned ACL when you perform a PUT or COPY operation.
For a user in Account A to grant a bucket-owner-full-control canned ACL to objects in Account B, the following permissions are required:
- Your IAM role or user in Account A must grant access to the bucket in Account B
- Your bucket policy in Account B must grant access to the IAM role or user in Account A
To grant bucket-owner-full-control access to objects, choose one of the following:
- Use canned ACLs
- Use S3 Batch Operations (for large-scale batch operations)
Note: Make sure to review your Amazon Virtual Private Cloud (Amazon VPC) endpoint policy when you add the bucket-owner-full-control canned ACL to your S3 objects.
Resolution
Your IAM role or user in Account A must grant access to the bucket in Account B
Note: If the IAM user or role must update the object's ACL during the upload, then the user must have permissions for s3:PutObjectAcl in their IAM policy.
Create an IAM role in Account A. Grant the role/user permissions to perform PutObjectAcl on objects in Account B.
The following example policy grants the IAM role in Account A access to perform the GetObject, PutObject, and PutObjectAcl actions on objects in Account B:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": "arn:aws:s3:::AccountB-Bucket/*" } ] }
Your bucket policy in Account B must grant access to the IAM user or role in Account A
Bucket policies vary based on the canned ACL requirement during object uploads. For example, these two bucket policies grant access to the IAM user or role in Account A in different ways:
- Policy 1: Allows access to the IAM user or role in Account A without the requirement that Amazon S3 PUT operations include a bucket-owner-full-control canned ACL.
- Policy 2: Enforces all Amazon S3 PUT operations to include the bucket-owner-full-control canned ACL.
Policy 1: Allows access to the IAM user or role in Account A without the requirement that Amazon S3 PUT operations include a bucket-owner-full-control canned ACL
To allow access to the IAM role in Account A without the requirement of an ACL, create a bucket policy in Account B. This bucket policy must grant access to the IAM role or user in Account A. The following bucket policy allows the role in Account A to perform GetObject, PutObject, and PutObjectAcl actions on the objects in Account B:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountA:role/AccountARole" }, "Action": [ "s3:GetObject", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::AccountB-Bucket/*" ] } ] }
Policy 2: Enforces all Amazon S3 PUT operations to include the bucket-owner-full-control canned ACL
The following bucket policy specifies that a user or role in Account A can upload objects to a bucket in Account B. You can perform uploads only when the object's ACL is set to bucket-owner-full-control.
For example, see the following bucket policy:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Only allow writes to my bucket with bucket owner full control", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::AccountA:role/AccountARole" ] }, "Action": [ "s3:PutObject", "s3:PutObjectAcl" ], "Resource": "arn:aws:s3:::AccountB-Bucket/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } } ] }
Note: When you apply the previous bucket policy, you must include the bucket-owner-full-control canned ACL during the PutObject operation. If you don't, then the operation fails and you get an Access Denied error. For more information about how Amazon S3 manages object ownership of other AWS accounts, see Controlling ownership of objects and turning off ACLs for your bucket.
Provide bucket-owner-full-control access
Canned ACLs
To grant a bucket-owner-full-control canned ACL when you upload objects, run the put-object command from Account A (object owner's account):
aws s3api put-object --bucket accountB-bucket --key example.txt --acl bucket-owner-full-control
To grant a bucket-owner-full-control canned ACL when you copy objects, run the copy-object command from Account A (object owner's account):
aws s3api copy-object --copy-source accountA-bucket/example.txt --key example.txt --bucket accountB-bucket --acl bucket-owner-full-control
Or, run the cp command from Account A to grant the bucket-owner-full-control canned ACL:
aws s3 cp s3://accountA-bucket/test.txt s3://accountB-bucket/test2.txt --acl bucket-owner-full-control
If the object owner (Account A) wants to copy multiple objects, then run the following command:
aws s3 cp s3://accountA-bucket/ s3://accountB-bucket/ --acl bucket-owner-full-control --recursive
If the object is in a bucket in another account (Account B), then the object owner can grant access with the following command:
aws s3api put-object-acl --bucket accountB-bucket --key example.txt --acl bucket-owner-full-control
S3 Batch Operations
To add a bucket-owner-full-control canned ACL on a large number of Amazon S3 objects, use S3 Batch Operations. S3 Batch Operations can perform a single operation on a list of objects that you specify. For example, you can add the same ACL to a large number of objects at the same time. S3 Batch Operations supports custom and canned ACLs that Amazon S3 provides with a predefined set of access permissions.
Note: The replace access control list operation replaces the Amazon S3 ACLs for every object that's listed in the manifest.
Grant access through a VPC endpoint policy
If you receive errors when you upload objects with ACLs, then you might have issues with your VPC endpoint policy. If an IAM role uploads objects to S3 from an instance that's routed through a VPC endpoint, then check the VPC endpoint policy. For example, suppose you want to upload an object to S3 from an Amazon Elastic Compute Cloud (Amazon EC2) instance in a VPC. To do this, your endpoint policy must allow the PutObjectAcl action:
{ "Statement": [ { "Sid": "Access-to-specific-bucket-only", "Principal": "*", "Action": [ "s3:PutObject", "s3:PutObjectAcl" ], "Effect": "Allow", "Resource": "arn:aws:s3:::AccountB-Bucket/*" } ] }

Relevant content
- Accepted Answer
- asked 2 years agolg...
- Accepted Answerasked a year agolg...
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 7 months ago
- AWS OFFICIALUpdated 17 days ago