Building Networks on AWS

0:00Welcome back, all you beautiful learners. My name is Scott Fletcher, and in "This Skill", we're gonna dive into Amazon VPCs or virtual Private Clouds. Now, this isn't the networking specialty course, so we're not gonna go ultra deep, but as a SysOps Admin, you are gonna need to know something about how AWS does networking, and how to set it up and how to troubleshoot it. But before that, I wanted to share with you a perspective that has helped me over the years, especially when I go to learn something new.

0:30Now, I recognize that people are probably coming to this course with a variety of AWS backgrounds, whether you're just getting started or you've been using it for years, and chances are you're taking this SysOps course because you want to learn more about how AWS does SysOps. Your knowledge, let's just say maybe is starting right here, and you're hoping for some trajectory like this. Two psychologists by the name of Justin Kruger, and David Dunning did a lot of research on how people self-assess their knowledge when they're just getting started in a new learning journey.

1:07What they found is many people overestimate where their starting, maybe their real starting point is down here, and they're going to take some trajectory like this, and that's the crux of Dunning-Kruger. It has nothing to do with your intelligence or your abilities or anything like that. Well, let's look at how this can really mess with our minds. On one axis here, we have confidence, and on the other axis, we have experience, our knowledge, our our practical ability with in this case our AWS platform, and our AWS skills.

1:40And with that Dunning-Kruger Effect at play, we might overestimate our abilities early on. And then we come to that inflection point, and then we realize, "Wow, we really don't know as much as we thought we did." And then maybe our confidence just plummets down into this, what some people call, the Trough of Disillusionment. And in this Trough of Disillusionment or Trough of Despair, I've heard it called several different things. There's some pretty negative thoughts that live down here.

2:11Imposter Syndrome. We might think, "Hey, we're not good enough. We're not good enough to complete this course." Or, "We're not good enough for that certification." Or self-doubt. "Wow, there's so much. I don't know and I feel like a fool." But the reason I'm sharing this stuff with you is because this is all very, very common, and I don't want you to feel bad if you have these feelings. This is part of many people's learning journey, and learning experience, and that's what I wanted to share with you.

2:42There's probably gonna be points in this course where you're gonna feel overwhelmed. Things just don't make sense. It's like I'm speaking a foreign language. Stick with it. Work hard, do the exercises, and you're gonna get there. You can do this. You got this.

0:00Okay, let's start with some white boarding or I guess black boarding in my case. So in the AWS universe, at the highest level we have AWS. And within this AWS universe, there's all sorts of networking, tying all these services and all these places together. Now, from that top level, AWS is divided into regions. Now there are regions on pretty much every continent, and these regions have names like US East 1 for the region that's based in Virginia or EU West 1, which is based in Ireland, and AP South 1, which is based in Mumbai.

0:39And you can see these regions if you do the dropdown on the console, the little dropdown on the upper right. And for the most part, AWS services live within these regions. It's the same service, it's just replicated across all these regions. There are some services though, that are region independent. In other words, they're global in nature. And some examples of that are IAM or identity and access management, S3, which is Global Object Storage.

1:12And Route 53, which is the managed DNS service. It just doesn't make sense to have region specific versions of these services. Now, if we dig into that region, we have further subdivisions. We have availability zones or AZs, and these availability zones, think of 'em like little data centers within that region. They're spread apart geographically so that if there's some sort of disaster that affects one area of the region, it doesn't take down the other AZs.

1:44And these AZs are all connected with all sorts of high speed data networking. And for some AWS services, we can choose to deploy those services in a single availability zone or a single AZ, or a multiple availability zone configuration, meaning that there's copies of that service or that data in multiple AZs. And of course, doing so increases our fault tolerance and we'll talk about that in another skill.

2:18But for now, I wanted to get you familiar with this concept of availability zones, because it comes into play when we start talking about virtual private clouds or VPCs. So we will go into a region, we're gonna go to the VPC console within that region, and we're gonna define a logical construct known as a VPC. Now by themselves, VPCs live at the region level. And this is a little bit different. If you've ever worked in Azure, their VPCs are more global in nature and then you can define resources within regions inside that VPC.

2:54For AWS, the VPCs are defined at the region level. Now of course, there's ways to get those VPCs to communicate to other VPCs in other regions, and we'll cover that later. But for now, know that VPCs are just tied to a region. Now, within that VPC, we can define different subnets, and these subnets are where our resources are gonna live, at least our IB based resources. Now, back to the AZs. The AZs are usually named after the region, and then an A, B, C, or D, depending on how many AZs are in that region, it's just tacked on at the end.

3:33Now, an interesting fact here, although these availability zones are physical buildings with racks and racks and racks of computers, the location defined as US East 2A in my account may be a different physical location than that which is defined as USE East 2A in your account. When your account is created, AWS randomly assigns these values, the A, B, C, and D to the physical locations for each account.

4:04And the reason AWS does this is they don't want people to tend to always choose USCs 2A, and then everything would be going to 2A 'cause psychologically, some people just, "Hey, I'm gonna choose the first one that being A," so AWS gets around this by randomly distributing A, B, C, and D. So that's why if you're working across accounts, don't necessarily assume that 2A is the same as this other account 2A, we have ways that we can ensure that we're gonna place our equipment together, but we'll get into that later.

4:40So back to our VPC, we're gonna define subnets, and then we have to assign a certain AZ to that subnet. Where is that subnet going to live? So we might define a subnet here and maybe we will put one here. And then in that case we have a subnet in US EAST 2A availability zone, and we have another subnet in US East 2C. And so if we deploy resources to either of these subnets, they're gonna be in physically different locations.

