EC2 instances can be configured either with 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 for use unless you’re comfortable with 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 configurations can vary from one deployment to the next but
for the best performance we recommend one volume for each of the
following: data directory, journal, and log. Each of those has
different write behaviours and we use one volume for each to reduce IO
contention. Different RAID levels such as RAID0, RAID1, or RAID10 can
also be used to provide volume level redundancy or capacity. Different
storage configurations will have different cost implications
especially when combined with PIOPS EBS volumes.

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.:

Additionally, default read ahead settings on EC2 are not optimized for
MongoDB. As noted in the read-ahead settings from Production
Notes, the settings should be
adjusted to read approximately 32 blocks (or 16 KB) of data. The
following command will set the readahead appropriately (repeat for
necessary volumes):

$ sudo blockdev --setra 32 /dev/xvdf

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

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.

Before running the database one should decide where to put
datafiles. Run df-h to see volumes.
On some images /mnt
will be the many locally attached storage volume. Alternatively you may
want to use Elastic Block Store which will
have a different mount point.

If you mount the file-system, ensure that you mount with the
noatime and
nodiratime attributes, for example:

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

Create the mongodb datafile directory in the desired location and then
run the database:

Occasionally, due to the shared and virtualized nature of EC2, an
instance can experience intermittent I/O problems and low responsiveness
compared to other similar instances. Terminating the instance and
bringing up a new one can in some cases result in better performance.

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.

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