# Independent shard scaling and per-shard tiering > Source-anchored research for Independent shard scaling and per-shard tiering. Run status: COMPLETED. 7 facets · 63 facts · page: https://llms-explorer.com/tree/independent-shard-scaling-and-per-shard-tiering/ ## Definitions - Zones are the supported way to steer data onto particular shards. A zone maps shard-key ranges to one or more shards. The balancer moves chunks that fall in a zone range only to shards in that zone. A document that matches a zone can be written only to a shard in it; a document that matches no zone can land on any shard. The MongoDB manual lists routing data by shard hardware or performance as a common zone use. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding/) - Resizing a shard is a rolling change. Atlas documents zero downtime for tier changes up or down: it elects a secondary as the new primary, then replaces the old member. Reverting an asymmetric cluster to symmetric tiers starts a rolling resize of all shards. Expect a primary election on each shard that is resized. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-independent-shard-scaling/) - Atlas NVMe clusters are not compatible with independent shard scaling. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/atlas/nvme-storage/) - Atlas deploys Search Nodes per shard: two Search Nodes on a three-shard cluster means six Search Nodes. The docs describe one node-count and node-size setting, from 2 to 32 nodes per region per shard, and document no per-shard Search Node tier. A Feb 2025 feedback idea asks to scale Search Nodes per shard (for example none on two shards and S40 on a third). It still showed status Submitted, 3 votes and no reply on 2026-10-20. (medium confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options/) ## How it works - Per-shard auto-scaling is not active on every cluster. Terraform configs written before v1.23.0, clusters imported from the legacy schema, and configs moved straight from v1.x to v2.0.0 may lack shard-level auto-scaling until an update triggers it, for example by temporarily changing compute_min_instance_size. For UI-managed clusters that enabled compute auto-scaling before the default changed, the Atlas docs say to contact MongoDB support to get independent scaling. (medium confidence) (verified as of 2026-10-20) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/guides/advanced-cluster-new-sharding-schema.md) - SERVER-2218, 'Make sharding balancer smarter when asymmetric hardware', asks for a shard-size-aware balancer. Its example: 2 TB shards extended with 3 TB shards leave the extra 1 TB unused. The ticket was created 2010-12-14 and last updated 2023-11-17. It is Unresolved in Backlog with no fix version and shows no engineer comments. (low confidence) (verified as of 2026-10-20) — [source](https://jira.mongodb.org/browse/SERVER-2218) - Adding or removing zones or zone ranges triggers chunk migrations that can hurt cluster performance. The manual says to disable the balancer on the whole cluster while defining zones, then run the balancer in a scheduled balancing window. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas/) - use_effective_fields = true has no effect on clusters with more than one replication_specs entry, and the provider docs recommend not enabling it on multi-shard clusters. Multi-shard clusters with auto-scaling therefore still need lifecycle.ignore_changes for instance_size, disk_size_gb and disk_iops, and the docs warn not to rely on list-index ignore_changes when the shard topology changes. (medium confidence) (verified as of 2026-10-20) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/resources/advanced_cluster.md) - Building block for placing a collection on a chosen shard: MongoDB 8.0 moveCollection moves one unsharded collection to a named shard (toShard) when run on mongos against the admin database. Limits: unsharded collections only, one at a time, 5-minute minimum duration, Search indexes become unavailable and must be rebuilt, Atlas Online Archive files are marked Orphaned, and topology changes are blocked until the move ends. (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/moveCollection/) - Per-shard scaling did not cover dedicated Atlas Search nodes when a customer filed an idea on 2025-02-08 asking for search nodes on only some shards (example: none on shard-0 and shard-1, an S40 on shard-2), noting electable nodes already scale per shard. On 2026-10-20 the idea showed status Submitted, 3 votes and no MongoDB response. (low confidence) (verified as of 2026-10-20) — [source](https://feedback.mongodb.com/ideas/CUSTOMER-I-6138) - The Atlas docs say the largest and smallest shard tiers must stay within two tiers of each other (if the largest shard is M50, the smallest can be M30 or M40). When auto-scaling raises the largest shard, Atlas also raises smaller shards as needed to keep that spread. The docs also say the minimum and maximum auto-scaling tier apply at the cluster level. (medium confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core/) - Neither the balancer docs nor Percona's description of the balancer mention weighting data by shard tier or capacity. SERVER-2218, "Make sharding balancer smarter when asymmetric hardware", has been open since 2010-12-14, showed Unresolved and Backlog on 2026-10-20, and has 13 votes. Its example says that adding 3 TB shards to a set of 2 TB shards leaves only 2 TB of each larger shard in use. A 2020 reply on MongoDB's feedback portal (signed "Andrew", role not shown) said "MongoDB Sharding is built on the assumption of symmetrically sized shards." Inference: a bigger tier on one shard does not make the balancer place more data there, so per-shard tiering helps only where load skew already maps to specific shards. (medium confidence) (verified as of 2026-10-20) — [source](https://jira.mongodb.org/browse/SERVER-2218) - In a self-managed sharded cluster, zones tie shard-key ranges to chosen shards, and a shard can belong to many zones. MongoDB's tiered-hardware tutorial puts recent data in a "recent" zone of fast machines (large RAM, fast SSD, strong CPUs) and older data in an "archive" zone of machines with less RAM, slower disks and more storage per server. A document that matches a zone range can only be written to a shard in that zone. The balancer moves chunks to respect zones, and changing zones or ranges triggers migrations, so MongoDB suggests scheduling a balancing window. A third-party example (OneUptime, 2026-01-30) maps HOT to NVMe SSD shards, WARM to standard SSD shards and COLD to HDD shards with `sh.addShardToZone()` and `sh.updateZoneKeyRange()`; that article's diagram and code disagree on the tier boundaries. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas/) - Inference: a time-ranged zone design sends all new writes to the fast tier. MongoDB's tutorial shards on `{ creation_date: 1 }` and sends documents in the "recent" range only to the recent-zone shards. Netdata lists a monotonically increasing shard key as a leading cause of write hotspots, because new writes land on the max-value chunk. Size the fast-tier shards for the full write rate, not for a fair share. (low confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas/) - Practitioners pair per-shard tiers with region-aligned zones so that a tier change hits only the busy region. MongoDB's launch post gives "only the shards serving US traffic during Thanksgiving" as its example. A Feb 2026 Medium write-up builds a geo-sharded Atlas cluster with two shards in a Mumbai zone and one shard in a US zone, shard key `{ region: 1, email: 1 }`, auto-scaling from M30 to M40, and sizes tiers per region through Terraform variables. (medium confidence) — [source](https://mongodb.com/blog/post/mongodb-atlas-introduces-enhanced-cost-optimization-tools) ## How-to and procedures - To return an asymmetric cluster to cluster-wide scaling: fetch the cluster, pick one shard as the template (the docs recommend the highest-tier shard for continuity of performance), then send one Update One Cluster in One Project PATCH that gives every shard the template's instanceSize for each role and the same disk settings (diskSizeGB, ebsVolumeType, diskIOPS). The payload must keep the existing shard id values. Atlas then runs a rolling resize of all shards. After symmetry returns, the 2024-10-23 API resource version (symmetric replicationSpecs.numShards model) can manage the cluster again. (low confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-independent-shard-scaling/) - To revert a cluster from independent to cluster-wide scaling, read the per-shard `replicationSpecs` with the Return One Cluster endpoint. Pick one shard as the template (MongoDB recommends your highest-tier shard). Then send an Update One Cluster PATCH that gives every shard the same instance sizes, disk size, volume type and IOPS, and keeps each shard `id`. Atlas then runs a rolling resize of all shards. (low confidence) — [source](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-independent-shard-scaling/) ## Measurements and reference values - The balancer does not weight shards by capacity. It watches the amount of data per shard for each sharded collection and migrates ranges to reach an even amount of data per shard, while respecting zones. Since MongoDB 6.0 it counts real data size, not chunk count. Migration starts only when two shards differ by at least three times the range size (384 MB at the default 128 MB). Inference from this target: a larger-tier shard does not receive proportionally more data unless zones or manual placement steer it. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/sharding-balancer-administration/) - The 2024-10-31 announcement (updated 2025-03-05) gives no pricing, savings percentages or benchmarks for independent shard scaling. Its cost language is qualitative ('cost-optimal', 'cost-optimization'). The numbers in the post (5X auto-scaling responsiveness, 512% Cyber Monday traffic, 13X spike, 4 TB storage) do not describe this feature. (low confidence) — [source](https://www.mongodb.com/company/blog/product-release-announcements/mongodb-atlas-introduces-enhanced-cost-optimization-tools) - Before you raise one shard's tier, find out why that shard is hot. Netdata's hot-shard guide lists the usual causes: a monotonically increasing shard key, a low-cardinality shard key, jumbo chunks, and temporal read hotspots on recent data. Its durable fixes are resharding or zones, not bigger hardware. Netdata also gives its own rules of thumb, which are not MongoDB limits: treat a shard that serves over 40% of an operation type as a hotspot, alert when one shard's latency exceeds 2x the cluster mean, and size each shard for 1.5x its fair share. (medium confidence) — [source](https://www.netdata.cloud/guides/mongodb/mongodb-sharding-hot-shard/) ## Problems, failure modes and limitations - Timeline from vendor records. Terraform provider v1.18.0 (2024-08-14) first let a cluster define shards as separate replication_specs objects and deprecated num_shards. MongoDB's announcement dated 2024-10-31 said all dedicated-tier customers could scale shards independently through Terraform and the Admin API. Provider v1.23.0 (2024-12-17) added per-shard cluster-tier auto-scaling. The Atlas docs say sharded clusters created before 2024-12-09 default to cluster-wide scaling. Provider v2.0.0 (2025-09-15) removed num_shards and supports only the per-shard schema. (high confidence) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/CHANGELOG.md) - The largest and smallest shard tiers must stay within two tiers of each other (if the largest shard is M50, the smallest may be M30 or M40). Atlas cannot auto-scale per shard when shards sit on different cluster classes, for example M30 General next to M40 Low-CPU. The Manage Clusters page states the two-tier rule for tiers chosen through the Admin API; the Manage Cluster Sharding page states it as a limit of the compute auto-scaler. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - The Atlas UI cannot scale shards independently. After any independent scaling through the Admin API, Atlas CLI or Terraform, the Cluster Builder UI can no longer manage the cluster. Editing the tier of a multi-tier sharded cluster in the UI sets every shard to the new tier, which erases the asymmetry. The UI can still switch on compute auto-scaling, and shards then scale independently. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - To check whether an older sharded cluster has gained per-shard auto-scaling, call GET /api/atlas/v2/groups/{groupId}/clusters/{clusterName}/autoScalingConfiguration and read autoScalingMode (INDEPENDENT_SHARD_SCALING or CLUSTER_WIDE_SCALING). The Admin API docs describe it as a diagnostic endpoint for clusters updated from older APIs and mark it Deprecated. (low confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-autogroupclusterscalingconfiguration) - Inference for Atlas: the manual's archive tier uses machines with more storage per server, but Atlas requires equal storage capacity on every shard. Per-shard tiers in Atlas therefore vary compute, memory and IOPS, not disk capacity, so an Atlas archive shard cannot be given more disk than a hot shard. (medium confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas/) - Resizing a hot shard does not fix a skewed shard key. A hot shard usually comes from an access pattern that does not match the shard key (monotonic keys, low cardinality, temporal skew), not from a chunk-count imbalance. The balancer can move chunks but cannot spread traffic inside one chunk. MongoDB's remedies are refining the shard key with a suffix field, resharding to a higher-cardinality key, or hashed sharding. A bigger tier on the hot shard raises its ceiling and leaves the cause in place. (high confidence) — [source](https://www.netdata.cloud/guides/mongodb/mongodb-sharding-hot-shard/) - Legacy Terraform objects break on asymmetric clusters. Once a cluster is asymmetric (through independent shard scaling or per-shard auto-scaling), the mongodbatlas_cluster resource and data source fail with API error code ASYMMETRIC_SHARD_UNSUPPORTED. Use mongodbatlas_advanced_cluster instead. Cloud backup schedules must reference zones with copy_settings.#.zone_id, because the per-shard model no longer supports replication_spec ids. (medium confidence) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/guides/advanced-cluster-new-sharding-schema.md) - You set per-shard tiers through the Atlas Administration API, the Atlas CLI, or the HashiCorp Terraform MongoDB Atlas Provider. The Atlas UI cannot set a tier per shard, but turning on compute auto-scaling in the UI lets shards scale independently. In the Atlas CLI, `--autoScalingMode independentShardScaling` scales shards independently and `clusterWideScaling` scales them together. The CLI defaults to `clusterWideScaling` when you omit the option. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - The April 2026 Atlas changelog says Atlas improved independent shard scaling by removing the two-tier zone gap limitation at the cluster level and adding support for asymmetric auto-scaling range configurations. The cluster sharding page fetched in October 2026 still states the two-tier gap, so it is unclear which limits Atlas enforces today. (low confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/release-notes/changelog/) - Several settings must stay identical across shards. Every shard needs the same number of electable, read-only and analytics nodes (Global Clusters can differ per zone), the same storage capacity, and the same NVMe tier. Atlas cannot auto-scale a cluster whose shards sit on different cluster classes, for example one shard on M30 General and another on M40 Low-CPU. The Terraform docs add that electable and read-only nodes inside one shard must share an instance size, and that `disk_size_gb` must be equal for all shards and node types. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - If a cluster becomes asymmetric through independent shard scaling or per-shard auto-scaling, the legacy `mongodbatlas_cluster` data source fails with API error code `ASYMMETRIC_SHARD_UNSUPPORTED`. Replace it with `mongodbatlas_advanced_cluster`. The legacy `mongodbatlas_cluster` docs describe their `replication_specs.id` as part of the legacy sharding schema with no independent shard scaling. (medium confidence) (verified as of 2026-10-20) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/guides/advanced-cluster-new-sharding-schema.md) - The older error `ASYMMETRIC_HARDWARE_INVALID` ("Asymmetric hardware is not supported by the v1.0 API") appears when a legacy-API cluster has base nodes and analytics nodes on different tiers. A 2023 feedback thread (status Completed) answers that `mongodbatlas_advanced_cluster` already supports this. The provider changelog lists matching closed issues #958 (v1.7.0) and #1214 (v1.10.0). (medium confidence) — [source](https://feedback.mongodb.com/ideas/CUSTOMER-I-8957) - The Admin API endpoint `GET /api/atlas/v2/groups/{groupId}/clusters/{clusterName}/autoScalingConfiguration` returns `autoScalingMode` as `INDEPENDENT_SHARD_SCALING` or `CLUSTER_WIDE_SCALING`. Its docs say to use it to confirm that a sharded cluster updated from an older API gained per-shard auto-scaling. The docs mark this endpoint Deprecated. (medium confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-autogroupclusterscalingconfiguration) - A Nov 2022 feedback idea asks for hot, warm and cold shards on different tiers and different storage (M60 with 128 GB, M40 with 256 GB, M30 with 512 GB, with 95% of accesses on the hot shard). It still showed status Submitted, 4 votes and no reply on 2026-10-20. Atlas now allows a different compute tier per shard, but the docs require equal disk size on every shard, so independent shard scaling alone cannot build that design (inference). (medium confidence) (verified as of 2026-10-20) — [source](https://feedback.mongodb.com/ideas/CUSTOMER-I-9055) ## Comparisons and alternatives - Independent shard scaling lets each shard of an Atlas sharded cluster run its own cluster tier. On each shard, the electable and read-only nodes can run on a different tier than the analytics nodes (example in the docs: M30 operational nodes with an M40 analytics node on one shard, the reverse on another). Within one shard, electable and read-only nodes ('base nodes') share one instance size. Both base nodes and analytics nodes can differ from their counterparts on other shards. (high confidence) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - In Terraform, each shard is its own `replication_specs` element, and the shard count equals the number of elements. The provider deprecated `num_shards` in v1.18.0 (2024-08-14) and removed it in v2.0.0 (2025-09-15). For independent shards, reference zones with `replication_specs.#.zone_id` instead of `replication_specs.#.id`, and use `copy_settings.#.zone_id` in `mongodbatlas_cloud_backup_schedule`. Make all of the shard-schema changes in the same apply. (high confidence) (verified as of 2026-10-20) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/guides/advanced-cluster-new-sharding-schema.md) - In independent mode, the Atlas Admin API and CLI return one `replicationSpecs` entry per shard instead of a `numShards` field. Each shard's `diskSizeGB` sits inside its own `regionConfigs`. Global clusters also return a `zoneId` that you pass on GET and UPDATE requests. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-independent-shard-scaling/) - The MongoDB balancer migrates data between shards to reach an even amount of data per shard, while respecting zones. Since MongoDB 6.0 it measures data size rather than chunk count. A collection counts as balanced when its shards differ by less than three times the range size, so with the default 128 MB range size a migration needs at least a 384 MB difference. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/sharding-balancer-administration/) ## Facts and statements - An asymmetric cluster is modeled as one replicationSpecs element per shard. The number of elements defines the shard count, so the numShards field is not used. In the Atlas CLI's independent-shard JSON output, diskSizeGB sits inside each shard's regionConfigs and a zoneId identifies the zone of a Global cluster. Terraform's mongodbatlas_advanced_cluster uses the same shape: one replication_specs element per shard, with num_shards removed. (high confidence) — [source](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-independent-shard-scaling/) - The Atlas CLI selects the scaling mode with --autoScalingMode clusterWideScaling or independentShardScaling. If the option is omitted, the command uses clusterWideScaling. The Admin API reports the same setting in the autoScalingMode field as CLUSTER_WIDE_SCALING or INDEPENDENT_SHARD_SCALING. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-independent-shard-scaling/) - Atlas still requires shards to match on several settings. Every shard must have the same number of electable, read-only and analytics nodes (Global clusters may use a different node count per zone). Storage capacity must be equal on all shards. The NVMe tier must match, and the Manage Clusters page says NVMe clusters are not compatible with independent shard scaling. In Terraform, replication_specs for all shards in one zone must be identical except instance_size and disk_iops, and disk_size_gb must be equal for all shards and node types. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - IOPS can differ per shard, but only on some storage types. The sharding page lists AWS Provisioned IOPS and Azure regions with Extended Storage/IOPS, and says Standard IOPS stay tied to storage size. The Terraform resource docs list more clusters that accept independent disk_iops: AWS Gen2 STANDARD (gp3), HIGH_PERFORMANCE (io2) and PROVISIONED (io2), GCP Gen2 (Hyperdisk Balanced), and Azure with Extended IOPS. (medium confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - With compute auto-scaling on, Atlas scales each shard's instance size on its own. The minimum and maximum tier apply at the cluster level. In Terraform, per-shard auto-scaling applies to clusters that use one replication_specs element per shard, from provider v1.23.0. Auto-scaling can leave shards asymmetric in instance_size, disk_size_gb and disk_iops. (high confidence) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - Hot/cold tiering pattern from the manual: place each shard in a zone by hardware tier, pick a shard key whose leading field encodes recency (the example uses creation_date), map the recent range to the fast-tier zone and older ranges to the archive zone. Adding shards to the matching zone scales that tier horizontally. Moving the cutoff date migrates data between tiers, so choose the rotation interval by weighing migration volume against how often ranges change. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas/) - MongoDB positions per-shard scaling for traffic that is naturally concentrated: its example is scaling only the shards that serve US traffic during Thanksgiving, and adding resources to hot shards while leaving the other shards' provisioning unchanged. The Atlas docs describe the goal as a customized allocation of resources and cost per shard. (medium confidence) — [source](https://www.mongodb.com/company/blog/product-release-announcements/mongodb-atlas-introduces-enhanced-cost-optimization-tools) - Config servers do not shrink with shard tiers. Atlas runs three config servers for a sharded cluster and bills them at a separate rate that does not depend on the cluster tier or storage you select. Data-bearing nodes equal the replication factor times the number of shards, so per-shard downsizing lowers only the data-bearing cost. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs/) - In mongodbatlas_advanced_cluster, the update path matches each replication_specs entry to a shard by list position. If you add, remove or reorder entries, a configuration can attach to the wrong Atlas shard. Keep existing entries in order, append new shards after them, and leave existing entries unchanged in the same update. MongoDB recommends contacting Support before removing a shard or making other significant production topology changes. (low confidence) (verified as of 2026-10-20) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/resources/advanced_cluster.md) - In Terraform, asymmetry comes from giving each shard its own replication_specs element. The guide's example sets instance_size M40 on the first shard and M30 on the second. Migrating from num_shards means replacing it with one identical element per shard, and all changes must be applied together. Provider v2.0.0 and later support only this schema. (high confidence) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/guides/advanced-cluster-new-sharding-schema.md) - A practitioner example of zone-driven asymmetry (Medium, 2026-02-10): a three-shard Atlas cluster with two shards in a Mumbai zone and one in a US zone, shard key {region: 1, email: 1}, autoscaling listed as M30 to M40, justified by 70 to 80 percent of traffic coming from India. Queries without the region prefix scatter to all shards. The post names no per-shard tiers and does not cover hotspots or resharding cost. It is an architecture sketch, not production evidence. (low confidence) — [source](https://medium.com/@ksingla.vikas/anatomy-of-an-active-active-asymmetric-multi-region-atlas-cluster-bc0f2638591a) - Independent shard scaling lets an Atlas sharded cluster give each shard its own cluster tier. Within one shard, the electable and read-only nodes can run a different tier from the analytics nodes. The Atlas docs give this example: one shard runs 3 electable/read-only nodes on M30 plus 1 analytics node on M40, while another shard runs 3 on M40 plus 1 analytics node on M30. (high confidence) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - MongoDB announced Atlas independent shard scaling at MongoDB.local London in October 2024. The launch post (2024-10-31, updated 2025-03-05) said dedicated-tier customers could use it through Terraform and the Admin API, with independent shard auto-scaling and configuration management due in late 2024. The Terraform provider published its new per-shard sharding guide in v1.18.0 (2024-08-14) and added per-shard tier auto-scaling in v1.23.0 (2024-12-17). The Atlas docs say sharded clusters created before 2024-12-09 default to cluster-wide shard scaling. (medium confidence) — [source](https://mongodb.com/blog/post/mongodb-atlas-introduces-enhanced-cost-optimization-tools) - Atlas Infinite, in public preview since September 2026, does not support sharded clusters. Independent shard scaling therefore applies only to Atlas Core clusters. The cluster sharding page carries a note that the feature is not supported on Atlas Infinite during public preview. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - With independent shard scaling, Atlas compute auto-scaling evaluates and scales each shard on its own, using the same criteria it applies to replica sets. Atlas enables independent shard scaling by default for sharded clusters that use auto-scaling. If only the operational nodes or only the analytics nodes of one shard meet the criteria, only those nodes on that shard change tier. In Terraform, per-shard auto-scaling of `instance_size` needs provider v1.23.0 or later. (high confidence) (verified as of 2026-10-19) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core/) - The Admin API can set different disk IOPS per shard. On AWS, each shard can use Standard or Provisioned IOPS, and shards on Provisioned IOPS can have different IOPS values. On Azure in regions with Extended Storage/IOPS, shards can have different Standard IOPS. The Terraform docs list the cases that support independent `disk_iops`: AWS Gen2 `STANDARD` (gp3), AWS Gen2 `HIGH_PERFORMANCE` (io2), AWS `PROVISIONED` (io2), GCP Gen2 (Hyperdisk Balanced), and Azure regions with Extended IOPS. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - In the Terraform `mongodbatlas_advanced_cluster` resource, the `replication_specs` settings for all shards in the same zone must match, except `instance_size` and `disk_iops`, which can differ per shard. The Crossplane provider reference (v1.4.1, generated for the same schema) repeats this rule. (medium confidence) (verified as of 2026-10-20) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/resources/advanced_cluster.md) - If a sharded cluster has shards on different tiers and you change the cluster tier in the Atlas UI, Atlas changes the tier of all shards. Use the Admin API, CLI or Terraform for any per-shard tier change. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - After you scale shards independently with the Admin API, CLI or Terraform, the Atlas docs say you can no longer manage the cluster with the Atlas Cluster Builder UI. (low confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding/) - For Terraform clusters with more than one `replication_specs` entry, the provider docs list two known issues. Setting `use_effective_fields = true` currently has no effect, and the docs recommend leaving it off. The update path matches `replication_specs` entries to shards by list position, so adding, removing or reordering entries can attach a configuration to the wrong shard. The docs say to keep existing entries in order, add new shards only at the end, avoid list-index `lifecycle.ignore_changes` while auto-scaling is on, and contact MongoDB Support before removing a shard. (low confidence) (verified as of 2026-10-20) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/resources/advanced_cluster.md) - A Terraform cluster that uses the new sharding configuration might not have shard-level auto-scaling if its configuration predates provider v1.23.0, was imported from the legacy schema, or jumped from v1.x straight to v2.0.0 or later. To activate it, update the cluster configuration, for example by temporarily changing `compute_min_instance_size`. (low confidence) (verified as of 2026-10-20) — [source](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/guides/advanced-cluster-new-sharding-schema.md) - If one hot shard gets disproportionate traffic or data and you scale the whole cluster, you pay for capacity the other shards do not need. MongoDB's cost guidance says to first rebalance traffic evenly across shards, including by sharding busy unsharded collections, and to use independent shard scaling only if rebalancing is not possible. MongoDB's launch post describes the feature as adding resources to hot shards while leaving the other shards unchanged. (high confidence) — [source](https://www.mongodb.com/docs/atlas/architecture/current/cost-saving-config/) - The Atlas Metrics tab for a sharded cluster shows shards side by side. Display Data can plot each shard as its own line, the sum of shards, or the average. The Terraform guide recommends reviewing the per-shard Metrics dashboard before you change shard-specific resources. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/review-sharded-cluster-metrics/) - Atlas charges cluster cost and storage cost for each data-bearing node. A sharded cluster has replication factor times number of shards data-bearing nodes. Atlas bills config servers separately, and your tier and storage choices do not change their cost. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs/) - If you add shards after predictive auto-scaling is already active, the new shards use reactive auto-scaling until Atlas has seen their workload pattern, about two weeks. The config server replica set does not auto-scale, but a config shard does. (low confidence) (verified as of 2026-10-19) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core/)