DynamoDB GSI cost explained: the index that quietly doubles writes

Quick answer

A DynamoDB Global Secondary Index (GSI) has its own read and write capacity and its own storage, billed at the same rates as the base table (on-demand write request units around $0.625 per million and reads around $0.125 per million in us-east-1, storage $0.25 per GB-month). The hidden cost is write amplification: every base-table write that changes an indexed attribute also triggers a billed write to each affected GSI, so a table with three GSIs can cost roughly four times the write throughput of the base table alone. Control it by minimizing indexes, projecting only needed attributes, and dropping unused GSIs.

Global Secondary Indexes make DynamoDB queryable by attributes other than the primary key, which is often essential. What is easy to miss is that a GSI is effectively a second copy of your data with its own throughput and storage, and it is maintained by charging you for the writes that keep it in sync. Add a few GSIs without thinking about this, and the write portion of your DynamoDB bill can multiply.

How a GSI is billed

A GSI has independent capacity from the base table. On on-demand, GSI writes cost the same as base-table writes, about $0.625 per million write request units in us-east-1, and reads about $0.125 per million read request units. On provisioned capacity, you set separate write and read capacity units for each GSI. GSI storage is billed at the same $0.25 per GB-month as the table, for whatever attributes the index projects. So far this is just another table's worth of cost, which is significant but predictable.

Write amplification is the real cost

Table config	Writes billed per item write
Base table only	1
Base + 1 GSI (attr changed)	2
Base + 3 GSIs (attrs changed)	4

Every write to the base table that adds, changes, or removes an attribute projected into a GSI triggers a corresponding billed write to that index. With three GSIs whose attributes all change on a typical update, a single logical write becomes four billed writes: one base plus three index. On a write-heavy table, this is the single largest driver of DynamoDB cost, and it is invisible unless you know to look for it. A table doing 100 million writes a month at $0.625 per million is $62.50 base, but $250 total with three fully-touched GSIs.

Projections change storage and cost

When you create a GSI you choose what it projects: KEYS_ONLY, INCLUDE (specific attributes), or ALL. ALL copies every attribute into the index, maximizing storage and the chance that any given write touches the index. KEYS_ONLY stores only the keys, minimizing storage but requiring a second read to the base table to fetch other attributes. The right projection balances query convenience against storage and write cost; projecting ALL by default is a common, avoidable overspend. See DynamoDB cost optimization for the broader picture.

Provisioned versus on-demand for GSIs

A GSI on a provisioned table needs its own capacity planning, and under-provisioned GSI capacity causes throttling even when the base table has headroom. On-demand avoids that but pays the per-request premium on every amplified write. For steady, predictable index traffic, provisioned with autoscaling is usually cheaper; for spiky or unpredictable traffic, on-demand avoids throttling. The trade-off mirrors the base table, covered in on-demand versus provisioned.

Index deliberately, audit regularly

GSIs are worth their cost when they replace expensive scans with efficient queries, but each one adds write amplification and storage that compound on write-heavy tables. Create only the indexes your access patterns require, project the narrowest set of attributes that satisfies the query, and periodically drop GSIs no query uses anymore. Price your table and its indexes against the resource catalog before deploy so the write multiplier is understood up front rather than discovered as an unexplained jump in write cost.

FAQ

How much does a DynamoDB GSI cost?

A GSI has its own read and write capacity and storage, billed at the same rates as the base table: on-demand writes around $0.625 per million request units and reads around $0.125 per million in us-east-1, plus storage at $0.25 per GB-month for projected attributes. On provisioned capacity you set separate capacity units per GSI.

What is GSI write amplification?

Every write to the base table that changes an attribute projected into a GSI also triggers a billed write to that index. With three GSIs whose attributes all change on an update, one logical write becomes four billed writes. On write-heavy tables this is the largest DynamoDB cost driver, quadrupling write cost that a base-only table would incur.

How do GSI projections affect cost?

Projection type sets what the index stores and how often writes touch it. ALL copies every attribute, maximizing storage and write amplification; KEYS_ONLY stores only keys, minimizing both but requiring a base-table read for other attributes; INCLUDE stores a chosen subset. Projecting ALL by default is a common overspend, choose the narrowest projection that satisfies the query.

Should DynamoDB GSIs use on-demand or provisioned?

For steady, predictable index traffic, provisioned capacity with autoscaling is usually cheaper because it avoids the per-request premium on every amplified write. For spiky or unpredictable traffic, on-demand avoids the GSI throttling that under-provisioned capacity causes even when the base table has headroom. Match the mode to the index's traffic pattern.

How does C3X help with DynamoDB GSI cost?

C3X prices DynamoDB tables from Terraform including their GSIs, capacity mode, and projections, so the write amplification and storage each index adds is visible in the pull request. That helps teams spot unnecessary indexes or overly broad ALL projections before deploy, rather than discovering a quadrupled write bill after the fact.

What to do next

Understand what each index adds before you create it. C3X prices DynamoDB tables and GSIs from Terraform against a live resource catalog. Start with the quickstart.