Amazon DocumentDB Pricing: The 25% Rule Nobody Explains

If you're sizing a new Amazon DocumentDB cluster, or explaining a bill that came in higher than expected, you already know DocumentDB isn't priced like a single hourly number. Instance-based clusters bill across four dimensions, two storage configurations change the math depending on your I/O pattern, and Serverless and Elastic Clusters add two more pricing models on top. Picking the wrong configuration can mean paying 20-40% more for the exact same workload.

Having sized and reviewed a fair number of these clusters, I've found the bill almost always traces back to a handful of configuration choices. This guide covers every DocumentDB billing dimension with AWS's own worked numbers, shows the break-even math AWS states as a rule but never plots out, and covers the IaC review checks that catch cost mistakes before a cluster is created. You'll leave knowing which configuration fits your workload and what to check in Terraform or CloudFormation before you deploy.

What Amazon DocumentDB Actually Costs (Quick Answer)

Amazon DocumentDB pricing for instance-based clusters breaks into four dimensions: instance hours, database I/O, database storage, and backup storage, plus data transfer separately. If you've costed the managed relational side of AWS, this sits alongside Amazon Aurora's own six billing dimensions as a similar multi-line model. Two storage configurations exist: Standard, which charges per I/O request, and I/O-Optimized, which folds I/O into a higher instance and storage rate with no per-request charge.

AWS's own worked example: a cluster with 2x db.r5.large instances, 50 GB of data, and 50 GB of backup in US East (N. Virginia) costs $449.42/month on Standard at 200 million I/O requests, or $459.86/month on I/O-Optimized at 1,000 million I/O requests. AWS's pricing page cites a 24.5% saving next to that second figure, but that percentage only holds if you compare it against what Standard would cost at the same 1,000 million I/O requests, which is $609.42, not the $449.42 figure from the 200-million-request example. $609.42 vs. $459.86 is the valid same-volume comparison, and it lands at the same 24.5%. The next section holds instance count and storage constant while I/O volume changes, so you can see exactly where Standard and I/O-Optimized cross for a specific cluster shape.

Serverless bills by DocumentDB Capacity Unit (DCU) per hour for spiky workloads, and Elastic Clusters bill by vCPU-hour for sharded, high-throughput ones. If you're comparing document and key-value stores, that capacity-mode choice mirrors DynamoDB's on-demand vs provisioned pricing. Global Clusters layer cross-region replication cost on top of whichever base model you pick. A one-month free trial exists (750 hours of db.t3.medium, 30 million I/Os, 5 GB storage, 5 GB backup), not a permanent free tier, so budget for standard rates once it expires.

Standard vs I/O-Optimized: The 25% Rule, With the Math

The official AWS DocumentDB pricing page states its own guidance plainly: "If you expect your I/O costs to be less than 25% of your database cluster spend, this configuration might be ideal for you" for Standard, and if I/O costs are expected to exceed 25% of cluster spend, I/O-Optimized "offers enhanced price performance," with AWS citing up to 40% cost savings for I/O-intensive applications. Treat that 25% figure as a rough rule of thumb, not a number to calculate against: run the math for a specific cluster shape below, and the real crossover lands well under 25% of spend. What AWS doesn't show is where that line actually falls in dollars for a specific cluster, and that's the gap worth closing before you pick a configuration.

The rate deltas explain why the threshold exists at all. For a db.r5.large instance in US East (N. Virginia), I/O-Optimized costs about 10% more per hour ($0.3047 vs. $0.277/hour), and its storage rate is three times higher ($0.30 vs. $0.10 per GB-month). In exchange, I/O drops from $0.20 per million requests to $0 under I/O-Optimized. Whether that trade pays off depends entirely on how much I/O your cluster actually generates.

Where the break-even point lands

Take the same fixed cluster AWS used in its own example (2x db.r5.large, 50 GB of data, 50 GB of backup within the free allotment, US East N. Virginia, 730 hours/month) and hold the instance count and storage size constant while I/O volume changes:

The I/O-Optimized total doesn't move with volume, because there's no per-request charge. The $459.86 figure is AWS's own published total at 1,000 million I/Os, and it would be identical at any I/O volume for this instance count and storage size. The Standard total climbs by $0.20 for every million I/O requests. Run the fixed-cost math ((instance_rate x 730 hrs x 2 instances) + (storage_rate x 50 GB) + (io_rate x millions_of_I/Os)) and the two lines cross at roughly 252 million I/O requests per month for this specific cluster shape. Below that, Standard wins. Above it, I/O-Optimized wins. This is a derived illustration built from AWS's confirmed rates for this instance size and data volume, not a table AWS itself publishes. Run your own numbers through the DocumentDB pricing calculator for a different instance class or storage size.

