# EBS volume modification limits and Atlas disk resize mechanics > Source-anchored research for EBS volume modification limits and Atlas disk resize mechanics. Run status: COMPLETED. Parent: [Oplog sizing under storage auto-scaling](https://llms-explorer.com/tree/oplog-sizing-under-storage-auto-scaling/) · 3 facets · 12 facts · page: https://llms-explorer.com/tree/ebs-volume-modification-limits-and-atlas-disk-resize-mechanics/ ## How it works - When Atlas provisions replacement AWS volumes for a disk increase, the cluster remains accessible, but a node being modified is unavailable until AWS attaches its new volume. The Atlas Review Changes page describes the chosen approach before a manual change is applied. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/customize-storage.md) - A July 5, 2023 firsthand CDK/CloudFormation experiment found that reconciling an already enlarged EBS volume to its existing size still issued ModifyVolume and encountered Client.VolumeModificationRateExceeded; a requested shrink failed because the new size was smaller. This is historical evidence about redundant requests and retries, not verification of a current mandatory six-hour wait. (low confidence) — [source](https://thomasquirke.com/2023/07/05/ebs-volume-modifications) ## Problems, failure modes and limitations - EBS cannot reduce a volume capacity in place. Atlas implements capacity decreases by provisioning replacement volumes and synchronizing data, with downtime on each node during synchronization; Atlas documents this replacement path regardless of elapsed time since the previous modification. (high confidence) (verified as of 2026-10-14) — [source](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modify-volume.html) ## Facts and statements - EBS permits up to four modifications per volume in a rolling 24-hour period. The volume must be in-use or available, and the previous modification must be completed before the next begins. This is a per-volume allowance, not a cluster-wide allowance. (high confidence) (verified as of 2026-10-30) — [source](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modify-volume.html) - AWS announced the four-modifications policy on January 15, 2026. A new modification may start immediately after its predecessor completes, provided fewer than four were initiated in the preceding 24 hours; a mandatory six-hour sleep is not the current AWS rule. (high confidence) (verified as of 2026-01-15) — [source](https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-ebs-up-to-four-volume-modifications/) - An EBS capacity increase becomes effective in optimizing, usually within seconds, before modification reaches completed. AWS describes completion as best effort and explicitly warns that duration is not always linear in volume size; six hours for a 1-TiB volume is an estimate, not a deadline. (low confidence) (verified as of 2026-10-30) — [source](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modify-volume.html) - Atlas documents the first AWS disk-size increase as an in-place data-volume modification without downtime. For subsequent increases, its table describes replacement and synchronization inside its timing thresholds and in-place modification after those thresholds: six hours below 1 TB, or six hours per TB above 1 TB. This is the Atlas-documented decision table, not proof that current EBS mandates those intervals. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/customize-storage.md) - Atlas distinguishes IOPS reduction from capacity reduction: after its documented modification waiting period, it can reduce IOPS in place without restarting nodes; otherwise it may provision replacement volumes and synchronize data, causing a rolling restart. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/customize-storage.md) - For non-NVMe M40+ AWS clusters, Atlas fast disk pre-warming temporarily provisions higher-performance storage during cloud-based initial sync. Returning that volume to its original storage settings consumes one of the four allowed EBS modifications, reducing the budget available for later storage changes. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md) - The Kubernetes SIG AWS EBS CSI driver documents coalescing size-expansion and attribute-modification RPCs into one EC2 ModifyVolume request to avoid unnecessary calls. Its controller waits for optimizing, while NodeExpandVolume separately resizes an existing filesystem. This is implementation evidence for that driver, not evidence of Atlas's internal implementation. (low confidence) (verified as of 2026-10-30) — [source](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/design.md) - EBS size increases take effect at optimizing, usually within seconds, before completed. Performance changes can take minutes to hours, and incompletely initialized volumes can take longer; elapsed time does not scale reliably with volume size. (high confidence) (verified as of 2026-10-30) — [source](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modify-volume.html) - Atlas documents the first AWS disk-size increase as an in-place change without downtime. For subsequent increases, its table describes replacement volumes and data synchronization below its waiting thresholds: six hours for volumes under 1 TB and six hours per TB for volumes over 1 TB. Affected nodes are inaccessible until AWS attaches the replacement volume, although the cluster remains accessible. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/customize-storage.md)