Explanation
Why the waste happens and who it affects.
Standard storage bills I/O on a pay-per-request basis on top of instance and storage charges, while I/O-optimized storage removes I/O charges in exchange for higher instance and storage rates. AWS's guidance is that standard storage suits clusters whose I/O costs are below 25 percent of total cluster cost, and I/O-optimized offers better price performance when I/O costs exceed 25 percent.
Clusters keep whichever configuration they were created with unless someone changes it, so I/O-heavy clusters, for example those with working sets larger than the buffer cache, frequent collection scans or heavy write workloads, often keep paying large and variable I/O charges on standard storage. The opposite also happens: light clusters switched to I/O-optimized for predictability pay the higher instance and storage rates without enough I/O to offset them.
Billing model
The pricing dimensions that drive this cost.
- Standard storage
- Instance and storage charges plus I/O billed per million requests, so costs vary with workload
- I/O-optimized storage
- No I/O charges, with higher instance and storage prices for predictable monthly cost
- 25 percent guideline
- AWS suggests I/O-optimized when I/O exceeds about 25 percent of total cluster cost
- Switching limits
- A cluster can move to I/O-optimized once every 30 days and back to standard at any time, with no downtime
How to detect
5 checks to find it in your estate.
- Tag DocumentDB clusters, activate cost allocation tags, and use Cost Explorer to break each cluster's cost into instance, storage and I/O to see the I/O share, as AWS recommends for this decision
- Chart the VolumeReadIOPs and VolumeWriteIOPs metrics (AWS/DocDB), which report billed cluster volume I/O, to see I/O volume trends per cluster
- Flag standard-storage clusters on DocumentDB 5.0 or later where I/O is consistently above about 25 percent of cluster cost
- Flag I/O-optimized clusters where modeled I/O at standard rates would stay well below 25 percent of cluster cost
- Note clusters on engine versions earlier than 5.0, which do not offer I/O-optimized storage and would need an upgrade first
How to fix
5 ways to remove the waste.
- Switch I/O-heavy clusters to I/O-optimized with modify-db-cluster --storage-type iopt1 or in the console; the change needs no downtime or reboot
- Switch light clusters back to standard storage, which is allowed at any time
- Before moving a cluster to I/O-optimized, confirm the analysis covers a representative period, because the next move to I/O-optimized is blocked for 30 days; describe-db-clusters shows when the next change is allowed
- Reduce I/O itself where possible, for example with indexes that avoid collection scans or an instance size whose buffer cache fits the working set, and re-run the comparison afterwards
- Review storage configuration periodically, since workload changes can move a cluster across the 25 percent threshold
Documentation
Vendor references for pricing and configuration.