Worth calling out directly: at that 252-million crossover, I/O makes up only about 11% of the Standard total, not 25%. Follow AWS's 25%-of-spend heuristic literally and you'd stay on Standard well past the point where I/O-Optimized is already cheaper for this cluster shape. The heuristic is a starting point, not a decision rule. Compare same-input totals for your own instance count and storage size, the way the table above does, and switch on that number instead.

Check VolumeReadIOPs and VolumeWriteIOPs in CloudWatch to see where your own cluster actually sits before you commit to a configuration. Switching to I/O-Optimized is allowed once every 30 days per cluster (track the next eligible switch date with describe-db-clusters), but you can switch back to Standard at any time, with no downtime or instance reboot required either way. Set the configuration on cluster creation with --storage-type iopt1 on the AWS CLI, or the matching Terraform/CloudFormation attribute; AWS documents the switch mechanics in its cluster storage configurations guide.

Instance Hours, Storage, and I/O: The Core Cost Components

Every DocumentDB pricing model is built from the same underlying mechanics for instance-based clusters, so it's worth understanding what each charge measures before comparing configurations or moving to Serverless or Elastic Clusters.

On-demand instance hours and burstable CPU credits

Instance hours bill from launch until an instance is stopped or deleted, metered in one-second increments with a 10-minute minimum after a billable status change (create, modify, delete). In a Multi-AZ deployment, instance cost is simply the primary cost plus each replica's cost. There's no separate "Multi-AZ" line item, and data transferred between AZs for that replication is free.

T3 or T4g instances run in unlimited burstable mode by default. You're only charged CPU Credits when average CPU over a rolling 24-hour period exceeds baseline, at a flat $0.09/vCPU-hour across every T3/T4g size and region. I've seen this catch teams off guard on dev clusters running background jobs that quietly push CPU above baseline all day.

Storage and I/O request charges

Storage bills per GB-month for data, indexes, and change stream data, and it auto-scales; you never pre-provision it. DocumentDB replicates your data six ways across three Availability Zones for durability, but you're billed for the logical size of your data, not the six replicated copies.

I/O is counted per operation: an 8 KB page read counts as one I/O, a 4 KB write-ahead log unit counts as one write. Once a page is in the buffer cache, repeat reads don't cost additional I/O, which is why right-sizing an instance to fit your working set in memory reduces I/O spend directly. Confirmed rates, US East (N. Virginia): db.r5.large runs $0.277/hour Standard or $0.3047/hour I/O-Optimized; db.r6g.large runs $0.263/hour Standard or $0.2895/hour I/O-Optimized. Storage runs $0.10/GB-month Standard and $0.30/GB-month I/O-Optimized; I/O costs $0.20 per million requests on Standard only.

Instance-based billing assumes a fairly steady, predictable load. If your workload swings hard between idle and busy, Serverless changes the math.

DocumentDB Serverless: DCU-Hour Billing Explained

DocumentDB Serverless scales capacity automatically to match demand, billed per second in DocumentDB Capacity Units (DCUs). One DCU is roughly 2 GiB of memory with proportional CPU and network, similar to a provisioned instance. Capacity starts at, and can drop to, 0.5 DCU, adjusting in fine-grained 0.5 DCU increments as load changes.

Confirmed rates, US East (N. Virginia): $0.0822/DCU-hour Standard, $0.0905/DCU-hour I/O-Optimized. A Serverless cluster still picks Standard or I/O-Optimized for its storage/I/O portion, so the same fixed-cost break-even logic from the earlier section still applies. Serverless changes how compute scales, not the storage-configuration decision.

AWS's own worked example: a workload running at 7 DCU for 30 minutes, then scaling down to 0.5 DCU over roughly 3 minutes, costs $0.32 for compute on Standard or $0.35 on I/O-Optimized. That's compute only. Storage, backup, and (Standard) I/O bill on top at the same rates as instance-based clusters, so don't mistake that figure for a full monthly total. Serverless also supports Multi-AZ deployments and up to 15 read replicas.

Serverless scales one cluster's compute automatically for you. When the scaling problem is sharding data across many nodes instead, Elastic Clusters uses a pricing model built for that shape of problem.

Elastic Clusters: vCPU-Hour Billing for Sharded Workloads

Elastic Clusters exist for horizontal scaling (millions of reads and writes, petabytes of storage), and they price differently from instance-based clusters. Instead of four billing dimensions, they bill on three: vCPU-hour, database storage, and backup storage. There's no separate per-request I/O line item; I/O cost is folded into the vCPU and storage model.

