<!-- llms-explorer concept facts · https://llms-explorer.com/tree/burstable-m10-m20-tiers/ · pack 2026-10-20 · ~1394 tokens -->

# Burstable M10/M20 tiers

> Source-anchored research for Burstable M10/M20 tiers. Run status: COMPLETED.

Parent: [Atlas Cluster Topology and Tier Economics](https://llms-explorer.com/tree/atlas-cluster-topology-and-tier-economics/) · 5 facets · 12 facts · page: https://llms-explorer.com/tree/burstable-m10-m20-tiers/

## How it works

- Atlas's System: CPU (Steal) alert is scoped to AWS EC2 burstable M10/M20 instances and applies when the instance credit balance is exhausted; it measures CPU usage above the guaranteed baseline credit-accumulation rate. It should not be treated as a provider-neutral M10/M20 signal. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/system-cpu-usage.md)
- AWS EC2 documents two burst-credit modes: Standard instances return to baseline when accrued credits run out, while Unlimited instances can continue bursting on surplus credits and incur additional charges when average CPU over the rolling 24-hour period exceeds baseline. (low confidence) (verified as of 2026-10-20) — [source](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html)

## Measurements and reference values

- Atlas bases M10/M20 auto-scaling CPU decisions on Relative System CPU Utilization, calculated by dividing Normalized System CPU by the provider baseline. MongoDB says the baseline is typically 20%-50% for burstable types and is not shown in Atlas metrics; provider-specific auto-scaling criteria are subject to change. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core/)
- In a load-test discussion dated October 21, 2022, an Atlas user reported that a test spent most of its time on M10/M20, saw CPU Steal around 130%-140% with poor performance, and became smoother after running long tests on M30. This is one workload report, not a general performance benchmark. (low confidence) — [source](https://www.mongodb.com/community/forums/t/dip-in-opcounters-every-15-mins/194315)
- A MongoDB feedback item for M10/M20 CPU-credit metrics and alerts was still marked Submitted when checked on October 20, 2026. A commenter dated July 25, 2025 reports CPU Steal rising from 0% to 80% within minutes; this records a user request and report, not confirmation that the requested metrics are absent from every Atlas interface. (low confidence) (verified as of 2026-10-20) — [source](https://feedback.mongodb.com/ideas/CUSTOMER-I-9170)

## Problems, failure modes and limitations

- Atlas says M10 and M20 use burstable performance infrastructure and warns that cloud providers can cap CPU after burst periods. AWS and Azure describe the credit model: instances earn credits below baseline, spend them above baseline, and run at baseline when credits are exhausted. This makes sustained above-baseline demand a throttling risk. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/manage-clusters.md)

## Comparisons and alternatives

- Inference from Atlas's low-traffic positioning and the provider credit models: M10/M20 fit intermittent CPU peaks when sustained usage stays near or below baseline; a continuously CPU-heavy workload can exhaust burst headroom and trade the lower tier for baseline-limited throughput. Compare measured workload behavior with a higher tier rather than treating a short burst test as steady-state capacity evidence. (medium confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/manage-clusters.md)
- Microsoft documents that Azure B-series VMs accumulate CPU credits below base performance, spend them above base, and throttle back to base performance when credits are exhausted. Atlas documents an Azure-specific M10/M20 auto-scaling signal but does not identify B-series as the Atlas host family, so the B-series behavior is provider context rather than a confirmed Atlas host mapping. (medium confidence) (verified as of 2026-10-20) — [source](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/b-series-cpu-credit-model)

## Facts and statements

- Atlas positions M10 and M20 as dedicated tiers for development and low-traffic production; they support replica sets only, while Atlas recommends M30+ for high-traffic production. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/manage-clusters.md)
- A practitioner article edited January 17, 2025 reports that Atlas M10/M20 on Azure used B-series VMs and that the Atlas CPU Steal metric was unavailable there at the time. Atlas's current alert documentation separately scopes its CPU Steal alert to AWS EC2; treat the Azure VM mapping as a dated user report, not a current Atlas tier-to-VM guarantee. (medium confidence) (verified as of 2026-10-20) — [source](https://dev.to/deyanp/mongodb-atlas-azure-a-forced-marriage-169m)
- Atlas documents M10 and M20 for development and low-traffic production, limits them to replica-set deployments, and recommends M30 or higher for production; M30+ also supports sharded deployments. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/manage-clusters.md)
- Atlas says M10/M20 use burstable performance infrastructure. Cloud providers can cap CPU after burst periods, which can throttle heavy workloads; MongoDB also warns that sustained M10/M20 loads may degrade performance. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/atlas/manage-clusters.md)
