Building Networks on AWS

0:00<v ->Welcome back, all you beautiful learners.</v>

0:01My name is Scott Fletcher,

0:02and in "This Skill",

0:03we're gonna dive into Amazon VPCs

0:06or virtual Private Clouds.

0:07Now, this isn't the networking specialty course,

0:10so we're not gonna go ultra deep,

0:11but as a SysOps Admin, you are gonna need

0:14to know something about how AWS does networking,

0:17and how to set it up and how to troubleshoot it.

0:20But before that,

0:21I wanted to share with you a perspective

0:24that has helped me over the years,

0:26especially when I go to learn something new.

0:30Now, I recognize that people are probably

0:33coming to this course with a variety of

0:35AWS backgrounds,

0:37whether you're just getting started

0:39or you've been using it for years,

0:41and chances are you're taking this SysOps course

0:44because you want to learn

0:45more about how AWS does SysOps.

0:48Your knowledge,

0:49let's just say maybe is starting right here,

0:51and you're hoping for some trajectory like this.

0:54Two psychologists by the name of Justin Kruger,

0:57and David Dunning did a lot of research

1:00on how people self-assess

1:03their knowledge when they're just

1:04getting started in a new learning journey.

1:07What they found is many people overestimate

1:11where their starting,

1:12maybe their real starting point is down here,

1:16and they're going to

1:16take some trajectory like this,

1:19and that's the crux of Dunning-Kruger.

1:20It has nothing to do with your intelligence

1:22or your abilities or anything like that.

1:25Well, let's look at how this can really

1:26mess with our minds.

1:28On one axis here, we have confidence,

1:31and on the other axis,

1:32we have experience, our knowledge,

1:34our our practical ability

1:36with in this case our AWS platform,

1:38and our AWS skills.

1:40And with that Dunning-Kruger Effect at play,

1:43we might overestimate our abilities early on.

1:48And then we come to that inflection point,

1:50and then we realize,

1:52"Wow, we really don't know as much

1:54as we thought we did."

1:56And then maybe our confidence

1:57just plummets down into this,

1:59what some people call,

2:00the Trough of Disillusionment.

2:02And in this Trough of Disillusionment

2:04or Trough of Despair,

2:06I've heard it called several different things.

2:08There's some pretty negative thoughts

2:10that live down here.

2:11Imposter Syndrome.

2:12We might think,

2:14"Hey, we're not good enough.

2:15We're not good enough to complete this course."

2:17Or, "We're not good enough

2:17for that certification."

2:19Or self-doubt.

2:20"Wow, there's so much.

2:21I don't know and I feel like a fool."

2:24But the reason I'm sharing this stuff with you

2:27is because this is all very, very common,

2:31and I don't want you to feel bad

2:33if you have these feelings.

2:35This is part of many people's learning journey,

2:39and learning experience,

2:41and that's what I wanted to share with you.

2:42There's probably gonna be points in this course

2:44where you're gonna feel overwhelmed.

2:47Things just don't make sense.

2:48It's like I'm speaking a foreign language.

2:50Stick with it.

2:52Work hard, do the exercises,

2:54and you're gonna get there.

2:56You can do this.

2:57You got this.

0:00<v Instructor>Okay, let's start with some white boarding</v>

0:01or I guess black boarding in my case.

0:04So in the AWS universe, at the highest level we have AWS.

0:09And within this AWS universe, there's all sorts

0:12of networking, tying all these services

0:15and all these places together.

0:16Now, from that top level, AWS is divided into regions.

0:20Now there are regions on pretty much every continent,

0:24and these regions have names like US East 1 for the region

0:30that's based in Virginia

0:32or EU West 1, which is based in Ireland,

0:35and AP South 1, which is based in Mumbai.

0:39And you can see these regions if you do the dropdown

0:43on the console, the little dropdown on the upper right.

0:47And for the most part, AWS services

0:50live within these regions.

0:52It's the same service,

0:54it's just replicated across all these regions.

0:57There are some services though, that are region independent.

1:01In other words, they're global in nature.

1:04And some examples of that are IAM or identity

1:07and access management, S3, which is Global Object Storage.

1:12And Route 53, which is the managed DNS service.

1:15It just doesn't make sense to have region specific versions

1:19of these services.

1:21Now, if we dig into that region,

1:22we have further subdivisions.

1:24We have availability zones or AZs,

1:27and these availability zones, think of 'em like

1:29little data centers within that region.

1:32They're spread apart geographically so that if there's

1:35some sort of disaster that affects one area

1:40of the region, it doesn't take down the other AZs.

1:44And these AZs are all connected with all sorts

1:49of high speed data networking.

1:53And for some AWS services, we can choose

1:56to deploy those services in a single availability zone

2:00or a single AZ, or a multiple availability zone

2:04configuration, meaning that there's copies of that service

2:08or that data in multiple AZs.

2:11And of course, doing so increases our fault tolerance

2:16and we'll talk about that in another skill.

2:18But for now, I wanted to get you familiar

2:20with this concept of availability zones,

2:23because it comes into play when we start talking about

2:25virtual private clouds or VPCs.

2:29So we will go into a region, we're gonna go

2:31to the VPC console within that region,

2:34and we're gonna define a logical construct known as a VPC.

2:39Now by themselves, VPCs live at the region level.

2:43And this is a little bit different.

2:45If you've ever worked in Azure,

2:47their VPCs are more global in nature

2:50and then you can define resources within regions

2:52inside that VPC.

2:54For AWS, the VPCs are defined at the region level.

2:58Now of course, there's ways to get those VPCs to communicate

3:01to other VPCs in other regions, and we'll cover that later.

3:04But for now, know that VPCs are just tied to a region.

3:08Now, within that VPC, we can define different subnets,

3:13and these subnets are where our resources are gonna live,

3:17at least our IB based resources.

3:20Now, back to the AZs.

3:23The AZs are usually named after the region,

3:26and then an A, B, C, or D, depending on how many AZs

3:31are in that region, it's just tacked on at the end.

3:33Now, an interesting fact here,

3:36although these availability zones are physical buildings

3:39with racks and racks and racks of computers,

3:43the location defined as US East 2A in my account

3:47may be a different physical location than that

3:51which is defined as USE East 2A in your account.

3:55When your account is created,

3:57AWS randomly assigns these values, the A, B, C, and D

4:01to the physical locations for each account.

4:04And the reason AWS does this is they don't want people

4:07to tend to always choose USCs 2A,

4:11and then everything would be going to 2A

4:12'cause psychologically, some people just, "Hey,

4:16I'm gonna choose the first one that being A,"

4:19so AWS gets around this by randomly distributing

4:22A, B, C, and D.

4:23So that's why if you're working across accounts,

4:27don't necessarily assume that 2A is the same

4:30as this other account 2A, we have ways

4:34that we can ensure that we're gonna place

4:37our equipment together, but we'll get into that later.

4:40So back to our VPC, we're gonna define subnets,

4:45and then we have to assign a certain AZ to that subnet.

4:49Where is that subnet going to live?

4:51So we might define a subnet here

4:56and maybe we will put one here.

4:59And then in that case we have a subnet in US EAST 2A

5:04availability zone,

