MongoDB Atlas Cost Optimization

Parent: MongoDB Atlas · Published reference · snapshot 2026-09-08 · skill mongodb-operations-expert/references/mongodb-cost-optimization.md

↓ Facts as markdown all context files

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

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#mongodb-atlas-cost-optimization]

Scope

In scope: Atlas dedicated clusters (M10 and above), replica sets, sharded clusters, backup, network egress, index storage, and committed-use pricing. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#scope]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#scope]

Quick Reference — Cost Levers by Impact

Use this table to prioritize effort. Detail for each lever is in the numbered sections below. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#quick-reference-cost-levers-by-impact]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#sizing-philosophy]

CPU targets

Sustained CPU < 60%: healthy headroom. If sustained CPU consistently sits below 30%, the cluster is a candidate for one tier down. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#cpu-targets]
P99 CPU < 80%: spikes above 80% during batch windows are acceptable if they are brief and predictable. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#cpu-targets]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#cpu-targets]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#ram-targets]
Cache utilization > 90%: investigate query patterns first (indexes, projections, covered queries) before adding RAM. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#ram-targets]
Target 70–85% cache utilization as a healthy steady state. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#ram-targets]

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). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#iops-targets]
For write-heavy workloads, watch "Disk Queue Depth" - values above 1 sustained indicate I/O saturation. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#iops-targets]

Tier step-down methodology

Pull 30-day P50/P95/P99 CPU, memory cache utilization, and IOPS from Atlas Metrics or Data Explorer. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#tier-step-down-methodology]
Identify the busiest 3-hour window in the week (typically Monday morning or end-of-month batch). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#tier-step-down-methodology]
Simulate one tier down: will P95 CPU stay below 75%? Will working set still fit? [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#tier-step-down-methodology]
For RS primaries, validate oplog window stays above 24 hours after downsizing (oplog window shrinks with smaller disks). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#tier-step-down-methodology]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#tier-step-down-methodology]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#cluster-count-reduction]

When to use Standard (GP3)

OLTP workloads with moderate write rates (< 3,000 sustained IOPS). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-standard-gp3]
Analytical or reporting workloads. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-standard-gp3]
Development, staging, and QA environments - always use standard here. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-standard-gp3]
Majority of M30–M60 production clusters that are not latency-sensitive. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-standard-gp3]

When to use Provisioned IOPS

Write-heavy workloads where disk queue depth consistently exceeds 1. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-provisioned-iops]
When you need deterministic IOPS SLA for compliance (fintech, healthcare). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-provisioned-iops]
Clusters where you can't size disk larger (data volume constraint) but need more IOPS. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-provisioned-iops]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-provisioned-iops]

When to use NVMe

Hot data caches (Okta session store, rate-limiting counters, real-time leaderboards). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-nvme]
When working set exceeds 500 GB and cache miss latency is unacceptable. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-nvme]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-use-nvme]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#cost-optimization-rule]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#what-atlas-compute-autoscaling-does]

Scale-up rules (Atlas defaults)

CPU utilization > 75% for 1 hour (or shorter sustained window depending on tier). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#scale-up-rules-atlas-defaults]
OR cache dirty bytes approaching capacity. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#scale-up-rules-atlas-defaults]
Scale-up is immediate (rolling restart, no downtime for RS). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#scale-up-rules-atlas-defaults]

Scale-down rules (Atlas defaults)

CPU utilization < 50% for the trailing 24 hours. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#scale-down-rules-atlas-defaults]
The 24-hour delay is intentional - Atlas will not oscillate. Reduce to 12 hours only if your workload has predictable weekly patterns (e.g., weekday-only traffic). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#opt-in-vs-opt-out-strategy]
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). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#opt-in-vs-opt-out-strategy]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#monitoring-autoscaling-events]

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). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#atlas-disk-autoscaling-default]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#why-the-90-trigger-is-dangerous]

Disk space alert setup (Atlas UI)

