Explore the default VPC - Amazon Web Services (AWS) Tutorial

- [Instructor] Virtual Private Cloud, or VPC, is the networking cornerstone of running your IT services in AWS, as it lets you set up your network and IP space however you want. When you create an AWS account, you get a default VPC in every region that is ready to use. Let's take a peek inside of the US East Ohio region's default VPC to understand what you get right out of the box. First off, the default VPC has a Classless Inter-Domain Routing, or CIDR, range of /16. The default VPC's CIDR block is 172.31.0.0/16, and that's the case for the default VPC in every region inside of AWS. This means that the default VPC can handle 65,536 private IP addresses. However, not all of them are usable, as you will see. The default VPC also creates a subnet in each availability zone in the region. All regions have a minimum of two AZs while some regions have more. In this case, in Ohio, there are three. Each default subnet has a CIDR of /20 which can handle 4,096 IP addresses. AWS reserves some IPs for internal services so you end up with 4,091 usable IPs. The default VPC also comes with an internet gateway attached and with a rule in the main route table that sends all traffic intended for the internet to the internet gateway. A default security group is created as well as a default network access control list, allowing all inbound and outbound traffic. While you are free to use the default VPC and modify its configuration, it's out-of-the-box setup is broadly permissive. It is designed as the catch-all location into which EC2 virtual machines called instances get dumped in the event they aren't assigned to a VPC. I prefer to create my own VPCs and avoid using the default VPC. This way, I can be sure that when I create servers or databases in AWS, I know exactly where they are going. Deleting a region's default VPC is a dangerous proposition, as doing so can render some AWS services in that region inoperable. While it's possible for AWS support to create a new default VPC in that region, this is painful and to be avoided. I find that it's simply better to not use it. Let's go into the console and annotate the default VPC that we don't use it or its components accidentally. Here I am logged into the main AWS Console. If you look at the top-right corner of the screen, you can see that I am in the Ohio region. If you drop that down, you can see all of the regions that are available inside of AWS. When you sign into the web console, it remembers the last region you were signed into. That said, it's a best practice to double-check the region indicator in the top-right corner to ensure you're in the region you want to be every time you log in. To navigate to the VPC configuration page, I simply start typing VPC into the search bar, find VPC Isolated Cloud Resources, and click on that link. This brings me to the VPC Dashboard. The VPC Dashboard shows me an overview of all VPC-related services operating in a given region. One useful feature I like is the See all regions dropdown. Remember that we said all regions have at least two availability zones while some have more? Dropping down the See all regions menu allows you to see the number of subnets associated with the default VPC in each region. We can see at the time of this recording that the Canada Central region looks like it has two availability zones while North Virginia has six and Oregon has four. Specifically for Ohio, I see that I have one VPC active, three subnets, one route table, one internet gateway, one DHCP option set, one network ACL, and one security group. Clicking on the VPC link in the center of the screen brings me to the VPC detail page. Here I see that the default /16 VPC is available. However, notice that the name is blank. All default VPC components are unnamed. The name tag is of special significance in AWS and is particularly useful when interacting with the web console. I'm going to rename the default VPC now by hovering over the Name area and clicking the little pencil edit icon. Instead of leaving it unnamed, I'm going to call it DONOTUSE_VPC. That's a little lengthy, but expanding the Name column allows me to see the entire thing. Okay, now let's rename the rest of the components. Clicking on the VPC Dashboard link brings me back to the Overview where I can see subnets, route tables, et cetera. Clicking on the Subnets section brings me to the subnet configuration page. Again, the subnet names are blank. Note that each one is a /20 with available 4,091 IPs, and each one corresponds to an availability zone. Note that in the VPC column, there's the internal VPC ID, which is hard to read and not very friendly. However, remember when we talked about name having a special significance? The name assigned to a component also appears in the web console. That makes it much easier when navigating in the future. To that end, let's go ahead and label these subnets as DONOTUSE as well. The first one happens to be an availability zone B, so I'm going to call this DONOTUSE_SUBNETB. The next one happens to be an availability zone A, so I'm going to repeat the process. And the last one is in AZC. Okay, the subnets are all renamed. Let's go back to the VPC Dashboard and see what we have to do next. Let's take a peek at the Route Table configuration. So, again, we see the route table's internal ID in the Route Table ID column, rtb-, et cetera et cetera. And in the lower right-hand corner of the screen, under the Summary section, we see that this route table is associated with the main VPC, that DONOTUSE_VPC, that default. So, again, I want to specify that this is the default route table and that I do not want to use it. Let's head back to the VPC Dashboard and see what's next. Okay, let's do the internet gateway. So, again, on the Internet Gateway page, we see the default ID for the internet gateway, which is immutable, and then we also see the VPC to which it's attached. Let's go ahead and label that as DONOTUSE_NOW. Wonderful, let's head back to the main dashboard. So we've done VPC, we've done subnet, we've done route table, we've done internet gateway. The DHCP options set is an interesting one. I don't label this as DONOTUSE because I tend to use the Amazon-provided DNS. Instead, what I do is I just label it so it's clear in my mind this is the Amazon-provided DNS, so I just say AWS_DNS. Heading back to the dashboard, we only have a couple of resources to go: network ACLs and security groups. Clicking on the Network ACL link in the center section of the screen takes me to the Network ACL configuration section. Once again, I see the default network ACL ID as well as the VPC to which it's associated. I'm going to go ahead and rename it now. While we're here, let's take a quick peek at the Inbound and Outbound Rules tabs in the bottom half of the screen. The Inbound Rules tab shows that all inbound traffic is allowed. Clicking on the Outbound Rules tab, we see that all outbound rules are allowed as well. This is unique to the default nACL. Every nACL you create denies all traffic by default. Clicking on the Subnet associations tab tells us that this nACL is associated with all of the default subnets. Again, I can just expand the Subnet ID column to see the name that I associated with the subnets earlier. Instead of navigating back to the VPC Dashboard, I can go directly to the security groups configuration screen by clicking the Security Groups link in the left-hand navigation pane. Here we have that default security group, and, once again, it doesn't have a name. I'm going to go ahead and assign it one now. Let's go ahead and expand the bottom section of the screen and take a peek at the inbound rules for the security group. Here we see that all traffic, all protocols, and all port ranges are allowed from this group itself. From an outbound standpoint, all traffic is allowed as well. Let's head back to the VPC Dashboard. Okay, by this point, we've flown through the default VPC components and assigned each one a name. Now let's go forward and create a VPC of our own.