Running a MongoDB-Compatible Database with Amazon DocumentDB - Design Patterns and Scaling
You select an instance class for MongoDB-compatible DocumentDB and secure scalability with sharding through Elastic Clusters. This article also introduces backup strategies.
DocumentDB Features and Differences from MongoDB
DocumentDB is a managed document database that provides a MongoDB-compatible API. You can use MongoDB drivers, ODMs (such as Mongoose), and management tools (mongosh, Compass) as is. However, its internal architecture differs from MongoDB and uses a storage engine similar to Aurora's. Storage replicates six copies across three AZs and scales automatically in 10 GB increments (the upper limit is 256 TiB for engine version 8.0 or later and 128 TiB for earlier versions). Because DocumentDB is a fully managed service, you do not manage the operation of MongoDB replica sets or sharding yourself. On the other hand, some MongoDB features (client-side field-level encryption, some $graphLookup patterns, and so on) are not supported, so you need to verify compatibility before migrating.
Instance Design and Scaling
One example of a DocumentDB instance class is db.r6g, a memory-optimized class that uses Graviton2. The primary instance handles writes, and up to 15 read replicas distribute reads. Read replicas also function as failover targets and are automatically promoted when the primary fails. For large workloads, you use Elastic Clusters. Elastic Clusters automatically distributes data based on the shard key and supports petabyte-scale data and throughput of millions of operations per second. Because the shard key affects performance, you choose a field with high cardinality that matches your query patterns.
Backup and High Availability
DocumentDB automatically takes continuous backups to S3, and point-in-time restore is possible to any second within up to 35 days. Manual snapshots can be stored without a limit on the retention period, and cross-Region copies support DR. In a Multi-AZ deployment, the primary and read replicas are placed in different AZs, and failover during an AZ failure usually completes within 30 seconds. With global clusters, you can place read replicas in up to five Regions and promote a replica in another Region to primary during a Region failure. Replication lag is usually less than 1 second.
DocumentDB Pricing
DocumentDB pricing consists of instance hours, storage, and I/O. The db.r6g.large class costs approximately $0.277 per hour (approximately $199 per month) (as of August 2026). Storage costs approximately $0.10 per GB per month, and I/O costs approximately $0.20 per 1 million requests on Standard clusters. I/O-Optimized clusters have a storage unit price about 25% higher but charge nothing for I/O, so the total cost may go down for workloads with a lot of I/O. Elastic Clusters (sharding) costs approximately $0.1386 per vCPU-hour and scales with the number of shards.
Data Modeling and Index Design
DocumentDB is a document-oriented database, and you can flexibly represent related data by grouping it into one document. In design, you decide whether embedding or referencing is appropriate, starting from how the application reads and writes data. Embedding data that is frequently read together in one document reduces the number of reads, so you decide the scope of embedding by looking at the document size. You create appropriate indexes on fields used in search conditions to secure query performance. Because many indexes increase the cost of writes, you narrow them down to the indexes you need according to your actual query patterns.
Read Scaling and Replicas
DocumentDB can take a configuration that separates the primary instance, which handles writes, from the replicas that handle reads. For workloads with a high read load, you can raise throughput by adding replicas and distributing reads. One design is to route reads that need the latest value to the primary instance and reads that can tolerate some delay to replicas on the application side. When you handle many connections, you pool and reuse connections to reduce the overhead of establishing connections. Distributing the load according to read and write characteristics is the basis of scalable operations.
Migrating from MongoDB
DocumentDB is compatible with MongoDB, and you can use many existing drivers and tools as is. When you migrate, you first check whether the MongoDB version and features you use are supported in DocumentDB. Some features may not be supported, so you confirm before migrating that the application does not use those features. For data migration, using a migration service that lets you switch over while continuously capturing changes lets you keep downtime low. After migrating, you test whether you get the expected query performance and adjust indexes and configuration as needed to prepare for production.
Security and Operational Monitoring
DocumentDB is placed inside a VPC and controls access at the network level. Communication is encrypted with TLS, and stored data is also encrypted for protection. You decide how to handle database credentials and manage them, and you narrow access permissions to the necessary scope. If you enable the audit feature, you can record what operations were performed and trace unauthorized operations. On the operations side, you use a mechanism that visualizes performance to identify slow queries and resource bottlenecks and turn the findings into improvements. Together with backups, you set up an operations system that keeps checking security, availability, and performance.
Summary
DocumentDB is a service that runs a document database in a managed way with a MongoDB-compatible API. Its storage holds six copies across three AZs, and Elastic Clusters supports large workloads. When migrating from MongoDB, you check compatibility first, and after migration you can leave the operation of replica sets and sharding to AWS.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.