5:16Now I'm gonna reset the drawing and we're gonna zoom in a little bit more into the subnets and the VPC. Okay, this is a little different view. Think about that last diagram as this is kind of inside out. So we have the VPC at the region level, we have the subnets, and this little A and B indicates that one of the subnets is in availability, zone A, and the other subnet is in availability zone B. Now we have a routing table or a router that allows these two subnets to communicate if we choose to allow them to communicate.

5:52And additionally, we can define an internet gateway that allows us to communicate back and forth to the public internet. Now, people will often refer to subnets as either public or private, and that just means how we have them set up. We can define our routing rules to say that subnet A, for example, can indeed talk to the internet. Well, subnet B can't talk to the internet because we don't allow the traffic a path or a route to the internet.

6:25So in this case, we would consider subnet A as a public subnet and subnet B as a private subnet. And likewise, we can also set up a VPN, for example, between our subnet that lives in AWS and our own data center. Now, let me redraw this where we're zoomed in more on the VPC and we can look at some of its components in more detail. Now, when we create a subnet, we're gonna be asked what IP range do we want to allow it to use? Now, most commonly, people go with the private reserved IP ranges like 10.0.0.0 or 172.16.0.0, or good old 192.168 network.

7:09You don't have to do that, but especially if you want your subnet to talk to the internet directly, then you don't want to be using somebody else's addresses. Now, your company may have a range of addresses, it's been assigned to them, and that's perfectly fine too. But generally speaking, most people stick with the private reserved addresses. Now, regardless of what IP range we assign to our subnet, there are some reserved addresses in there.

7:40Let's say for example, we're gonna configure one of our subnets to use the 10.1.1.0/24 address range. If you're kind of rusty on your IP addressing, that's the equivalent of 255.255.255.0 as a net mask, which gives us 250 -ish addresses. And the reason I say that is because there are some reserved addresses that AWS doesn't allow us to use. And in this particular network range, those would be 10.1.1.0, which is the network, and of course, 10.1.1.255 which is broadcast.

8:20And then in this network, 10.1.1.1 this is all assigned by AWS internally. We really have no control over this. This is the VPC router, so that is this thing. We also have 0.2, which is our DNS server. And then finally we have .3, which AWS says is reserved for future use. So if you bring up a machine or a resource or something like that inside that subnet, you're not gonna get any one of these IP addresses, and you should not manually assign any one of these IP addresses to anything.

9:03You can cause some weird problems. Now, we do have some control over the DHCP options, and I'll show you that when we get to that point in the actual configuration. But we can define custom DNS servers. We can define an NTP server if we want to. We could set a custom domain name. We can even set a NetBIOS name server. And if you don't know what NetBIOS is, that's a Windows networking thing. I know, I know you're eager to get in there and roll your sleeves up and get building, but bear with me here, we got a few more topics to cover.

9:38And one of those topics is security groups and network access control lists. So network access control lists or NACLs as some people like to call them, define what port level traffic we're gonna allow in and out of our subnets and maybe in and out of our internet connections. It's IP based, we define certain IP ranges or a specific IP address, and we can say whether or not we can allow traffic to that.

10:11It's an allow or deny type thing. The other piece we have that we can work with is security groups, or you'll see 'em sometimes abbreviated SGs. Now security groups can be assigned to resources inside the subnet. What's useful about security groups is that we can assign security groups to use other security groups, and I'll show you an example later on. Okay, last thing before we get into some real hands-on stuff, we have several different ways to provide internet access.

10:48The most basic way is simply an internet gateway, and this just goes out to the internet. As long as we provide a route, typically it's 0.0.0.0 /0 In other words, the default route would go out to the internet and we can get that traffic back. Now, if our network access control list allows that traffic going outbound or inbound to pass, then we can provide that access to our public subnet.

11:24So let's say this was our public subnet, and we had resources in there that were assigned public IP addresses as well as a private IP address because everything in a subnet always gets a private IP address. That's how it communicates internally. But we also have the option a lot of times of also assigning a public IP address, that is an address that's typically in AWS's reserved range, and they would assign it to a resource in there.

11:56Therefore, that resource could directly talk to the internet in that case. Now, if we're using IPV 6, AWS has something called the egress only gateway. And that only allows traffic out. We're not gonna dwell on that option too much. It's kind of an advanced topic. Probably see that more in the networking specialty course. But just know that there's an IPv6 gateway that is egress only, meaning our resources inside the VPC, inside the subnets, can only reach out via IPv6.

12:40Now, why on earth would you want a one-way door to the internet? Well, for one security reasons. IPv6 addresses are globally unique and therefore we can use them on the public internet. So if I wanted to define a path for my IPv6 resources to get out to the internet to say maybe download some updates or retrieve some information, then maybe I don't want any IPv6 resources from the public internet getting into my VPC. That's the way I would do it.

13:11Now, if we want bi-directional IPv6 internet access, we can set that up using the standard internet gateway, but it requires a little bit of configuration. So what about the Subnet A here? It's our private subnet. We don't want anything out on the internet directly talking to it, but we still wanna provide internet access for things that live inside that subnet. We can come over to our public subnet and we can define something called a NAT, network address translation.

13:42If we define a NAT gateway, then resources in our private subnet can go through our router to our public subnet to our NAT Gateway, where the NAT Gateway acts as kind of a middleman and then makes an internet request using a public IP address, and then returns that request to the private address. Okay, finally, I think it'll make more sense once we get in there and start setting things up.

