On this page
To deploy MongoDB on Amazon EC2, you can either:
- Set up a new cluster on MongoDB Atlas or live migrate an existing MongoDB deployment using the Atlas Live Migration Service.
- Set up a new instance manually install MongoDB.
Deploy MongoDB on EC2 with MongoDB Atlas¶
MongoDB Atlas is a hosted database as a service from the team that engineers the database. Atlas deploys MongoDB on AWS EC2 instances. The MongoDB Atlas GUI allows you:
- Set up and manage your clusters
- Scale up or out with automated sharding
- Monitor your MongoDB deployments running in MongoDB Atlas
- Configure security controls
- Manage automated backups and failure recovery
Manually Deploy MongoDB on EC2¶
To install MongoDB on Amazon Linux, refer to the installation instructions in the MongoDB manual.
EC2 instances can be configured with either ephemeral storage or persistent storage using the Elastic Block Store (EBS). Ephemeral storage is lost when instances are terminated, so it is generally not recommended unless you understand the data loss implications.
For almost all deployments EBS will be the better choice. For production systems we recommend using
- EBS-optimized EC2 instances
- Provisioned IOPS (PIOPS) EBS volumes
Storage configuration needs vary among deployments, but for best performance we recommend separate volumes for data files, the journal, and the log. Each has different write behavior, and placing them on separate volumes reduces I/O contention.
Using different storage devices will affect your ability to create snapshot-style backups of your data, since the files will be on different devices and volumes.
For optimal performance in terms of the storage layer, use disks backed by RAID-10. RAID-5 and RAID-6 do not typically provide sufficient performance to support a MongoDB deployment.
Avoid RAID-0 with MongoDB deployments. While RAID-0 provides good write performance, it also provides limited availability and can lead to reduced performance on read operations, particularly when using Amazon’s EBS volumes.
Backup, Restore, Verify¶
Depending upon the configuration of your EC2 instances, there are a number of ways to conduct regular backups of your data. For specific instructions on backing up, restoring and verifying refer to EC2 Backup and Restore.
MongoDB works on most 64-bit EC2 types including Linux and Windows. Refer to the Supported Platforms documentation to ensure your selected platform is compatible with your version of MongoDB.
Before starting a
instance, decide where to put your
data files. Run
to see a list of available
volumes. On some images,
/mnt will be the locally-attached
storage volume. Alternatively, you may want to use Elastic Block Store which will have a different mount
Mounting the filesystem with the
mount -o noatime option can
improve disk performance. For example, the following is an example
/etc/fstab stanza with this option:
/dev/mapper/my_vol /var/lib/mongodb xfs noatime,noexec 0 0
mkdir /mnt/db ./mongod --fork --logpath ~/mongod.log --dbpath /mnt/db/
Refer to the MongoDB on Virtual Environments section of the Production Notes for configuration recommendations.
By default, the
listens on port
27017. To change
the default port, use the
Change the default TCP keepalive time to 300 seconds. See our troubleshooting page for details.
Enhanced Networking on Supported Instance Types¶
Restrict access to your instances by using the Security Groups feature within AWS. A Security Group is a set of firewall rules for incoming packets that can apply to TCP, UDP or ICMP.
A common approach is to create a MongoDB security group that contains the nodes of your cluster (replica set members or sharded cluster members), followed by the creation of a separate security group for your app servers or clients.
Create a rule in your MongoDB security group with the "source" field set
to the Security Group name containing your app servers and the port set
27017 (or whatever port you use for your MongoDB). This will ensure
that only your app servers have permission to connect to your MongoDB
Remember that Security Groups only control ingress traffic.
Communication Across Regions¶
Every EC2 instance will have a private IP address that can be used to communicate within the EC2 network. It is also possible to assign a public "elastic" IP to communicate with the servers from another network. If using different EC2 regions, servers can only communicate via public IPs.
To set up a cluster of servers that spans multiple regions, it is recommended to name the server hostname to the "public dns name" provided by EC2. This will ensure that servers from a different network use the public IP, while the local servers use the private IP, thereby saving costs. This is required since EC2 security groups are local to a region.
To control communications between instances in different regions (for example, if you have two members of a replica set in one region and a third member in another), it is possible to use a built-in firewall (such as IPtables on Linux) to restrict allowed traffic to certain (elastic) IP addresses or ports.
For example one solution is following, on each server:
- set the hostname of the server
sudo hostname server1
- install "bind", it will serve as local resolver
- add a zone for your domain, say "myorg.com", and add the CNAMEs for all your servers
server1 IN CNAME ec2-50-19-237-42.compute-1.amazonaws.com. server2 IN CNAME ec2-50-18-157-87.us-west-1.compute.amazonaws.com.
- restart bind and modify /etc/resolv.conf to use the local bind
search myorg.conf nameserver 127.0.0.1
- verify that you can properly resolve server1, server2, ... using a tool like dig.
- when running mongod,
should show the correct hostname, e.g. "server1:27017".
- you can then set up replica sets or shards using the simple hostname. For example connect to server1 and run ==Not implemented:role,samp ==, then ==Not implemented:role,samp ==.