Build a VPC from Scratch

In today's lab we will create a bare-bones VPC piece by piece to learn what you need, what you don't, and how it works.

Prerequisites

  • A workload account

The Lesson

I’m not here to teach you how to be a cloud network engineer, but I think I need to teach you how to be a cloud network engineer. Sorry. 🐼

Information security’s origins are in network security. It’s still one of the bedrocks of our profession, even though there are many newer career paths which never involve touching a firewall. But if you think about cloud computing, one of the essential characteristics is that we do everything… over the network.

So why network engineering instead of just talking about security features? It’s simple: network design profoundly affects network security. Unlike a physical network, with cloud we have way more capabilities to tune our networks at no additional cost for better security design.

In Journey to the Center of the VPC I introduced a bunch of concepts around Software Defined Networks (SDNs) and how Amazon‘s implementation, the mighty VPC, functions. With that intro out of the way I want to cover a networking fundamental — Internet Gateways — before we start building a basic VPC by hand.

As we work through the lab I’ll explain each component, with a focus on the minimum required elements.

Pour some CIDR on RFC 1918

Classless Intern-Domain Routing (CIDR, and yes, it’s pronounced cider) is the standard notation we use to describe and define networks and subnets. When you see “192.168.0.0/16”, that’s CIDR notation. You can read the details at Wikipedia but here’s the short version.

CIDR notation defines an IP address range. It consists of an IP address (like 192.168.0.0) and a number after the / (often 24 or 16) which, combined with the base address, defines how large the network is and which IP addresses it includes. 192.168.0.0/16 is what we call a Class B network, including the IP addresses between 192.168.0.0 and 192.168.255.255 — a total of 65,536 addresses.

192.168.2.5/32 is a single IP address.

You’ll see in a minute how we use CIDR notation in building a VPC; we have a lot of flexibility to define subnets as we want. These are all IPv4 examples, but AWS also has options for IPv6, which we will get to… in a while.

So what’s that RFC 1918? I mentioned it briefly last week — it’s the specification for addresses reserved for private networks. These addresses are never routed over the Internet, and we can use them however we want for our own private networks. What if something needs to talk to the Internet? Stand by for our Network Address Translation lab.

There are 3 blocks of reserved private IP addresses:

  • 10.0.0.0-10.255.255.255 (/8)

  • 172.16.0.0-172.31.255.255 (/12)

  • 192.168.0.0-192.168.255.255 (/16)

We will use both CIDR and RFC 1918 in a couple minutes.

Internet Gateways

VPCs are Software Defined Networks, where all the packets are wrapped and shipped around using Amazon’s internal software. But hey, at some point we want to, you know, talk to the Internet. And the Internet still uses old-school standard networking. So how the heck do we pull this off?

We use a special construct called an Internet Gateway. I assume this is massive hardware and not merely software, but an Internet Gateway is a thing you attach to your VPC which connects you, bidirectionally, to the Internet.

Internet Gateways connect your resources in a VPC to the Internet and handle translating from the AWS Software Defined Network to the rest of the Internet.

With an Internet Gateway we can assign Public IP addresses to our resources, including instances (virtual machines) via their Elastic Network Interfaces (ENI, the virtual “hardware” which emulates a network interface and cable). By default these are IPv4 public IP addresses within the huge range of Internet addresses AWS bought and owns. You get a random address from their pool, and it changes when you shut a resource down and start it up again. You can pay more to get a stable address, which we will talk about soon.

The cool thing about Internet Gateways is that they track and translate the software defined resources in AWS, and handle all the unwrapping and routing of packets from the VPC to the Internet, and back from the Internet to your virtual resource. How? I assume magic; and in my head I see unicorns in hamster wheels, which may indicate I need professional help.

Lesson Key Points

  • CIDR notation is how we define address ranges of networks and subnets.

  • RFC 1918 sets aside 3 address ranges for private networks.

  • Internet Gateways connect VPCs to the Internet, and allow us to assign public IP addresses to our resources (inside a VPC).

The Lab

We will build our first bare-bones VPC by defining our VPC, subnets, and an Internet Gateway. Along the way I’ll review some other smaller components.

Video Walkthrough

Step-by-Step

Sign into your portal and go to TestAccount1 with AdministratorAccess:

Then go to VPC, and make sure you are in us-west-2:

You shouldn’t currently have a VPC in us-west-2 since we deleted it, so click Create VPC:

You’ll see a pretty screen with a nice diagram for a potential VPC to build, with lines and boxes visualizing everything.

We won’t use that. I’m kind of a jerk, so we will build everything by hand. Using a number 2 pencil. (Okay, not that last part.)

