Control MongoDB Atlas Cluster Configurations With Resource Policies

Editor's note: This post is the fifth in a series exploring how MongoDB Atlas Resource Policies help you strengthen database security and enforce consistent guardrails across your organization. Read the first post on IP access list management, the second on defense-in-depth strategies, the third on blocking wildcard IP access, and the fourth on cloud provider and region restrictions.

The configuration drift problem

Picture this: Your engineering team deploys a sharded cluster with just one shard for a proof-of-concept (POC) project. The POC succeeds and quietly transitions into production. Months pass, but the cluster architecture remains unchanged. Since it only has one shard, it provides none of the horizontal scalability benefits sharding was designed to deliver. You discover this when a customer complains about performance.

Other examples are just as common. A developer provisions a cluster with 10 TB of storage “just to be safe,” far exceeding actual requirements and your organization’s cost policies. Or perhaps teams create global clusters for single-region applications, paying for multi-region complexity they don’t need.

These scenarios aren’t isolated incidents. Without enforceable standards, MongoDB Atlas cluster configurations can drift away from architectural best practices and organizational policies. MongoDB Atlas Resource Policies solve this by making architectural standards technically enforceable, preventing configuration mistakes before clusters are deployed.

The importance of cluster configuration governance

Storage and compute resources are significant investments in your database infrastructure. When teams can provision resources without guardrails to enforce organizational standards, it becomes more challenging to optimize spending and accurately forecast capacity needs. 

MongoDB Atlas Resource Policies address this by defining and enforcing which cluster configurations are allowed across your organization, including approved cluster topologies (replica set, sharded, or global clusters) and minimum shard counts. These guardrails guide teams toward decisions that align with your architectural goals while creating the predictability needed for accurate capacity planning. 

Architectural decisions made during cluster creation have lasting performance implications. A sharded cluster deployed with insufficient shards creates bottlenecks that are painful to fix later. Conversely, choosing a replica set when a sharded cluster is needed means complex migrations when scale requirements increase. Enforcing standards from the start prevents these costly migrations.

Every unique cluster configuration variant increases operational overhead. Different topologies can require different monitoring strategies, backup procedures, and troubleshooting approaches. Standardization through MongoDB Atlas Resource Policies reduces complexity, making it easier to operate databases at scale.

MongoDB Atlas cluster configuration controls

Let’s explore the specific policies you can implement to control your MongoDB Atlas cluster configuration. 

Policy #1: Enforce disk size limits

Storage costs often scale linearly with provisioned disk size. Without guardrails, teams frequently overprovision dramatically, for example, allocating 10 TB when 500 GB would suffice. This wastes money and obscures actual capacity requirements.

What it does

This policy prevents anyone from creating or modifying clusters with disk sizes exceeding 4 TB (4096 GB). Any attempt to configure larger storage is automatically blocked, forcing development teams to justify exceptional requirements through a formal exception process.

When to use this

Implement disk size policies when you want to prevent accidental overprovisioning during cluster creation, enforce cost boundaries for different environment types (e.g., development clusters limited to 500 GB while production reaches 4 TB), or require architectural review for exceptionally large clusters. Organizations in the scaling phase benefit particularly from this guardrail, as it forces intentional decisions about when to shard data across multiple clusters.

Start by auditing current cluster storage usage to understand typical requirements. Set your initial limits conservatively high—perhaps 2x your current largest cluster—to avoid disrupting existing workflows. And consider implementing tiered policies where different MongoDB Atlas Organizations may have different limits based on their use cases.

Policy #2: Enforce cluster topology

MongoDB Atlas supports three cluster topologies: replica sets, sharded clusters, and global clusters. Teams often choose based on familiarity rather than requirements, which can create unnecessary operational complexity or necessitate painful migrations later.

What it does

This example policy enforces that all clusters must be replica sets, automatically blocking attempts to create sharded or global clusters. Organizations can modify the policy to require sharded clusters instead.

