Amazon EC2

To deploy MongoDB on Amazon EC2, you can either:

MongoDB Atlas and EC2

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

Storage Considerations

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.

Manually Deploy MongoDB on EC2

The following steps can be used to deploy MongoDB on EC2 yourself. The instances will be configured with the following characteristics:

  • Amazon Linux
  • MongoDB installed via yum
  • Individual PIOPS EBS volumes for data (1000 IOPS), journal (250 IOPS), and log (100 IOPS)
  • Updated read-ahead values for each block device
  • Update ulimit settings

Before continuing be sure to have the following:

Create the instance using the key pair and security group previously created and also include the --ebs-optimized flag and specify individual PIOPS EBS volumes (/dev/xvdf for data, /dev/xvdg for journal, /dev/xvdh for log). Refer to the documentation for ec2-run-instances for more information on devices and parameters.:

ec2-run-instances ami-05355a6c -t m1.large -g [SECURITY-GROUP] -k [KEY-PAIR] -b "/dev/xvdf=:200:false:io1:1000" -b "/dev/xvdg=:25:false:io1:250" -b "/dev/xvdh=:10:false:io1:100" --ebs-optimized true

You can use the returned instance-id to ascertain the IP Address or DNS information for the instance:

ec2-describe-instances [INSTANCE-ID]

Now SSH into the instance:

ssh -i /path/to/keypair.pem

After login, update installed packages, add the MongoDB yum repo, and install MongoDB:

echo "[mongodb-org-3.4]
name=MongoDB Repository
gpgkey=" |
  sudo tee -a /etc/yum.repos.d/mongodb-org-3.4.repo
sudo yum -y update && sudo yum install -y mongodb-org-server \
    mongodb-org-shell mongodb-org-tools

Next, create/configure the mount points, mount each volume, set ownership (MongoDB runs under the mongod user/group), and set the /journal link:

sudo mkdir /data /log /journal

sudo mkfs.xfs /dev/xvdf
sudo mkfs.xfs /dev/xvdg
sudo mkfs.xfs /dev/xvdh

echo '/dev/xvdf /data xfs defaults,auto,noatime,noexec 0 0
/dev/xvdg /journal xfs defaults,auto,noatime,noexec 0 0
/dev/xvdh /log xfs defaults,auto,noatime,noexec 0 0' | sudo tee -a /etc/fstab

sudo mount /data
sudo mount /journal
sudo mount /log

sudo chown mongod:mongod /data /journal /log

sudo ln -s /journal /data/journal

Now configure the following MongoDB parameters by editing the configuration file /etc/mongod.conf so that it contains the following:

dbpath = /data
logpath = /log/mongod.log

If you don’t want MongoDB to start at boot, you can issue the following command:

sudo chkconfig mongod off

By default Amazon Linux uses ulimit settings that are not appropriate for MongoDB. To setup ulimit to match the documented ulimit settings, run the following command:

echo '* soft nofile 64000
* hard nofile 64000
* soft nproc 64000
* hard nproc 64000' | sudo tee /etc/security/limits.d/90-mongodb.conf

Additionally, default read ahead settings on EC2 may not be optimized for MongoDB. Refer to the Production Notes for the recommended configuration for your Linux distribution and selected MongoDB storage engine. For example, to set readahead to 0 for use with the WiredTiger storage engine,

sudo blockdev --setra 0 /dev/xvdf

To make this change persistent across system boot, issue the following command:

echo 'ACTION=="add|change", KERNEL=="xvdf", ATTR{bdi/read_ahead_kb}="0"' | sudo tee -a /etc/udev/rules.d/85-ebs.rules

Once again, repeat the above command for all required volumes (note: the device we created was named /dev/xvdf but the name used by the system is xvdf).

To start mongod, issue the following command:

sudo service mongod start

Then connect to the MongoDB instance using the mongo shell:


To have MongoDB startup automatically at boot issue the following command:

sudo chkconfig mongod on

For production deployments consider using Replica Sets or Sharding.

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.

Deployment Notes

Instance Types

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.

Running MongoDB

Before starting a mongod instance, decide where to put your data files. Run df -h 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 point.

Mounting the filesystem with the mount -o noatime option can improve disk performance. For example, the following is an example of an /etc/fstab stanza with this option:

/dev/mapper/my_vol /var/lib/mongodb xfs noatime,noexec 0 0

Create the mongodb data file directory in the desired location and then start the mongod server:

mkdir /mnt/db
./mongod --fork --logpath ~/mongod.log --dbpath /mnt/db/

Operating System

Refer to the MongoDB on Virtual Environments section of the Production Notes for configuration recommendations.


Port Management

By default, the mongod listens on port 27017. To change the default port, use the net.port setting or --port option.


Change the default TCP keepalive time to 300 seconds. See our troubleshooting page for details.

Enhanced Networking on Supported Instance Types

When available, enable AWS’s Enhanced Networking for your instance. Not all instance types support Enhanced Networking. Refer to the AWS documentation for more information.

Secure Instances

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 to 27017 (or whatever port you use for your MongoDB). This will ensure that only your app servers have permission to connect to your MongoDB instances.

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 “”, and add the CNAMEs for all your servers
server1          IN     CNAME
server2          IN     CNAME
  • restart bind and modify /etc/resolv.conf to use the local bind
search myorg.conf


  • verify that you can properly resolve server1, server2, … using a tool like dig.
  • when running mongod, db.serverStatus() 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 rs.initiate(), then rs.add('server2:27017').