5:05and we have another subnet in US East 2C.

5:09And so if we deploy resources to either of these subnets,

5:12they're gonna be in physically different locations.

5:16Now I'm gonna reset the drawing

5:19and we're gonna zoom in a little bit more

5:20into the subnets and the VPC.

5:23Okay, this is a little different view.

5:25Think about that last diagram as this is kind of inside out.

5:27So we have the VPC at the region level, we have the subnets,

5:31and this little A and B indicates that one

5:34of the subnets is in availability, zone A,

5:37and the other subnet is in availability zone B.

5:40Now we have a routing table or a router

5:44that allows these two subnets to communicate

5:47if we choose to allow them to communicate.

5:52And additionally, we can define an internet gateway

5:54that allows us to communicate back

5:57and forth to the public internet.

6:00Now, people will often refer to subnets as either public

6:04or private, and that just means how we have them set up.

6:08We can define our routing rules to say that subnet A,

6:12for example, can indeed talk to the internet.

6:16Well, subnet B can't talk to the internet

6:20because we don't allow the traffic a path

6:23or a route to the internet.

6:25So in this case, we would consider subnet A

6:28as a public subnet and subnet B as a private subnet.

6:33And likewise, we can also set up a VPN, for example,

6:36between our subnet that lives in AWS

6:39and our own data center.

6:41Now, let me redraw this

6:44where we're zoomed in more on the VPC

6:46and we can look at some of its components in more detail.

6:49Now, when we create a subnet, we're gonna be asked

6:52what IP range do we want to allow it to use?

6:54Now, most commonly, people go with the private reserved

6:58IP ranges like 10.0.0.0

7:02or 172.16.0.0,

7:05or good old 192.168 network.

7:09You don't have to do that,

7:11but especially if you want your subnet to talk

7:15to the internet directly, then you don't want

7:19to be using somebody else's addresses.

7:21Now, your company may have a range of addresses,

7:24it's been assigned to them, and that's perfectly fine too.

7:26But generally speaking, most people stick

7:29with the private reserved addresses.

7:32Now, regardless of what IP range we assign to our subnet,

7:36there are some reserved addresses in there.

7:40Let's say for example, we're gonna configure one

7:42of our subnets to use

7:43the 10.1.1.0/24

7:46address range.

7:48If you're kind of rusty on your IP addressing,

7:51that's the equivalent of

7:52255.255.255.0

7:54as a net mask,

7:55which gives us 250 -ish addresses.

7:59And the reason I say that is

8:01because there are some reserved addresses

8:03that AWS doesn't allow us to use.

8:06And in this particular network range, those would be

8:1010.1.1.0,

8:13which is the network,

8:15and of course, 10.1.1.255

8:19which is broadcast.

8:20And then in this network,

8:2410.1.1.1

8:26this is all assigned by AWS internally.

8:30We really have no control over this.

8:32This is the VPC router, so that is this thing.

8:37We also have 0.2, which is our DNS server.

8:41And then finally we have .3,

8:45which AWS says is reserved for future use.

8:49So if you bring up a machine or a resource

8:51or something like that inside that subnet,

8:53you're not gonna get any one of these IP addresses,

8:56and you should not manually assign any one

9:01of these IP addresses to anything.

9:03You can cause some weird problems.

9:05Now, we do have some control over the DHCP options,

9:10and I'll show you that when we get to that point

9:12in the actual configuration.

9:14But we can define custom DNS servers.

9:16We can define an NTP server if we want to.

9:19We could set a custom domain name.

9:22We can even set a NetBIOS name server.

9:26And if you don't know what NetBIOS is,

9:28that's a Windows networking thing.

9:30I know, I know you're eager to get in there

9:32and roll your sleeves up and get building,

9:35but bear with me here,

9:36we got a few more topics to cover.

9:38And one of those topics is security groups

9:41and network access control lists.

9:44So network access control lists

9:46or NACLs as some people like to call them, define

9:51what port level traffic we're gonna allow in

9:55and out of our subnets and maybe in

9:58and out of our internet connections.

10:01It's IP based, we define certain IP ranges

10:05or a specific IP address, and we can say whether

10:09or not we can allow traffic to that.

10:11It's an allow or deny type thing.

10:14The other piece we have that we can work with

10:18is security groups,

10:19or you'll see 'em sometimes abbreviated SGs.

10:23Now security groups can be assigned to resources

10:27inside the subnet.

10:29What's useful about security groups is

10:32that we can assign security groups

10:35to use other security groups,

10:37and I'll show you an example later on.

10:40Okay, last thing before we get into some

10:43real hands-on stuff, we have several different ways

10:46to provide internet access.

10:48The most basic way is simply an internet gateway,

10:53and this just goes out to the internet.

10:59As long as we provide a route, typically

11:03it's 0.0.0.0

11:04/0

11:07In other words, the default route would go out

11:09to the internet and we can get that traffic back.

11:12Now, if our network access control list

11:15allows that traffic going outbound

11:18or inbound to pass, then we can provide that access

11:23to our public subnet.

11:24So let's say this was our public subnet,

11:31and we had resources in there

11:33that were assigned public IP addresses as well

11:36as a private IP address because everything

11:38in a subnet always gets a private IP address.

11:41That's how it communicates internally.

11:43But we also have the option a lot of times

11:45of also assigning a public IP address, that is an address

11:50that's typically in AWS's reserved range,

11:53and they would assign it to a resource in there.

11:56Therefore, that resource could directly talk

11:59to the internet in that case.

12:02Now, if we're using IPV 6,

12:04AWS has something called the egress only gateway.

12:14And that only allows traffic out.

12:18We're not gonna dwell on that option too much.

12:20It's kind of an advanced topic.

12:22Probably see that more in the networking specialty course.

12:25But just know that there's an IPv6 gateway

12:29that is egress only, meaning our resources inside the VPC,

12:35inside the subnets, can only reach out via IPv6.

12:40Now, why on earth would you want a one-way

12:42door to the internet?

12:43Well, for one security reasons.

12:46IPv6 addresses are globally unique and therefore

12:50we can use them on the public internet.

12:53So if I wanted to define a path for my IPv6 resources

12:57to get out to the internet to say maybe download

13:00some updates or retrieve some information,

13:03then maybe I don't want any IPv6 resources from

13:06the public internet getting into my VPC.

13:09That's the way I would do it.

13:11Now, if we want bi-directional IPv6 internet access,

13:14we can set that up using the standard internet gateway,

13:18but it requires a little bit of configuration.

13:20So what about the Subnet A here? It's our private subnet.

13:23We don't want anything out on the internet directly talking

13:26to it, but we still wanna provide internet access for things

13:30that live inside that subnet.

13:32We can come over to our public subnet

13:35and we can define something called a NAT,

13:40network address translation.

13:42If we define a NAT gateway,

13:45then resources in our private subnet can go

13:49through our router to our public subnet to our NAT Gateway,

13:52where the NAT Gateway acts as kind of a middleman

13:56and then makes an internet request using

13:59a public IP address, and then returns that request

14:03to the private address.

14:05Okay, finally,

14:06I think it'll make more sense once we get in there

14:09and start setting things up.

0:00<v Scott>Now here we are logged into our AWS console.</v>

