AWS Security ChangesHomeSearch

AWS amazondynamodb documentation change

Service: amazondynamodb · 2026-07-07 · Documentation low

File: amazondynamodb/latest/developerguide/data-modeling-blocks.md

Summary

Replaced multiple conceptual images with markdown tables showing concrete data examples for shopping carts, multi-tenant applications, sparse indexes, TTL usage, vertical partitioning, and write sharding.

Security assessment

The change improves documentation clarity by replacing visual diagrams with structured data examples. No security vulnerabilities, security features, or security-related content are referenced in the added tables. The examples show standard data modeling patterns without security implications.

Diff

diff --git a/amazondynamodb/latest/developerguide/data-modeling-blocks.md b/amazondynamodb/latest/developerguide/data-modeling-blocks.md
index 99e80b8e5..b42faa28b 100644
--- a//amazondynamodb/latest/developerguide/data-modeling-blocks.md
+++ b//amazondynamodb/latest/developerguide/data-modeling-blocks.md
@@ -38 +38,7 @@ When people think of NoSQL, they may also think of it as non-relational. Ultimat
-![Image showing an item in a table with a userID as the primary key, and a combination of other attributes as the sort key.](/images/amazondynamodb/latest/developerguide/images/DataModeling/ShoppingCart.png)
+Partition key: PK | Sort key: SK  
+---|---  
+UserID | CART#ACTIVE#Apples  
+UserID | CART#ACTIVE#Bananas  
+UserID | CART#SAVED#Oranges  
+UserID | CART#SAVED#Pears  
+UserID | WISH#VEGGIES#Carrots  
@@ -59 +65,7 @@ Many customers use DynamoDB to host data for their multi-tenant applications. Fo
-![Image showing a table that could represent a multi-tenant photo site. The primary key is made up of users as the partition key and different photos as the sort key. The attribute for each item shows the URL the photo is hosted at.](/images/amazondynamodb/latest/developerguide/images/DataModeling/MultiTenant.png)
+Partition key: PK | Sort key: SK | ImageURL  
+---|---|---  
+UserOne | PhotoID1 | https://s3.amazonaws.com/[BUCKET-NAME]/[FILE-NAME].[FILE-TYPE]  
+UserOne | PhotoID2 | https://s3.amazonaws.com/[BUCKET-NAME]/[FILE-NAME].[FILE-TYPE]  
+UserTwo | PhotoID3 | https://s3.amazonaws.com/[BUCKET-NAME]/[FILE-NAME].[FILE-TYPE]  
+UserTwo | PhotoID4 | https://s3.amazonaws.com/[BUCKET-NAME]/[FILE-NAME].[FILE-TYPE]  
+UserThree | PhotoID5 | https://s3.amazonaws.com/[BUCKET-NAME]/[FILE-NAME].[FILE-TYPE]  
@@ -80,3 +92,15 @@ Sometimes an access pattern requires looking for items that match a rare item or
-![Image showing a base table that receives a large amount of steady state data](/images/amazondynamodb/latest/developerguide/images/DataModeling/SparseBaseTable.png)
-
-![Image showing a global secondary index that only receives items that have been escalated](/images/amazondynamodb/latest/developerguide/images/DataModeling/SparseGSI.png)
+Partition key: DeviceID | Sort key: State#Date | Operator | Date | EscalatedTo  
+---|---|---|---|---  
+d#12345 | NORMAL#2020-04-24T14:55:00 | Liz | 2020-04-24 |   
+d#12345 | WARNING1#2020-04-24T14:45:00 | Liz | 2020-04-24 |   
+d#12345 | WARNING1#2020-04-24T14:50:00 | Liz | 2020-04-24 |   
+d#54321 | NORMAL#2020-04-11T06:00:00 | Liz | 2020-04-11 |   
+d#54321 | NORMAL#2020-04-11T09:30:00 | Sue | 2020-04-11 |   
+d#54321 | WARNING2#2020-04-11T09:25:00 | Sue | 2020-04-11 |   
+d#54321 | WARNING3#2020-04-11T05:55:00 | Liz | 2020-04-11 |   
+d#11223 | WARNING4#2020-04-27T16:10:00 | Sue | 2020-04-27 |   
+d#11223 | WARNING4#2020-04-27T16:15:00 | Sue | 2020-04-27 | Sara  
+  
+Partition key: EscalatedTo | Sort key: State#Date | DeviceID | Operator  
+---|---|---|---  
+Sara | WARNING4#2020-04-27T16:15:00 | d#11223 | Sue  
@@ -105 +129,5 @@ If you are using [Global Tables version 2019.11.21 (Current)](./GlobalTables.htm
-![Image showing a table with a user's messages with a time to live attribute](/images/amazondynamodb/latest/developerguide/images/DataModeling/TTL.png)
+Partition key: PK | Sort key: MessageTimestamp | TTL | Message  
+---|---|---|---  
+UserID | 2030-06-30T12:12:12 | 1909570332 | Hello  
+UserID | 2030-06-30T12:17:22 | 1909570647 | DynamoDB  
+UserID | 2030-06-30T12:22:27 | 1909570947 | TTL  
@@ -145,5 +173,43 @@ Users familiar with a document model database will be familar with the idea of s
-![Image showing a large data structure formatted as a nested JSON object.](/images/amazondynamodb/latest/developerguide/images/DataModeling/DocumentBlob.png)
-
-![Image showing an item collection where the item's sort key helps keep DynamoDB usage optimized.](/images/amazondynamodb/latest/developerguide/images/DataModeling/SingleTableSchema.png)
-
-Vertical partitoning, as shown above, is a key example of single table design in action but can also be implemented across multiple tables if desired. Since DynamoDB bills writes in 1KB increments, you should ideally partition the document in a way that results in items under 1KB.
+For example, consider the following single JSON document that stores a user's profile, store, shopping cart, shipping address, and order history together:
+    
+    
+    {
+        "UserProfile": {
+            "FirstName": "Paul",
+            "LastName": "Atreides",
+            "DateJoined": "1965-08-01"
+        },
+        "Store": {
+            "store_id": "STOREUID",
+            "city": "Los Angeles",
+            "zip_code": "90029"
+        },
+        "ShoppingCart": [
+            { "Spice": { "SKU": "SpiceSKU", "CategoryID": "FictionalSpice", "DateAdded": "2019-06-11" } },
+            { "EspressoBeans": { "SKU": "CaffeineSKU", "CategoryID": "FOODANDDRINK", "DateAdded": "2019-06-10" } }
+        ],
+        "ShippingAddress": {
+            "street_address": "1234 Arrakis Dr",
+            "city": "Los Angeles",
+            "zip_code": "90029",
+            "status": "default"
+        },
+        "OrderHistory#OrderUID": {
+            "ProductA": "SKU_A",
+            "ProductB": "SKU_B",
+            "DateOrdered": "2018-09-28"
+        }
+    }
+
+Using vertical partitioning, the single document is broken apart into individual items that share the same partition key (`UserID`) but use a sort key prefix to identify each entity. The following table shows the same data stored as separate items:
+
+Partition key: UserID | Sort key: SK | Attributes  
+---|---|---  
+UserID | UserProfile | FirstName: Paul, LastName: Atreides, DateJoined: 1965-08-01  
+UserID | Store#STOREUID | city: Los Angeles, zip_code: 90029  
+UserID | Cart#ACTIVE#Spice | SKU: SpiceSKU, CategoryID: FictionalSpice, DateAdded: 2019-06-11  
+UserID | Cart#ACTIVE#EspressoBeans | SKU: CaffeineSKU, CategoryID: FOODANDDRINK, DateAdded: 2019-06-10  
+UserID | Address#default | street_address: 1234 Arrakis Dr, city: Los Angeles, zip_code: 90029, status: default  
+UserID | OrderHistory#OrderUID | ProductA: SKU_A, ProductB: SKU_B, DateOrdered: 2018-09-28  
+  
+Vertical partitioning, as shown above, is a key example of single table design in action but can also be implemented across multiple tables if desired. Since DynamoDB bills writes in 1KB increments, you should ideally partition the document in a way that results in items under 1KB.
@@ -179 +245,6 @@ In the event requests against the table exceed either of these limits, an error
-![Image showing how DynamoDB shards partition keys across multiple partitions to prevent throttling from spikes in traffic.](/images/amazondynamodb/latest/developerguide/images/DataModeling/WriteShardingSolution.png)
+Partition key: Candidate | Vote-Counter | Last-Update  
+---|---|---  
+CandidateA#1 | 10238 | 2019-09-30T11:35:53  
+CandidateA#2 | 8452 | 2019-09-30T11:35:53  
+CandidateA#3 | 9148 | 2019-09-30T11:35:53  
+CandidateA#4 | 11092 | 2019-09-30T11:35:53