0:00Now here we are logged into our AWS console. I'm using my IAM account that we created in our first skill. I'm not using root, there's no need to use root, you really shouldn't use root as your daily driver account. And I happen to be landed in the region of US East One, and that's based in Northern Virginia. Now, I typically don't use US East One for my workloads for a couple different reasons.

0:31First is it's not the closest region to my home or my business. And then the second is that US East One was one of the first regions brought online. And I've heard kind of informally from some AWS resources that that region has a lot of stuff, there's a lot of workloads running in that region. So I would tend to want to put my workloads in a region that may not be so utilized.

1:04Typically I'll use US West two, which is out in Oregon, or I'll use US East two, which I believe is near Columbus. Now keep in mind these regions are comprised of availability zones, typically three or more availability zones. And those availability zones are the physical data centers that our workloads live in. And they're tied together with high speed lines and so forth. So as long as we work within a single region, we really shouldn't have to worry too much about latency or anything like that.

1:39So I am going to switch over to US East two, and I'm going out to the VPC console. And so this is our VPC console. We have our various options over here on the left. One thing you'll notice is if we go into your VPCs, hey, wait a second, we already have a VPC. Well, yeah, that's the default VPC. Now every account when it's created gets a default VPC in every region, or at least most all regions that you have enabled.

2:11And this is used for some of the various wizards and one click setups that the other services use. Now some people delete the default VPC because they just get itchy because they like a clean workspace. I typically just leave it alone, because like I said, some of the other products, especially new products that they get released will have a quick start. And if you delete that default VPC that quick start script is expecting that default VPC to be there and it could error out.

2:49So for my purpose, I just forget about it and leave it there. Okay, we're going to create a VPC, and at this point I'm just gonna create a VPC only. I'm gonna call this my VPC. And now we're asked to allocate our IP block. And I'm going to use 10 dot one dot zero dot zero slash 16. So that's gonna give us a network that we can use, these first two numbers are going to be fixed, that's part of the network, and then we can use these other two numbers to dole out IP address ranges, and you'll see that in a second.

3:35So here's where we can define our IPV six block. I'm not going to use IPV six in this VPC. Then we come to tenancy. By default, our systems are set up our VPC configuration, it lives in a virtual sense on a physical machine, Now because it doesn't really make sense to have each customer have their own dedicated physical machine, AWS of course shares these physical machines across several customers.

4:07We don't have access to those other customers activities or data, but our configuration, our systems may be running on the same physical device as somebody else's, that's by default. Now, if we wanted to force our stuff to run on its own dedicated physical machine, we could do that too. And some cases you may have regulatory requirements that necessitate this. Maybe you're concerned about any sort of hypervisor level viruses or something like that.

4:42Typically I just do default. There's special cases where you might wanna do dedicated, but we're not in one of those cases right now. We have our name down here, it automatically creates that tag from up here. And if you remember in a previous video, I recommended getting in the habit of tagging your things. I'm gonna create a project called or a tag called project. And I'm gonna say this is VPC skill. And this is just a good habit to get into, because you can use tags for all sorts of things.

5:19And one of the things that I could do here is I could pull up all the resources that have this project VPC skill and if I wanted to shut that stuff down, I could do that. We'll look into tags more later, but just I would suggest getting in the habit of putting tags on there. You could put a cost center, you could put a department, maybe an owner, as a matter of fact, that's a good idea. I'm gonna owner and I'm gonna put my name here. That way if somebody is stirring around out here and they say, "What in the world is this VPC?"

5:51They can look up the tag, owner Scott, call me up, slack me and say, "Hey, what is this? "Do you still need it?" So I'm gonna create VPC. And there we have it, our VPC has been created. Now there's a few things of note here that we wanna check out. First of all, let's go into actions and then edit VPC settings. Now these are some of the settings that we have for our overall VPC. Now mind you, this is the overall VPC, not the subnets.

6:21But one of the things we can decide is whether or not we want those subnets to be able to provide DNS resolution, by default, this is turned on. And there are some cases where maybe you don't want to allow that, maybe you want to stand up your own DNS server. You can turn that off and then that would not have those resources do that DNS resolution in those subnets. Another thing that we can turn on is enabled DNS host names. Now this will assign a host name to the resource when it gets launched that is publicly resolvable.

7:01Typically I will leave this off, but I'll just turn it on here in this case. We can also turn on some network address usage metrics, which may be useful in trying to analyze the flow of traffic and so forth. If you recall before, I mentioned that we have some options in the DHCP option set, I'll go over that later. But for now, we're just going to use the default option set and I'm gonna save that.

7:33If we go down here, we can see our IP address range that we set up. Flow logs are, think of flow logs as just logs of just raw logs of all the traffic coming in and coming and going around our VPC. Now if there's cases where we need to troubleshoot some things within our VPC, these flow logs are are really useful for that. I'm not gonna turn it on right now. We'll maybe turn it on in a later skill as we learn how to troubleshoot some of the things that can go wrong with VPC's.

8:09And here are our tags. Okay, so that's really it. So if we go back to our VPC's, you can see my VPC right there. One of the things that I like to do is use this little dropdown and select just my VPC. And then as we build out the components of this VPC, it's just gonna show the stuff that's relevant for this VPC. So next I'm gonna create some subnets.

8:39Create subnet. I have to select my VPC. Okay. Now one of the things that I like to do is I like to name them based on which AZ they are in. Now we can just create one and it's gonna randomly assign us an AZ, but I like the control over knowing which subnet lives in which AZ. Now remember as I said in a previous video, my US East two A may be different than your US East two A from a physical location standpoint.