0:03I'm using my IAM account

0:06that we created in our first skill.

0:09I'm not using root, there's no need to use root,

0:11you really shouldn't use root as your daily driver account.

0:15And I happen to be landed in the region of US East One,

0:22and that's based in Northern Virginia.

0:25Now, I typically don't use US East One

0:28for my workloads for a couple different reasons.

0:31First is it's not the closest region

0:35to my home or my business.

0:38And then the second is that US East One

0:41was one of the first regions brought online.

0:44And I've heard kind of informally from some AWS resources

0:49that that region has a lot of stuff,

0:53there's a lot of workloads running in that region.

0:56So I would tend to want to put my workloads

1:01in a region that may not be so utilized.

1:04Typically I'll use US West two, which is out in Oregon,

1:09or I'll use US East two, which I believe is near Columbus.

1:14Now keep in mind these regions

1:15are comprised of availability zones,

1:19typically three or more availability zones.

1:22And those availability zones are the physical data centers

1:26that our workloads live in.

1:27And they're tied together

1:28with high speed lines and so forth.

1:31So as long as we work within a single region,

1:35we really shouldn't have to worry too much

1:37about latency or anything like that.

1:39So I am going to switch over to US East two,

1:43and I'm going out to the VPC console.

1:46And so this is our VPC console.

1:48We have our various options over here on the left.

1:51One thing you'll notice is if we go into your VPCs,

1:56hey, wait a second, we already have a VPC.

1:58Well, yeah, that's the default VPC.

2:01Now every account when it's created

2:03gets a default VPC in every region,

2:07or at least most all regions that you have enabled.

2:11And this is used for some of the various wizards

2:16and one click setups that the other services use.

2:21Now some people delete the default VPC

2:25because they just get itchy

2:27because they like a clean workspace.

2:30I typically just leave it alone,

2:33because like I said, some of the other products,

2:36especially new products that they get released

2:38will have a quick start.

2:40And if you delete that default VPC

2:43that quick start script is expecting

2:46that default VPC to be there and it could error out.

2:49So for my purpose,

2:52I just forget about it and leave it there.

2:54Okay, we're going to create a VPC,

2:56and at this point I'm just gonna create a VPC only.

3:00I'm gonna call this my VPC.

3:04And now we're asked to allocate our IP block.

3:10And I'm going to use 10 dot one dot zero dot zero slash 16.

3:18So that's gonna give us a network that we can use,

3:22these first two numbers are going to be fixed,

3:25that's part of the network,

3:26and then we can use these other two numbers

3:30to dole out IP address ranges,

3:32and you'll see that in a second.

3:35So here's where we can define our IPV six block.

3:39I'm not going to use IPV six in this VPC.

3:44Then we come to tenancy.

3:45By default, our systems are set up our VPC configuration,

3:51it lives in a virtual sense on a physical machine,

3:55Now because it doesn't really make sense

3:58to have each customer have their own

4:00dedicated physical machine,

4:03AWS of course shares these physical machines

4:05across several customers.

4:07We don't have access to those other customers

4:10activities or data, but our configuration,

4:14our systems may be running on the same physical device

4:16as somebody else's, that's by default.

4:19Now, if we wanted to force our stuff

4:23to run on its own dedicated physical machine,

4:27we could do that too.

4:29And some cases you may have regulatory requirements

4:33that necessitate this.

4:35Maybe you're concerned

4:37about any sort of hypervisor level viruses

4:41or something like that.

4:42Typically I just do default.

4:44There's special cases where you might wanna do dedicated,

4:47but we're not in one of those cases right now.

4:50We have our name down here,

4:51it automatically creates that tag from up here.

4:55And if you remember in a previous video,

4:57I recommended getting in the habit of tagging your things.

5:02I'm gonna create a project

5:03called or a tag called project.

5:06And I'm gonna say this is VPC skill.

5:12And this is just a good habit to get into,

5:15because you can use tags for all sorts of things.

5:19And one of the things that I could do here

5:21is I could pull up all the resources

5:24that have this project VPC skill

5:26and if I wanted to shut that stuff down, I could do that.

5:29We'll look into tags more later,

5:32but just I would suggest getting in the habit

5:34of putting tags on there.

5:36You could put a cost center, you could put a department,

5:38maybe an owner, as a matter of fact, that's a good idea.

5:41I'm gonna owner and I'm gonna put my name here.

5:46That way if somebody is stirring around out here

5:48and they say, "What in the world is this VPC?"

5:51They can look up the tag, owner Scott, call me up,

5:54slack me and say, "Hey, what is this?

5:56"Do you still need it?"

5:57So I'm gonna create VPC.

6:00And there we have it, our VPC has been created.

6:02Now there's a few things of note here

6:04that we wanna check out.

6:06First of all, let's go into actions

6:09and then edit VPC settings.

6:13Now these are some of the settings

6:14that we have for our overall VPC.

6:17Now mind you, this is the overall VPC, not the subnets.

6:21But one of the things we can decide

6:23is whether or not we want those subnets to be able

6:26to provide DNS resolution, by default, this is turned on.

6:31And there are some cases

6:32where maybe you don't want to allow that,

6:34maybe you want to stand up your own DNS server.

6:39You can turn that off

6:40and then that would not have those resources

6:44do that DNS resolution in those subnets.

6:47Another thing that we can turn on is enabled DNS host names.

6:51Now this will assign a host name

6:55to the resource when it gets launched

6:58that is publicly resolvable.

7:01Typically I will leave this off,

7:03but I'll just turn it on here in this case.

7:06We can also turn on some network address usage metrics,

7:10which may be useful in trying to analyze

7:14the flow of traffic and so forth.

7:18If you recall before,

7:19I mentioned that we have some options

7:22in the DHCP option set, I'll go over that later.

7:27But for now, we're just going to use the default option set

7:31and I'm gonna save that.

7:33If we go down here,

7:34we can see our IP address range that we set up.

7:37Flow logs are, think of flow logs

7:41as just logs of just raw logs

7:44of all the traffic coming in and coming and going

7:47around our VPC.

7:49Now if there's cases where we need to troubleshoot

7:52some things within our VPC,

7:55these flow logs are are really useful for that.

7:58I'm not gonna turn it on right now.

8:00We'll maybe turn it on in a later skill

8:03as we learn how to troubleshoot some of the things

8:07that can go wrong with VPC's.

8:09And here are our tags.

8:12Okay, so that's really it.

8:14So if we go back to our VPC's,

8:18you can see my VPC right there.

8:20One of the things that I like to do

8:22is use this little dropdown and select just my VPC.

8:27And then as we build out the components of this VPC,

8:30it's just gonna show the stuff that's relevant for this VPC.

8:35So next I'm gonna create some subnets.

8:39Create subnet.

8:42I have to select my VPC.

8:45Okay.

8:49Now one of the things that I like to do

8:50is I like to name them based on which AZ they are in.

8:55Now we can just create one

8:56and it's gonna randomly assign us an AZ,

8:59but I like the control over knowing

9:02which subnet lives in which AZ.

9:04Now remember as I said in a previous video,

9:07my US East two A may be different than your US East two A

9:12from a physical location standpoint.

