Elastic Clusters

Even well-designed documents and indexes, as explored in the previous lesson on schema and query design, eventually hit a vertical ceiling. A single writer instance in an instance-based Amazon DocumentDB cluster can only absorb so much write throughput, no matter how many read replicas sit behind it or how large the instance class becomes. When the workload demands millions of reads and writes per second, tens of thousands of concurrent connections, or storage that pushes past 128 TiB, the instance-based model runs out of room. This is the exact boundary where Amazon DocumentDB elastic clusters take over as the AWS-native horizontal scale-out architecture for MongoDB-compatible document workloads.

An instance-based cluster scales reads by adding replicas and scales compute by upgrading to a larger instance class, but write throughput remains bound to one primary node. Connection limits are fixed per instance, and the shared cluster storage volume caps at 128 TiB. For moderate workloads, this model is efficient and operationally simple. For workloads that need petabyte-scale storage, aggregate write throughput across many parallel writers, or connection counts that exceed what any single instance can offer, the architecture must change fundamentally.

Attention: A common exam trap asks about MongoDB-compatible workloads that need massive horizontal write scaling. The correct answer is elastic clusters, not adding more read replicas, not migrating to DynamoDB, and not running self-managed MongoDB on EC2. Replicas only scale reads, DynamoDB is not MongoDB-compatible, and self-managed MongoDB shifts operational burden without leveraging the managed elastic cluster capability.

An elastic clusterA DocumentDB deployment model that distributes data and compute across multiple shards, enabling horizontal scaling of both reads and writes beyond the limits of a single-writer instance-based cluster. replaces the single-writer model with a multi-shard architecture, where each shard processes its own portion of the data. The shard key determines how documents are distributed, while unsharded collections remain on a single shard. These concepts form the foundation for every capacity planning and design decision in elastic clusters.

The following diagram illustrates the architectural difference between the two cluster models.

With the architectural ...