For AI agents: a documentation index is available at https://www.mongodb.com/docs/llms.txt — markdown versions of all pages are available by appending .md to any URL path.
Docs Menu

Manage Clusters

Use the following resources to configure and manage Atlas clusters.

To view your clusters, you must have Project Read Only access or higher to the project.

To list all clusters for your project using the Atlas CLI, run the following command:

atlas clusters list [options]

To return the details for the cluster you specify using the Atlas CLI, run the following command:

atlas clusters describe <clusterName> [options]

To learn more about the syntax and parameters for the previous commands, see the Atlas CLI documentation for atlas clusters list and atlas clusters describe.

To return the advanced configuration settings details for the cluster you specify using the Atlas CLI, run the following command:

atlas clusters advancedSettings describe <clusterName> [options]

To learn more about the command syntax and parameters, see the Atlas CLI documentation for atlas clusters advancedSettings describe.

To view all clusters in the Atlas UI, see View All Cloud Clusters. To view the details for a cluster, see View Cluster Details.

You can select a cluster tier when you create a new cluster or modify an existing cluster.

On Atlas Core clusters, the cluster tier sets the RAM, vCPUs, and storage for each data-bearing server [1] in the cluster. On Atlas Infinite clusters, the cluster tier sets the RAM, vCPUs, and IOPS for each node in the cluster.

On Atlas Infinite clusters, the cluster tier also fixes the storage IOPS and storage throughput values. These values don't change as the amount of data you store grows. To review the storage performance for each tier, see Atlas Infinite Storage IOPs and Throughput Values per Cluster Tier.

[1]

On Atlas Core clusters, data-bearing servers are the machines that run the nodes holding your application data. In a sharded cluster, each shard is a replica set whose members are the data-bearing servers. Sharded clusters may also use config servers, which are billed separately from the data-bearing servers.

On Atlas Infinite clusters, data-bearing servers don't apply. Atlas stores and manages your data in a storage layer that is separate from the compute layer. The electable, read-only, and analytics nodes are compute nodes that access data in the storage layer. To learn more, see MongoDB Atlas Infinite: Architecture.

Note

You might see different values depending on your selected cloud provider and region.

During public preview, Atlas Infinite clusters support the M10-M60 General cluster tiers and the M40-M60 Low-CPU cluster tiers. Atlas Infinite clusters don't support sharded clusters.

Atlas Core clusters support M10+ General cluster tiers and M40+ Low-CPU cluster tiers.

The following sections describe the differences between available cluster tiers.

Use Free clusters and Flex clusters as an economical way for getting started with MongoDB and for low-throughput applications. These clusters deploy to an environment with access to a subset of Atlas features. To learn more about Free cluster and Flex cluster limitations, see:

You can deploy one Free cluster (free sandbox replica set cluster) per Atlas project. You can scale a Free cluster to a Flex cluster or to a dedicated cluster at any time.

Flex clusters provide the following added features compared to Free clusters:

When you create a Free cluster or a Flex cluster, you can select Atlas Infinite or Atlas Core. The selection doesn't change your Free cluster or Flex cluster. Atlas stores the selection and applies it when you scale the cluster tier to a dedicated cluster, where you can optionally select a different edition. To learn more, see Scale a Free or Flex Cluster to a Dedicated Cluster.

Flex clusters don't have the full availability of features found in Dedicated clusters. To learn more, see Limits on Atlas Cluster Types.

M10 and M20 cluster tiers support development environments and production environments with low-traffic applications.

These cluster tiers support replica set deployments only, but otherwise provide full access to Atlas features.

Note

M10 and M20 cluster tiers use burstable performance infrastructure. Cloud providers cap CPU usage after burst periods, which can cause throttling under heavy load. To learn more, see How Atlas Scales Cluster Tier.

M30+ clusters are recommended for production environments.

These cluster tiers support replica set and sharded cluster deployments with full access to Atlas features.

Some clusters have variants, denoted by the ❯ character. When you select these clusters, Atlas lists the variants and tags each cluster to distinguish their key characteristics.

M30+ Atlas Core clusters are available in cluster generations Gen1 or Gen2 on AWS and Google Cloud. On Atlas Core clusters, Gen2 Dedicated clusters offer improved performance compared to Gen1 clusters and support Extended Standard IOPS, offering the following benefits:

  • Optimized price performance.

  • Newer hardware that enables long-term growth and avoids capacity restraints from older hardware.

  • Independent scaling of your cluster's standard IOPS and storage capacity with increased maximum standard IOPS rates:

    • 80k IOPS for AWS

    • 160k IOPS for Google Cloud

M30+ Atlas Infinite clusters are available on Gen2 only, and don't support Extended Standard IOPS. To learn more about how Atlas Infinite clusters handle storage and IOPS, see Manage Storage on an Atlas Infinite Cluster and Atlas Infinite Storage IOPs and Throughput Values per Cluster Tier.

