MongoDB Atlas Cost Optimization
Parent: MongoDB Atlas · researched 2026-05-28T15:22:05.601Z· 1 source · 12 concepts · skill mongodb-cost-optimization
Expert guidance on reducing MongoDB Atlas spend while maintaining performance SLAs. Applicable to all Atlas dedicated cluster tiers (M10–M700+). Real-world context: this skill was developed in part to
MongoDB Atlas Cost Optimization
- Expert guidance on reducing MongoDB Atlas spend while maintaining performance SLAs. Applicable to all Atlas dedicated cluster tiers (M10–M700+). Real-world context: this skill was developed in part to support a $300k cost optimization target for enterprise Atlas deployments. [source]
Scope
- In scope: Atlas dedicated clusters (M10 and above), replica sets, sharded clusters, backup, network egress, index storage, and committed-use pricing. [source]
- Out of scope: Atlas Serverless and Atlas Flex clusters use per-operation and range-based pricing models that differ fundamentally from instance-based pricing. Cost guidance for Serverless and Flex requires separate analysis - this skill does not cover them. Atlas App Services (triggers, Data API) costs are also excluded. [source]
Quick Reference — Cost Levers by Impact
- Use this table to prioritize effort. Detail for each lever is in the numbered sections below. [source]
Sizing philosophy
- Right-sizing is an iterative process, not a one-time event. Atlas clusters are over-provisioned by default because teams size for peak-of-peak and never revisit. Most production clusters run at <40% CPU and <60% RAM utilization on average. [source]
CPU targets
- Sustained CPU < 60%: healthy headroom. If sustained CPU consistently sits below 30%, the cluster is a candidate for one tier down. [source]
- P99 CPU < 80%: spikes above 80% during batch windows are acceptable if they are brief and predictable. [source]
- CPU steal > 5% on M10/M20 clusters: signal that the underlying host is saturated; consider moving up one tier to get more dedicated compute headroom. [source]
RAM targets
- Working set fit: the most critical metric. If the Atlas "Page Faults" metric (in Metrics → Cache) shows sustained page faults, your working set has outgrown RAM. Size up until page faults are near zero. [source]
- Cache utilization > 90%: investigate query patterns first (indexes, projections, covered queries) before adding RAM. [source]
- Target 70–85% cache utilization as a healthy steady state. [source]
IOPS targets
- Monitor "Disk IOPS" in Atlas Metrics. If IOPS consistently approach the tier's provisioned limit, consider scaling up or switching to Provisioned IOPS storage (NVMe or custom IOPS). [source]
- For write-heavy workloads, watch "Disk Queue Depth" - values above 1 sustained indicate I/O saturation. [source]
Tier step-down methodology
- Pull 30-day P50/P95/P99 CPU, memory cache utilization, and IOPS from Atlas Metrics or Data Explorer. [source]
- Identify the busiest 3-hour window in the week (typically Monday morning or end-of-month batch). [source]
- Simulate one tier down: will P95 CPU stay below 75%? Will working set still fit? [source]
- For RS primaries, validate oplog window stays above 24 hours after downsizing (oplog window shrinks with smaller disks). [source]
- Apply the change via Atlas UI rolling restart (Atlas changes secondaries first, then the primary automatically via election). Watch metrics for 24 hours after the rolling restart completes before declaring success. [source]
Cluster count reduction
- Consolidating several under-utilized M30 clusters onto fewer M50 clusters often saves more than tier reduction alone. Evaluate multi-tenant cluster patterns (separate databases per tenant) when per-cluster overhead exceeds actual workload cost. [source]
When to use Standard (GP3)
When to use Provisioned IOPS
- Write-heavy workloads where disk queue depth consistently exceeds 1. [source]
- When you need deterministic IOPS SLA for compliance (fintech, healthcare). [source]
- Clusters where you can't size disk larger (data volume constraint) but need more IOPS. [source]
- Cost break-even: provisioned IOPS becomes cost-effective only when you need > 3,000 IOPS from a disk that would otherwise require scaling the cluster tier. [source]
When to use NVMe
- Hot data caches (Okta session store, rate-limiting counters, real-time leaderboards). [source]
- When working set exceeds 500 GB and cache miss latency is unacceptable. [source]
- Note: NVMe local disks are not network-attached persistent storage - if an individual node fails, WiredTiger data on that node must be rebuilt by initial sync from a healthy peer. Atlas manages this automatically, but it means the replica set must stay healthy (never lose quorum) or recovery time increases significantly. [source]
Cost optimization rule
- Audit provisioned IOPS allocations quarterly. Teams frequently provision 10,000 IOPS for a cluster consuming 800. Move over-provisioned io1 clusters to GP3 with IOPS matching actual P95 usage + 30% headroom. [source]
What Atlas compute autoscaling does
- Atlas Compute Autoscaling (available M10+, enabled per cluster) monitors CPU and memory, then scales up or down one tier at a time. It does not skip tiers. [source]
Scale-up rules (Atlas defaults)
Scale-down rules (Atlas defaults)
Opt-in vs opt-out strategy
- Opt in for: non-production clusters, single-region analytics clusters, clusters with variable batch workloads. [source]
- Opt out for: sharded clusters (autoscaling applies per shard - coordinate with capacity planning), clusters with strict latency SLAs where a rolling restart during a scale event is disruptive, M0/M2/M5 free/shared tiers (autoscaling not available on shared infrastructure). [source]
Monitoring autoscaling events
- Atlas Project Activity Feed logs every scale event. Set a budget alert at 110% of current spend to catch unexpected autoscale-up events. [source]
Atlas disk autoscaling default
- Atlas triggers disk autoscaling when disk utilization reaches 90% of provisioned storage. The disk is expanded by approximately 25% (rounded to the next billing increment). [source]
Why the 90% trigger is dangerous
- By the time Atlas fires the autoscale event and the expansion completes, the cluster can momentarily spike above 90%, causing the WiredTiger storage engine to stall writes. For high-write clusters, configure the disk alert at 85% to give yourself a 2–4 hour window to intervene manually. [source]
Disk space alert setup (Atlas UI)
Manual vs auto disk scaling
- Manual scaling is preferred for predictable growth patterns (data archival, known ingest schedules). Avoids unexpected storage cost jumps. [source]
- Auto scaling is appropriate when ingest rate is variable and unpredictable. Set a maximum disk size cap in cluster configuration to avoid runaway expansion. [source]
Compaction and space recovery
- Atlas does not automatically compact reclaimed disk space after large deletes. Use compact command during maintenance windows on secondaries, then primary, to reclaim space. [source]
- After TTL index deletes or large bulk-delete operations, compaction can recover 30–60% of disk, avoiding an autoscale event. [source]
Backup pricing model
- Atlas charges for backup storage separately from cluster storage. Snapshot storage list price starts at approximately $0.14/GB-month (varies by cloud provider and region; see references/mongodb-backup-restore.md for the same figure). Snapshots are incremental after the first, so realized cost is typically well under the full dataset size times that rate. Continuous (PIT) backups add overhead for oplog tailing. [source]
Snapshot retention tuning
- Default Atlas backup policies are often set to 7 daily + 4 weekly + 12 monthly + 2 yearly. For non-production environments, this is severe overkill. [source]
- Recommended retention by environment: [source]
- Applying minimal retention to staging/dev/QA clusters alone can reduce backup spend by 20–40% for organizations with many non-prod clusters. [source]
Queryable backups vs continuous backups
- Queryable backups (Backup Query) allow running read queries against a snapshot without restoring. They incur an additional charge per hour the queryable session is active. Terminate sessions immediately after use - stale queryable backup sessions are a common surprise charge. [source]
- Continuous backups (Point-in-Time Restore, PITR) require oplog storage in addition to snapshots. For clusters with high write rates, oplog storage can equal or exceed base snapshot storage. PITR is essential for production; disable it on all non-production clusters. [source]
Cross-region backup cost
- Atlas charges cloud provider data transfer rates for cross-region snapshot copies. Example: us-east-1 → eu-west-1 snapshot copy on AWS costs ~$0.02/GB in egress. For a 2 TB cluster with weekly cross-region backup copies, this is ~$40/week ($2,080/year) in egress alone, before storage. [source]
- Optimization: Use cross-region backup only for your most critical production clusters. For DR, consider whether a replica set spanning regions (geo-distributed RS) eliminates the need for cross-region backup copies. [source]
Free paths
- Intra-region, same VPC/peering: traffic between your application VPC and Atlas via VPC peering in the same cloud region is free on AWS and GCP (standard peering rules). This is the target architecture. [source]
- Private Link / Private Endpoint within the same region: free for data transfer; you pay for the endpoint hour only. [source]
Charged paths
- Cross-region data transfer: any data that crosses cloud provider region boundaries is charged at the provider's inter-region rate (~$0.02/GB on AWS, similar on GCP/Azure). [source]
- Internet egress (no peering): clusters accessed over the public internet are charged at provider internet egress rates (~$0.09/GB on AWS). This is the most expensive path and should be eliminated in production. [source]
- Atlas Data Federation: egress from Atlas Data Federation to S3 or external storage layers has its own pricing. Review federation query patterns. [source]
Marketplace billing and egress credits
- When Atlas is purchased through AWS Marketplace (or GCP/Azure Marketplace), egress charges from Atlas to compute in the same cloud are often offset by Marketplace agreements. Verify with your MongoDB sales rep whether your Marketplace agreement includes egress credits. [source]
Egress cost reduction tactics
- Co-locate application and Atlas cluster in the same region. Mismatched regions are the single largest source of unplanned egress costs. [source]
- Use VPC peering or Private Link everywhere - eliminate public endpoint usage. [source]
- Minimize cross-shard scatter queries in sharded clusters (scatter-gather reads data from all shards, multiplying egress if shards span regions). [source]
- Atlas Charts and Atlas Data Federation running cross-region against production clusters generate egress at query time. [source]
Atlas committed use discounts
- MongoDB offers committed-use pricing (similar to cloud provider reserved instances) through multi-year Atlas contracts. Discounts range from 15–35% depending on commitment term and volume: [source]
- 1-year commitment: ~15% discount [source]
- 2-year commitment: ~25% discount [source]
- 3-year commitment: ~30–35% discount [source]
Marketplace private offers
- AWS, GCP, and Azure Marketplace support Private Offer agreements where MongoDB can negotiate custom pricing with volume commitments. These are distinct from on-demand Marketplace rates and are typically accessed through MongoDB's enterprise sales team. Private Offers can bundle: [source]
- Atlas cluster usage [source]
- Atlas Search (Lucene-powered) [source]
- Atlas Stream Processing [source]
- Professional services [source]
Enterprise Discount Programs (EDP)
- For AWS customers with an existing AWS EDP agreement, Atlas Marketplace spend can count toward your EDP commitment and receive EDP discounts. This stacks with any MongoDB-level committed-use discount. Validate with both your AWS account team and MongoDB sales rep. [source]
- Key question to ask: "Does my Atlas Marketplace spend count toward my AWS EDP draw-down, and is there a private offer available that reduces the per-unit rate further?" [source]
When to trigger a renegotiation
- Annual Atlas spend > $100k: dedicated Technical Account Manager and discount eligibility. [source]
- Annual Atlas spend > $250k: committed-use discount almost always warranted. [source]
- At Okta's $300k cost optimization target: combination of right-sizing + committed-use renegotiation + Marketplace private offer is the typical playbook. [source]
What cluster pause does
- Pausing a cluster in Atlas stops all compute charges (you continue to pay for storage). Atlas M0 (free) clusters are excluded; M10+ clusters can be paused via UI or API. [source]
Savings from pausing
- For a paused cluster, you pay storage cost only - typically 5–15% of the running cluster cost. A paused M30 cluster ($0.54/hour compute) saves ~$389/month, paying only ~$20–40/month in storage. [source]
Cold-start time
- Cluster resume takes 1–5 minutes (Atlas provisions the compute instances, mounts storage, initiates replica set election). Plan for this in CI/CD pipelines that spin up on-demand. [source]
Pause schedule automation
- Use Atlas API + a cron job or Atlas Scheduled Triggers to automate pause/resume for non-production clusters: [source]
Recommended pause schedule for dev/staging
Pause limitations
- Clusters with active Atlas Search indexes cannot be paused (as of Atlas 7.x). [source]
- Clusters paused for more than 60 days are automatically resumed by Atlas (to prevent indefinitely stale configs). Set a calendar reminder or monitoring alert if long-term pause is intended. [source]
- Paused clusters still run scheduled Atlas triggers and Atlas Charts queries - review and disable these before pausing. [source]
Indexes and storage billing
- Every index consumes disk storage, which is included in your cluster's storage billing. For large collections, indexes can represent 20–50% of total disk usage. [source]
The too-many-indexes anti-pattern
- Teams frequently create indexes during development and never prune them. Common patterns: [source]
- ESR (Equality, Sort, Range) indexes created separately instead of as compound indexes. [source]
- Indexes created for a feature that was never launched or was retired. [source]
- Redundant prefix indexes: {a:1} when {a:1, b:1} already exists (the compound covers the single-field case). [source]
- Text indexes on every string field "just in case." [source]
Monitoring index size
Finding unused indexes
- For Atlas clusters, use Atlas Performance Advisor - it surfaces "Redundant Indexes" and "Unused Indexes" recommendations automatically. [source]
Safe index removal process
- Identify candidate unused index via $indexStats over a 14-day window (catch monthly jobs). [source]
- Hide the index first: db.collection.hideIndex("index_name") - hidden indexes are maintained but not used by the query planner. Monitor for 1–2 weeks. [source]
- If no degradation observed, drop: db.collection.dropIndex("index_name"). [source]
- For large indexes (> 10 GB), expect an immediate disk space reduction after compaction. [source]
Atlas Billing Dashboard
- Navigate to Atlas Organization → Billing to see: [source]
- Invoices: line-item breakdown by project and cluster. [source]
- Cost Explorer (Atlas Advanced): filter by project, cluster, service type (compute, storage, backup, data transfer) across date ranges. [source]
- Usage details CSV export: machine-readable daily usage for offline analysis. [source]
Tagging strategy
Budget alerts
Automated cost anomaly detection
- Use the Atlas API to pull daily cost data and feed it to a cost anomaly tool (AWS Cost Anomaly Detection if using Marketplace, or a custom time-series alert). A 20% day-over-day spike in a project's cost is worth investigating - common causes are autoscale-up events, runaway Data Federation queries, or accidentally un-paused dev clusters. [source]
Monthly cost review cadence
- For accounts > $10k/month Atlas spend, establish a monthly review: [source]
- Pull invoice line items, sort by cost descending. [source]
- Identify top 5 clusters by cost - are they appropriately sized? [source]
- Review autoscaling events in Activity Feed. [source]
- Check for orphaned clusters (no connections in 30 days per Atlas access logs). [source]
- Validate backup retention policies match current policy. [source]
Tier definitions (internal operational classification)
- This is a customer-defined classification, not an Atlas-native concept. Align with your SRE or platform team's existing tier model. [source]
Mixing tiers strategically
- Don't gold-plate Tier 2: a common mistake is running internal dashboards and analytics clusters at Tier 1 specs "because it's easy." An M30 with a 3-day daily snapshot is almost always sufficient for internal tools. [source]
- Separate clusters by tier: avoid co-mingling Tier 0 and Tier 2 workloads on the same cluster (multi-tenancy) - a noisy Tier 2 workload can degrade Tier 0 performance. [source]
- Tier 2 pause savings: if you have 20 Tier 2 clusters at M20 average, pausing them 65% of the time saves ~$5,000–$8,000/month. [source]
Okta-scale application
- For an account targeting $300k in savings: [source]
- Audit all clusters: classify into T0/T1/T2. [source]
- Right-size T1 clusters (likely 20–40% of spend, 40% reduction = $30–60k savings). [source]
- Pause T2 clusters off-hours (~$60–80k savings if significant T2 footprint). [source]
- Negotiate committed-use discount on remaining T0/T1 spend (~15–25% = $60–120k savings). [source]
- Prune backup retention on T1/T2 (~$20–30k savings). [source]
- Total: $170–290k annualized, reaching or exceeding the $300k target with combined levers. [source]
Over-provisioned IOPS
- Pattern: Team provisions io1 storage with 10,000 IOPS "to be safe" for a cluster consuming 600 IOPS at P95. [source]
- Detection: Atlas Metrics → Disk IOPS → compare provisioned vs actual over 30 days. [source]
- Fix: Switch to GP3 storage, set IOPS to actual_P95 * 1.5 (minimum 3,000 for GP3). [source]
- Savings: Can be 50–70% of storage cost for over-provisioned io1 clusters. [source]
Oversized clusters
- Pattern: M80 cluster purchased for a projected workload peak that never materialized. Team inherited it and never questioned the spec. [source]
- Detection: 30-day CPU P95 < 30% AND page faults near zero AND disk utilization < 50%. [source]
- Fix: Rolling tier-down via Atlas UI. Start one tier at a time, validate, continue. [source]
- Savings: Each tier step is roughly 40–60% cost reduction. [source]
Redundant backups
- Pattern: Both continuous backups (PITR) and aggressive snapshot retention enabled on dev/staging clusters. [source]
- Detection: Atlas Billing → filter by "Backup" service type - compare backup cost vs compute cost per cluster. Backup > 30% of cluster cost is a red flag for non-production. [source]
- Fix: Disable PITR on staging; reduce to 1-day daily retention for dev clusters. [source]
Orphaned clusters
- Pattern: Cluster created for a proof-of-concept 18 months ago. PoC ended, cluster never deleted. [source]
- Detection: Atlas Data Explorer or listClusters API → filter for clusters with zero connections in the past 30 days via Atlas access logs. [source]
- Fix: Confirm with application team, take final snapshot, delete cluster. [source]
Runaway Data Federation queries
- Pattern: Atlas Data Federation configured to query S3 data on-demand. A scheduled report or misconfigured dashboard runs full-collection scans every 5 minutes. [source]
- Detection: Atlas Billing → Data Federation line items spiking. Atlas Data Federation logs show query frequency. [source]
- Fix: Add query result caching, reduce schedule frequency, add $match filters to reduce data scanned. [source]
Multi-region clusters where single-region suffices
- Pattern: 3-region global cluster deployed "for availability" on an internal analytics workload that has no international users. [source]
- Detection: Atlas cluster topology → global write distribution map → low write/read volume outside primary region. [source]
- Fix: Convert to single-region RS with appropriate tier. 3-region global clusters are 3× the base compute cost. [source]
Forgotten Atlas Search indexes
- Pattern: Atlas Search (Lucene) indexes deployed on collections that are no longer queried via Atlas Search (application switched to a different search path). [source]
- Detection: Atlas Search Index list → check queryCount via Atlas Search metrics. Search indexes on large collections add meaningful storage overhead. [source]
- Fix: Drop unused Search indexes via Atlas UI → Search → Indexes. [source]
References and Atlas Documentation Pointers
13. Atlas Flex Tier Cost Guidance
- Flex is the entry-level paid Atlas tier ($8–$30/month hard cap) that replaced M2/M5 shared clusters and Serverless instances (EOL: January 22, 2026). It is the most cost-efficient option for development, staging, and low-traffic production workloads. [source]
Flex billing model
When NOT to use Flex (upgrade to M10+ dedicated)
- Private Endpoints / VPC Peering required (security policy) [source]
- PITR backup required (compliance) [source]
- BYOK encryption at rest required [source]
- Data > 5 GB [source]
- Connections > 500 [source]
- Ops/sec > 500 sustained [source]
- Atlas Vector Search going to production (resource contention on Flex) [source]
Multi-environment cost strategy
- M0 (Free): individual dev - $0 [source]
- Flex: shared dev/staging - $8–$30/mo (saves ~$500–700/mo vs multiple M10s) [source]
- M10–M20: pre-production - $57–$100/mo [source]
- M30+: production - $190+/mo [source]
- For full Flex technical limits, migration steps, and tooling, see mongodb-atlas-flex-serverless. [source]
Children
- Instance Right-Sizing (frontier)
- Storage Tier Selection (frontier)
- Elastic Compute Autoscaling (frontier)
- Storage Autoscaling (frontier)
- Backup Cost Optimization (frontier)
- Network Egress Costs (frontier)
- Reserved Capacity and Committed Use (frontier)
- Cluster Pause (frontier)
- Index Storage Cost (frontier)
- Cost Monitoring (frontier)
- Tier 0 Tier 1 Tier 2 Strategy (frontier)
- Common Cost Overruns (frontier)
- MongoDB Atlas Flex and Serverless Tiers
Frontier under this node: Backup Cost Optimization, Cluster Pause, Common Cost Overruns, Cost Monitoring, Elastic Compute Autoscaling, Index Storage Cost, Instance Right-Sizing, Network Egress Costs, Reserved Capacity and Committed Use, Storage Autoscaling, Storage Tier Selection, Tier 0 Tier 1 Tier 2 Strategy