WirelessPhreak.com

I like to travel, f*ck with technology, and partake in the occasional tropical drink.
I am also a co-host on The NBD Show podcast.
Follow Me

Recently we have been moving services to the Cloud (AKA other people's computers.) Amazon Web Services (AWS) offers two different types of cloud service: Gov cloud and Commercial cloud. Gov cloud is marketed to federal, state, and local government entities and offers hosting within the Untied States. The biggest issue I have found with Gov cloud is that only a fraction of the functionality offered in Commercial AWS is offered in Gov cloud. Gov cloud is pretty much a stripped down version of the Commercial AWS.

The cloud in my opinion serves a purpose, first and foremost to host stand-alone public facing applications. This is not a place to host heavy web applications that depend on data or content you are not wiling to host in the cloud. But there is still a need to connect to your corporate network for monitoring, auditing, or publishing content.

That being said, we have recently built out AWS infrastructure and wanted to share the design we came up with. Our first hurdle is the amount Amazon charges for VPN connectivity to a VPC. And if you want connectivity to a VPC it must have its own VPN connection. This was a limitation that drove us crazy. So we asked ourselves, if we are hosting truly stand-alone websites, why do we need direct connectivity to those servers? So with that question in mind we came up with the idea of creating a management VPC that is connected to or corporate network. Then as we create new applications we could add application specific VPCs that where connected to that management VPC. This not only provides a single VPN connection to our corporate network but also isolates each application in its own VPC giving us segmentation at a network and billing level.

Here are the steps we went though:
  1. Assigned a /16 network to the AWS infrastructure and set a static route to our AWS IPSec device. (This is not mandatory since you will only be routing the management VPC network, but I did it to tag those networks for AWS)
  2. Build out the management VPC with a /24. (This will be where we build our management servers such as Bastion hosts, patch server, LDAP, etc.) This VPC does not need to have internet access.
  3. Per application build out of new VPC networks using /22 this gives you 4 /24 networks to use between a web, app, and DB tier across two availability zones. (Remember Elastic Load Balancers are going to burn up a number of IP addresses.)
Pros and Cons of this design:

Pros
  • You only need one VPN connection
  • Complete segmentation between applications
  • Easy to track application billing
  • Super scalable 
  • Added security since the application VPC servers can not route directly to your corporate network
Cons
  • You can not route through the management VPC to connect directly to a server in the application VPC, or the reverse. You will need to use an SSH proxy server in the management VPC
  • Web applications that are dependent on corporate resources will not work
  • You will need to build all your management tools in the management VPC to connect and monitor application VPC servers