AWS DocumentDB Cluster Builder

About This Tool

Build a DocumentDB (MongoDB-compatible) cluster with a writer/reader instance topology spread across AZs, storage encryption via a customer-managed KMS key, and EnableCloudwatchLogsExports for audit and profiler logs, which aren't captured anywhere by default. DocumentDB's replication model is important to know going in: it's a single-writer, multi-reader architecture built on a distributed, auto-scaling cluster storage volume (similar to Aurora's architecture), not genuine multi-region multi-master, and it's MongoDB API-compatible up to specific supported MongoDB versions, not a literal MongoDB fork, meaning some MongoDB-specific features and driver behaviors aren't identical.

When to Use This Tool

• •Spreading Instances across three distinct AvailabilityZones (as the example does) so a single AZ failure only removes one instance from the cluster rather than threatening overall availability, since DocumentDB's single-writer model means the specific writer instance's AZ matters for failover speed.
• •Enabling EnableCloudwatchLogsExports for both audit and profiler logs specifically, since neither is captured by default, a compliance requirement needing database audit trails or a performance investigation needing slow-query profiling both require this to be explicitly turned on ahead of time, not retroactively.
• •Setting DeletionProtection true on a production cluster so an accidental terraform destroy or console deletion attempt is blocked, requiring an explicit, deliberate step to actually disable protection before deletion can proceed.
• •Using a smaller DBInstanceClass for one read replica (db.r6g.large versus db.r6g.xlarge for the others) when that replica serves a lighter, specific read workload (like reporting queries) that doesn't need the same capacity as the primary read path.

Pro Tips

How It Works Under the Hood

Frequently Asked Questions

Is DocumentDB actually running MongoDB under the hood?

No, it's a purpose-built, AWS-native database engine that implements the MongoDB API for compatibility up to specific supported MongoDB wire-protocol versions, it isn't a fork or repackaging of the actual MongoDB codebase. Most application code using standard MongoDB drivers works against it, but some MongoDB-specific server-side features, aggregation pipeline stages, or newer MongoDB version features may not have an equivalent, verify feature compatibility for anything beyond basic CRUD and common aggregation operations.

What's the impact of not enabling EnableCloudwatchLogsExports?

Without it, DocumentDB doesn't export audit logs (tracking who did what, needed for many compliance frameworks) or profiler logs (needed to investigate slow queries) to CloudWatch Logs at all, they're simply not captured anywhere accessible. This has to be enabled proactively, if you discover you need audit history during an incident and it wasn't enabled beforehand, that history doesn't exist retroactively.

Can I add more read replicas to an existing cluster without downtime?

Yes, adding a new read instance to an existing DocumentDB cluster doesn't require downtime for the existing writer or other readers, it's an online operation that provisions a new instance and joins it to the cluster's shared storage volume, existing traffic to the writer and other readers continues uninterrupted during the addition.

Related Learning Guides

• S3 Storage Classes Explained24 min read
• DynamoDB Data Modeling28 min read