9:14So we can't rely on that. But even still, I like to know where my stuff is logically, US East two A, and then I'm going to put that in US East two A. And then I'm going to give it this block of addresses. I'll give it one dot zero slash 24, that's gonna give us supposedly 256, but remember those reserved addresses, so we're not gonna have access to all of those.

9:54And one thing you'll notice is that it will pull up previous tags that we've created. This is kinda handy because then you don't have VPC skill with camel case or any sort of other punctuation or capitalization. You can kind of enforce some consistency there. There is a another way that we can really enforce consistency, and we'll show that when we start talking about multi accounts where we can impart some rules on tagging that will force some standardization, which is really handy.

10:29So I'm gonna again, put my name here, and then I'm going to create my subnet. Okay, so there is my subnet. Now I'm gonna create two more for the other AZ's. Okay, there we go, Ive created two more. I've named them corresponding to the AZ that they happen to live in. And if we scroll all the way out here, you'll notice that they've been assigned a route table, which we'll talk about next.

0:00Okay, so now we have three subnets. We have one in each AZ of the US-East region, and we go to route tables. And here's the default route table. Now, by default, we just have one route in here. And this, all this does is it routes our local traffic. It communicates between these different subnets. It allows us to transverse from one subnet to the other subnet and vice versa.

0:35And because it's our only route and it is our main route, then we don't have to explicitly assign subnets. So everything within this IP range is caught by this route entry. Now, let's say that we want to create a subnet, one of our subnets. We want that to be public, and we want the other ones to be private. Well, what I like to do here is, let's say, let's pick US-East-A and we're gonna make him the public one.

1:15And this is just a name, it doesn't instantly make it public or private. A subnets, a subnets, a subnet. It's just how we configure it, okay? So just to help me remember which is which and which one I'm gonna make public and private. I'll change the names. So US-East-2A is gonna be public, and these are private. Now, here's how we make that happen. So we have our main route table here. It's taking care of routing all the traffic amongst the three subnets that we have.

1:47Now we have that public subnet that we want to provide access to get out to the public internet. So we're going to have to create a specific route table and explicitly assign that subnet to that route table. But before we do that, we have to create a way to get out to the internet. And to do that, we're gonna create an internet gateway. And it's really simple to create an internet gateway. And I'm gonna add my customary tags here.

2:21Okay, and there we go. It has been created, but it's detached. We have to attach it to a VPC. So I'm gonna go up here to attach, I'm gonna select my VPC, attach my internet gateway. So now we have attached this internet gateway to our VPC, and that's going to allow us to route traffic to the internet. So as I said, this is our main route table. It takes care of all the traffic in and among our three subnets.

2:52But if we created a route inside this main table to the public internet, that would allow our other two private subnets to get access and vice versa, traffic could come in. So I don't wanna do that. I wanna wall them off. I wanna keep them private. So I'm gonna create a separate route table, and I'll just call it public route. And again, customary tags.

3:24Okay, there, I've created a route table. And you'll notice it has our route in there, but I'm gonna add a route. And the route that I want is 0.0 0.0/0. That's basically, if the traffic doesn't match this as a destination, if it's trying to go anyplace else, it's gonna follow this route and we can tell it where to go. Now, if you remember, we had this concept of an egress only internet gateway that's used for IPv6.

3:57We have an instance, we have an internet gateway, we have a NAT gateway. All these other options here. A peering connection, a transit gateway, and we'll cover that later. I wanna use internet gateway and it auto detects that I already have an internet gateway attached to my VPC. I'm gonna select that and save my changes. Now, this particular route table has the ability now to send traffic out to the internet and receive it back. Now, for me to actually use this, I have to explicitly assign the subnet that we wanted to make public.

4:34So I'm going to edit the subnet, select that guy. And so now you'll notice that this particular route table has been explicitly assigned to this subnet. What that means is we've told this subnet to use this route table instead of the other one, whereas these subnets are still using that main one, that first default one that has no route to the public internet.

5:07So that is creating our first VPC, creating our subnets, and we've created a route table to allow one of those subnets to be public and the other to be private. And we've also created an internet gateway. I'm gonna wrap up this video now, and then next we're gonna go into some of the other options that I talked about, including the DHCP option set, what's an elastic IP, some of the managed prefix lists and endpoints and so forth.

0:00Okay, continuing along on our VPC exploration, we've already created our VPC, we've created our three subnets, we've placed them in different AZs. We've decided that we wanted to make one of those subnets a public subnet and the other's private. So we attached our internet gateway and a route to that internet gateway, to that public subnet. Now we can explore some of the other options that we have. If you recall, when we initially created our VPC, we had the option to choose which DHCP option set we wanted.

0:35And if we wanted to customize these things, we could, we could give it a name up here. We can configure a custom domain. Maybe we wanted to use a domain of our own creation. Maybe we've registered our own domain. We can specify domain name servers, either via IPv4 or IPv6. We can specify NTP servers, which is network time protocol servers, NetBIOS name servers, NetBIOS node types.

1:05And that's pretty much it. We don't have a whole lot of options, but if your use case requires for you to define an NTP server and NetBIOS or domain name server, this is how you would do it. Moving right along, elastic IPs. So elastic IPs are fixed static IP addresses that we can assign to certain resources. And by default, whenever a resource comes up in a subnet, it's going to get an address using DHCP.

1:39But sometimes we don't want a randomly assigned DHCP address. We want a fixed static address. And this is how we can allocate elastic IPs to certain resources. Now, we'll get into this later when we stand up some other resources, but I just wanted to mention it here. We have managed prefix lists. Prefix lists are maintained lists of IP addresses that AWS uses for various services.