9:14So we can't rely on that.

9:16But even still,

9:18I like to know where my stuff is logically, US East two A,

9:25and then I'm going to put that in US East two A.

9:28And then I'm going to give it this block of addresses.

9:34I'll give it one dot zero slash 24,

9:37that's gonna give us supposedly 256,

9:41but remember those reserved addresses,

9:44so we're not gonna have access to all of those.

9:54And one thing you'll notice

9:55is that it will pull up previous tags that we've created.

10:00This is kinda handy because then you don't have VPC skill

10:04with camel case or any sort

10:07of other punctuation or capitalization.

10:10You can kind of enforce some consistency there.

10:14There is a another way

10:16that we can really enforce consistency,

10:18and we'll show that when we start talking

10:20about multi accounts where we can impart

10:24some rules on tagging that will force some standardization,

10:28which is really handy.

10:29So I'm gonna again, put my name here,

10:34and then I'm going to create my subnet.

10:39Okay, so there is my subnet.

10:40Now I'm gonna create two more for the other AZ's.

10:46Okay, there we go, Ive created two more.

10:49I've named them corresponding

10:51to the AZ that they happen to live in.

10:58And if we scroll all the way out here,

11:01you'll notice that they've been assigned a route table,

11:06which we'll talk about next.

0:00<v Instructor>Okay, so now we have three subnets.</v>

0:03We have one in each AZ

0:06of the US-East region, and we go to route tables.

0:14And here's the default route table.

0:15Now, by default, we just have one route in here.

0:20And this, all this does is it routes our local traffic.

0:26It communicates between these different subnets.

0:28It allows us to transverse

0:30from one subnet to the other subnet and vice versa.

0:35And because it's our only route and it is our main route,

0:42then we don't have to explicitly assign subnets.

0:46So everything within this IP range

0:49is caught by this route entry.

0:53Now, let's say that we want to create a subnet,

0:57one of our subnets.

0:58We want that to be public,

1:01and we want the other ones to be private.

1:04Well, what I like to do here is, let's say,

1:09let's pick US-East-A

1:12and we're gonna make him the public one.

1:15And this is just a name,

1:17it doesn't instantly make it public or private.

1:20A subnets, a subnets, a subnet.

1:22It's just how we configure it, okay?

1:25So just to help me remember which is which

1:27and which one I'm gonna make public and private.

1:29I'll change the names.

1:30So US-East-2A is gonna be public, and these are private.

1:35Now, here's how we make that happen.

1:39So we have our main route table here.

1:41It's taking care of routing all the traffic

1:43amongst the three subnets that we have.

1:47Now we have that public subnet

1:49that we want to provide access

1:51to get out to the public internet.

1:54So we're going to have to create a specific route table

1:57and explicitly assign that subnet to that route table.

2:01But before we do that,

2:04we have to create a way to get out to the internet.

2:06And to do that, we're gonna create an internet gateway.

2:10And it's really simple to create an internet gateway.

2:13And I'm gonna add my customary tags here.

2:21Okay, and there we go.

2:23It has been created, but it's detached.

2:25We have to attach it to a VPC.

2:28So I'm gonna go up here to attach, I'm gonna select my VPC,

2:33attach my internet gateway.

2:35So now we have attached this internet gateway to our VPC,

2:41and that's going to allow us to route traffic

2:43to the internet.

2:45So as I said, this is our main route table.

2:47It takes care of all the traffic

2:49in and among our three subnets.

2:52But if we created a route inside this main table

2:57to the public internet,

2:59that would allow our other two private subnets

3:02to get access and vice versa, traffic could come in.

3:06So I don't wanna do that.

3:07I wanna wall them off.

3:08I wanna keep them private.

3:11So I'm gonna create a separate route table,

3:13and I'll just call it public route.

3:17And again, customary tags.

3:24Okay, there, I've created a route table.

3:26And you'll notice it has our route in there,

3:29but I'm gonna add a route.

3:32And the route that I want is 0.0 0.0/0.

3:36That's basically, if the traffic

3:39doesn't match this as a destination,

3:42if it's trying to go anyplace else,

3:44it's gonna follow this route

3:46and we can tell it where to go.

3:50Now, if you remember,

3:51we had this concept of an egress only internet gateway

3:54that's used for IPv6.

3:57We have an instance, we have an internet gateway,

3:59we have a NAT gateway.

4:01All these other options here.

4:03A peering connection, a transit gateway,

4:04and we'll cover that later.

4:06I wanna use internet gateway

4:08and it auto detects that I already have an internet gateway

4:11attached to my VPC.

4:12I'm gonna select that and save my changes.

4:16Now, this particular route table has the ability now

4:20to send traffic out to the internet and receive it back.

4:25Now, for me to actually use this,

4:27I have to explicitly assign

4:31the subnet that we wanted to make public.

4:34So I'm going to edit the subnet,

4:39select that guy.

4:41And so now you'll notice

4:43that this particular route table

4:45has been explicitly assigned to this subnet.

4:48What that means is we've told this subnet

4:51to use this route table instead of the other one,

4:55whereas these subnets are still using that main one,

4:58that first default one

5:00that has no route to the public internet.

5:07So that is creating our first VPC, creating our subnets,

5:12and we've created a route table

5:14to allow one of those subnets to be public

5:16and the other to be private.

5:18And we've also created an internet gateway.

5:20I'm gonna wrap up this video now,

5:22and then next we're gonna go into some of the other options

5:26that I talked about, including the DHCP option set,

5:29what's an elastic IP,

5:31some of the managed prefix lists and endpoints and so forth.

0:00<v Instructor>Okay, continuing along on our</v>

0:02VPC exploration, we've already created our VPC,

0:06we've created our three subnets,

0:09we've placed them in different AZs.

0:12We've decided that we wanted to make one of those subnets

0:14a public subnet and the other's private.

0:17So we attached our internet gateway

0:19and a route to that internet gateway, to that public subnet.

0:23Now we can explore some of the other options that we have.

0:27If you recall, when we initially created our VPC,

0:30we had the option to choose which DHCP option set we wanted.

0:35And if we wanted to customize these things, we could,

0:38we could give it a name up here.

0:40We can configure a custom domain.

0:43Maybe we wanted to use a domain of our own creation.

0:47Maybe we've registered our own domain.

0:50We can specify domain name servers, either via IPv4

0:54or IPv6.

0:56We can specify NTP servers,

0:59which is network time protocol servers,

1:01NetBIOS name servers, NetBIOS node types.

1:05And that's pretty much it.

1:07We don't have a whole lot of options,

1:09but if your use case requires for you

1:12to define an NTP server and NetBIOS

1:15or domain name server, this is how you would do it.

1:20Moving right along, elastic IPs.

1:23So elastic IPs are fixed static IP addresses

1:28that we can assign to certain resources.

1:32And by default, whenever a resource comes up in a subnet,

1:36it's going to get an address using DHCP.

1:39But sometimes we don't want a randomly

1:41assigned DHCP address.

1:42We want a fixed static address.

1:44And this is how we can allocate elastic IPs

1:48to certain resources.

1:51Now, we'll get into this later when we stand up

1:54some other resources, but I just wanted to mention it here.

