DocumentDB cost explained: what you pay for a managed document database

Quick answer

Amazon DocumentDB bills four things: instance hours (per instance by size, for each node in the cluster), storage (per GB-month of data actually stored, growing automatically), I/O (per million read/write operations against storage), and backup storage (per GB-month beyond the free backup equal to your cluster size). Compute and storage scale independently. For I/O-heavy workloads the per-operation charge can rival or exceed instance cost, so query efficiency matters. A newer I/O-optimized configuration trades higher instance rates for no per-I/O charge on heavy workloads.

Amazon DocumentDB is AWS's managed, MongoDB-compatible document database. Like Aurora, it separates compute from storage, and it meters several things independently. Understanding each meter, especially I/O, which surprises people, is the key to predicting and controlling DocumentDB cost.

The four meters

Meter	Billed by
Instances	Per instance-hour, by instance size, per node
Storage	Per GB-month of data stored, grows automatically
I/O	Per million read/write operations to storage
Backup storage	Per GB-month beyond free backup equal to cluster size

You run a cluster of one or more instances (a primary plus optional replicas), and each instance bills per hour by its size, whether or not it is busy. Storage grows automatically as data grows and is billed per GB-month. I/O is billed per operation against the storage layer. Backups up to your cluster size are free; beyond that you pay per GB-month. This is a similar shape to Aurora.

Why I/O can dominate

The meter that catches people out is I/O. Every read that misses the cache and every write generates billed I/O operations against the storage layer, and for read-heavy or write-heavy workloads with poor cache hit rates, the I/O charge can rival or even exceed the instance cost. Inefficient queries that scan large amounts of data, missing indexes, and workloads that constantly miss the buffer cache all drive I/O up. So query and index efficiency is a direct cost lever, not just a performance one.

Instances and replicas

Instance cost scales with size and count. Adding read replicas for availability and read scaling multiplies the instance bill (each replica is a full billed instance), so add replicas for real availability or read-scaling needs, not by default. Right-size the instance class to your working set: an instance large enough to cache the hot data reduces I/O (and thus I/O cost), so there is a tradeoff between instance size and I/O charges worth modeling. This is the same capacity-versus-cost tradeoff seen across databases.

Controlling DocumentDB cost

Right-size instances to your working set, add replicas only when availability or read load justifies them, optimize queries and indexes to cut I/O, and set backup retention to what you actually need. For very I/O-heavy clusters, evaluate the I/O-optimized configuration, which charges higher instance rates but no per-I/O fee, and can be cheaper when I/O would otherwise dominate. Compare DocumentDB against alternatives like DynamoDB or self-managed MongoDB for your access pattern, and price the cluster before you deploy against the resource catalog.

FAQ

What does Amazon DocumentDB cost?

DocumentDB bills four things: instance hours (per instance by size, for each node in the cluster), storage (per GB-month of data stored, growing automatically), I/O (per million read and write operations against storage), and backup storage (per GB-month beyond a free backup equal to your cluster size). Compute and storage scale independently, and for I/O-heavy workloads the per-operation charge can be a large part of the total.

Why is DocumentDB I/O so expensive?

Every read that misses the cache and every write generates billed I/O operations against the storage layer. For read-heavy or write-heavy workloads with poor cache hit rates, that per-operation charge can rival or exceed instance cost. Inefficient queries scanning large data, missing indexes, and constant cache misses all drive I/O up, so query and index efficiency directly controls I/O cost, not just performance.

How do I reduce DocumentDB cost?

Right-size instances to your working set (a bigger instance that caches hot data reduces billed I/O), add read replicas only when availability or read load justifies them since each is a full billed instance, optimize queries and indexes to cut I/O operations, and set backup retention to what you actually need. For very I/O-heavy clusters, evaluate the I/O-optimized configuration that removes per-I/O charges.

Does DocumentDB charge for storage separately?

Yes. DocumentDB separates compute from storage. Storage is billed per GB-month of data actually stored and grows automatically as your data grows, independent of instance size. That means you cannot reduce storage cost by shrinking the instance, you reduce it by storing less data or setting retention on backups, whose free tier equals your cluster size before per-GB-month charges apply.

Is DocumentDB cheaper than running MongoDB yourself?

It depends on scale and operational burden. DocumentDB removes the work of running MongoDB (patching, backups, replication, failover) in exchange for its managed pricing across instances, storage, I/O, and backups. Self-managed MongoDB on your own instances can be cheaper in raw compute but costs engineering time to operate. Compare total cost including operations, not just instance rates, for your workload.

How does C3X help with DocumentDB cost?

C3X prices DocumentDB clusters and other database resources from your Terraform before deploy, so instance, storage, and configuration costs are visible in the pull request. Seeing the cost of instance sizes and replica counts at design time helps you right-size the cluster and choose the configuration before an expensive, over-provisioned cluster ships to production.

What to do next

Price your DocumentDB cluster before you deploy it. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.