Available cluster types

• Replica set: ResourcePolicy::ClusterType::"replicaset" - Best for most applications requiring high availability without horizontal partitioning

• Sharded cluster: ResourcePolicy::ClusterType::"sharded" - Used for horizontal scaling when data volumes or throughput exceed single replica set capabilities

• Global cluster: ResourcePolicy::ClusterType::"geosharded" - Designed for globally distributed applications requiring location-aware data placement

When to use this

Early-stage startups might standardize on replica sets exclusively because they simplify operations and serve most use cases. As organizations mature, they might allow both replica sets and sharded clusters, but prohibit global clusters unless specific geographic distribution requirements are documented.

Organizations with limited operational experience should implement these policies. The operational complexity of sharded and global clusters requires some expertise. By standardizing on replica sets initially, you can build operational maturity before expanding to more complex topologies.

Policy #3: Enforce minimum shard counts

MongoDB Atlas allows sharded clusters to be created with just one shard. While this makes sense for testing, it defeats the purpose of sharding entirely. A single-shard “sharded” cluster carries all the operational overhead—mongos routers, config servers, balancer operations—without providing the benefits you are looking for.

What it does

This policy requires sharded clusters to have at least three shards and denies the use of replica sets (since all replica sets have only one shard), preventing the deployment of under-sharded configurations. The policy includes an important exception: !context.cluster.isConvertingToSharded. This exception allows existing clusters to transition through a temporary single-shard state during replica set to sharded cluster conversions.

Critical implementation notes

When enforcing minimum shard counts greater than one, you must explicitly allow the transitional state during conversions using !context.cluster.isConvertingToSharded. Without this exception, MongoDB Atlas would block users from converting replica sets to sharded clusters.

MongoDB Atlas treats replica sets as having a shard count of one internally. The policy above avoids marking replica sets as noncompliant by only evaluating when isConvertingToSharded is specified.

Only use minShardCount to enforce minimums and maxShardCount to enforce maximums. Doing otherwise can cause policy evaluation errors.

When to use this

Implement minimum-shard-count policies when your organization has adopted sharded clusters and wants to ensure they are deployed properly. If you have had to add shards reactively during production incidents, enforcing minimums from the start prevents repeating that experience.

Three shards represent a good minimum for most organizations. It provides meaningful horizontal distribution while keeping operational complexity manageable. Organizations with extremely high throughput requirements may enforce higher minimums to ensure adequate distribution from the outset.

Combined policies for comprehensive governance

The true power of MongoDB Atlas Resource Policies emerges when multiple controls are layered together. A financial services organization might combine disk size limits, topology requirements, and shard count minimums with additional controls like cluster tier restrictions to create a comprehensive governance framework.

Example: Production cluster standards

These policies create multiple independent barriers to configuration problems. The disk size limit controls storage costs. The sharded cluster requirement ensures production deployments can scale horizontally. The minimum shard count prevents under-sharded deployments. The cluster tier restriction ensures production clusters use appropriately sized instances: not too small (below M30) to handle production workloads, and not unnecessarily large (above M60) without architectural review. The region restrictions meet data residency requirements. The wildcard blocking prevents network security violations.

Each policy addresses a different concern, and when used together, they create a production environment where misconfigurations are technically impossible, rather than simply discouraged.

Your path forward

Cluster configuration governance transforms database provisioning from reactive to proactive architecture enforcement. By codifying standards as MongoDB Atlas Resource Policies, you ensure every cluster deployed adheres to best practices for cost, performance, and operational consistency.

Start taking control of your cluster configurations today. Your future self—the one managing a fleet of properly configured databases rather than a collection of architectural one-offs—will thank you.

Additional resources

• MongoDB Atlas Resource Policies documentation

• Cedar policy language guide

• Sharding in MongoDB Atlas

• MongoDB Atlas Administration API reference