Amazon DocumentDB Core Architecture

In the previous lesson, you built a foundation around document databases, shared cluster volumes, endpoints, replicas, and data-protection basics. This lesson shifts from concepts to production behavior, examining how Amazon DocumentDB instance-based clusters actually operate under load, scale, fail over, and manage storage costs. Understanding these mechanics is essential for the AWS Database Specialty exam and for anyone designing resilient document workloads on AWS because the architecture of DocumentDB drives every operational decision, from connection management to billing optimization.

How DocumentDB separates compute and storage

A self-managed MongoDB deployment on EC2 ties each node to its own data copy. Every replica maintains a full copy of the dataset, and scaling out means replicating data to yet another node. Amazon DocumentDB takes a fundamentally different approach by decoupling compute instances from a single shared cluster storage volume. The shared cluster volumeA distributed, fault-tolerant storage layer that spans multiple Availability Zones and is accessed by all compute instances in the cluster without each instance maintaining its own data copy. sits beneath every instance in the cluster, and all instances read from and write to this same layer.

The cluster contains one primary instance that handles both reads and writes, alongside up to fifteen read replicas that handle read traffic only. Every one of these instances points at the identical underlying storage. This separation produces a critical operational benefit: when you add a replica or resize an instance, no data copying occurs. Compute scales independently of storage capacity, and storage capacity is independent of how many instances exist.

Attention: A common exam distractor states that each DocumentDB replica maintains its own storage copy. This is false. All replicas share the same cluster volume, which is why adding replicas does not increase storage consumption.

Two ...