The Five Elements of Your On-Premises MongoDB to AWS Migration Strategy

A MongoDB application migration requires coordination between multiple teams, stakeholders, and systems. You need a comprehensive plan to reduce the risk of project failure, allocate resources to support the migration, and remain on-schedule and on-budget.

When migrating from on-premises MongoDB to Amazon Web Services (AWS), you need to consider five key elements when putting together a successful strategy.

AWS Instance Type

The first decision to make is which AWS instance type works best for your MongoDB application. While Amazon EC2 has a variety of options, we recommend M4 or I3 for MongoDB. You also need to determine the amount of memory and storage for the instance.

M4
M4 instance types are well-balanced between compute, memory, and network resources. This general-purpose instance is a good starting point as it can support a wide range of use cases. You can choose between a 2.3 GHz Intel Xeon E5-2686 v4 processor or a 2.4 GHz Intel Xeon E5-2676 v3 processor on M4.

I3
I3 instance types are bare metal and optimized for high-transaction, low-latency databases, helping you achieve better performance with this type of MongoDB application. You get 15.2 TB of NVMe SSD instance storage, which delivers up to 25 Gbps of bandwidth and high IOPS while remaining affordable for many businesses.

You can directly access physical resources on these bare metal instances to gain greater control and optimization opportunities. These servers are powered by Intel Xeon E5-2686 v4 processors with 36 hyper-threaded cores.

High Availability Strategy

MongoDB uses a replica set to achieve high availability, protecting the database from natural disasters, power and network outages, and hardware failures. When you migrate your application to AWS, you need to select regions and availability zones that are best suited to maintaining high availability. AWS regions are self-explanatory — they are geographic regions for the data centers. Availability zones are specific locations within that region.

MongoDB developers recommend configuring your infrastructure to distribute your replica set across an odd number of data centers. This approach helps you eliminate a single point of failure by spreading replica members throughout many locations.

We recommend at least a five-member replica set for your production environments, with the following configuration:

• One primary: Your primary member in a MongoDB replica set is the only one that receives write operations.
• Four secondary: Your secondary members maintain copies of the primary member’s data set and are read-only.

 
The total for the replica set always needs to be an odd number. Arbiters are included in old version, but are now being deprecated by MongoDB, however, the total still needs to be odd.

Security Design on AWS

You can expand on MongoDB’s built-in security features through AWS solutions, making your application a challenging target for any malicious actors. The security features to consider in your AWS design include encryption, SSL, networking, firewalls, virtual private networks, and security groups.

MongoDB Migration Plan

Your MongoDB migration plan should cover each step of the process. What teams will assist in the migration, when do systems need to cut over to the cloud-based deployment, and how much will it disrupt your daily operations?

You have a dozen of these details to consider when you create a migration plan that best suits your company’s requirements. What happens if essential technical personnel go on vacation or become ill during the migration process? How do you effectively get buy-in from stakeholders and ensure that you have the budget to complete the migration? What do you hope to gain from moving this application to the cloud?

The more questions you address before your MongoDB migration, the better prepared you will be when the process is underway.

Backup and Recovery Strategy

Your on-premises backup and recovery strategy may not translate to a cloud-based environment, so it’s time to revisit your existing plan. Make sure that your preferred solutions work with AWS and then work properly following the migration.