Resources referenced within this lecture:

VPC TCP/IP Addressing

 

Transcript

So now we know what a VPC is, let's take a look at subnets. Now, subnets reside inside your VPC, and they allow you to segment your VPC infrastructure into multiple different networks. Now, you might want to do this to create better management for your resources, or to isolate certain resources from others, or even to create high-availability and resiliency within your infrastructure. So let's take a look at the subnets. 

Firstly, then we'll just draw our VPC quickly. So this is our VPC. And I mentioned when talking about VPCs that when you create your VPC, there's two pieces of information that you need. You need to give it a name and also a CIDR block address. Now, the CIDR block address is a range of IP addresses and this CIDR block range can have a subnet mask between a range of IP addresses from a  /16 all the way through to a /28. Now, if you're not familiar with TCP/IP addressing, now please take a look at the link on screen and check out the following course and this will dive into the CIDR block and TCP/IP addressing in greater detail. 

Now, for our example, let's say we created our VPC with the following CIDR block. 10.0.0.0/16. Now, this is important because any subnets that we create within our VPC need to reside within this CIDR block range. So let's take a look at a couple of subnets. 

Now, in this section, I want to talk to you about public subnets and also private subnets. So let's just create a public subnet there and also a private subnet here. This yellow one can be our public subnet and the green one can be our private subnet. Now, similarly, when we create a VPC, we need to give it a CIDR block range. We need to do the same with our subnets as well. So let's say for example this is 10.0.1.0/24. Now, this range of addresses sits within this bigger CIDR block here, and then this private subnet can be 10.0.2.0/24. And again, this CIDR block sits within the bigger VPC CIDR block. 

Now, what makes a subnet public and what makes a subnet private? Well, essentially a public subnet is accessible from outside of your VPC. So essentially from the Internet. For any resources created within your public subnet, for example web servers, would be accessible from the Internet. Now, because we want these web service accessible from the Internet, I have two IP addresses. So they have their own internal IP address which will be within the range of the subnet, which, for this subnet, it's 10.0.1.0/24. And then also we're going to assign them a public IP address as well, because to be accessible from the Internet, the instance itself has to have a public IP address. 

Any resources created within your private subnet, for example your backend databases, would be considered private and inaccessible by default from the Internet. So how do you make a subnet public and how do you make one private? When you create a subnet, you create them both exactly the same. It's what you configure afterwards that will dictate if a subnet is public or private. 

There's two changes you need to make to your infrastructure to make a subnet public. The first is to add an Internet gateway. Now, an Internet gateway is a managed component by AWS that is attached to your VPC and acts as a gateway between your VPC and the outside world. So essentially the Internet. So let's just add in an Internet gateway here, IGW for Internet gateway. So now we have our Internet gateway attached to our VPC. And this Internet gateway then also connects out to the Internet. So we now have a bridge between our isolated VPC to the Internet by the Internet gateway which is managed by AWS. 

Now, you might think that a public subnet now has access to the Internet because there's an Internet gateway. However, before the public subnet can access the Internet, we need to add a route to the public subnet's route table. Now, associated with every subnet when it's created will also be an associated route table. Now, you can have the same route table associated to multiple subnets. That's not a problem. However, you can't associate more than one route table to a single subnet. 

Now, by default, when your subnet's created, it will have a default route in it, and this is a local route. Let's take a look. Now, your route table will contain a destination field and also a target field. Now, the destination field is the destination address that you're trying to get to. The target essentially specifies the route to that destination. Now, within every route table that's created, there will be this local route here. Now, what this enables your subnets to do is simply talk to each other. So any subnet within your VPC is able to communicate with each other without you having to configure any routes. It's there by default. Every route table has this local route. It can't be deleted, and it simply allows all subnets within your VPC to communicate with each other. 

So what we need to do is we need to add a route to this route table that's associated to the public subnet. Now, this new route here that's been added to the route table has a destination of 0.0.0.0/0. Now, that essentially means that for any IP address that's not known within the route table already, send it to this target. Now, this target is the Internet gateway as shown by the IGW. This part here is simply the ID of the Internet gateway. So by adding this route to the route table, this public subnet now knows exactly how to get to the Internet by going by the Internet gateway as shown in the route table. Now, those two components are essentially what makes a subnet public, the fact that we have an Internet gateway attached to the VPC and this subnet has a route pointing to the Internet gateway for any traffic that it doesn't know how to get to. 

Now, if we compare the route table of the private subnet, we can see that it only has this local route, so it has no route to the Internet gateway. It's not aware that an Internet gateway even exists, so it has no route out to the public Internet. So this is considered a private subnet. Now, if we go back to the public subnet, before we added this route here, so let's just take that out. This subnet is effectively a private subnet, because it doesn't have a route to the Internet gateway. So with that in mind, every time you create a subnet, it is a private subnet to begin with and that is until you attach an Internet gateway to your VPC and then add this additional route. 

