Amazon DynamoDB stores items in tables and bills each table for the reads and writes it serves and the data it keeps: per request unit in on-demand mode, or per capacity unit and hour when you provision the throughput. In Paris, provisioned capacity costs less than on-demand once a table uses 28.9% of it on average, computed, and on-demand prices halved on November 1, 2024, so a price copied from before then is twice today's. The requests and the storage are rarely the whole bill: every global secondary index is written again on each change it carries, and backups, replicas and streams bill on lines of their own. This article explains how DynamoDB works under the hood, how Amazon DynamoDB pricing works line by line, when on-demand or provisioned capacity costs less, and the ways AWS documents to reduce DynamoDB costs, priced with the list prices of the Paris Region (eu-west-3). Four architectures show what the levers do to whole monthly bills, and the cost section opens with an index of the levers, in the order to work through them.
Prices in this article are AWS list prices for the EU (Paris) Region, in USD before tax, from the AWS Price List. The offer files and their publication dates are listed in the Sources section, and each table repeats the dates of its own prices. DynamoDB bills on-demand reads and writes in request units, by the million, and provisioned throughput in capacity units, by the hour; a month is 730 hours. Monthly amounts, totals, percentages and break-evens are computed from these prices. The free tier is left out.
What Amazon DynamoDB is
In AWS's words, "Amazon DynamoDB is a serverless, fully managed, distributed NoSQL database with single-digit millisecond performance at any scale." There is no server to size: "With DynamoDB, you don't need to provision any servers, or patch, manage, install, maintain, or operate any software", and "It has no versions (major, minor, or patch), and there are no maintenance windows." In on-demand mode a table "scales down to zero so you don't pay for throughput when your table doesn't have traffic and there are no cold starts".
It is not a relational database, the same guide warns: "Unlike relational databases, DynamoDB doesn't support a JOIN operator. We recommend that you denormalize your data model to reduce database round trips and processing power needed to answer queries." The pricing page sums up what it bills: "DynamoDB charges for reading, writing, and storing data in tables, along with any additional features you choose to enable." Two choices set the price of every table: the capacity mode, and the table class, DynamoDB Standard or DynamoDB Standard-Infrequent Access (Standard-IA):
The two choices that set a DynamoDB table's price
| Option | What it bills |
|---|---|
| On-demand capacity | Each read and write, in request units, by the million |
| Provisioned capacity | The reads and writes a second you set, in capacity units, by the hour, used or not |
| Standard table class | The default: lower prices for reads and writes |
| Standard-IA table class | Lower storage prices, higher prices for reads and writes |
The rest of the bill is features you turn on: point-in-time recovery and on-demand backups, global tables, DynamoDB Streams, Amazon Kinesis Data Streams for DynamoDB, Amazon DynamoDB Accelerator (DAX), vector search, exports and imports. Each has its own line, priced in How DynamoDB pricing works.
How DynamoDB works under the hood
AWS documents DynamoDB at the level of the table, its keys and partitions, its indexes, the units its requests consume and the capacity modes. Each is a line of the bill, or a multiplier on one: an item's size sets the units of each request, an index adds writes, a replica adds them again in another Region. How the storage nodes behind a partition are built is not in the pages this article cites, and is left out.
Tables, items and primary keys
"A table is a collection of items, and each item is a collection of attributes", and "DynamoDB uses primary keys to uniquely identify each item in a table." Only the key is declared: beyond it, "neither the attributes nor their data types need to be defined beforehand." A primary key takes one of two forms:
The two kinds of DynamoDB primary key, from the core components guide
| Primary key | Items per partition key value | Stored |
|---|---|---|
| Partition key alone | One: "no two items can have the same partition key value" | Where the hash of the key sends it |
| Partition key and sort key | Many, each with its own sort key value | Together, "in sorted order by sort key value" |
Either way, in the same guide's words, "DynamoDB uses the partition key's value as input to an internal hash function. The output from the hash function determines the partition (physical storage internal to DynamoDB) in which the item will be stored." An item has a size limit: "Amazon DynamoDB limits the size of each item that you store in a table to 400 KB".
Partitions, and the ceiling of each
"A partition is an allocation of storage for a table, backed by solid state drives (SSDs) and automatically replicated across multiple Availability Zones within an AWS Region", and "Partition management is handled entirely by DynamoDB". DynamoDB adds partitions when a table's provisioned throughput grows beyond what its partitions support, or when one fills up. The items that share a partition key stay together: "The set of items which have the same value of partition key is called an item collection."
- A request carries the item's primary key: a partition key alone, or a partition key and a sort key, here PK A and SK 2.
- The partition key's value goes into an internal hash function, whose output picks the partition: storage internal to DynamoDB, replicated across Availability Zones.
- Items with the same partition key value are stored together, sorted by sort key value: an item collection, here the two items of PK A.
- Every partition is designed to deliver up to 3,000 read units and 1,000 write units a second, for on-demand mode and provisioned capacity alike.
A partition has a ceiling, the same in both capacity modes: "Every partition in a DynamoDB table is designed to deliver a maximum capacity of 3,000 read units per second and 1,000 write units per second". Large items reach it sooner: "if the table has an item size of 20 KB, a single consistent read operation will consume 5 read units. This means you can concurrently drive 600 consistent read operations per second on that single item before reaching the partition limits."
It follows that a partition key with few distinct values, or one value that takes most of the traffic, throttles at its partition's ceiling while the table's other partitions sit idle: a hot key, as the DAX guide calls it below. The partitions guide gives the rule against it: "We recommend that you choose a partition key that can have a large number of distinct values relative to the number of items in the table."
Request units: what an item's size costs
Every read and write is counted in units, and the item's size, rounded up, sets how many. On-demand, a read is counted in read request units (RRUs) and a write in write request units (WRUs), and the pricing page gives their sizes: "RRUs are consumed in 4 KB increments", "Eventually consistent reads require one-half RRUs per 4 KB or part thereof. Strongly consistent reads consume one RRU per 4 KB or part thereof. Transactional reads requires two RRUs per 4 KB or part thereof", and "WRUs are consumed in 1 KB increments. Standard writes require 1 WRU per 1 KB or part thereof. Transactional writes require 2 WRUs per 1 KB or part thereof."
Provisioned capacity counts the same way, per second, in read capacity units (RCUs) and write capacity units (WCUs). AWS's example: "an eventually consistent read of a 10 KB item requires 1.5 RRUs (half RRU x 3)", and "a write request of a 10 KB item requires 10 WRUs". Applied to four item sizes:
Request units of one request, by item size: reads round up to 4 KB, writes to 1 KB (the 10 KB column is AWS's example)
| Request | 1 KB | 3.5 KB | 10 KB | 20 KB |
|---|---|---|---|---|
| Read, eventually consistent | 0.5 | 0.5 | 1.5 | 2.5 |
| Read, strongly consistent | 1 | 1 | 3 | 5 |
| Read, transactional | 2 | 2 | 6 | 10 |
| Write | 1 | 4 | 10 | 20 |
| Write, transactional | 2 | 8 | 20 | 40 |
A write costs more than a read on both counts: its unit covers a quarter of the size, and a write request unit costs $0.7423 per million in Paris against $0.1487 for a read request unit. A million writes of a 10 KB item cost $7.42, a million strongly consistent reads of it $0.45, computed.
A Scan pays for every item it reads, whatever it returns: Query instead of Scan prices one.
Secondary indexes: copies that are written too
A secondary index lets a table answer a second question. The core components guide defines a global secondary index (GSI) as "An index with a partition key and sort key that can be different from those on the table", a local secondary index (LSI) as "An index that has the same partition key as the table, but a different sort key", and "Each table in DynamoDB has a quota of 20 global secondary indexes (default quota) and 5 local secondary indexes."
A global secondary index is a table of its own, in its own partitions: "The data in a global secondary index is stored separately from the data in its base table, but index partitions behave in much the same way as table partitions" (partitions). A local one lives with the table: "When an item in a table is added, updated, or deleted, updating the local secondary indexes consumes provisioned write capacity units for the table", and "For tables with local secondary indexes, there is a 10 GB size limit per partition key value."
DynamoDB keeps a global secondary index up to date, and the GSI guide bills each update: "The total provisioned throughput cost for a write consists of the sum of write capacity units consumed by writing to the base table and those consumed by updating the global secondary indexes." What a change to the base table costs an index depends on what changes:
What one write to the base table costs a global secondary index, from the GSI guide
| The write to the base table | Writes in the index |
|---|---|
| Adds an item that defines the indexed attribute, or defines it on an existing item | One |
| Changes the value of an indexed key attribute | Two: a delete and a put |
| Deletes the indexed attribute of an item in the index | One |
| Changes only attributes projected into the index | One |
| Changes only attributes neither indexed nor projected | None |
| Concerns an item absent from the index before and after | None |
Each of those writes is counted at the index entry's size, from 1 KB, the same guide adds: "Larger index entries require additional write capacity units." So the projection, the attributes an index copies, sets its price. "KEYS_ONLY" keeps the keys and "results in the smallest possible secondary index", "INCLUDE" adds the attributes you name, and "ALL" copies the whole item. The guidelines for secondary indexes say what ALL costs:
Projecting all attributes eliminates the need for table fetches, but in most cases, it doubles your costs for storage and write activity.
This is what other guides call write amplification. For a 2 KB item, an index with ALL projection costs as much per write as the table itself, a KEYS_ONLY index one unit, and an index whose key the item does not carry nothing:
- A write that changes what an index carries costs a write in that index too: the write's cost is the sum of the table's write units and each affected index's, here 5 against 2.
- ALL projection copies the whole item: its write costs as many units as the table's, 2 WRU for this item.
- KEYS_ONLY keeps only the key attributes: its small entry still rounds up to 1 KB, so 1 WRU.
- If the item is not in the index before or after the write, its key attribute absent as in a sparse index, the index costs nothing.
An index can also stop the table, the GSI guide warns: "For a table write to succeed, the provisioned throughput settings for the table and all of its global secondary indexes must have enough write capacity to accommodate the write. Otherwise, the write to the table is throttled." Reading an index has its own rule: "Both tables and LSIs provide two read consistency options: eventually consistent (default) and strongly consistent reads. All reads from GSIs and streams are eventually consistent." So a global secondary index's queries cost half a unit per 4 KB: the GSI guide's example, a query that matches eight items of 2,000 bytes, rounds 16,000 bytes up to 16 KB and costs "0.5 × (16 KB / 4 KB), or 2 read capacity units".
Capacity modes: per request or per unit-hour
The capacity mode decides what you pay for. "On-demand mode is the default and recommended throughput option for most DynamoDB workloads", says the Serverless Applications Lens; in provisioned mode, "you must specify the number of reads and writes per second that you require for your application. You'll be charged based on the hourly read and write capacity you have provisioned, not how much of that provisioned capacity you actually consumed." On-demand absorbs growth up to a point: "New on-demand tables will be able to sustain up to 4,000 writes per second and 12,000 reads per second", and "On-demand capacity mode instantly accommodates up to double the previous peak traffic on a table", but "throttling can occur if you exceed double your previous peak within 30 minutes."
- You set
- Nothing: the table follows its traffic
- Billed
- $0.7423 per million write request units, $0.1487 per million read request units
- Growth
- Up to double the previous peak, at once; more within 30 minutes can throttle
- While idle
- Nothing for throughput
- You set
- Reads and writes a second, or a range for auto scaling
- Billed
- $0.000772 per WCU-hour, $0.0001544 per RCU-hour, used or not
- Growth
- Scheduled actions, or target tracking after two minutes above its target
- While idle
- The capacity provisioned
What differs: a price per request unit, nothing while idle, against a price per unit of capacity, every hour it is provisioned.
Provisioned capacity can follow the traffic: "Amazon DynamoDB auto scaling uses the AWS Application Auto Scaling service to dynamically adjust provisioned throughput capacity on your behalf, in response to actual traffic patterns", and "If you use the AWS Management Console to create a table or a global secondary index, DynamoDB auto scaling is enabled by default." Target tracking reacts in minutes, not seconds: "Auto scaling triggers when your consumed capacity breaches the configured target utilization for two consecutive minutes", and "a scale down event can occur when 15 consecutive data points are lower than the target utilization." For a peak at a known time, a schedule acts before it: "You can scale DynamoDB tables and global secondary indexes using target tracking scaling policies and scheduled scaling".
A table can also change modes: on August 14, 2025, the document history records, DynamoDB raised the limit for switching a table from provisioned to on-demand "from once every 24 hours to four times every 24 hours". Which mode costs less is a question of utilization: in Paris, provisioned capacity costs less above 28.9%, computed (On-demand or provisioned?).
Streams, change data capture and DAX
Three features sit around a table. "DynamoDB Streams captures a time-ordered sequence of item-level modifications in any DynamoDB table and stores this information in a log for up to 24 hours"; AWS Lambda functions read it through an event source mapping, the subject of the Lambda article's batching lever. Amazon Kinesis Data Streams captures the same changes separately, from the table: "Kinesis Data Streams captures item-level modifications in any DynamoDB table and replicates them to a Kinesis data stream", and "Using Kinesis data streams for DynamoDB is subject to both Kinesis Data Streams pricing for the data stream and DynamoDB pricing for the source table." On the read side, Amazon DynamoDB Accelerator (DAX) is a cache: "DynamoDB Accelerator (DAX) delivers fast response times for accessing eventually consistent data", and it serves those reads only.
- DynamoDB Streams captures a time-ordered log of item-level changes, kept for up to 24 hours.
- A Lambda Event Function polling the stream is not charged for its GetRecords calls, unless it runs on Lambda Managed Instances.
- Amazon Kinesis Data Streams captures the table's item-level changes itself, a mechanism separate from DynamoDB Streams, billed in change data capture units.
- DAX serves eventually consistent reads in microseconds; it cannot serve a strongly consistent read, the same limit a global secondary index has.
DAX's guide names the hot key as one of its cases: "To mitigate the impacts of a "hot" key and a non-uniform traffic distribution, you could offload the read activity to a DAX cache". Its nodes bill by the hour, priced in DAX in Paris.
Global tables: every replica bills its writes
"Amazon DynamoDB global tables is a fully managed, multi-Region, and multi-active database feature". Each replica pays for the writes it receives, and for its own indexes: "Replicated write (rWCU or rWRU) charges are incurred in every Region containing a replica table for the global table", and "Updates to Global Secondary Indexes (GSIs) are billed using the same units as single-Region DynamoDB tables, even if the base table for the GSI is a replica table." The replication itself carries no transfer fee: "DynamoDB does not charge cross-Region data transfer fees for replicating data between the Regions of a global table." The pricing page's own worked example counts four write units for each 1 KB written to two replicas with one index each:
Write units billed for each 1 KB item written, with one global secondary index (computed; two replicas is AWS's example)
| Table | Base table writes | Index writes | In all |
|---|---|---|---|
| One Region | 1 | 1 | 2 |
| Two replicas | 2 | 2 | 4 |
| Three replicas | 3 | 3 | 6 |
The rates are each Region's own, the count grows with every replica, and no projection narrows the replicated writes of the base table.
Time to live
Time to live (TTL) deletes items for you: "DynamoDB automatically deletes expired items within a few days of their expiration time, without consuming write throughput." In a global table, only the first delete is free: "The initial TTL delete does not consume Write Capacity Units (WCU) in the region in which the TTL expiry occurs. However, the replicated TTL delete to the replica table(s) consumes a replicated Write Capacity Unit when using provisioned capacity, or Replicated Write Unit when using on-demand capacity mode, in each of the replica regions".
In short: Under the hood, a DynamoDB bill is units: an item's size sets the units of each request, each index and each replica adds its own, and the capacity mode decides whether you pay for the units used or for the units kept ready.
What DynamoDB is used for
AWS lists the workloads it sees on DynamoDB in What is Amazon DynamoDB? and on the pricing page. What drives each one's bill is this article's reading of the mechanisms above, not AWS's words:
Workloads AWS names for DynamoDB, in its words, and what drives their bills
| Workload | What AWS says | What drives its bill |
|---|---|---|
| Financial services | "live trading and routing, loan management, token generation, and transaction ledgers" | Transactions, at twice the request units |
| Gaming | "all parts of game platforms, for example, game state, player data, session history, and leaderboards" | Writes, and hot keys on popular items |
| Streaming and media | "a metadata index for content, content management service, or to serve near real-time sports statistics" | Reads, which eventually consistent reads or DAX lighten |
| Retrieval-augmented generation and agents | "build retrieval-augmented generation (RAG) and agentic AI applications without a separate vector database" | Vector writes and searches, by the GB |
The vector search of the last row stores embeddings with the items: "With vector indexes, you can store vector embeddings alongside your operational data in DynamoDB and perform similarity searches without needing a separate vector database", and "Vector indexes use on-demand capacity mode only, and they require a table that also uses on-demand capacity mode".
DynamoDB or a relational database?
Is DynamoDB cheaper than RDS? The two bill different things. Amazon Relational Database Service (Amazon RDS) bills a DB instance by the hour, busy or idle, and its storage by the GB-month, as the RDS article prices them; DynamoDB bills each request unit, or the capacity provisioned for them, and the GB stored, with no server to size. AWS frames the choice by the data model, not the price: "As a NoSQL database, DynamoDB is purpose-built to deliver improved performance, scalability, manageability, and flexibility compared to traditional relational databases", and "As a NoSQL database, DynamoDB provides strong read consistency and ACID transactions to build enterprise-grade applications" (What is Amazon DynamoDB?). It follows that the cheaper one depends on the workload: a database that is busy every hour suits an instance paid by the hour, and a table with idle hours suits a price per request. This article prices DynamoDB only; the RDS article prices instances, storage and their commitments.
In short: Whether DynamoDB costs less than a relational database is not a price-list question: an instance suits a database busy every hour, a price per request a table with idle hours.
How DynamoDB pricing works
What a DynamoDB bill is made of
The pricing page prices a table's reads, writes and storage, and each feature on its own line:
The lines of a DynamoDB bill, and what each charges for
| Line | Billed by | Charged for |
|---|---|---|
| Reads and writes, on-demand | The million request units | Each request, at its units: item size, consistency, transactions |
| Reads and writes, provisioned | The capacity unit-hour | The capacity set each hour, used or not |
| Storage | The GB-month, by table class | Items and their indexes |
| Indexes | No line of their own | Their writes and storage, on the table's lines |
| Backups and restores | The GB-month, the GB restored | Point-in-time recovery, on-demand backups, restores |
| Global tables | The replicated write unit | Each write, in every replica's Region |
| Streams and change data capture | The million units | Stream reads; changes sent to Kinesis Data Streams |
| DAX | The node-hour | The cache's nodes, on a service line of their own |
| Vector search, exports, imports | The GB | Data written, searched, exported or imported |
Indexes have no line, so they hide in the others. One table's month, with an index that projects all attributes and without it:
The table and its index Illustrative
| Line | A month |
|---|---|
| Storage | $41.61 |
| Storage: 50 GB, and as much in the index100 GB × $0.29715 /GB-mo | $29.72 |
| Point-in-time recovery: the table's 50 GB50 GB × $0.23772 /GB-mo | $11.89 |
| Other | $44.57 |
| Reads: 100 million read request units100 M request units × $0.1487 /M RU | $14.87 |
| Writes to the table: 20 million20 M request units × $0.7423 /M RU | $14.85 |
| Writes to the index: the same 20 million20 M request units × $0.7423 /M RU | $14.85 |
| A month, computed | $86.18 |
The table alone Illustrative
| Line | A month |
|---|---|
| Storage | $26.75 |
| Storage: 50 GB50 GB × $0.29715 /GB-mo | $14.86 |
| Point-in-time recovery: the table's 50 GB50 GB × $0.23772 /GB-mo | $11.89 |
| Other | $29.72 |
| Reads: 100 million read request units100 M request units × $0.1487 /M RU | $14.87 |
| Writes to the table: 20 million20 M request units × $0.7423 /M RU | $14.85 |
| A month, computed | $56.47 |
Without the index costs $29.71 a month less than with an ALL-projection index (34.5% less), computed.
USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.
The index doubles the writes and the storage, as AWS warns. Point-in-time recovery counts the table and its local secondary indexes, not a global one (Backups and restores in Paris). Not counted: on-demand backups, Streams, data transfer and the free tier.
On-demand request units in Paris
DynamoDB on-demand request units in Paris (eu-west-3)
| Item | List price, per million request units |
|---|---|
| Standard table class | |
| Write request units | $0.7423 |
| Read request units | $0.1487 |
| Standard-IA table class | |
| Write request units | $0.9279 |
| Read request units | $0.1856 |
USD, before tax. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026.
These are not the prices many pricing guides still print. The AWS Price List dates the change: its Paris offer of October 22, 2024, in effect that month, priced a million write request units at $1.4846 and a million read request units at $0.2969; the version in effect from November 1, 2024, published on January 13, 2025, prices them at $0.7423 and $0.1487, today's rates:
The on-demand price cut of November 1, 2024
50.0% lessper million write request units in Paris, from the October 2024 offer to the version in effect from November 1, 2024; provisioned prices did not move, so the break-even doubled.
Computed from the AWS Price List · eu-west-3 · Oct 22, 2024 and Jan 13, 2025
Reads cost 49.9% less than before, computed. It follows that the break-even of the two modes doubled, from 14.4% to 28.9% for writes, computed: a table moved to provisioned capacity before November 2024, at a utilization between the two, now costs more than it would on-demand. And an on-demand price copied from before that date is twice today's: check the date of a guide before its numbers.
Provisioned capacity units in Paris
DynamoDB provisioned capacity units in Paris (eu-west-3), per unit
| Item | List price, per hour | A month (730 h), computed |
|---|---|---|
| Standard table class | ||
| Write capacity unit (WCU)One write a second, up to 1 KB | $0.000772 | $0.56 |
| Read capacity unit (RCU)One strongly consistent read a second, up to 4 KB | $0.0001544 | $0.11 |
| Standard-IA table class | ||
| Write capacity unit (WCU) | $0.000965 | $0.70 |
| Read capacity unit (RCU) | $0.000193 | $0.14 |
USD, before tax. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026.
A capacity unit bills every hour it is set, whatever passes through it. The pages this article cites name no charge for auto scaling itself: what it costs is the capacity it provisions. One capacity unit serves at most one request of its size a second: a WCU kept all month costs $0.56 and can serve 2,628,000 writes, which on-demand would bill $1.95, computed. That gap is the break-even of the two modes. Warm throughput, the reads and writes a table can take at once, is free until you raise it: pre-warming is "a one-time fee at the regional rate of one read capacity unit (RCU) for every unit increase in read warm throughput and one write capacity unit (WCU) for every unit increase in write warm throughput" (pricing page; warm throughput).
Storage and the free tier
DynamoDB table storage in Paris (eu-west-3), per GB-month
| Item | List price, per GB-month |
|---|---|
| Standard table classItems, their indexes, vector indexes | $0.29715 |
| Standard-IA table classThe same, at the Standard-IA price | $0.11886 |
USD, before tax. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026.
Storage on Standard-IA costs 60.0% less than on Standard, computed, and the class covers the whole table: "All secondary indexes associated with the table use the same table class". Vector indexes add no storage line: the pricing page charges their data "per GB-month, the same way DynamoDB charges for table storage". The free tier, not deducted here, "uses provisioned capacity and the DynamoDB Standard table class": 25 WCUs, 25 RCUs and 25 GB of storage a month, among others, per Region and payer account.
Backups and restores in Paris
Backups come in two kinds. With point-in-time recovery (PITR), "DynamoDB takes continuous backups for the preceding 1 to 35 days" and "charges for PITR based on the size of each DynamoDB table, including table data and local secondary indexes" (pricing page). On-demand backups are full copies you take, billed on the same table size, and AWS Backup can schedule, copy and tier them:
DynamoDB backups and restores in Paris (eu-west-3)
| Item | List price | Unit |
|---|---|---|
| Point-in-time recoveryPer GB-month of the table and its local secondary indexes | $0.23772 | per GB-month |
| On-demand backupsPer GB-month of backup storage | $0.11886 | per GB-month |
| Restoring a tablePer GB restored, from either kind | $0.17829 | per GB |
USD, before tax. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026.
In Paris, a GB under point-in-time recovery costs twice a GB of on-demand backup, computed from the two prices. Two rules of the backup billing guide shape the month: "DynamoDB on-demand backups are billed monthly", and "On the 1st of every month, any existing DynamoDB backups will have usage charges for the entire month applied." A deleted table leaves one backup for free, says the pricing page: "DynamoDB automatically creates a backup snapshot called a system backup and retains it for up to 35 days (at no additional cost)." A restore from a backup creates a new table, and "You restore a table without consuming any provisioned throughput on the table"; "Restores can be faster and more cost-efficient if you exclude some or all indexes from being created on the restored table."
Global tables in Paris and Frankfurt
A global table's replica in Paris (eu-west-3) and in Frankfurt (eu-central-1)
| Item | List price | Unit |
|---|---|---|
| Paris | ||
| Replicated write request unitsOn-demand, per million | $0.7423 | per million request units |
| Replicated write capacity unitsProvisioned, per unit-hour | $0.000772 | per hour |
| Frankfurt | ||
| Write request unitsOn-demand, per million: a replica's writes and its indexes' | $0.7625 | per million request units |
| Table storageStandard table class, per GB-month | $0.306 | per GB-month |
USD, before tax. AWS Price List, eu-west-3 and eu-central-1, offer file published September 11, 2026, fetched October 16, 2026.
A replicated write costs what a single-Region write costs, $0.7423 per million in Paris: "Replicated write units (rWCUs and rWRUs) are priced the same as single-Region write units (WCUs and WRUs)". The global table multiplies the count, not the price: each Region bills the writes at its own rates, Frankfurt's 2.7% more than Paris's for a write, computed, and the storage of its replica at its own price.
Streams and change data capture in Paris
DynamoDB Streams and change data capture in Paris (eu-west-3), per million
| Item | List price | Unit |
|---|---|---|
| DynamoDB Streams read request unitsBeyond the free tier | $0.237 | per million request units |
| Change data capture unitsFor Amazon Kinesis Data Streams, plus Kinesis's own charges | $0.11877 | per million units |
USD, before tax. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026.
The commonest reader of a stream pays nothing on this line: "You are not charged for GetRecords API calls invoked through DynamoDB triggers on AWS Lambda, unless the functions are running on Lambda Managed Instances, in which case standard Streams charges will apply. Also, you are not charged for GetRecords API calls invoked by DynamoDB global tables" (pricing page). It follows that a table whose stream feeds an AWS Lambda Event Function shows no Streams line at all: the function's requests and duration bill on the Lambda side, as the Lambda article prices them.
DAX in Paris
Amazon DynamoDB Accelerator (DAX) nodes in Paris (eu-west-3), per node
| Item | List price, per hour | A month (730 h), computed |
|---|---|---|
| dax.t3.smallThe smallest node type | $0.044 | $32.12 |
| dax.r7i.largeCurrent generation, memory-optimized | $0.299 | $218.27 |
USD, before tax. AWS Price List, eu-west-3, offer file published October 9, 2026, fetched October 16, 2026.
DAX bills its nodes by the hour, "from the time a node is launched until it is terminated" (billing guide), on a service line of its own, and nothing per read. A cluster of three dax.t3.small nodes costs $96.36 a month: the price of 855 provisioned RCU kept all month or, on-demand, of 648 million read request units, 493 eventually consistent reads of 4 KB or less a second on average. Three dax.r7i.large nodes cost $654.81, the price of 5,810 RCU, all computed. Three nodes is this article's illustration, not an AWS minimum. A cluster pays for itself only if the reads it serves let the table give up more than that.
Vector search, exports and imports in Paris
DynamoDB vector search, exports and imports in Paris (eu-west-3), per GB
| Item | List price, per GB |
|---|---|
| Vector search, Standard | |
| Vector writesData written into a vector index | $0.6176 |
| Vector searchesData processed and returned | $0.00238 |
| Vector search, Standard-IA | |
| Vector writes | $0.77325 |
| Vector searches | $0.00299 |
| Amazon S3 | |
| Full exportThe table and its local secondary indexes | $0.11886 |
| Incremental exportData processed from PITR backups | $0.11886 |
| ImportUncompressed source data | $0.17829 |
USD, before tax. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026.
A vector search does not read the whole index: "The data processed grows logarithmically with the number of items in your index, not in proportion to it", and "Vector search is billed per byte with a 1 KB minimum charge for both writes and searches." (pricing page) Exports read the PITR backups, not the table, and land in Amazon S3, at S3's storage prices. An import from Amazon S3 creates a new table and spares its capacity: "Import from Amazon S3 does not consume write capacity on the new table, so you do not need to provision any extra capacity for importing data into DynamoDB."
Data transfer
Within a Region, traffic is free: "DynamoDB does not charge for inbound data transfer, and it does not charge for data transferred between DynamoDB and other AWS services within the same AWS Region", while "Data transferred across AWS Regions (such as between DynamoDB in the US East [N. Virginia] Region and Amazon EC2 in the EU [Ireland] Region) is charged on both sides of the transfer" (pricing page). The path to the table can still bill. From a VPC's private subnets, a gateway endpoint for DynamoDB avoids the NAT gateway: "With a gateway endpoint, you can access DynamoDB from your VPC, without requiring an internet gateway or NAT device for your VPC, and with no additional cost." The NAT gateway article prices the path through a NAT gateway against it.
Reading the DynamoDB lines of a bill
"Each usage type begins with an optional Region prefix", EUW3- in Paris, and the Standard-IA lines add IA-. Among them, from the Paris price list:
DynamoDB usage types on a bill in Paris
| Usage type | What it counts |
|---|---|
EUW3-WriteRequestUnits |
On-demand writes, Standard |
EUW3-ReadRequestUnits |
On-demand reads, Standard |
EUW3-WriteCapacityUnit-Hrs |
Provisioned writes, Standard, reserved hours included |
EUW3-ReadCapacityUnit-Hrs |
Provisioned reads, Standard, reserved hours included |
EUW3-TimedStorage-ByteHrs |
Table and index storage, Standard |
EUW3-TimedPITRStorage-ByteHrs |
Point-in-time recovery |
EUW3-TimedBackupStorage-ByteHrs |
On-demand backups |
EUW3-ReplWriteRequestUnits |
Replicated writes, on-demand |
EUW3-ReplWriteCapacityUnit-Hrs |
Replicated writes, provisioned |
EUW3-Streams-Requests |
Stream reads |
EUW3-ChangeDataCaptureUnits-Kinesis |
Changes sent to Kinesis |
EUW3-IA-… |
The same lines on the Standard-IA table class |
EUW3-NodeUsage:dax.t3.small |
DAX nodes, by type, under the AmazonDAX product code |
Reserved capacity shows twice: its hours as zero-cost ReadCapacityUnit-Hrs or WriteCapacityUnit-Hrs lines, and its charge on a HeavyUsage:dynamodb.read or HeavyUsage:dynamodb.write line, "a one-time up-front charge and a monthly charge at the start of each month covering all the discounted committed RCU-hours during the month." To see a table rather than a Region, the AWS Cost and Usage Report has to break usage down by resource: its lineitem/ResourceId is "Available if the CUR includes a breakdown by resource ID."
In short: A DynamoDB bill is request units or capacity hours, storage by class, and a line for each feature turned on; in Paris, on-demand prices halved on November 1, 2024, and the break-even of the two modes doubled with them.
Choosing a DynamoDB capacity mode and table class
Three decisions set most of a table's price, and the Paris prices answer each: provisioned capacity costs less than on-demand above 28.9% average utilization, a 1-year reservation takes about half off the provisioned capacity a table uses every hour, and Standard-IA costs less once storage passes 41.7% of a table's throughput cost, all computed. Database Savings Plans, which the price list does not price, come after the reservation.
On-demand or provisioned?
Does on-demand or provisioned capacity cost less for the same traffic? A provisioned unit costs the same whether it is busy or idle, an on-demand unit only when used, so the answer is a utilization: the average share of its capacity a provisioned table actually uses. Above it, provisioned costs less.
Computed from Paris list prices
28.9%the average utilization above which provisioned capacity costs less than on-demand for the same writes, on the Standard table class.
Computed from the AWS Price List · eu-west-3 · Sep 11, 2026
At utilization u, a provisioned unit costs its hourly price, and the same traffic on-demand costs u × 3,600 request units an hour: on-demand costs less only while u stays below the hourly price divided by 3,600 request units' price. The four break-evens differ by a tenth of a point:
Break-even utilization of provisioned capacity against on-demand, in Paris (computed)
| Table class and request | Break-even, computed |
|---|---|
| Standard, writes | 28.9% |
| Standard, reads | 28.8% |
| Standard-IA, writes | 28.9% |
| Standard-IA, reads | 28.9% |
Computed from the AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026.
So on-demand is the expensive mode for a busy table: provisioned capacity used at 28.9% or more, averaged over the month, already costs less than on-demand, and a table busy every hour pays on-demand 3.46 times its provisioned price, which pattern 2 draws at every utilization from 10% to 100%. AWS's advice points the same way: provisioned capacity "may be better" for those who "Have existing applications with steady and predictable throughput patterns" or "Can forecast capacity requirements", and on-demand is "recommended in most scenarios", for workloads where "you do not want to manage capacity" (pricing page).
It follows that on-demand earns its price on tables idle most of the time, new tables whose traffic is not known yet, and bursts too fast for provisioned capacity to follow. A daily peak at a known time is not such traffic: pattern 1 prices one, with a scheduled action. The break-even is far lower than for AWS Lambda, whose provisioned concurrency must be almost always busy to cost less than on demand, as the Lambda article computes.
Is reserved capacity worth it?
Reserved capacity is a commitment to provisioned capacity, and the pricing page sets its scope: "Reserved provisioned capacity is available for single-Region, provisioned read and write capacity units (RCU and WCU) on DynamoDB tables including global and local secondary indexes. You cannot purchase reserved provisioned capacity for replicated WCUs (rWCUs) or for DynamoDB Standard-Infrequent Access (DynamoDB Standard-IA) table class." It is bought by the hundred units, "The smallest reserved provisioned capacity offering is 100 capacity units (reads or writes)", and billed whether used or not: "If you use less than your reserved provisioned capacity, you will still be charged each month for that minimum amount of provisioned throughput capacity."
DynamoDB reserved capacity in Paris (eu-west-3): 1 year, per unit
| Item | List price | Unit |
|---|---|---|
| Write capacity | ||
| Reserved WCU, recurringPer WCU-hour, every hour of the term | $0.000153 | per hour |
| Reserved WCU, upfrontOnce, per WCU reserved | $1.78 | upfront, per reservation |
| Read capacity | ||
| Reserved RCU, recurringPer RCU-hour, every hour of the term | $0.000031 | per hour |
| Reserved RCU, upfrontOnce, per RCU reserved | $0.356 | upfront, per reservation |
USD, before tax. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026.
With its upfront fee spread over the twelve months, a reserved WCU costs 53.9% less than a provisioned one and a reserved RCU 53.6% less, computed: the pricing page's "up to 54% (one-year term)" holds in Paris. It also says "up to 77% (three-year term)", but the Paris price list carries the 1-year term only, so this article prices no three-year reservation. Reserved capacity is worth it for the capacity a table uses every hour of the year, once the other levers have shrunk it; pattern 2 prices it on a steady table.
Do Database Savings Plans cover DynamoDB?
Yes, both modes, according to the pricing page's comparison: "Up to 18% cost savings on on-demand throughput" and "Up to 12% cost savings on provisioned throughput", for "1 year", with the "Flexibility of consuming committed spend across AWS Database services and Regions", where reserved capacity is "Available only for provisioned capacity, single-Region, and Standard table class". The two do not add up on the same usage: "for the same workload, you may not combine discounts from Database Savings Plans and reserved provisioned capacity. If you have both, reserved provisioned capacity is applied first, after which any remaining provisioned capacity is eligible for Database Savings Plans coverage." No Database Savings Plans rate for DynamoDB was found in the AWS Price List, so the plan is not priced here; the RDS article prices it for Amazon RDS.
Standard or Standard-IA?
AWS gives a rule of thumb: "When storage exceeds 50% of the throughput (reads and writes) cost of a table using the DynamoDB Standard table class, the DynamoDB Standard-IA table class can help you reduce your total table cost". The Paris prices trade one for the other:
Standard-IA against Standard in Paris: what the class changes (computed)
| Price | Standard | Standard-IA | Standard-IA against Standard |
|---|---|---|---|
| Storage, per GB-month | $0.29715 | $0.11886 | 60.0% less |
| Write request units, per million | $0.7423 | $0.9279 | 25.0% more |
| Read request units, per million | $0.1487 | $0.1856 | 24.8% more |
| WCU, per hour | $0.000772 | $0.000965 | 25.0% more |
| RCU, per hour | $0.0001544 | $0.000193 | 25.0% more |
USD, before tax. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026.
With storage at that discount and throughput at that premium, Standard-IA costs less once a Standard table's storage line exceeds 41.7% of its throughput line, computed from the Paris prices: a little sooner than AWS's round 50%. The switch is a setting: "The choice of a table class is not permanent", and "Switching between the DynamoDB Standard and DynamoDB Standard-IA table classes does not require changing your application code" (table class considerations). Pattern 3 prices it on a history table.
In short: In Paris, provisioned capacity costs less than on-demand above 28.9% average utilization, a 1-year reservation takes about half off what remains steady, and Standard-IA pays once storage passes 41.7% of a table's throughput cost, all computed from the same price list.
Architecture patterns around DynamoDB and what they cost
Four illustrative configurations in Paris, each priced before and after the levers of the next section, line by line from the AWS Price List: a public API's table with a daily peak, a steady table busy every hour, a history table whose storage outweighs its traffic, and a table whose indexes multiply its writes. None is a client case; every amount is computed, and each card lists its assumptions and what it leaves out.
Pattern 1 of 4 · Illustrative configuration
A spiky public API's table: on-demand, or provisioned with auto scaling
A public API's table in Paris serves a daily peak of 2 hours at 2,000 strongly consistent reads and 500 writes a second, and a 22-hour baseline of 100 reads and 25 writes a second, Standard table class: on-demand, then provisioned capacity with Application Auto Scaling at the default 70% target.
- On-demand: $0.1487 per million read request units, $0.7423 per million write request units. No capacity is sized; on-demand instantly accommodates up to double the previous peak.
- Provisioned: $0.0001544 per RCU-hour, $0.000772 per WCU-hour: 2,858 RCU and 715 WCU through the peak, 143 RCU and 36 WCU through the baseline.
- Application Auto Scaling: a scheduled action raises the minimum capacity to the peak's when it starts and lowers it when it ends; target tracking at 70% follows the baseline.
The peak takes 2 hours of every 24 and comes at a known time, so a scheduled action raises the capacity for it alone; target tracking alone, acting only after two minutes above its target, would throttle at the start of every peak, a step of 20 times the baseline. Provisioned for the peak all month without scaling, the same traffic costs more than either: on-demand costs 55.6% less than that static capacity, and the scheduled and auto-scaled capacity 81.7% less, computed. The static capacity is busy only 12.8% of the time on average, far below the break-even.
With the levers: $132.02 a month less (58.7% less), computed.
The bills line by line, the assumptions and the sources
A spiky public API's table: on-demand, or provisioned with auto scaling, before: On-demand Illustrative
On-demand capacity mode: 673.2 million reads and 168.3 million writes a month, priced per request.
| Line | A month |
|---|---|
| Other | $225.03 |
| On-demand reads, strongly consistent, 673.2 million a month673.2 M request units × $0.1487 /M RU | $100.10 |
| On-demand writes, 168.3 million a month168.3 M request units × $0.7423 /M RU | $124.93 |
| A month, computed | $225.03 |
A spiky public API's table: on-demand, or provisioned with auto scaling, with the levers: Provisioned: scheduled for the peak, auto-scaled at 70% Illustrative
Application Auto Scaling: a scheduled action holds 2,858 RCU and 715 WCU through the 60-hour peak, target tracking at 70% 143 RCU and 36 WCU through the 670-hour baseline.
| Line | A month |
|---|---|
| Other | $93.01 |
| Provisioned RCU at the peak, 60 h a month2,858 RCU × 60 h × $0.0001544 /h | $26.48 |
| Provisioned RCU at the baseline, 670 h a month143 RCU × 670 h × $0.0001544 /h | $14.79 |
| Provisioned WCU at the peak, 60 h a month715 WCU × 60 h × $0.000772 /h | $33.12 |
| Provisioned WCU at the baseline, 670 h a month36 WCU × 670 h × $0.000772 /h | $18.62 |
| A month, computed | $93.01 |
Provisioned capacity, sized to the peak, all month, no auto scaling: $507.20 a month, 125.4% more than before, computed.
Assumptions
- Illustrative configuration in Paris (eu-west-3), not a client case.
- 60 hours a month at the daily peak (2,000 strongly consistent reads and 500 writes a second), the remaining 670 hours at the baseline (100 reads and 25 writes a second): 673.2 million reads and 168.3 million writes a month. Items at or under their rounding unit (4 KB for reads, 1 KB for writes), so each request is one RRU/RCU or one WRU/WCU.
- The daily peak's timing is known (it repeats every day) and its size is stable month to month, so on-demand's own protection, instantly accommodating up to double the previous peak traffic, is never tested by this pattern.
- A scheduled action of Application Auto Scaling raises the minimum capacity to the peak's when the peak starts and lowers it when the peak ends; target tracking at 70.0% sets the baseline's. Target tracking alone acts only after two consecutive minutes above its target: at a step of 20 times the baseline, it would throttle at the start of every peak.
- Capacity is approximated as consumed ÷ 70.0%, rounded up, for the whole of each window; a scheduled action set a few minutes before the peak adds those minutes at the peak's capacity.
- No throttling in any variant: the scheduled capacity is in place when the peak starts. Standard table class throughout.
Not counted
- Storage (the same in every variant) and the free tier.
Sources
- DynamoDB on-demand capacity mode
- Managing throughput capacity automatically with DynamoDB auto scaling
- Best practices for designing and using partition keys effectively in DynamoDB
- Amazon DynamoDB pricing
USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.
Pattern 2 of 4 · Illustrative configuration
A steady high-throughput table: provisioned plus reserved capacity
A steady backend table in Paris runs 1,000 RCU and 500 WCU around the clock, Standard table class, strongly consistent reads, 1 KB writes: on-demand, provisioned with no commitment, then provisioned with a one-year reserved-capacity commitment.
- Reserved capacity commits to the steady baseline for a year: $0.000031 per RCU-hour and $0.000153 per WCU-hour, plus a one-time upfront fee of $0.356 per RCU and $1.78 per WCU.
- Available only for provisioned capacity, single-Region, Standard table class: Standard-IA tables and replicated (global-tables) write capacity cannot be reserved.
- Capacity above the reservation bills at $0.0001544 per RCU-hour and $0.000772 per WCU-hour; on-demand, the same traffic bills $0.1487 per million read request units and $0.7423 per million write request units.
Most of the saving is the capacity mode, the first step under the bill. Reserved for a year, the capacity then costs 53.8% less than with no commitment, for its mix of reads and writes, computed; its upfront fees, $1,246.00 in all, are paid once, at purchase, and spread over the term here. The last chart sets on-demand against that capacity at every utilization: busy every hour, this table sits far above the break-even.
With the levers: $1,183.84 a month less (86.7% less), computed.
The bills line by line, the assumptions and the sources
A steady high-throughput table: provisioned plus reserved capacity, before: On-demand Illustrative
The same sustained traffic on-demand: 2,628 million reads and 1,314 million writes a month.
| Line | A month |
|---|---|
| Other | $1,366.16 |
| On-demand reads, strongly consistent, 2,628 million a month2,628 M request units × $0.1487 /M RU | $390.78 |
| On-demand writes, 1,314 million a month1,314 M request units × $0.7423 /M RU | $975.38 |
| A month, computed | $1,366.16 |
A steady high-throughput table: provisioned plus reserved capacity, with the levers: Provisioned capacity, with a 1-year reserved-capacity commitment Illustrative
1,000 RCU and 500 WCU on the 1-year, Heavy Utilization reserved rate, the upfront fee spread over the term.
| Line | A month |
|---|---|
| Other | $182.32 |
| Reserved RCU, recurring rate, 1,000 RCU1,000 RCU × 730 h × $0.000031 /h | $22.63 |
| Upfront fee for 1,000 reserved RCU, spread over the 12-month term83.33 RCU (1,000 ÷ 12 months) × $0.356 upfront | $29.67 |
| Reserved WCU, recurring rate, 500 WCU500 WCU × 730 h × $0.000153 /h | $55.85 |
| Upfront fee for 500 reserved WCU, spread over the 12-month term41.67 WCU (500 ÷ 12 months) × $1.78 upfront | $74.17 |
| A month, computed | $182.32 |
Provisioned capacity, no commitment: $394.49 a month, 71.1% less than before, computed.
Assumptions
- Illustrative configuration in Paris (eu-west-3), not a client case.
- 1,000 RCU and 500 WCU, every hour of the month: 2,628 million reads and 1,314 million writes, the equivalent traffic on-demand. Standard table class (reserved capacity excludes Standard-IA entirely).
- The reservation covers the steady baseline exactly (1,000 RCU, 500 WCU): any capacity provisioned beyond it bills at the standard provisioned rate.
- The upfront fee is spread evenly over the 12 months of the term (an assumption of this pattern, not a method AWS states) and added to the recurring hourly rate, so the reserved total is a monthly equivalent; the whole fee is paid once, at purchase.
- The 1-year, Heavy Utilization rate is the only reserved-capacity term the AWS Price List carries for DynamoDB: the pricing page's 3-year term, "up to 77%" in AWS's words, has no rate there and is not priced here.
Not counted
- Storage (the same in every variant) and the free tier.
Sources
USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.
Pattern 3 of 4 · Illustrative configuration
A storage-heavy history table: Standard, or Standard-IA with TTL
An order-history/audit-log table in Paris accumulates data: a small, on-demand request volume whose storage dominates the bill, the shape AWS's own table-class guidance describes: Standard with no TTL, then Standard-IA with TTL capping storage growth.
- Before: Standard storage at $0.29715 per GB-month, unbounded without a TTL attribute.
- After: Standard-IA storage at $0.11886 per GB-month, lower per GB; a TTL attribute expires old items within a few days of their timestamp, at no write cost in this Region, capping storage.
Each lever works on its own: the table class alone takes the bill to $240.51 (59.7% less), TTL alone to $418.23 (29.9% less), computed. Reads and writes cost more on Standard-IA, but they are a few dollars of a bill that is almost all storage.
With the levers: $427.33 a month less (71.6% less), computed.
The bills line by line, the assumptions and the sources
A storage-heavy history table: Standard, or Standard-IA with TTL, before: Standard, no TTL Illustrative
Standard table class, no TTL, 2,000 GB of storage.
| Line | A month |
|---|---|
| Storage | |
| Table storage, Standard, 2,000 GB2,000 GB × $0.29715 /GB-mo | $594.30 |
| Other | $2.22 |
| On-demand reads, Standard, 5 million5 M request units × $0.1487 /M RU | $0.74 |
| On-demand writes, Standard, 2 million2 M request units × $0.7423 /M RU | $1.48 |
| A month, computed | $596.52 |
A storage-heavy history table: Standard, or Standard-IA with TTL, with the levers: Standard-IA, with TTL Illustrative
Standard-IA table class, TTL capping storage at 1,400 GB.
| Line | A month |
|---|---|
| Storage | |
| Table storage, Standard-IA, 1,400 GB1,400 GB × $0.11886 /GB-mo | $166.40 |
| Other | $2.79 |
| On-demand reads, Standard-IA, 5 million5 M request units × $0.1856 /M RU | $0.93 |
| On-demand writes, Standard-IA, 2 million2 M request units × $0.9279 /M RU | $1.86 |
| A month, computed | $169.19 |
Assumptions
- Illustrative configuration in Paris (eu-west-3), not a client case.
- 5 million reads and 2 million writes a month, on-demand, in both variants: request volumes are unchanged by the table-class switch or by TTL (TTL deletes do not consume write capacity in the Region where the item expires).
- Before: Standard table class, no TTL, average storage this month 2,000 GB, growing without bound. After: TTL expires items past their retention, capping average storage at 1,400 GB (30.0% less, an illustrative assumption), and the table class switched to Standard-IA.
- No global-tables replication: TTL's replicated-delete cost in every other Region of a global table does not apply to a single-Region table.
Not counted
- The free tier.
Sources
- Considerations when choosing a table class in DynamoDB
- DynamoDB table classes
- Using time to live (TTL) in DynamoDB
- Amazon DynamoDB pricing
USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.
Pattern 4 of 4 · Illustrative configuration
Write amplification: a table with three GSIs, before and after narrowing them
A base table in Paris receives 50 million writes a month, average item size 2 KB, with three ALL-projection GSIs: GSI1 answers a frequent, narrow query; GSI2 answers a query over a minority of items; GSI3 was added for a report nobody runs any more. Narrowed, made sparse, and one deleted.
- Before the levers, each 2 KB write costs 2 WRU in the table and 2 in each index, 8 in all; with them, 3.4 on average.
Before the levers, each logical write costs 8 write request units, the table's 2 and 2 for each index; with them, 3.4 on average, computed. The index that was deleted saved the most, and it was the one nobody read.
With the levers: $170.72 a month less (57.5% less), computed.
The bills line by line, the assumptions and the sources
Write amplification: a table with three GSIs, before and after narrowing them, before: Three GSIs, all ALL-projection Illustrative
Every base write also writes to all three GSIs, at the base item's own 2 WRU.
| Line | A month |
|---|---|
| Other | $296.92 |
| Base table, 50 million writes × 2 WRU100 M request units × $0.7423 /M RU | $74.23 |
| GSI1, ALL projection, every write (2 WRU)100 M request units × $0.7423 /M RU | $74.23 |
| GSI2, ALL projection, every write (2 WRU)100 M request units × $0.7423 /M RU | $74.23 |
| GSI3, ALL projection, every write (2 WRU)100 M request units × $0.7423 /M RU | $74.23 |
| A month, computed | $296.92 |
Write amplification: a table with three GSIs, before and after narrowing them, with the levers: Narrower, sparse, and one deleted Illustrative
GSI1 KEYS_ONLY, GSI2 sparse, GSI3 deleted.
| Line | A month |
|---|---|
| Other | $126.20 |
| Base table, 50 million writes × 2 WRU100 M request units × $0.7423 /M RU | $74.23 |
| GSI1, KEYS_ONLY, every write (rounds to 1 WRU)50 M request units × $0.7423 /M RU | $37.12 |
| GSI2, sparse (20.0% of writes touch it, 2 WRU each)20 M request units × $0.7423 /M RU | $14.85 |
| GSI3, deleted0 M request units × $0.7423 /M RU | $0.00 |
| A month, computed | $126.20 |
Assumptions
- Illustrative configuration in Paris (eu-west-3), not a client case.
- 50 million writes a month, average item size 2 KB (2 WRU each), on-demand capacity mode throughout (the same mechanism applies to provisioned WCU).
- Before: three GSIs, all ALL-projection; every base write also writes to all three indexes, at the base item's own WRU, because every write changes an attribute each index projects.
- After: GSI1 switched to KEYS_ONLY (its entries round to 1 KB, 1 WRU instead of 2); GSI2 made sparse on its status flag, so only 20.0% of writes touch it (an illustrative share); GSI3 deleted outright.
- Item size and write volume as stated; GSI2's sparse share and the "every write touches every index" assumption of the before case are illustrative figures, not AWS's.
Not counted
- Table and index storage (unchanged by these levers) and the free tier.
Sources
- Using Global Secondary Indexes in DynamoDB
- General guidelines for secondary indexes in DynamoDB
- Amazon DynamoDB pricing
USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.
Want the same levers on your own bill?
Get a free auditHow to reduce DynamoDB costs
Why is a DynamoDB bill high? Usually for one of a few reasons this article has priced: a busy table on on-demand, indexes that copy every write, scans that read whole tables, large items, storage that never expires, and backups nobody revisits. Each lever below comes from AWS documentation; their order is this article's: see the bill first, remove what is billed but serves nothing, shrink the units each request and each item cost, choose the table class and the capacity mode for what remains, and commit to it last. The levers, in that order:
- Lever 01,SeeSee the bill by table, index and usage typeAlways, and first
- Lever 02,TrimDelete the indexes nothing queriesA global secondary index whose query has gone
- Lever 03,TrimQuery instead of ScanAny code path that scans to find a few items
- Lever 04,TrimExpire old items with TTLItems with a natural end of life
- Lever 05,TrimKeep backups to what recovery needsEvery table with PITR or on-demand backups
- Lever 06,ReshapeUse eventually consistent reads where staleness is acceptableRead paths that can wait for a very recent write
- Lever 07,ReshapeKeep items small: compress, or store large values in Amazon S3Items of several KB, or large text and binary attributes
- Lever 08,ReshapeProject only what a global secondary index needsAn ALL-projection index whose queries need a few attributes
- Lever 09,ReshapeKeep an index sparse where the access pattern allows itAn index that serves a minority of the items
- Lever 10,ReshapeDesign partition keys for even distributionAt table design, and when a key takes the throttles
- Lever 11,ReshapeMove storage-heavy tables to Standard-IATables whose storage outweighs their reads and writes
- Lever 12,ReshapeChoose the capacity mode from measured utilizationEvery table, and again when traffic or prices change
- Lever 13,ReshapeSchedule known peaks, auto-scale the restProvisioned tables whose traffic repeats
- Lever 14,ReshapeAdd DAX only where it offloads more than it costsEventually consistent, read-heavy or hot-key reads, measured first
- Lever 15,CommitCommit last: reserved capacity, then Database Savings PlansProvisioned capacity used every hour, once the rest is done
- Lever 16,ReviewReview on a cadenceQuarterly to yearly, by share of the bill
Lever 01 · See
See the bill by table, index and usage type
Split the DynamoDB line by usage type first: request units, capacity hours, storage by class, backups, replicated writes and streams each have their own. Then by table: the billing guide points to the AWS Cost and Usage Report, where "you can choose if you want to break out usage by resource ID or not". DAX bills under its own product code. Each line points to its levers:
The lines of a DynamoDB bill, and the levers that act on each
| Line | What to look for | Levers |
|---|---|---|
| Write request units | Indexes written on every change, large items, transactions | Indexes, item size, projection, sparse keys |
| Read request units | Scans, strongly consistent reads, large items | Query, consistency, item size, DAX |
| Capacity unit-hours | Utilization against the capacity provisioned | Capacity mode, scheduling, commitment |
| Storage | Items past their use, indexes that copy everything | TTL, item size, projection, Standard-IA |
| Point-in-time recovery, backups | Tables that need no recovery, backups nobody restores | Backups |
| Replicated writes | Replicas, and the indexes on each | Indexes, TTL |
The first levers cost nothing to apply but a look at what each line serves.
Lever 02 · Trim
Delete the indexes nothing queries
An index bills on every write that touches what it carries, whether anything reads it or not. The guidelines for secondary indexes are plain: "Keep the number of indexes to a minimum. Don't create secondary indexes on attributes that you don't query often. Indexes that are seldom used contribute to increased storage and I/O costs without improving application performance."
One ALL-projection index nobody queries
$74.23 a monthof write request units for 50 million writes of 2 KB items, on-demand in Paris, computed: pattern 4's third index, before its storage.
Computed from the AWS Price List · eu-west-3 · Sep 11, 2026
Find the indexes no query names, and delete them; pattern 4 deletes one first, and it is the step that saves the most.
Lever 03 · Trim
Query instead of Scan
A Scan reads the whole table or index and filters afterwards, so the filter shrinks the answer, not the bill: "A Scan operation always scans the entire table or secondary index. It then filters out values to provide the result you want, essentially adding the extra step of removing data from the result set" (querying and scanning). Each 1 MB page costs, in the same guide's arithmetic, "(1 MB page size / 4 KB item size) / 2 (eventually consistent reads) = 128 read operations", and twice as many strongly consistent.
One Scan of a 100 GB table
$1.95 a scaneventually consistent, on-demand in Paris: 102,400 pages of 1 MB at 128 read request units each, computed.
Computed from the AWS Price List · eu-west-3 · Sep 11, 2026
Run once an hour, that Scan costs $1,422.80 a month, computed. Shape the table's keys, or a global secondary index, on the question the Scan stands in for, so that a Query reads the items of one partition key value instead of the whole table. The same guide's advice: "If possible, you should avoid using a Scan operation on a large table or index with a filter that removes many results."
Lever 04 · Trim
Expire old items with TTL
Items that are no longer needed still bill their storage every month, and a delete job pays a write for each delete. TTL deletes them for nothing in the table's own Region (Time to live), and every GB it removes is a GB-month no longer billed:
600 GB that TTL keeps out of a table
$178.29 a monthof Standard storage no longer billed in Paris, computed: pattern 3's history table, before its change of class.
Computed from the AWS Price List · eu-west-3 · Sep 11, 2026
In a global table, each other Region pays the replicated delete as a write. Pattern 3 caps a history table with TTL.
Lever 05 · Trim
Keep backups to what recovery needs
Point-in-time recovery bills the table's size, not the days it keeps, so the obvious trim does nothing:
Reducing the retention period (for example, from 35 days to 1 day) doesn't lower PITR costs.
What lowers it is this article's advice rather than AWS's: keep it on the tables that recovery needs, and off the ones that can be rebuilt from elsewhere, since each costs its size every month:
Point-in-time recovery on a 2,000 GB table
$475.44 a monthin Paris, computed, whether it keeps 1 day or 35: the size of the table sets the price.
Computed from the AWS Price List · eu-west-3 · Sep 11, 2026
On-demand backups bill until deleted, a whole month on the 1st (Backups and restores in Paris), so delete the ones nobody will restore before the month turns. AWS Backup adds lifecycle rules, with "Cold storage tiering", and a restore costs less without the indexes it does not need.
Lever 06 · Reshape
Use eventually consistent reads where staleness is acceptable
A strongly consistent read costs twice an eventually consistent one, and a transactional read twice again, per 4 KB (Request units). Eventually consistent is the default; keep strongly consistent reads, and transactions, for the paths that must see the last write:
A billion reads a month of a 4 KB item, on-demand in Paris, by consistency (computed)
| Read | Read request units each | A billion reads, computed |
|---|---|---|
| Eventually consistent | 0.5 | $74.35 |
| Strongly consistent | 1 | $148.70 |
| Transactional | 2 | $297.40 |
Computed from the AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026.
Index and stream reads are eventually consistent anyway, so the choice concerns the table and its local secondary indexes.
Lever 07 · Reshape
Keep items small: compress, or store large values in Amazon S3
An item's size, rounded up, sets the units of every request on it (Request units), and its storage. AWS's guide to large items gives two ways to shrink one: "Compressing large attribute values can let them fit within item limits in DynamoDB and reduce your storage costs", and for values too large to keep, "You can store them as an object in Amazon S3 and then store the object identifier in your DynamoDB item." It follows that a smaller item also costs fewer request units, at every 1 KB step it drops below:
10 write request units a write Illustrative
| Line | A month |
|---|---|
| Other | |
| 10 million writes × 10 write request units100 M request units × $0.7423 /M RU | $74.23 |
| A month, computed | $74.23 |
4 write request units a write Illustrative
| Line | A month |
|---|---|
| Other | |
| 10 million writes × 4 write request units40 M request units × $0.7423 /M RU | $29.69 |
| A month, computed | $29.69 |
The item compressed to 3.5 KB costs $44.54 a month less than the 10 KB item (60.0% less), computed.
USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.
The objects moved to Amazon S3 then bill at S3's storage prices, and each item keeps only their identifier.
Lever 08 · Reshape
Project only what a global secondary index needs
An index entry is written at its own size, so a narrower projection writes and stores less. The guidelines give the rule: "If your queries usually return only a small subset of attributes, and the total size of those attributes is much smaller than the whole item, project only the attributes that you regularly request", and "Specify ALL only if you want your queries to return the entire table item sorted by a different sort key." The floor is the unit: "All of these factors assume that the size of each item in the index is less than or equal to the 1 KB item size for calculating write capacity units" (GSI guide), so a KEYS_ONLY entry of a few bytes still costs one unit per write.
The whole 2 KB item Illustrative
| Line | A month |
|---|---|
| Other | |
| 50 million writes × 2 write request units100 M request units × $0.7423 /M RU | $74.23 |
| A month, computed | $74.23 |
The keys, rounded up to 1 KB Illustrative
| Line | A month |
|---|---|
| Other | |
| 50 million writes × 1 write request unit50 M request units × $0.7423 /M RU | $37.12 |
| A month, computed | $37.12 |
A KEYS_ONLY index costs $37.11 a month less than an ALL-projection index (50.0% less), computed.
USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.
A query that needs an attribute the index does not carry fetches it from the table, at the table's read price: project what the queries read, no more. Pattern 4 narrows one index to its keys.
Lever 09 · Reshape
Keep an index sparse where the access pattern allows it
An index is written only for the items that carry its key: "If an item is not present in the index before or after the item is updated, there is no additional write cost for the index" (GSI guide). It follows that an index whose partition key is an attribute only some items carry, such as a flag set on the open orders and removed when they close, is written for those items alone; others call it a sparse index.
The writes a sparse index skips
$59.38 a month80 million write request units, for the 40 million of pattern 4's writes that no longer reach its second index, on-demand in Paris, computed.
Computed from the AWS Price List · eu-west-3 · Sep 11, 2026
Pattern 4 makes that index sparse on a status that a fifth of the writes carry.
Lever 10 · Reshape
Design partition keys for even distribution
A hot key does not raise the price of a request, but it throttles one partition while the table has capacity to spare (Partitions, and the ceiling of each). It follows that the usual answer, more capacity for the whole table, is paid for the partitions that did not need it. Find the keys first: the document history records "a new Throttled keys only mode in CloudWatch Contributor Insights that specifically tracks the most throttled partition keys". Then spread them, by the partitions guide's rule of many distinct values, and keep items small, since a large item reaches the ceiling sooner. For a key that is hot by nature, such as the product of a one-day sale, AWS's answer is a cache: Add DAX only where it offloads more than it costs.
Lever 11 · Reshape
Move storage-heavy tables to Standard-IA
When storage is most of a table's bill, the class that cuts the storage price by more than half pays for its dearer requests: in Paris, once storage passes 41.7% of the throughput cost, computed (Standard or Standard-IA?). The class covers the table and its indexes and changes without code.
Standard table class Illustrative
| Line | A month |
|---|---|
| Storage | |
| Storage: 2,000 GB2,000 GB × $0.29715 /GB-mo | $594.30 |
| Other | $2.22 |
| Reads: 5 million5 M request units × $0.1487 /M RU | $0.74 |
| Writes: 2 million2 M request units × $0.7423 /M RU | $1.48 |
| A month, computed | $596.52 |
Standard-IA table class Illustrative
| Line | A month |
|---|---|
| Storage | |
| Storage: 2,000 GB2,000 GB × $0.11886 /GB-mo | $237.72 |
| Other | $2.79 |
| Reads: 5 million5 M request units × $0.1856 /M RU | $0.93 |
| Writes: 2 million2 M request units × $0.9279 /M RU | $1.86 |
| A month, computed | $240.51 |
The Standard-IA table costs $356.01 a month less than the Standard table (59.7% less), computed.
USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.
That is pattern 3's table before TTL. The reverse holds too: a busy table with little data pays the premium on every request for a storage discount it does not use.
Lever 12 · Reshape
Choose the capacity mode from measured utilization
Measure before you choose: a table's consumed capacity, against what it would provision, gives its utilization, and On-demand or provisioned? gives the break-even. Measure again after a price change: on November 1, 2024 the break-even doubled (On-demand request units in Paris), so a table moved to provisioned capacity before then, at a utilization between the two break-evens, now costs less on-demand. The Serverless Applications Lens frames the choice: "You can choose to use provisioned capacity if you have steady workloads with predictable growth, and if you can reliably forecast capacity requirements for your application" (capacity). By the traffic a table has:
Which capacity mode costs less, by the traffic a table has
| Traffic | Mode | Why |
|---|---|---|
| Busy every hour, steady | Provisioned, then reserved | Far above the break-even all month |
| A daily peak at a known time | Provisioned: scheduled actions and target tracking | Capacity raised before the peak, not after it |
| Idle most of the time | On-demand | Below the break-even; nothing billed while idle |
| Bursts nobody can schedule | On-demand | Up to double the previous peak, at once |
| New, shape unknown | On-demand, then measure | AWS's default until the utilization is known |
A wrong choice can be undone the same day: a table can switch to on-demand four times in 24 hours (Capacity modes).
Lever 13 · Reshape
Schedule known peaks, auto-scale the rest
Target tracking keeps consumed capacity near a target share of what is provisioned, "the default value of 70 percent" in the pricing page's examples, but it reacts in minutes (Capacity modes), and "CloudWatch alarms might have a short delay of up to a few minutes before triggering auto scaling" (auto scaling). For a peak at a known time, scheduled scaling raises the capacity first: "With scheduled scaling, you can set up automatic scaling for your application based on predictable load changes by creating scheduled actions that increase or decrease capacity at specific times", and "You can use scheduled scaling and scaling policies together to get the benefits of proactive and reactive approaches to scaling."
2,000 RCU and 500 WCU, 730 h Illustrative
| Line | A month |
|---|---|
| Other | $507.20 |
| 2,000 RCU × 730 h1,460,000 RCU-h × $0.0001544 /h | $225.42 |
| 500 WCU × 730 h365,000 WCU-h × $0.000772 /h | $281.78 |
| A month, computed | $507.20 |
Peak capacity 60 h, baseline 670 h Illustrative
| Line | A month |
|---|---|
| Other | $93.01 |
| 2,858 RCU × 60 h, 143 RCU × 670 h267,290 RCU-h × $0.0001544 /h | $41.27 |
| 715 WCU × 60 h, 36 WCU × 670 h67,020 WCU-h × $0.000772 /h | $51.74 |
| A month, computed | $93.01 |
Scheduled and auto-scaled capacity costs $414.19 a month less than capacity sized to the peak (81.7% less), computed.
USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published September 11, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.
The scheduled capacity pays its peak size for the 60 hours of peak only, and target tracking keeps the baseline near its target; keep on-demand for the bursts nobody can schedule.
Lever 14 · Reshape
Add DAX only where it offloads more than it costs
DAX is worth its nodes when the reads it absorbs let the table give up more read capacity than the nodes cost. AWS puts the case in the DAX guide: "Applications that are read-intensive, but are also cost-sensitive", with "potential operational cost savings by reducing the need to overprovision read capacity units".
Three dax.t3.small nodes
$96.36 a monthin Paris, computed, before the first read and whatever the reads it serves.
Computed from the AWS Price List · eu-west-3 · Oct 9, 2026
That is the bar DAX in Paris converts into provisioned RCU and into on-demand reads: a table that would not otherwise need that much read capacity pays more with the cache than without it. Measure the reads first, size the cluster to them, and look again when the traffic changes.
Lever 15 · Commit
Commit last: reserved capacity, then Database Savings Plans
A commitment discounts what is left once the other levers are done, so it comes last. Reserve the provisioned capacity a table uses every hour, in blocks of 100 units, for a year: in Paris it costs about half, 53.9% less for writes and 53.6% less for reads, computed (Is reserved capacity worth it?). A Database Savings Plan then covers what remains, on-demand throughput included, never on top of a reservation (Do Database Savings Plans cover DynamoDB?). Pattern 2 reserves a steady table's capacity, once the capacity mode has done most of the work.
Lever 16 · Review
Review on a cadence
"The review effort should reflect potential benefit", in AWS's words (COST10-BP01):
How often AWS suggests reviewing a workload
| Workload | Reviewed |
|---|---|
| Core workloads, or workloads over ten percent of the bill | Quarterly or every six months |
| Workloads below ten percent of the bill | Annually |
DynamoDB gives a reason of its own to look again: the capacity mode and the table class are settings, prices move, as on November 1, 2024, and a table's traffic and storage drift away from the shape they were chosen for. Each review checks the utilization against the break-even, storage against throughput, and every index against the queries that still read it.
In short: Commit last: see the bill by table and usage type, delete the indexes, scans, items and backups that serve nothing, shrink what each item, request and index costs, choose the table class and the capacity mode from measured traffic, and only then reserve the capacity that remains busy every hour.
FAQ
How much does DynamoDB cost?
Per request on-demand, $0.7423 per million write request units and $0.1487 per million read request units in Paris, or per capacity unit-hour provisioned, $0.000772 per WCU and $0.0001544 per RCU, plus $0.29715 per GB-month of storage on the Standard table class and a line for each feature turned on (What a DynamoDB bill is made of).
Is DynamoDB on-demand cheaper than provisioned?
Only for tables that would sit mostly idle on provisioned capacity: in Paris, provisioned capacity costs less above 28.9% average utilization for writes and 28.8% for reads, computed (On-demand or provisioned?).
Why did my DynamoDB bill not go down after the 2024 price cut?
Because the cut lowered on-demand prices only: on November 1, 2024 the Paris on-demand prices halved and provisioned prices stayed, so a provisioned table's bill did not move. The break-even doubled with it, from 14.4% to 28.9%, computed: a provisioned table used between the two now costs less on-demand (On-demand request units in Paris).
Do GSIs double DynamoDB's write cost?
An index that projects all attributes does, in most cases, AWS says, for writes and storage; a KEYS_ONLY index costs one unit per write, and an index the item is absent from costs nothing (Secondary indexes).
Is DynamoDB free?
Partly: the free tier runs on provisioned capacity and the Standard table class, with 25 WCUs, 25 RCUs and 25 GB of storage a month per Region; on-demand requests are not in it (Storage and the free tier).
Is DynamoDB cheaper than RDS?
It depends on the traffic: RDS bills an instance every hour, DynamoDB each request unit or each unit of capacity; a table with idle hours favours DynamoDB on-demand, a database busy all day an instance (DynamoDB or a relational database?; the RDS article prices the instance).