Fundamentals of networking in AWS

People use AWS as a virtual datacenter, so they deploy various services there like EC2 instances, RDS instances, etc.

Now, these instances/machines need to live somewhere in the datacenter and typically need to connect to the Internet. This is where VPC comes into the picture. I will use the term instance interchangeably with machine throughout this post. By instance, I mean the deployment of a service.

AWS has different regions, where it has its data centers. In those regions, we have availability zones. So if North Virginia is a region with id us-east-1, we have availability zones (AZs) us-east-1a, us-east-1b, us-east-1c, etc. They provide multiple AZs for resilience, so if one AZ is having some issues, deployments in other AZs won’t be affected. So you deploy your instances in a particular AZ, which in turn belongs to a particular region.

As you can see in the image above, VPC is an isolated network in a region, and it spans all the AZs in that region.
When you create an AWS account, it gives you a default VPC. I will explain what all things a default VPC offers, then I will show you how you can create one yourself.

A default VPC gives you four things -

1. IP address ranges/CIDR block
2. Subnets in availability zones
3. Routers to route out to the internet
4. Security groups and network access control lists (NACLs) for security

So, I will be talking about each of these 4 topics -

1. IP addressing
2. Creating Subnets
3. Routing
4. Security

In some places, I will also be explaining some standard networking terms like CIDR blocks, etc. If you are familiar with them, feel free to skip them.

IP addressing

In the default VPC, AWS gives you some range of IP addresses so that anything that will be deployed in that VPC will get an IP address from that IP address range. We denote IP address ranges with a CIDR (Classless Inter-Domain Routing) block. For example, AWS gives you 172.31.0.0/16 range of addresses for the default VPC.

Let's understand this CIDR block - Open any IP calculator like http://jodies.de/ipcalc and calculate the IP ranges that belong to this CIDR block.

As you can see in the image, where 16 is the netmask, saying the first 16 bits in the addresses are constant (here equal to 172.31), so that gives us the option to change rest 16 bits. By changing the last 16 bits i.e., previous two blocks of 8 bits (172.31.x.x), we can generate 65536 (256*256) IP addresses. That's how you represent the IP address range with CIDR blocks.

So, In the address range 172.31.0.0/16 (172.31 describes the network because of the 16 netmask, and 0.0 part will describe the host i.e., the actual system on the network)

Also, 172.31.0.0/16 falls within RFC 1918 ranges. RFC 1918 are reserved IP address ranges for private networks, so they don’t exist publicly on the Internet. So if you create something in your VPC, its IP address is not going to conflict with anything on the Internet because its private. If you want to talk to something on the Internet, you can’t have an IP address conflict. Even when you have two services talking to each other on-premise, both of those services’ VPCs should have different CIDR ranges so that IP addresses of instances inside them don’t overlap, because overlapping addresses can’t talk to each other easily.

So, when you create a VPC, you specify a CIDR block (saying all the machines that will be deployed in this VPC will receive an IP address from this range).

Creating Subnets

Subnets are sub-networks inside a VPC. As we know, VPC is specific to a region, and subnets are specific to availability zones.

For example, if a VPC belongs to a region us-east-1, this region will have AZs us-east-1a, us-east-1b, us-east-1c, etc.

Now you can assign a subnet to each of these AZs, so that machines in these AZs can talk to each other across AZs. Subnets receive IP address ranges that are subdivisions of the IP address/CIDR range VPC has been assigned. For example-
VPC - 172.31.0.0/16
Subnets - 172.31.0.0/24, 172.31.1.0/24, 172.31.2.0/24

So here again looking at the network mask in each subnet (24) first three numbers denote the network (172.31.x), and the last number denotes the machine, so here we can have about 251 (2⁸ = 256, but 5 of them are reserved by AWS for its internal networking) machines in each subnet.

Machines are launched in a specific Subnet. So, machines receive IP addresses from the address range of Subnets and Subnets receive address range from the address range of the VPC. Needless to say, each subnet belongs to a VPC.

We are talking about IPV4 addresses here, and You can also configure the machines to receive IPV6 addresses.

Routing in a VPC

To talk between the addresses, we need to be able to route, and the routing table tells the system how to move the packets around, where to put the next packet.

Basically, a routing table contains routes. A route is a destination - target mapping.

Destination- Destination CIDR where you want traffic from your subnet to go. For example, an external corporate network with a 172.16.0.0/12 CIDR.
Target- Target through which to send the destination traffic; for example, an internet gateway.

AWS gives you a default Main route table for every VPC. You can create custom route tables and also associate them with a subnet (for example, when you don’t want any data to be allowed to leave a subnet). AWS also creates a default route for communication within the VPC.

In this image, the first route is the default route 172.31.0.0/16 — local, It says any traffic that is destined to an IP address belonging to this CIDR block should be routed internally/locally, or that is destined to somewhere inside this VPC.

