We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 4
Okay, cloud gurus.
Welcome to this lesson
where we're going to talk about customizing VPCs, we'll talk about routing, and we're also going to cover security controls. Now we're covering a broad range of topics throughout this lesson, including VPCs and the different subnets and NACLs and security groups. So let's go ahead and get started. Now, first things first, let's have a quick review on what a VPC actually is. I imagine most of you know what this is, but, again, I'd just like to reinforce these fundamental learning blocks before we continue on. An Amazon VPC is a logically isolated virtual network that is dedicated to your AWS account only by default. Now, let's go ahead and take a closer look at some of the resources within a VPC including the different types of VPCs. Now, VPCs come in two different forms. There's a default and then there's a custom. Now with a default VPC, this is automatically created for you during your account creation. With these VPCs, it includes internet access by default. So there's an internet gateway that is deployed by default. Now, with default VPCs, any compute that you spin up within them is going to be assigned both public and private IPv4 addresses by default. So essentially, all of your compute is going to have internet access directly, as opposed to using a net gateway. Now, this is a major reason why you should never use a default VPC for workloads. They're great to experiment in and get some hands-on experience with, but they're never recommended to use for production, ever. Now, speaking of production workloads, this is where custom VPCs come in. With a custom VPC, you configure every little thing as required. Now, with the custom VPC, when you spin it up, internal communication will always be allowed. So compute can internal privately using the private IP space, but there's no default internet access. You have to explicitly grant and attach an IGW to your VPC and set up the routing for that to work. Now, no matter what, whenever you spin up compute, it is automatically always going to get assigned private IPv4 addresses. This is unavoidable and that's essentially how networking works, right? You can't avoid that. Now, as the opposite of default, you should always deploy custom VPCs for your workloads. All right, that's a little bit about the custom VPCs compared to the default VPCs. Let's go ahead and move on and talk about subnetting and routing. Now, most of this content is gonna be specific to custom VPCs, but you do have similar controls in default VPCs. But for this exam, custom VPCs will always be included within the scenarios and not the defaults. Now, the first thing I wanna talk about are subnets. An important thing to remember is that subnets belong to one availability zone only. You can have both public and private subnets based on the internet access granted to each of them. Now, a common scenario is going to be a three-tiered architecture on the exam, and this is where you will have a web tier, which is likely publicly accessible and this is gonna usually include things like a load balancer. You'll have an application tier, which is behind that load balancer, and is going to be included in private subnets. And then you'll also have something like a data or a database tier, which is also private and is exclusively accessed from the application tier. So it's security in layers. Now, moving on, let's talk about route tables. Remember, subnets can only have one route table at a time. You want to use custom route tables for controlling your routing needs. Now, a cool thing is, you can have multiple subnets share one route table if required. Generally, a best practice is to have each subnet have its own custom route table as this offers the most amount of control. Now, a new term within VPCs is middlebox routing, and this is the ability to control your routing paths of all of your traffic that's coming in or out of your custom VPCs. Now, a common scenario for this would be something like inspecting traffic using security appliances. So you route traffic through a custom subnet, which has your security appliances, and then it can continue routing that traffic to the other subnets. Now, the next on the list is managed prefix lists, and this is simply a set of one or more CIDR blocks. It's that simple. What it does is it allows for easier configuration when you're maintaining your security groups and route tables. Now they come in two forms. There's a customer-managed, which is where you define the common set of IP ranges; or there's AWS-managed, which is usually a set of AWS service IP ranges that they set. Now, a common example of this for an AWS-managed one, would be an S3 gateway. When you're setting up an S3 gateway for a VPC endpoint, it allows you to specify the AWS managed prefix list and route your traffic to those IP ranges. This really allows you to scale far easier as opposed to having to put a set of rules for each individual IP address as they get updated. So for customer-managed, maybe you have a default set of IPs for a security appliance you want to route traffic to. Well, instead of manually inserting those, you can create your own customer-managed prefix list and attach that prefix list into your routing rules. Hopefully that helps you visualize how scalable these really are. The next topic is subnet security. VPC subnets are going to reference NACLs or network access control lists for referencing the allowed and denied traffic for both inbound and outbound traffic. Now, we'll discuss NACLs in depth coming up, but this is very important for you to know, so I bring it up here. You need to know that subnets do not use security groups to control traffic. That's not how they work. Now, some more things to know, subnets are going to have five reserved IP addresses that you cannot use. There's a network address, VPC router address, DNS reserved address, and then a future use reserved address, and a broadcast address. Now, these are more geared toward the networking exam so it's not necessarily super important. You know these in depth but you do need to know that they are reserved. So let's go ahead and look at a subnet example for the reserved IPs. We have our example CIDR here of 10.0.0.0/20 and the first reserved address would be the network address, which you can see here. We then have to reserve our VPC router, which is the first available IP space in that subnet. And then thirdly, the DNS reservation. So the next reserved IP space for allowing internal DNS resolution. We would have our future use which is not specified yet, just reserved just in case. And then of course, the broadcast address, which is hardly used as well. So these are five examples of reserved IPs within this common subnet CIDR. Alright, cloud gurus. Now we're getting on the lengthier side for this lesson and we still have a lot to cover. So let's go ahead. We're gonna pause here. We'll take a break and then when you're ready, we'll pick up in part two of this very same lesson.