We only need to change 3 settings on this page. First select the VPC only option. Then name your VPC CloudSLAW. This is a really good habit. I’ve assessed a lot of environments where there were either no names on a VPC, or a meaningless name. That makes it much harder to know what’s going on as you build out dozens, hundreds, or thousands of these things.

Document your code and show your work, people!

The last change is to set our IPv4 CIDR block; we want to use 10.0.0.0/16, that class B network which gives us 65K+ addresses to play with. No, we don’t need that many, but it isn’t like we pay extra for the bigger network, so don’t overthink it.

In case you were wondering, Tenancy can put you on dedicated hardware. You pay much more for it, so you need very particular requirements for it to make sense. Okay, now…

AWS created 3 components for you automatically since you used the console, which you would need to create manually using the command line or infrastructure as code (CloudFormation/Terraform). These are all required:

  • DHCP Option Set: This configures DNS and internal domain names. For our purposes we are fine with the defaults (feel free to look at them).

  • Route Table: We’ll look at this in a minute.

  • Main network ACL (Access Control List): This is a security construct we won’t use for a while, which I generally recommend you don’t touch until you know with certainty what you need to change. The default one AWS create allows all inbound and outbound traffic. I’ll mention these again when we talk about Security Groups, but for now just know that I rarely need to modify the default NACL; you usually only have to mess with them in complex enterprise network scenarios.

DHCP options, such as setting internal domain names

Allows all inbound and outbound traffic

It’s great that we have a VPC, but we don’t really have a network yet. We need subnets for that. Go to Subnets > Create subnet:

Pick the CloudSLAW VPC. If you see anything else you haven’t been following my instructions:

Change the following settings:

  • Name it slaw-public-1.

  • Choose us-west-2a for your Availability Zone. When you click that you’ll also see another designation like usw-az2. This is a weird thing where 2a is specific to your VPC, but az2 is the physical AZ. AWS used to not let you know which physical AZ you were in, but they had to add that over time as people started to connect more across VPCs and accounts, and needed to keep some things in the same physical datacenter.

  • Set 10.0.1.0/24 as the CIDR for the subnet. This gives us 256 potential IP addresses (not quite — AWS steals some for internal things it needs, so we only get 251 we can actually use ourselves).

Then click Add new subnet to configure another one before we actually create it. Use these settings, then click Create subnet:

  • slaw-public-2

  • us-west-2b

  • 10.0.2.0/24

Success!

Click slaw-public-1 to review at the settings. Nothing too exciting. Then click on the route table to review that:

If you drill down you can see we only have the one route, which only sends traffic to anything with the same VPC. If you try to talk to the Internet there’s no place for the traffic to go.

One cool thing is that we can define routes between some subnets and not others, which would restrict traffic to only the allowed subnets… all without needing a firewall. In our case we want these to be public subnets which can talk to the Internet, so let’s Create internet gateway:

Call it slaw-ig. These name tags really do help:

We now have an Internet gateway, but we need to attach it to our VPC. Actions > Attach to VPC:

Select your CloudSLAW VPC, and then Attach internet gateway:

If we go back into Your VPCs and click our VPC, you can see in the visualization that we have an Internet gateway, but it isn’t connected to anything.

To fix that we need to edit our route table to send traffic to the Internet gateway. Go to Route tables and pick the only one we have. Yes, as we add more we will absolutely use names. Perhaps you can feel my prior trauma oozing out of my pores, from all those assessments and repair jobs on consulting gigs where things were unnamed.

There are a few steps here. First we need to Add route, then we need to select the Destination of 0.0.0.0/0 which is CIDR-style notation for “The Internet”. Then click the Target dropdown to send the traffic to an Internet Gateway, and you’ll see the field fill in with igw-. Click that and select your slaw-ig gateway. Then Save changes:

Now local traffic routes within the VPC (but only to the destination, remember — this isn’t like a physical network where you can sniff traffic) and Internet traffic routes to the Internet gateway. BTW: “Propagated” means it is a route pushed into the table from someplace else. We don’t have someplace else yet, so that will always say No.

If we look back in the Resource map, everything is now wired up! We have a VPC with 2 subnets which can talk to each other and the Internet. This is a fully functional VPC:

I’d say more, but my dog is giving me a really big hint that it’s time for her walk. (Her brother is napping). Oh… without any network traffic this VPC is free. None of these constructs costs anything.

Lab Key Points

  • A minimal VPC requires the VPC, a subnet, a route table, DHCP options set, and NACL.

  • To connect to the Internet use an Internet gateway.

  • Route tables define where traffic is… routed.

-Rich

Reply

or to participate.