1:59We have managed prefix lists.

2:02Prefix lists are maintained lists of IP addresses

2:08that AWS uses for various services.

2:11Some of these are based on whole networks.

2:13Some of these are based on individual IP addresses.

2:17And AWS keeps up with this.

2:18So where you might use some of these is if you were trying

2:21to get to a certain service

2:23and you wanted to be absolutely sure

2:25that that route took the best path,

2:29and it went to the destination that AWS says

2:32is indeed that service.

2:35Now, these come into play a little bit more

2:37when we talk about endpoints

2:39and endpoint services,

2:40which we're gonna talk about right now.

2:44So endpoints are pretty interesting,

2:46and I wanna show you, I want to draw a little diagram

2:48that shows you how they work.

2:50Okay, so here's how endpoints work.

2:52We have our AWS network, our universe of AWS.

2:55We have our VPC inside a region

2:59inside that AWS network.

3:01And there are other services that live

3:04inside the AWS network.

3:06In this case, I've created a little DynamoDB service here.

3:11So if we wanted to call, if one of the resources

3:15inside the subnets wanted to call the DynamoDB API,

3:20or maybe send some data to it, by default

3:24our connection would be out to the internet.

3:28So it would go out here, go out to the public internet,

3:31and then loop back around

3:33and come back in the front door of AWS hitting that API.

3:39Well, there's a better way.

3:41There's a more secure way that we can do this.

3:44We can set up an endpoint inside our VPC.

3:49And what that is, is that's kind of like a little

3:51tunneled connection there within the AWS network,

3:55kinda these back alleys.

3:57And we can call that API

4:01from within our VPC

4:04and our traffic never goes out to the public internet,

4:07which is pretty handy in two ways.

4:10Number one, if you don't have to send something

4:13over the public internet, you probably really shouldn't.

4:16And number two, there's less things that can go wrong

4:19with that connection because we're using the built in

4:23functionalities of AWS's backbone itself.

4:27So that's what an endpoint is.

4:30So just as an example, I'm gonna set one up for S3.

4:36So I'm going to say this is my S3 endpoint

4:43and I'm gonna use AWS services.

4:46I wanna show you something unique about S3 and DynamoDB.

4:54So one of the things you'll notice here is that we have

4:57different types of end points.

5:00One being an interface and one being a gateway.

5:04What's the difference?

5:05Well, an interface uses something

5:08that AWS calls private link.

5:10So if you hear private link, that's just their trade name

5:14for their kind of back channel paths to services

5:18that use the AWS backbone

5:21and to implement it, it uses in essence DNS trickery.

5:26It makes a DNS entry into your subnet DNS

5:29that will point name resolutions

5:32to the internal IP addresses of those services.

5:37Now, a gateway's a little bit different,

5:39and right now there's only two services

5:41that use the gateway endpoint, that's S3 and Dynamo,

5:47and they use prefix lists, which we talked about earlier.

5:51All in all, we don't really need to worry about

5:53what type it is

5:54because as soon as we add it to our VPC,

5:58then AWS takes the necessary measures to implement it.

6:03So I'm gonna choose the gateway, and I can select my VPC.

6:08I'm gonna choose my VPC,

6:09and it's asking me, which route table

6:11do I want to put this in?

6:13I'm gonna put it in both route tables.

6:16And the reason for that is because

6:18if I put this just in the main route table,

6:23the default route table,

6:25it only has our two private subnets associated with it.

6:28Whereas I also want any resources in my public subnet

6:32to take advantage of this same kind of more

6:34secure path to S3.

6:39And I can customize it with various policies.

6:44But I'm not gonna do that.

6:46Remember my habit?

6:48I'm telling you, you probably thinking

6:50this is a hassle right now,

6:51but there will come a time when you're gonna say,

6:55oh my goodness, thank you so much

6:56for getting me into that habit.

6:59Okay, there we go.

7:01So if we go back to our route table here,

7:05we can look at both of them.

7:09We see our routes and you see

7:12we have a prefix list that's been created

7:16for us with a target.

7:23And this is our special route to S3.

7:34So the endpoint services, let's say you're a company

7:38that provides services

7:40or maybe you know, some sort of SaaS offering

7:43to other companies.

7:45You could create your own endpoint

7:48and allow other AWS customers

7:50to attach to that endpoint just the same way

7:53as we just created an endpoint for going to S3.

7:57So all the data stays on the AWS network.

8:00It's all safe and secure that way.

8:02We're not gonna do that

8:03because we don't have any services that we want to publish.

8:07NAT gateways,

8:09if you recall from our earlier video,

8:12NAT gateways are used when we want our

8:14private subnet resources to be able to reach

8:19the public internet.

8:21So what I can do here is create a NAT gateway,

8:25my NAT gateway,

8:29And then I have to choose a subnet.

8:31Now, this subnet has to be a public subnet

8:34because this NAT gateway has to basically touch both worlds,

8:39both private and public.

8:41So I'm gonna choose this public, connectivity type public.

8:45Now, there are cases where you would use a NAT gateway

8:49in a private network.

8:51Let's say for example, that you had two companies

8:54that came together.

8:55They merged.

8:56They need to be able to tie their networks together.

8:58But oh shucks, they happen to use

9:00the same identical IP ranges.

9:03In that case, rather than trying to renumber

9:07one of the company's IP addresses,

9:10you could use a NAT gateway

9:11between as a go-between to allow one network

9:15to talk to the other network.

9:17And this NAT gateway would just kind of translate things.

9:20We need to assign an elastic IP.

9:23This will be the IP address that the NAT gateway will use.

9:26We can just click on assign and it creates it for us.

9:31And our NAT gateway is created.

9:35Now to allow our private resources to use this NAT gateway,

9:40we have to create a route

9:43for our private subnets to reach it.

9:46So I go back here to my route tables,

9:47I'll go into my default.

9:49As a matter of fact, I'm just gonna change this here.

9:52I don't know, I have a thing about just blank names.

9:55I like everything to have a name.

9:57Okay, call me crazy.

10:00All right.

10:01So you can see the routes here.

10:02We have our endpoint to get to S3

10:05using kind of the back channel ways.

10:08And we have our route to get to the other subnets,

10:12including that public subnet.

10:13But we have no route to get out to the public internet.

10:18But we don't want this particular set of subnets

10:22that we're gonna be dealing with

10:23to get out to the public internet.

10:24So we're going to edit this route,

10:29and I'm gonna put in the default route of 0.0.0.0

10:36and then we're gonna send that to a NAT gateway.

10:41And the console recognized that I already have

10:43a NAT gateway out there.

10:44So I'm gonna specify that and then save changes.

10:50So what we have now for the subnets

10:52that are associated with this,

10:55which implicitly are these two,

10:57but I'm just going to go ahead and add them explicitly.

11:07So for these two private subnets,

11:08they're going to use this collection of routings.

11:13Number one, if we're trying to go to S3,

11:14it's going to use this route

11:17that does not go out to the public internet.

11:20And if we're trying to get to the other subnet,

11:21it's gonna use this route.

11:23But for anything else, it's going to use this NAT gateway

11:28that we set up that lives in our public subnet.

11:31So now our resources on that private subnet