vCPU count is a straightforward multiplication: shards x nodes per shard x vCPUs per node, billed per second with a 10-minute minimum. The confirmed rate is $0.132/vCPU-hour, storage runs $0.30/GB-month (the same as I/O-Optimized instance storage), and backup storage is free up to 100% of your Elastic Cluster's total storage in-region.

AWS's own worked example: 2 shards x 2 nodes per shard x 2 vCPUs per node, storing 500 GB of data plus 500 GB of backup, in US East (N. Virginia):

• Compute: $0.132 x 730 hrs x 2 shards x 2 nodes/shard x 2 vCPUs/node = $770.88/month
• Storage: $0.30 x 500 GB = $150.00/month
• Backup: $0 (within the free allotment)
• Total: $920.88/month

Don't compare that $920.88 figure directly against the $449.42 instance-based total: they represent different data volumes (500 GB vs. 50 GB) and capacity profiles entirely. Pick your model by workload shape, not by dollar figure. Sizing guardrails: up to 32 shards, 2-64 vCPUs per node in powers of 2, and up to 128 TiB of storage per shard.

Whichever model you land on, the same backup and cross-region mechanics apply underneath it, and that's where a lot of unplanned spend actually shows up.

Backup Storage, Global Clusters, and Data Transfer

Backups in DocumentDB are always on and can't be disabled, with a default 1-day PITR (point-in-time restore) window, configurable from 1 to 35 days. Backup storage is free up to 100% of your current cluster's data storage size, per region: AWS's own example gives a 10 TB cluster 10 TB of backup storage free. Overage is priced "as low as $0.02/GB-month," which varies by region.

Global Clusters add cross-region replication for disaster recovery and low-latency global reads, and the cost mechanic is easy to misread. You pay for replicated write I/O to every secondary region regardless of storage configuration: I/O-Optimized removes your in-region per-request I/O charge, but not this cross-region one, and it's billed at the same $0.20 per million requests as Standard in-region I/O. Full instance, storage, backup, and (Standard-only) I/O costs also apply per secondary region. Run your topology through the DocumentDB pricing calculator for a live number across multiple regions.

Data transfer has clear free and charged triggers: same-AZ transfer between DocumentDB and EC2 is free, cross-AZ Multi-AZ replication is free, and cross-AZ transfer between EC2 and DocumentDB in different AZs of the same region uses standard EC2 regional data-transfer rates rather than a DocumentDB-specific charge.

Once the recurring bill is clear, the next lever is contractual: committing to usage in exchange for a discount, or dealing with the extra cost of staying on an older engine version.

Database Savings Plans and Extended Support: Commitments and Legacy Costs

One thing worth knowing before you go looking for it: DocumentDB doesn't have a dedicated Reserved Instance product the way RDS and Aurora do. AWS's own DocumentDB FAQ page doesn't mention Reserved Instances at all, only Database Savings Plans, so skip hunting for a Reserved Instance purchase page. The commitment discount you want is an AWS Database Savings Plan instead, and it comes with an eligibility rule worth checking before you commit.

Database Savings Plans deliver up to 35% savings on DocumentDB Serverless usage and up to 20% on provisioned instances vs. on-demand rates, over a 1-year term, applying automatically regardless of engine, instance family, size, or Region, with one exception: provisioned instance coverage requires generation 7 or newer. DocumentDB's own instance lineup skips straight from db.r6g to db.r8g (Graviton4), with no r7g class, so in practice db.r8g is the only provisioned instance family a Database Savings Plan currently discounts. The db.r5.large and db.r6g.large instances used in the worked examples throughout this article are older generations and aren't covered; you'd need to move to db.r8g before a Database Savings Plan discount applies. DocumentDB Serverless usage has no generation restriction.

You can't combine a Database Savings Plan with an RDS Reserved Instance or DynamoDB reserved capacity for the same workload, though a different workload on your account can use a different mechanism. Payment options are narrower here too: Database Savings Plans only offer No Upfront, billed monthly regardless of usage. If you want to prepay, AWS's separate Advance Pay feature in the Billing and Cost Management console handles that and can be combined with a Database Savings Plan.

Still on DocumentDB engine version 3.6? Extended Support billing started July 1, 2026, so if that fleet hasn't upgraded yet, this charge is already on the bill, not something to plan for later. It works much like RDS's own Extended Support charges: an 80% premium on top of on-demand rates for Year 1 and Year 2 (through March 31, 2028), rising to 160% for Year 3, priced by instance family and vCPU-hour. AWS's own worked example: a db.r4.large (2 vCPUs) in US East (Ohio) normally runs $0.277/hour. Through March 31, 2028, Extended Support adds $0.222/hour on top; from April 1, 2028 through March 31, 2029, that jumps to $0.444/hour. That's an Ohio-specific example, not N. Virginia, so confirm current rates for your own region. Upgrading off version 3.6 is the only way to stop paying the premium.