When creating a new cluster through the Atlas UI, Atlas automatically selects the Gen2 option under the Cluster Tier section for eligible clusters. For an Atlas Core cluster, you can select Gen1 instead to deploy a Gen1 cluster.

Tip

Setting a cluster's generation using the Atlas Administration API or Atlas CLI

To specify a cluster's generation using the Atlas Administration API or Atlas CLI, use the instanceSize or --tier options, respectively.

Gen1 clusters use only the cluster tier in their names in the API and CLI, while Gen2 clusters use the cluster tier with _GEN_2 appended. For example, to deploy an M30 tiered cluster:

  • Use M30 for a Gen1 M30 cluster.

  • Use M30_GEN_2 for a Gen2 M30 cluster.

For a list of AWS and Google Cloud cluster tiers that support Gen2 clusters, see:

For existing clusters, you can switch between generations in the same way you would change your cluster's tier. To learn more, see Modify the Cluster Tier.

Before using Gen2 clusters, consider the following limitations. You can also Compare Gen1 and Gen2 Clusters.

  • Gen2 clusters are available only on AWS and Google Cloud. Gen2 Dedicated clusters are not available on Azure.

  • Multi-cloud support is not available for Gen2 Dedicated clusters.

  • Not all cloud provider regions support Gen2 Dedicated clusters. To learn more, see:

  • Cross-region support is available only if all regions in which you deploy your cluster support Gen2 clusters on your chosen cloud provider.

  • On Atlas Core clusters and Atlas Infinite clusters, M10 and M20 clusters are generation-agnostic. You don't select a cluster generation when you deploy an M10 or M20 cluster.

  • All nodes within a cluster must be of the same generation. You can't mix Gen1 and Gen2 nodes within the same cluster.

  • Gen2 clusters support only reactive auto-scaling, not predictive auto-scaling. To learn more, see Scaling a Gen2 Dedicated Cluster.

The following table lists the differences between Gen1 and Gen2 cluster generations:

Gen1
Gen2

Storage and Standard IOPS Expansion

Storage and Standard IOPS scale together

Storage and Standard IOPS scale independently

Maximum Standard IOPS [2]

Up to:

  • 16k IOPS for AWS

  • 100k IOPS for Google Cloud

Up to:

  • 80k IOPS for AWS

  • 160k IOPS for Google Cloud

Cluster Tiers

All tiers

M30+ only

Cloud Providers

AWS, Google Cloud, Azure

AWS, Google Cloud

Region Availability

All regions for a given cloud provider

For AWS, see Gen2 Region Support

For Google Cloud, see Gen2 Region Support

Cross-Region Deployments

Only across regions that support Gen2 clusters for the cloud provider you are using. See:

Auto-scaling

Reactive and predictive auto-scaling

Reactive auto-scaling only on Atlas Core clusters. Atlas Infinite clusters support reactive and predictive auto-scaling.

Cross-Cloud Deployment Support

Storage and IOPS scale together, so your bill reflects scaling for both.

Storage and IOPS scale independently, so your bill only reflects what you scaled.

[2] A cluster's maximum IOPS rate also depends on the tier and disk size. The maximum standard IOPS rates listed are the highest IOPS rates achievable through different tier and disk size configurations.

A sharded cluster distributes your data across multiple shards, each a replica set, to horizontally scale your Atlas deployment and efficiently handle growing data and workloads. To learn how to configure and manage sharding, see Manage Cluster Sharding.

You can use the Atlas Administration API to choose a different tier per shard in a sharded cluster. You can also select Analytics node tiers independently for each shard. The largest and smallest shard tiers must be within two tiers of each other. For example, if the largest shard is M50, the smallest shard can be M30 or M40. If you change the cluster tier for a sharded cluster in the Atlas UI, Atlas changes the tier of all shards in the cluster.

You can also use the Atlas Administration API to choose different IOPS per shard if the cluster is on AWS using AWS provisioned IOPS or the cluster is on Azure in regions that support Extended IOPS/storage.

Atlas Infinite doesn't support sharded clusters in public preview. For the features supported in public preview, see Public Preview Availability.

To learn more, see Manage Cluster Sharding and the Update One Cluster in One Project endpoint in the Atlas Administration API documentation.

Every shard must have an equal disk size on all nodes. NVMe clusters are not compatible with independent shard scaling.

For applications hosted on AWS or Azure that require low-latency and high-throughput I/O, Atlas offers storage options using locally attached ephemeral NVMe SSDs.

Note

Atlas doesn't support NVMe clusters on Google Cloud. NVMe clusters are not compatible with independent shard scaling.

NVMe instances can't be used in multi-cloud clusters.

Atlas Infinite doesn't support locally attached NVMe SSD storage in public preview. For the features supported in public preview, see Public Preview Availability.

The following cluster tiers support NVMe clusters on AWS:

  • M40

  • M50

  • M60

  • M80

  • M200

  • M400

The following cluster tiers support NVMe clusters on Azure:

  • M60

  • M80

  • M200

  • M300

  • M400

  • M600

Atlas supports NVMe clusters in the following Azure regions:

Azure Region
Location
Atlas Region

brazilsouth

São Paulo, Brazil

BRAZIL_SOUTH

canadacentral

Toronto, ON

CANADA_CENTRAL

centralus

Iowa, USA

US_CENTRAL

eastus

Virginia (East US)

US_EAST

eastus2

Virginia, USA

US_EAST_2

southcentralus

Texas, USA

US_SOUTH_CENTRAL

westus3

El Mirage, Arizona

US_WEST_3

Azure Region
Location
Atlas Region

francecentral

Paris, France

FRANCE_CENTRAL

northeurope

Ireland

EUROPE_NORTH

swedencentral

Gävle, Sweden

SWEDEN_CENTRAL

uksouth

London, England, UK

UK_SOUTH

westeurope

Netherlands

EUROPE_WEST

Azure Region
Location
Atlas Region

australiaeast

New South Wales, Australia

AUSTRALIA_EAST

centralindia

Pune (Central India)

INDIA_CENTRAL

japaneast

Saitama, Tokyo, Japan

JAPAN_EAST

The fixed-value storage space and RAM for an NVMe cluster corresponds to its cluster tier. To learn more, see Amazon Cluster Configuration Options and Azure Cluster Configuration Options.

Clusters with NVMe storage use Cloud Backups. You can't disable backup on NVMe clusters. If you want to use hourly backups, Atlas limits backups on NVMe clusters to once every 12 hours.

NVMe clusters use a hidden secondary node that consists of a provisioned volume with high throughput and IOPS to facilitate backup.

You can't pause an NVMe cluster.

On Atlas Core clusters, scaling of clusters (including auto-scaling) that use the local NVMe SSD storage option requires an initial sync, and always uses a File Copy Based Initial Sync to sync all the nodes of an NVME cluster whenever an initial sync is required. Atlas NVMe clusters auto-scale to the next higher tier when 90% of the storage space is full. An initial sync takes longer to complete compared to subsequent syncs, and reduces the performance of the primary from which the data is read.

NVMe clusters in the following Azure regions have two Availability Zones:

  • eastus2

  • centralus

  • southcentralus

NVMe clusters in all other Azure regions that indicate Availability Zones have three Availability Zones.

The following table highlights key differences between Free clusters, Flex clusters, and Dedicated Atlas Core clusters.

Free Clusters
Flex Clusters
Dedicated Clusters

Storage (Data Size + Index Size)

512 MB

5 GB

10 - 4000 GB

MongoDB Version Support

8.0

8.0

7.0, and Latest Release

Metrics and Alerts

Limited

Limited

VPC Peering

No

No

Global Region Selection

A subset of regions in AWS, Google Cloud, and Azure.

A subset of regions in AWS, Google Cloud, and Azure.

Atlas supports deploying clusters globally on Amazon Web Services, Google Cloud Platform, and Microsoft Azure.

Cross-Region Deployments

No

No

Yes. Specify additional regions for high availability or local reads when creating or scaling a cluster.

Backups

No

Yes

Sharding

No

No

Yes, for clusters using an M30+ tier

Dedicated Cluster

No, Free clusters run in a shared environment

No, Flex clusters run in a shared environment

Yes, M10+ clusters deploy each mongod process to its own instance.

Performance Advisor

No

No

Yes

BI Connector for Atlas

No

No

Yes

For a complete list of Free cluster limitations, see Atlas Free Cluster Limits.

To learn more, see Auto-Scaling for Atlas Clusters.

You can manage clusters in the following ways:

Action
Description

Customize the storage capacity of your cluster. Each cluster tier comes with a default set of resources. M10+ clusters provide the ability to customize your storage capacity.

Shard your cluster to scale horizontally. You can use the Atlas Cluster Builder UI, the latest version of the Atlas Admin API, Atlas CLI, or HashiCorp Terraform MongoDB Atlas Provider to shard your cluster.

You can also use the latest version of the Atlas Admin API to independently scale each shard in your cluster.

Configure the cluster tier ranges that Atlas uses to automatically scale your cluster tier, storage capacity, or both in response to cluster usage.

Configure additional cluster settings such as MongoDB version, backup, and encryption options.

Use resource tags that you provide and manage to categorize resources by purpose, environment, team, or billing center.

Reconfigure an existing cluster. Modify any of the available Atlas configuration options.

Manage major version upgrades for your cluster. Atlas enables you to upgrade the major version of an Atlas cluster at any time.

Configure maintenance windows for your cluster. You can set the hour of the day that Atlas should start weekly maintenance on your cluster.

Pause, resume, or terminate an existing cluster. You can't change the configuration of a paused cluster. Also, you can't read data from or write data to a paused cluster.

Configure multi-cloud distribution for increased availability. Atlas offers options to improve the availability and workload balancing of your cluster.

Use pre-defined replica set tags that Atlas provides to direct queries from specific applications to specific node types and regions. To use pre-defined replica set tags in your connection string and direct queries to specific nodes, set the tag in the readPreferenceTags connection string option.