11:34can get access to the internet.

11:38Now, peering connections.

11:39Peering connections are how we can link VPCs together,

11:45either within the same region or across regions.

11:50We're not gonna do that right now,

11:53but just know that you can create a peering connection

11:58to allow VPCs from different companies,

12:03different regions.

12:05You can create this connection

12:07where you can specify some routing rules

12:10and then you can pass traffic back and forth between them.

12:14And here's how this works.

12:16You can create my peer

12:21and I select a VPC.

12:22Let's say I wanted to peer my VPC with some other account.

12:27I have to enter the account, maybe it's in another region.

12:30I can specify that region, but I have to know the VPC ID.

12:35So I would get that information from either myself

12:38by looking it up in the other region

12:40or whoever I'm trying to peer this with.

12:44And you would create that peering account.

12:46It would send a request to whoever the account is,

12:51it pops up right here on this,

12:53here let me cancel outta here.

12:55Pops up right here on this dashboard.

12:57And they have to explicitly approve that

13:01before that connection becomes a possibility.

13:05And then once it's a possibility there,

13:07then you would set up some routes

13:09to move traffic between the two.

13:12Okay, so that's about it for this particular video.

13:16Next we're going to go into network ACL's

13:18and security groups.

0:00<v Instructor>Okay, let's talk about</v>

0:01network access control lists and security groups.

0:05So we're out here at our VPC console page,

0:09and we can scroll down to network access control lists,

0:12network ACLS.

0:14And you can see we already have

0:15one network access control list set up for us,

0:18and that was created automatically

0:20as part of our VPC creation process.

0:23But I will say that most people

0:25do not use this default rule at all, and here's why.

0:30So if we go to the inbound rules, these rules are listed.

0:35You create these rules and the rule processor,

0:38the rule engine that tries to process

0:40and interrogate traffic as it's coming by,

0:43executes these rules in numeric order.

0:45And so we have this rule number 100,

0:48all traffic, all protocols, all port ranges,

0:52coming from anywhere is gonna be allowed.

0:54And oh, by the way, if you don't match that criteria,

0:57we're gonna deny you.

0:58Now deny is always the end,

1:00or it should always be the end here

1:01because you always wanna explicitly deny anything

1:04that doesn't match your criteria.

1:06But in this case, everything's gonna get through,

1:08this is an inbound rule,

1:10everything's gonna come in from the internet

1:12if it's trying to get to our resources.

1:15And for the outbound rule, it's the same thing.

1:17Now, this is probably less egregious, I guess,

1:21because it's outbound, but as you can see,

1:25by default this rule has been associated

1:28with all of our subnets.

1:31Well, let's say in our scenario,

1:34we only want web traffic, maybe HTTP and/or HTTPS,

1:41to come in inbound from the internet.

1:44So what we need to do is we need to create

1:47a network access control list that will allow for that.

1:52So we can go up here to create list.

1:54I'm gonna say allow HTTPS.

2:00We're gonna select our VPC

2:03and add my customary tags and create.

2:09Now we can define what we want, our rules.

2:12Oops, get rid of that guy, move some stuff around,

2:16there he is.

2:21Now we can define what we want our inbound rules to be.

2:28I'm gonna edit inbound rules.

2:32We go 100 and it has a lot of the well-known ports

2:37already here for you.

2:37You can specify UDP, TCP, ICMP,

2:43you have quite a bit of functionality here.

2:46So I'm gonna pick HTTPS protocol, TCP 443,

2:52the source is anywhere, that's fine.

2:54Gonna add another rule

2:58for HTTP port 80 coming from anywhere.

3:03That's all well and good, save changes.

3:08So now I've created my inbound rule

3:11that only allows certain port traffic.

3:13Now, you might also want to put port 22, which is SSH,

3:18to allow you to get in maybe over the public internet

3:21into your EC2 resources.

3:24But I'm gonna show you a way in a later skill

3:27that's much easier, I think, and much more secure,

3:32that doesn't require you opening up port 22 to the world.

3:36Now with outbound rules, right now, by default,

3:41it's not gonna allow anything outbound.

3:44So we probably want to change this.

3:46Now, if we had a really good understanding

3:49of exactly what ports we needed to open for outbound,

3:55we could lock this down.

3:57But there's something that you might want to remember

4:01when you're trying to lock down these outbound rules.

4:07And that is that a lot of transactions, a lot of protocols,

4:13for example, TCP, UDP,

4:15and I think also streaming control transmission protocol

4:21uses something called ephemeral ports.

4:24So initially they'll make a connection

4:26over the well-known port, say it's maybe 443,

4:29but then as soon as that handshake is done

4:31and that connection is made,

4:32then they switch to an ephemeral port,

4:36which is one of the high end ports on the port range,

4:41and oftentimes those are completely random.

4:45So if you are intent on messing with your outbound rules,

4:51I would suggest creating a rule for ephemeral ports,

4:55maybe over port 1024 or something like that.

4:59Especially if you wanted to try to really lock down

5:01your well-known ports, but just keep that in mind.

5:06So now we need to associate this with a subnet.

5:09Now a subnet can only have one network ACL

5:13assigned to it at any one time.

5:16So the fact that we're going to assign

5:19this network ACL to this public subnet

5:23means it's going to unassign that wide open,

5:26kind of scary network access rule.

5:31It is now assigned.

5:33And now if we had anything in that subnet

5:36and we were trying to reach it from the internet,

5:39if it wasn't trying to reach us on port 80 or port 443,

5:43we would not be able to reach it.

5:47Let's move on to security groups.

5:49I don't wanna spend too much time on security groups here

5:52because they're kind of hard to understand

5:54if we don't have any resources to assign them to.

5:57So we're gonna put that off till a little later.

6:01But for now, I just wanted to mention it

6:03so you're not left wondering what they are.

6:06Now, if you think of network ACLs, those are more broad,

6:09those are kind of at the network layer or network level.

6:13Security groups are more granular.

6:15They're designed to be applied

6:16to various resources inside those networks.

6:20So it's a little bit more fine grained permission.

6:22Now, by default, just the act of creating a VPC,

6:25it creates a default security group.

6:27And again, people typically don't use this

6:29default security group, but here's what it says.

6:32It has the same inbound and outbound type format

6:35as the network ACLs.

6:37We can go here and edit the inbound rules

6:42and we can see that this particular

6:45rule says it's gonna allow all traffic, all protocols,

6:49all port ranges from, and look at this,

6:52this is pretty interesting,

6:53this is the name of the security group.

6:56You can see up here, right there.

6:59So why is this special?

7:02Well, what this means is that in this default rule,

7:05at least, if we assign this default rule to a resource,

7:10then we assign this same default rule to another resource.

7:14Well, because those two resources

7:16are in the same security group,

7:18they're gonna be allowed to communicate between one another,

7:23with whatever traffic they want to talk to.

7:26Now, if there's another resource in that same network

7:28that does not have this security group

7:30or assigned a different security group,

7:32there's no talking, there's no communication.

7:35So you can see how this can be kind of useful.

7:38And how I like to use security groups

7:40is if you look at it maybe in a three tier app layer,

7:44where maybe you have the web server, you have an app server,

