Use the following resources to configure and manage Atlas clusters.
View Your Clusters
Required Access
To view your clusters, you must have Project Read Only access or higher to the project.
Procedure
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.
Cluster Tiers
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.
Free Clusters and Flex Clusters
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:
Backups for your cluster data
Increased storage
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.
Considerations
Flex clusters don't have the full availability of features found in Dedicated clusters. To learn more, see Limits on Atlas Cluster Types.
Dedicated Clusters for Low-Traffic Applications
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.
Dedicated Clusters for High-Traffic Applications
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.
Gen2 Dedicated clusters
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:
80kIOPS for AWS160kIOPS 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
M30for a Gen1M30cluster.Use
M30_GEN_2for a Gen2M30cluster.
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.
Considerations
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,
M10andM20clusters are generation-agnostic. You don't select a cluster generation when you deploy anM10orM20cluster.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.
Compare Gen1 and Gen2 Clusters
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:
| Up to:
|
Cluster Tiers | All tiers |
|
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. |
Sharded Clusters
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.
Limitations
Every shard must have an equal disk size on all nodes. NVMe clusters are not compatible with independent shard scaling.
NVMe Storage
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 Considerations
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:
M40M50M60M80M200M400
The following cluster tiers support NVMe clusters on Azure:
M60M80M200M300M400M600
Atlas supports NVMe clusters in the following Azure regions:
Azure Region | Location | Atlas Region |
|---|---|---|
| São Paulo, Brazil |
|
| Toronto, ON |
|
| Iowa, USA |
|
| Virginia (East US) |
|
| Virginia, USA |
|
| Texas, USA |
|
| El Mirage, Arizona |
|
Azure Region | Location | Atlas Region |
|---|---|---|
| Paris, France |
|
| Ireland |
|
| Gävle, Sweden |
|
| London, England, UK |
|
| Netherlands |
|
Azure Region | Location | Atlas Region |
|---|---|---|
| New South Wales, Australia |
|
| Pune (Central India) |
|
| Saitama, Tokyo, Japan |
|
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 Availability Zones
NVMe clusters in the following Azure regions have two Availability Zones:
eastus2centralussouthcentralus
NVMe clusters in all other Azure regions that indicate Availability Zones have three Availability Zones.
Free, Flex, and Dedicated Cluster Comparison
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 | Full metrics, including the Real Time Performance Tab, and full alert configuration options. |
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 | |
Backups | No | Yes | |
Sharding | No | No | Yes, for clusters using an |
Dedicated Cluster | No, Free clusters run in a shared environment | No, Flex clusters run in a shared environment | Yes, |
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.
Take the Next Steps
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. | |
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 |