A Beginner’s Overview of AWS VPCs

  • by
AWS VPC

In AWS, a VPC or Virtual Private Cloud is a service that allows you to create your own private network within the AWS ecosystem. Think of a VPC like your own virtual router that lives inside AWS. As you spin up an EC2 or RDS instance it gets assigned to a VPC which helps it communicate with the rest of the network. VPCs have several components that help you configure your network for security and efficiency, you’ll find an explanation for the most commonly used ones below.

Common Components Of a VPC

Elastic IPs

Elastic IPs are static IP Addresses that you are reserving to be used on your EC2 instances, Load Balancers, etc. For example, if I click the “Allocate Elastic IP Address” button in AWS it might give me an IP of 54.3.3.3. I can then assign that IP Address to one of my EC2 instances knowing that no matter how many time I reboot that box that the IP won’t change.

Subnets

Subnets are a group of IP addresses that exist within your VPC. Let’s dig into that a bit more. By default a VPC comes with a /16 CIDR block of ip addresses – or 65,536 IPs. Subnets allow you to break those IPs up into logical groups so that you can apply different settings to them.

The most common settings to pay attention to on your subnets are:

  • Should they auto-assign public IP addresses?
  • What Availability Zone should they live in?
  • How many available IP addresses (internal) will they need?

With those settings in mind let’s say that we just spun up our brand new shiny VPC and now have a 10.0.0.0/16 CIDR block (remember you get a /16 by default). There are many ways to break up our IPs into subnets but I lean towards first breaking them up by environment (production and staging), giving each environment an internal and an external subnet, and then giving each internal or external subnet 2 availability zones for a grand total of 8 subnets.

You might be thinking, “Woah, that’s a lot of subnets, how much is that going to cost me?” Luckily they don’t cost anything extra. As far as AWS knows you’re just adding some configuration options to your VPC. So let’s see what our subnets and their settings look like if we give each one a /21 (2048 IPs) CIDR block.

  • Internal Production: 10.0.0.0/21
    • Auto Assign IPs: False
    • Availability Zone: us-west-2a
    • IPs available: 2048
  • Internal Production: 10.0.8.0/21
    • Auto Assign IPs: False
    • Availability Zone: us-west-2b
    • IPs available: 2048
  • External Production: 10.0.16.0/21
    • Auto Assign IPs: True
    • Availability Zone: us-west-2a
    • IPs available: 2048
  • External Production: 10.0.24.0/21
    • Auto Assign IPs: True
    • Availability Zone: us-west-2b
    • IPs available: 2048
  • Internal Staging: 10.0.32.0/21
    • Auto Assign IPs: False
    • Availability Zone: us-west-2a
    • IPs available: 2048
  • Internal Staging: 10.0.40.0/21
    • Auto Assign IPs: False
    • Availability Zone: us-west-2b
    • IPs available: 2048
  • External Staging: 10.0.48.0/21
    • Auto Assign IPs: True
    • Availability Zone: us-west-2a
    • IPs available: 2048
  • External Staging: 10.0.56.0/21
    • Auto Assign IPs: True
    • Availability Zone: us-west-2b
    • IPs available: 2048

There you have it! We now have a nicely sliced up VPC. Note that this is probably a good starter setup, but you may need to customize it more if you’re working in a more complex environment.

Route Tables

A route table is a set of rules that tells network traffic where to go. They are similar to aisle signs at a grocery store. If you want baked goods you can look at the signs above the aisles, see that they are on aisle 4 and proceed. In networking, your EC2 instance may say, “I want to get to my database who’s IP address is 10.0.40.78”. It would then reference the route table who would safely direct it to the location of the database.

Let’s look at something a bit more real. Here’s an example of a basic route table in AWS:

An EC2 looking for it’s database would read the rules top down, the ‘Destination’ column being where the network is going and the ‘Target’ being the location that it will direct the traffic to. It would first say, is the IP Address I’m looking for in the 10.0.0.0/16 subnet? Oh it is? Well then the target is ‘local’ meaning I can access it from within my own network. If your EC2 instead wanted to reach out to ‘Amazon.com’ it would use DNS to grab the IP Address of Amazon.com (205.251.242.103), see if the first rule matches, it doesn’t, so it would then use the next route rule which directs it to the igw or Internet Gateway (we’ll talk about this in the next section) in order to reach out to Amazon.

