A MongoDB workload has three real destinations inside AWS: Amazon DocumentDB (MongoDB-compatible, fully managed), MongoDB Atlas running inside your AWS region, or self-managed MongoDB on EC2. They are not interchangeable — the right one depends on which MongoDB features you actually use, how much operational burden you want to own, and how the cost curve behaves at your scale. This page walks the tradeoffs, the DMS path to DocumentDB, the compatibility gotchas that derail teams, and the cutover. When the workload qualifies, an AWS MAP-funded partner runs the migration for you at little-to-no cost.
The single most common mistake teams make is treating "migrate MongoDB to AWS" as one project with one answer. It is three different projects depending on where the data lands. Get the destination right and the rest is mechanical; get it wrong and you discover six weeks in that a feature your app depends on does not exist on the target.
When someone says they want MongoDB on AWS, they almost always mean one of three things, and the words "MongoDB" and "AWS" hide the distinction. Amazon DocumentDB is an AWS-built, AWS-operated document database that speaks the MongoDB wire protocol and API — your drivers connect as if it were MongoDB, but the engine underneath is Amazon's, not MongoDB Inc.'s. MongoDB Atlas on AWS is the genuine MongoDB engine, built and operated by MongoDB Inc., that happens to run on EC2 instances inside an AWS region you choose — you get full feature parity because it literally is MongoDB. Self-managed MongoDB on EC2 is you installing and running the open-source or Enterprise MongoDB server on instances you own, with you responsible for replica sets, backups, patching, and scaling.
These three differ on every axis a migration cares about: API/feature compatibility, who carries the operational burden, the cost curve as you scale, how AWS-native the integration feels, and how locked-in you become. A team running a plain document store with simple CRUD and aggregation will be perfectly happy on DocumentDB and pay the least for the least ops. A team leaning on Atlas Search (full-text and vector), Online Archive, change streams in anger, or a very recent MongoDB server version will find DocumentDB frustrating and should keep the real engine — which means Atlas-on-AWS. A team with a hard requirement neither managed option satisfies (an exotic MongoDB version, a storage engine tweak, a compliance constraint forcing full control) accepts the ops tax of self-managed EC2.
The honest framing CloudRoute uses when triaging a MongoDB inquiry is a single question: does your application use any MongoDB feature that DocumentDB does not implement? Everything downstream — tooling, timeline, cost, and whether MAP funding applies — flows from the answer. The next sections give you the inputs to answer it yourself, then the mechanics to execute whichever path you land on.
Run the AWS DocumentDB compatibility tool against your real queries and index definitions before you pick a destination. If it returns clean, DocumentDB is usually the cheapest, lowest-ops home. If it flags features you depend on — text/vector search, GridFS, capped collections, certain aggregation operators — keep the real engine on Atlas-on-AWS. Do not decide on vibes; decide on the tool's output.
DocumentDB is AWS's answer to "I want a managed document database and I want it inside AWS with no MongoDB Inc. relationship." It is the default destination for the majority of straightforward MongoDB workloads — and the one most likely to qualify for MAP funding, because the target is an AWS-native service.
DocumentDB separates storage from compute the way Aurora does: a cluster volume that auto-scales to 64 TB, replicates six ways across three Availability Zones, and is fronted by a primary instance plus up to 15 read replicas. You get automated backups, point-in-time restore, encryption at rest with KMS, IAM authentication, and tight integration with the rest of AWS — CloudWatch metrics, VPC isolation, Secrets Manager for credentials, and Performance Insights. Operationally it is close to hands-off: AWS patches the engine, manages failover, and handles the storage layer entirely.
On compatibility, DocumentDB emulates the MongoDB API at roughly the 4.0 and 5.0 feature level, with newer engine versions continuing to roll out (an 8.0-class engine and in-place upgrades from 5.0 have shipped). For the bulk of application code — CRUD, the common aggregation pipeline stages, secondary indexes, transactions across documents and collections, change streams for the supported surface — your existing MongoDB drivers connect and behave as expected. Most teams migrate the data, point the connection string at the DocumentDB cluster TLS endpoint, and the application runs unchanged.
The cost story is favorable for steady-state workloads. You pay for instance-hours (DocumentDB instance classes), I/O, storage consumed, and backup storage. There is no per-engine licensing and no separate vendor invoice — it is one line on your AWS bill, which is also why credits and MAP funding apply cleanly to it. For a workload that fits within the supported feature set, DocumentDB is typically the lowest total cost of the three destinations once you account for the operational headcount you are NOT spending.
The catch — and it is a real one — is the compatibility ceiling. DocumentDB is API-compatible, not the MongoDB engine, so anything MongoDB Inc. ships that AWS has not implemented simply is not there. The next section lists exactly what to check. If your workload lives entirely inside the supported surface, DocumentDB is the right answer and the cheapest path. If it does not, forcing it onto DocumentDB means rewriting application features — which usually costs more than just keeping the real engine on Atlas-on-AWS.
Plain document workloads: CRUD-heavy services, content stores, catalogs, user/session data, event payloads — anything that uses MongoDB as a flexible JSON store with standard queries and aggregation.
You want zero MongoDB ops and zero vendor relationship: one AWS bill, AWS-managed patching and failover, IAM and KMS and VPC built in.
You want credits/MAP funding to apply cleanly: because DocumentDB is an AWS-native service, its consumption sits on your AWS bill and qualifies for AWS funding programs.
You depend on full-text or vector search: DocumentDB does not implement MongoDB text indexes or Atlas-style vector search. If search is core, this is disqualifying.
You use capped collections, GridFS, or TTL via collMod: these are unsupported or limited; apps that lean on them need rework.
You are on a bleeding-edge MongoDB version or use newer aggregation operators: verify each operator against the supported-operations list — emulation lags the latest MongoDB releases.
This is the section that saves projects. DocumentDB advertises MongoDB compatibility, and for most code it is genuine — but "compatible" is not "identical." Below is the honest list of features that are unsupported or limited as of 2026. Check your application against every line before you commit to DocumentDB as the destination.
The reliable way to do this is not to read a list and guess — it is to run the official AWS DocumentDB compatibility tool (the open-source compat-tool from awslabs) against your actual query log and index definitions, and to consult the "Supported MongoDB APIs, operations, and data types" and "Functional differences" pages in the DocumentDB documentation. The tool parses what your application actually does and flags the operators and features that will not work. Treat a clean run as a green light and any flags as a decision point: rework the feature, or change the destination to Atlas-on-AWS.
None of this means DocumentDB is a bad service — for the workloads that fit, it is excellent and cheap. It means "MongoDB-compatible" should never be taken on faith for a production migration. The half-day it takes to run the compatibility tool is the highest-leverage half-day in the whole project: it is the difference between a clean cutover and discovering a missing operator in production. A CloudRoute-routed partner runs this assessment as the first deliverable, precisely because it determines the destination and therefore the entire downstream plan.
If the compatibility tool flags features you cannot give up, the answer is usually not "rewrite the app" — it is "keep the real MongoDB engine, but run it inside AWS." That is what Atlas-on-AWS is: MongoDB Inc.'s managed Atlas service, deployed onto EC2 in the AWS region of your choice.
Atlas is MongoDB Inc.'s own fully managed database-as-a-service, and it runs on all three major clouds. Choosing AWS as the deployment target means your Atlas cluster lives on EC2 instances inside an AWS region (e.g., us-east-1, eu-west-1, me-central-1), co-located with the rest of your AWS workloads. You get the genuine MongoDB engine with full feature parity — Atlas Search (full-text and vector), change streams, the complete and current aggregation framework, the latest server versions, online archive, and triggers — because it is the real thing, not an emulation.
The integration with AWS is good, though not as deep as a native service. You connect over VPC peering or AWS PrivateLink so traffic stays off the public internet; you can pay through AWS Marketplace so Atlas consumption lands on your AWS invoice; and data egress within the same region is minimal. What you do not get is the single-pane-of-glass, IAM-native, one-bill experience of DocumentDB — Atlas is operated through MongoDB's control plane, billed (unless you route through Marketplace) by MongoDB, and governed by MongoDB's own access model layered onto AWS networking.
On cost, Atlas is generally more expensive than equivalently-sized DocumentDB for steady-state workloads, because you are paying MongoDB Inc.'s managed-service margin on top of the underlying EC2/EBS. What you buy for that premium is zero compatibility risk and full portability — because Atlas runs on every cloud, you are not locked to AWS the way DocumentDB locks you in. For teams that value multi-cloud optionality or that genuinely use the advanced MongoDB feature set, the premium is worth it.
A funding nuance worth stating honestly: because Atlas is a third-party (MongoDB) service rather than an AWS-native one, MAP funding and AWS credits apply less cleanly than they do to DocumentDB. AWS will still fund the migration engagement (the partner's work, landing zone, networking, cutover) under MAP for a qualifying workload, and routing Atlas billing through AWS Marketplace lets credits offset some consumption — but the cleanest, fullest funding story is DocumentDB. This is a real input to the destination decision, not a reason to force the wrong target: if your app needs Atlas Search, you need Atlas, and the marginally less complete funding is the correct trade.
The third destination is running MongoDB yourself on EC2: you install the server, configure the replica set, manage backups, patch the engine, and scale the cluster by hand or with automation you build. It is the right answer in a narrow set of cases and the wrong answer in most.
Self-managed gives you total control. You pick the exact MongoDB version (including very recent releases or specific patch levels), tune the storage engine and instance/EBS configuration precisely, run MongoDB Enterprise features with your own license, and keep the database entirely inside your own AWS account with no third-party control plane and no API-emulation gaps. For a workload with a hard requirement that neither DocumentDB nor Atlas satisfies — an unusual version pin, a compliance regime that forbids a vendor control plane, a bespoke topology — this is the only option that works.
The cost is operational, and it is larger than teams expect. You own replica-set configuration and failover testing, backup strategy and restore drills, monitoring and alerting, security patching on AWS's shared-responsibility line, capacity planning, and upgrades. That is real, ongoing senior-engineer time — frequently the equivalent of a meaningful fraction of an SRE — which is exactly the cost the two managed options remove. On paper EC2 instance-hours can look cheaper than a managed service; in practice the loaded cost of the humans running it usually erases the difference and then some.
The honest recommendation: choose self-managed only when a specific, articulable requirement forces it. "We want control" is rarely a sufficient reason on its own once you price the ops. For the overwhelming majority of MongoDB-to-AWS migrations, the real decision is DocumentDB versus Atlas-on-AWS, and self-managed is the fallback for genuine edge cases. A migration partner will tell you the same thing — and if you do go self-managed, the MAP-funded engagement still covers building the landing zone, the replica set, and the cutover automation.
Once the destination is chosen, moving the data is well-trodden. The tooling differs by target: AWS DMS is the workhorse for MongoDB → DocumentDB; MongoDB's own Live Migration / mongosync is the path to Atlas; native dump/restore covers smaller datasets and self-managed.
For MongoDB → DocumentDB, AWS Database Migration Service (DMS) is the standard tool. DMS accepts a self-managed MongoDB (on EC2 or on-premises) — or other MongoDB-compatible source — as the source endpoint and DocumentDB as the target endpoint, and it runs the migration in document mode for MongoDB-family endpoints. The pattern is the same one DMS uses everywhere: a full load copies existing collections and documents, then change data capture (CDC) tails the source's oplog and replicates ongoing writes to the target, keeping the two in sync until you are ready to cut over. Because DMS supports all the BSON data types DocumentDB supports, the type mapping is clean. For like-to-like moves, DMS also offers homogeneous data migrations that drive MongoDB's native tools under the hood for fast, native-fidelity transfers.
For very small or one-shot datasets, you do not need DMS at all: mongodump from the source and mongorestore into DocumentDB is the simplest possible migration, accepting a short write-freeze while the dump/restore runs. The tradeoff is downtime — dump/restore has no CDC, so writes during the copy are lost unless you stop them. Use it for dev/test, for small reference collections, or when a brief maintenance window is acceptable; use DMS with CDC whenever near-zero downtime matters.
For MongoDB → Atlas-on-AWS, you stay inside MongoDB's toolchain. Atlas Live Migration (powered by mongosync) replicates from the source cluster into the destination Atlas cluster with continuous sync and a managed cutover — conceptually the same full-load-plus-CDC model, but operated through Atlas rather than DMS. Because both sides are the real MongoDB engine, there is no compatibility translation to worry about; it is a like-to-like replication. For self-managed EC2 targets you have the full menu — mongodump/mongorestore, mongosync, or replica-set initial sync — chosen by dataset size and downtime tolerance.
Source endpoint: your MongoDB on EC2/on-prem, in document mode, with a user that can read the oplog (CDC requires a replica set so the oplog exists).
Replication instance: a DMS instance sized to your throughput, in the same VPC as (or peered to) the DocumentDB cluster.
Target endpoint: the DocumentDB cluster TLS endpoint, with the CA bundle and credentials in Secrets Manager.
Task: "full load + ongoing replication," with table/collection mappings and a validation pass; monitor lag in CloudWatch until cutover.
DMS migrates documents, not necessarily your indexes in the optimal order. Create secondary indexes on the DocumentDB target after the full load completes (or use the DocumentDB Index Tool to export source indexes and replay them), then let CDC catch up. Building indexes up front slows the load and can balloon write amplification.
The migration is not done when the data is copied; it is done when production traffic is safely on the new cluster and you have proven you can roll back. This is the highest-risk hour of the project, and it is entirely manageable with a written runbook.
The near-zero-downtime cutover sequence is the same regardless of destination, because all three paths support continuous replication. First, you let full-load-plus-CDC run until replication lag is consistently near zero — the target is a live mirror of the source. Second, at the cutover window you stop or drain writes to the source (put the application in a brief read-only or maintenance mode), let CDC drain the final in-flight changes so source and target are byte-for-byte equivalent, and run a validation/row-count check. Third, you flip the application's connection string to the new endpoint (DocumentDB TLS endpoint, Atlas SRV string, or your EC2 replica-set URI) and resume writes against the new cluster. With a clean drain, the write-freeze is measured in minutes, not hours.
The connection-string flip should never be a code deploy under time pressure. Put the database URI behind configuration — an environment variable, AWS Secrets Manager, or Parameter Store — so cutover is a config change you can make (and reverse) in seconds without shipping code. Pre-stage the new credentials and CA bundle, and rehearse the flip in staging against the migrated target before the production window.
Rollback is the part teams skip and regret. Before you freeze writes, you must know exactly how to revert: keep the source cluster running and untouched through a defined bake period (24–72 hours is typical), so that if the new cluster misbehaves you flip the connection string back to the source with zero data loss. The discipline that makes rollback safe is simple: do not write to the source after cutover, and do not decommission it until the new cluster has carried production cleanly for the full bake period. Only then do you tear down the old environment.
Everything above is the work. CloudRoute's role is to make sure you do not do it alone or pay full freight for it: we route you to a vetted AWS partner who runs the migration end to end, and for a qualifying workload the AWS Migration Acceleration Program funds the engagement so your out-of-pocket cost is low to nil.
AWS's Migration Acceleration Program (MAP) is structured in three phases — Assess (TCO and readiness analysis, including running the DocumentDB compatibility tool to pick the destination; often free), Mobilize (the landing zone, networking, the DMS or mongosync pipeline, and a pilot), and Migrate & Modernize (the production data move and cutover). AWS provides credits and funding scaled to the size of the migration, delivered through an APN partner. For qualifying workloads — typically those with a meaningful projected AWS-spend commitment after migration — MAP credits cover a large share of the migration and modernization cost, and the partner is paid through MAP rather than by you. The result is a done-for-you migration at little-to-no cost.
The honest boundary: MAP funding is for qualifying migrations, and the cleanest funding applies when the destination is an AWS-native service like DocumentDB, whose consumption lands on your AWS bill. For an Atlas-on-AWS destination, MAP still funds the migration engagement and credits can offset Marketplace-billed Atlas consumption, but the funding picture is less complete than for DocumentDB — a real input to the destination decision. Where MAP funding does not apply, CloudRoute is still a vetted-partner referral that de-risks the cutover: you get a partner with a track record of MongoDB-to-AWS moves rather than running your first one solo.
Mechanically, you tell CloudRoute three things — your current MongoDB setup (Atlas, self-managed, on-prem), the features your app depends on, and your rough scale and timeline. We match you to a partner with specific MongoDB-to-AWS experience and the right AWS partner tier to file MAP. The partner runs the compatibility assessment first (which settles the destination), then builds the landing zone, stands up the DMS/mongosync pipeline, runs the data sync, executes the cutover with a rollback plan, and decommissions the source after the bake period. You stay in control of the go/no-go at the cutover gate; the partner does the work. For the funding mechanics in detail, see the AWS credits and MAP cross-links below.
The three destinations side by side on the axes a MongoDB migration actually cares about. There is no universally "best" row — the right destination is the one whose compatibility column matches the MongoDB features your application depends on, at a cost and ops level you can live with.
| Dimension | Amazon DocumentDB | MongoDB Atlas on AWS | Self-managed on EC2 |
|---|---|---|---|
| What it is | AWS-built, MongoDB-API-compatible managed DB | The real MongoDB engine, MongoDB-managed, on AWS | Open-source / Enterprise MongoDB you run yourself |
| Compatibility | API-compatible (~v4.0/5.0-class; newer rolling out); feature gaps | Full parity — it IS MongoDB, latest versions | Full parity, any version you choose |
| Feature coverage | No text/vector search, GridFS, capped collections; operator gaps | Everything (Atlas Search, vector, change streams, etc.) | Everything the chosen MongoDB version ships |
| Operational burden | Lowest — AWS patches, fails over, scales storage | Low — MongoDB Inc. manages the cluster | Highest — you own replica sets, backups, patching, scaling |
| Cost curve (steady state) | Typically lowest; one AWS bill, no licensing | Higher — managed-service margin on top of EC2/EBS | EC2/EBS cheap on paper; loaded ops cost usually erases it |
| AWS-native integration | Deep — IAM, KMS, VPC, CloudWatch, one bill | Good — PrivateLink/peering, Marketplace billing | Whatever you build yourself in your account |
| Lock-in / portability | AWS-locked (AWS-specific engine) | Portable — Atlas runs on every cloud | Portable — standard MongoDB, you own it |
| Data-move tooling | AWS DMS (full load + CDC); dump/restore | Atlas Live Migration / mongosync | mongodump/restore, mongosync, replica-set sync |
| MAP funding fit | Cleanest — AWS-native consumption on your AWS bill | Engagement funded; consumption funding via Marketplace credits | Engagement funded; you run the resulting infra |
| Pick it when | Your queries pass the compatibility tool | You need full MongoDB features or multi-cloud | A hard requirement forces full control |
Situation: Running their own MongoDB replica set on EC2 had become an ops drain — two engineers were spending meaningful time on patching, backup drills, and a scary failover earlier in the year. They wanted off self-managed and onto something managed, with credits/MAP funding if possible. Open question: DocumentDB (cheaper, AWS-native) or stay on the real engine via Atlas? Their app used change streams heavily and one service relied on text search.
What CloudRoute did: Routed within 22 hours to an AWS Advanced-tier partner with document-database and DMS experience. Partner ran the DocumentDB compatibility tool in week 1 (the MAP Assess phase): change streams were fine, but the text-search dependency and a couple of aggregation operators failed — disqualifying DocumentDB for the search service. Decision: migrate the bulk of collections to DocumentDB via DMS (full load + CDC) and keep the search-dependent service on Atlas-on-AWS via PrivateLink, billed through Marketplace so credits applied. Landing zone + DMS pipeline stood up in Mobilize; production cutover with a 48-hour rollback bake in Migrate.
Outcome: Cutover write-freeze: ~7 minutes after CDC drained. Self-managed replica set decommissioned after the 48-hour bake — zero data loss. Two engineers reclaimed from MongoDB ops. MAP funded the assessment, landing zone, and migration engagement; the bulk DocumentDB consumption and the Marketplace Atlas spend were offset by AWS credits. CloudRoute's commission was paid by the partner from MAP — the customer paid $0 for the engagement.
engagement window: ~9 weeks · cutover downtime: ~7 min · data migrated: ~1.8 TB · engagement cost to customer: $0 (MAP-funded)
CloudRoute routes you to a vetted AWS partner who picks the right destination, runs the data sync and cutover, and — for qualifying workloads — does it MAP-funded at low-to-$0 cost. You keep the go/no-go; the partner does the work.