> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Customize Atlas Core Cluster Storage **Note:** Atlas Infinite manages storage independently from compute and scales it separately, so the storage configuration options on this page apply to Atlas Core clusters. To learn what Atlas Infinite supports, see [Public Preview Availability.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-availability) On Atlas Core clusters, storage performance scales with storage capacity. On Atlas Infinite clusters, the cluster tier determines the storage IOPS (Input/Output Operations per Second) and storage throughput values. To review the storage performance for each tier, see [Atlas Infinite Storage IOPs and Throughput Values per Cluster Tier.](https://www.mongodb.com/docs/atlas/reference/amazon-aws.md#std-label-atlas-infinite-storage-iops-throughput-values) Each cluster tier comes with a default set of resources. `M10+` clusters provide the ability to customize your storage capacity. Atlas provides the following storage configuration options, depending on the selected cloud provider and cluster tier. ## Cluster Class `M40+` clusters offer multiple options, including: - Low CPU - General - Local NVMe SSD All production environments can use the General option. Select the Class box with your preferred speed. Changes to cluster class affect [cost.](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs.md#std-label-instance-size-costs) ### Low CPU Class Generally, the Low CPU option offers a lower-cost alternative for applications that require more memory and fewer CPUs. This option includes half the vCPUs of an instance with the General option of the same tier. For example, a General `M40` instance includes 4 vCPUs, while a Low CPU `M40` instance includes 2 vCPUs. Depending on the cluster tier, this option may also include fewer max connections. To learn more, see [Connection Limits and Cluster Tier.](https://www.mongodb.com/docs/atlas/reference/atlas-limits.md#std-label-connection-limits) **Note:** Atlas provisions storage for Low CPU and General clusters in gibibytes (GiB), despite the UI showing GB. ### NVMe Storage You can select the Local NVMe SSD storage option for some dedicated clusters that run on AWS (Amazon Web Services) or Azure (Microsoft Azure). Locally attached ephemeral [NVMe SSDs](https://www.mongodb.com/docs/atlas/nvme-storage.md#std-label-nvme-storage) offer the highest level of speed and performance. Atlas provisions storage for NVMe clusters in gigabytes (GB). On Atlas Core clusters, [a File Copy Based Initial Sync](https://www.mongodb.com/docs/manual/core/replica-set-sync/#file-copy-based-initial-sync) will always be used to sync all of the nodes of an NVME cluster whenever an initial sync is required. **Note:** Atlas doesn't support NVMe (non-volatile memory express) clusters on Google Cloud. ## Storage Capacity To change the server data volume size, do one of the following tasks: - Move the slider until the text box displays your preferred disk size. - Specify the exact disk size in the text box. For Azure (Microsoft Azure)-specific instructions, see [Change Storage Capacity and IOPS on Azure (Microsoft Azure).](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-change-storage-capacity-azure) Changes to storage capacity affect [cost.](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs.md#std-label-instance-size-costs) **Note:** MongoDB uses a small portion of your specified storage capacity for buffer files, journal files, and log files to ensure proper cluster operation. In no-overwrite storage engines like the [WiredTiger storage engine](https://www.mongodb.com/docs/manual/core/wiredtiger/), you should expect to use approximately 20% more disk space than your compressed data occupies. ### Oplog Size Behavior Atlas manages the cluster's [oplog size](https://www.mongodb.com/docs/manual/core/replica-set-oplog/#oplog-size) and its entries differently, depending on the cluster's database edition. - On an Atlas Infinite cluster, Atlas stores the oplog in the storage layer, and [Atlas Core storage auto-scaling](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-Atlas-Core-storage-auto-scaling) doesn't manage cluster storage. To learn more, see [Oplog on Atlas Infinite clusters.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-architecture.md#std-label-atlas-infinite-oplog) - On an Atlas Core cluster, oplog management depends on whether [storage auto-scaling](https://www.mongodb.com/docs/atlas/cluster-autoscaling-storage.md#std-label-howitworks-scale-cluster-storage) is enabled for the cluster: - Atlas enables cluster storage auto-scaling by default. If you choose to use storage auto-scaling, Atlas manages the oplog entries based on the [minimum oplog retention window (oplogMinRetentionHours)](https://www.mongodb.com/docs/manual/core/replica-set-oplog.md#std-label-replica-set-minimum-oplog-size) setting. The oplog entries are time-stamped. The oplog window is the time difference between the newest and the oldest timestamps in the oplog. By default, Atlas sets the minimum oplog retention window to 24 hours. This means that, unless you set the minimum oplog retention window to a particular custom value, the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) for the Atlas cluster retains all oplog entries for at least 24 hours and until the oplog reaches the maximum size that MongoDB best practices permit. You can [set the minimum oplog retention window](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-set-oplog-min-window) to a particular value in the Atlas UI. For storage auto-scaling to complete successfully, Atlas requires the [minimum oplog retention window (oplogMinRetentionHours)](https://www.mongodb.com/docs/manual/core/replica-set-oplog.md#std-label-replica-set-minimum-oplog-size) to be up to (60 seconds) \* (GB of disk space configured). If the cluster's storage capacity decreases, Atlas automatically scales the oplog size down to ensure it fits in the decreased storage size. **Note:** In some high-volume bulk write scenarios, such as migrations, the cluster might not maintain the configured minimum oplog retention window. Plan [migrations](https://www.mongodb.com/docs/atlas/import.md#std-label-import-strategies) and other write-intensive operations accordingly. - You can opt out of cluster storage auto-scaling by de-selecting the Storage Scaling checkbox in the Auto-scale section. If you opt out of storage auto-scaling, Atlas manages the oplog size as follows: - If you don't specify the oplog size in the UI, Atlas sets the oplog size to: - 5% of the disk size when you create a cluster, for General and Low-CPU clusters - 10% of the disk size for clusters with [NVMe storage.](https://www.mongodb.com/docs/atlas/nvme-storage.md#std-label-nvme-storage) For dedicated clusters that use EBS (non-NVMe) storage, Atlas automatically scales the oplog size to match the new disk size when you change the storage size. For clusters with [NVMe storage](https://www.mongodb.com/docs/atlas/nvme-storage.md#std-label-nvme-storage), oplog size is tied to the instance size rather than the disk size, since NVMe storage can't be resized independently. Atlas automatically syncs the oplog size with the new instance size when you change your cluster's tier. - You may choose to scale up the oplog size when you scale up the cluster's storage. In this case, manually [set the oplog size](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-set-oplog-size) to a particular value when you create a cluster. Atlas automatically scales the oplog size when you increase the cluster's storage, as follows: - For General and Low-CPU clusters, the oplog size scales up to remain at 5% of the storage capacity, not to exceed a certain maximum determined according to MongoDB best practices. - For clusters with NVMe storage, the oplog size scales up to remain at 10% of the storage capacity, not to exceed a certain maximum determined according to MongoDB best practices. - If you scale down the cluster's storage, Atlas uses the previous oplog-to-disk ratio to scale down the oplog proportionately. For example, if you scale from 100 GB to 50 GB with an oplog of 25 GB (ratio of 0.25), the new oplog size would also have a ratio of 0.25, which would make it 12.5 GB. The only exception is if the new oplog size is less than 5% of the storage capacity (or less than 10% for NVMe storage). In that case, Atlas uses the higher value for the oplog size, which would be 5% of the storage capacity (10% for NVMe storage). The oplog also affects auto-scaling differently on each edition: - On an Atlas Core cluster, Atlas delays an auto-scaling event until the oplog window covers the estimated scaling time. To keep the window from blocking scaling, [set the minimum oplog retention window.](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-set-oplog-min-window) - On an Atlas Infinite cluster, the [minimum oplog retention window](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-set-oplog-min-window) doesn't affect auto-scaling. To learn more, see [Oplog on Atlas Infinite clusters.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-architecture.md#std-label-atlas-infinite-oplog) ### Change Storage Capacity or IOPS on AWS Atlas handles changes differently based on whether you want to increase or decrease storage capacity or storage throughput (IOPS (Input/Output Operations per Second)) on AWS (Amazon Web Services). **Important:** You can make a maximum of 4 modifications per EBS volume within any 24-hour period. If you reach this limit, Atlas cannot modify that volume until the 24-hour window resets. On `M40+` AWS (Amazon Web Services) clusters that don't use [NVMe storage](https://www.mongodb.com/docs/atlas/nvme-storage.md#std-label-nvme-storage), Atlas consumes an EBS volume modification to support fast disk pre-warming during a Cloud-based initial sync. To learn more, see [Enable or Disable Fast Disk Pre-Warming.](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-disk-pre-warming) #### Increase Capacity or Throughput If previous changes are completed, AWS (Amazon Web Services) usually takes about six hours to increase storage capacity or IOPS (Input/Output Operations per Second). However, this time frame can vary depending on the data size stored on disk. To learn more, see the [AWS documentation](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-modifications.html#). Atlas supports more changes within the time frame for volume modification changes. AWS (Amazon Web Services) supports extended storage for clusters which meet the following criteria: - The cluster is an Atlas Core cluster. - The cluster is either General or Low-CPU class - The cluster is single-region. Extended Storage is not available for multi-region clusters. - Extended storage is available for `M40` tier and higher clusters with the following limitations: - `M40`: up to 4TB - `M50`/`M60`: up to 8TB - `M80+`: up to 14TB To change your cluster's tier, see [Modify an Atlas Core Cluster.](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-modify-cluster) If you enable extended storage, this slows down initial syncs and cross-project snapshot restores, and can reduce high availability. Enabling extended storage is a temporary solution for clusters that might require additional storage capacity in the future. We recommend that you enable [sharding](https://www.mongodb.com/docs/manual/sharding/) for long-term expanded storage capacity. How Atlas handles additional changes within a given period depends on AWS (Amazon Web Services) limits for EBS volume modifications. AWS (Amazon Web Services) restricts EBS volume size and throughput adjustments to a maximum of four modifications per volume within a rolling 24-hour period. After this limit is reached, Atlas delays additional storage capacity or IOPS (Input/Output Operations per Second) changes for that volume until AWS (Amazon Web Services) allows another modification. - For the first change, Atlas modifies data volumes in place without downtime when increasing disk size. - For subsequent disk size increases: | Data Volume Size | Time Since Last Storage Change | Action Atlas Takes | | --- | --- | --- | | Less than 1TB | Less than 6 hours | Atlas provisions new volumes and syncs the data from the old volumes. If Atlas provisions new volumes, you can access your cluster. You can't access *nodes* that AWS (Amazon Web Services) modifies until AWS (Amazon Web Services) attaches the new volume. | | Less than 1TB | 6 hours or more | Atlas waits until the cooldown period expires, then modifies the hosts' data volumes in place without downtime. | | More than 1TB | Less than volume modification cooldown period (6 hours per TB) | Atlas provisions new volumes and syncs the data from the old volumes. If Atlas provisions new volumes, you can access your cluster. You can't access *nodes* that AWS (Amazon Web Services) modifies until AWS (Amazon Web Services) attaches the new volume. | | More than 1TB | Volume modification cooldown period or more (6 hours per TB) | Atlas waits until the cooldown period expires, then modifies the hosts' data volumes in place without downtime. This takes less time than provisioning new volumes and syncing data from the old to the new volumes. If you modify the disk size within 4 hours of a previous disk modification, Atlas prioritizes compute upscaling first, then disk modification. | Before you apply your storage capacity or IOPS (Input/Output Operations per Second) increases, the Review Changes page describes how Atlas approaches the increase. The Clusters page displays a banner if Atlas is waiting for AWS (Amazon Web Services) to allow another volume modification before changing your cluster's storage capacity or IOPS (Input/Output Operations per Second): - Some EBS volume changes are delayed because AWS (Amazon Web Services) has reached the maximum number of allowed EBS volume modifications for this volume within a 24-hour period. These behaviors apply when Atlas changes capacity during [auto-scaling.](https://www.mongodb.com/docs/atlas/cluster-autoscaling.md#std-label-cluster-autoscaling) To learn more about AWS (Amazon Web Services)'s limitations, see the [AWS documentation.](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/modify-volume-requirements.html#elastic-volumes-limitations) #### Decrease Capacity or Throughput - AWS (Amazon Web Services) doesn't allow you to reduce storage *capacity* in place. Atlas *can* reduce storage capacity by first provisioning new volumes and then syncing data from the old to the new volumes with an in-place data sync process. This works around the AWS (Amazon Web Services) limitation, but there is downtime on each node during the sync. Unlike capacity increases, Atlas always uses this process for capacity decreases, regardless of the volume modification cooldown period. - AWS (Amazon Web Services) *does* allow you to reduce IOPS (Input/Output Operations per Second) without migrating data. If the volume modification cooldown period has passed, Atlas reduces IOPS (Input/Output Operations per Second) in place without restarting nodes. If the cooldown period has not passed, Atlas may provision new volumes and sync data, which causes a rolling restart. ### Change Storage Capacity and IOPS on Azure (Microsoft Azure) For Low CPU or General clusters deployed on Azure (Microsoft Azure), you can extend IOPS (Input/Output Operations per Second) and the data volumes' storage capacity in the Atlas UI. If you increase disk storage for Low CPU or General clusters, you can: - Receive more IOPS (Input/Output Operations per Second) on clusters in the same cluster tier. - Use these clusters for hosting applications with high IO workload requirements without having to configure sharding to spread the applications' workload across servers. **Note:** Not all Azure (Microsoft Azure) regions support extended storage. For details, see [supported regions.](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-storage-supported-regions) Azure (Microsoft Azure) has volume modification cooldown periods that might limit how frequently you can make storage changes. **Important:** For Azure (Microsoft Azure) clusters that support Extended Storage/IOPS, you can make up to four disk IOPS/throughput changes within any 24-hour period. If you reach this limit, Atlas replaces the virtual machine (VM) to bypass this limitation. The following statements describe the options you have in the Atlas UI for IOPS (Input/Output Operations per Second) and storage management on Azure (Microsoft Azure) clusters. 1. Initially, when you choose an Azure (Microsoft Azure) Low CPU or General cluster, Atlas assigns the default storage size and IOPS (Input/Output Operations per Second) based on the tier you choose. 2. Depending on the specific characteristics of the storage volumes used in your region and whether the cluster is in the [region that supports extended storage](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-storage-supported-regions), you can do one of the following actions: - If your region doesn't [support extended storage](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-storage-supported-regions), you can change storage capacity only in preset amounts and can't change the IOPS using the slider. - If your region [supports extended storage](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-storage-supported-regions), you can use the Storage slider to increase the default storage capacity within the same tier. Atlas also increases IOPS (Input/Output Operations per Second) to correspond to the increased storage size. 3. If, after you increase the storage volume's size, the increased number of IOPS (Input/Output Operations per Second) still isn't sufficient, and the cluster's tier is in a [region that supports extended storage](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-storage-supported-regions), you can further extend the number of IOPS (Input/Output Operations per Second) using the IOPS slider, without changing the cluster tier. 4. In addition, you can also expand the total cluster storage beyond the default limits for the cluster's tier in [regions that support extended storage](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-storage-supported-regions). You enable extended storage sizes in the [Project Settings.](https://www.mongodb.com/docs/atlas/tutorial/manage-project-settings.md#std-label-project-settings) **Note:** When increasing IOPS for a cluster deployed on Azure, values are limited to the cluster tier's maximum IOPS. The following sections describe how to increase the storage size and IOPS (Input/Output Operations per Second). - [Change Data Volume Size on Azure (Microsoft Azure)](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-change-storage-azure-steps) - [Configure Extended Storage/IOPS on Azure (Microsoft Azure)](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-extend-iops-azure-steps) #### Change Data Volume Size on Azure (Microsoft Azure) To change the server's data volume size: 1. [View the cluster details.](https://www.mongodb.com/docs/atlas/manage-database-deployments.md#std-label-view-cluster-details) 2. In the Cluster tier > Storage section, you can do one of the following actions, depending on the region: - If your region [supports extended storage](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-storage-supported-regions), move the slider to the right and choose your preferred disk size. The text box to the right of the slider changes dynamically and indicates the new disk size. Atlas also increases IOPS (Input/Output Operations per Second) to correspond to the increased storage size. - If your region doesn't support extended storage, you can increase the disk capacity in preset amounts. In this case, Atlas doesn't increase IOPS (Input/Output Operations per Second). For storage capacity increases, Atlas increases the storage capacity in place without copying data or performing an [initial sync.](https://www.mongodb.com/docs/manual/core/replica-set-sync/#initial-sync) **Note:** If you change to another region or to a multi-region cluster, the specific storage volume capabilities or extended storage might be unavailable. The Atlas UI notifies you that your IOPS (Input/Output Operations per Second) will be reduced. This change might impact the application's performance, the speed of restoring data from a backup, or copying backups from these regions to other regions. To preserve the same performance, continue using the same region. To learn more, see [regions that support extended storage.](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-storage-supported-regions) Azure (Microsoft Azure) doesn't allow decreasing the storage capacity in place. Atlas can reduce storage capacity by first provisioning new volumes and then syncing data from the old to the new volumes with an in-place data sync process. This works around the Azure (Microsoft Azure) limitation, but there is downtime on each node during the sync. Before you apply your storage capacity reductions, the Review Changes page notifies you that Atlas triggers a rolling restart of your cluster when you make this change. During this time, you can still access your cluster, but each node that Azure (Microsoft Azure) modifies remains unavailable until the node's data sync process completes. For large clusters, this process for each node might take several hours to complete. To expand the total cluster storage beyond the limits for the cluster tier, you can enable extended storage in the [Project Settings](https://www.mongodb.com/docs/atlas/tutorial/manage-project-settings.md#std-label-project-settings) for [regions that support extended storage.](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-storage-supported-regions) Azure (Microsoft Azure) supports extended storage for clusters which meet the following criteria: - The cluster is an Atlas Core cluster. - The cluster is either General or Low-CPU class - The cluster is single-region. Extended Storage is not available for multi-region clusters. - Extended storage is available for `M40` tier and higher clusters with the following limitations: - `M40`: up to 4TB - `M50`/`M60`: up to 8TB - `M80+`: up to 14TB To change your cluster's tier, see [Modify an Atlas Core Cluster.](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-modify-cluster) If you enable extended storage, this slows down initial syncs and cross-project snapshot restores, and can reduce high availability. Enabling extended storage is a temporary solution for clusters that might require additional storage capacity in the future. We recommend that you enable [sharding](https://www.mongodb.com/docs/manual/sharding/) for long-term expanded storage capacity. #### Configure Extended Storage/IOPS on Azure (Microsoft Azure) The following procedure describes how to obtain extended IOPS (Input/Output Operations per Second), **on top of** the number of IOPS that you receive when you [increase](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-change-storage-azure-steps) the storage size within the same cluster tier. You can change the number of IOPS (Input/Output Operations per Second) for `M40+` Atlas clusters for [regions that support extended storage.](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-storage-supported-regions) To extend the number of IOPS (Input/Output Operations per Second): 1. [View the cluster details.](https://www.mongodb.com/docs/atlas/manage-database-deployments.md#std-label-view-cluster-details) 2. In the Cluster tier, change to the `M40` or higher cluster tier. The IOPS (Input/Output Operations per Second) slider displays in the IOPS section. 3. If you haven't already, [increase](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-change-storage-azure-steps) the storage size. 4. If your application requires additional IOPS on top of increased IOPS that you received by increasing storage, you can extend IOPS further. Move the IOPS slider to the right and choose your preferred number of IOPS (Input/Output Operations per Second). Extending IOPS (Input/Output Operations per Second) affects [cost.](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs.md#std-label-instance-storage-speed) ### Change Storage Capacity on Google Cloud Google Cloud supports extended storage for clusters which meet the following criteria: - The cluster is an Atlas Core cluster. - The cluster is either General or Low-CPU class - The cluster is single-region. Extended Storage is not available for multi-region clusters. - Extended storage is available for `M40` tier and higher clusters with the following limitations: - `M40`: up to 4TB - `M50`/`M60`: up to 8TB - `M80+`: up to 14TB To change your cluster's tier, see [Modify an Atlas Core Cluster.](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-modify-cluster) If you enable extended storage, this slows down initial syncs and cross-project snapshot restores, and can reduce high availability. Enabling extended storage is a temporary solution for clusters that might require additional storage capacity in the future. We recommend that you enable [sharding](https://www.mongodb.com/docs/manual/sharding/) for long-term expanded storage capacity. Unlike AWS (Amazon Web Services), Google Cloud doesn't have volume modification cooldown periods. Therefore, storage changes can be made immediately without waiting for previous modifications to complete. When you increase a cluster's storage capacity, Atlas modifies the size of the servers' data volumes in a rolling manner with zero downtime. Atlas increases the storage capacity in place without copying data or performing an [initial sync.](https://www.mongodb.com/docs/manual/core/replica-set-sync/#initial-sync) However, Google Cloud doesn't allow in-place storage capacity reduction. If you reduce the storage capacity of a cluster, Atlas provisions new volumes, and then syncs data from the old to the new volumes with an in-place data sync process. This works around the Google Cloud limitation, but there is downtime on each node during the sync. Before you apply your storage capacity reduction, the Review Changes page notifies you that Atlas triggers a rolling restart of your cluster when you make this change. During this time, you can still access your cluster, but each node that Google Cloud modifies remains unavailable until the node's data sync process completes. For large clusters, this process for each node might take several hours to complete. Atlas has disk capacity limits on single replica sets, scaling up to 4 TB for higher cluster tiers. To expand the total cluster storage beyond default limits, you can enable extended storage in the [Project Settings](https://www.mongodb.com/docs/atlas/tutorial/manage-project-settings.md#std-label-project-settings). To accommodate further scaling in the future, enable [sharding](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-cluster-option-sharding) for long-term expansion. ### Change Storage Capacity for Multi-Cloud Provider Clusters Atlas selects the lowest common denominator across the three cloud providers. This ensures consistency across the multi-cloud deployment. You can't adjust the IOPS (Input/Output Operations per Second) for your multi-cloud cluster. ## IOPS Types `M30+` clusters offer different options for customizing the amount of IOPS (Input/Output Operations per Second), depending on the cluster's cloud provider and [cluster generation:](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-cluster-generation) - For clusters hosted on AWS (Amazon Web Services) you can use [Provisioned IOPS and High Performance IOPS](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-provisioned-high-perf-iops) for Gen1 and [Gen2 Dedicated clusters](https://www.mongodb.com/docs/atlas/manage-clusters.md#std-label-gen2-clusters), respectively. - For clusters hosted on either AWS (Amazon Web Services) or Google Cloud, you can use [Extended Standard IOPS](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-extended-iops-gen2) for [Gen2 Dedicated clusters.](https://www.mongodb.com/docs/atlas/manage-clusters.md#std-label-gen2-clusters) **Note:** For Gen1 `M40+` tier clusters, you can customize IOPS (Input/Output Operations per Second) only for clusters in the General and Low CPU classes. You cannot customize IOPS (Input/Output Operations per Second) for Gen1 clusters in the Local NVMe SSD class. ### Provisioned IOPS and High Performance IOPS for AWS-hosted Clusters Provisioned IOPS (Input/Output Operations per Second) and High Performance IOPS (Input/Output Operations per Second) let you customize the maximum IOPS (Input/Output Operations per Second) rate for your AWS (Amazon Web Services)-hosted cluster with additional performance benefits. Provisioned IOPS (Input/Output Operations per Second) and High Performance IOPS (Input/Output Operations per Second) refer to the same concept, though Gen1 clusters use Provision IOPS in the Atlas UI and Gen2 clusters use High Performance IOPS. For simplicity, we use **High Performance IOPS** to refer to both here. Standard IOPS (Input/Output Operations per Second) use AWS (Amazon Web Services) General Purpose SSD volumes, which are designed to deliver their baseline performance 99% of the time. High Performance IOPS (Input/Output Operations per Second) use AWS (Amazon Web Services) Provisioned IOPs SSD volumes, which are designed to deliver their provisioned performance 99.9% of the time. Compared to standard IOPS (Input/Output Operations per Second), High Performance IOPS (Input/Output Operations per Second): - Deliver their configured IOPS (Input/Output Operations per Second) rate more consistently. - Lower your cluster's p90 latency (measurement of the server's response time). 90 percent of server requests have responses faster than the p90 latency value, so a lower p90 latency value means a generally faster response time. To learn more, see: - [Amazon EBS volume types](http://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) - [Configure Provisioned IOPS and High Performance IOPS](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-config-provisioned-high-perf-iops) ### Extended Standard IOPS Gen2 Dedicated clusters on AWS (Amazon Web Services) or Google Cloud have a baseline minimum IOPS (Input/Output Operations per Second), on top of which you can provision additional IOPS (Input/Output Operations per Second): - For clusters with disk storage under `1000GB` (`1TB`), this baseline is `3000` IOPS (Input/Output Operations per Second). - For clusters with disk storage over `1000GB`, this baseline scales with storage at an IOPS (Input/Output Operations per Second)-to-`GB` ratio of 3:1. **Note:** Clusters hosted on AWS (Amazon Web Services) make a distinction between **Standard IOPS** and **Provisioned or High Performance IOPS**. This distinction stems from the cluster's underlying SSD volumes, and is exclusive to clusters hosted on AWS (Amazon Web Services). To learn more, see [Provisioned IOPS and High Performance IOPS.](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-provisioned-high-perf-iops) The following table shows non-exhaustive examples of how this baseline scales with various disk sizes: | Disk Storage | Baseline IOPS | | --- | --- | | `500GB` | `3000` | | `1000GB` | `3000` | | `2000GB` | `6000` | | `4000GB` | `12000` | To provision additional IOPS (Input/Output Operations per Second) for your cluster, you can use Extended Standard IOPS (Input/Output Operations per Second) for Gen2 clusters hosted on AWS (Amazon Web Services) or Google Cloud. Extended Standard IOPS (Input/Output Operations per Second) allow you to provision up to: - `80k` IOPS (Input/Output Operations per Second) for AWS Gen2 Dedicated clusters - `160k` IOPS (Input/Output Operations per Second) for GCP Gen2 Dedicated clusters As you increase IOPS (Input/Output Operations per Second), the cluster’s available disk throughput also increases. For Gen2 Dedicated clusters, you provision additional IOPS (Input/Output Operations per Second) and scale storage capacity independently, so scaling one doesn't necessitate scaling the other. Because provisioning additional IOPS (Input/Output Operations per Second) and scaling storage capacity are independent, Atlas bills for each separately. To learn more, see: - [Gen2 Dedicated clusters](https://www.mongodb.com/docs/atlas/manage-clusters.md#std-label-gen2-clusters) - [Configure IOPS for Gen2 Clusters](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-config-ext-standard-gen2-iops) ### Configure the IOPS Rate #### Standard IOPS for Gen1 Clusters If you want your IOPS (Input/Output Operations per Second) rate to scale automatically with your cluster's storage capacity, don't select Provision IOPS when you create your AWS (Amazon Web Services) Gen1 `M30+` tier cluster. The cluster uses standard IOPS (Input/Output Operations per Second) by default. If you want to provision an exact standard IOPS (Input/Output Operations per Second) value for your AWS (Amazon Web Services) cluster, see [Provisioned and High Performance IOPS.](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-config-provisioned-high-perf-iops) **Note:** Clusters hosted on AWS (Amazon Web Services) make a distinction between **Standard IOPS** and **Provisioned or High Performance IOPS**. This distinction stems from the cluster's underlying SSD volumes, and is exclusive to clusters hosted on AWS (Amazon Web Services). To learn more, see [Provisioned IOPS and High Performance IOPS.](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-provisioned-high-perf-iops) The minimum standard IOPS (Input/Output Operations per Second) for `M30+` tier clusters is 3000. The standard IOPS (Input/Output Operations per Second) value remains at 3000 unless you set the cluster storage size to 1TB or more. If the storage for your `M30+` cluster meets or exceeds 1TB, Atlas increases the standard IOPS (Input/Output Operations per Second) rate using an IOPS (Input/Output Operations per Second) to a storage ratio of 3:1, up to `16k` IOPS (Input/Output Operations per Second) for AWS (Amazon Web Services) network storage volumes. Gen1 Local NVMe (non-volatile memory express) SSD (Solid State Disk) class clusters must use standard IOPS (Input/Output Operations per Second). #### Extended Standard IOPS for Gen2 Clusters To provision additional IOPS (Input/Output Operations per Second) for your cluster, you can use Extended Standard IOPS (Input/Output Operations per Second) for Gen2 clusters hosted on AWS (Amazon Web Services) or Google Cloud. Extended Standard IOPS (Input/Output Operations per Second) allow you to provision up to: - `80k` IOPS (Input/Output Operations per Second) for AWS Gen2 Dedicated clusters - `160k` IOPS (Input/Output Operations per Second) for GCP Gen2 Dedicated clusters **Note:** Clusters hosted on AWS (Amazon Web Services) make a distinction between **Standard IOPS** and **Provisioned or High Performance IOPS**. This distinction stems from the cluster's underlying SSD volumes, and is exclusive to clusters hosted on AWS (Amazon Web Services). To learn more, see [Provisioned IOPS and High Performance IOPS.](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-provisioned-high-perf-iops) If your `M30+` tier Gen2 Dedicated clusters is hosted on AWS (Amazon Web Services), you must first select Standard next to IOPS under the Cluster Tier section. Then, you can either: - Specify the exact IOPS (Input/Output Operations per Second) rate in the text box, *or* - Move the slide bar below the IOPS (Input/Output Operations per Second) options until the text box displays your preferred IOPS (Input/Output Operations per Second) rate. #### Provisioned and High Performance IOPS High Performance IOPS (Input/Output Operations per Second) are supported only for `M30+` tier clusters on AWS (Amazon Web Services). To use High Performance IOPS (Input/Output Operations per Second) for your `M30+` tier AWS (Amazon Web Services) cluster, next to IOPS under the Cluster Tier section, select one of the following options: - Provision IOPS if you are using Gen1 clusters. - High Performance IOPS if you are using Gen2 cluster. Then, you can either: - Specify the exact IOPS (Input/Output Operations per Second) rate in the text box, *or* - Move the slide bar below the IOPS (Input/Output Operations per Second) options until the text box displays your preferred IOPS (Input/Output Operations per Second) rate. **Note:** The available provisioned IOPS (Input/Output Operations per Second) range for a Gen1 cluster relates to disk [storage capacity](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-storage-capacity-ui). Changing your Gen1 cluster's storage capacity changes the range of available provisioned IOPS (Input/Output Operations per Second). The available High Performance IOPS (Input/Output Operations per Second) range for a Gen2 cluster is unrelated to disk [storage capacity.](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-storage-capacity-ui) ### Minimum Disk Capacity to RAM Ratios Atlas enforces the following minimum ratios for given cluster tiers. This keeps cluster performance consistent with large datasets. Instance sizes **M10** to **M40** have a ratio of disk capacity to system memory of 60:1. Instance sizes greater than **M40** have a ratio of 120:1. **Example:** To support 3 TB (or 3,072 GB) of disk capacity, select a cluster tier with a minimum of 32 GB of RAM. This would be **M50** or greater. Atlas has disk capacity limits on single replica sets, scaling up to 4 TB for higher cluster tiers. To expand the total cluster storage beyond default limits, you can enable extended storage in the [Project Settings](https://www.mongodb.com/docs/atlas/tutorial/manage-project-settings.md#std-label-project-settings). To accommodate further scaling in the future, enable [sharding](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-cluster-option-sharding) for long-term expansion. **See also:** To learn more about the default resources and available configuration options for each cloud service provider, see: - [AWS Configuration Options](https://www.mongodb.com/docs/atlas/reference/amazon-aws.md#std-label-amazon-aws-configuration-options) - [GCP Configuration Options](https://www.mongodb.com/docs/atlas/reference/google-gcp.md#std-label-google-gcp-configuration-options) - [Azure Configuration Options.](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-configuration-options) ## Auto-Scale Cluster Tier and Storage Capacity Atlas cluster tier reactive auto-scaling is available for all dedicated Atlas Core cluster tiers under the General and the Low-CPU cluster classes. Reactive auto-scaling is also available for Atlas Infinite clusters. For new clusters, Atlas automatically enables cluster tier auto-scaling and storage auto-scaling. Use Auto-scale options to configure your cluster to automatically scale your cluster tier, storage capacity, or both in response to cluster usage. **Important:** For dedicated Atlas Core clusters, if you restore a snapshot with a larger size than the storage capacity of the destination cluster, the cluster does not automatically scale. You can [opt out](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md#std-label-opt-out-autoscaling) of cluster tier and storage auto-scaling. To learn more, see [How Atlas Scales Cluster Tier](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md#std-label-howitworks-scale-cluster-tier) and [How Atlas Scales Cluster Storage on Atlas Core.](https://www.mongodb.com/docs/atlas/cluster-autoscaling-storage.md#std-label-howitworks-scale-cluster-storage) **See also:** - [Auto-Scaling for Atlas Clusters](https://www.mongodb.com/docs/atlas/cluster-autoscaling.md#std-label-cluster-autoscaling) - [Connection Limits and Cluster Tier](https://www.mongodb.com/docs/atlas/reference/atlas-limits.md#std-label-connection-limits)