7:47and you have a data store of some sort,

7:49I'll create security groups along those three lines.

7:53And then I can specify,

7:54okay, the web server can only communicate to the app server,

7:58the app server can only communicate to the database

8:01and vice versa.

8:02And that helps me kind of hone in on my open ports

8:07or possible security threats

8:09by just telling certain machines

8:12you can only communicate with those other machines

8:14that you must communicate to,

8:17but we'll see that in action later.

8:21Same thing for the outbound rules here.

8:24If we edit the outbound rules.

8:25Now this is a little bit different,

8:27we're in this particular security group,

8:29we've said that at least default settings is all traffic

8:33is allowed for everywhere.

8:35And you know, I think AWS just does this because

8:38they've had their fair share of people

8:40calling in to support saying,

8:41hey, I can't figure out how to use my security groups,

8:45it must be broken, or something like that.

8:46Well, a lot of people get a little overzealous

8:48in trying to lock down their ports,

8:51they may not fully understand

8:53what ports their application uses,

8:54especially in those cases

8:56where ephemeral ports are being used and it doesn't work.

9:00So that's my advice to you,

9:01just remember those ephemeral ports

9:04and know that security groups

9:07and network access control lists

9:09are pretty handy and powerful ways

9:11of locking down your network.

0:00<v ->All right, let's put some of our VPC learning to the test.</v>

0:03Now it's time for a challenge,

0:05and that challenge is this.

0:07I want you to try to build a VPC network

0:09to these specifications.

0:12For starters, you should have three private subnets

0:16that can all communicate amongst one another.

0:19Then, we also want a public subnet

0:21that we're gonna call our Web Farm,

0:24and that subnet can only communicate

0:26to the app server's subnet.

0:28Now, there's some resources in the app server subnet

0:31that need to get out to the public internet,

0:34but that's a private subnet,

0:35so we're gonna have to implement NAT there.

0:38Now, on the public subnet side,

0:40we only want to allow port 25 inbound,

0:43but all the other outbound traffic is just fine.

0:47We wanna allow that.

0:48We also want to establish a really secure connection

0:52between the database subnet and DynamoDB.

0:56We don't want that traffic going out

0:57onto the public internet,

0:59so try to recall how we might do that.

1:02Now, to distribute their risk,

1:03our client wants the private subnets

1:06to all be on different AZs,

1:09but the Web Farm must share the same AZ as the app servers.

1:14And then finally, for the testing subnet,

1:17the client only wants to allow port 22 inbound.

1:22I'm gonna make this diagram a downloadable file

1:25right below this video, so you can take it offline.

1:28Maybe you wanna go brainstorm with some colleagues

1:31or see how many different ways

1:32you could build out this particular network

1:35and still accomplish the objectives here.

1:38So, hopefully the gears are starting to turn

1:40and you're getting some ideas

1:41on how we might build this out for our client.

1:44Go ahead and give it your best shot and in the next video,

1:46I'm gonna show you how I approach this particular challenge.

1:49Not saying that that's the only way or the best way,

1:52but the whole idea here

1:53is to give you a chance to try this on your own

1:56and then see how you fared if you run into difficulties.

2:00My solution is always there to help you out.

0:00<v Instructor>All right, let's get started.</v>

0:01Now, before I actually start building anything out,

0:04I like to just whiteboard it

0:06and come up with a strategy

0:07of how I might approach this particular problem.

0:10So I can say that this is going to be our VPC.

0:17We're gonna have an internet gateway right there.

0:20And because we also are using NAT,

0:22we know that we're gonna need a NAT gateway

0:25in that public subnet.

0:29Now, one of the other requirements

0:32is that each one of these private subnets

0:35has to be on a different AZ.

0:37So I'll put this one on AZ1,

0:40I'll put this one on AZ2, and AZ3.

0:46Now we also have the requirement that our public subnet,

0:50our WebFarm has to be on the same AZ as our AppServers.

0:54So this will be AZ2.

0:57Now we also have some port restriction requirements here.

1:02So we only want public internet port 25 inbound

1:07to our WebFarm here.

1:09Kind of weird if this is a WebFarm

1:10and we're only letting in port 25,

1:12but whatever, the customer is the customer.

1:15So we can restrict that with a Network Access Control List

1:21for port 25 inbound.

1:24Now, the same thing with our private testing subnet.

1:29We can restrict that

1:33with a Network Access Control List for 22.

1:37And the reason we'd use a Network Access Control List

1:39rather than a security group

1:40is because we're talking about kind of the whole network,

1:44the whole subnet versus just individual resources.

1:49So network ACLs are generally better at that.

1:52Now this is going to be an endpoint

1:56to allow us to securely access DynamoDB

1:59from the database here.

2:01And one thing to point out here

2:03is this requirement right here,

2:05one public subnet, WebFarm,

2:08can only communicate with the AppServer subnet.

2:12That means that we wanna restrict any traffic

2:16going to these other two.

2:20We don't wanna allow that.

2:22So what we can do there

2:24is we can use another Network Access Control List

2:28to allow traffic in and among these,

2:33but not for our public subnet.

2:36Okay, so I think we have a plan.

2:39Let's hop over into console

2:41and see how we can build this out.

2:43Alright, here we are logged into our AWS console.

2:46I'm using my IAM user

2:47'cause there's no good reason to use root for this.

2:52Gonna go under Your VPCs.

2:55And then the first step is gonna be Create a VPC.

3:02And I'm going to enter my IP address block.

3:10Now I'm gonna put a little poll down below.

3:12Some people call this Cedar, some people call it Cider.

3:16I guess it kind of depends on where you grew up,

3:18where you're coming from,

3:20but I'm curious to know what people prefer to call it.

3:24I've heard it used both ways.

3:28Create the VPC.

3:32Okay, now we need to create four subnets.

3:40That's what we're gonna do, okay.

3:43Now you know that I like to name my subnets based on the AZ

3:46that they happen to live in.

3:48So that's what I'm gonna do here.

3:51And we're gonna call this the Database subnet

3:55'cause that's what one of our subnets is gonna be used for.

4:02Give it that IP address block.

4:05Create.

4:06Now I'm gonna create three more.

4:20Call this the AppServer.

4:50Okay, and we have one last one to create.

4:54And this is gonna be our public.

4:55And if you remember,

4:57we were asked to make sure that this public subnet

5:01for our WebFarm is on the same availability zone

5:05as our AppServers.

5:12Okay.

5:14Creating our subnets, there we go.

5:16So we have four subnets.

5:17Okay, now I know I'm gonna need an internet gateway,

5:20so I'll go out here and create one of those.

5:26And then we need to attach that to our VPC.

5:31And then I'm also gonna need a NAT gateway.

5:33So I'm gonna create one of those.

5:36And the subnet that we want this to land in is our WebFarm,

5:40which is gonna be our public subnet.

5:43Connectivity is public,

5:45allocate and allocate an Elastic IP,

5:49and then create the NAT gateway.

5:50And that's gonna take a little while to get spun up.

5:54Now we also want to create an end point for DynamoDB,

5:58but before that, let's create some route tables.

6:02So right now we have our default route table

6:05that implicitly handles all the subnets.

