AWS Security ChangesHomeSearch

AWS prescriptive-guidance documentation change

Service: prescriptive-guidance · 2025-04-23 · Documentation low

File: prescriptive-guidance/latest/defining-bucket-names-data-lakes/welcome.md

Summary

Updated document title, author list, date, and terminology (S3 to Amazon S3). Added 'Intended audience' section. Enhanced governance outcome mentions differentiated access policies. Updated links and formatting.

Security assessment

The change adds explicit mention of 'differentiated access policies' as part of governance improvements, which relates to security best practices for IAM policies. However, there is no evidence of addressing a specific security vulnerability or incident.

Diff

diff --git a/prescriptive-guidance/latest/defining-bucket-names-data-lakes/welcome.md b/prescriptive-guidance/latest/defining-bucket-names-data-lakes/welcome.md
index 2700fb7f6..b7a034470 100644
--- a//prescriptive-guidance/latest/defining-bucket-names-data-lakes/welcome.md
+++ b//prescriptive-guidance/latest/defining-bucket-names-data-lakes/welcome.md
@@ -3 +3 @@
-[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Defining S3 bucket and path names for data lake layers on the AWS Cloud](welcome.html)
+[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Defining Amazon S3 bucket and path names for data lake layers](welcome.html)
@@ -5 +5 @@
-Targeted business outcomes
+Intended audienceTargeted business outcomes
@@ -7 +7 @@ Targeted business outcomes
-# Defining S3 bucket and path names for data lake layers on the AWS Cloud
+# Defining Amazon S3 bucket and path names for data lake layers
@@ -9 +9 @@ Targeted business outcomes
- _Isabelle Imacseng, Samuel Schmidt, and Andrés Cantor, Amazon Web Services (AWS)_
+ _Andres Cantor, Amazon Web Services_
@@ -11 +11 @@ Targeted business outcomes
-_November 2021_ ([document history](./doc-history.html))
+ _April 2025_ ([document history](./doc-history.html))
@@ -13 +13 @@ _November 2021_ ([document history](./doc-history.html))
-This guide helps you create a consistent naming standard for Amazon Simple Storage Service (Amazon S3) buckets and paths in data lakes hosted on the Amazon Web Services (AWS) Cloud. The guide's naming standard for S3 buckets and paths helps you to improve governance and observability in your data lakes, identify costs by data layer and AWS account, and provides an approach for naming AWS Identity and Access Management (IAM) roles and policies.
+This guide helps you create a consistent naming standard for Amazon Simple Storage Service (Amazon S3) buckets and paths in data lakes hosted on the AWS Cloud. The guide's naming standard for Amazon S3 buckets and paths helps you to improve governance and observability in your data lakes, identify costs by data layer and AWS account, and provides an approach for naming AWS Identity and Access Management (IAM) roles and policies.
@@ -15 +15 @@ This guide helps you create a consistent naming standard for Amazon Simple Stora
-We recommend that you use at least three data layers in your data lakes and that each layer uses a separate S3 bucket. However, some use cases might require an additional S3 bucket and data layer, depending on the data types that you generate and store. For example, if you store sensitive data, we recommend that you use a landing zone data layer and a separate S3 bucket. The following list describes the three recommended data layers for your data lake:
+We recommend that you use at least three data layers in your data lakes and that each layer uses a separate Amazon S3 bucket. However, some use cases might require an additional Amazon S3 bucket and data layer, depending on the data types that you generate and store. For example, if you store sensitive data, we recommend that you use a landing zone data layer and a separate Amazon S3 bucket. The following list describes the three recommended data layers for your data lake:
@@ -17 +17 @@ We recommend that you use at least three data layers in your data lakes and that
-  * **Raw data layer** – Contains raw data and is the layer in which data is initially ingested. If possible, we recommend that you retain the original file format and turn on versioning in the S3 bucket.
+  * **Raw data layer** – Contains raw data and is the layer in which data is initially ingested. If possible, we recommend that you retain the original file format and turn on versioning in the Amazon S3 bucket.
@@ -19 +19 @@ We recommend that you use at least three data layers in your data lakes and that
-  * **Stage data layer** – Contains intermediate, processed data that is optimized for consumption (for example CSV to Apache Parquet converted raw files or data transformations). An AWS Glue job reads the files from the raw layer and validates the data. The AWS Glue job then stores the data in an Apache Parquet-formatted file and the metadata is stored in a table in the AWS Glue Data Catalog.
+  * **Stage data layer** – Contains intermediate, processed data that is optimized for consumption (for example CSV to Apache Parquet converted raw files or data transformations). An AWS Glue job reads the files from the raw layer and validates the data. The AWS Glue job then stores the data in an Apache Parquet-formatted file, and the metadata is stored in a table in the AWS Glue Data Catalog.
@@ -21 +21 @@ We recommend that you use at least three data layers in your data lakes and that
-  * **Analytics data layer** – Contains the aggregated data for your specific use cases in a consumption-ready format (for example, Apache Parquet). 
+  * **Analytics data layer** – Contains the aggregated data for your specific use cases in a consumption-ready format, such as Apache Parquet.
@@ -26 +26,3 @@ We recommend that you use at least three data layers in your data lakes and that
-This guide's recommendations are based on the authors’ experience in implementing data lakes with the [serverless data lake framework (SDLF)](https://sdlf.workshop.aws/en/) and are intended for data architects, data engineers, or solutions architects who want to set up a data lake on the AWS Cloud. However, you must make sure that you adapt this guide's approach to meet your organization's policies and requirements. 
+## Intended audience
+
+This guide's recommendations are based on the authors' experience in implementing data lakes with the [serverless data lake framework (SDLF)](https://sdlf.workshop.aws/en/) and are intended for data architects, data engineers, or solutions architects who want to set up a data lake on the AWS Cloud. However, make sure that you adapt this guide's approach to meet your organization's policies and requirements.
@@ -32 +34 @@ The guide contains the following sections:
-  * [Naming S3 buckets in your data layers](./naming-structure-data-layers.html)
+  * [Naming Amazon S3 buckets in your data layers](./naming-structure-data-layers.html)
@@ -34 +36 @@ The guide contains the following sections:
-  * [Mapping S3 buckets to IAM policies in your data lake](./iam-policies-data-lakes.html)
+  * [Mapping Amazon S3 buckets to IAM policies in your data lake](./iam-policies-data-lake.html)
@@ -36 +38 @@ The guide contains the following sections:
-  * [Handling sensitive data](./handling-sensitive-data.html)
+  * [Handling sensitive data](./sensitive-data.html)
@@ -43 +45 @@ The guide contains the following sections:
-You should expect the following five outcomes after implementing a naming standard for S3 buckets and paths in data lakes on the AWS Cloud:
+You should expect the following outcomes after implementing a naming standard for Amazon S3 buckets and paths in data lakes on the AWS Cloud:
@@ -45 +47 @@ You should expect the following five outcomes after implementing a naming standa
-  * Improved governance and observability in your data lake. 
+  * Improved governance in your data lake by being able to provide differentiated access policies to the buckets
@@ -47 +49 @@ You should expect the following five outcomes after implementing a naming standa
-  * Increased visibility into your overall costs for individual AWS accounts by using the relevant AWS account ID in the S3 bucket name and for data layers by using [cost allocation tags](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CostAllocTagging.html) for the S3 buckets.
+  * Increased visibility into your overall costs for individual AWS accounts by using the relevant AWS account ID in the Amazon S3 bucket name and for data layers by using [cost allocation tags](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CostAllocTagging.html) for the buckets
@@ -49 +51 @@ You should expect the following five outcomes after implementing a naming standa
-  * More cost-effective data storage by using layer-based versioning and path-based lifecycle policies.
+  * More cost-effective data storage by using layer-based versioning and path-based lifecycle policies
@@ -51 +53 @@ You should expect the following five outcomes after implementing a naming standa
-  * Meet security requirements for data masking and data encryption.
+  * Meet security requirements for data masking and data encryption
@@ -53 +55 @@ You should expect the following five outcomes after implementing a naming standa
-  * Simplify data source tracing by enhancing developer visibility to the AWS Region and AWS account of the underlying data storage. 
+  * Simplify data source tracing by enhancing developer visibility into the AWS Region and AWS account of the underlying data storage