AWS VPC: Networking basics, CIDR notations, Subnets, Gateways and Route Tables

Let’s start off by saying this article is for getting the basics on AWS networking straight. I have arranged the article as modules/blocks, so incase you feel like you already know something skip that module/block and feel free to skip through as per your comfort zone. Having said that let’s jump straight in.

Module 1: “CIDR Notations”

CIDR notations are how we describe IPv4 addresses, when we are looking at them in sequence.

Example of an IP address: 10.10.101.1

This is a 32-bit binary number, what this means? Well, it means it has 4 octets ranging from 0 to 255. So what i mean is each part of this IP 10.10.101.6 stands for an 8 digit binary number. So in reality what we read as:

10.10.101.6 → 00001010.00001010.01100101.00000110

So again here are those 4 octets I mentioned!

Now the CIDR blocks are after then slash mark: 10.10.101.6/16

So /16 basically means we freeze the first 16 digits of the IP address. This means that the IP address of the server will always be 10.10.x.x where x is any number from 0 to 255. This gives us 65,536 possible IP addresses!

It could be 10.10.102.52/16
OR 10.10.103.57/16
OR any of the possible 65536 combinations as I mentioned.

16 is a very common CIDR block for VPC. Wel, if it was anything else say CIDR block was 32, that woul just mean 1 IP address since that is what you get if you freeze all 32 bits, correct? Now that you see where I am going with this, let’s go a bit deeper.

Now, let’s say you have a front end of your application that you want to expose to the entire internet, you would put your IP range as 0.0.0.0/0 hence freezing 0 bits basically means you are allowing the entire IP to be anything you want!

Module 2: “Subnets & VPC”

Now that we are clear about the CIDR blocks annotating of IPv4 addresses, we need to subdivide those IP’s into subnets. Basically subnets are a subset of the CIDR blocks (/16 in the above example)

(Note: Subnets in on prem infrastructures were originally meant so that you could place stuff like servers and routers and switches close to each other if you needed continuous communicaiton between them. Using them in AWS is a bit different. Here we use them as kind of security isolations where we group stuff in subnets as per their communication with outside world and within the VPC and On prem Hybrid framework if you choose that option.)

To understand subnets and VPC better let’s take a look at a standard 3 tier architecture:

Tier 1: Front-end Web server → open to the world
Tier 2: Application Server → Protected and private
Tier 3: Database → Protected, private and running in a master standby config

Let’s think of VPC(Virtual Private Cloud) as a private cloud you own on the AWS infrastructure. Noting goes in or comes out without your explicit permission. You allows stuff in and out using Route Tables. Route tables are basically a list of IP CIDR blocks that you allow your subnet to communicate

Thinking of VPC think about high availability from the beginning , running in 1 AWS region within multiple Availability Zones(AZ) for redundancy, incase one AZ goes down yo have another to fall back on. But each VPC is constrained to just 1 region.

Everything inside a VPC is 10.10.x.x./16. Also everything inside a VPC lives inside a subnet. Every subnet has it’s own CIDR block. Each CIDR block must be unique and cannot collide. SO every subnet has it’s own location inside the VPC with a 10.10.x.x address

Now as we mentioned we were going to look at a standard 3 tier architecture for a VPC. This following image provides a rather descriptive detail of whats going on in every VPC.

Now every VPC has public and private subnets as per the user’s(architect’s) recommendation based on security framework. Here we have 2 subnets in each AZ in the region. 1 Public and 1 private for each AZ. We replicate the subnets over the AZ’s in the region as per our required redundancy.

The public subnet is open to the internet and communicates to the open internet from the IGW (Internet Gateway) All traffic routed to the open internet is sent through this gateway. The private subnet consists of the main juice running behind your application, it has the application server and the database. You obviously want this protected, so that is behind a private subnet. This won’t send communications via the IGW

Now how do these subnets know how to send these packets using the IGW or not and how do these subnets know what they are? Surely not the name since we coud name it whatever we want , it’s convention to name them like this but the name doesn’t suffice, so any ideas?

Module 3: Route Tables”

Well, Route Tables! They do all the magic of knowing which packets need to go where from which subnet. Every subnet has a RT by default when you create a VPC. It is one line: 10.10.0.0/16 Local , where the first if the IP and CIDR block and the latter part “Local” means it’s to look inside the VPC and see each other’s stuff of other subnets only within the VPC. This is created automatically when you create a VPC on AWS.

Now this won’t allow public subnets where we want users to interact with our application to access the public subnet since that is our front end. And obviously we do not want users to see the application server and database directly. All traffic should be routed through Public Subnet and that will query the private subnet.