6:11And you know how I do not like stuff that's unlabeled.

6:14Gonna label that.

6:16I'm gonna create a new route table,

6:17and I'm gonna call this the public route.

6:20And this is gonna be how our public subnet gets out

6:24to the internet through our internet gateway.

6:33And we're gonna use our internet gateway, and there it is.

6:37Okay, so the one last thing we have to do here

6:43is explicitly assign it to our WebFarm.

6:49So for this particular subnet right here,

6:57we have a default route to go out to the internet.

7:00So that's what we want.

7:05Now, there's one more thing that I'm gonna do.

7:09It's kind of optional, I suppose,

7:11because the requirements weren't explicit

7:14on whether or not we have to limit access to DynamoDB

7:20through our endpoint, via our database subnet.

7:23But I'm gonna create a route for the database subnet,

7:29and that's where we're going to add the endpoint

7:33or the prefix list to Dynamo.

7:41So we can do that right now.

7:44We go down to endpoints, we create an endpoint.

7:56Okay, and we wanna associate it with this route table.

8:05And there's one last thing I have to do back here

8:07at this database route.

8:09See if you can guess what it is, yep.

8:12We have to explicitly associate the database subnet.

8:19So now anything in that database subnet

8:22is gonna use this route table.

8:25So it's gonna go to,

8:27it's gonna use that kind of back channel path to DynamoDB.

8:35Okay, now let's create some port restrictions.

8:41So we're asked to restrict inbound into our public subnet,

8:47just port 25, which is SMTP.

8:53So I'm gonna create a network ACL,

8:58and once I find it here,

9:02for inbound rules, we're gonna edit those.

9:05We're gonna add a new rule.

9:11SMTP,

9:12and I think our requirements said from anywhere.

9:15So we'll save this.

9:21Now because this is,

9:23we're going to be applying this to our public subnet,

9:26we also need to be sure to think about

9:29outbound rules as well.

9:31And if you recall, AppServers use this NAT gateway.

9:36And so that traffic needs to be able to go out.

9:39So because we don't know specifically what traffic it is,

9:43we're just gonna allow all the traffic to go outbound.

9:48All right.

9:52And now we can associate this Network Access Control List

9:57with our WebFarm.

10:03And there, we've just applied restriction

10:06that only allows port 25 inbound,

10:10but any traffic can go outbound.

10:12Now we're also being asked to create a network ACL

10:16for port 22 into our testing environment.

10:20So I'm gonna create one called allowSSH,

10:29edit the inbound rules.

10:37Okay, and I believe it was from anywhere.

10:41So we'll save that.

10:43Can't forget about the outbound as well,

10:44'cause if once we apply this,

10:47if there's no outbound rules, then anybody, any resources

10:51inside that testing subnet

10:53won't be able to get to our other subnets.

10:56And I think that's probably not a good thing

11:00because we wanted to have the subnets

11:03be able to communicate with one another.

11:07And again, 'cause it didn't specify

11:09which traffic or which ports,

11:10we're just gonna allow everything.

11:12All right, now we need to associate that with our testing.

11:22And there we go.

11:25All right,

11:25there's one other thing that we can use Network ACLs for.

11:29And if you recall on the requirements,

11:32we were told that the public subnet,

11:36the WebFarm and the AppServers

11:39were able to communicate to one another,

11:41but they should not be able to,

11:43the WebFarm should not be able to communicate

11:46to either the database subnet or the testing subnet.

11:50And one of the things to know about Network ACLs

11:54is that subnets can only have one

11:57and only one Network ACL assigned to them.

11:59But we can use Network ACLS to prevent traffic

12:03coming in from that public WebFarm origin.

12:08And we can do that pretty simply.

12:11So let's go to Subnets here.

12:13Let's recall what the IP address range is for that.

12:17So here's the IP address range for our WebFarm.

12:21So it's 10.0.4.0.

12:24Okay, so if we go back to our NACLs,

12:29so this one is rather than call it SSH,

12:32I'm gonna call it testing.

12:34So this is our allow list for testing.

12:37For the inbound rules, I mean, we're pretty restrictive.

12:40We're only allowing port 22, which is what we required,

12:43but the source is anywhere.

12:46So it is possible, it is within the realm of possibility

12:49that we could have something on that WebFarm,

12:52that public subnet,

12:53and then it's trying to get into this testing subnet

12:56and it's using port 22.

12:59So what we need to do is we can add a new rule

13:05and we're gonna make this new rule appear before this rule.

13:14So we're gonna say all traffic from 10.0.4.0/24,

13:23which is that whole network, Deny.

13:29Now let's look at what we have.

13:31So any traffic coming from this source

13:36is gonna be rejected, denied,

13:39even if it is port 22,

13:40because this is the first rule on our list.

13:45Now we need to do something similar

13:47to protect our database subnet.

13:51Just call it protectDatabase.

13:54Again, you can name these whatever you want.

13:56I would recommend coming up with a naming scheme,

13:59especially if you have a bunch of people in here

14:01doing this stuff.

14:04Okay, so for the inbound rules,

14:07I'm gonna do this a different way

14:08just to show you an alternative.

14:13So I'm gonna specifically allow only certain networks in,

14:19okay, I don't have to do one, I forgot about that.

14:23'Cause this is for network one.

14:27Two is our app servers, three is our testing.

14:31And so what I'm doing here is allowing traffic

14:35from those two subnets in.

14:36And anything else from the WebFarm,

14:38for example, is going to be denied.

14:41So that's just a little different way

14:43of doing the Network Access Control Lists.

14:46But what I do have to do

14:49is associate that with the database.

14:52And there we go.

14:54Now I think we have one last thing to do.

14:58Our NAT is set up.

15:01Let's go back to our route table.

15:06And so our public route

15:08is taking care of our WebFarm network.

15:11We need to create a route for our NAT

15:16on our AppServer routes.

15:18So I'm gonna edit the routes.

15:20I'm gonna say anything going to the default route,

15:23I want you to go through the NAT gateway.

15:28And then I'm gonna associate

15:30just the AppServer with this private route.

15:43And I believe we have completed our task.

15:48And again, if you did it a different way,

15:49there's probably a dozen different ways to do this.

15:52Doesn't mean it's wrong,

15:53especially combining route tables

15:56and Network Access Control Lists

15:57and maybe use security groups.

15:59There are many different ways

16:01to accomplish the same objectives.

16:04So the intent for this exercise

16:06wasn't to be right or wrong,

16:08it's just to get you in there

16:09and get familiar with the different parts and pieces

16:12and how you can take this abstract requirement

16:16and then turn that into a set of steps

16:18to help meet business needs.

0:00<v ->Well, congratulations on making it through another skill</v>

0:02as we make our march up that AWS learning curve.

0:06In this skill, we learned about VPCs, subnets, both public

0:09and private route tables,

0:11network address translation gateways, internet gateways,

0:15elastic IPs, DHCP options, prefix lists, security groups,

0:20and a lot more.

0:21But we've really only just scratched the surface on

0:24what we can do with AWS Networking.

0:26That stuff we'll cover in a later skill,

0:29but for now, we got a pretty good baseline.

0:32So I hope you found this video informative,

0:34and thank you for watching.