2:11Some of these are based on whole networks. Some of these are based on individual IP addresses. And AWS keeps up with this. So where you might use some of these is if you were trying to get to a certain service and you wanted to be absolutely sure that that route took the best path, and it went to the destination that AWS says is indeed that service. Now, these come into play a little bit more when we talk about endpoints and endpoint services, which we're gonna talk about right now.

2:44So endpoints are pretty interesting, and I wanna show you, I want to draw a little diagram that shows you how they work. Okay, so here's how endpoints work. We have our AWS network, our universe of AWS. We have our VPC inside a region inside that AWS network. And there are other services that live inside the AWS network. In this case, I've created a little DynamoDB service here. So if we wanted to call, if one of the resources inside the subnets wanted to call the DynamoDB API, or maybe send some data to it, by default our connection would be out to the internet.

3:28So it would go out here, go out to the public internet, and then loop back around and come back in the front door of AWS hitting that API. Well, there's a better way. There's a more secure way that we can do this. We can set up an endpoint inside our VPC. And what that is, is that's kind of like a little tunneled connection there within the AWS network, kinda these back alleys. And we can call that API from within our VPC and our traffic never goes out to the public internet, which is pretty handy in two ways.

4:10Number one, if you don't have to send something over the public internet, you probably really shouldn't. And number two, there's less things that can go wrong with that connection because we're using the built in functionalities of AWS's backbone itself. So that's what an endpoint is. So just as an example, I'm gonna set one up for S3. So I'm going to say this is my S3 endpoint and I'm gonna use AWS services.

4:46I wanna show you something unique about S3 and DynamoDB. So one of the things you'll notice here is that we have different types of end points. One being an interface and one being a gateway. What's the difference? Well, an interface uses something that AWS calls private link. So if you hear private link, that's just their trade name for their kind of back channel paths to services that use the AWS backbone and to implement it, it uses in essence DNS trickery.

5:26It makes a DNS entry into your subnet DNS that will point name resolutions to the internal IP addresses of those services. Now, a gateway's a little bit different, and right now there's only two services that use the gateway endpoint, that's S3 and Dynamo, and they use prefix lists, which we talked about earlier. All in all, we don't really need to worry about what type it is because as soon as we add it to our VPC, then AWS takes the necessary measures to implement it.

6:03So I'm gonna choose the gateway, and I can select my VPC. I'm gonna choose my VPC, and it's asking me, which route table do I want to put this in? I'm gonna put it in both route tables. And the reason for that is because if I put this just in the main route table, the default route table, it only has our two private subnets associated with it. Whereas I also want any resources in my public subnet to take advantage of this same kind of more secure path to S3.

6:39And I can customize it with various policies. But I'm not gonna do that. Remember my habit? I'm telling you, you probably thinking this is a hassle right now, but there will come a time when you're gonna say, oh my goodness, thank you so much for getting me into that habit. Okay, there we go. So if we go back to our route table here, we can look at both of them. We see our routes and you see we have a prefix list that's been created for us with a target.

7:23And this is our special route to S3. So the endpoint services, let's say you're a company that provides services or maybe you know, some sort of SaaS offering to other companies. You could create your own endpoint and allow other AWS customers to attach to that endpoint just the same way as we just created an endpoint for going to S3.

7:57So all the data stays on the AWS network. It's all safe and secure that way. We're not gonna do that because we don't have any services that we want to publish. NAT gateways, if you recall from our earlier video, NAT gateways are used when we want our private subnet resources to be able to reach the public internet. So what I can do here is create a NAT gateway, my NAT gateway, And then I have to choose a subnet.

8:31Now, this subnet has to be a public subnet because this NAT gateway has to basically touch both worlds, both private and public. So I'm gonna choose this public, connectivity type public. Now, there are cases where you would use a NAT gateway in a private network. Let's say for example, that you had two companies that came together. They merged. They need to be able to tie their networks together. But oh shucks, they happen to use the same identical IP ranges.

9:03In that case, rather than trying to renumber one of the company's IP addresses, you could use a NAT gateway between as a go-between to allow one network to talk to the other network. And this NAT gateway would just kind of translate things. We need to assign an elastic IP. This will be the IP address that the NAT gateway will use. We can just click on assign and it creates it for us. And our NAT gateway is created.

9:35Now to allow our private resources to use this NAT gateway, we have to create a route for our private subnets to reach it. So I go back here to my route tables, I'll go into my default. As a matter of fact, I'm just gonna change this here. I don't know, I have a thing about just blank names. I like everything to have a name. Okay, call me crazy. All right. So you can see the routes here. We have our endpoint to get to S3 using kind of the back channel ways.

10:08And we have our route to get to the other subnets, including that public subnet. But we have no route to get out to the public internet. But we don't want this particular set of subnets that we're gonna be dealing with to get out to the public internet. So we're going to edit this route, and I'm gonna put in the default route of 0.0.0.0 and then we're gonna send that to a NAT gateway.

10:41And the console recognized that I already have a NAT gateway out there. So I'm gonna specify that and then save changes. So what we have now for the subnets that are associated with this, which implicitly are these two, but I'm just going to go ahead and add them explicitly. So for these two private subnets, they're going to use this collection of routings.

11:13Number one, if we're trying to go to S3, it's going to use this route that does not go out to the public internet. And if we're trying to get to the other subnet, it's gonna use this route. But for anything else, it's going to use this NAT gateway that we set up that lives in our public subnet. So now our resources on that private subnet can get access to the internet. Now, peering connections. Peering connections are how we can link VPCs together, either within the same region or across regions.