Commitments and legacy-version costs are decisions you make at the account level. The next section is about catching cost mistakes at the code level, before a cluster is ever created.

Catching DocumentDB Cost Drivers Before They Hit Your Bill

Every dollar amount above traces back to a checkable pattern in your Terraform or CloudFormation. I've reviewed enough DocumentDB clusters to know the same handful of mistakes account for most of the wasted spend:

• Oversized instance class picked "just in case." DocumentDB reserves roughly a third of instance RAM for its own services, so only about two-thirds is available for the buffer cache. Check BufferCacheHitRatio in CloudWatch, and flag any instance class chosen without a sizing rationale tied to that metric.
• Missing the I/O-Optimized flag on an I/O-heavy cluster. Grep your IaC for --storage-type iopt1 or its Terraform/CloudFormation equivalent on any cluster whose workload profile suggests I/O volume will cross the break-even point covered earlier. This is a one-line fix with real monthly impact.
• Unbounded Elastic Clusters shard count. Shard count multiplies directly into the vCPU-hour bill (shards x nodes per shard x vCPUs per node). A review should flag a shard count set without a documented capacity target behind it.
• Dev and test clusters left running around the clock. DocumentDB instances can be stopped for up to 7 days; storage and snapshot charges continue, but instance-hour charges stop. Run the math on a 3x db.r6g.large cluster at $0.263/hour Standard: 720 hours/month always-on runs $568.08 in instance charges, while a 189-hour business-hours-only schedule (roughly 9 hours a day across 21 business days) drops that to $149.12, a greater than 73% reduction in instance cost specifically (storage and backup keep billing regardless).
• Backup retention overrides that outrun the free allotment. Raising retention from the 1-day default to satisfy a compliance control, like AWS Control Tower's CT.DOCUMENTDB.PR.2 (which checks for 7-day-or-longer retention), can push backup storage past the free 100%-of-data-storage allotment sooner than expected, especially on clusters with high churn or accumulated manual snapshots.
• No cost-allocation tags on new clusters. Tagging plus AWS Cost Explorer is AWS's own documented mechanism for making the Standard-vs-I/O-Optimized decision empirically, per cluster, instead of by guesswork. Flag untagged database resources in review.
• Running an old engine version with no compression. DocumentDB 5.0+ supports LZ4 compression, shrinking documents up to 7x, with 8.0 improving further. It's a code-level lever, not a runtime one: picking a current engine version indirectly reduces both storage and I/O cost.

Catching these in code review before a cluster ships is a shift-left FinOps practice: a different discipline than reacting to a bill after the fact. CloudBurn is an open-source policy engine that scans your Terraform and CloudFormation for exactly these patterns in CI, then runs the same rules against your live AWS account to find what's already running unchecked. Reviewing patterns in code catches mistakes before they deploy. The fastest way to check a specific number for your own cluster, though, is to run it through a calculator built for this exact billing model.

Estimate Your Own DocumentDB Bill

A few things worth carrying forward:

• Instance-based bills carry four dimensions (instance hours, I/O, storage, backup), and the Standard-vs-I/O-Optimized choice is the single biggest lever, with a real crossover point you can calculate instead of guessing at.
• Serverless and Elastic Clusters use entirely different billing units (DCU-hour and vCPU-hour). Match the model to your workload's shape, not just the sticker price.
• Backup storage is free up to 100% of your data storage per region, but a compliance-driven retention change can push you past that allotment sooner than expected.
• DocumentDB has no dedicated Reserved Instance product. Commitment discounts come from Database Savings Plans instead: up to 35% for Serverless, 20% for provisioned instances on a 1-year term, and provisioned coverage requires generation 7+ (db.r8g for DocumentDB).
• The cheapest bill is the one caught in review: a right-sized instance, the correct storage flag, a pause schedule for dev/test clusters, and sane backup retention, all checkable before a cluster deploys.

Amazon DocumentDB pricing rewards the teams who model it before they deploy, not after the invoice lands. Run your own instance count, storage size, and I/O volume through the DocumentDB pricing calculator below for a number specific to your cluster. If your commitment strategy spans more than DocumentDB, the AWS Database Savings Plans guide covers how the same 1-year commitment applies across RDS, Aurora, DynamoDB, and the rest of the eligible services.