Once a route table is created it gets assigned to a VPC and can then be used by the subnets within that VPC.

Internet Gateways

Internet gateways are a VPC component that enables your instances with a public IP address to communicate with the outside world. It sounds pretty complex, but all the magic happens under the hood. In fact when you go to create an internet gateway the only customization you can do is assign it a name and tags, take a look.

Alright, so I created the mystical “Internet Gateway” making sure to give it a name. Now what? How do I use this thing?

Once you create your Internet Gateway there are 2 things you need to do to use it:

  1. Assign it to a VPC by clicking on the internet gateway, choosing “Actions”, and assigning it to the VPC of your choice. Note that each VPC can only have 1 internet gateway. It’s kind of a set and forget type of thing.
  2. Create a route table rule that sends external traffic to the internet gateway. In the section above (Route Tables) you can see that we added a rule at the bottom that says, any traffic (0.0.0.0/0) that doesn’t meet the rules above gets directed to the internet gateway.

One of the biggest misconceptions about Internet Gateways is that they provide access to the internet from ANY instance in your VPC. This isn’t true! In order to use an Internet Gateway YOUR INSTANCE MUST HAVE A PUBLIC IP ADDRESS! Whoops, my caps lock must be having issues.

The reason your instances need to have a public IP Address to use an internet gateway is because as the traffic leaves it needs to know how to return. Imagine we’re on an Ubuntu machine and we run apt install nginx. Your traffic will go through the internet gateway, grab the nginx files it needs, and then not have an IP Address to return files back to.

Luckily Amazon has thought this through and created another service that fixes our little problem of internal only instances not having access to the internet. The answer, NAT Gateways!

NAT Gateways

NAT Gateways are similar to Internet Gateways, but they give your internal instances (rather than external instances) access to the internet. Let’s explain how they work by exercising our imagination.

Imagine you have a castle with walls around. The walls are your VPC and the people inside are your servers or instances. There are some people in the castle like the chef or cleaner that can go in and out through the castle door. This is like using an Internet Gateway. But others like the king are far too important to leave the castle (your internal instances). In order for him to send and receive messages from the outside world he has a guard to do it for him. That guard is the NAT gateway. His whole job is to ensure that the king can communicate with the outside world without risking any harm.

Okay, back to networking terms. The NAT Gateway has a static public IP address – let’s say 5.5.5.5. If my internal Ubuntu instance runs apt install nginx and uses the NAT Gateway it will form a connection through the NAT Gateway to the server that has the nginx files it’s trying to pull down. The server that has the nginx files will think that an instance with the IP 5.5.5.5 is pulling the files down, when really it’s an internal only instance. If another instance within your network (that uses the NAT Gateway) runs apt install nginx it will look like the same server is reaching out to pull the nginx files down again.

A NAT Gateway allows your internal instances to start a connection with servers outside the network, but doesn’t allow anything from outside to start a connection with your instances.

To use a NAT Gateway you need to:

  1. Create the NAT Gateway in AWS. It will ask you which subnet you want it assigned to (note that NAT Gateways are a subnet resource not a VPC resource) and which elastic IP you want it to use.
  2. Add it to your route table for your internal instances to use.

One thing that’s a little bothersome about NAT Gateways is that unlike Internet Gateways they cost money – about $33/mo for each NAT Gateway.

Security Groups

I like to think of Security Groups as AWS’ take on firewall rules. Security Groups like to be told which ports to open and any not specified it will keep closed. Let’s take a look at a Security Groups inbound and outbound rules.

We can see that all traffic from any ‘Source’ is allowed to come in at port 8080 and all outbound traffic on any port is allowed to flow through.

Security Groups are assigned to your VPC upon creation and can be assigned to new and running instances.

Leave a Reply

Your email address will not be published. Required fields are marked *