11:50We're not gonna do that right now, but just know that you can create a peering connection to allow VPCs from different companies, different regions. You can create this connection where you can specify some routing rules and then you can pass traffic back and forth between them. And here's how this works. You can create my peer and I select a VPC.

12:22Let's say I wanted to peer my VPC with some other account. I have to enter the account, maybe it's in another region. I can specify that region, but I have to know the VPC ID. So I would get that information from either myself by looking it up in the other region or whoever I'm trying to peer this with. And you would create that peering account. It would send a request to whoever the account is, it pops up right here on this, here let me cancel outta here.

12:55Pops up right here on this dashboard. And they have to explicitly approve that before that connection becomes a possibility. And then once it's a possibility there, then you would set up some routes to move traffic between the two. Okay, so that's about it for this particular video. Next we're going to go into network ACL's and security groups.

0:00Okay, let's talk about network access control lists and security groups. So we're out here at our VPC console page, and we can scroll down to network access control lists, network ACLS. And you can see we already have one network access control list set up for us, and that was created automatically as part of our VPC creation process. But I will say that most people do not use this default rule at all, and here's why.

0:30So if we go to the inbound rules, these rules are listed. You create these rules and the rule processor, the rule engine that tries to process and interrogate traffic as it's coming by, executes these rules in numeric order. And so we have this rule number 100, all traffic, all protocols, all port ranges, coming from anywhere is gonna be allowed. And oh, by the way, if you don't match that criteria, we're gonna deny you. Now deny is always the end, or it should always be the end here because you always wanna explicitly deny anything that doesn't match your criteria.

1:06But in this case, everything's gonna get through, this is an inbound rule, everything's gonna come in from the internet if it's trying to get to our resources. And for the outbound rule, it's the same thing. Now, this is probably less egregious, I guess, because it's outbound, but as you can see, by default this rule has been associated with all of our subnets. Well, let's say in our scenario, we only want web traffic, maybe HTTP and/or HTTPS, to come in inbound from the internet.

1:44So what we need to do is we need to create a network access control list that will allow for that. So we can go up here to create list. I'm gonna say allow HTTPS. We're gonna select our VPC and add my customary tags and create. Now we can define what we want, our rules. Oops, get rid of that guy, move some stuff around, there he is.

2:21Now we can define what we want our inbound rules to be. I'm gonna edit inbound rules. We go 100 and it has a lot of the well-known ports already here for you. You can specify UDP, TCP, ICMP, you have quite a bit of functionality here. So I'm gonna pick HTTPS protocol, TCP 443, the source is anywhere, that's fine.

2:54Gonna add another rule for HTTP port 80 coming from anywhere. That's all well and good, save changes. So now I've created my inbound rule that only allows certain port traffic. Now, you might also want to put port 22, which is SSH, to allow you to get in maybe over the public internet into your EC2 resources. But I'm gonna show you a way in a later skill that's much easier, I think, and much more secure, that doesn't require you opening up port 22 to the world.

3:36Now with outbound rules, right now, by default, it's not gonna allow anything outbound. So we probably want to change this. Now, if we had a really good understanding of exactly what ports we needed to open for outbound, we could lock this down. But there's something that you might want to remember when you're trying to lock down these outbound rules.

4:07And that is that a lot of transactions, a lot of protocols, for example, TCP, UDP, and I think also streaming control transmission protocol uses something called ephemeral ports. So initially they'll make a connection over the well-known port, say it's maybe 443, but then as soon as that handshake is done and that connection is made, then they switch to an ephemeral port, which is one of the high end ports on the port range, and oftentimes those are completely random.

4:45So if you are intent on messing with your outbound rules, I would suggest creating a rule for ephemeral ports, maybe over port 1024 or something like that. Especially if you wanted to try to really lock down your well-known ports, but just keep that in mind. So now we need to associate this with a subnet. Now a subnet can only have one network ACL assigned to it at any one time.

5:16So the fact that we're going to assign this network ACL to this public subnet means it's going to unassign that wide open, kind of scary network access rule. It is now assigned. And now if we had anything in that subnet and we were trying to reach it from the internet, if it wasn't trying to reach us on port 80 or port 443, we would not be able to reach it.

5:47Let's move on to security groups. I don't wanna spend too much time on security groups here because they're kind of hard to understand if we don't have any resources to assign them to. So we're gonna put that off till a little later. But for now, I just wanted to mention it so you're not left wondering what they are. Now, if you think of network ACLs, those are more broad, those are kind of at the network layer or network level. Security groups are more granular. They're designed to be applied to various resources inside those networks.

6:20So it's a little bit more fine grained permission. Now, by default, just the act of creating a VPC, it creates a default security group. And again, people typically don't use this default security group, but here's what it says. It has the same inbound and outbound type format as the network ACLs. We can go here and edit the inbound rules and we can see that this particular rule says it's gonna allow all traffic, all protocols, all port ranges from, and look at this, this is pretty interesting, this is the name of the security group.

6:56You can see up here, right there. So why is this special? Well, what this means is that in this default rule, at least, if we assign this default rule to a resource, then we assign this same default rule to another resource. Well, because those two resources are in the same security group, they're gonna be allowed to communicate between one another, with whatever traffic they want to talk to. Now, if there's another resource in that same network that does not have this security group or assigned a different security group, there's no talking, there's no communication.

