AWS: A SysAdmin's Guide to Understanding AWS Networks

When you come from a SysAdmin background and end up involved in Cloud platforms such as AWS, it's entirely possible that you'll come across more networking than you've ever needed to be involved in within the physical world.  When you deal with physical boxes, the Server Team deal with the Servers and the Network Team deal with the switches and routers.  In this world, the demarcation is pretty clear.  In AWS, you'll probably need to design some secure networks at some point and I hope that this guide will help you out.

The caveat is that I'm not a Solutions Architect nor a Network Engineer, but I hope that what I worked out from first principles,  may speed up the understanding for others.

Networking Basics
Lets start by contemplating the basics when designing AWS networks.  Obviously, AWS has plenty of documentaion about all of these elements (and I'll link back to them as I'm going through), but I hope that my descriptions will be a little easier to understand.

The easiest way to describe a VPC is that it is the top level design of the network.  Just like if you had a physical network, you would start at the top level and then work out what goes inside it (e.g. the subnets, switches, routers etc.) It's exactly the same with a VPC.  It is your little bit of AWS and once you define and create it, everything else you put 'inside' is entirely up to you.

Just like in a physical network, Subnets are used to sub-divide the whole network into smaller 'areas' for different functions of your EC2 instances.  As an example, you might want keep your crown jewels, like your Database servers, away from the Webservers.  The Webservers need to be always available to people on the Internet (including those of nefarious aims!), so you might put these in a separate subnets to act like a 'DMZ' (I say like, because there is some consternation whether a true DMZ is available in the Cloud) and the Databases in another subnet away from the Internet Gateway.  You may also want to set up servers with same roles but in different Availability Zones, this means that you could create a subnet for each Availability Zone and place a server in each.

If you come from a Server background, the only time you will have needed to be involved in routing is probably to add some static routes in the OS, if you have multiple NICs going into different networks.   In the Cloud, you need to understand routing the way the Network guys used to.  At every stage, you'll need to consider how the data is going to get to the next point and the routing tables dictate how it gets there.  Both the main VPC and the Subnets have Routing Tables 'attached' to them.

If you need to route from the EC2 instances within your VPC out to the Internet, or allow connections from the Internet into your VPC contained EC2 instances, you'll probably need one of these.  As well as a gateway to the Internet, it also perform network address translation (NAT) for any EC2 instances that have been assigned a public IP address.  Internet Gateways are always attached to the VPC and any subnet that contains Internet addressable servers e.g. Webservers should have a route that points to the Internet Gateway.

Whilst Webservers go into a subnet that have a route to an Internet Gateway, you will still probably want your Database servers to have outbound Internet access to update software etc. without allowing inbound access from the Internet. This is a special type of pre-configured EC2 instance (AMI name: amzn-ami-vpc-nat) which will sit in the same subnet as any Webserver and use the Internet Gateway to talk to the Internet.  The subnet containing the Database server will then have a route which points to the NAT instance in the other subnet.

Security Basics
Security Groups and ACLs are the main elements to secure your infrastructure and we will cover these in a few weeks.