AWS Security ChangesHomeSearch

AWS AmazonS3 documentation change

Service: AmazonS3 · 2025-07-18 · Documentation low

File: AmazonS3/latest/userguide/metadata-tables-schema.md

Summary

Updated documentation to emphasize journal tables for auditing and security use cases, added examples of security-related queries (IP addresses, KMS keys), and clarified terminology from 'metadata tables' to 'journal tables'.

Security assessment

The changes highlight security and compliance use cases (e.g., tracking deletions, auditing request sources, KMS key usage) but do not address a specific security vulnerability. The additions demonstrate how to use journal tables for security monitoring, which qualifies as adding security documentation.

Diff

diff --git a/AmazonS3/latest/userguide/metadata-tables-schema.md b/AmazonS3/latest/userguide/metadata-tables-schema.md
index 2d1c273cc..cfa55faa6 100644
--- a//AmazonS3/latest/userguide/metadata-tables-schema.md
+++ b//AmazonS3/latest/userguide/metadata-tables-schema.md
@@ -5 +5 @@
-# S3 Metadata tables schema
+# S3 Metadata journal tables schema
@@ -7 +7 @@
-Amazon S3 metadata tables contain rows and columns. Each row represents a mutation event that has created, updated, or deleted an object in your general purpose bucket. Most of these events are the result of various user actions, but some of these events are the result of actions taken by Amazon S3 on your behalf, such as S3 Lifecycle expirations or storage class transitions. 
+The journal table records changes made to your data in near real time, helping you to identify new data uploaded to your bucket, track recently deleted objects, monitor lifecycle transitions, and more. The journal table records new objects and updates to your objects and their metadata (those updates that require either a `PUT` or a `DELETE` operation). Because this table is queryable, you can audit the changes to your bucket through simple SQL queries. 
@@ -9 +9 @@ Amazon S3 metadata tables contain rows and columns. Each row represents a mutati
-S3 Metadata is an event-processing pipeline that is designed to keep the metadata table eventually consistent with what changes have occurred in your general purpose bucket. Be aware that by the time that S3 Metadata is notified that an object is created or updated, that object might already have been overwritten or deleted in the bucket. By default, a table row is created for each [S3 bucket operation](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/s3-example-basic-bucket-operations.html). However, if any object metadata is deleted or overwritten, or objects can no longer be retrieved, some columns might show a `NULL` value to indicate any missing metadata schema.
+You can use the journal table for security, auditing, and compliance use cases to track uploaded, deleted, and changed objects in the bucket. For example, you can query the journal table to answer questions such as: 
@@ -11 +11,16 @@ S3 Metadata is an event-processing pipeline that is designed to keep the metadat
-The following is an example of a metadata table for a general purpose bucket named `amzn-s3-demo-bucket:`
+  * Which objects were deleted in the past 24 hours by S3 Lifecycle?
+
+  * Which IP addresses did the most recent `PUT` requests come from?
+
+  * Which AWS Key Management Service (AWS KMS) keys were used for `PUT` requests in the past 7 days?
+
+  * Which objects in your bucket were created by Amazon Bedrock in the last five days?
+
+
+
+
+Amazon S3 Metadata journal tables contain rows and columns. Each row represents a mutation event that has created, updated, or deleted an object in your general purpose bucket. Most of these events result from user actions, but some of these events result from actions taken by Amazon S3 on your behalf, such as S3 Lifecycle expirations or storage class transitions. 
+
+S3 Metadata journal tables are eventually consistent with the changes that have occurred in your general purpose bucket. In some cases, by the time S3 Metadata is notified that an object is created or updated, that object might already have been overwritten or deleted in the bucket. In such cases, the objects can no longer be retrieved and some columns might show a NULL value to indicate missing metadata schema.
+
+The following is an example of a journal table for a general purpose bucket named `amzn-s3-demo-bucket:`
@@ -19 +34 @@ The following is an example of a metadata table for a general purpose bucket nam
-Metadata tables have the following schema:
+Journal tables have the following schema:
@@ -47 +62 @@ If a row represents an object version that no longer existed at the time that a
-`object_tags` | No | Map <String, String> |  The object tags that are associated with the object. Object tags are stored as a map of key-value pairs. If an object has no object tags, an empty map (`{}`) is stored. For more information, see [Categorizing your storage using tags](./object-tagging.html)
+`object_tags` | No | Map <String, String> |  The object tags that are associated with the object. Object tags are stored as a map of key-value pairs. If an object has no object tags, an empty map (`{}`) is stored. For more information, see [Categorizing your storage using tags](./object-tagging.html).
@@ -57 +72 @@ If the `record_type` value is `DELETE`, the `user_metadata` column contains a nu
-`requester` | No | String | The AWS account ID of the requester or the AWS service principal that made the request.  
+`requester` | No | String | The AWS account ID of the requester or the AWS service principal that made the request. For example, if the requester is S3 Lifecycle, this value is `s3.amazonaws.com`.   
@@ -69 +84 @@ Limitations and restrictions
-Configuring metadata tables
+Live inventory tables schema