The Virtual Private Cloud (VPC) is one of the cornerstones of AWS & will be covered in a lot of detail below. Before we start looking specifically at VPC’s, it’s first important to understand at a high level, how AWS infrastructure hangs together.
AWS has many locations across the globe. A region is defined as a grouping of AWS resources located in a geographic area. Within each region we have three availability zones which are geographically isolated data centres in different areas within the region.
Think of it like this: the region is the United Kingdom and the availability zones are London, Manchester and Cornwall. The region acts as a high level term to give you an idea of where your application will be hosted so you can place it closest to your users, minimising latency.
We have different availability zones within a region in order to create highly available and fault tolerant systems. Let’s say there was a flood in availability zone one; your application would still be available (assuming you’d utilized a multiple-availability-zone design) & online as it’s replicated to availability zone two and three.
A VPC is a logically isolated area of the AWS infrastructure in which you can define your own network configuration & launch your AWS resources into an area, over which you have complete control – it’s intended to resemble your private on-premise data centre.
With the VPC, you can control who has access to the resources held within it and define your own virtual network (IP ranges, subnets, route tables & network gateways).
A VPC can be launched into a specific region. You can then place subnets in different availability zones within the VPC. This enables you to create fault tolerant and highly available applications and services by straddling multiple availability zones and/or regions.
AWS provides a DNS server for your VPC so that each instance has it’s own hostname. However, you can configure your own DNS servers by changing the DHCP option set configuration within the VPC.
Note: You can have multiple subnets in an availability zone but one subnet cannot span multiple availability zones.
VPC Components / Concepts
IGW (Internet Gateways)
Internet Gateways (IGW) are an integral part of the VPC. They provide your network with a route to the open internet. They are horizontally scaled, redundant and highly available – and don’t need to be managed. They’ll automatically scale to meet traffic requirements and will automatically be replaced if they fail.
The IGW has two main purposes. The first is to allow communication between the AWS resources within your VPC and the internet and the second is to perform NAT translation for instances that have a public IP address.
It’s important to note that only one IGW can be attached to a VPC at any given time and that you cannot detach an IGW from a VPC while there are active AWS resources within the VPC (e.g. EC2 Instances).
Route tables provide a set of rules (or routes) which direct traffic to the intended destination. When a route table is connected to an Internet Gateway, it will have a rule defined in the rules tab which will explicitly refer to the IGW. If an IGW is detached from a VPC the route table will show a status of ‘black hole’ .
The route table enables you to configure routes between subnets (both public and private) within a VPC (in the same region but potentially different availability zones). Note: you cannot delete a route table if it has any dependencies. This can include any Internet Gateways or subnets associated to the route table.
The below is an example of a route table. You’ll see that we have two records in place, each with two columns – destination and Target.
With the top line of the route table, you’ll notice that the target is local (we call this the ‘local route’). That means this is to be routed internally – between subnets within the VPC, this will not require access to the open internet. As such, the destination of this record is simply the CIDR block range of the VPC itself.
You cannot modify the ‘local route’
The second row will show the target as being the IGW (Internet Gateway), which indicates that this should be able to connect to the open internet – as would be required if you were hosting a website. The destination of 0.0.0.0/0 means that it can go to any destination on the open web.
Best practice is to leave the default route table as it is. If any modifications are required, it’s better to create a new route table. Note: you can have multiple route tables per VPC.
In many cases, you may choose to have a private and a public route table for your VPC. Both would have the same local route, meaning communication between subnets would be possible. However, the private subnet would be attached to a route table that was NOT attached to an internet gateway.
A subnet is a subsection of a network. In AWS, we can have multiple subnets within a single VPC and those subnets can span multiple availability zones. However, all subnets within a VPC must be in the same region.
When you first setup your AWS account, you’ll notice that you have a default VPC and a number of subnets (one for each availability zone within the region). Each of those subnets will be attached to an internet gateway and will be public subnets.
Each instance launched into the default VPC will have both a private and public subnet by default – this setting can be altered to suit your requirements.
A public subnet is defined as one that has a route to the internet. A private subnet is one that does not have a route to the internet. Both public and private subnets can communicate with other subnets within a VPC using the local route.
Private subnets can benefit from enhanced security as they’re not available to the open web. However, this can also mean that they’re unable to download and install software updates. This can be solved via the use of a NAT instance.
In order to make a subnet private, you’ll need to create a new route table that is NOT attached to an internet gateway (IGW) and associate a subnet with that table. Note that all subnets must be associated to a route table.
Subnet associations with a route table can be either explicit or non-explicit. No subnet is explicitly associated with the default route table – they’re non-explicitly associated until they’re explicitly associated with another (non-default) route table.
Availability zones are locations within a region. These are distinct data centres which sit within a specific region which can be tens or hundreds of miles apart. Distances are engineered in such a way that the failure of one availability zone should not impact another.
For example, let’s user our example of a region of the United Kingdom. Our availability zones are London, Manchester and Cornwall. As you can see from the below, they’re hundreds of miles apart from one another. So, a flood in London, really shouldn’t affect the other two availability zones. Each availability zone is designed to be isolated from the problems of the other zones in the region.
It’s best practice to build applications spanning multiple availability zones in order to provide high availability and fault tolerance in your application architecture.
|Side Note: |
High availability is defined as an application / service with minimal downtime and that is always available to its users.
Fault tolerant systems are those which either fix themselves or failover to a backup system, preventing / minimizing downtime for the user.
Network Access Control Lists (NACL)
Network Access Control Lists (NACL) are an optional layer of security which essentially acts as a firewall for controlling traffic in or out of one or more subnets. It does this through the enforcement of traffic rules based on protocol. For example, you may wish to block all inbound HTTP traffic to your subnet.
To do this, we assign a rule number. The lower the number we assign, the higher priority that rule is given and once one rule is evaluated and executed, all following rules are ignored. So, let’s say we have the below rules:
|Rule Number||Protocol||Source||Allow / Deny|
In this case, our HTTP traffic will come into the NACL. It’ll start evaluating the rules that it has and will first come across rule 90 and will allow the HTTP traffic to enter the subnet. Even though we have a deny rule below, it always executes the rule with the lowest rule number.
Remember, Network Access Control Lists are stateless. This means that traffic must be allowed in both inbound and outbound rules if a reply is to be required.
|Side Note: |
The default NACL in the default VPC will allow all traffic (both inbound & outbound) by default while any new NACL’s will deny all traffic by default. N.B. when the source is set to 0.0.0.0/0, it means rule will apply to all traffic sources.
Through the NACL interface in the AWS management console, we can associate subnets to the NACL. Remember, only a subnet can be associated with one NACL at a time.
While the NACL enforces security at a subnet level, EC2 instances may also apply additional security at the security group level.
Security groups work on the instance level. They’re relatively similar to Network Access Control Lists in the sense that you can configure rules to allow certain types of traffic.
There are two noticeable differences between a NACL and a security group:
- Security groups only support allow rules
- Security groups are stateful
- All rules are evaluated before a decision is made
What does it mean to be stateful? Well, let’s say you allow inbound SSH traffic to your instance and that traffic requires a response from your server but you do not have SSH allowed in the outbound rules of your security group – it will still allow you to send the response. This is not true with NACL’s.
There are a number of limits placed on resources in AWS. These can be lifted by submitting a support request to AWS. However, by default, those limits are:
|#VPC’s Per Region||5|
|#Internet Gateways Per Region||5|
|#Customer Gateways Per Region||50|
|#VPN Connections Per Region||50|
|#Route Tables Per Region||200|
|#Entries Per Route Table||50|
|#Elastic IP Addresses||5|
|#Security Groups Per VPC||500|
|#Rules Per Security Group||50|
|#Security Groups Per Network Interface||5|