There are some prerequisites one should consider if you are going to prepare an environment for Cloud Manager deployments with AWS. I like to think of a VPC much like a datacenter, with the creation of a new network requires some understanding of general subnetting and routing.

AWS provides two network environment types for you to work with, EC2 Classic and VPC. The EC2 Classic methodology is a legacy part of the AWS cloud. (A link to a full explanation can be found here http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html#differences-ec2-classic-vpc)

EC2 Classic

Instances that use the EC2 classic do not have the full internet access unless assigned a public IP, but for the most part all the work is done for you when it comes to routing and subnet. You choose an availability zone (AZ) you wish to start up in and really get going once you assign an elastic IP. Your private network subnets are NAT-ted by default by AWS and there’s not much else to be done. You can just launch and get these running, there’s very little additional networking knowledge required aside from understating which ingress ports should be allowed into the security groups. Additionally, your number of security groups permitted per instance is limited, further limiting your control on what can and cannot access your systems.

VPC

The VPC (Virtual Private Cloud) is a networking concept that allows you to create isolated resources within the AWS ecosystem and properly network them to interconnect to one another and the internet in how you see fit. This acts like your own private datacenter where you control all network configuration including routes and subnets.

All AWS regions after 2013-03-18 have a default VPC created for you to work with. The default VPC comes with a default network configured for you along with three subnets. This preconfigured VPC allows you an entry level into the VPC environment without having to have a large amount of experience. The three subnets pre-configured allow for you to have an environment for you to deploy MongoDB in that’s already multi-AZ. You can get more details and answers to frequently asked questions here: http://aws.amazon.com/vpc/faqs/#Default_VPCs.

Customizing the VPC

As mentioned previously, the VPC does come with three default subnets along with an attached internet gateway which provides you with internet access. While for many this configuration is completely valid, for others they may require some additional custom configuration.

Want more than three subnets? Totally doable within the VPC environment! Consider you want to isolate your MongoDB installation to a secondary, private subnet which will have no inbound internet access. This may require you to configure the VPC a bit different in order to accomplish your goals. These skills may not be on the tip of every technologist’s fingers at this time due to whatever their project may require of them, that being said we can leverage some of the tools Amazon has provided in order to get past this step.

CloudFormation is a tool that AWS provides to create “stacks” of resources based on JSON templates:

http://aws.amazon.com/cloudformation/aws-cloudformation-templates/

 "Parameters" : {

  "InstanceType" : {
   "Description" : "WebServer EC2 instance type",
   "Type" : "String",
   "Default" : "m1.small",
   "AllowedValues" : [ "t1.micro","m1.small","m1.medium","m1.large","m1.xlarge","m2.xlarge","m2.2xlarge","m2.4xlarge","m3.xlarge","m3.2xlarge","c1.medium","c1.xlarge","cc1.4xlarge","cc2.8xlarge","cg1.4xlarge"],
   "ConstraintDescription" : "must be a valid EC2 instance type."
  },

  "InstanceCount" : {
   "Description" : "Number of EC2 instances to launch",
   "Type" : "Number",
   "Default" : "1"
  }
 },

Thanks to CloudFormation we can make use of a pre-created template to allow multi-subnet (public and private) to handle these more difficult tasks on our behalf. Today we’ll be using this subnet:

https://s3.amazonaws.com/cloudformation-templates-us-east-1/vpc_multiple_subnets.template

First I’ll create a new stack while in the CloudFormation section of my console for the specific region:

Then I’ll use the above template we’ve been provided by Amazon:

Follow the directions in the template configuration over the next few pages such as providing a logical stack name, the number of instances we need to launch (let’s just start with one) and the size of the instance.

Once we hit Create we’ll wait for our resources in our stack to automatically be created:

Once our stack is completed you’ll be able to see a VPC and public and private subnets have been created:

You can now follow the directions AWS provides for NAT instance creation: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html. Once you’ve configured your NAT, you should be able to route out of your future private EC2 instances you create. Then you can finally install the automation and monitoring agents on your EC2 instances in these private subnets. This should permit your Cloud Manager install to then configure your instances, monitor them and back them up.

At this time, our Cloud Manager tool does not provide direct to private subnet instance provisioning. You may use “Cloud Server Provisioning” for your publicly accessible subnet EC2 servers that have routable public IPs. You then can configure your security groups to support Cloud Manager as listed in this document: https://docs.cloud.mongodb.com/tutorial/configure-aws-integration/#security-group.

Time and security are precious, make sure you are making the most of both within AWS. By creating further custom resources and extending beyond the typical AWS configuration, you can best secure and ready your Cloud Manager MongoDB deployments.