7:35So you can see how this can be kind of useful. And how I like to use security groups is if you look at it maybe in a three tier app layer, where maybe you have the web server, you have an app server, and you have a data store of some sort, I'll create security groups along those three lines. And then I can specify, okay, the web server can only communicate to the app server, the app server can only communicate to the database and vice versa. And that helps me kind of hone in on my open ports or possible security threats by just telling certain machines you can only communicate with those other machines that you must communicate to, but we'll see that in action later.

8:21Same thing for the outbound rules here. If we edit the outbound rules. Now this is a little bit different, we're in this particular security group, we've said that at least default settings is all traffic is allowed for everywhere. And you know, I think AWS just does this because they've had their fair share of people calling in to support saying, hey, I can't figure out how to use my security groups, it must be broken, or something like that. Well, a lot of people get a little overzealous in trying to lock down their ports, they may not fully understand what ports their application uses, especially in those cases where ephemeral ports are being used and it doesn't work.

9:00So that's my advice to you, just remember those ephemeral ports and know that security groups and network access control lists are pretty handy and powerful ways of locking down your network.

0:00All right, let's put some of our VPC learning to the test. Now it's time for a challenge, and that challenge is this. I want you to try to build a VPC network to these specifications. For starters, you should have three private subnets that can all communicate amongst one another. Then, we also want a public subnet that we're gonna call our Web Farm, and that subnet can only communicate to the app server's subnet. Now, there's some resources in the app server subnet that need to get out to the public internet, but that's a private subnet, so we're gonna have to implement NAT there.

0:38Now, on the public subnet side, we only want to allow port 25 inbound, but all the other outbound traffic is just fine. We wanna allow that. We also want to establish a really secure connection between the database subnet and DynamoDB. We don't want that traffic going out onto the public internet, so try to recall how we might do that. Now, to distribute their risk, our client wants the private subnets to all be on different AZs, but the Web Farm must share the same AZ as the app servers.

1:14And then finally, for the testing subnet, the client only wants to allow port 22 inbound. I'm gonna make this diagram a downloadable file right below this video, so you can take it offline. Maybe you wanna go brainstorm with some colleagues or see how many different ways you could build out this particular network and still accomplish the objectives here. So, hopefully the gears are starting to turn and you're getting some ideas on how we might build this out for our client.

1:44Go ahead and give it your best shot and in the next video, I'm gonna show you how I approach this particular challenge. Not saying that that's the only way or the best way, but the whole idea here is to give you a chance to try this on your own and then see how you fared if you run into difficulties. My solution is always there to help you out.

0:00All right, let's get started. Now, before I actually start building anything out, I like to just whiteboard it and come up with a strategy of how I might approach this particular problem. So I can say that this is going to be our VPC. We're gonna have an internet gateway right there. And because we also are using NAT, we know that we're gonna need a NAT gateway in that public subnet. Now, one of the other requirements is that each one of these private subnets has to be on a different AZ.

0:37So I'll put this one on AZ1, I'll put this one on AZ2, and AZ3. Now we also have the requirement that our public subnet, our WebFarm has to be on the same AZ as our AppServers. So this will be AZ2. Now we also have some port restriction requirements here. So we only want public internet port 25 inbound to our WebFarm here.

1:09Kind of weird if this is a WebFarm and we're only letting in port 25, but whatever, the customer is the customer. So we can restrict that with a Network Access Control List for port 25 inbound. Now, the same thing with our private testing subnet. We can restrict that with a Network Access Control List for 22. And the reason we'd use a Network Access Control List rather than a security group is because we're talking about kind of the whole network, the whole subnet versus just individual resources.

1:49So network ACLs are generally better at that. Now this is going to be an endpoint to allow us to securely access DynamoDB from the database here. And one thing to point out here is this requirement right here, one public subnet, WebFarm, can only communicate with the AppServer subnet. That means that we wanna restrict any traffic going to these other two.

2:20We don't wanna allow that. So what we can do there is we can use another Network Access Control List to allow traffic in and among these, but not for our public subnet. Okay, so I think we have a plan. Let's hop over into console and see how we can build this out. Alright, here we are logged into our AWS console. I'm using my IAM user 'cause there's no good reason to use root for this.

2:52Gonna go under Your VPCs. And then the first step is gonna be Create a VPC. And I'm going to enter my IP address block. Now I'm gonna put a little poll down below. Some people call this Cedar, some people call it Cider. I guess it kind of depends on where you grew up, where you're coming from, but I'm curious to know what people prefer to call it.

3:24I've heard it used both ways. Create the VPC. Okay, now we need to create four subnets. That's what we're gonna do, okay. Now you know that I like to name my subnets based on the AZ that they happen to live in. So that's what I'm gonna do here. And we're gonna call this the Database subnet 'cause that's what one of our subnets is gonna be used for.

4:02Give it that IP address block. Create. Now I'm gonna create three more. Call this the AppServer.

4:50Okay, and we have one last one to create. And this is gonna be our public. And if you remember, we were asked to make sure that this public subnet for our WebFarm is on the same availability zone as our AppServers. Okay. Creating our subnets, there we go. So we have four subnets. Okay, now I know I'm gonna need an internet gateway, so I'll go out here and create one of those.

5:26And then we need to attach that to our VPC. And then I'm also gonna need a NAT gateway. So I'm gonna create one of those. And the subnet that we want this to land in is our WebFarm, which is gonna be our public subnet. Connectivity is public, allocate and allocate an Elastic IP, and then create the NAT gateway. And that's gonna take a little while to get spun up. Now we also want to create an end point for DynamoDB, but before that, let's create some route tables.