Second route 0.0.0.0/0 - igw-5a67df33 says that traffic destined to any other IP address should be routed through Internet gateway (igw-5a67df33 is its id). 0.0.0.0/0 denotes all IPV4 addresses, so if any other entry in your route table doesn’t handle the traffic, this route entry will. So you can say the routing table is used in order of the most specific to the least specific route rule.

Every VPC has a default route table that says everything that’s inside my CIDR range, (in any of the AZs) is inside my VPC, and they can talk to one another. So considering the CIDR ranges we assigned to a subnet earlier, say 172.31.0.0/24, Now if a request comes for 172.31.0.1, it will be routed internally on the local network.

That’s about communication within a VPC. How do you connect machines in that VPC to the Internet?
To connect to the internet, you need -

1. some form of connection to the internet
2. some route to the internet
3. some public address (172.31.x.x we are using in our example is a private address, not available on the internet)

For a machine to connect to the Internet, It has to be present in a public subnet.

what is a public subnet?

AWS doesn’t let you create private or public subnet as such. A subnet is public or private based on its routing table.
If a subnet allows outgoing requests (to the Internet) by connecting to the internet gateway, it is a public subnet.
If a subnet blocks outgoing requests to the Internet or redirects them to a NAT (network address translation) gateway, it is a private subnet.

But why do you need to connect the private subnet to a NAT gateway?

For use cases where your machine wants to remain private but needs to fetch something from the Internet (say to download updates). For that, you create a subnet, you don’t create a route to connect it to the internet gateway, but if needed, you rather connect it to a NAT gateway. NAT gateway is a one-way valve, and it only allows responses to the requests that come from inside, rejects outside (from the Internet) requests. NAT gateway is created in a public subnet and connected to Internet gateway (igw). So it acts as a proxy between your private subnet and the internet gateway.

Now to deal with the 3 points mentioned above.

1. Public IP address - create the instance in a public subnet, Also while creating the instance, check the option to assign it a public (elastic) IP address (say 198.51.100.3 is assigned). It will still have a private address as well.
2. Need a connection to the Internet - create an Internet gateway and connect it to the VPC.
3. Route - create a route 0.0.0.0/0 - igw_id in the public subnet’s route table. When you connect the subnet to igw (Internet gateway), this machine having address 198.51.100.3 can talk to anything on the Internet, and anything on the Internet can talk to it as well, like a typical web server.

Security

Here we will discuss three things -

1. Security groups
2. Network access control lists (NACLs)
3. Flow logs (for monitoring, analyzing network traffic, debugging network calls)

Let’s first see why do we need security? (especially Security groups here)

Consider this case, where you have one logical group of machines for web servers and one for the backend. Now we have an obvious constraint, things on the Internet should be allowed to talk to the webserver, and only webserver group should be allowed to talk to the backend group.

• The webserver will have to allow 0.0.0.0/0 traffic rule.
• The backend will have only allow webservers group traffic rule.

So here, we can assign one security group to web servers instances and another security group to backend instances.

1. Security groups

As is evident from the example above, security groups are distributed firewalls, and they are specific to an instance/machine. Also, Security groups are stateful.
Stateful means if a request comes from one direction, it automatically sets permission for the response to the request that comes from the other direction. But that doesn’t mean if you created an inbound access rule, then you don’t need outbound access rules.

what are inbound and outbound rules?
The inbound rules govern how externally initiated connections are handled, such as serving HTTP requests, for instance. The outbound rules govern how internally initiated connections are handled, such as fetching server updates with yum or apt.

The stateful nature of security groups can be compared to a router (Not exactly, though). The router protects your computer from the evils of the Internet. Traffic can’t come through your router to your computer. However, if you make a request to go to a website, that request goes out of your router, and the response is allowed back in because it is stateful. That is, the router remembers that you made the request to that website, and it permits the response to come back to your computer.

2. NACLs

NACLs gives you the option to set ALLOW/DENY traffic rules. But they are specific to a subnet. NACLs are stateless, So you will have to allow traffic rules in both directions explicitly. Please refer to AWS documentation for when to use security groups and when to use NACL.
For example, you can use NACLs when you want a rule to allow/deny traffic from a particular network or range of IP addresses. NACLs are relatively short compared to security groups. So, If you are writing complex rules around ports and IP addresses, you should probably use security groups.

Security Group acts as a firewall for associated Amazon EC2 instances, controlling both inbound and outbound traffic at the instance level, while ACLs act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level.

3. Flow Logs

Flow logs work at VPC, subnet, and instance level. You can dump the network calls to s3 or cloudwatch and analyze the traffic flow. You can configure it in your VPC (you will find a flow logs tab). Flow logs contain network interface, source IP address and port, destination IP address and port, bytes, accept/reject.

Now you can debug your traffic rules like an inbound ssh request is getting rejected, so you should check if you have set up that rule.

You also have DNS options in VPC to map those IP addresses to some names. Check out Route53 for details.
You can check AWS direct connect, transit gateway for building inter-VPN connection.

Let’s discuss in comments if you have anything to add, and give me claps. 🙂
Thanks.