So now we've looked at public subnets and also private subnets. Let's now look at architecting multiple subnets across your VPC for high availability and resilience. So let's just clear the screen, give us a blank VPC to work with. So let's consider we have three subnets this time. We'll have a public subnet, and we'll have two private subnets. This can be our public subnet, and these two will be our private subnets. This will be our web layer. This will be our application layer, and this will be our database layer. 

So in our public subnet, we will have some web servers. In our application layer, we'll just have some EC2 instances. And in our database layer, we'll just have some databases. So there we have our three tiers of our deployment. So as we know with any subnet, we have a local route, so each of these will all have a local, as you can't remove that local route. And this enables all of these subnets to communicate with each other. The public subnet, as we know, will also have a route to the Internet gateway. Now, when you create a subnet, you have to create it in one of the availability zones that are available within that region. Now, if you're not too familiar with the AWS global infrastructure, then please take a quick read of the blog post below. 

Let's say for example when we created this subnet, we created it in availability zone one, and we've done the same for the remainder of our subnets as well, and placed them all in the same availability zone. And that's all okay, we can deploy infrastructure all within the same availability zone and our solution would be operating fine. However, should AWS have an issue with availability zone within this region, for example they might experience a flood or a fire or a natural disaster, and it took out the services to availability zone one, what would happen to our resources? 

Well, effectively, these would also be taken down because they're all running in availability zone one. So that's not ideal. It's not best practice to deploy all of your resources within the same availability zone, within a single region, simply because it doesn't offer high-availability and resilience. So what should you do in that situation? Well, the best thing to do to ensure high-availability is to add additional subnets to allow for resiliency. So we'll add an additional web tier and also additional application, and also a database. 

So now we have six subnets, and again, we'd replicate our resources, so it'd have our web infrastructure here, we'll have our application service here and our databases here. Again, then we'll have the routes and then Internet gateway route as well. This will have a local route, and as we know, this allows communication between all subnets. So now, every subnet can talk to every other subnet with a local route, and also this also has a route to the Internet gateway as well. So now let's look at the availability zones that we'll deploy our infrastructure in this time. 

Let's say for example we'll deploy this in AZ-1, this application subnet in AZ-2, and this database subnet in AZ-3, and similarly, down here, we have this public subnet in AZ-3. This one in one, and this final one in two. So now let's run through the scenario again. Let's imagine AZ-1 experienced a failure. So what would happen here? This public subnet would be out of action. This application subnet and that is it. So in this situation, we still have one subnet available in each layer of our infrastructure. So should we experience a failure with availability zone one, our services will remain up and running. 

So let's do the same with availability zone two. What would happen in this situation? Well, both of our public subnets would be okay, because everyone's in AZ-1 and three. This application subnet would be down, and this database subnet would also be down. So again, at least one subnet in each of our layers is operational and available. So again, our services would still be up and running. 

Now, finally, just for clarity, if we take down availability zone three, this web layer would go and also this database layer. So again, we still have at least one subnet in each tier or each layer of our infrastructure operational. So this is a much better design. This allows you to ensure your resources stay up and running should a failure occur in one of the availability zones. Before we move onto some security features, let me just clear the screen because I want to talk to you just quickly about IP addressing, just a couple of points that I want to mention with regards to the subnets. So let's just clear this quickly. 

So I mentioned that when you create your subnet, you have to assign it a CIDR block range that fits within the VPC CIDR block. So say for example we created a subnet here, and we give the subnet the address of 10.0.1.0/24. Now, with a slash 24 mask, this gives this subnet a total of 256 IP addresses. You can only actually use 251 IP addresses. And I'll explain why. So the very first IP address in this subnet is 10.0.1.0 and this is known as the network address. Now, you're not able to use this as an IP address to assign to your host addresses. This is reserved for networking. Now, the next available IP address after the network address is 10.0.1.1. And this is reserved for AWS routing. So again, not a network address. You can't use this address as a host network in your subnet. Now, the next available IP address is 10.0.1.2. And again, this one is reserved by AWS, but this time for DNS. So you cannot use this IP address. Now, the fourth IP address that you won't be able to use in this subnet is 10.0.1.3. And this is actually reserved by AWS for future use. Now, the fifth and final address that you can't use in an AWS subnet is the last available address in the subnet. So in this case, it'd be 10.0.1.255, and the last address in any subnet is known as the broadcast address, and again, you cannot use this for host resources. 

So when working with TCP/IP addresses within your subnet, first four addresses in any subnet are reserved and you cannot use for host addresses and also the very last address is reserved. So that's why use only 251 IP addresses available to you that you can use to assign to your host resources. So now we've covered what a VPC is. We've looked at subnets, both public and private, and also how it's best to architect your subnets across multiple availability zones for high-availability. So now let's look at some security features. I want to start with network access control list. Let's take a look.