More about AWS Big Data
- AWS Snowball vs Snowmobile: Data -Migration Options Compared
- AWS Snowball Edge: Data Shipping and Compute at the Edge
- AWS Snowmobile: Migrate Data to the Cloud With the World’s Biggest Hard Disk
- AWS Snowball Family: Options, Process, and Best Practices
- MongoDB on AWS: Managed Service vs. Self-Managed
- Cassandra on AWS Deployment Options: Managed Service or Self-Managed?
- Elasticsearch in Production: 5 Things I Learned While Using the Popular Analytics Engine in AWS
- AWS Data Lake: End-to-End Workflow in the Cloud
- AWS ElastiCache for Redis: How to Use the AWS Redis Service
- AWS Data Analytics: Choosing the Best Option for You
- AWS Big Data: 6 Options You Should Consider
May 26, 2021
Topics: Cloud Volumes ONTAP AWSDatabaseAdvanced8 minute readAnalytics
MongoDB, like other NoSQL databases that support JSON-styled, document-oriented storage systems, offers scalability and flexibility that complex applications today require. As such, running MongoDB can be a great enabler for your AWS big data workloads.
But how exactly are you going to run MongoDB on AWS?
This post will introduce you to the two major deployment options for MongoDB on AWS: using a managed service or managing it yourself based on Amazon EC2 instances.
Read on to find out about:
- NoSQL and MongoDB at a Glance
- Can I Use MongoDB on AWS?
- How Do I Use MongoDB on AWS?
- Managed Deployment Options for MongoDB on AWS
- Running MongoDB on AWS EC2: The Self-Managed Option
- Migrating MongoDB to AWS
- A Third Option?: MongoDB Deployment in AWS with Cloud Volumes ONTAP
NoSQL and MongoDB at a Glance
As a NoSQL database, MongoDB addresses the scalability needs of modern data applications. That’s because unlike traditional databases, MongoDB typically stores a collection of schema-less data which gives developers the flexibility they need to map out different data types without a database administrator’s help. It’s a DevOps-focused database.
Some of the common use cases for MongoDB include:
- Product catalogs for e-commerce applications
- Mobile databases
- Real-time analytics
- Operational intelligence
- Geospatial applications
- Content management systems
Can I Use MongoDB on AWS?
Whether you’re already using AWS and looking to adopt MongoDB or if you want to migrate an existing MongoDB database to the cloud, the good news is that AWS and MongoDB can combine to offer the best of both services. When you combine MongoDB with cloud services like AWS, the benefits include increased speed and massive economies of scale.
How Do I Use MongoDB on AWS?
Using MongoDB on AWS will really depend on which deployment option you decide on for the database. There are two ways to use MongoDB on AWS:
- With the fully managed-service options, Amazon DocumentDB or MongoDB Atlas third- party service
- Self-managed option using MongoDB on raw Amazon EC2 compute instances.
For the rest of this post, we’ll explore the pros and cons of the two deployment options and how to migrate your existing MongoDB cluster to AWS.
Managed Deployment Options for MongoDB on AWS
In the managed deployment option, the responsibility of maintaining and scaling the database is abstracted away from you. You pay for what you use with less operational burden. For this managed service option, you can either use MongoDB on AWS through Amazon DocumentDB, the native-AWS managed service, or use MongoDB Atlas, which is a third-party managed option.
Amazon DocumentDB: The Managed Database Service by Amazon
Amazon offers Amazon DocumentDB, a MongoDB-compatible and fully managed database service that is fast, scalable, and highly available. MongoDB’s source code is not shared or used by Amazon DocumentDB. However, it began as a clone of MongoDB version 3.6, which Amazon rebuilt as a closed-source to address scalability pain points from customers.
A decision to use Amazon DocumentDB comes down to availability, scalability, data protection, manageability, automation, and low maintenance.
Is AWS DocumentDB the Same as MongoDB?
While Amazon DocumentDB is a compatible service for use with MongoDB and MongoDB workloads, Amazon DocumentDB is not the same as MongoDB. The major difference is that DocumentDB is a managed service. There are also key differences and a few limitations to using DocumentDB, which we’ll detail below.
AWS DocumentDB Managed Service for MongoDB: Pros and Cons
- Highly available: Amazon DocumentDB provides a service level agreement (SLA) of 99.99% availability and can achieve twice the throughput of available MongoDB solutions at the moment. Amazon DocumentDB instances are distributed across three Availability Zones (AZs). A failure in the primary node triggers a failover and one healthy node in the cluster is automatically promoted with no downtime.
- Higher throughput: Amazon DocumentDB can achieve twice the throughput of available MongoDB solutions at the moment making it a preferred alternative to MongoDB.
- Scalability: The storage and compute capabilities of Amazon DocumentDB are decoupled, ensuring that each can be managed and scaled independently. You can scale the number of reads into the millions per second, all with low latency. Amazon DocumentDB scales based on demands. It scales up as your data grows automatically up to 64 TB.
- Data protection: The shared AWS Responsibility Model applies to protecting your data in Amazon DocumentDB.
- Manageability: Amazon DocumentDB is a fully managed service. You don’t need to worry about managing your clusters. It’s all taken care of by AWS.
- Low maintenance: As a managed database, Amazon takes care of maintenance, patches, and upgrades for you. AWS is responsible for security patches, upgrades, maintenance thereby abstracting the operational burden away from you.
- Supported Instance Types: Amazon DocumentDB currently supports the use of R5, R4, and T3 Amazon EC2 instance types. These supported instances each have their own limits in memory, connection, and open transaction-per-limit capabilities.
- Regional Limits: Amazon DocumentDB is currently available in 15 AWS regions, and each region has regional quotas and limits on the cluster, instances, and event subscriptions.
- Aggregation Limits: Amazon DocumentDB has an aggregation limit of 500.
- Data Types and Indices Limitation: Amazon DocumentDB can’t be used with the Decimal128 data type. It also doesn’t support the use of case insensitive indices.
- Cluster Types: Amazon DocumentDB cluster size has a limit of 64TB with a document size of 16 MB with 1000 users per cluster limit.
- TTL Constraints: Deleting from a TTL index isn’t assured within a specific timeframe and is affected by factors such as the document size, instance resource utilization, and overall throughput.
- Field Name Restrictions: With Amazon DocumentDB, you can't have dot and $ prefix in fieldnames.
The Third-Party Managed Option: MongoDB Atlas
There is another option for running MongoDB as a managed service outside of AWS. MongoDB Atlas is the Database-as-a-Service (DBaaS) platform built by the same team that created MongoDB. It has all the features of MongoDB with the benefits of being fully managed.
MongoDB Atlas offers users a managed, pay-as-you-go pricing model with the ability to deploy on any cloud service provider of their choice, AWS included. It provides an automated patching and one-click upgrade from high availability to scalability and security to disaster recovery. Its sharding feature allows users to scale beyond a single server’s limits and across a range of instances with zero application downtime.
Running MongoDB on AWS EC2: The Self-Managed Option
The other option for running Mongo DB on AWS is to self-manage the database built on AWS components.
The self-managed deployment option is a do-it-all approach. With this option, you’re going to be in charge of how the database is managed. You install it, you configure the settings to match your requirements, and you maintain the cluster.
Deploying MongoDB on EC2 Using the Marketplace
MongoDB can be installed on Amazon EC2 or deployed using the AWS Marketplace. First, you will need to get your deployment planning and set up the single production node. This will be followed up with setting up a place for storage before getting your MongoDB instance running. You could also scale your deployment on a multi-node replica or a shared cluster.
The Self-Managed Option for MongoDB: Pros and Cons
Different applications have different needs. Sometimes, an application’s need might push you to a self-managed option. So, it’s worth considering its pros and cons.
- Total control: Full control over the database and where your data is located. You can use any environment that meets your needs.
- No region restrictions: All 25 AWS regions are available to you.
- Less expensive: Avoids the costs of a fully managed service
- Reduced migration cost: Lower costs for refactoring existing applications.
- No configuration limitations: All configuration options are available, so you can build the database that matches your needs.
- Avoid AWS lock-in: As with any managed service, once you start using DocumentDB, your database is integrated into that service and that provider. By using the self-managed option, you eliminate the risk of staying locked to a specific vendor.
- Operational overhead: You take responsibility for installing and maintaining it.
- Requires domain expertise: You’re going to have to know what you’re doing, and that requires an expert team in the domain.
Migrating MongoDB to AWS
You may already have your database cluster in-house or in another data center. To take advantage of AWS Cloud, you may consider migrating your MongoDB database to AWS. The following section will detail the approaches to MongoDB migration on AWS.
MongoDB Migration with AWS Database Migration Service (AWS DMS)
You can use AWS Database Migration Service (AWS DMS) to migrate data from on-premises, on an Amazon Relational Database Service (RDS), or Amazon Elastic Compute Cloud (EC2) to Amazon DocumentDB with virtually no downtime.
Command-line Utilities: Mongodump and Mongorestore
Mongodump and Mongostore allow you to dump and restore data from MongoDB databases in a binary format while migrating data to Amazon DocumentDB. This tends to yield a smaller data size than logical exports and incurs downtime for your cluster.
A Third Option?: MongoDB Deployment in AWS with Cloud Volumes ONTAP
There is a way to combine the benefits of managed and self-managed options to get the best of both worlds. The way to do that is with Cloud Volumes ONTAP.
Cloud Volumes ONTAP is an enterprise-class data management platform for AWS as well as Azure and Google Cloud.
Cloud Volumes ONTAP enables its users to scale their applications quickly without compromising performance. Using it as a data management layer on top of your EC2-based MongoDB, lets you avoid losing full control and risking getting locked to a vendor that comes with a managed service.
Cloud Volumes ONTAP gives you the ability to run MongoDB:
- Without configuration, instance type, or scalability limits
- Without getting locked in AWS
- Only paying for the resources that your database uses
- Across multiple clouds and hybrid storage environments
At the same time, you’re getting more features than either the managed services or the infrastructure-as-a-service (IaaS) model can provide:
- RPO=0, RTO < 60-second, cross-region high availability
- Data protection with NetApp Snapshot™ copies
- Seamless DR and data replication capabilities with SnapMirror®
- Instant, zero-capacity, writable data volume cloning with FlexClone®
- Cost-cutting storage efficiencies like deduplication and data tiering
MongoDB can be run as a service, or you can run it the way you want to. With Cloud Volumes ONTAP, you can get a solution to provide the best of both, and much more.