Index capacity and cost in DynamoDB - Step-by-Step Execution

Concept Flow - Index capacity and cost

Create Table

↓

Add Index (GSI or LSI)

↓

Write Operation

↓

Calculate Capacity Units

↓

Calculate Cost

↓

Billing Based on Usage

This flow shows how adding an index affects capacity units and cost in DynamoDB, starting from table creation to billing.

Execution Sample

DynamoDB

Create table with 5 WCU and 5 RCU
Add a Global Secondary Index (GSI) with 2 WCU and 2 RCU
Write 10 items to table (propagates to GSI)
Read 5 items from table
Read 5 items from GSI
Calculate total WCU and RCU consumed
Calculate cost based on capacity units

This example shows how writing data to a table with a GSI consumes capacity units on both table and GSI, and reads consume separately, affecting cost.

Execution Table

Step	Action	Table WCU Used	GSI WCU Used	Total WCU	Table RCU Used	GSI RCU Used	Total RCU	Cost Impact
1	Create table with 5 WCU and 5 RCU	0	0	0	0	0	0	No usage cost yet
2	Add GSI with 2 WCU and 2 RCU	0	0	0	0	0	0	No usage cost yet
3	Write 10 items to table (propagates to GSI)	10	10	20	0	0	0	Consumes 10 WCU on table + 10 WCU on GSI
4	Read 5 items from table	10	10	20	5	0	5	Consumes 5 RCU on table
5	Read 5 items from GSI	10	10	20	5	5	10	Consumes 5 RCU on GSI
6	Calculate total capacity	10	10	20	5	5	10	Total: 20 WCU and 10 RCU consumed
7	Billing	-	-	-	-	-	-	Charged for 20 WCU and 10 RCU usage (on-demand mode)

💡 Execution stops after billing calculation based on capacity units used.

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
Table WCU Used	0	10	10	10	10
GSI WCU Used	0	10	10	10	10
Total WCU	0	20	20	20	20
Table RCU Used	0	0	5	5	5
GSI RCU Used	0	0	0	5	5
Total RCU	0	0	5	10	10

Key Moments - 3 Insights

Why does writing to a table with GSI consume write capacity units on both?

Writes to the table automatically propagate to the GSI, which maintains its own copy of data, consuming WCU on table and GSI separately (see execution_table row 3).

Does reading from a GSI consume read capacity units from the main table?

No, reading from a GSI consumes RCU from the GSI's provisioned/on-demand capacity only (see execution_table row 5).

How is the total cost calculated when using indexes?

In on-demand mode, cost is based on the sum of capacity units actually consumed by the table and all indexes (see execution_table rows 6-7).

Visual Quiz - 3 Questions

Look at the execution_table, what is the total write capacity units used after step 3?

A 10

B 20

C 0

D 5

💡 Hint

Check the 'Total WCU' column at step 3 in the execution_table.

At which step does reading from the GSI first consume read capacity units?

A Step 5

B Step 4

C Step 3

D Step 6

💡 Hint

Look at the 'GSI RCU Used' column in the execution_table.

If you remove the GSI, how would the total write capacity units after step 3 change?

A It would stay 20

B It would become 0

C It would become 10

D It would become 5

💡 Hint

Without GSI, writes consume WCU only on the table (10 WCU for 10 items).

Concept Snapshot

DynamoDB indexes (GSI/LSI) have separate capacity units.
Writes to table automatically update GSIs, consuming WCU on table + each GSI.
Reads from table/GSI consume RCU from their respective capacities.
In on-demand mode, billed for consumed units across table + indexes.
Plan indexes carefully to balance query flexibility and cost.

Full Transcript

This visual execution demonstrates DynamoDB index capacity and cost. Create a table, add a GSI—each with their capacity settings. Writing items to the table consumes WCU on both table and GSI since GSIs store data copies. Reads consume RCU separately from table or GSI. Total consumed units sum table + index usage. In on-demand billing, pay for actual consumption. This helps optimize capacity planning and costs.

Practice

1. What is the main reason to use indexes in DynamoDB?

easy

A. To speed up query performance by allowing efficient data access

B. To reduce the storage size of the table

C. To automatically backup data

D. To encrypt data at rest

Solution

1. Step 1: Understand the purpose of indexes

   Indexes in DynamoDB are designed to speed up queries by providing alternate ways to access data efficiently.

2. Step 2: Eliminate unrelated options

   Options about storage size, backup, and encryption are unrelated to index functionality.

3. Final Answer:

   To speed up query performance by allowing efficient data access -> Option A

4. Quick Check:

   Indexes improve query speed = B [OK]

Hint: Indexes speed queries, not reduce storage or backup [OK]

Common Mistakes:

• Thinking indexes reduce storage cost
• Confusing indexes with backup features
• Assuming indexes encrypt data

2. Which of the following is the correct way to specify a Global Secondary Index (GSI) in a DynamoDB table creation JSON?

easy

A. {
"LocalSecondaryIndexes": [
{
"IndexName": "MyGSI",
"KeySchema": [
{"AttributeName": "UserId", "KeyType": "HASH"}
],
"Projection": {"ProjectionType": "ALL"}
}
]
}