6:02So right now we have our default route table that implicitly handles all the subnets. And you know how I do not like stuff that's unlabeled. Gonna label that. I'm gonna create a new route table, and I'm gonna call this the public route. And this is gonna be how our public subnet gets out to the internet through our internet gateway.

6:33And we're gonna use our internet gateway, and there it is. Okay, so the one last thing we have to do here is explicitly assign it to our WebFarm. So for this particular subnet right here, we have a default route to go out to the internet. So that's what we want.

7:05Now, there's one more thing that I'm gonna do. It's kind of optional, I suppose, because the requirements weren't explicit on whether or not we have to limit access to DynamoDB through our endpoint, via our database subnet. But I'm gonna create a route for the database subnet, and that's where we're going to add the endpoint or the prefix list to Dynamo.

7:41So we can do that right now. We go down to endpoints, we create an endpoint. Okay, and we wanna associate it with this route table. And there's one last thing I have to do back here at this database route. See if you can guess what it is, yep.

8:12We have to explicitly associate the database subnet. So now anything in that database subnet is gonna use this route table. So it's gonna go to, it's gonna use that kind of back channel path to DynamoDB. Okay, now let's create some port restrictions. So we're asked to restrict inbound into our public subnet, just port 25, which is SMTP.

8:53So I'm gonna create a network ACL, and once I find it here, for inbound rules, we're gonna edit those. We're gonna add a new rule. SMTP, and I think our requirements said from anywhere. So we'll save this. Now because this is, we're going to be applying this to our public subnet, we also need to be sure to think about outbound rules as well.

9:31And if you recall, AppServers use this NAT gateway. And so that traffic needs to be able to go out. So because we don't know specifically what traffic it is, we're just gonna allow all the traffic to go outbound. All right. And now we can associate this Network Access Control List with our WebFarm.

10:03And there, we've just applied restriction that only allows port 25 inbound, but any traffic can go outbound. Now we're also being asked to create a network ACL for port 22 into our testing environment. So I'm gonna create one called allowSSH, edit the inbound rules.

10:37Okay, and I believe it was from anywhere. So we'll save that. Can't forget about the outbound as well, 'cause if once we apply this, if there's no outbound rules, then anybody, any resources inside that testing subnet won't be able to get to our other subnets. And I think that's probably not a good thing because we wanted to have the subnets be able to communicate with one another.

11:07And again, 'cause it didn't specify which traffic or which ports, we're just gonna allow everything. All right, now we need to associate that with our testing. And there we go. All right, there's one other thing that we can use Network ACLs for. And if you recall on the requirements, we were told that the public subnet, the WebFarm and the AppServers were able to communicate to one another, but they should not be able to, the WebFarm should not be able to communicate to either the database subnet or the testing subnet.

11:50And one of the things to know about Network ACLs is that subnets can only have one and only one Network ACL assigned to them. But we can use Network ACLS to prevent traffic coming in from that public WebFarm origin. And we can do that pretty simply. So let's go to Subnets here. Let's recall what the IP address range is for that. So here's the IP address range for our WebFarm.

12:21So it's 10.0.4.0. Okay, so if we go back to our NACLs, so this one is rather than call it SSH, I'm gonna call it testing. So this is our allow list for testing. For the inbound rules, I mean, we're pretty restrictive. We're only allowing port 22, which is what we required, but the source is anywhere. So it is possible, it is within the realm of possibility that we could have something on that WebFarm, that public subnet, and then it's trying to get into this testing subnet and it's using port 22.

12:59So what we need to do is we can add a new rule and we're gonna make this new rule appear before this rule. So we're gonna say all traffic from 10.0.4.0/24, which is that whole network, Deny. Now let's look at what we have.

13:31So any traffic coming from this source is gonna be rejected, denied, even if it is port 22, because this is the first rule on our list. Now we need to do something similar to protect our database subnet. Just call it protectDatabase. Again, you can name these whatever you want. I would recommend coming up with a naming scheme, especially if you have a bunch of people in here doing this stuff.

14:04Okay, so for the inbound rules, I'm gonna do this a different way just to show you an alternative. So I'm gonna specifically allow only certain networks in, okay, I don't have to do one, I forgot about that. 'Cause this is for network one. Two is our app servers, three is our testing. And so what I'm doing here is allowing traffic from those two subnets in.

14:36And anything else from the WebFarm, for example, is going to be denied. So that's just a little different way of doing the Network Access Control Lists. But what I do have to do is associate that with the database. And there we go. Now I think we have one last thing to do. Our NAT is set up. Let's go back to our route table.

15:06And so our public route is taking care of our WebFarm network. We need to create a route for our NAT on our AppServer routes. So I'm gonna edit the routes. I'm gonna say anything going to the default route, I want you to go through the NAT gateway. And then I'm gonna associate just the AppServer with this private route.

15:43And I believe we have completed our task. And again, if you did it a different way, there's probably a dozen different ways to do this. Doesn't mean it's wrong, especially combining route tables and Network Access Control Lists and maybe use security groups. There are many different ways to accomplish the same objectives. So the intent for this exercise wasn't to be right or wrong, it's just to get you in there and get familiar with the different parts and pieces and how you can take this abstract requirement and then turn that into a set of steps to help meet business needs.

0:00Well, congratulations on making it through another skill as we make our march up that AWS learning curve. In this skill, we learned about VPCs, subnets, both public and private route tables, network address translation gateways, internet gateways, elastic IPs, DHCP options, prefix lists, security groups, and a lot more. But we've really only just scratched the surface on what we can do with AWS Networking. That stuff we'll cover in a later skill, but for now, we got a pretty good baseline.

0:32So I hope you found this video informative, and thank you for watching.