Now to make sure the public subnet can interact with the world i.e. 0.0.0.0/0(look up in Module 1 if you don’t know what this means) . We need to add that rule to the Public Route table. So the Public RT would look like this:

Public RT:
10.10.0.0/16 Local
0.0.0.0/0 IGW

As we put open to the entire internet we also put IGW meaning that all traffic to and form the world to the public subnet should be routed through the Internet Gateway.

Module 4: “Private Subnet RT”

Now that we have seen how Public Interface Route Tables work that makes you curious right what if we have a Database Admin or a Systems Administrator who wants to jump in and push an update to the DB software or to the software stack hosted within the confines of the Private Subnet. How does he talk to that given that the only communication from the private subnet is via the Front end stack in the Public subnet (check picture above for representation).

BAD CHOICE: Obviously, if you’re just thinking practically, you can (even though this goes against every security recommendation in the book) open the private subnet to the internet for a while as you push an update to the private stack or DB and close it again. This obviously leaves you open to malicious attacks in that timeframe. Goes without saying, this a BAD choice! It also negates every security protection you put in place up until now.

2 GOOD CHOICES:

Having said that there are 2 possible good things we could do; a.) use Bastion Host, and routing outward traffic packets through NAT. or b.) VGW(Virtual Private Gateways)

a.) Use of Bastion Host, and routing outward traffic packets through NAT

Let’s say you have a DBA, using an Oracle DB in your stack and now he wants to connect to an external IP x.x.x.x to download Oracle’s updates and security patches looking at your current DB stack. How would you do that using AWS VPC. You put in the x.x.x.x Ip and try downloading and it fails packet transmission. Duh! your private subnet is not configured for outside packets remember? And Making it public would violate every security mechanism in place.

How to solve this→ bastion host Or a jump box

The whole point of this is to allow your DBA to log into a public facing instance, then they can log into any other instance or assets they have access to inside VPC. The Bastion group will have security groups and ACLs(Access Control Lists) to prevent any unauthorized access to it. Basically you would get root access to bastion host.

Think of the bastion host as a pretty UI with login info where DBA can login from to gain root access. Ofocurse there will be security in place for restricting IPs from where the DBA can do all this and how, and so on.

But what bastion hosts don’t do is allow traffic from private s/n to trace its way back out into the open internet. For that we have to add something else→ a NAT server(network address translation server),

NAT servers have been here from the beginning and were not invented by AWS. NAT server pretends to be the entire internet. It accepts and redirects the packet. You need to add this line to your Private s/n RT: 0.0.0.0/0 NAT-ID

And this routes all outbound internet traffic form pvt s/n thru NAT. To do this you have to disable source/destination checking→ which is ON by default. But this is what protects your assets from MITM attacks. NAT sends out packets to 0.0.0.0/0 since it has public RT, and boom! you’re talking to the outside internet from your DB.

Private RT:
10.10.0.0/16 Local
0.0.0.0/0 NAT-ID

Please follow the dark line in the picture above to find the path we just explained. And here we conclude 1 good way.

Module 5: “Gateways”

We just saw how to connect to the internet for DB and stack updates using Bastion hosts and NAT. But what if we want something else more secure maybe. Not that that is not secure but let’s say we want to lock down our subnets further.

What to do?

b.) Virtual Private Gateways

We spoke about Internet Gateways to route traffic and packets to the internet up for a bit but didnt go into details of what gateways are.

Gateways are basically how traffic moves in and out of your VPC. Think of these like your security guards at the gates who check your RT and privileges to let you in or out. Hence,the name.(see image Sci-fi nerds)

SO we know IGW are internet gateways that give public subnet access to the world 0.0.0.0/0 and deny them access to private subnets.

VGW or virtual Private Gateways give secure access to Private subnets to certain people. Think of this as giving some root to some people. Like selective sudo access to a group of users in linux.

Now if the DBA is On-Prem at the Data Center at 172.168.x.x and tries to ssh into the DB he can through the VGW, or iff he uses a VPN he can again ssh into the DB from that.

Simple as that!

You just need to add that IP to the Private RT: 172.168.0.0/16 VGW
Hence, allowing traffic from that IP range to the Private subnets, as explained above through the VGW.

Private RT:
10.10.0.0/16 Local
172.168.0.0/16 VGW

And then the DBA can push updates to the stack from that IP range alone. I believe this a more robust method and allows for higher security but that is just my subjective opinion and is not a security recommendation.

To summarize, we started with CIDR blocks, learnt about Subnets, Routing Tables, Gateways and understood ‘VPC’s’ as a whole, through a simple 3 tiered architecture.

HPC, Engineering, Operations Research, Statistics, Cloud, Tech. & Management. Currently work at Penn State’s HPC Initiative(PSU-ICS).