Configure in Atlas UI → Project → Alerts → Add Alert: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#disk-space-alert-setup-atlas-ui]
- Condition: Disk Utilization > 85% [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#disk-space-alert-setup-atlas-ui]
- Notification channels: PagerDuty + Slack channel [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#disk-space-alert-setup-atlas-ui]
- Evaluation window: 5 minutes [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#manual-vs-auto-disk-scaling]
Auto scaling is appropriate when ingest rate is variable and unpredictable. Set a maximum disk size cap in cluster configuration to avoid runaway expansion. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#manual-vs-auto-disk-scaling]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#compaction-and-space-recovery]
After TTL index deletes or large bulk-delete operations, compaction can recover 30–60% of disk, avoiding an autoscale event. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#compaction-and-space-recovery]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#backup-pricing-model]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#snapshot-retention-tuning]
Recommended retention by environment: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#snapshot-retention-tuning]
Applying minimal retention to staging/dev/QA clusters alone can reduce backup spend by 20–40% for organizations with many non-prod clusters. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#snapshot-retention-tuning]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#queryable-backups-vs-continuous-backups]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#queryable-backups-vs-continuous-backups]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#cross-region-backup-cost]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#cross-region-backup-cost]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#free-paths]
Private Link / Private Endpoint within the same region: free for data transfer; you pay for the endpoint hour only. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#free-paths]

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). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#charged-paths]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#charged-paths]
Atlas Data Federation: egress from Atlas Data Federation to S3 or external storage layers has its own pricing. Review federation query patterns. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#charged-paths]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#marketplace-billing-and-egress-credits]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#egress-cost-reduction-tactics]
Use VPC peering or Private Link everywhere - eliminate public endpoint usage. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#egress-cost-reduction-tactics]
Minimize cross-shard scatter queries in sharded clusters (scatter-gather reads data from all shards, multiplying egress if shards span regions). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#egress-cost-reduction-tactics]
Atlas Charts and Atlas Data Federation running cross-region against production clusters generate egress at query time. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#egress-cost-reduction-tactics]

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: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#atlas-committed-use-discounts]
- 1-year commitment: ~15% discount [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#atlas-committed-use-discounts]
- 2-year commitment: ~25% discount [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#atlas-committed-use-discounts]
- 3-year commitment: ~30–35% discount [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#atlas-committed-use-discounts]

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: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#marketplace-private-offers]
- Atlas Search (Lucene-powered) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#marketplace-private-offers]
- Atlas Stream Processing [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#marketplace-private-offers]
- Professional services [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#marketplace-private-offers]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#enterprise-discount-programs-edp]
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?" [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#enterprise-discount-programs-edp]

When to trigger a renegotiation

Annual Atlas spend > $100k: dedicated Technical Account Manager and discount eligibility. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-trigger-a-renegotiation]
Annual Atlas spend > $250k: committed-use discount almost always warranted. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-trigger-a-renegotiation]
At Okta's $300k cost optimization target: combination of right-sizing + committed-use renegotiation + Marketplace private offer is the typical playbook. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-to-trigger-a-renegotiation]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#what-cluster-pause-does]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#savings-from-pausing]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#cold-start-time]

Pause schedule automation

Use Atlas API + a cron job or Atlas Scheduled Triggers to automate pause/resume for non-production clusters: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#pause-schedule-automation]

Recommended pause schedule for dev/staging

Pause: weekdays 8pm local time [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#recommended-pause-schedule-for-devstaging]
Resume: weekdays 7am local time [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#recommended-pause-schedule-for-devstaging]
Pause all weekend (Friday 8pm → Monday 7am) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#recommended-pause-schedule-for-devstaging]
Savings: ~65% of compute hours eliminated [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#recommended-pause-schedule-for-devstaging]

Pause limitations

Clusters with active Atlas Search indexes cannot be paused (as of Atlas 7.x). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#pause-limitations]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#pause-limitations]
Paused clusters still run scheduled Atlas triggers and Atlas Charts queries - review and disable these before pausing. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#pause-limitations]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#indexes-and-storage-billing]

The too-many-indexes anti-pattern

Teams frequently create indexes during development and never prune them. Common patterns: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#the-too-many-indexes-anti-pattern]
- ESR (Equality, Sort, Range) indexes created separately instead of as compound indexes. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#the-too-many-indexes-anti-pattern]
- Indexes created for a feature that was never launched or was retired. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#the-too-many-indexes-anti-pattern]
- Redundant prefix indexes: {a:1} when {a:1, b:1} already exists (the compound covers the single-field case). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#the-too-many-indexes-anti-pattern]
- Text indexes on every string field "just in case." [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#the-too-many-indexes-anti-pattern]

Monitoring index size

In Atlas Data Explorer or mongosh: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#monitoring-index-size]
Atlas Metrics also exposes "Index Size" at the cluster level in the Storage metrics group. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#monitoring-index-size]

Finding unused indexes

For Atlas clusters, use Atlas Performance Advisor - it surfaces "Redundant Indexes" and "Unused Indexes" recommendations automatically. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#finding-unused-indexes]

Safe index removal process

Identify candidate unused index via $indexStats over a 14-day window (catch monthly jobs). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#safe-index-removal-process]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#safe-index-removal-process]
If no degradation observed, drop: db.collection.dropIndex("index_name"). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#safe-index-removal-process]
For large indexes (> 10 GB), expect an immediate disk space reduction after compaction. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#safe-index-removal-process]

Atlas Billing Dashboard

Navigate to Atlas Organization → Billing to see: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#atlas-billing-dashboard]
- Invoices: line-item breakdown by project and cluster. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#atlas-billing-dashboard]
- Cost Explorer (Atlas Advanced): filter by project, cluster, service type (compute, storage, backup, data transfer) across date ranges. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#atlas-billing-dashboard]
- Usage details CSV export: machine-readable daily usage for offline analysis. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#atlas-billing-dashboard]

Tagging strategy

Atlas supports resource tags on projects and clusters. Align tags with your cloud provider's tagging taxonomy for cost allocation: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#tagging-strategy]
Tags flow through to Marketplace bills and can be used in cloud provider Cost Explorer for consolidated reporting. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#tagging-strategy]

Budget alerts

Set Atlas budget alerts at the organization and project levels: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#budget-alerts]
- Organization budget alert: 90% and 110% of monthly budget. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#budget-alerts]
- Per-project alert: for projects with known spend floors; alert at 120% of 3-month average. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#budget-alerts]
- Alert destinations: email, PagerDuty, Slack webhook. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#automated-cost-anomaly-detection]

Monthly cost review cadence

For accounts > $10k/month Atlas spend, establish a monthly review: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#monthly-cost-review-cadence]
- Pull invoice line items, sort by cost descending. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#monthly-cost-review-cadence]
- Identify top 5 clusters by cost - are they appropriately sized? [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#monthly-cost-review-cadence]
- Review autoscaling events in Activity Feed. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#monthly-cost-review-cadence]
- Check for orphaned clusters (no connections in 30 days per Atlas access logs). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#monthly-cost-review-cadence]
- Validate backup retention policies match current policy. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#monthly-cost-review-cadence]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#tier-definitions-internal-operational-classification]

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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#mixing-tiers-strategically]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#mixing-tiers-strategically]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#mixing-tiers-strategically]

Okta-scale application

For an account targeting $300k in savings: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#okta-scale-application]
- Audit all clusters: classify into T0/T1/T2. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#okta-scale-application]
- Right-size T1 clusters (likely 20–40% of spend, 40% reduction = $30–60k savings). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#okta-scale-application]
- Pause T2 clusters off-hours (~$60–80k savings if significant T2 footprint). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#okta-scale-application]
- Negotiate committed-use discount on remaining T0/T1 spend (~15–25% = $60–120k savings). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#okta-scale-application]
- Prune backup retention on T1/T2 (~$20–30k savings). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#okta-scale-application]
- Total: $170–290k annualized, reaching or exceeding the $300k target with combined levers. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#okta-scale-application]

Over-provisioned IOPS

Pattern: Team provisions io1 storage with 10,000 IOPS "to be safe" for a cluster consuming 600 IOPS at P95. Detection: Atlas Metrics → Disk IOPS → compare provisioned vs actual over 30 days. Fix: Switch to GP3 storage, set IOPS to actual_P95 * 1.5 (minimum 3,000 for GP3). Savings: Can be 50–70% of storage cost for over-provisioned io1 clusters. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#over-provisioned-iops]

Oversized clusters

Pattern: M80 cluster purchased for a projected workload peak that never materialized. Team inherited it and never questioned the spec. Detection: 30-day CPU P95 < 30% AND page faults near zero AND disk utilization < 50%. Fix: Rolling tier-down via Atlas UI. Start one tier at a time, validate, continue. Savings: Each tier step is roughly 40–60% cost reduction. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#oversized-clusters]

Redundant backups

Pattern: Both continuous backups (PITR) and aggressive snapshot retention enabled on dev/staging clusters. 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. Fix: Disable PITR on staging; reduce to 1-day daily retention for dev clusters. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#redundant-backups]

Orphaned clusters

Pattern: Cluster created for a proof-of-concept 18 months ago. PoC ended, cluster never deleted. Detection: Atlas Data Explorer or listClusters API → filter for clusters with zero connections in the past 30 days via Atlas access logs. Fix: Confirm with application team, take final snapshot, delete cluster. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#orphaned-clusters]

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. Detection: Atlas Billing → Data Federation line items spiking. Atlas Data Federation logs show query frequency. Fix: Add query result caching, reduce schedule frequency, add $match filters to reduce data scanned. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#runaway-data-federation-queries]

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. Detection: Atlas cluster topology → global write distribution map → low write/read volume outside primary region. Fix: Convert to single-region RS with appropriate tier. 3-region global clusters are 3× the base compute cost. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#multi-region-clusters-where-single-region-suffices]

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). Detection: Atlas Search Index list → check queryCount via Atlas Search metrics. Search indexes on large collections add meaningful storage overhead. Fix: Drop unused Search indexes via Atlas UI → Search → Indexes. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#forgotten-atlas-search-indexes]

References and Atlas Documentation Pointers

Atlas Cluster Autoscaling [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#references-and-atlas-documentation-pointers]
Atlas Backup Documentation [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#references-and-atlas-documentation-pointers]
Atlas Billing [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#references-and-atlas-documentation-pointers]
Atlas Performance Advisor [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#references-and-atlas-documentation-pointers]
Atlas API - Clusters [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#references-and-atlas-documentation-pointers]
$indexStats aggregation stage - MongoDB Manual [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#13-atlas-flex-tier-cost-guidance]

Flex billing model

Ops/sec tiered, billed hourly prorated - $8 base (100 ops/sec, 5 GB), caps at $30/month at 500 ops/sec [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#flex-billing-model]
No per-document billing (unlike the deprecated Serverless RPU model) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#flex-billing-model]
No runaway billing: $30/month is the absolute maximum regardless of load spikes [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#flex-billing-model]

When NOT to use Flex (upgrade to M10+ dedicated)

Private Endpoints / VPC Peering required (security policy) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-not-to-use-flex-upgrade-to-m10-dedicated]
PITR backup required (compliance) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-not-to-use-flex-upgrade-to-m10-dedicated]
BYOK encryption at rest required [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-not-to-use-flex-upgrade-to-m10-dedicated]
Ops/sec > 500 sustained [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-not-to-use-flex-upgrade-to-m10-dedicated]
Atlas Vector Search going to production (resource contention on Flex) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#when-not-to-use-flex-upgrade-to-m10-dedicated]

Multi-environment cost strategy

M0 (Free): individual dev - $0 [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#multi-environment-cost-strategy]
Flex: shared dev/staging - $8–$30/mo (saves ~$500–700/mo vs multiple M10s) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#multi-environment-cost-strategy]
M10–M20: pre-production - $57–$100/mo [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#multi-environment-cost-strategy]
M30+: production - $190+/mo [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#multi-environment-cost-strategy]

For full Flex technical limits, migration steps, and tooling, see mongodb-atlas-flex-serverless. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-cost-optimization/#multi-environment-cost-strategy]

Where this helps

Preparing for an Atlas cost-optimization initiative where the target is a specific dollar figure, such as a committed six-figure annual reduction, and levers need to be prioritized by impact. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Deciding whether a cluster is actually oversized before committing to a tier step-down, using CPU/RAM/IOPS targets rather than gut feel. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Auditing backup spend across many non-production clusters where default retention policies (7 daily + 4 weekly + 12 monthly + 2 yearly) are needlessly aggressive. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Setting up automated pause/resume schedules for dev and staging clusters that sit idle outside business hours. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Project ideas

Build an automated pause/resume schedule for non-production clusters using the Atlas API plus a cron job or Atlas Scheduled Triggers, targeting the recommended weekday-evening/weekend pause window. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build a monthly cost-review script against the Atlas Billing API that surfaces the top 5 clusters by cost, flags clusters with zero connections in 30 days, and checks autoscaling events in the Activity Feed. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Run a safe index-removal pipeline: identify unused indexes via $indexStats over a 14-day window, hide them with hideIndex(), monitor, then drop. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build a budget-alert and cost-anomaly pipeline that flags a >20% day-over-day spend spike per project for investigation. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Antipatterns

Provisioning IOPS "to be safe" far above the P95 actual usage, instead of matching provisioned IOPS to actual_P95 × 1.5 with a documented minimum. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Running internal dashboards and low-priority analytics workloads on the same tier and cluster as customer-facing (Tier 0) workloads, letting a noisy internal job degrade production performance. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Leaving both continuous backup (PITR) and aggressive snapshot retention enabled on dev/staging clusters, where minimal retention alone can cut non-prod backup spend 20–40%. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Letting proof-of-concept clusters persist indefinitely after the PoC ends instead of tracking connection activity and decommissioning orphaned clusters. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Known issues

Atlas does not automatically reclaim disk space after large deletes — a compact pass on secondaries then the primary is required to recover the 30–60% of disk that large bulk deletes or TTL-driven deletes typically leave behind. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
The default 90% disk-autoscaling trigger can let a high-write cluster spike past 90% before the expansion completes, which can stall WiredTiger writes; configuring the alert at 85% buys 2–4 hours of headroom instead. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Clusters with active Atlas Search indexes cannot be paused (as of Atlas 7.x), and any cluster paused more than 60 days is automatically resumed by Atlas regardless of intent. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Compute autoscaling only moves one tier at a time and won't skip tiers, so a workload that spikes far past its current tier's headroom may need a manual tier change rather than relying on autoscaling alone. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

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

← the whole tree · 3D view· how to read this page