Networking in AWS – VPC, subnets and routing

The key part of your AWS infrastructure is your VPC (Virtual Private Cloud). It is important to get it right, as it can't be changed later, although you can have multiple VPCs in your AWS account. Think of the VPC as the container in which you build your whole AWS environment, so that's where I'll start this series.

Talking about the account, we already used AWS for customer facing web sites. When I started this project, there was a distinction between “front end” (customer facing web site) developers and “back end” developers. This has since changed, but it seemed reasonable to keep the distinction, so I created a second AWS account. If you do, set up an email alias to use as the root account, and consolidate the billing. I'm sure finance would rather have to deal with just the one bill...

If possible, when you create your VPC, use a CIDR in a range that does not overlap with any of your internal subnets. For the company (and group) I'm currently contracting for I used 10.128.0.0/16 – this means I could potentially have VPN set up to connect to 10.0.0.0/9 with one VPN. Use http://www.subnet-calculator.com/ to help you work it out.

Besides the normal public and private subnets, I decided also to have a defined “AD” subnet and and a “routing” subnet. Call me too careful, but if I'm going to have domain controllers in an environment, I want to control access to them very carefully. The two extra “subnets” mean I can set up a security group (what a firewall is called in AWS) to restrict access to the read only domain controllers (RODC) only to the routing subnet, not anything in the “public” subnet. Same for internal firewalls as well – I can restrict access from the private subnet, but obviously need the domain controllers to connect.

For each purpose, you create a subnet in each availability zone – in Ireland that's three availability zones, so you have 12 subnets you create. To make the firewalls etc. easier, create the subnets in easy CIDR blocks – e.g. if you have the public in 10.128.1.0/24, 10.128.2.0/24 and 10.128.3.0/24, put the private in 10.128.16.0/24 etc., so you can treat 10.128.0.0/20 as all being public.

Subnet summary:

Routing subnet – use for any routing services, such as VPN and NAT

Public subnet – for any services accessible from the internet, e.g. load balancers. No access to internal network through VPN.

Private subnet – No direct internet access, through NAT only. Access to internal networks through VPN.

AD subnet – Same as the private subnet, but can be treated different internally.

As an aside – I did not use Cloudformation to create my VPC and subnets because I'm not planning on recreating them and it's a pretty small job to do it manually, but if you're creating lots you will want to.

In the routing subnet, you will need to create a NAT instance. I will use Elastic Beanstalk to put applications in the private subnet, which fails if they don't have internet access (AWS health checks fail if the instance doesn't contact it). Hopefully in my next post I'll share something on this, including my Cloudformation template.

I also used a VPN instance (OpenSWAN on linux) to connect my internal network with AWS. More on that later – in most cases you probably want to use a VPG and Amazon's VPN. Again, a Cloudformation template and a simple script will bring it all up with no manual intervention (and replace the instance if anything goes wrong).

You'll also want to create two routing tables. The Main table has a local route to 10.128.0.0/16 and a default route to the internet gateway and probably doesn't need any modification.

To keep the private and AD subnets private, you create a routing table with a default route through the NAT instance and a route to your internal infrastructure through your VPN. Then associate this with the private and AD subnets.

Hopefully more coming soon...