diff --git a/doc_source/PresignedUrlUploadObject.md b/doc_source/PresignedUrlUploadObject.md index df09caf..5c51d61 100644 --- a/doc_source/PresignedUrlUploadObject.md +++ b/doc_source/PresignedUrlUploadObject.md @@ -520,7 +520,7 @@ const createPresignedUrlWithoutClient = async ({ region, bucket, key }) => { return formatUrl(signedUrlObject); }; -const createPresignedUrlWithClient = async ({ region, bucket, key }) => { +const createPresignedUrlWithClient = ({ region, bucket, key }) => { const client = new S3Client({ region }); const command = new PutObjectCommand({ Bucket: bucket, Key: key }); return getSignedUrl(client, command, { expiresIn: 3600 }); @@ -551,8 +551,8 @@ function put(url, data) { export const main = async () => { const REGION = "us-east-1"; - const BUCKET = "coreys-default-bucket"; - const KEY = "corey_test.txt"; + const BUCKET = "example_bucket"; + const KEY = "example_file.txt"; // There are two ways to generate a presigned URL. // 1. Use createPresignedUrl without the S3 client. @@ -610,7 +610,7 @@ const createPresignedUrlWithoutClient = async ({ region, bucket, key }) => { return formatUrl(signedUrlObject); }; -const createPresignedUrlWithClient = async ({ region, bucket, key }) => { +const createPresignedUrlWithClient = ({ region, bucket, key }) => { const client = new S3Client({ region }); const command = new GetObjectCommand({ Bucket: bucket, Key: key }); return getSignedUrl(client, command, { expiresIn: 3600 }); @@ -618,8 +618,8 @@ const createPresignedUrlWithClient = async ({ region, bucket, key }) => { export const main = async () => { const REGION = "us-east-1"; - const BUCKET = "coreys-default-bucket"; - const KEY = "corey_mug.jpg"; + const BUCKET = "example_bucket"; + const KEY = "example_file.jpg"; try { const noClientUrl = await createPresignedUrlWithoutClient({ diff --git a/doc_source/S3OutpostsAPI.md b/doc_source/S3OutpostsAPI.md index 3533104..9efde0b 100644 --- a/doc_source/S3OutpostsAPI.md +++ b/doc_source/S3OutpostsAPI.md @@ -26,6 +26,7 @@ Amazon S3 on Outposts supports the following Amazon S3 API operations: + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListMultipartUploads.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListMultipartUploads.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjects.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjects.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html) ++ [https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectVersions.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectVersions.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListParts.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListParts.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectTagging.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectTagging.html) @@ -51,6 +52,7 @@ S3 on Outposts supports the following Amazon S3 Control API operations for worki + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketPolicy.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketPolicy.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketReplication.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketReplication.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketTagging.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketTagging.html) ++ [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketVersioning.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketVersioning.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_ListAccessPoints.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_ListAccessPoints.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_ListRegionalBuckets.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_ListRegionalBuckets.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutAccessPointPolicy.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutAccessPointPolicy.html) @@ -58,6 +60,7 @@ S3 on Outposts supports the following Amazon S3 Control API operations for worki + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutBucketPolicy.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutBucketPolicy.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutBucketReplication.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutBucketReplication.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutBucketTagging.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutBucketTagging.html) ++ [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutBucketVersioning.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutBucketVersioning.html) ## S3 on Outposts API operations for managing Outposts @@ -66,5 +69,4 @@ S3 on Outposts supports the following Amazon S3 on Outposts API operations for m + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3outposts_DeleteEndpoint.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3outposts_DeleteEndpoint.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3outposts_ListEndpoints.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3outposts_ListEndpoints.html) + [ListOutpostsWithS3](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3outposts_ListOutpostsWithS3.html) -+ [ListOutpostsWithS3](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3outposts_ListOutpostsWithS3.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3outposts_ListSharedEndpoints.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3outposts_ListSharedEndpoints.html) \ No newline at end of file diff --git a/doc_source/ShareObjectPreSignedURL.md b/doc_source/ShareObjectPreSignedURL.md index 68ad638..104640f 100644 --- a/doc_source/ShareObjectPreSignedURL.md +++ b/doc_source/ShareObjectPreSignedURL.md @@ -202,7 +202,7 @@ const createPresignedUrlWithoutClient = async ({ region, bucket, key }) => { return formatUrl(signedUrlObject); }; -const createPresignedUrlWithClient = async ({ region, bucket, key }) => { +const createPresignedUrlWithClient = ({ region, bucket, key }) => { const client = new S3Client({ region }); const command = new GetObjectCommand({ Bucket: bucket, Key: key }); return getSignedUrl(client, command, { expiresIn: 3600 }); @@ -210,8 +210,8 @@ const createPresignedUrlWithClient = async ({ region, bucket, key }) => { export const main = async () => { const REGION = "us-east-1"; - const BUCKET = "coreys-default-bucket"; - const KEY = "corey_mug.jpg"; + const BUCKET = "example_bucket"; + const KEY = "example_file.jpg"; try { const noClientUrl = await createPresignedUrlWithoutClient({ diff --git a/doc_source/UsingBucket.md b/doc_source/UsingBucket.md index 66cdc22..a2d9b76 100644 --- a/doc_source/UsingBucket.md +++ b/doc_source/UsingBucket.md @@ -2,9 +2,9 @@ To upload your data \(photos, videos, documents, etc\.\) to Amazon S3, you must first create an S3 bucket in one of the AWS Regions\. -A bucket is a container for objects stored in Amazon S3\. You can store any number of objects in a bucket and can have up to 100 buckets in your account\. To request an increase, visit the [Service Quotas Console](https://console.aws.amazon.com/servicequotas/home/services/s3/quotas/)\. +A bucket is a container for objects stored in Amazon S3\. You can store any number of objects in a bucket and can have up to 100 buckets in your account\. To request an increase, visit the [Service Quotas console](https://console.aws.amazon.com/servicequotas/home/services/s3/quotas/)\. -Every object is contained in a bucket\. For example, if the object named `photos/puppy.jpg` is stored in the `DOC-EXAMPLE-BUCKET` bucket in the US West \(Oregon\) Region, then it is addressable using the URL `https://DOC-EXAMPLE-BUCKET.s3.us-west-2.amazonaws.com/photos/puppy.jpg`\. For more information, see [Accessing a Bucket](access-bucket-intro.md)\. +Every object is contained in a bucket\. For example, if the object named `photos/puppy.jpg` is stored in the `DOC-EXAMPLE-BUCKET` bucket in the US West \(Oregon\) Region, then it is addressable by using the URL `https://DOC-EXAMPLE-BUCKET.s3.us-west-2.amazonaws.com/photos/puppy.jpg`\. For more information, see [Accessing a Bucket](access-bucket-intro.md)\. In terms of implementation, buckets and objects are AWS resources, and Amazon S3 provides APIs for you to manage them\. For example, you can create a bucket and upload objects using the Amazon S3 API\. You can also use the Amazon S3 console to perform these operations\. The console uses the Amazon S3 APIs to send requests to Amazon S3\. @@ -12,9 +12,9 @@ This section describes how to work with buckets\. For information about working Amazon S3 supports global buckets, which means that each bucket name must be unique across all AWS accounts in all the AWS Regions within a partition\. A partition is a grouping of Regions\. AWS currently has three partitions: `aws` \(Standard Regions\), `aws-cn` \(China Regions\), and `aws-us-gov` \(AWS GovCloud \(US\)\)\. - After a bucket is created, the name of that bucket cannot be used by another AWS account in the same partition until the bucket is deleted\. You should not depend on specific bucket naming conventions for availability or security verification purposes\. For bucket naming guidelines, see [Bucket naming rules](bucketnamingrules.md)\. +After a bucket is created, the name of that bucket cannot be used by another AWS account in the same partition until the bucket is deleted\. You should not depend on specific bucket naming conventions for availability or security verification purposes\. For bucket naming guidelines, see [Bucket naming rules](bucketnamingrules.md)\. -Amazon S3 creates buckets in a Region that you specify\. To optimize latency, minimize costs, or address regulatory requirements, choose any AWS Region that is geographically close to you\. For example, if you reside in Europe, you might find it advantageous to create buckets in the Europe \(Ireland\) or Europe \(Frankfurt\) Regions\. For a list of Amazon S3 Regions, see [Regions and Endpoints](https://docs.aws.amazon.com/general/latest/gr/s3.html) in the *AWS General Reference*\. +Amazon S3 creates buckets in a Region that you specify\. To reduce latency, minimize costs, or address regulatory requirements, choose any AWS Region that is geographically close to you\. For example, if you reside in Europe, you might find it advantageous to create buckets in the Europe \(Ireland\) or Europe \(Frankfurt\) Regions\. For a list of Amazon S3 Regions, see [Regions and Endpoints](https://docs.aws.amazon.com/general/latest/gr/s3.html) in the *AWS General Reference*\. **Note** Objects that belong to a bucket that you create in a specific AWS Region never leave that Region, unless you explicitly transfer them to another Region\. For example, objects that are stored in the Europe \(Ireland\) Region never leave it\. @@ -36,14 +36,18 @@ The AWS account that creates a resource owns that resource\. For example, if you ## Managing public access to buckets -Public access is granted to buckets and objects through access control lists \(ACLs\), bucket policies, or both\. To help you manage public access to Amazon S3 resources, Amazon S3 provides settings to block public access\. Amazon S3 Block Public Access settings can override ACLs and bucket policies so that you can enforce uniform limits on public access to these resources\. You can apply Block Public Access settings to individual buckets or to all buckets in your account\. +Public access is granted to buckets and objects through bucket policies, access control lists \(ACLs\), or both\. To help you manage public access to Amazon S3 resources, Amazon S3 provides settings to block public access\. Amazon S3 Block Public Access settings can override ACLs and bucket policies so that you can enforce uniform limits on public access to these resources\. You can apply Block Public Access settings to individual buckets or to all buckets in your account\. -To help ensure that all of your Amazon S3 buckets and objects have their public access blocked, we recommend that you turn on all four settings for Block Public Access for your account\. These settings block all public access for all current and future buckets\. +To ensure that all of your Amazon S3 buckets and objects have their public access blocked, all four settings for Block Public Access are enabled by default when you create a new bucket\. We recommend that you turn on all four settings for Block Public Access for your account too\. These settings block all public access for all current and future buckets\. -Before applying these settings, verify that your applications will work correctly without public access\. If you require some level of public access to your buckets or objects—for example, to host a static website as described at [Hosting a static website using Amazon S3](WebsiteHosting.md)—you can customize the individual settings to suit your storage use cases\. For more information, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. +Before applying these settings, verify that your applications will work correctly without public access\. If you require some level of public access to your buckets or objects—for example, to host a static website, as described at [Hosting a static website using Amazon S3](WebsiteHosting.md)—you can customize the individual settings to suit your storage use cases\. For more information, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. + + However, we highly recommend keeping Block Public Access enabled\. If you want to keep all four Block Public Access settings enabled and host a static website, you can use Amazon CloudFront origin access control \(OAC\)\. Amazon CloudFront provides the capabilities required to set up a secure static website\. Amazon S3 static websites support only HTTP endpoints\. Amazon CloudFront uses the durable storage of Amazon S3 while providing additional security headers, such as HTTPS\. HTTPS adds security by encrypting a normal HTTP request and protecting against common cyberattacks\. + +For more information, see [Getting started with a secure static website](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/getting-started-secure-static-website-cloudformation-template.html) in the *Amazon CloudFront Developer Guide*\. **Note** -If you see an `Error` when you list your buckets and their public access settings, you might not have the required permissions\. Check to make sure you have the following permissions added to your user or role policy: +If you see an `Error` when you list your buckets and their public access settings, you might not have the required permissions\. Make sure that you have the following permissions added to your user or role policy: ``` s3:GetAccountPublicAccessBlock diff --git a/doc_source/WebsiteAccessPermissionsReqd.md b/doc_source/WebsiteAccessPermissionsReqd.md index 06aab92..2f5514f 100644 --- a/doc_source/WebsiteAccessPermissionsReqd.md +++ b/doc_source/WebsiteAccessPermissionsReqd.md @@ -90,12 +90,12 @@ The following policy is an example only and allows full access to the contents o You can use a bucket policy to grant public read permission to your objects\. However, the bucket policy applies only to objects that are owned by the bucket owner\. If your bucket contains objects that aren't owned by the bucket owner, the bucket owner should use the object access control list \(ACL\) to grant public READ permission on those objects\. -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. +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, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. + 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 unusual 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, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. To make an object publicly readable using an ACL, grant READ permission to the `AllUsers` group, as shown in the following grant element\. Add this grant element to the object ACL\. For information about managing ACLs, see [Access control list \(ACL\) overview](acl-overview.md)\. diff --git a/doc_source/Welcome.md b/doc_source/Welcome.md index dd060a3..4dada15 100644 --- a/doc_source/Welcome.md +++ b/doc_source/Welcome.md @@ -29,16 +29,16 @@ Amazon S3 has storage management features that you can use to manage costs, meet + [S3 Replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) – Replicate objects and their respective metadata and object tags to one or more destination buckets in the same or different AWS Regions for reduced latency, compliance, security, and other use cases\. + [S3 Batch Operations](https://docs.aws.amazon.com/AmazonS3/latest/userguide/batch-ops.html) – Manage billions of objects at scale with a single S3 API request or a few clicks in the Amazon S3 console\. You can use Batch Operations to perform operations such as **Copy**, **Invoke AWS Lambda function**, and **Restore** on millions or billions of objects\. -### Access management +### Access management and security Amazon S3 provides features for auditing and managing access to your buckets and objects\. By default, S3 buckets and the objects in them are private\. You have access only to the S3 resources that you create\. To grant granular resource permissions that support your specific use case or to audit the permissions of your Amazon S3 resources, you can use the following features\. -+ [S3 Block Public Access](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html) – Block public access to S3 buckets and objects\. By default, Block Public Access settings are turned on at the account and bucket level\. ++ [S3 Block Public Access](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html) – Block public access to S3 buckets and objects\. By default, Block Public Access settings are turned on at the bucket level\. We recommend that you keep all Block Public Access settings enabled unless you know that you need to turn off one or more of them for your specific use case\. For more information, see [Configuring block public access settings for your S3 buckets](configuring-block-public-access-bucket.md)\. + [AWS Identity and Access Management \(IAM\)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) – IAM is a web service that helps you securely control access to AWS resources, including your Amazon S3 resources\. With IAM, you can centrally manage permissions that control which AWS resources users can access\. You use IAM to control who is authenticated \(signed in\) and authorized \(has permissions\) to use resources\. + [Bucket policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) – Use IAM\-based policy language to configure resource\-based permissions for your S3 buckets and the objects in them\. + [Amazon S3 access points](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html) – Configure named network endpoints with dedicated access policies to manage data access at scale for shared datasets in Amazon S3\. -+ [Access control lists \(ACLs\)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acls.html) – Grant read and write permissions for individual buckets and objects to authorized users\. 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\. ACLs are an access control mechanism that predates resource\-based policies and IAM\. For more information about when you'd use ACLs instead of resource\-based policies or IAM policies, see [Access policy guidelines](access-policy-alternatives-guidelines.md)\. -+ [S3 Object Ownership](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) – Disable ACLs and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. You, as the bucket owner, automatically own and have full control over every object in your bucket, and access control for your data is based on policies\. -+ [Access Analyzer for S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-analyzer.html) – Evaluate and monitor your S3 bucket access policies, ensuring that the policies provide only the intended access to your S3 resources\. ++ [Access control lists \(ACLs\)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acls.html) – Grant read and write permissions for individual buckets and objects to authorized users\. As a general rule, we recommend using S3 resource\-based policies \(bucket policies and access point policies\) or IAM user 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\. For more information about the specific cases when you'd use ACLs instead of resource\-based policies or IAM user policies, see [Access policy guidelines](access-policy-alternatives-guidelines.md)\. ++ [S3 Object Ownership](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) – Take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable or enable ACLs\. By default, ACLs are disabled\. With ACLs disabled, the bucket owner owns all the objects in the bucket and manages access to data exclusively by using access\-management policies\. ++ [IAM Access Analyzer for S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-analyzer.html) – Evaluate and monitor your S3 bucket access policies, ensuring that the policies provide only the intended access to your S3 resources\. ### Data processing @@ -92,9 +92,9 @@ Buckets and the objects in them are private and can be accessed only if you expl ### Buckets -A bucket is a container for objects stored in Amazon S3\. You can store any number of objects in a bucket and can have up to 100 buckets in your account\. To request an increase, visit the [Service Quotas Console](https://console.aws.amazon.com/servicequotas/home/services/s3/quotas/)\. +A bucket is a container for objects stored in Amazon S3\. You can store any number of objects in a bucket and can have up to 100 buckets in your account\. To request an increase, visit the [Service Quotas console](https://console.aws.amazon.com/servicequotas/home/services/s3/quotas/)\. -Every object is contained in a bucket\. For example, if the object named `photos/puppy.jpg` is stored in the `DOC-EXAMPLE-BUCKET` bucket in the US West \(Oregon\) Region, then it is addressable using the URL `https://DOC-EXAMPLE-BUCKET.s3.us-west-2.amazonaws.com/photos/puppy.jpg`\. For more information, see [Accessing a Bucket](access-bucket-intro.md)\. +Every object is contained in a bucket\. For example, if the object named `photos/puppy.jpg` is stored in the `DOC-EXAMPLE-BUCKET` bucket in the US West \(Oregon\) Region, then it is addressable by using the URL `https://DOC-EXAMPLE-BUCKET.s3.us-west-2.amazonaws.com/photos/puppy.jpg`\. For more information, see [Accessing a Bucket](access-bucket-intro.md)\. When you create a bucket, you enter a bucket name and choose the AWS Region where the bucket will reside\. After you create a bucket, you cannot change the name of the bucket or its Region\. Bucket names must follow the [bucket naming rules](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)\. You can also configure a bucket to use [S3 Versioning](Versioning.md) or other [storage management](https://docs.aws.amazon.com/AmazonS3/latest/userguide/managing-storage.html) features\. @@ -152,9 +152,9 @@ For more information, see [Managing data access with Amazon S3 access points](ac You can use ACLs to grant read and write permissions to authorized users for individual buckets and objects\. Each bucket and object has an ACL attached to it as a subresource\. The ACL defines which AWS accounts or groups are granted access and the type of access\. ACLs are an access control mechanism that predates IAM\. For more information about ACLs, see [Access control list \(ACL\) overview](acl-overview.md)\. -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. +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, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. + 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 unusual 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, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. ### Regions @@ -225,7 +225,7 @@ The [AWS Command Line Interface \(AWS CLI\)](http://aws.amazon.com/cli/) provide ### AWS SDKs -AWS provides SDKs \(software development kits\) that consist of libraries and sample code for various programming languages and platforms \(Java, Python, Ruby, \.NET, iOS, Android, and so on\)\. The AWS SDKs provide a convenient way to create programmatic access to S3 and AWS\. Amazon S3 is a REST service\. You can send requests to Amazon S3 using the AWS SDK libraries\. which wrap the underlying Amazon S3 REST API and simplify your programming tasks\. For example, the SDKs take care of tasks such as calculating signatures, cryptographically signing requests, managing errors, and retrying requests automatically\. For information about the AWS SDKs, including how to download and install them, see [Tools for AWS](http://aws.amazon.com/tools/)\. +AWS provides SDKs \(software development kits\) that consist of libraries and sample code for various programming languages and platforms \(Java, Python, Ruby, \.NET, iOS, Android, and so on\)\. The AWS SDKs provide a convenient way to create programmatic access to S3 and AWS\. Amazon S3 is a REST service\. You can send requests to Amazon S3 using the AWS SDK libraries, which wrap the underlying Amazon S3 REST API and simplify your programming tasks\. For example, the SDKs take care of tasks such as calculating signatures, cryptographically signing requests, managing errors, and retrying requests automatically\. For information about the AWS SDKs, including how to download and install them, see [Tools for AWS](http://aws.amazon.com/tools/)\. Every interaction with Amazon S3 is either authenticated or anonymous\. If you are using the AWS SDKs, the libraries compute the signature for authentication from the keys that you provide\. For more information about how to make requests to Amazon S3, see [Making requests](MakingRequests.md)\. diff --git a/doc_source/about-object-ownership.md b/doc_source/about-object-ownership.md index 2bd52b9..4e619cc 100644 --- a/doc_source/about-object-ownership.md +++ b/doc_source/about-object-ownership.md @@ -15,9 +15,6 @@ Object Ownership has three settings that you can use to control ownership of obj + **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 \(default\)** – 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\. -**Important** -Starting in April 2023, Amazon S3 will change the default settings for S3 Block Public Access and Object Ownership \(ACLs disabled\) for all new S3 buckets\. For new buckets created after this update, all S3 Block Public Access settings will be enabled, and S3 access control lists \(ACLs\) will be disabled\. These defaults are the recommended best practices for securing data in Amazon S3\. You can adjust these settings after creating your bucket\. For more information, see [ Default settings for new S3 buckets FAQ](create-bucket-faq.md) and [Heads\-Up: Amazon S3 Security Changes Are Coming in April of 2023](http://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/) in the * AWS News Blog*\. - For the majority of modern use cases in S3, we recommend that you disable ACLs by choosing the bucket owner enforced setting and use your bucket policy to share data with users outside of your account as needed\. This approach simplifies permissions management and auditing\. You can disable ACLs on both newly created and already existing buckets\. 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\. You must reset your bucket ACL to the default \(full control to the bucket owner\)\. 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`\. diff --git a/doc_source/access-analyzer.md b/doc_source/access-analyzer.md index c9d508f..e477b0d 100644 --- a/doc_source/access-analyzer.md +++ b/doc_source/access-analyzer.md @@ -1,39 +1,39 @@ -# Reviewing bucket access using Access Analyzer for S3 +# Reviewing bucket access using IAM Access Analyzer for S3 -Access Analyzer for S3 alerts you to S3 buckets that are configured to allow access to anyone on the internet or other AWS accounts, including AWS accounts outside of your organization\. For each public or shared bucket, you receive findings into the source and level of public or shared access\. For example, Access Analyzer for S3 might show that a bucket has read or write access provided through a bucket access control list \(ACL\), a bucket policy, a Multi\-Region Access Point policy, or an access point policy\. With these findings, you can take immediate and precise corrective action to restore your bucket access to what you intended\. +IAM Access Analyzer for S3 alerts you to S3 buckets that are configured to allow access to anyone on the internet or other AWS accounts, including AWS accounts outside of your organization\. For each public or shared bucket, you receive findings into the source and level of public or shared access\. For example, IAM Access Analyzer for S3 might show that a bucket has read or write access provided through a bucket access control list \(ACL\), a bucket policy, a Multi\-Region Access Point policy, or an access point policy\. With these findings, you can take immediate and precise corrective action to restore your bucket access to what you intended\. -When reviewing an at\-risk bucket in Access Analyzer for S3, you can block all public access to the bucket with a single click\. We recommend that you block all access to your buckets unless you require public access to support a specific use case\. Before you block all public access, ensure that your applications will continue to work correctly without public access\. For more information, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. +When reviewing an at\-risk bucket in IAM Access Analyzer for S3, you can block all public access to the bucket with a single click\. We recommend that you block all access to your buckets unless you require public access to support a specific use case\. Before you block all public access, ensure that your applications will continue to work correctly without public access\. For more information, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. You can also drill down into bucket\-level permission settings to configure granular levels of access\. For specific and verified use cases that require public access, such as static website hosting, public downloads, or cross\-account sharing, you can acknowledge and record your intent for the bucket to remain public or shared by archiving the findings for the bucket\. You can revisit and modify these bucket configurations at any time\. You can also download your findings as a CSV report for auditing purposes\. -Access Analyzer for S3 is available at no extra cost on the Amazon S3 console\. Access Analyzer for S3 is powered by AWS Identity and Access Management \(IAM\) Access Analyzer\. To use Access Analyzer for S3 in the Amazon S3 console, you must visit the IAM console and enable IAM Access Analyzer on a per\-Region basis\. +IAM Access Analyzer for S3 is available at no extra cost on the Amazon S3 console\. IAM Access Analyzer for S3 is powered by AWS Identity and Access Management \(IAM\) IAM Access Analyzer\. To use IAM Access Analyzer for S3 in the Amazon S3 console, you must visit the IAM console and enable IAM IAM Access Analyzer on a per\-Region basis\. -For more information about IAM Access Analyzer, see [What is Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) in the *IAM User Guide*\. For more information about Access Analyzer for S3, review the following sections\. +For more information about IAM IAM Access Analyzer, see [What is IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) in the *IAM User Guide*\. For more information about IAM Access Analyzer for S3, review the following sections\. **Important** -Access Analyzer for S3 requires an account\-level analyzer\. To use Access Analyzer for S3, you must visit IAM Access Analyzer and create an analyzer that has an account as the zone of trust\. For more information, see [Enabling Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html#access-analyzer-enabling) in *IAM User Guide*\. -Access Analyzer for S3 doesn't analyze the access point policy that's attached to cross\-account access points\. This behavior occurs because the access point and its policy are outside the zone of trust, that is, the account\. Buckets that delegate access to a cross\-account access point are listed under **Buckets with public access** if you haven't applied the `RestrictPublicBuckets` block public access setting to the bucket or account\. When you apply the `RestrictPublicBuckets` block public access setting, the bucket is reported under **Buckets with access from other AWS accounts — including third\-party AWS accounts**\. -When a bucket policy or bucket ACL is added or modified, Access Analyzer generates and updates findings based on the change within 30 minutes\. Findings related to account level block public access settings might not be generated or updated for up to 6 hours after you change the settings\. Findings related to Multi\-Region Access Points might not be generated or updated for up to six hours after the Multi\-Region Access Point is created, deleted, or you change its policy\. +IAM Access Analyzer for S3 requires an account\-level analyzer\. To use IAM Access Analyzer for S3, you must visit IAM IAM Access Analyzer and create an analyzer that has an account as the zone of trust\. For more information, see [Enabling IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html#access-analyzer-enabling) in *IAM User Guide*\. +IAM Access Analyzer for S3 doesn't analyze the access point policy that's attached to cross\-account access points\. This behavior occurs because the access point and its policy are outside the zone of trust, that is, the account\. Buckets that delegate access to a cross\-account access point are listed under **Buckets with public access** if you haven't applied the `RestrictPublicBuckets` block public access setting to the bucket or account\. When you apply the `RestrictPublicBuckets` block public access setting, the bucket is reported under **Buckets with access from other AWS accounts — including third\-party AWS accounts**\. +When a bucket policy or bucket ACL is added or modified, IAM Access Analyzer generates and updates findings based on the change within 30 minutes\. Findings related to account level block public access settings might not be generated or updated for up to 6 hours after you change the settings\. Findings related to Multi\-Region Access Points might not be generated or updated for up to six hours after the Multi\-Region Access Point is created, deleted, or you change its policy\. ****Topics**** -+ [What information does Access Analyzer for S3 provide?](#access-analyzer-information-s3) -+ [Enabling Access Analyzer for S3](#enabling-access-analyzer) ++ [What information does IAM Access Analyzer for S3 provide?](#access-analyzer-information-s3) ++ [Enabling IAM Access Analyzer for S3](#enabling-access-analyzer) + [Blocking all public access](#blocking-public-access-access-analyzer) + [Reviewing and changing bucket access](#changing-bucket-access) + [Archiving bucket findings](#archiving-buckets) + [Activating an archived bucket finding](#activating-buckets) + [Viewing finding details](#viewing-finding-details) -+ [Downloading an Access Analyzer for S3 report](#downloading-bucket-report-s3) ++ [Downloading an IAM Access Analyzer for S3 report](#downloading-bucket-report-s3) -## What information does Access Analyzer for S3 provide? +## What information does IAM Access Analyzer for S3 provide? -Access Analyzer for S3 provides findings for buckets that can be accessed outside your AWS account\. Buckets that are listed under **Buckets with public access** can be accessed by anyone on the internet\. If Access Analyzer for S3 identifies public buckets, you also see a warning at the top of the page that shows you the number of public buckets in your Region\. Buckets listed under **Buckets with access from other AWS accounts — including third\-party AWS accounts** are shared conditionally with other AWS accounts, including accounts outside of your organization\. +IAM Access Analyzer for S3 provides findings for buckets that can be accessed outside your AWS account\. Buckets that are listed under **Buckets with public access** can be accessed by anyone on the internet\. If IAM Access Analyzer for S3 identifies public buckets, you also see a warning at the top of the page that shows you the number of public buckets in your Region\. Buckets listed under **Buckets with access from other AWS accounts — including third\-party AWS accounts** are shared conditionally with other AWS accounts, including accounts outside of your organization\. -For each bucket, Access Analyzer for S3 provides the following information: +For each bucket, IAM Access Analyzer for S3 provides the following information: + **Bucket name** -+ **Discovered by Access analyzer** ‐ When Access Analyzer for S3 discovered the public or shared bucket access\. ++ **Discovered by Access analyzer** ‐ When IAM Access Analyzer for S3 discovered the public or shared bucket access\. + **Shared through** ‐ How the bucket is shared—through a bucket policy, a bucket ACL, a Multi\-Region Access Point policy, or an access point policy\. Multi\-Region Access Points and cross\-account access points are reflected under access points\. A bucket can be shared through both policies and ACLs\. If you want to find and review the source for your bucket access, you can use the information in this column as a starting point for taking immediate and precise corrective action\. -+ **Status** ‐ The status of the bucket finding\. Access Analyzer for S3 displays findings for all public and shared buckets\. ++ **Status** ‐ The status of the bucket finding\. IAM Access Analyzer for S3 displays findings for all public and shared buckets\. + **Active **‐ Finding has not been reviewed\. + **Archived** ‐ Finding has been reviewed and confirmed as intended\. + **All** ‐ All findings for buckets that are public or shared with other AWS accounts, including AWS accounts outside of your organization\. @@ -44,39 +44,39 @@ For each bucket, Access Analyzer for S3 provides the following information: + **Permissions** ‐ Grant or modify resource permissions\. + **Tagging** ‐ Update tags associated with the resource\. -## Enabling Access Analyzer for S3 +## Enabling IAM Access Analyzer for S3 -To use Access Analyzer for S3, you must complete the following prerequisite steps\. +To use IAM Access Analyzer for S3, you must complete the following prerequisite steps\. 1. Grant the required permissions\. - For more information, see [Permissions Required to use Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html#access-analyzer-permissions) in the *IAM User Guide*\. + For more information, see [Permissions Required to use IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html#access-analyzer-permissions) in the *IAM User Guide*\. -1. Visit IAM to create an account\-level analyzer for each Region where you want to use Access Analyzer\. +1. Visit IAM to create an account\-level analyzer for each Region where you want to use IAM Access Analyzer\. - Access Analyzer for S3 requires an account\-level analyzer\. To use Access Analyzer for S3, you must create an analyzer that has an account as the zone of trust\. For more information, see [Enabling Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html#access-analyzer-enabling) in *IAM User Guide*\. + IAM Access Analyzer for S3 requires an account\-level analyzer\. To use IAM Access Analyzer for S3, you must create an analyzer that has an account as the zone of trust\. For more information, see [Enabling IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html#access-analyzer-enabling) in *IAM User Guide*\. ## Blocking all public access -If you want to block all access to a bucket in a single click, you can use the **Block all public access** button in Access Analyzer for S3\. When you block all public access to a bucket, no public access is granted\. We recommend that you block all public access to your buckets unless you require public access to support a specific and verified use case\. Before you block all public access, ensure that your applications will continue to work correctly without public access\. +If you want to block all access to a bucket in a single click, you can use the **Block all public access** button in IAM Access Analyzer for S3\. When you block all public access to a bucket, no public access is granted\. We recommend that you block all public access to your buckets unless you require public access to support a specific and verified use case\. Before you block all public access, ensure that your applications will continue to work correctly without public access\. If you don't want to block all public access to your bucket, you can edit your block public access settings on the Amazon S3 console to configure granular levels of access to your buckets\. For more information, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. -In rare events, Access Analyzer for S3 might report no findings for a bucket that an Amazon S3 block public access evaluation reports as public\. This happens because Amazon S3 block public access reviews policies for current actions and any potential actions that might be added in the future, leading to a bucket becoming public\. On the other hand, Access Analyzer for S3 only analyzes the current actions specified for the Amazon S3 service in the evaluation of access status\. +In rare events, IAM Access Analyzer for S3 might report no findings for a bucket that an Amazon S3 block public access evaluation reports as public\. This happens because Amazon S3 block public access reviews policies for current actions and any potential actions that might be added in the future, leading to a bucket becoming public\. On the other hand, IAM Access Analyzer for S3 only analyzes the current actions specified for the Amazon S3 service in the evaluation of access status\. -**To block all public access to a bucket using Access Analyzer for S3** +**To block all public access to a bucket using IAM Access Analyzer for S3** 1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console\.aws\.amazon\.com/s3/](https://console.aws.amazon.com/s3/)\. 1. In the navigation pane on the left, under **Dashboards**, choose **Access analyzer for S3**\. -1. In Access Analyzer for S3, choose a bucket\. +1. In IAM Access Analyzer for S3, choose a bucket\. 1. Choose **Block all public access**\. 1. To confirm your intent to block all public access to the bucket, in **Block all public access \(bucket settings\)**, enter **confirm**\. - Amazon S3 blocks all public access to your bucket\. The status of the bucket finding updates to **resolved**, and the bucket disappears from the Access Analyzer for S3 listing\. If you want to review resolved buckets, open IAM Access Analyzer on the IAM console\. + Amazon S3 blocks all public access to your bucket\. The status of the bucket finding updates to **resolved**, and the bucket disappears from the IAM Access Analyzer for S3 listing\. If you want to review resolved buckets, open IAM IAM Access Analyzer on the IAM console\. ## Reviewing and changing bucket access @@ -132,19 +132,19 @@ If you did not intend to grant access to the public or other AWS accounts, inclu For more information, see [Using Amazon S3 access points with the Amazon S3 console](access-points-manage.md)\. - If you edit or remove a bucket ACL, a bucket policy, or an access point policy to remove public or shared access, the status for the bucket findings updates to resolved\. The resolved bucket findings disappear from the Access Analyzer for S3 listing, but you can view them in IAM Access Analyzer\. + If you edit or remove a bucket ACL, a bucket policy, or an access point policy to remove public or shared access, the status for the bucket findings updates to resolved\. The resolved bucket findings disappear from the IAM Access Analyzer for S3 listing, but you can view them in IAM IAM Access Analyzer\. ## Archiving bucket findings -If a bucket grants access to the public or other AWS accounts, including accounts outside of your organization, to support a specific use case \(for example, a static website, public downloads, or cross\-account sharing\), you can archive the finding for the bucket\. When you archive bucket findings, you acknowledge and record your intent for the bucket to remain public or shared\. Archived bucket findings remain in your Access Analyzer for S3 listing so that you always know which buckets are public or shared\. +If a bucket grants access to the public or other AWS accounts, including accounts outside of your organization, to support a specific use case \(for example, a static website, public downloads, or cross\-account sharing\), you can archive the finding for the bucket\. When you archive bucket findings, you acknowledge and record your intent for the bucket to remain public or shared\. Archived bucket findings remain in your IAM Access Analyzer for S3 listing so that you always know which buckets are public or shared\. -**To archive bucket findings in Access Analyzer for S3** +**To archive bucket findings in IAM Access Analyzer for S3** 1. Open the Amazon S3 console at [https://console\.aws\.amazon\.com/s3/](https://console.aws.amazon.com/s3/)\. 1. In the navigation pane, choose **Access analyzer for S3**\. -1. In Access Analyzer for S3, choose an active bucket\. +1. In IAM Access Analyzer for S3, choose an active bucket\. 1. To acknowledge your intent for this bucket to be accessed by the public or other AWS accounts, including accounts outside of your organization, choose **Archive**\. @@ -154,7 +154,7 @@ If a bucket grants access to the public or other AWS accounts, including account After you archive findings, you can always revisit them and change their status back to active, indicating that the bucket requires another review\. -**To activate an archived bucket finding in Access Analyzer for S3** +**To activate an archived bucket finding in IAM Access Analyzer for S3** 1. Open the Amazon S3 console at [https://console\.aws\.amazon\.com/s3/](https://console.aws.amazon.com/s3/)\. @@ -166,23 +166,23 @@ After you archive findings, you can always revisit them and change their status ## Viewing finding details -If you need to see more information about a bucket, you can open the bucket finding details in IAM Access Analyzer on the IAM console\. +If you need to see more information about a bucket, you can open the bucket finding details in IAM IAM Access Analyzer on the IAM console\. -**To view finding details in Access Analyzer for S3** +**To view finding details in IAM Access Analyzer for S3** 1. Open the Amazon S3 console at [https://console\.aws\.amazon\.com/s3/](https://console.aws.amazon.com/s3/)\. 1. In the navigation pane, choose **Access analyzer for S3**\. -1. In Access Analyzer for S3, choose a bucket\. +1. In IAM Access Analyzer for S3, choose a bucket\. 1. Choose **View details**\. - The finding details open in IAM Access Analyzer on the IAM console\. + The finding details open in IAM IAM Access Analyzer on the IAM console\. -## Downloading an Access Analyzer for S3 report +## Downloading an IAM Access Analyzer for S3 report -You can download your bucket findings as a CSV report that you can use for auditing purposes\. The report includes the same information that you see in Access Analyzer for S3 on the Amazon S3 console\. +You can download your bucket findings as a CSV report that you can use for auditing purposes\. The report includes the same information that you see in IAM Access Analyzer for S3 on the Amazon S3 console\. **To download a report** @@ -192,7 +192,7 @@ You can download your bucket findings as a CSV report that you can use for audit 1. In the Region filter, choose the Region\. - Access Analyzer for S3 updates to shows buckets for the chosen Region\. + IAM Access Analyzer for S3 updates to shows buckets for the chosen Region\. 1. Choose **Download report**\. diff --git a/doc_source/access-control-best-practices.md b/doc_source/access-control-best-practices.md index 6863dc3..4fb3991 100644 --- a/doc_source/access-control-best-practices.md +++ b/doc_source/access-control-best-practices.md @@ -10,49 +10,49 @@ Amazon S3 provides a variety of security features and tools\. The following scen ## Creating a new bucket -When creating a new bucket, you should apply the following tools and settings to help ensure that your Amazon S3 resources are protected\.  +When creating a new bucket, you should apply the following tools and settings to help ensure that your Amazon S3 resources are protected\. **S3 Object Ownership for simplifying access control** -S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable access control lists \(ACLs\) and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. + S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use both to control ownership of objects that are 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\. With ACLs disabled, the bucket owner owns every object in the bucket and manages access to data exclusively by using policies\. -Object Ownership has three settings that you can use to control ownership of objects uploaded in your bucket and disable or enable ACLs: +Object Ownership has three settings that you can use both to control ownership of objects that are uploaded to your bucket and to disable or enable ACLs: **ACLs disabled** -+ **Bucket owner enforced \(recommended\)** – 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 exclusively to define access control\. ++ **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 exclusively 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 \(default\)** – 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\. ++ **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 more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **Block Public Access** -S3 Block Public Access provides four settings to help you avoid inadvertently exposing your S3 resources\. You can apply these settings in any combination to individual access points, buckets, or entire AWS accounts\. If you apply a setting to an account, it applies to all buckets and access points that are owned by that account\. By default, the **Block all public access** setting is applied to new buckets created in the Amazon S3 console\.  +S3 Block Public Access provides four settings to help you avoid inadvertently exposing your S3 resources\. You can apply these settings in any combination to individual access points, buckets, or entire AWS accounts\. If you apply a setting to an account, it applies to all buckets and access points that are owned by that account\. By default, the four **Block all public access** settings are enabled for new buckets\. We recommend that you keep all four settings enabled, unless you know that you need to turn off one or more of them for your specific use case\. You can modify individual Block Public Access settings by using the Amazon S3 console\. For more information, see [The meaning of "public"](access-control-block-public-access.md#access-control-block-public-access-policy-status)\. -If the S3 Block Public Access settings are too restrictive, you can use AWS Identity and Access Management \(IAM\) identities to grant access to specific users rather than disabling all Block Public Access settings\. Using Block Public Access with IAM identities helps ensure that any operation that is blocked by a Block Public Access setting is rejected unless the requesting user has been given specific permission\. +If you need to grant access to specific users, we recommend that you use AWS Identity and Access Management \(IAM\) policies rather than disabling all Block Public Access settings\. Keeping Block Public Access enabled is a security best practice\. Using Block Public Access with IAM identities helps ensure that any operation that is blocked by a Block Public Access setting is rejected unless the requested user has been given specific permission\. For more information, see [Block public access settings](access-control-block-public-access.md#access-control-block-public-access-options)\. **Grant access with IAM identities** -When setting up accounts for new team members who require S3 access, use IAM users and roles to ensure least privileges\. You can also implement a form of IAM multi\-factor authentication \(MFA\) to support a strong identity foundation\. Using IAM identities, you can grant unique permissions to users and specify what resources they can access and what actions they can take\. IAM identities provide increased capabilities, including the ability to require users to enter login credentials before accessing shared resources and apply permission hierarchies to different objects within a single bucket\. +When setting up accounts for new team members who require S3 access, use IAM users and roles to ensure least privileges\. You can also implement a form of IAM multi\-factor authentication \(MFA\) to support a strong identity foundation\. By using IAM identities, you can grant unique permissions to users and specify what resources they can access and what actions they can take\. IAM identities provide increased capabilities, including the ability to require users to enter login credentials before accessing shared resources and to apply permission hierarchies to different objects within a single bucket\. For more information, see [Example 1: Bucket owner granting its users bucket permissions](example-walkthroughs-managing-access-example1.md)\. **Bucket policies** -With bucket policies, you can personalize bucket access to help ensure that only those users you have approved can access resources and perform actions within them\. In addition to bucket policies, you should use bucket\-level Block Public Access settings to further limit public access to your data\. +With bucket policies, you can personalize bucket access to help ensure that only those users that you have approved can access resources and perform actions within them\. In addition to bucket policies, we recommend using bucket\-level Block Public Access settings to further limit public access to your data\. For more information, see [Using bucket policies](bucket-policies.md)\. -When creating policies, avoid the use of wildcard characters in the `Principal` element because it effectively allows anyone to access your Amazon S3 resources\. It's better to explicitly list users or groups that are allowed to access the bucket\. Rather than including a wildcard for their actions, grant them specific permissions when applicable\. +When creating policies, avoid the use of wildcard characters \(`*`\) in the `Principal` element because using a wildcard character allows anyone to access your Amazon S3 resources\. Instead, explicitly list users or groups that are allowed to access the bucket\. Rather than including a wildcard character for their actions, grant them specific permissions when applicable\. -To further maintain the practice of least privileges, `Deny` statements in the `Effect` element should be as broad as possible and `Allow` statements should be as narrow as possible\. `Deny` effects paired with the "`s3:*`" action are another good way to implement opt\-in best practices for the users included in policy condition statements\. +To further maintain the practice of least privileges, `Deny` statements in the `Effect` element should be as broad as possible, and `Allow` statements should be as narrow as possible\. `Deny` effects paired with the `s3:*` action are another good way to implement opt\-in best practices for the users that are included in policy condition statements\. For more information about specifying conditions for when a policy is in effect, see [Amazon S3 condition key examples](amazon-s3-policy-keys.md)\. **Buckets in a VPC setting** -When adding users in a corporate setting, you can use a virtual private cloud \(VPC\) endpoint to allow any users in your virtual network to access your Amazon S3 resources\. VPC endpoints enable developers to provide specific access and permissions to groups of users based on the network the user is connected to\. Rather than adding each user to an IAM role or group, you can use VPC endpoints to deny bucket access if the request doesn’t originate from the specified endpoint\. +When adding users in a corporate setting, you can use a virtual private cloud \(VPC\) endpoint to allow any users in your virtual network to access your Amazon S3 resources\. VPC endpoints enable developers to provide specific access and permissions to groups of users based on the network the user is connected to\. Rather than adding each user to an IAM role or group, you can use VPC endpoints to deny bucket access if the request doesn't originate from the specified endpoint\. For more information, see [Controlling access from VPC endpoints with bucket policies](example-bucket-policies-vpc-endpoint.md)\. @@ -61,60 +61,64 @@ For more information, see [Controlling access from VPC endpoints with bucket pol Use the following tools and best practices to store and share your Amazon S3 data\. **Versioning and Object Lock for data integrity** -If you use the Amazon S3 console to manage buckets and objects, you should implement S3 Versioning and S3 Object Lock\. These features help prevent accidental changes to critical data and enable you to roll back unintended actions\. This capability is particularly useful when there are multiple users with full write and execute permissions accessing the Amazon S3 console\. +If you use the Amazon S3 console to manage buckets and objects, we recommend implementing S3 Versioning and S3 Object Lock\. These features help prevent accidental changes to critical data and enable you to roll back unintended actions\. This rollback capability is particularly useful when there are multiple users with full write and execute permissions who are accessing the Amazon S3 console\. For information about S3 Versioning, see [Using versioning in S3 buckets](Versioning.md)\. For information about Object Lock, see [Using S3 Object Lock](object-lock.md)\. **Object lifecycle management for cost efficiency** -To manage your objects so that they are stored cost effectively throughout their lifecycle, you can pair lifecycle configurations with object versioning\. Lifecycle configurations define actions that you want S3 to take during an object's lifetime\. For example, you can create a lifecycle configuration that will transition objects to another storage class, archive them, or delete them after a specified period of time\. You can define a lifecycle configuration for all objects or a subset of objects in the bucket by using a shared prefix or tag\. +To manage your objects so that they are stored cost\-effectively throughout their lifecycle, you can pair lifecycle configurations with S3 Versioning\. Lifecycle configurations define actions that you want Amazon S3 to take during an object's lifetime\. For example, you can create a lifecycle configuration that will transition objects to another storage class, archive them, or delete them after a specified period of time\. You can define a lifecycle configuration for all objects in the bucket or for a subset of objects by using a shared prefix or tag\. For more information, see [Managing your storage lifecycle](object-lifecycle-mgmt.md)\. **Cross\-Region Replication for multiple office locations** -When creating buckets that are accessed by different office locations, you should consider implementing S3 Cross\-Region Replication\. Cross\-Region Replication helps ensure that all users have access to the resources they need and increases operational efficiency\. Cross\-Region Replication offers increased availability by copying objects across S3 buckets in different AWS Regions\. However, the use of this tool increases storage costs\. +When creating buckets that are accessed by different office locations, consider implementing S3 Cross\-Region Replication\. Cross\-Region Replication helps ensure that all users have access to the resources that they need and increases operational efficiency\. Cross\-Region Replication offers increased availability by copying objects across S3 buckets in different AWS Regions\. However, the use of this feature increases storage costs\. For more information, see [Replicating objects](replication.md)\. **Permissions for secure static website hosting** -When configuring a bucket to be used as a publicly accessed static website, you must disable all Block Public Access settings\. It is important to only provide `s3:GetObject` actions and not `ListObject` or `PutObject` permissions when writing the bucket policy for your static website\. This helps ensure that users cannot view all the objects in your bucket or add their own content\. +When configuring a bucket to be used as a publicly accessed static website, you must disable all Block Public Access settings\. When writing the bucket policy for your static website, make sure that you allow only `s3:GetObject` actions, not `ListObject` or `PutObject` permissions\. Doing so helps ensure that users cannot view all the objects in your bucket or add their own content\. For more information, see [Setting permissions for website access](WebsiteAccessPermissionsReqd.md)\. -Amazon CloudFront provides the capabilities required to set up a secure static website\. Amazon S3 static websites only support HTTP endpoints\. CloudFront uses the durable storage of Amazon S3 while providing additional security headers like HTTPS\. HTTPS adds security by encrypting a normal HTTP request and protecting against common cyberattacks\. +We recommended keeping Block Public Access enabled\. If you want to keep all four Block Public Access settings enabled and host a static website, you can use Amazon CloudFront origin access control \(OAC\)\. Amazon CloudFront provides the capabilities required to set up a secure static website\. Amazon S3 static websites support only HTTP endpoints\. CloudFront uses the durable storage of Amazon S3 while providing additional security headers, such as HTTPS\. HTTPS adds security by encrypting a normal HTTP request and protecting against common cyberattacks\. For more information, see [Getting started with a secure static website](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/getting-started-secure-static-website-cloudformation-template.html) in the *Amazon CloudFront Developer Guide*\. ## Sharing resources -There are several different ways that you can share resources with a specific group of users\. You can use the following tools to share a set of documents or other resources to a single group of users, department, or an office\. Although they can all be used to accomplish the same goal, some tools might pair better than others with your existing settings\. +There are several different ways that you can share resources with a specific group of users\. You can use the following tools to share a set of documents or other resources to a single group of users, a department, or an office\. Although these tools can all be used to accomplish the same goal, some tools might pair better than others with your existing settings\. **S3 Object Ownership** -S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable ACLs and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. + S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use both to control ownership of objects that are 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\. With ACLs disabled, the bucket owner owns every object in the bucket and manages access to data exclusively by using 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 unusual circumstances where you must control access for each object individually\. + + For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **User policies** -You can share resources with a limited group of people using IAM groups and user policies\. When creating a new IAM user, you are prompted to create and add them to a group\. However, you can create and add users to groups at any point\. If the individuals you intend to share these resources with are already set up within IAM, you can add them to a common group and share the bucket with their group within the user policy\. You can also use IAM user policies to share individual objects within a bucket\. +You can share resources with a limited group of people by using IAM groups and user policies\. When creating a new IAM user, you are prompted to create and add them to a group\. However, you can create and add users to groups at any point\. If the individuals that you intend to share these resources with are already set up within IAM, you can add them to a common group\. You can then use an IAM user policy to share the bucket with that group\. You can also use IAM user policies to share individual objects within a bucket\. For more information, see [Allowing an IAM user access to one of your buckets](example-policies-s3.md#iam-policy-ex0)\. **Access control lists** -As a general rule, we recommend that you use S3 bucket policies or IAM policies for access control\. Amazon S3 ACLs are the original access control mechanism in Amazon S3 that predates IAM\. If you already use S3 ACLs and you find them sufficient, there is no need to change\. However, certain access control scenarios require the use of ACLs\. For example, when a bucket owner wants to grant permission to objects, but not all objects are owned by the bucket owner, the object owner must first grant permission to the bucket owner\. This is done using an object ACL\. +As a general rule, we recommend that you use S3 bucket policies or IAM user policies for access control\. Amazon S3 ACLs are the original access\-control mechanism in Amazon S3 that predates IAM\. If you already use S3 ACLs and you find them sufficient, there is no need to change\. However, certain access\-control scenarios require the use of ACLs\. For example, suppose that a bucket owner wants to grant permission to objects, but not all objects are owned by the bucket owner\. In this case, the object owner must first grant permission to the bucket owner by using an object ACL\. -A majority of modern use cases in Amazon S3 no longer require the use of ACLs, and we recommend that you disable ACLs except in unusual circumstances where you must control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies\. +A majority of modern use cases in Amazon S3 no longer require the use of ACLs\. We recommend that you disable ACLs, except in unusual circumstances where you must control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects that are uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them by using policies\. **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. For more information about using ACLs, see [Example 3: Bucket owner granting permissions to objects it does not own](example-walkthroughs-managing-access-example3.md)\. **Prefixes** -When trying to share specific resources from a bucket, you can replicate folder\-level permissions by using prefixes\. The Amazon S3 console supports the folder concept as a means of grouping objects by using a shared name prefix for objects\. To then grant an IAM user explicit permission to access the resources associated with that prefix, you can specify that prefix within the conditions of their IAM user policy\.  +When trying to share specific resources from a bucket, you can replicate folder\-level permissions by using prefixes\. The Amazon S3 console supports the folder concept as a means of grouping objects by using a shared name prefix for objects\. To then grant an IAM user explicit permission to access the resources associated with that prefix, you can specify that prefix within the conditions of their IAM user policy\. For more information, see [Organizing objects in the Amazon S3 console using folders](using-folders.md)\. **Tagging** -If you use object tagging to categorize storage, you can share objects that have been tagged with a specific value with specified users\. Resource tagging allows you to control access to objects based on the tags associated with the resource that a user is trying to access\. To do this, use the `ResourceTag/key-name` condition within an IAM user policy to allow access to the tagged resources\. +If you use object tagging to categorize storage, you can share objects that have been tagged with a specific value with specified users\. Resource tagging allows you to control access to objects based on the tags associated with the resource that a user is trying to access\. To allow access to the tagged resources, use the `ResourceTag/key-name` condition within an IAM user policy\. -For more information, see [Controlling access to AWS resources using resource tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) in the *IAM User Guide*\. +For more information, see [Controlling access to AWS resources by using resource tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) in the *IAM User Guide*\. ## Protecting data @@ -144,6 +148,6 @@ Monitoring is an important part of maintaining the reliability, availability, an For more information, see [Logging and monitoring in Amazon S3](s3-incident-response.md)\. -Amazon S3 is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, a role, or an AWS service in Amazon S3\. This feature can be paired with Amazon GuardDuty, which monitors threats against your Amazon S3 resources by analyzing CloudTrail management events and CloudTrail S3 data events\. These data sources monitor different kinds of activity\. For example, S3 related CloudTrail management events include operations that list or configure S3 projects\. GuardDuty analyzes S3 data events from all of your S3 buckets and monitors them for malicious and suspicious activity\. +Amazon S3 is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, a role, or an AWS service in Amazon S3\. This feature can be paired with Amazon GuardDuty, which monitors threats against your Amazon S3 resources by analyzing CloudTrail management events and CloudTrail S3 data events\. These data sources monitor different kinds of activity\. For example, Amazon S3 related CloudTrail management events include operations that list or configure S3 projects\. GuardDuty analyzes S3 data events from all of your S3 buckets and monitors them for malicious and suspicious activity\. For more information, see [Amazon S3 protection in Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/s3_detection.html) in the *Amazon GuardDuty User Guide*\. \ No newline at end of file diff --git a/doc_source/access-control-block-public-access.md b/doc_source/access-control-block-public-access.md index f414bb0..468d98d 100644 --- a/doc_source/access-control-block-public-access.md +++ b/doc_source/access-control-block-public-access.md @@ -6,9 +6,6 @@ With S3 Block Public Access, account administrators and bucket owners can easily For instructions on configuring public block access, see [Configuring block public access](#configuring-block-public-access)\. -**Important** -Starting in April 2023, Amazon S3 will change the default settings for S3 Block Public Access and Object Ownership \(ACLs disabled\) for all new S3 buckets\. For new buckets created after this update, all S3 Block Public Access settings will be enabled, and S3 access control lists \(ACLs\) will be disabled\. These defaults are the recommended best practices for securing data in Amazon S3\. You can adjust these settings after creating your bucket\. For more information, see [ Default settings for new S3 buckets FAQ](create-bucket-faq.md) and [Heads\-Up: Amazon S3 Security Changes Are Coming in April of 2023](http://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/) in the * AWS News Blog*\. - When Amazon S3 receives a request to access a bucket or an object, it determines whether the bucket or the bucket owner's account has a block public access setting applied\. If the request was made through an access point, Amazon S3 also checks for block public access settings for the access point\. If there is an existing block public access setting that prohibits the requested access, Amazon S3 rejects the request\. Amazon S3 Block Public Access provides four settings\. These settings are independent and can be used in any combination\. Each setting can be applied to an access point, a bucket, or an entire AWS account\. If the block public access settings for the access point, bucket, or account differ, then Amazon S3 applies the most restrictive combination of the access point, bucket, and account settings\. @@ -27,7 +24,7 @@ When you apply block public access settings to an account, the settings apply to + [Block public access settings](#access-control-block-public-access-options) + [Performing block public access operations on an access point](#access-control-block-public-access-examples-access-point) + [The meaning of "public"](#access-control-block-public-access-policy-status) -+ [Using Access Analyzer for S3 to review public buckets](#access-analyzer-public-info) ++ [Using IAM Access Analyzer for S3 to review public buckets](#access-analyzer-public-info) + [Permissions](#access-control-block-public-access-permissions) + [Configuring block public access](#configuring-block-public-access) + [Configuring block public access settings for your account](configuring-block-public-access-account.md) @@ -149,15 +146,15 @@ Amazon S3 evaluates block public access settings slightly differently for access + An access point that has a VPC network origin is always considered non\-public, regardless of the contents of its access point policy\. + An access point policy that grants access to a set of access points using `s3:DataAccessPointArn` is considered public\. Note that this behavior is different than for bucket policies\. For example, a bucket policy that grants access to values of `s3:DataAccessPointArn` that match `arn:aws:s3:us-west-2:123456789012:accesspoint/*` is not considered public\. However, the same statement in an access point policy would render the access point public\. -## Using Access Analyzer for S3 to review public buckets +## Using IAM Access Analyzer for S3 to review public buckets -You can use Access Analyzer for S3 to review buckets with bucket ACLs, bucket policies, or access point policies that grant public access\. Access Analyzer for S3 alerts you to buckets that are configured to allow access to anyone on the internet or other AWS accounts, including AWS accounts outside of your organization\. For each public or shared bucket, you receive findings that report the source and level of public or shared access\. +You can use IAM Access Analyzer for S3 to review buckets with bucket ACLs, bucket policies, or access point policies that grant public access\. IAM Access Analyzer for S3 alerts you to buckets that are configured to allow access to anyone on the internet or other AWS accounts, including AWS accounts outside of your organization\. For each public or shared bucket, you receive findings that report the source and level of public or shared access\. -In Access Analyzer for S3, you can block all public access to a bucket with a single click\. You can also drill down into bucket\-level permission settings to configure granular levels of access\. For specific and verified use cases that require public or shared access, you can acknowledge and record your intent for the bucket to remain public or shared by archiving the findings for the bucket\. +In IAM Access Analyzer for S3, you can block all public access to a bucket with a single click\. You can also drill down into bucket\-level permission settings to configure granular levels of access\. For specific and verified use cases that require public or shared access, you can acknowledge and record your intent for the bucket to remain public or shared by archiving the findings for the bucket\. -In rare events, Access Analyzer for S3 might report no findings for a bucket that an Amazon S3 block public access evaluation reports as public\. This happens because Amazon S3 block public access reviews policies for current actions and any potential actions that might be added in the future, leading to a bucket becoming public\. On the other hand, Access Analyzer for S3 only analyzes the current actions specified for the Amazon S3 service in the evaluation of access status\. +In rare events, IAM Access Analyzer for S3 might report no findings for a bucket that an Amazon S3 block public access evaluation reports as public\. This happens because Amazon S3 block public access reviews policies for current actions and any potential actions that might be added in the future, leading to a bucket becoming public\. On the other hand, IAM Access Analyzer for S3 only analyzes the current actions specified for the Amazon S3 service in the evaluation of access status\. -For more information about Access Analyzer for S3, see [Reviewing bucket access using Access Analyzer for S3](access-analyzer.md)\. +For more information about IAM Access Analyzer for S3, see [Reviewing bucket access using IAM Access Analyzer for S3](access-analyzer.md)\. ## Permissions diff --git a/doc_source/access-control-overview.md b/doc_source/access-control-overview.md index dce6e2f..2a18f36 100644 --- a/doc_source/access-control-overview.md +++ b/doc_source/access-control-overview.md @@ -146,17 +146,17 @@ Access policy describes who has access to what\. You can associate an access pol When Amazon S3 receives a request, it must evaluate all the access policies to determine whether to authorize or deny the request\. For more information about how Amazon S3 evaluates these policies, see [How Amazon S3 authorizes a request](how-s3-evaluates-access-control.md)\. -### Access Analyzer for S3 +### IAM Access Analyzer for S3 -On the Amazon S3 console, you can use Access Analyzer for S3 to review all buckets that have bucket access control lists \(ACLs\), bucket policies, or access point policies that grant public or shared access\. Access Analyzer for S3 alerts you to buckets that are configured to allow access to anyone on the internet or other AWS accounts, including AWS accounts outside of your organization\. For each public or shared bucket, you receive findings that report the source and level of public or shared access\. +On the Amazon S3 console, you can use IAM Access Analyzer for S3 to review all buckets that have bucket access control lists \(ACLs\), bucket policies, or access point policies that grant public or shared access\. IAM Access Analyzer for S3 alerts you to buckets that are configured to allow access to anyone on the internet or other AWS accounts, including AWS accounts outside of your organization\. For each public or shared bucket, you receive findings that report the source and level of public or shared access\. -In Access Analyzer for S3, you can block all public access to a bucket with a single click\. We recommend that you block all access to your buckets unless you require public access to support a specific use case\. Before you block all public access, ensure that your applications will continue to work correctly without public access\. For more information, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. +In IAM Access Analyzer for S3, you can block all public access to a bucket with a single click\. We recommend that you block all access to your buckets unless you require public access to support a specific use case\. Before you block all public access, ensure that your applications will continue to work correctly without public access\. For more information, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. You can also drill down into bucket\-level permission settings to configure granular levels of access\. For specific and verified use cases that require public or shared access, you can acknowledge and record your intent for the bucket to remain public or shared by archiving the findings for the bucket\. You can revisit and modify these bucket configurations at any time\. You can also download your findings as a CSV report for auditing purposes\. -Access Analyzer for S3 is available at no extra cost on the Amazon S3 console\. Access Analyzer for S3 is powered by AWS Identity and Access Management \(IAM\) Access Analyzer\. To use Access Analyzer for S3 on the Amazon S3 console, you must visit the IAM console and create an account\-level analyzer in IAM Access Analyzer on a per\-Region basis\. +IAM Access Analyzer for S3 is available at no extra cost on the Amazon S3 console\. IAM Access Analyzer for S3 is powered by AWS Identity and Access Management \(IAM\) IAM Access Analyzer\. To use IAM Access Analyzer for S3 on the Amazon S3 console, you must visit the IAM console and create an account\-level analyzer in IAM IAM Access Analyzer on a per\-Region basis\. -For more information about Access Analyzer for S3, see [Reviewing bucket access using Access Analyzer for S3](access-analyzer.md)\. +For more information about IAM Access Analyzer for S3, see [Reviewing bucket access using IAM Access Analyzer for S3](access-analyzer.md)\. ## Which access control method should I use? diff --git a/doc_source/access-policy-alternatives-guidelines.md b/doc_source/access-policy-alternatives-guidelines.md index 2164d2d..4d48d14 100644 --- a/doc_source/access-policy-alternatives-guidelines.md +++ b/doc_source/access-policy-alternatives-guidelines.md @@ -12,12 +12,12 @@ Amazon S3 supports resource\-based policies and user policies to manage access t Both buckets and objects have associated ACLs that you can use to grant permissions\. -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. +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, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. + 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 unusual 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, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. ### When to use an object ACL diff --git a/doc_source/acl-overview.md b/doc_source/acl-overview.md index 1e82485..ad62975 100644 --- a/doc_source/acl-overview.md +++ b/doc_source/acl-overview.md @@ -2,12 +2,12 @@ Amazon S3 access control lists \(ACLs\) enable you to manage access to buckets and objects\. Each bucket 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 received against a resource, Amazon S3 checks the corresponding ACL to verify that the requester has the necessary access permissions\. -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. +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, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. + 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 unusual 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, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. When you create a bucket or an object, Amazon S3 creates a default ACL that grants the resource owner full control over the resource\. This is shown in the following sample bucket ACL \(the default object ACL has the same structure\): diff --git a/doc_source/acls.md b/doc_source/acls.md index ed13d2c..1824198 100644 --- a/doc_source/acls.md +++ b/doc_source/acls.md @@ -4,12 +4,12 @@ For example, you can grant permissions only to other AWS accounts; you cannot grant permissions to users in your account\. You cannot grant conditional permissions, nor can you explicitly deny permissions\. ACLs are suitable for specific scenarios\. For example, if a bucket owner allows other AWS accounts to upload objects, permissions to these objects can only be managed using object ACL by the AWS account that owns the object\. -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. +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, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. + 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 unusual 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, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. For more information about ACLs, see the following topics\. diff --git a/doc_source/bucket-policies.md b/doc_source/bucket-policies.md index 648cebc..6a1d537 100644 --- a/doc_source/bucket-policies.md +++ b/doc_source/bucket-policies.md @@ -2,7 +2,7 @@ A bucket policy is a resource\-based policy that you can use to grant access permissions to your Amazon S3 bucket and the objects in it\. Only the bucket owner can associate a policy with a bucket\. The permissions attached to the bucket apply to all of the objects in the bucket that are owned by the bucket owner\. These permissions do not apply to objects that are owned by other AWS accounts\. -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through access control lists \(ACLs\)\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. +By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through access control lists \(ACLs\)\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM user policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. Bucket policies use JSON\-based IAM policy language\. You can use bucket policies to add or deny permissions for the objects in a bucket\. Bucket policies can allow or deny requests based on the elements in the policy\. These elements include the requester, S3 actions, resources, and aspects or conditions of the request \(such as the IP address that's used to make the request\)\. diff --git a/doc_source/checking-object-integrity.md b/doc_source/checking-object-integrity.md index 59cc655..e745157 100644 --- a/doc_source/checking-object-integrity.md +++ b/doc_source/checking-object-integrity.md @@ -28,7 +28,7 @@ After uploading objects, you can get the checksum value and compare it to a prec ### Using the S3 console -To learn more about using the console and specifying checksum algorithms to use when uploading objects, see [Uploading objects](upload-objects.md)\. +To learn more about using the console and specifying checksum algorithms to use when uploading objects, see [Uploading objects](upload-objects.md) and [Tutorial: Checking the integrity of data in Amazon S3 with additional checksums](http://aws.amazon.com/getting-started/hands-on/amazon-s3-with-additional-checksums/?ref=docs_gateway/amazons3/checking-object-integrity.html)\. ### Using the AWS SDKs diff --git a/doc_source/cloudtrail-logging-understanding-s3-entries.md b/doc_source/cloudtrail-logging-understanding-s3-entries.md index 527ccf3..94b2b7c 100644 --- a/doc_source/cloudtrail-logging-understanding-s3-entries.md +++ b/doc_source/cloudtrail-logging-understanding-s3-entries.md @@ -84,7 +84,7 @@ The following example shows a CloudTrail log entry that demonstrates the [GET Se "Owner": { "ID": "d25639fbe9c19cd30a4c0f43fbf00e2d3f96400a9aa8dabfbbebe1906Example" } - } + }, "host": [ "s3.us-west-2.amazonaws.com" ], @@ -132,7 +132,7 @@ The following example shows a CloudTrail log entry that demonstrates the [GET Se "additionalEventData": { "SignatureVersion": "SigV4", "CipherSuite": "ECDHE-RSA-AES128-SHA", - "AuthenticationMethod": "AuthHeader", + "AuthenticationMethod": "AuthHeader" }, "requestID": "07D681279BD94AED", "eventID": "f2b287f3-0df1-4961-a2f4-c4bdfed47657", diff --git a/doc_source/create-bucket-overview.md b/doc_source/create-bucket-overview.md index 1b63929..adf89ee 100644 --- a/doc_source/create-bucket-overview.md +++ b/doc_source/create-bucket-overview.md @@ -4,12 +4,11 @@ To upload your data to Amazon S3, you must first create an Amazon S3 bucket in o The AWS account that creates the bucket owns it\. You can upload any number of objects to the bucket\. By default, you can create up to 100 buckets in each of your AWS accounts\. If you need more buckets, you can increase your account bucket limit to a maximum of 1,000 buckets by submitting a service limit increase\. To learn how to submit a bucket limit increase, see [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) in the *AWS General Reference*\. You can store any number of objects in a bucket\. -S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable access control lists \(ACLs\) and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. By default, when another AWS account uploads an object to your Amazon S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. When you create a bucket, you can apply the bucket owner enforced setting for Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. + S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use both to control ownership of objects that are 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\. With ACLs disabled, the bucket owner owns every object in the bucket and manages access to data exclusively by using policies\. -Server\-side encryption with Amazon S3 managed keys \(SSE\-S3\) is the base level of encryption configuration for every bucket in Amazon S3\. All new objects uploaded to an S3 bucket are automatically encrypted with SSE\-S3 as the base level of encryption setting\. If you want to use a different type of default encryption, you can also specify server\-side encryption with AWS Key Management Service \(AWS KMS\) keys \(SSE\-KMS\) or customer\-provided keys \(SSE\-C\) to encrypt your data\. For more information, see [Setting default server\-side encryption behavior for Amazon S3 buckets](bucket-encryption.md)\. + For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. -**Important** -Starting in April 2023, Amazon S3 will change the default settings for S3 Block Public Access and Object Ownership \(ACLs disabled\) for all new S3 buckets\. For new buckets created after this update, all S3 Block Public Access settings will be enabled, and S3 access control lists \(ACLs\) will be disabled\. These defaults are the recommended best practices for securing data in Amazon S3\. You can adjust these settings after creating your bucket\. For more information, see [ Default settings for new S3 buckets FAQ](create-bucket-faq.md) and [Heads\-Up: Amazon S3 Security Changes Are Coming in April of 2023](http://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/) in the * AWS News Blog*\. +Server\-side encryption with Amazon S3 managed keys \(SSE\-S3\) is the base level of encryption configuration for every bucket in Amazon S3\. All new objects uploaded to an S3 bucket are automatically encrypted with SSE\-S3 as the base level of encryption setting\. If you want to use a different type of default encryption, you can also specify server\-side encryption with AWS Key Management Service \(AWS KMS\) keys \(SSE\-KMS\) or customer\-provided keys \(SSE\-C\) to encrypt your data\. For more information, see [Setting default server\-side encryption behavior for Amazon S3 buckets](bucket-encryption.md)\. You can use the Amazon S3 console, Amazon S3 APIs, AWS CLI, or AWS SDKs to create a bucket\. For more information about the permissions required to create a bucket, see [CreateBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateBucket.html) in the *Amazon Simple Storage Service API Reference*\. @@ -26,7 +25,7 @@ You can use the Amazon S3 console, Amazon S3 APIs, AWS CLI, or AWS SDKs to creat 1. For **Bucket name**, enter a name for your bucket\. The bucket name must: - + Be unique within a partition\. A partition is a grouping of Regions\. AWS currently has three partitions: `aws` \(Standard Regions\), `aws-cn` \(China Regions\), and `aws-us-gov` \(AWS GovCloud \[US\] Regions\)\. + + Be unique within a partition\. A partition is a grouping of Regions\. AWS currently has three partitions: `aws` \(Standard Regions\), `aws-cn` \(China Regions\), and `aws-us-gov` \(AWS GovCloud \(US\) Regions\)\. + Be between 3 and 63 characters long\. + Consist only of lowercase letters, numbers, dots \(\.\), and hyphens \(\-\)\. For best compatibility, we recommend that you avoid using dots \(\.\) in bucket names, except for buckets that are used only for static website hosting\. + Begin and end with a letter or number\. @@ -42,21 +41,23 @@ Avoid including sensitive information, such as account numbers, in the bucket na 1. Under **Object Ownership**, to disable or enable ACLs and control ownership of objects uploaded in your bucket, choose one of the following settings: **ACLs disabled** - + **Bucket owner enforced** – ACLs are disabled, and the bucket owner automatically owns and has full control over every object in the bucket\. ACLs no longer affect access permissions to data in the S3 bucket\. The bucket uses policies to define access control\. + + **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 access permissions to data in the S3 bucket\. The bucket uses policies exclusively to define access control\. - To require that all new buckets are created with ACLs disabled by using AWS Identity and Access Management \(IAM\) or AWS Organizations policies, see [Disabling ACLs for all new buckets \(bucket owner enforced\)](ensure-object-ownership.md#object-ownership-requiring-bucket-owner-enforced)\. + By default, ACLs are disabled\. 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 unusual circumstances where you must control access for each object individually\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **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\. - If you apply the bucket owner preferred setting, to require all Amazon S3 uploads to include the `bucket-owner-full-control` canned ACL, you can [add a bucket policy](ensure-object-ownership.md#ensure-object-ownership-bucket-policy) that allows only object uploads that use this ACL\. + If you apply the **Bucket owner preferred** setting, to require all Amazon S3 uploads to include the `bucket-owner-full-control` canned ACL, you can [add a bucket policy](ensure-object-ownership.md#ensure-object-ownership-bucket-policy) that allows only object uploads that use this 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\. **Note** -To apply the **Bucket owner enforced** setting or the **Bucket owner preferred** setting, you must have permission to use the following actions: `s3:CreateBucket` and `s3:PutBucketOwnershipControls`\. +The default setting is **Bucket owner enforced**\. To apply the default setting and keep ACLs disabled, only the `s3:CreateBucket` permission is needed\. To enable ACLs, you must have the `s3:PutBucketOwnershipControls` permission\. 1. Under **Block Public Access settings for this bucket**, choose the Block Public Access settings that you want to apply to the bucket\. - We recommend that you keep all settings enabled unless you know that you need to turn off one or more of them for your use case, such as to host a public website\. The Block Public Access settings that you enable for the bucket are also enabled for all access points that you create on the bucket\. For more information about blocking public access, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. + By default, all four Block Public Access settings are enabled\. We recommend that you keep all settings enabled, unless you know that you need to turn off one or more of them for your specific use case\. For more information about blocking public access, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. +**Note** +To enable all Block Public Access settings, only the `s3:CreateBucket` permission is required\. To turn off any Block Public Access settings, you must have the `s3:PutBucketPublicAccessBlock` permission\. 1. \(Optional\) Under **Bucket Versioning**, you can choose if you wish to keep variants of objects in your bucket\. For more information about versioning, see [Using versioning in S3 buckets](Versioning.md)\. diff --git a/doc_source/creating-bucket.md b/doc_source/creating-bucket.md index ed31598..017f443 100644 --- a/doc_source/creating-bucket.md +++ b/doc_source/creating-bucket.md @@ -16,7 +16,7 @@ You are not charged for creating a bucket\. You are charged only for storing obj 1. For **Bucket name**, enter a name for your bucket\. The bucket name must: - + Be unique within a partition\. A partition is a grouping of Regions\. AWS currently has three partitions: `aws` \(Standard Regions\), `aws-cn` \(China Regions\), and `aws-us-gov` \(AWS GovCloud \[US\] Regions\)\. + + Be unique within a partition\. A partition is a grouping of Regions\. AWS currently has three partitions: `aws` \(Standard Regions\), `aws-cn` \(China Regions\), and `aws-us-gov` \(AWS GovCloud \(US\) Regions\)\. + Be between 3 and 63 characters long\. + Consist only of lowercase letters, numbers, dots \(\.\), and hyphens \(\-\)\. For best compatibility, we recommend that you avoid using dots \(\.\) in bucket names, except for buckets that are used only for static website hosting\. + Begin and end with a letter or number\. @@ -32,21 +32,23 @@ Avoid including sensitive information, such as account numbers, in the bucket na 1. Under **Object Ownership**, to disable or enable ACLs and control ownership of objects uploaded in your bucket, choose one of the following settings: **ACLs disabled** - + **Bucket owner enforced** – ACLs are disabled, and the bucket owner automatically owns and has full control over every object in the bucket\. ACLs no longer affect access permissions to data in the S3 bucket\. The bucket uses policies to define access control\. + + **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 access permissions to data in the S3 bucket\. The bucket uses policies exclusively to define access control\. - To require that all new buckets are created with ACLs disabled by using AWS Identity and Access Management \(IAM\) or AWS Organizations policies, see [Disabling ACLs for all new buckets \(bucket owner enforced\)](ensure-object-ownership.md#object-ownership-requiring-bucket-owner-enforced)\. + By default, ACLs are disabled\. 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 unusual circumstances where you must control access for each object individually\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **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\. - If you apply the bucket owner preferred setting, to require all Amazon S3 uploads to include the `bucket-owner-full-control` canned ACL, you can [add a bucket policy](ensure-object-ownership.md#ensure-object-ownership-bucket-policy) that allows only object uploads that use this ACL\. + If you apply the **Bucket owner preferred** setting, to require all Amazon S3 uploads to include the `bucket-owner-full-control` canned ACL, you can [add a bucket policy](ensure-object-ownership.md#ensure-object-ownership-bucket-policy) that allows only object uploads that use this 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\. **Note** -To apply the **Bucket owner enforced** setting or the **Bucket owner preferred** setting, you must have permission to use the following actions: `s3:CreateBucket` and `s3:PutBucketOwnershipControls`\. +The default setting is **Bucket owner enforced**\. To apply the default setting and keep ACLs disabled, only the `s3:CreateBucket` permission is needed\. To enable ACLs, you must have the `s3:PutBucketOwnershipControls` permission\. 1. Under **Block Public Access settings for this bucket**, choose the Block Public Access settings that you want to apply to the bucket\. - We recommend that you keep all settings enabled unless you know that you need to turn off one or more of them for your use case, such as to host a public website\. The Block Public Access settings that you enable for the bucket are also enabled for all access points that you create on the bucket\. For more information about blocking public access, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. + By default, all four Block Public Access settings are enabled\. We recommend that you keep all settings enabled, unless you know that you need to turn off one or more of them for your specific use case\. For more information about blocking public access, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. +**Note** +To enable all Block Public Access settings, only the `s3:CreateBucket` permission is required\. To turn off any Block Public Access settings, you must have the `s3:PutBucketPublicAccessBlock` permission\. 1. \(Optional\) Under **Bucket Versioning**, you can choose if you wish to keep variants of objects in your bucket\. For more information about versioning, see [Using versioning in S3 buckets](Versioning.md)\. diff --git a/doc_source/creating-buckets-s3.md b/doc_source/creating-buckets-s3.md index 1b767ae..a969c53 100644 --- a/doc_source/creating-buckets-s3.md +++ b/doc_source/creating-buckets-s3.md @@ -13,7 +13,6 @@ The topics in this section provide an overview of working with buckets in Amazon + [Buckets overview](UsingBucket.md) + [Bucket naming rules](bucketnamingrules.md) + [Creating a bucket](create-bucket-overview.md) -+ [Default settings for new S3 buckets FAQ](create-bucket-faq.md) + [Viewing the properties for an S3 bucket](view-bucket-properties.md) + [Methods for accessing a bucket](access-bucket-intro.md) + [Emptying a bucket](empty-bucket.md) diff --git a/doc_source/enable-server-access-logging.md b/doc_source/enable-server-access-logging.md index 4106e29..37655ba 100644 --- a/doc_source/enable-server-access-logging.md +++ b/doc_source/enable-server-access-logging.md @@ -2,37 +2,37 @@ Server access logging provides detailed records for the requests that are made to an Amazon S3 bucket\. Server access logs are useful for many applications\. For example, access log information can be useful in security and access audits\. It can also help you learn about your customer base and understand your Amazon S3 bill\. -By default, Amazon S3 doesn't collect server access logs\. When you enable logging, Amazon S3 delivers access logs for a source bucket to a target bucket that you choose\. The target bucket must be in the same AWS Region and AWS account as the source bucket, and must not have a default retention period configuration\. +By default, Amazon S3 doesn't collect server access logs\. When you enable logging, Amazon S3 delivers access logs for a source bucket to a target bucket that you choose\. The target bucket must be in the same AWS Region and AWS account as the source bucket, and must not have a default retention period configuration\. The target bucket must also not have Requester Pays enabled\. An access log record contains details about the requests that are made to a bucket\. This information can include the request type, the resources that are specified in the request, and the time and date that the request was processed\. For more information about logging basics, see [Logging requests using server access logging](ServerLogs.md)\. **Important** There is no extra charge for enabling server access logging on an Amazon S3 bucket\. However, any log files that the system delivers to you will accrue the usual charges for storage\. \(You can delete the log files at any time\.\) We do not assess data transfer charges for log file delivery, but we do charge the normal data transfer rate for accessing the log files\. -Your target bucket should not have server access logging enabled\. You can have logs delivered to any bucket that you own that is in the same Region as the source bucket, including the source bucket itself\. However, this would cause an infinite loop of logs and is not recommended\. For simpler log management, we recommend that you save access logs in a different bucket\. For more information, see [How do I enable log delivery?](ServerLogs.md#server-access-logging-overview) +Your target bucket should not have server access logging enabled\. You can have logs delivered to any bucket that you own that is in the same Region as the source bucket, including the source bucket itself\. However, delivering logs to the source bucket will cause an infinite loop of logs and is not recommended\. For simpler log management, we recommend that you save access logs in a different bucket\. For more information, see [How do I enable log delivery?](ServerLogs.md#server-access-logging-overview) S3 buckets with S3 Object Lock can't be used as destination buckets for server access logs\. You can enable or disable server access logging by using the Amazon S3 console, Amazon S3 API, the AWS Command Line Interface \(AWS CLI\), or AWS SDKs\. Before you enable server access logging, consider the following: -+ You can use either a bucket policy or bucket access control lists \(ACL\) to grant log delivery permissions\. However, we recommend that you use a bucket policy\. If the target bucket uses the bucket owner enforced setting for Object Ownership, ACLs are disabled and no longer affect permissions\. You must use a bucket policy to grant access permissions to the logging service principal\. For more information, see [Permissions for log delivery](#grant-log-delivery-permissions-general)\. -+ Adding *deny* conditions to a bucket policy might prevent Amazon S3 from delivering access logs\. -+ You can use [default bucket encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) on the target bucket *only* if you use **AES256 \(SSE\-S3\)**\. Default encryption with AWS KMS keys \(SSE\-KMS\) is not supported\. ++ You can use either a bucket policy or bucket access control lists \(ACLs\) to grant log delivery permissions\. However, we recommend that you use a bucket policy\. If the target bucket uses the bucket owner enforced setting for Object Ownership, ACLs are disabled and no longer affect permissions\. In that case, you must use a bucket policy to grant access permissions to the logging service principal\. For more information, see [Permissions for log delivery](#grant-log-delivery-permissions-general)\. ++ If there are `Deny` statements in your bucket policy, make sure that they don't prevent Amazon S3 from delivering access logs\. ++ You can use [default bucket encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) on the target bucket *only* if you use server\-side encryption with Amazon S3 managed keys \(SSE\-S3\), which uses the 256\-bit Advanced Encryption Standard \(AES\-256\)\. Default server\-side encryption with AWS Key Management Service \(AWS KMS\) keys \(SSE\-KMS\) is not supported\. + You can't enable S3 Object Lock on the target bucket\. ## Permissions for log delivery Amazon S3 uses a special log delivery account to write server access logs\. These writes are subject to the usual access control restrictions\. We recommend that you update the bucket policy on the target bucket to grant access to the logging service principal \(`logging.s3.amazonaws.com`\) for access log delivery\. -To grant access using the bucket policy on the target bucket, you update the bucket policy to allow `s3:PutObject` access for the logging service principal\. If you use the Amazon S3 console to enable server access logging, the console automatically updates the bucket policy on the target bucket to grant these permissions to the logging service principal\. If you enable server access logging programmatically, you can manually update the bucket policy for the target bucket to grant access to the logging service principal\. +To grant access by using the bucket policy on the target bucket, update the bucket policy to allow `s3:PutObject` access for the logging service principal\. If you use the Amazon S3 console to enable server access logging, the console automatically updates the bucket policy on the target bucket to grant these permissions to the logging service principal\. If you enable server access logging programmatically, you can manually update the bucket policy for the target bucket to grant access to the logging service principal\. -You can alternately use bucket ACLs to grant access for access log delivery\. You add a grant entry to the bucket ACL that grants `WRITE` and `READ_ACP` permissions to the S3 log delivery group\. Granting access to the S3 log delivery group using your bucket ACL is not recommended\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. +You can alternately use bucket ACLs to grant access for access log delivery\. You add a grant entry to the bucket ACL that grants `WRITE` and `READ_ACP` permissions to the S3 log delivery group\. However, granting access to the S3 log delivery group by using bucket ACLs is not recommended\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **Bucket owner enforced setting for S3 Object Ownership** -If the target bucket uses the bucket owner enforced setting for Object Ownership, ACLs are disabled and no longer affect permissions\. You must update the bucket policy for the target bucket to grant access to the logging service principal\. You can't update your bucket ACL to grant access to the S3 log delivery group\. You also can't include target grants in your [https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html) configuration\. For information about migrating existing bucket ACLs for access log delivery to a bucket policy, see [Grant access to S3 log delivery group for server access logging](object-ownership-migrating-acls-prerequisites.md#object-ownership-server-access-logs)\. For more information about Object Ownership see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. +If the target bucket uses the bucket owner enforced setting for Object Ownership, ACLs are disabled and no longer affect permissions\. In this case, you must update the bucket policy for the target bucket to grant access to the logging service principal\. You can't update your bucket ACL to grant access to the S3 log delivery group\. You also can't include target grants in your [https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html) configuration\. For information about migrating existing bucket ACLs for access log delivery to a bucket policy, see [Grant access to S3 log delivery group for server access logging](object-ownership-migrating-acls-prerequisites.md#object-ownership-server-access-logs)\. For more information about Object Ownership, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. -### Grant permissions to the logging service principal using a bucket policy +### Grant permissions to the logging service principal by using a bucket policy -This example bucket policy grants `s3:PutObject` permissions to the logging service principal \(`logging.s3.amazonaws.com`\)\. To use this bucket policy, replace the example values\. +This example bucket policy grants `s3:PutObject` permissions to the logging service principal \(`logging.s3.amazonaws.com`\)\. To use this bucket policy, replace the `user input placeholders` with your own information\. In the following policy, `DOC-EXAMPLE-DESTINATION-BUCKET` is the target bucket where server access logs will be delivered and `DOC-EXAMPLE-SOURCE-BUCKET` is the source bucket\. ``` { @@ -47,10 +47,10 @@ This example bucket policy grants `s3:PutObject` permissions to the logging serv "Action": [ "s3:PutObject" ], - "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/EXAMPLE-LOGGING-PREFIX*", + "Resource": "arn:aws:s3:::DOC-EXAMPLE-DESTINATION-BUCKET/EXAMPLE-LOGGING-PREFIX*", "Condition": { "ArnLike": { - "aws:SourceArn": "arn:aws:s3:::SOURCE-BUCKET-NAME" + "aws:SourceArn": "arn:aws:s3:::DOC-EXAMPLE-SOURCE-BUCKET" }, "StringEquals": { "aws:SourceAccount": "SOURCE-ACCOUNT-ID" @@ -61,9 +61,9 @@ This example bucket policy grants `s3:PutObject` permissions to the logging serv } ``` -### Grant permissions to the log delivery group using the bucket ACL +### Grant permissions to the log delivery group by using a bucket ACL -While we do not recommend this approach, you can grant permissions to the log delivery group using bucket ACL\. However, if the target bucket uses the bucket owner enforced setting for Object Ownership, you can't set bucket or object ACLs\. You also can't include target grants in your [https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html) configuration\. You must use a bucket policy to grant access to the logging service principal \(`logging.s3.amazonaws.com`\)\. For more information, see [Permissions for log delivery](#grant-log-delivery-permissions-general)\. +While we do not recommend this approach, you can grant permissions to the log delivery group by using a bucket ACL\. However, if the target bucket uses the bucket owner enforced setting for Object Ownership, you can't set bucket or object ACLs\. You also can't include target grants in your [https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html) configuration\. Instead, you must use a bucket policy to grant access to the logging service principal \(`logging.s3.amazonaws.com`\)\. For more information, see [Permissions for log delivery](#grant-log-delivery-permissions-general)\. In the bucket ACL, the log delivery group is represented by the following URL\. @@ -91,11 +91,11 @@ To grant `WRITE` and `READ_ACP` \(ACL read\) permissions, add the following gran For examples of adding ACL grants programmatically, see [Configuring ACLs](managing-acls.md)\. **Important** -When you enable Amazon S3 server access logging using AWS CloudFormation on a bucket and use ACLs to grant access to the S3 log delivery group, you must also add "`AccessControl": "LogDeliveryWrite"` in the property field of your bucket\. This is important because you can only grant those permissions by creating an ACL for the bucket, but you can't create custom ACLs for buckets in CloudFormation\. You can only use canned ACLs\. +When you enable Amazon S3 server access logging by using AWS CloudFormation on a bucket and you're using ACLs to grant access to the S3 log delivery group, you must also add "`AccessControl": "LogDeliveryWrite"` to your CloudFormation template\. Doing so is important because you can only grant those permissions by creating an ACL for the bucket, but you can't create custom ACLs for buckets in CloudFormation\. You can only use canned ACLs with CloudFormation\. ## To enable server access logging -Use the following examples to enable server access logging using the AWS Management Console, AWS CLI, REST API, and AWS SDK for \.NET\. +To enable server access logging by using the AWS Management Console, AWS CLI, REST API, and AWS SDK for \.NET, use the following procedures\. ### Using the S3 console @@ -111,13 +111,13 @@ Use the following examples to enable server access logging using the AWS Managem 1. For **Target bucket**, enter the name of the bucket that you want to receive the log record objects\. - The target bucket must be in the same Region as the source bucket and must not have a default retention period configuration\. + The target bucket must be in the same Region as the source bucket, must be owned by the same AWS account as the source bucket, and must not have Object Lock enabled or a default retention period configuration\. The target bucket must also not have Requester Pays enabled\. 1. Choose **Save changes**\. - When you enable server access logging on a bucket, the console both enables logging on the source bucket and updates the bucket policy for the target bucket to grant `s3:PutObject` permissions to the logging service principal \(`logging.s3.amazonaws.com`\)\. For more information about this bucket policy, see [Grant permissions to the logging service principal using a bucket policy](#grant-log-delivery-permissions-bucket-policy)\. + When you enable server access logging on a bucket, the console both enables logging on the source bucket and updates the bucket policy for the target bucket to grant `s3:PutObject` permissions to the logging service principal \(`logging.s3.amazonaws.com`\)\. For more information about this bucket policy, see [Grant permissions to the logging service principal by using a bucket policy](#grant-log-delivery-permissions-bucket-policy)\. - You can view the logs in the target bucket\. After you enable server access logging, it might take a few hours before the logs are delivered to the target bucket\. For more information about how and when logs are delivered, see [How are logs delivered?](ServerLogs.md#how-logs-delivered)\. + You can view the logs in the target bucket\. After you enable server access logging, it might take a few hours before the logs are delivered to the target bucket\. For more information about how and when logs are delivered, see [How are logs delivered?](ServerLogs.md#how-logs-delivered) For more information, see [Viewing the properties for an S3 bucket](view-bucket-properties.md)\. @@ -139,16 +139,16 @@ The following example identifies `LOGBUCKET` as the target bucket and `logs/` as The log objects are written and owned by the S3 log delivery account, and the bucket owner is granted full permissions on the log objects\. You can optionally use target grants to grant permissions to other users so that they can access the logs\. For more information, see [PUT Bucket logging](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTlogging.html)\. **Note** -If the target bucket uses the bucket owner enforced setting for Object Ownership, you can't use target grants to grant permissions to other users\. To grant permissions to others, you can use update the bucket policy on the target bucket\. For more information, see [Permissions for log delivery](#grant-log-delivery-permissions-general)\. +If the target bucket uses the bucket owner enforced setting for Object Ownership, you can't use target grants to grant permissions to other users\. To grant permissions to others, you can update the bucket policy on the target bucket\. For more information, see [Permissions for log delivery](#grant-log-delivery-permissions-general)\. -Amazon S3 also provides the [GET Bucket logging](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGETlogging.html) API to retrieve logging configuration on a bucket\. To delete the logging configuration, you send the `PUT` Bucket logging request with an empty `BucketLoggingStatus`\. +Amazon S3 also provides the [GET Bucket logging](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGETlogging.html) API operation to retrieve the logging configuration on a bucket\. To delete the logging configuration, you send the `PUT` Bucket logging request with an empty `BucketLoggingStatus`\. ``` 1. 2. ``` -You can use either the Amazon S3 API or the AWS SDK wrapper libraries to enable logging on a bucket\. +To enable logging on a bucket, you can use either the Amazon S3 API or the AWS SDK wrapper libraries\. ### Using the AWS SDKs @@ -268,14 +268,14 @@ In this example, you have the following five buckets: + `1-DOC-EXAMPLE-BUCKET1-us-west-2` logs to the S3 bucket `DOC-EXAMPLE-BUCKET1-logs-us-west-2` with prefix `1-DOC-EXAMPLE-BUCKET1-us-west-2` + `2-DOC-EXAMPLE-BUCKET1-us-west-2` logs to the S3 bucket `DOC-EXAMPLE-BUCKET1-logs-us-west-2` with prefix `2-DOC-EXAMPLE-BUCKET1-us-west-2` -1. Grant permissions for server access log delivery using a bucket ACL or a bucket policy: - + **Update the bucket policy** \(Recommended\) – To grant permissions to the logging service principal, use `put-bucket-policy`: +1. Grant permissions for server access log delivery by using a bucket ACL or a bucket policy: + + **Update the bucket policy** \(Recommended\) – To grant permissions to the logging service principal, use the following `put-bucket-policy` command\. Replace `DOC-EXAMPLE-BUCKET1` with the name of your target bucket\. ``` 1. aws s3api put-bucket-policy --bucket DOC-EXAMPLE-BUCKET1-logs --policy file://policy.json ``` - `Policy.json` is a JSON document in the current folder that contains the bucket policy\. To use this bucket policy, replace the example values\. + `Policy.json` is a JSON document in the current folder that contains the bucket policy\. To use this bucket policy, replace the example values\. `user input placeholders` with your own information\. In the following policy, `DOC-EXAMPLE-DESTINATION-BUCKET` is the target bucket where server access logs will be delivered and `DOC-EXAMPLE-SOURCE-BUCKET` is the source bucket\. ``` { @@ -290,10 +290,10 @@ In this example, you have the following five buckets: "Action": [ "s3:PutObject" ], - "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET1-logs/*", + "Resource": "arn:aws:s3:::DOC-EXAMPLE-DESTINATION-BUCKET-logs/*", "Condition": { "ArnLike": { - "aws:SourceArn": "arn:aws:s3:::SOURCE-BUCKET-NAME" + "aws:SourceArn": "arn:aws:s3:::DOC-EXAMPLE-SOURCE-BUCKET" }, "StringEquals": { "aws:SourceAccount": "SOURCE-ACCOUNT-ID" @@ -303,16 +303,16 @@ In this example, you have the following five buckets: ] } ``` - + **Update the bucket ACL** – To grant permissions to the S3 log delivery group, use `put-bucket-acl`\. + + **Update the bucket ACL** – To grant permissions to the S3 log delivery group, use the following `put-bucket-acl` command\. Replace `DOC-EXAMPLE-DESTINATION-BUCKET` with the name of your target bucket\. ``` - 1. aws s3api put-bucket-acl --bucket DOC-EXAMPLE-BUCKET1-logs --grant-write URI=http://acs.amazonaws.com/groups/s3/LogDelivery --grant-read-acp URI=http://acs.amazonaws.com/groups/s3/LogDelivery + 1. aws s3api put-bucket-acl --bucket DOC-EXAMPLE-DESTINATION-BUCKET-logs --grant-write URI=http://acs.amazonaws.com/groups/s3/LogDelivery --grant-read-acp URI=http://acs.amazonaws.com/groups/s3/LogDelivery ``` -1. Then, apply the logging policy\. +1. Then, apply the logging policy by using the following `put-bucket-logging` command\. Replace `DOC-EXAMPLE-DESTINATION-BUCKET` with the name of your target bucket\. ``` - 1. aws s3api put-bucket-logging --bucket DOC-EXAMPLE-BUCKET1 --bucket-logging-status file://logging.json + 1. aws s3api put-bucket-logging --bucket DOC-EXAMPLE-DESTINATION-BUCKET --bucket-logging-status file://logging.json ``` `Logging.json` is a JSON document in the current folder that contains the logging configuration\. If a bucket uses the bucket owner enforced setting for Object Ownership, your logging configuration can't contain target grants\. For more information, see [Permissions for log delivery](#grant-log-delivery-permissions-general)\. @@ -323,8 +323,8 @@ In this example, you have the following five buckets: ``` { "LoggingEnabled": { - "TargetBucket": "DOC-EXAMPLE-BUCKET1-logs", - "TargetPrefix": "DOC-EXAMPLE-BUCKET1/" + "TargetBucket": "DOC-EXAMPLE-DESTINATION-BUCKET-logs", + "TargetPrefix": "DOC-EXAMPLE-DESTINATION-BUCKET/" } } ``` @@ -337,8 +337,8 @@ In this example, you have the following five buckets: ``` { "LoggingEnabled": { - "TargetBucket": "DOC-EXAMPLE-BUCKET1-logs", - "TargetPrefix": "DOC-EXAMPLE-BUCKET1/", + "TargetBucket": "DOC-EXAMPLE-DESTINATION-BUCKET-logs", + "TargetPrefix": "DOC-EXAMPLE-DESTINATION-BUCKET/", "TargetGrants": [ { "Grantee": { @@ -354,11 +354,11 @@ In this example, you have the following five buckets: 1. Use a bash script to add access logging for all the buckets in your account\. **Note** -This script only works if all your buckets are in the same Region\. If you have buckets in multiple Regions, you must adjust the script\. +This script works only if all of your buckets are in the same Region\. If you have buckets in multiple Regions, you must adjust the script\. **Example – Grant access with bucket policies and add logging for the buckets in your account** ``` - loggingBucket='DOC-EXAMPLE-BUCKET1-logs' + loggingBucket='DOC-EXAMPLE-DESTINATION-BUCKET-logs' region='us-west-2' @@ -389,7 +389,7 @@ This script only works if all your buckets are in the same Region\. If you have **Example – Grant access with bucket ACLs and add logging for the buckets in your account** ``` - loggingBucket='DOC-EXAMPLE-BUCKET1-logs' + loggingBucket='DOC-EXAMPLE-DESTINATION-BUCKET-logs' region='us-west-2' @@ -416,4 +416,12 @@ This script only works if all your buckets are in the same Region\. If you have rm logging.json echo "Complete" - ``` \ No newline at end of file + ``` + +## Verifying your server access logs setup + +After you enable server access logging, complete the following steps: ++ Access the target bucket and verify that the log files are being delivered\. After the access logs are set up, it might take longer than an hour for all requests to be properly logged and delivered\. You can also automatically verify log delivery by using Amazon S3 request metrics and setting up Amazon CloudWatch alarms for these metrics\. For more information, see [Monitoring metrics with Amazon CloudWatch](cloudwatch-monitoring.md)\. ++ Verify that you are able to open and read the contents of the log files\. + +For server access logging troubleshooting information, see [Troubleshoot server access logging](troubleshooting-server-access-logging.md)\. \ No newline at end of file diff --git a/doc_source/example-walkthroughs-managing-access-example3.md b/doc_source/example-walkthroughs-managing-access-example3.md index 8cfc723..37cc818 100644 --- a/doc_source/example-walkthroughs-managing-access-example3.md +++ b/doc_source/example-walkthroughs-managing-access-example3.md @@ -17,8 +17,8 @@ A bucket owner can enable other AWS accounts to upload objects\. By default, the If the bucket owner applies the bucket owner enforced setting for S3 Object Ownership for the bucket, the bucket owner will own all objects in the bucket, including objects written by another AWS account\. This will resolve the issue that objects are not owned by the bucket owner\. Then, you can delegate permission to users in your own account or to other AWS accounts\. **Note** -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. -A majority of modern use cases in Amazon S3 no longer require the use of ACLs, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. +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 unusual 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, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. In this example, we assume the bucket owner has not applied the bucket owner enforced setting for Object Ownership\. The bucket owner delegates permission to users in its own account\. The following is a summary of the walkthrough steps: diff --git a/doc_source/example-walkthroughs-managing-access-example4.md b/doc_source/example-walkthroughs-managing-access-example4.md index eb04038..26588f2 100644 --- a/doc_source/example-walkthroughs-managing-access-example4.md +++ b/doc_source/example-walkthroughs-managing-access-example4.md @@ -18,8 +18,8 @@ Now, suppose as a bucket owner, you need to grant cross\-account permission on o In this scenario, the bucket owner can create an AWS Identity and Access Management \(IAM\) role with permission to access objects, and grant another AWS account permission to assume the role temporarily enabling it to access objects in the bucket\. **Note** -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. -A majority of modern use cases in Amazon S3 no longer require the use of ACLs, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. +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 unusual 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, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. ## Background: Cross\-account permissions and using IAM roles diff --git a/doc_source/example_s3_GetObject_section.md b/doc_source/example_s3_GetObject_section.md index 3eff89b..144dd05 100644 --- a/doc_source/example_s3_GetObject_section.md +++ b/doc_source/example_s3_GetObject_section.md @@ -297,6 +297,35 @@ Get an object by using the S3Presigner client object using an [S3Client](https:/ } } ``` +Get an object by using a ResponseTransformer object and [S3Client](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/services/s3/S3Client.html)\. + +``` + public static void getObjectBytes (S3Client s3, String bucketName, String keyName, String path) { + try { + GetObjectRequest objectRequest = GetObjectRequest + .builder() + .key(keyName) + .bucket(bucketName) + .build(); + + ResponseBytes objectBytes = s3.getObject(objectRequest, ResponseTransformer.toBytes()); + byte[] data = objectBytes.asByteArray(); + + // Write the data to a local file. + File myFile = new File(path ); + OutputStream os = new FileOutputStream(myFile); + os.write(data); + System.out.println("Successfully obtained bytes from an S3 object"); + os.close(); + + } catch (IOException ex) { + ex.printStackTrace(); + } catch (S3Exception e) { + System.err.println(e.awsErrorDetails().errorMessage()); + System.exit(1); + } + } +``` + For API details, see [GetObject](https://docs.aws.amazon.com/goto/SdkForJavaV2/s3-2006-03-01/GetObject) in *AWS SDK for Java 2\.x API Reference*\. ------ diff --git a/doc_source/example_s3_Scenario_PresignedUrl_section.md b/doc_source/example_s3_Scenario_PresignedUrl_section.md index 65d7161..71200cd 100644 --- a/doc_source/example_s3_Scenario_PresignedUrl_section.md +++ b/doc_source/example_s3_Scenario_PresignedUrl_section.md @@ -492,7 +492,7 @@ const createPresignedUrlWithoutClient = async ({ region, bucket, key }) => { return formatUrl(signedUrlObject); }; -const createPresignedUrlWithClient = async ({ region, bucket, key }) => { +const createPresignedUrlWithClient = ({ region, bucket, key }) => { const client = new S3Client({ region }); const command = new PutObjectCommand({ Bucket: bucket, Key: key }); return getSignedUrl(client, command, { expiresIn: 3600 }); @@ -523,8 +523,8 @@ function put(url, data) { export const main = async () => { const REGION = "us-east-1"; - const BUCKET = "coreys-default-bucket"; - const KEY = "corey_test.txt"; + const BUCKET = "example_bucket"; + const KEY = "example_file.txt"; // There are two ways to generate a presigned URL. // 1. Use createPresignedUrl without the S3 client. @@ -582,7 +582,7 @@ const createPresignedUrlWithoutClient = async ({ region, bucket, key }) => { return formatUrl(signedUrlObject); }; -const createPresignedUrlWithClient = async ({ region, bucket, key }) => { +const createPresignedUrlWithClient = ({ region, bucket, key }) => { const client = new S3Client({ region }); const command = new GetObjectCommand({ Bucket: bucket, Key: key }); return getSignedUrl(client, command, { expiresIn: 3600 }); @@ -590,8 +590,8 @@ const createPresignedUrlWithClient = async ({ region, bucket, key }) => { export const main = async () => { const REGION = "us-east-1"; - const BUCKET = "coreys-default-bucket"; - const KEY = "corey_mug.jpg"; + const BUCKET = "example_bucket"; + const KEY = "example_file.jpg"; try { const noClientUrl = await createPresignedUrlWithoutClient({ diff --git a/doc_source/getting-started-next-steps.md b/doc_source/getting-started-next-steps.md index 100f280..bf84617 100644 --- a/doc_source/getting-started-next-steps.md +++ b/doc_source/getting-started-next-steps.md @@ -25,12 +25,12 @@ You can use Amazon S3 to support your specific use case\. The [AWS Solutions Lib Amazon S3 provides a variety of security features and tools\. For an overview, see [Access control best practices](access-control-best-practices.md)\. By default, S3 buckets and the objects in them are private\. You have access only to the S3 resources that you create\. You can use the following features to grant granular resource permissions that support your specific use case or to audit the permissions of your Amazon S3 resources\. -+ [S3 Block Public Access](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html) – Block public access to S3 buckets and objects\. By default, Block Public Access settings are turned on at the account and bucket level\. -+ [AWS Identity and Access Management \(IAM\) identities](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) – Use IAM or AWS IAM Identity Center \(successor to AWS Single Sign\-On\) to create IAM identities in your AWS account to manage access to your Amazon S3 resources\. For example, you can use IAM with Amazon S3 to control the type of access a user or group of users has to an Amazon S3 bucket that your AWS account owns\. For more information about IAM identities and best practices, see [IAM identities \(users, user groups, and roles\)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) in the *IAM User Guide*\. ++ [S3 Block Public Access](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html) – Block public access to S3 buckets and objects\. By default, Block Public Access settings are turned on at the bucket level\. ++ [AWS Identity and Access Management \(IAM\) identities](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) – Use IAM or AWS IAM Identity Center \(successor to AWS Single Sign\-On\) to create IAM identities in your AWS account to manage access to your Amazon S3 resources\. For example, you can use IAM with Amazon S3 to control the type of access that a user or group of users has to an Amazon S3 bucket that your AWS account owns\. For more information about IAM identities and best practices, see [IAM identities \(users, user groups, and roles\)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) in the *IAM User Guide*\. + [Bucket policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) – Use IAM\-based policy language to configure resource\-based permissions for your S3 buckets and the objects in them\. -+ [Access control lists \(ACLs\)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acls.html) – Grant read and write permissions for individual buckets and objects to authorized users\. 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\. ACLs are an access control mechanism that predates resource\-based policies and IAM\. For more information about when you'd use ACLs instead of resource\-based policies or IAM policies, see [Access policy guidelines](access-policy-alternatives-guidelines.md)\. -+ [S3 Object Ownership](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) – Disable ACLs and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. You, as the bucket owner, automatically own and have full control over every object in your bucket, and access control for your data is based on policies\. -+ [Access Analyzer for S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-analyzer.html) – Evaluate and monitor your S3 bucket access policies, ensuring that the policies provide only the intended access to your S3 resources\. ++ [Access control lists \(ACLs\)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acls.html) – Grant read and write permissions for individual buckets and objects to authorized users\. As a general rule, we recommend using S3 resource\-based policies \(bucket policies and access point policies\) or IAM user 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\. For more information about the specific cases when you'd use ACLs instead of resource\-based policies or IAM user policies, see [Access policy guidelines](access-policy-alternatives-guidelines.md)\. ++ [S3 Object Ownership](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) – Take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable or enable ACLs\. By default, ACLs are disabled\. With ACLs disabled, the bucket owner owns all the objects in the bucket and manages access to data exclusively by using access\-management policies\. ++ [IAM Access Analyzer for S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-analyzer.html) – Evaluate and monitor your S3 bucket access policies, ensuring that the policies provide only the intended access to your S3 resources\. ## Manage and monitor your storage + [Managing your storage](managing-storage.md) – After you create buckets and upload objects in Amazon S3, you can manage your object storage\. For example, you can use S3 Versioning and S3 Replication for disaster recovery, S3 Lifecycle to manage storage costs, and S3 Object Lock to meet compliance requirements\. diff --git a/doc_source/how-s3-evaluates-access-control.md b/doc_source/how-s3-evaluates-access-control.md index 3c18b29..cc00c6a 100644 --- a/doc_source/how-s3-evaluates-access-control.md +++ b/doc_source/how-s3-evaluates-access-control.md @@ -31,7 +31,7 @@ If the requester is an IAM principal, Amazon S3 must determine if the parent AWS **Example Requester is an IAM principal – If the request is for an operation on an object that the bucket owner doesn't own\.** If the request is for an operation on an object that the bucket owner does not own, in addition to making sure the requester has permissions from the object owner, Amazon S3 must also check the bucket policy to ensure the bucket owner has not set explicit deny on the object\. A bucket owner \(who pays the bill\) can explicitly deny access to objects in the bucket regardless of who owns it\. The bucket owner can also delete any object in the bucket\. -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through access control lists \(ACLs\)\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. +By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through access control lists \(ACLs\)\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM user policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. For more information about how Amazon S3 evaluates access policies to authorize or deny requests for bucket operations and object operations, see the following topics: diff --git a/doc_source/index.md b/doc_source/index.md index 580f383..0314bad 100644 --- a/doc_source/index.md +++ b/doc_source/index.md @@ -37,7 +37,6 @@ sponsored by Amazon. + [Buckets overview](UsingBucket.md) + [Bucket naming rules](bucketnamingrules.md) + [Creating a bucket](create-bucket-overview.md) - + [Default settings for new S3 buckets FAQ](create-bucket-faq.md) + [Viewing the properties for an S3 bucket](view-bucket-properties.md) + [Methods for accessing a bucket](access-bucket-intro.md) + [Emptying a bucket](empty-bucket.md) @@ -190,7 +189,7 @@ sponsored by Amazon. + [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md) + [Configuring block public access settings for your account](configuring-block-public-access-account.md) + [Configuring block public access settings for your S3 buckets](configuring-block-public-access-bucket.md) - + [Reviewing bucket access using Access Analyzer for S3](access-analyzer.md) + + [Reviewing bucket access using IAM Access Analyzer for S3](access-analyzer.md) + [Verifying bucket ownership with bucket owner condition](bucket-owner-condition.md) + [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md) + [Prerequisites for disabling ACLs](object-ownership-migrating-acls-prerequisites.md) diff --git a/doc_source/intro-lifecycle-rules.md b/doc_source/intro-lifecycle-rules.md index e33cc48..9665c1c 100644 --- a/doc_source/intro-lifecycle-rules.md +++ b/doc_source/intro-lifecycle-rules.md @@ -203,14 +203,14 @@ You can direct Amazon S3 to perform specific actions in an object's lifetime by For a versioned bucket \(versioning\-enabled or versioning\-suspended bucket\), the `Transition` action applies to the current object version\. To manage noncurrent versions, Amazon S3 defines the `NoncurrentVersionTransition` action \(described later in this topic\)\. + **Expiration action element** – The `Expiration` action expires objects identified in the rule and applies to eligible objects in any of the Amazon S3 storage classes\. For more information about storage classes, see [Using Amazon S3 storage classes](storage-class-intro.md)\. Amazon S3 makes all expired objects unavailable\. Whether the objects are permanently removed depends on the versioning state of the bucket\. -**Important** -Object expiration lifecycle configurations do not remove incomplete multipart uploads\. To remove incomplete multipart uploads, you must use the **AbortIncompleteMultipartUpload** Lifecycle configuration action that is described later in this section\. + **Non\-versioned bucket** – The `Expiration` action results in Amazon S3 permanently removing the object\. - + **Versioned bucket** – For a versioned bucket \(that is, versioning\-enabled or versioning\-suspended\), there are several considerations that guide how Amazon S3 handles the `Expiration` action\. For more information, see [Using versioning in S3 buckets](Versioning.md)\. Regardless of the versioning state, the following applies: + + **Versioned bucket** – For a versioned bucket \(that is, versioning\-enabled or versioning\-suspended\), there are several considerations that guide how Amazon S3 handles the `Expiration` action\. For versioning\-enabled or versioning\-suspended buckets, the following applies: + The `Expiration` action applies only to the current version \(it has no impact on noncurrent object versions\)\. + Amazon S3 doesn't take any action if there are one or more object versions and the delete marker is the current version\. + If the current object version is the only object version and it is also a delete marker \(also referred as an *expired object delete marker*, where all object versions are deleted and you only have a delete marker remaining\), Amazon S3 removes the expired object delete marker\. You can also use the expiration action to direct Amazon S3 to remove any expired object delete markers\. For an example, see [Example 7: Removing expired object delete markers](lifecycle-configuration-examples.md#lifecycle-config-conceptual-ex7)\. + For more information, see [Using versioning in S3 buckets](Versioning.md)\. + Also consider the following when setting up Amazon S3 to manage expiration: + **Versioning\-enabled bucket** @@ -228,7 +228,7 @@ In addition, Amazon S3 provides the following actions that you can use to manage Delayed removal of noncurrent objects can be helpful when you need to correct any accidental deletes or overwrites\. For example, you can configure an expiration rule to delete noncurrent versions five days after they become noncurrent\. For example, suppose that on 1/1/2014 10:30 AM UTC, you create an object called `photo.gif` \(version ID 111111\)\. On 1/2/2014 11:30 AM UTC, you accidentally delete `photo.gif` \(version ID 111111\), which creates a delete marker with a new version ID \(such as version ID 4857693\)\. You now have five days to recover the original version of `photo.gif` \(version ID 111111\) before the deletion is permanent\. On 1/8/2014 00:00 UTC, the Lifecycle rule for expiration executes and permanently deletes `photo.gif` \(version ID 111111\), five days after it became a noncurrent version\. For details about how Amazon S3 calculates the date when you specify the number of days in an `NoncurrentVersionExpiration` action, see [Lifecycle rules: Based on an object's age](#intro-lifecycle-rules-number-of-days)\. -**Important** +**Note** Object expiration lifecycle configurations do not remove incomplete multipart uploads\. To remove incomplete multipart uploads, you must use the **AbortIncompleteMultipartUpload** Lifecycle configuration action that is described later in this section\. In addition to the transition and expiration actions, you can use the following Lifecycle configuration action to direct Amazon S3 to stop incomplete multipart uploads\. diff --git a/doc_source/lifecycle-expire-general-considerations.md b/doc_source/lifecycle-expire-general-considerations.md index b629f72..07f7da0 100644 --- a/doc_source/lifecycle-expire-general-considerations.md +++ b/doc_source/lifecycle-expire-general-considerations.md @@ -1,9 +1,26 @@ # Expiring objects -When an object reaches the end of its lifetime based on its lifecycle configuration, Amazon S3 queues it for removal and removes it asynchronously\. There might be a delay between the expiration date and the date at which Amazon S3 removes an object\. You are not charged for expiration or the storage time associated with an object that has expired\. +When an object reaches the end of its lifetime based on its lifecycle configuration, Amazon S3 takes an action based on which state the bucket is in\. ++ **Non\-versioned bucket** – Amazon S3 queues the object for removal and removes it asynchronously, permanently removing the object\. ++ **Versioning\-enabled bucket** – If the current object version is not a delete marker, Amazon S3 adds a delete marker with a unique version ID\. This makes the current version noncurrent, and the delete marker the current version\. ++ **Versioning\-suspended bucket** – Amazon S3 creates a delete marker with null as the version ID\. This delete marker replaces any object version with a null version ID in the version hierarchy, which effectively deletes the object\. -When dealing with buckets that have versioning enabled, realize that you will need to create a transition for noncurrent versions as well to avoid being charged for objects that have noncurrent versions\. For more information about noncurrent version transitions, see [Lifecycle configuration elements](intro-lifecycle-rules.md)\. +For a versioned bucket \(that is, versioning\-enabled or versioning\-suspended\), there are several considerations that guide how Amazon S3 handles the Expiration action\. For versioning\-enabled or versioning\-suspended buckets, the following applies: ++ Object expiration applies only to an object's current version \(it has no impact on noncurrent object versions\)\. ++ Amazon S3 doesn't take any action if there are one or more object versions and the delete marker is the current version\. ++ If the current object version is the only object version and it is also a delete marker \(also referred as an *expired object delete marker*, where all object versions are deleted and you only have a delete marker remaining\), Amazon S3 removes the expired object delete marker\. You can also use the expiration action to direct Amazon S3 to remove any expired object delete markers\. For example, see [Example 7: Removing expired object delete markers](lifecycle-configuration-examples.md#lifecycle-config-conceptual-ex7)\. - To find when an object is scheduled to expire, use the [HEAD Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectHEAD.html) or the [GET Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html) API operations\. These API operations return response headers that provide this information\. +For more information, see [Using versioning in S3 buckets](Versioning.md)\. -If you create an S3 Lifecycle expiration rule that causes objects that have been in S3 Standard\-IA or S3 One Zone\-IA storage for less than 30 days to expire, you are charged for 30 days\. If you create a Lifecycle expiration rule that causes objects that have been in S3 Glacier Flexible Retrieval storage for less than 90 days to expire, you are charged for 90 days\. If you create a Lifecycle expiration rule that causes objects that have been in S3 Glacier Deep Archive storage for less than 180 days to expire, you are charged for 180 days\. For more information, see [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/)and [Using the S3 console](how-to-set-lifecycle-configuration-intro.md#create-lifecycle)\. \ No newline at end of file +## How to find when objects will expire + +To find when an object is scheduled to expire, use the [HEAD Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectHEAD.html) or [GET Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html) API operation\. These API operations return response headers that provide the date and time at which the object is no longer cacheable\. + +**Note** +There may be a delay between the expiration date and the date at which Amazon S3 removes an object\. You are not charged for expiration or the storage time associated with an object that has expired\. + +## Minimum storage duration charge + +If you create an S3 Lifecycle expiration rule that causes objects that have been in S3 Standard\-IA or S3 One Zone\-IA storage for less than 30 days to expire, you are charged for 30 days\. If you create a Lifecycle expiration rule that causes objects that have been in S3 Glacier Flexible Retrieval storage for less than 90 days to expire, you are charged for 90 days\. If you create a Lifecycle expiration rule that causes objects that have been in S3 Glacier Deep Archive storage for less than 180 days to expire, you are charged for 180 days\. + +For more information, see [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/)\. \ No newline at end of file diff --git a/doc_source/managing-acls.md b/doc_source/managing-acls.md index 8446693..5233a2f 100644 --- a/doc_source/managing-acls.md +++ b/doc_source/managing-acls.md @@ -8,12 +8,12 @@ You can grant permissions to other AWS account users or to predefined groups\. T Each permission you grant for a user or group adds an entry in the ACL that is associated with the bucket\. The ACL lists grants, which identify the grantee and the permission granted\. -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. +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, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. + 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 unusual 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, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. **Warning** We highly recommend that you avoid granting write access to the **Everyone \(public access\)** or **Authenticated Users group \(all AWS authenticated users\)** groups\. For more information about the effects of granting write access to these groups, see [Amazon S3 predefined groups](acl-overview.md#specifying-grantee-predefined-groups)\. @@ -39,7 +39,7 @@ The following table shows the ACL permissions that you can configure for buckets For more information about ACL permissions, see [Access control list \(ACL\) overview](acl-overview.md)\. **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. **To set ACL permissions for a bucket** @@ -117,7 +117,7 @@ The console displays combined access grants for duplicate grantees\. To see the For more information about ACL permissions, see [Access control list \(ACL\) overview](acl-overview.md)\. **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. **To set ACL permissions for an object** @@ -176,7 +176,7 @@ We highly recommend that you *do not* grant the **Everyone** group write object This section provides examples of how to configure access control list \(ACL\) grants on buckets and objects\. **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. ------ #### [ Java ] @@ -477,7 +477,7 @@ For information on the REST API support for managing ACLs, see the following sec + [Initiate Multipart Upload](https://docs.aws.amazon.com/AmazonS3/latest/API/mpUploadInitiate.html) **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. ### Access Control List \(ACL\)\-Specific Request Headers @@ -497,4 +497,4 @@ With this operation, you can grant access permissions using one these two method For more information about managing ACLs using the AWS CLI, see [put\-bucket\-acl](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-acl.html) in the *AWS CLI Command Reference*\. **Important** -If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. Requests to set ACLs or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. \ No newline at end of file +If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it\. With the bucket owner enforced setting enabled, requests to set access control lists \(ACLs\) or update ACLs fail and return the `AccessControlListNotSupported` error code\. Requests to read ACLs are still supported\. \ No newline at end of file diff --git a/doc_source/object-ownership-error-responses.md b/doc_source/object-ownership-error-responses.md index 8575bfd..2bf7ee0 100644 --- a/doc_source/object-ownership-error-responses.md +++ b/doc_source/object-ownership-error-responses.md @@ -1,6 +1,6 @@ # Troubleshooting -When you apply the bucket owner enforced setting for S3 Object Ownership, access control lists \(ACLs\) are disabled and you, as the bucket owner, automatically own all objects in your bucket\. ACLs no longer affect permissions for the objects in your bucket\. You can use policies to grant permissions\. All S3 PUT requests must specify bucket owner full control ACLs or not specify an ACL, or they fail\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. +When you apply the bucket owner enforced setting for S3 Object Ownership, access control lists \(ACLs\) are disabled and you, as the bucket owner, automatically own all objects in your bucket\. ACLs no longer affect permissions for the objects in your bucket\. You can use policies to grant permissions\. All S3 `PUT` requests must either specify the `bucket-owner-full-control` canned ACL or not specify an ACL, or these requests will fail\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. If an invalid ACL is specified or bucket ACL permissions grant access outside of your AWS account, you might see the following error responses\. diff --git a/doc_source/object-ownership-existing-bucket.md b/doc_source/object-ownership-existing-bucket.md index 7874f15..3cc4f1e 100644 --- a/doc_source/object-ownership-existing-bucket.md +++ b/doc_source/object-ownership-existing-bucket.md @@ -2,16 +2,16 @@ You can configure S3 Object Ownership on an existing S3 bucket\. To apply Object Ownership when you create a bucket, see [Setting Object Ownership when you create a bucket](object-ownership-new-bucket.md)\. -S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable [access control lists \(ACLs\)](acl-overview.md) and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. We recommend that you disable ACLs unless you to need to control access at the individual object level\. +S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable [access control lists \(ACLs\)](acl-overview.md) and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. By default, S3 Object Ownership is set to the bucket owner enforced setting, and ACLs are disabled for new buckets\. With ACLs disabled, the bucket owner owns every object in the bucket and manages access to data exclusively by using access\-management policies\. We recommend that you keep ACLs disabled, except in unusual circumstances where you must control access for each object individually\. 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 \(recommended\)** – 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\. ++ **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 \(default\)** – 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\. ++ **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\. **Prerequisites**: Before you apply the bucket owner enforced setting to disable ACLs, you must migrate bucket ACL permissions to bucket policies and reset your bucket ACLs to the default private ACL\. We also recommend that you migrate object ACL permissions to bucket policies and edit bucket policies that require ACLs other than bucket owner full control ACLs\. For more information, see [Prerequisites for disabling ACLs](object-ownership-migrating-acls-prerequisites.md)\. diff --git a/doc_source/object-ownership-new-bucket.md b/doc_source/object-ownership-new-bucket.md index 546f30f..19b53d3 100644 --- a/doc_source/object-ownership-new-bucket.md +++ b/doc_source/object-ownership-new-bucket.md @@ -2,16 +2,16 @@ When you create a bucket, you can configure S3 Object Ownership\. To set Object Ownership for an existing bucket, see [Setting Object Ownership on an existing bucket](object-ownership-existing-bucket.md)\. -S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable [access control lists \(ACLs\)](acl-overview.md) and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. We recommend that you disable ACLs unless you to need to control access at the individual object level\. +S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable [access control lists \(ACLs\)](acl-overview.md) and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. By default, S3 Object Ownership is set to the bucket owner enforced setting, and ACLs are disabled for new buckets\. With ACLs disabled, the bucket owner owns every object in the bucket and manages access to data exclusively by using access\-management policies\. We recommend that you keep ACLs disabled, except in unusual circumstances where you must control access for each object individually\. 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 \(recommended\)** – 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\. ++ **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 \(default\)** – 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\. ++ **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\. **Permissions**: To apply the **Bucket owner enforced** setting or the **Bucket owner preferred** setting, you must have the following permissions: `s3:CreateBucket` and `s3:PutBucketOwnershipControls`\. No additional permissions are needed when creating a bucket with the **Object writer** setting applied\. For more information about Amazon S3 permissions, see [Actions, resources, and condition keys for Amazon S3](list_amazons3.md)\. @@ -31,7 +31,7 @@ A majority of modern use cases in Amazon S3 no longer require the use of ACLs, a 1. For **Bucket name**, enter a name for your bucket\. The bucket name must: - + Be unique within a partition\. A partition is a grouping of Regions\. AWS currently has three partitions: `aws` \(Standard Regions\), `aws-cn` \(China Regions\), and `aws-us-gov` \(AWS GovCloud \[US\] Regions\)\. + + Be unique within a partition\. A partition is a grouping of Regions\. AWS currently has three partitions: `aws` \(Standard Regions\), `aws-cn` \(China Regions\), and `aws-us-gov` \(AWS GovCloud \(US\) Regions\)\. + Be between 3 and 63 characters long\. + Consist only of lowercase letters, numbers, dots \(\.\), and hyphens \(\-\)\. For best compatibility, we recommend that you avoid using dots \(\.\) in bucket names, except for buckets that are used only for static website hosting\. + Begin and end with a letter or number\. @@ -47,21 +47,23 @@ Avoid including sensitive information, such as account numbers, in the bucket na 1. Under **Object Ownership**, to disable or enable ACLs and control ownership of objects uploaded in your bucket, choose one of the following settings: **ACLs disabled** - + **Bucket owner enforced** – ACLs are disabled, and the bucket owner automatically owns and has full control over every object in the bucket\. ACLs no longer affect access permissions to data in the S3 bucket\. The bucket uses policies to define access control\. + + **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 access permissions to data in the S3 bucket\. The bucket uses policies exclusively to define access control\. - To require that all new buckets are created with ACLs disabled by using AWS Identity and Access Management \(IAM\) or AWS Organizations policies, see [Disabling ACLs for all new buckets \(bucket owner enforced\)](ensure-object-ownership.md#object-ownership-requiring-bucket-owner-enforced)\. + By default, ACLs are disabled\. 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 unusual circumstances where you must control access for each object individually\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **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\. - If you apply the bucket owner preferred setting, to require all Amazon S3 uploads to include the `bucket-owner-full-control` canned ACL, you can [add a bucket policy](ensure-object-ownership.md#ensure-object-ownership-bucket-policy) that allows only object uploads that use this ACL\. + If you apply the **Bucket owner preferred** setting, to require all Amazon S3 uploads to include the `bucket-owner-full-control` canned ACL, you can [add a bucket policy](ensure-object-ownership.md#ensure-object-ownership-bucket-policy) that allows only object uploads that use this 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\. **Note** -To apply the **Bucket owner enforced** setting or the **Bucket owner preferred** setting, you must have permission to use the following actions: `s3:CreateBucket` and `s3:PutBucketOwnershipControls`\. +The default setting is **Bucket owner enforced**\. To apply the default setting and keep ACLs disabled, only the `s3:CreateBucket` permission is needed\. To enable ACLs, you must have the `s3:PutBucketOwnershipControls` permission\. 1. Under **Block Public Access settings for this bucket**, choose the Block Public Access settings that you want to apply to the bucket\. - We recommend that you keep all settings enabled unless you know that you need to turn off one or more of them for your use case, such as to host a public website\. The Block Public Access settings that you enable for the bucket are also enabled for all access points that you create on the bucket\. For more information about blocking public access, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. + By default, all four Block Public Access settings are enabled\. We recommend that you keep all settings enabled, unless you know that you need to turn off one or more of them for your specific use case\. For more information about blocking public access, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. +**Note** +To enable all Block Public Access settings, only the `s3:CreateBucket` permission is required\. To turn off any Block Public Access settings, you must have the `s3:PutBucketPublicAccessBlock` permission\. 1. \(Optional\) Under **Bucket Versioning**, you can choose if you wish to keep variants of objects in your bucket\. For more information about versioning, see [Using versioning in S3 buckets](Versioning.md)\. diff --git a/doc_source/object-ownership-retrieving.md b/doc_source/object-ownership-retrieving.md index f4bfb19..8ebecad 100644 --- a/doc_source/object-ownership-retrieving.md +++ b/doc_source/object-ownership-retrieving.md @@ -1,15 +1,15 @@ # Viewing the Object Ownership setting for an S3 bucket -S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable [access control lists \(ACLs\)](acl-overview.md) and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. We recommend that you disable ACLs unless you to need to control access at the individual object level\. +S3 Object Ownership is an Amazon S3 bucket\-level setting that you can use to disable [access control lists \(ACLs\)](acl-overview.md) and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3\. By default, S3 Object Ownership is set to the bucket owner enforced setting, and ACLs are disabled for new buckets\. With ACLs disabled, the bucket owner owns every object in the bucket and manages access to data exclusively by using access\-management policies\. We recommend that you keep ACLs disabled, except in unusual circumstances where you must control access for each object individually\. 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 \(recommended\)** – 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\. ++ **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 \(default\)** – 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\. ++ **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\. You can view the S3 Object Ownership settings for an Amazon S3 bucket\. To set Object Ownership for a new bucket, see [Setting Object Ownership when you create a bucket](object-ownership-new-bucket.md)\. To set Object Ownership for an existing bucket, see [Setting Object Ownership on an existing bucket](object-ownership-existing-bucket.md)\. diff --git a/doc_source/privatelink-interface-endpoints.md b/doc_source/privatelink-interface-endpoints.md index 1eeb5e1..87346e9 100644 --- a/doc_source/privatelink-interface-endpoints.md +++ b/doc_source/privatelink-interface-endpoints.md @@ -157,7 +157,7 @@ For more information about how to view your endpoint\-specific DNS names, see [V To access S3 buckets, S3 access points, or Amazon S3 Control API operations through S3 interface endpoints in AWS CLI commands, use the `--region` and `--endpoint-url` parameters\. **Example: Use an endpoint URL to list objects in your bucket** -In the following example, replace the Region `us-east-1`, the DNS name of the VPC endpoint ID `vpce-1a2b3c4d-5e6f.s3.us-east-1.vpce.amazonaws.com`, and the bucket name `my-bucket` with your own information\. +In the following example, replace the bucket name `my-bucket`, Region `us-east-1`, and the DNS name of the VPC endpoint ID `vpce-1a2b3c4d-5e6f.s3.us-east-1.vpce.amazonaws.com` with your own information\. ``` aws s3 ls s3://my-bucket/ --region us-east-1 --endpoint-url https://bucket.vpce-1a2b3c4d-5e6f.s3.us-east-1.vpce.amazonaws.com diff --git a/doc_source/s3-access-control.md b/doc_source/s3-access-control.md index 78a0547..af6a1c0 100644 --- a/doc_source/s3-access-control.md +++ b/doc_source/s3-access-control.md @@ -4,9 +4,9 @@ By default, all Amazon S3 resources—buckets, objects, and related subresources Amazon S3 offers access policy options broadly categorized as resource\-based policies and user policies\. Access policies that you attach to your resources \(buckets and objects\) are referred to as *resource\-based policies*\. For example, bucket policies and access point policies are resource\-based policies\. You can also attach access policies to users in your account\. These are called *user policies*\. You can choose to use resource\-based policies, user policies, or some combination of these to manage permissions to your Amazon S3 resources\. You can also use access control lists \(ACLs\) to grant basic read and write permissions to other AWS accounts\. -By default, when another AWS account uploads an object to your S3 bucket, that account \(the object writer\) owns the object, has access to it, and can grant other users access to it through ACLs\. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket\. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. +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, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually\. With Object Ownership, you can disable ACLs and rely on policies for access control\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies\. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. + 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 unusual 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, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. For more information about managing access to your Amazon S3 objects and buckets, see the topics below\. @@ -19,5 +19,5 @@ For more information about managing access to your Amazon S3 objects and buckets + [Managing access with ACLs](acls.md) + [Using cross\-origin resource sharing \(CORS\)](cors.md) + [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md) -+ [Reviewing bucket access using Access Analyzer for S3](access-analyzer.md) ++ [Reviewing bucket access using IAM Access Analyzer for S3](access-analyzer.md) + [Verifying bucket ownership with bucket owner condition](bucket-owner-condition.md) \ No newline at end of file diff --git a/doc_source/security-best-practices.md b/doc_source/security-best-practices.md index d673b1e..10b3ee9 100644 --- a/doc_source/security-best-practices.md +++ b/doc_source/security-best-practices.md @@ -11,14 +11,15 @@ Amazon S3 provides a number of security features to consider as you develop and The following best practices for Amazon S3 can help prevent security incidents\. **Disable access control lists \(ACLs\)** -A majority of modern use cases in Amazon S3 no longer require the use of [access control lists \(ACLs\)](acl-overview.md), and we recommend that you disable ACLs except in unusual circumstances where you must control access for each object individually\. To disable ACLs and take ownership of every object in your bucket, apply the bucket owner enforced setting for S3 Object Ownership\. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts\. Access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud \(VPC\) endpoint policies, and AWS Organizations service control policies \(SCPs\)\. -Disabling ACLs simplifies permissions management and auditing\. You can disable ACLs on both newly created and already existing buckets\. 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\. -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\. You must reset your bucket ACL to the default \(full control to the bucket owner\)\. 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`\. +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 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 [access control lists \(ACLs\)](acl-overview.md), and we recommend that you keep ACLs disabled except in unusual circumstances where you must control access for each object individually\. When you disable ACLs, you can more easily maintain a bucket with objects uploaded by different AWS accounts\. Access control for your data is based on policies, such as IAM policies and S3 bucket policies\. +Disabling ACLs simplifies permissions management\. When you create a bucket, ACLs are automatically disabled\. You can also disable ACLs on existing buckets\. 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\. +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`\. For more information\. see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md)\. **Ensure that your Amazon S3 buckets use the correct policies and are not publicly accessible** Unless you explicitly require anyone on the internet to be able to read or write to your S3 bucket, you should ensure that your S3 bucket is not public\. The following are some of the steps you can take: -+ Use Amazon S3 block public access\. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources that are enforced regardless of how the resources are created\. For more information, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. ++ You can use Amazon S3 Block Public Access to manage public access to Amazon S3 resources\. Block Public Access provides settings to help you avoid inadvertent public exposure of your resources\. You can apply these settings to individual access points, buckets, or entire AWS accounts\. By default, all Block Public Access settings are enabled for new buckets\. For more information, see [Blocking public access to your Amazon S3 storage](access-control-block-public-access.md)\. + Identify Amazon S3 bucket policies that allow a wildcard identity such as Principal “\*” \(which effectively means “anyone”\) or allows a wildcard action “\*” \(which effectively allows the user to perform any action in the Amazon S3 bucket\)\. + Similarly, note Amazon S3 bucket access control lists \(ACLs\) that provide read, write, or full\-access to “Everyone” or “Any authenticated AWS user\.” + Use the `ListBuckets` API to scan all of your Amazon S3 buckets\. Then use `GetBucketAcl`, `GetBucketWebsite`, and `GetBucketPolicy` to determine whether the bucket has compliant access controls and configuration\. diff --git a/doc_source/troubleshoot-403-errors.md b/doc_source/troubleshoot-403-errors.md index 4f445e2..536926d 100644 --- a/doc_source/troubleshoot-403-errors.md +++ b/doc_source/troubleshoot-403-errors.md @@ -67,9 +67,6 @@ To check whether the requester has proper permissions to perform an Amazon S3 op ## Amazon S3 ACL settings -**Important** -A majority of use cases in Amazon S3 no longer require the use of access control lists \(ACLs\)\. We recommend that you disable ACLs, except in unusual circumstances where you need to control access for each object individually\. Starting in April 2023, Amazon S3 will change the default setting for S3 Object Ownership for all new buckets\. For new buckets created after this update, ACLs will be disabled\. This new default follows the recommended best practices for securing data in Amazon S3\. You can adjust the Object Ownership setting after creating your bucket\. For more information, see [ Default settings for new S3 buckets FAQ](create-bucket-faq.md) and [Heads\-up: Amazon S3 security changes are coming in April of 2023](http://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/) in the *AWS News Blog*\. - When checking your ACL settings, first [review your Object Ownership setting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-retrieving.html) to check whether ACLs are enabled on the bucket\. Be aware that ACL permissions can be used only to grant permissions and cannot be used to reject requests\. ACLs also cannot be used to grant access to requesters that are rejected by explicit denials in bucket policies or IAM user policies\. ### The Object Ownership setting is set to bucket owner enforced