AWS Networking Simplified

Intro

For me the AWS networking was not really clear at first, I kinda understood it but not really. In this post I will try to simplify AWS networking for an easier, clearer understanding.

What is a VPC

"Amazon Virtual Private Cloud (Amazon VPC) is a service that lets you launch AWS resources in a logically isolated virtual network that you define." From this definition we understand that VPC's are about networking isolation.

We could say that the cloud is a huge grid and we don't want our communication to be open or be mixing with the whole grid except at points where we say it makes sense. Rather we want to isolate our communication so it is undisturbed and private just like we want to be undisturbed from other companies listening in on our meetings.

CIDR Block

Since we are talking about networking we cannot avoid the topic of IP addresses. A CIDR block is where it starts. For every VPC we have to define a CIDR block. This CIDR block is basically a range of IP addresses out of which our instances in the VPC will get their IP's.

The default CIDR block is 172.31.0.0/16. This translates to 65,534 thousand possible instance IP addresses. This is then further divided into subnets based on availability zone.

Availability Zones

An Availability Zone (AZ) is one or more discrete / separate data centers with redundant power, networking, and connectivity in an AWS Region. The benefits of multi AZ's is that they give us the ability to operate our applications with higher availability, fault-tolerance and scalability.

VPC Subnets

VPC's are split up into subnets by splitting up our CIDR block. If we have 3 AZ's in our region, we could split up our CIDR Block as follows:

172.31.1.0/24
172.31.2.0/24
172.31.3.0/24

This would give us 254 IP addresses per subnet. If need more IP's per subnet we could use a subnet mask of /18 which would give us up to 4 subnets and 16384 hosts per subnet.

Dual Stack

VPC's on AWS operate in a so-called Dual-Stack mode. That means that subnets and nodes e.g. EC2 instances will be assigned, along the IPv4 addresses, IPv6 addresses as well.

Route Tables

Within every VPC there is an implicit router. This router routes traffic within a VPC. How does it route traffic? It routes traffic using a certain set of rules called a route table.

Routes in a route table are rules the router uses when routing network traffic. A route table rule has a destination and a target.

Let's say one of our EC2 instances contacts the IP address 142.251.37.14 (ping google.com). This request (packet) reaches the router with a destination IP of 142.251.37.14. This IP is an IP within the public range. Our default VPC is a private network (172.31.0.0/16) this means the destination is not in our VPC. The router now uses the route table and looks for a destination in routes which matches that IP. Then it uses the target associated with that destination to forward the packet to. In the case of 142.251.37.14, with the default VPC setup, we would match the route having the a destination of 0.0.0.0/0 which represents all IP's. This route has an "Internet Gateway" configured as the target and that's where our packet will be sent to. Eventually the packet should reach google servers.

Another route we get out of the box with our default VPC is the one having a destination of 172.31.0.0/16 and a target of local. So any IP packet with a destination IP matching 172.31.0.0/16 will be considered as local and will be sent to an instance within our VPC.

The default subnets also have the flag "Auto-assign public IPv4 address" turned on. This means that instances launched in those subnets will have internet access (default internet gateway) and the internet will have access to them via their public IP or in other words we have outbound as well as inbound internet access.

NAT Gateway

If we want instances to talk to the internet but block the internet from talking to your instances then the keyword is "NAT Gateway". NAT stands for network address translation. It will let our private instances connect to the internet while there is no public IP for an external actor to initiate a connection with our instance, basically blocking requests from outside and translating responses to the inside. A NAT gateway will forward outside responses only if the request came from inside.

For this type of setup we need a private subnet and a route in our route table that has 0.0.0.0/0 as the destination and the NAT gateway ID as the target.

Security Groups

A security group is a (virtual) firewall. With a firewall (security group) you can control traffic coming in and out of your instances via firewall rules.

By default, all traffic is denied by a firewall except that which we explicitly allow by a firewall rule. Firewall rules are allow only.

A firewall will recognize and allow responses from outside to our instances based on the requests our instances sent out. Because it remembers requests a firewall is referred to as stateful. This saves us from having to set up counterpart rules i.e. inbound for outbound rules and vice versa.

A simple use case would be that you have instances in a public subnet behind a firewall sg-public that allows port 80 inbound traffic from all IP addresses (0.0.0.0/0). Those could be your web servers like nginx. Behind the public subnet you also have a private subnet with your backend instances. If you don't want your backend instances to be accessable from outside and only from your webservers, you could put them behind another firewall sg-backend. For the firewall sg-backend you would then allow inbound traffic with a security group source
sg-webserver. This means that our backend instances can only receive inbound traffic from the security group sg-public.

Network ACL's

Network Access Control Lists are similar to security groups in that they can allow access but they can also deny access. In contrast to SG's, NACL's are stateless meaning inbound rules have no effect on outbound rules meaning if you e.g. allow some outbound traffic the response will not "magically" come back if there is no inbound rule.

NACL's give us finer control in cases where we need finer control which are rare cases. By default there are no NACL's in VPC's

Conclusion

In this post I tried to simplify some of the core VPC concepts, terms and features (there are, course, many more). When starting off with AWS, VPC's are essential. Before we can effectively create or manage VPC's we need to get familiar with new terms, concepts and architectures. Those can be a bit overwhelming at first glance but hidden behind all the jargon and extensive documentation are simple concepts. Understanding the simple ideas behind it is great and the next step should be to get your hands dirty and experiment with VPC's and its many features.