B. {
"GlobalSecondaryIndexes": [
{
"IndexName": "MyGSI",
"KeySchema": [
{"AttributeName": "UserId", "KeyType": "HASH"}
],
"Projection": {"ProjectionType": "ALL"},
"ProvisionedThroughput": {"ReadCapacityUnits": 5, "WriteCapacityUnits": 5}
}
]
}

C. {
"GlobalSecondaryIndexes": {
"IndexName": "MyGSI"
}
}

D. {
"Indexes": [
{
"Name": "MyGSI"
}
]
}

Solution

1. Step 1: Identify correct GSI syntax

   Global Secondary Indexes require an array under "GlobalSecondaryIndexes" with full details: IndexName, KeySchema, Projection, and ProvisionedThroughput.

2. Step 2: Compare options

   { "GlobalSecondaryIndexes": [ { "IndexName": "MyGSI", "KeySchema": [ {"AttributeName": "UserId", "KeyType": "HASH"} ], "Projection": {"ProjectionType": "ALL"}, "ProvisionedThroughput": {"ReadCapacityUnits": 5, "WriteCapacityUnits": 5} } ] } correctly uses "GlobalSecondaryIndexes" as an array with all required fields. Others use wrong keys or incomplete structures.

3. Final Answer:

   { "GlobalSecondaryIndexes": [ { "IndexName": "MyGSI", "KeySchema": [ {"AttributeName": "UserId", "KeyType": "HASH"} ], "Projection": {"ProjectionType": "ALL"}, "ProvisionedThroughput": {"ReadCapacityUnits": 5, "WriteCapacityUnits": 5} } ] } -> Option B

4. Quick Check:

   GSI syntax requires array with full details = A [OK]

Hint: GSIs need full details in GlobalSecondaryIndexes array [OK]

Common Mistakes:

• Using LocalSecondaryIndexes instead of GlobalSecondaryIndexes
• Providing object instead of array for GSIs
• Omitting ProvisionedThroughput for GSIs

3. Given a DynamoDB table with a provisioned write capacity of 10 units and a Global Secondary Index (GSI) with 5 write capacity units, what is the total write capacity units consumed when writing one item to the table and the GSI?

medium

A. 5 units

B. 10 units

C. 15 units

D. 20 units

Solution

1. Step 1: Understand write capacity consumption

   Writing one item consumes write capacity units on the main table plus on each index that is updated.

2. Step 2: Add main table and GSI write units

   Main table uses 10 units, GSI uses 5 units, total = 10 + 5 = 15 units.

3. Final Answer:

   15 units -> Option C

4. Quick Check:

   Total write capacity = main + GSI = 15 [OK]

Hint: Add main table and index write units for total cost [OK]

Common Mistakes:

• Counting only main table write units
• Counting only GSI write units
• Multiplying instead of adding capacities

4. You notice your DynamoDB table's write capacity is being exceeded even though your application writes only a few items per second. Which of the following is the most likely cause related to indexes?

medium

A. You have a Global Secondary Index with high write capacity units causing extra cost

B. You forgot to create any indexes

C. Your table has no read capacity units set

D. You are using Local Secondary Indexes which do not affect write capacity

Solution

1. Step 1: Analyze write capacity usage

   Writes to the table also consume write capacity on GSIs, increasing total usage.

2. Step 2: Identify cause of exceeded capacity

   If GSIs have high write capacity or many writes, they can cause capacity to be exceeded even if main table writes are low.

3. Final Answer:

   You have a Global Secondary Index with high write capacity units causing extra cost -> Option A

4. Quick Check:

   GSIs increase write capacity usage = C [OK]

Hint: Check GSIs for hidden write capacity usage [OK]

Common Mistakes:

• Assuming no indexes means no extra capacity
• Confusing read and write capacity units
• Thinking Local Secondary Indexes increase write capacity

5. You want to optimize costs for a DynamoDB table with a Global Secondary Index (GSI). The table has 20 write capacity units and the GSI has 10 write capacity units. If your application writes 5 items per second, how can you reduce costs without affecting query performance on the GSI?

hard

A. Disable the table's write capacity units

B. Remove the GSI to save all index costs

C. Increase the table write capacity units to 30

D. Reduce the GSI write capacity units to 5 and enable auto scaling

Solution

1. Step 1: Understand cost drivers

   Write capacity units on both table and GSI affect cost. Reducing GSI units lowers cost but must still handle write load.

2. Step 2: Apply auto scaling and adjust capacity

   Reducing GSI write units to match actual writes (5) and enabling auto scaling balances cost and performance.

3. Final Answer:

   Reduce the GSI write capacity units to 5 and enable auto scaling -> Option D

4. Quick Check:

   Lower GSI units + auto scaling = cost optimization [OK]

Hint: Match GSI capacity to writes and use auto scaling [OK]

Common Mistakes:

• Removing GSI and losing query performance
• Increasing table capacity unnecessarily
• Disabling write capacity causing failures