"AWS VPC Beginner to Pro - Virtual Private Cloud Tutorial" - Transcript | YTScribe

Amazon Virtual Private Cloud is a service that lets you launch AWS resources in a logically isolated virtual network that you define. Neil Davis teaches this course. He's created many popular AWS courses and he's a great teacher. This is Neil Davis from Digital cloud training. And this hands on video, you're going to learn Amazon Virtual Private Cloud VPC. In AWS a VPC is a logically isolated portion of the cloud into which you can deploy your own resources such as Amazon easy to instances VPC is quite a complex topic. In this video, I'm going to start right

at the beginner level and take you through to an intermediate or even expert level, you'll learn how to define your own IP address ranges for a VPC, how to create a VPC and launch resources into it. You'll learn about routing and VPC security groups, network access control lists, and we'll also cover VPN connections, direct connects and much more. This video comes from my brand new AWS Certified Solutions Architect associate goals. So if you're planning to take an AWS certification exam, this video will be very, very useful for you. But it's good for anybody who wants

to learn about Amazon VPC, and actually practice using it. For those who want to learn even more. There are some supplementary videos on the digital cloud training YouTube channel, including for creating a client VPN, and a site to site VPN, both hands on videos, you can find the links to those videos in the description of this video. And you'll also find the course download as well which you'll need to complete the hands on exercises in this course. Now I really hope that you enjoy this video. And let's get straight into it. Hi guys, in this

lesson, I'm going to cover a basic primer on IP addressing. And we are specifically talking about IP version four, not version six. I'll cover version six, a bit later on in this section. Now, what I want to do here is assume that you don't have much knowledge of IP addressing at all, if any. And we're going to start right at the basics. Now it is a really complex subject. So I'm only going to go as far as what you need to know in order to be competent working with Amazon VPC. And with IP addressing in

general with AWS. Now, there'll be some areas of the subject matter where you may want to go deeper. And there's lots of resources on the internet for doing that if you wish to. to kick off the lesson, let's start with what is an IP address. Now, let's say we have a web server on the internet, and you want to communicate with that web server. Now the web server is likely to have some kind of network interface and attached to that network interface will be an IP address. And this is going to be a public IP

address. In this case, because the web server is available via the internet, IP addresses are the addresses that computers use to communicate with each other. So you've got your computer at home, and you got a web browser open. And you type in example.com, the address of our web server. Now what happens now because you put in example.com, but like I said, the computers communicate using IP addresses. So this is where a domain name system or DNS server comes in. Your computer will speak to a DNS server. And it's going to ask that DNS server what

is the IP address for example.com. Once your computer has the result, it's then able to connect to the web server using the IP address. So this is the main name resolution, where you're resolving a name, a nice friendly name that you can remember easily into an IP address, which is less easy to remember. But it's the way computers actually communicate with each other. Let's move on to the structure of an IP address. Now you've very likely seen IP addresses we've already worked with them in this course. So an IP address might look like this 192

dot 168 dot 0.1. This is known as dotted decimal notation. And it's a simple way of actually representing an IP address. Now each of these parts between the dots is actually a binary octet. So that's where things get a little bit more complex. But you do need to know this. So what is a binary octet? Well, octet means that you have eight values, and those values can either be a one, or they can be a zero. Those are the only two options. It's binary. In this small table here, you can see that in this case,

we have once eight ones, all in a line. Now on the left hand side we have what's called the most significant bit that means that if one In this leftmost place, it's going to have a value of 128. If you have a one, on the right hand side, that's the least significant bit, and its value is only one. If you have a zero anywhere, it just means zero. So for example, in this address, the third octet is a zero. So that means all of the eight bits are zeros. The one means that all seven bits

here are zeros. And we have a one on the right hand side, and that equals this least significant bit here. On the very left, we have 192. Well, 192 is 128 plus 64. So we have a one and a one, and the remaining values are zeros. And then for 168, we have a one, so that's 128. Then we have a one in the third place here, which is 32. And then we have a one in the fifth place here, which is eight. So we have 128 plus 32 plus eight equals 168. The reason it's important

to understand this binary is when we get to subnetting, with variable length subnet masks that's coming shortly. So firstly, let's understand that network and host portions of an IP address. Every IP address has a network ID and a host ID, the free blue boxes on the left there represent the network ID, this value will be the same for every computer on this network. The host ID will be unique for every computer on this network. As I said before, every IP address will have a network and host ID. But how this is configured does vary. Now

how do we know which piece is the network ID and which is the host ID? Well, that's where the subnet mask comes into play. Where we have 255. In this case, essentially where we have a bit that is a one that represents the network ID. So here we have eight bits that are one, eight bits that are one and eight bits that are one so those first free octets are all representing the network ID. Now the last octet in the orange box here is going to be the host ID. That's why it's zero. So every

bit in the subnet mask that is zero means that's where we have values that can be assigned a host. And every bit that's a one, those are values that are going to be exactly the same for every computer on the network. So a subnet mask is an easy way to see which bit is the network and which portion is the host ID. So let's look at an example. We have our 19216800 network with a subnet mask that looks like this. Now this is 24 bits, a 24 bit subnet mask because we have eight ones in

those first three octets. And that means it's a slash 24 network. It's another way of representing the subnet mask. And that's the format you'll often work with in AWS. So on this network, we might have several computers. And we can see that they each have different host IDs. But that same network ID. In this case, the host IDs are 123456 and the network ID is 1921680. For all of the hosts on the network. We also have something called classes with IP addresses. Class A looks like this 10 000 and 255000. Essentially, you have an eight

bit subnet mask. And that means the first assignable address is going to be a one, you can't ever assign zero as an address for a computer on the network. And the last assignable address is going to be 254 because you can't use 255, which is what's known as the broadcast address. Now in AWS, there's also a few other addresses that are reserved with a class a subnet mask, you can have up to 126 networks. And each of those networks can have a huge number of hosts 16,777,214. And that's because we have all of these bits

here to play with for the host ID. We then got Class B, which has a 16 bit subnet mask. First assignable address is 172 16 01 For this example, and the last address would be the 254. Here we have 16,382 networks, so a lot more networks and the usable addresses per network has reduced to 65 544. Lastly, we have a class C. This has a 24 bit subnet mask. And as you can see, the number of networks has now really increased, but we don't have as many addresses Available per network. So those are the standard

classes. Now, there's also something called a private IP address range, there's a few of these that are reserved for private use. That means not on the internet internally, within your company, we have 10, triple zero to 10 2552 552-551-7216 00217 230-225-5255. And then 19216800321921680255. These addresses are reserved for use in private networks. So not internet facing, you can't use these on the public Internet, things now get a little bit more complicated. Sometimes we want to vary the length of our subnet masks. And we don't want to stick to those standard classes. So we use something

called classless inter domain routing. And this helps us optimize the IP space. Let's have a look at some examples. Let's say we have this network here, we have a 24 bit subnet mask, we have eight house bits, and 254 possible addresses. The first address is dot one. The last is dot 254. Pretty standard so far, we then have a 16 bit subnet mask. So with the same network, we're using a different subnet martyr, a non standard one in this case, because 192168 is typically a Class C network. With a 16 bits subnet mask, we have

16 host bits, and up to 65,534 addresses. And it looks like this. But what about a slash 20 subnet mask? Well here, as you can see, we have a blue slash orange box. And that's because we borrowed some bits from the network ID to share them and use them for the host ID. That means we now have 12 host bits and 4094 addresses. So sometimes that's a better configuration for the number of computers you need to have on the network and the number of networks you actually need. And the addresses for this network would start

at 01 and go up to 15.254. So that's classless inter domain routing or cider. And it's using variable length subnet masks. In other words, breaking away from the standard and optimizing the amount of networks and hosts that we have. Now I know that's quite complex, and hopefully it will make more sense as we go through the section. So that's it for this particular lesson. I hope you got lots of value from that and I'll see you in the next lesson. Bye guys. In this lesson I'm going to teach you about the Amazon virtual private cloud

or VPC. VPC incorporates several different concepts. And what we're going to do in this section is go into them in much more detail. So first, we'll start off with the core knowledge around VPC itself. So within a region, we have our VP C's and they are always within a region they can't span across regions. A VPC is essentially a logically isolated portion of the AWS cloud that you can then use to deploy your resources inside it. And that's different to the public space outside of the VPC where services like Amazon s3 set, this is a

private space and you have full control over how you configure your VPC. Now as you know within a region, we have availability zones, and you can use those within your VPC by creating subnets and assigning those subnets to an availability zone. A subnet is always assigned to one availability zone, it can't span across multiple azs. But you can of course have multiple subnets in the same AZ we then deploy our resources such as easy two instances into our subnets. Now there's a thing called the VPC router. You don't really see the VPC router, but it

exists, and we interact with it by configuring route tables. Now the VPC router takes care of all routing for connections that are going outside of a subnet. If you send data out of a subnet, it's got to go somewhere else, maybe to another subnet, or maybe out to the internet or some other network. So the router takes care of making sure the data connection is sent to the right place. Now as I said, you don't see the VPC router. All you do is see the route tables and they are configuring the VPC router for you.

So we need to specify the destinations and the targets for certain networks and that's how it then knows where to send those connection attempts. If we want to access the internet, we also need an internet gateway, the internet gateway is attached to your VPC, you only ever have one per VPC, the internet gateway is used for sending data out to the internet. That's egress traffic. And in from the internet that's Ingress traffic. And we configure our route table with a route to the internet gateway ID, that tells it to send all traffic that doesn't fit

one of the networks in the route table before it to the internet gateway. Now you can create multiple v PCs within a region, you have a limit of five by default, but you can request an increase on that amount. Each VPC has a cider block. That's the overall block of addresses from which you then create the addresses you assign to your subnets. So it's kind of like a master block of addresses. Each VPC has a different one of these. So in this case, we've got two v PCs. And they have different cider blocks. As you

learned in the last lesson, cider stands for classless inter domain routing, from the overall cider block, we can then create the network IDs for our subnets. And they fit within that overall cider block. But they have a different subnet mask, so that essentially a subset of the overall available addresses and this is why it's really important to make sure we specify our cider blocks correctly so that we have enough networks and enough hosts per network. We'll cover that in another lesson. So here we have two v PCs, each with different cider blocks, and then each

with different subnets that come from those cider blocks. Now we're going to cover a lot of these components within this section, but I just want to cover them at a high level now. So you know what a VPC is and what subnets are, you know what an internet gateway is as well. Now, an egress only internet gateway is when you're using the IP v six protocol. And it allows traffic outbound only, whereas an internet gateway is for IPv IP version four, and it allows both egress and Ingress traffic. As you know the router the VPC

router takes care of routing connections to the right places. Now appearing connection is something where you can connect multiple v PCs and have private routing between them. We'll cover that in detail later on in the section. VPC endpoints allow you to connect using private IP addresses to public services on AWS. Again, we'll cover that in detail later on. Now, Nat instances and gateways, we covered these earlier in the course, these are both ways that you can enable internet connectivity outbound only for your instances in private subnets. The next two components, the Virtual Private gateway and

the customer gateway are both related to creating virtual private network VPN connections to our company offices or our company data centers. So that's a virtually private network and encrypted tunnel over the internet. We then have direct connect, that avoids the internet by using private connections right the way through to your data center or office and security groups and network ACLs are two different types of firewall. We'll cover them in a bit more detail in this section. We've used security groups quite a lot so far. They are what we call a instance level firewall, because they

operate at the level of the network interface attached to our EC two instances. Then we have the network ACL, that's a subnet level firewall. So it only sees traffic going in and out of the subnet. So just to summarize, that core knowledge of VPC is a virtual network dedicated to your AWS account. It's similar to having your own data center inside AWS because you're able to have full control over what you do with defining your cider blocks, creating your own subnets, setting up your security, your routing and so on. You have lots and lots of

control. It's logically isolated from other virtual networks in the AWS cloud. And as I mentioned before you get full control over lots of the configuration items in your VPC. And a VPC is a place where you then launch your resources such as Amazon 82 instances. When you create a VPC, you must specify your cider block. So that's the overall block of addresses. Now we'll see how to select the best cider block for our use case. And another lesson a VPC spans all azs within a region. that essentially means if there's three or six or whatever

number of azs in a region, you can create subnets within your VPC on all of those azs. But remember, each subnet is always within one AZ it can't span azs but you create multiple subnets if you want to. In an availability zone, you get full control over access to your resources inside a VPC as well. By default, you can create five per region. But you can extend that if you submit a request. A default VPC is created in each region with a subnet in each availability zone. And that's always a public subnet. So whichever region

was changed to your fine is already a default VPC and it already has a number of public subnets in it. Now that's it for this lesson. In the next lesson, we'll have a look at how we can work out a suitable cider block for our use case. In this lesson, we're going to look at what we need to do to define the cider blocks, we're going to use a few of the rules and guidelines and best practices. So first with the rules and guidelines. And these come from AWS, the cider block size can be between

a slash 16 and slash 28 subnet mask, it cannot overlap with any existing cider block that's associated with the VPC. And you cannot increase or decrease the size of an existing cider block. So you must get it right from the beginning, the first four and last IP address are not available for use. So you got to account for that when you set the size of your subnets. Because you want to make sure you have enough addresses for your instances that you deploy. AWS recommend that you use cider blocks from the RFC 1918 ranges. Remember, these

are the private IP ranges. And that's these addresses. And of course, these give you plenty of scope. So that shouldn't be a problem. Now let's have a look at an example. So let's say I have a VPC cider block that looks like this. It's 10 000 with a 16 bit subnet mask. So that means it looks like this 10 000 slash 16. So that's the overall block of addresses. But now we want to create our subnets. So what we need to do there is we're going to take some of the bits from the host portion

here and assign them to the network portion. So maybe we're going to have 10 010 slash 24. And that means we borrowed all eight bits from that third octet for the network ID. So your VPC subnets, will have a longer subnet mask than the cider block that they come from. Now, in this case, it's a 24 bit subnet mask. Now what's the next network, the next network is 10 020 slash 24. And then the next one is 10, zero free, zero slash 24. So each of these subnets is going to have up to 254 potential

hosts. But of course, you have to take away a few from that number. So take away five from that number. And that's how many addresses you have remaining for your EC two instances. So as long as you're happy with that number of instances per network, which is quite a big number still, then this is a good and very simple range to use. Now let's go through a few additional considerations. You got to ensure you have enough networks and hosts, you really don't want to mess this up. You only get to set the cider block once

and then you're stuck with it. So make sure you plan correctly. Bigger cider blocks are typically better gives you more flexibility down the road. Smaller subnets are okay for most use cases you don't need 1000s of instances per subnet. Consider deploying application tiers per subnet. So if you have a free tier application, you might have different subnets for each tier. And you might have it as highly available across multiple availability zones as well with a subnet in each AZ. So that's a good way of getting that high availability and resilience into your workload. Now VPC

peering, which we're going to cover a bit later, is where you connect your VP C's so that you can route directly between them using private IP addresses, so you don't go out to the public Internet. Now it's really essential that you don't have overlapping cider blocks. So in other words, you can't have the same cider block in two v PCs and connect them with VPC peering. So even if you're not doing peering now, just remember this because you might need to do it in the future. You want to make sure your cider blocks don't overlap.

And this is across all v PCs and all regions and all accounts so make sure you get it correct. So in general, just avoid overlapping cider blocks as much as possible. Make sure you consider this when you're designing your IP address ranges. So let's go back to an example. Let's say we have 10 000 slash 16. So that's our cider block. And we create a series of subnets. Now each of these subnets has a 24 bit subnet mask and as you can see were separating them into public and private subnets in different availability zones, the

private subnets have a private route table, and the public ones have a different route table course the main route table for the public subnets here will have an internet gateway. And those subnets will also assign public IP addresses to the instances that are launched in them. So that's a bit of theory behind it and some practical examples there. I also want to show you a very useful tool that helps you to plan out your cider blocks and your subnets. I'll attach a link to this tool to the lesson. Now what we can do with this

tool is specify our cider block and see the subnets. And we can actually, the tool will help us to work out which subnets to use based on the number of networks we need subnets or the number of hosts per network. So let's stick with the example and put in 10.0 dot 0.0. And then the subnet mask, we're going to scroll down to slash 16. Now I want to have subnets with at least 254 hosts. So that would be a standard Class C network. Now let's have a look what we get. So let's click on Create.

And it gives us all the subnets with a slash 24 bit subnet mask that fit within the cider block. So we've got the zero subnet here. And then all the way down, we get to the very last subnet, which is 255. So that's 255 subnets, that we can have. And each of those subnets can support up to 254 hosts. Of course the VPC will actually reserve a few addresses so you won't get that many but you'll still get close to 250. So that's a really nice tool to use to help you to work out what

your subnets are going to be within your cider block. And that will also help you to determine the best cider block as well. Hi guys, in this lesson, I'm going to show you how to use the VPC wizard. The Wizard helps you to really easily create a VPC without having to do much manual work at all. In my management console. Let's go down to networking and VPC. On the VPC dashboard here, I can choose launch VPC wizard, and we then get offered four different pre configured options. And what I want to do is just go

through what you get with each of these options. So the first one is a VPC with a single public subnet. Very simple. You get a slash 16 cider block and a slash 24. subnet. And it's a public subnet. So if you select this option, you can specify your cider block and it's given you this default, you can specify a name, it's already entered the subnet cider block as well. You could choose an AZ if you want to, or otherwise, after entering the name, you could literally just create the VPC and it's going to do all

the tasks for you. And that would include attaching an internet gateway so that you have internet connectivity for your public subnet. Now let's cancel out of that all let's go back, go to VPC with public and private subnets. So now you simply get public and private subnets. And you get a network address translation device, so you get a NAT gateway, so your private instances can access the internet. So again, with this option, there's not too much to configure, other than the different subnets public and private. The key difference here is your Nat gateway does need

an elastic IP, so you need an elastic IP allocation ID. Now let's go back again. And this time we're going to go to VPC with public and private subnets and hardware VPN access. Here you have public subnets, private subnets. And also a VPN tunnel gets created. Now you need to have a VPN device in your corporate data center. If we select this option, and let's just give this a name, my VBC. And leave the defaults on this page, click on Next. And then it's going to ask for the customer gateway IP and that's the IP

address of your VPN device on your side of the network on your corporate data center. So if you specify those details, when you create this VPC, it's going to make that connection. Let's just go back, back again. And the last one at the bottom is VPC with a private subnet only and hardware VPN access the same as the one before except that you only have a private subnet. So you've got a VPN connection from your corporate data center to a private subnet on AWS, with no routing going out via the internet from that subnet in

AWS. So those are the four options. I just wanted to quickly show you through them. And in the next lesson, we'll actually create our own custom VPC. In this lesson, we're going to create a custom VPC with public and private subnets. Now let's have a look at what we're going to create So we're going to use the same example cider block we've seen in the section, it's going to be a 10 000 network with a 16 bit subnet mask, that's the overall block of addresses, then we're going to create these four subnets. We've got private

one a in private one, B, and public one, a public one, B, and the one a and the one B mean that they're associated with a specific availability zone. Now for the private subnets will have a private route table for the public subnets will have this main route table that's created, by default, will attach an internet gateway to our VPC. And the main route table will have a route via the internet gateway out to the internet for those public subnets. We also must specify that we want our instances to pick up a public IP address

automatically. So that's the configuration let's head over to the console and build this out. In the VPC dashboard. I'm going to go to your V PCs, and we just have a single default VPC. So let's create a new one. In your course download in the code directory, Amazon VPC, you'll have this file a custom bash VPC, we can simply copy values. So I've got the name, that's going to go under name tag, let's copy the cider block and put that under ipv4 cider block. We're not going to do ipv6 at this stage. In this course,

we'll leave the tenancy as default. If you change to dedicated, it's going to put your instances on hardware that's dedicated to you, and that's going to cost you more money. So definitely leave that as default. And that's all we need to do to create the VPC. So the VPC is being created. One thing I like to do is go to actions, edit DNS host names, and enable, that means we will get DNS hostnames for our EC two instances. The next task is to create our subnets we've got public subnets and private subnets. So I'm just

going to copy these values to my clipboard, we'll come back Go down to subnets. Create subnets, we need to specify our VPC. So my VPC and then we can put in the name and the subnet name, choose the availability zone as one a US East one a. And then the IP B's for cider block, we'll come back, we'll copy this cider block. And we'll paste that in. Now we could create the subnet there or we can add a new one. And we're just going to do the same for the next three subnets. So just go

through this file and copy the settings for your additional free subnets. When you finished your page should look like this, you've got public one a in US East one a, we have a 10 01 cyber block, and then you've got subnet to public one, B, and that should be in US East one, B, so let's modify that. And 10 zero to private one a should also be in US East one, a 10, zero free, and then private one B in US East one, b 10 04. So that all looks good. Let's create all four subnets.

And that's the four subnets created. Now for our public subnets. We want to go to actions here, modify auto assign IP settings, and enable the auto assignment of public ipv4 addresses. So I've done that for public one, B, let's do it for public one, a. And those are updated now. So the next thing I want to do is I need to create a route table for my private subnets. So they're not attached to the main route table, which is where the public subnets will be. So let's go to route tables. Create route table, we're going

to specify a name, I have that in my clipboard from the file private RT. For VPC, I'm going to select my VPC. And then we'll create the route table. Once that's created, go to subnet associations, edit subnet associations, and you want to select private one B and private one a and save. So now we've done that if we go into subnet associations, we should see an explicit Association for private one A and B. If we come back up to route tables, we'll see the other route table here. So this is the main route table or

the public route table if you like. And under subnet associations, there are no explicit subnet associations, but one a and one B public are associated implicitly. The next thing I need to do is go and create an internet gateway. So under internet gateways, here let's create an internet gateway. We'll give it a name. And let's just paste this value in from the file and create internet gateway. Once it's been created, it needs to be attached and the actions you can attach to VPC, select the VPC and then attach the internet gateway. Now the last thing

we need to do now we have an internet gateway. We do not route from our main route table. So let's go to the main route table here. Go to routes, edit routes, add a route, and we'll put in the 0000 slash zero, choose our internet gateway. And there it is in the list. So now, everything within the cider block will be routed locally by the VPC router. And everything that's not within that VPC cider block will go out to the internet via the internet gateway. So let's just save those changes. So that's it, we've created

our custom VPC with public subnets, private subnets to route tables, and an internet gateway. Now, that's all I need to do for this particular lesson. In the next lesson, what I'd like to do is launch some instances and just test our configuration and make sure we have the communication we expect. So we've created our custom VPC and I've just like to test that now. So we're going to launch some easy two instances, two instances in two different public subnets and one in a private subnet. And we're actually going to do that via the command line,

it's really useful to know the command line. Now not all exams require you to know the command line. So for the solutions architect associate, doesn't really matter too much. For the developer, it does a bit more for certain services, and definitely for the sysops exam. Now, whatever exam you're doing, or whatever career path you're taking in AWS, it's still a really useful skill to have. So it's definitely worth learning the command line. So we'll launch some instances using the command line. And then we'll use those instances just to test connectivity with each other. There's a

couple of things I want to do before we get started there. Firstly, I want to create a NAT gateway. So I'm in the VPC Management Console. Under Nat gateways, let's create a NAT gateway, I'm just going to call it my Nat GW, and I need to select a subnet. Now remember, with Nat gateways, they always go in public subnets. So here, I'm going to choose public one a, and that I know is within the correct VPC as well. So connectivity is public, we allocate an elastic IP, and then just create the NAT gateway. Now, of

course, it won't work until we update the route table for our private subnets. So under route tables, let's choose the private RT. Go to routes, edit routes, add route, and we're gonna specify 000 slash zero. And this time, it's going to be a NAT gateway. And we'll choose that Nat gateway ID. Now our private subnets will have access to the internet. And that's important because when our instance launches, we're going to run some user data. And that's going to connect to the internet to download some binaries for httpd. Next thing is under security groups, we

need a security group. Let's create a security group. I'm going to call it public that web, give it a description, and make sure I select my VPC. For outbound rules. By default, it allows all traffic to any destination. For inbound just for now, we're going to add all traffic from any destination. So this is very open, don't worry, we're going to lock it down in a subsequent lesson and practice with some different security group configurations. But for now, let's just open everything up. I'm going to create my security group, and that's ready to use. There's

a file in your course download. And that's in the code Amazon VPC directory, and it's AWS COI run instances, we need to add some values into this file. The first thing we need to do for this command is specify an image ID. So the command is AWS easy to run dash instances. And these are the values that we need to specify. So first, let's find the AMI ID that we want to use. ami IDs are region specific. So we've got to make sure that everything we do in this lesson is within the same region. It's

also where you created your custom VPC. So for me, that's North Virginia, hopefully it's the same for you. Let's launch an instance. Next to the Amazon Linux two ami. Let's grab this ami ID don't take anything in brackets there, copy that to the clipboard. Come back and paste that in the instance type we can just type this in, it's just going to be T two dot micro for security group IDs. Let's go back and find the ID of our security group. I can see my public web access security group. Let's just copy the security group

ID come back and paste that one in. Then we need the subnet ID. This time I'm back in the VPC Management Console. Let's go to subnets. First I want the public one a subnet ID. So I'm just going to copy that to my clipboard. Key name is the key pair that you're using in this specific region. Back in EC two, you can go to key pairs if you don't remember what it is, and just copy this name. And we can paste that in. Lastly, there's some user data that we're going to specify. Now this is

the user data file. What it does is runs a web server. And then it creates a couple of variables from the metadata were actually grabs the subnet ID, and it basically just puts that into a simple web page. So we can see where the instance is running. In our command here, we just need to specify the name of that file. Now what you want to do is change to your Amazon VPC directory, where we have all this information. And this is where the file is. So copy that to your clipboard, make sure you have the

file colon slash slash, and then the name of your file. Let's copy this and make sure it works. Before we fill out the other two, now, you will have had to run AWS configure, before you do this exercise, you should have specified an access key ID secret access key. And your region must be the same as the region where we're trying to deploy our instances now. So mine's all good. Let's paste in this command and run the command. And that appears successful. And we can see that we have an instance running in US East one

a. And there's quite a bit of information if you just spacebar and go down the page here. So let's go into EC two and check it's launching back in 82, I can see I have this instance at the bottom here running. Now I'm just going to label this one as public one a so I know which one it is. Now the next thing we need to do is to go back over to the VPC Management Console, take the subnet ID of public one, B and come back to our file. And we're going to use this

one. So what we can do is copy all of this, put it in one be here. And then I'm going to take this subnet ID, and just override this one here. So we should now be able to launch into public one B, let's copy this to our clipboard, come back and paste it in. That looks good. If I refresh the page here, and we have this pending instance, that's the public one be. So I'll just give that a label so we know which one it is. And then lastly, we're going to launch the instance in

our private subnet. So again, I just need to get the subnet ID for private one v. So I've copied that to my clipboard, come back, paste that in. And now we have the command. And this user data should run okay in the private subnet, because we're able to connect out to the internet via the NAT gateway. So I paste this in, hit enter. There we go, we should have another instance, back in easy to I can see my pending instance here. So let's call this one private, one be great. So I have these instances, let's

just give a refresh and see where we're at. So a couple of them are running let's saw by name, that might make things a bit easier. I'm just going to copy to my clipboard, the public IP for public one a, and paste this into a browser window. And I get this web page. And it gives me the subnet ID. So that should correspond with the subnet for public one A. So that's great, we've proved that we can connect from the internet to our EC two instance. Now the other thing I want to do is connect

between my EC two instances back in the console here, what I'm going to do is connect to public one, I use the EC two instance Connect. And while that's just connecting, let's come back. Next I want to get the private IP address of my public one B instance. And that's 10, zero to 25. And let's just change back to the EC two instance Connect. And I'm going to ping 10 dot 0.2 dot 25. And let's see if that response. So that proves that we have connectivity to our instance, in the other public subnet public subnet

one B. So we have two way connectivity, the responses coming back as well. So that's great. Lastly, let's check that we can connect to our private subnet. So let's see what the private IP address is. It's 10 04148. So let's ping 10.0 dot 4.148. And let's see if that works. And it does so we get an ICMP response. So that's great that shows that we have that connectivity working. One other thing we could do from here is see if we can connect to that web page. So we'll use the curl command and specify 10.0 dot

4.148 and hit Enter. And we get a response here that says this instance is in the subnet with ID and it gives us the subnet ID. So that's the h1 header for the HTML web page that we have on that website. So we We can see that we have Port 80. Open as well, were able to connect to the instance in the private subnet. And we can also infer from that, that the instance can connect out to the internet because it was able to install that web service. So that's it for our connectivity testing for

now. Now I'm going to leave all of these instances and the NAT gateway running, because we're going to come back and carry on when we do some testing with security groups and network ACLs. Guys, security groups and network access control lists. ACLs are two different types of firewall that we can apply in our AWS environment. So let's have a look at how they work. So here we have a VPC with two availability zones. And we've got a couple of public and private subnets. And we've got a few EC two instances that have been launched into

different public subnets and private subnets. So let's see how we can control traffic. Firstly, we can apply something called a network access control list or network ACL. Now these get applied at the subnet level. So you can see that they're sitting here at the edge of the subnet. Now, all traffic that goes into and out of a subnet will go through a network ACL. So you're essentially filtering traffic as it enters or exits the subnet. So ingress and egress traffic, a security group is different. A security group actually applies at the instance level of an

EC two instance, actually at the network interface level of the EC two instance. So that means we can have a security group that is applied to EC two instances in different subnets. So this is the same security group Security Group A, and it's been applied to instances in several different subnets. So remember that this is the instance level, that means it's going to filter traffic going between instances in the same subnet, or across different subnets, we could then have security group B, that's attached to different instances. So security groups can be applied to instances in

any subnet. Now, what happens here with these security groups, is the same basic thing as a network ACL. They're looking for traffic that's going in and out of the security group. So if you send traffic from an instance, in security group A, to an instance, in security group B, it's going to check that there's a rule to allow the outbound traffic, and then it's going to check here, the Security Group B is going to check Am I going to allow the traffic from Security Group A, and you can do that by IP address, or you

can actually do it by the ID of the security group itself, we'll look at all this in detail in the hands on as well. Now I want to talk to you about stateful versus state less firewalls, because the security group is a stateful firewall. And a network ACL is a stateless firewall. And it's really important to understand the difference. So let's look at an example. We have a client here. So this is a computer that wants to access a service on a web server, and we've got a firewall in the middle. So what happens is

the client is going to connect to the server, the server is a web server, it's listening on port 80. The Source port is the port that's assigned to the connection by the computer. And this is what's called a high numbered port is a port above 1024. And it's dynamically assigned for every connection. So we have a source port and a destination port. And we have a source and destination IP as well. Now the return traffic has a source port of Port 80, because that's where the web service port runs, and the destination port of 65188.

And of course the IPS are switched around as well. So the destination IP will be the client, the source IP will be the web server. Now what do we need in the firewall rule table to allow this to work? Well, what we need here is we need a rule for HTTP that allows the source IP 10.1 dot 1.1 to talk to the destination IP 10 dot 2.1 dot 10. And it has to have the source port and the destination port specified. Now of course, this is a dynamically assigned port. So we don't know what that

is ahead of time. So what you'd most likely have here is any so rather than having the source port specified we'd have the any specified so any source port is acceptable. And then rather than a specific source IP, we might have any because it's an internet based connection. So those are things that we can play around with in our rule tables. But the destination port will always be 80 because that's where the web server runs. So we want to make sure that we don't allow connections to any ports on the web server. Now that's the

traffic coming inbound to the web server. What about the return traffic going back? Well, in that case, things are swapped around. So we've got the same protocol, the source IP of the web server, the destination IP of the client, and the source port of 80, and the destination port of the dynamic port at the clients. Now again, you'd probably have the destination port, and the destination IP is any, because you want to allow traffic coming from any client on the internet if you're running a public web service, but you still might need a rule set

for the outbound traffic. And this is where the difference comes in between stateful and stateless firewalls. So a stateful firewall will allow the return traffic automatically. Now this is what a security group is, what that means is with a security group, you only need this roll up the top here, you need a role that says that you're going to allow the traffic from whatever client on whatever port, but you're going to allow inbound to Port 80 on your web server. And then the return traffic is automatically allowed. So you don't have to worry about the

return traffic is going to just go out automatically, it's going to be allowed because the firewall is clever enough to know that that's part of the connection. And so it just allows that return traffic. Now a state less viable checks for an allow rule for both connections. Now, this is what a network ACL does. So we have a network ACL, you need both the inbound rule and the outbound rule. So you need to make sure that you have the inbound rule for traffic coming in, and the outbound rule for traffic going back. Even if it's

the same connection, it doesn't understand that that's part of the same connection, it treats them separately. So really important to understand those differences when you configure your network ACLs. Now let's have a look at a security group. This is what a security group rule set looks like. So here we have separate rules defined for inbound and outbound traffic, what we're looking at here is the inbound traffic. Now again, because it's stateful, we don't have to have a rule for the return traffic. But we still might need an outbound rule for traffic going out from our

instances. So when our instances that are attached to the security group are initiating connections outbound. so here we can see we have several rules using different protocols. And we've got the protocol specified the port range, and then the source. And the source in many cases might be either an IP address or IP address range. Or it can be a security group ID as well. security groups support allow rules only. So there's no such thing as a deny rule in a security group. Essentially, there's an implicit deny rule at the end of the rule set. And

it's going to check for an allow, and if there is no allow, then by default, it's just going to deny the traffic. As I mentioned, a security group can use a source of an IP address an IP address range, or the security group ID of itself or another security group. Now let's have a look at a best practice configuration when using security groups. What we have here is a public subnet and a private subnet. And we've got an internet facing load balancer. So this is going to distribute traffic to our web servers. So we have

a load balancer, we have a web server front end. So this is the one that's actually users are connecting to from the internet. And then there's an application layer that's going to process data. And this could have multiple servers. So we have a load balancer. And we need a connections to be able to come from our clients on the internet through to the application layer, it might then write to a database. I haven't shown that in this diagram. So let's see how we set this up. Firstly, we create a security group for the public iob.

It allows traffic on port 80 for the web service from any source on the internet. Now outbound it has because it's going to now create a connection to the web front end. It has a role that allows outbound access to Port 80. And we've specified the actual security group ID public easy to. So that's the name of this security group. So it's only going to allow traffic outbound to the web front end, the web front end allows traffic only from the public lb on port 80. And then it has a destination for outbound traffic of

another security group called private lb, and a port of 8080. So that's what that particular application is listening on. The private lb security group will in turn, only allow inbound traffic from the public EC to security group. And it will only allow outbound traffic to the private easy to security group. And that's the one which has the application layer in it. So that's a way that we're locking down access to the different layers of our application, and ensuring that the application can talk to other components but nothing else can. So that's the best practice security

group configuration. Now let's have a look at network ACLs. One of the first things you'll notice is we have inbound and outbound rules. Again, and we have allow and deny rules. So with NaCl, you can have an explicit deny that's different to security groups. Remember, security groups only support allow rules. Rules are processed in order. So you can see that they're numbered. So we typically number our rules. And you might want to say that the next rules that you add in are 202 101. And then 303 101, you could work out your own process for

how you assign those numbers, but just remember that they will be processed in order. Now, the important facts about that means that once you actually reach a rule that either allows or denies traffic, the processing stops there. So if we have an allow rule at 100, that allows the traffic, then even if you had a deny rule, later on in the rule set for that specific traffic, it's not going to get there, it's going to allow it because it reaches DLL and processing finishes. So you've got to be very careful with how you set up

your rules the order that you create them in, and just remember that they will be processed in order, and then when an allow or deny is reached, then that's the end of the processing, it will either allow or deny the connection. So that's it for the theory. In the next lesson, we're going to do some hands on and set up our security groups, and network ACLs. Hi, guys, in this lesson, we're going to use security groups and network ACLs. And we should already have some instances running from earlier on in this section. So you should

have free instances running to in a public subnet, and one in a private subnet. And what we're going to do is test various configurations of security groups, and network ACLs. Now the first thing I need to do back in EC two is go to security groups. And I'm going to create a new security group. So we have the public web. Now we're going to create the private app. So this security group is going to be called private dash app. I've given it a description. And let's choose my VPC for the VPC. Now, what will the

rule be here? Well, I'm actually going to delete the outbound rules we've already configured, we've given internet access to this particular instance before. So we were able to download httpd when we installed the web service. But for now, I'm going to take out outbound rules, which means From now on, it won't be able to connect out to the internet for inbound rules, what I want to do is use HTTP. So let's just scroll down, find HTTP, that's the protocol for the web server. And for source, what I'm going to do here is type s, G.

And I can see my public web access. So I'm doing the best practice here, what I want to do is make sure that the web server in our app there is only ever going to allow connections that come from the web servers on the front end the public facing web servers in this security group. So let's create that security group. Now we need to assign it to our instance. So let's choose private one, B, go to actions, security, change security groups. And we're going to remove public web. And we're going to choose private app, click

on Add security group, and then click on Save. Great, so that should be set up correctly. Now, the first thing I want to do, though, is test the access to the security group on our front end. So what I'm going to do is go to security groups, choose the public web security group. And under inbound rules, I'm going to edit the inbound rules. And what I want to do here is change from all traffic. And again, we're going to choose HTTP only. We're going to remove the any source, and we're going to specify my IP.

So what that will do is it picks up my IP address. And that means that I will be able to connect over the Internet to this particular web service. Now I'm actually using a VPN and we're going to change it in a moment. So if you do have access to a VPN, you'll be able to do this as well. Otherwise, it can be a little bit difficult unless you have multiple public IPs. But I just want to show you the concept anyway. So let's just save this rule, come back to instances, take the public IP

address. And in a browser, let's just hit Enter. And that looks great. So I get access to this instance. Now what I'm going to do is I'm just going to go in and change my VPN here. So I'm connecting to a different service. And that means I've got a different IP now. So let's just refresh the page. Now you can't see anything happening. But if you look up in the top browser bar here, we can see we're trying to connect and this is what happens with security groups. When you can't connect, it kind of just

hangs for quite a while and then eventually it will timeout. So that's definitely working. We're not able to access the instance now. If I come back to security groups, and what I'd rather do is choose my public web security group edit inbound rules. And instead, I'm going to change this to any ipv4, because this is a web service. So we want anyone on the internet to be able to connect. So let's just save that rule. And back over here, it failed to connect, let's refresh. And now we're back in again. So that's a good configuration.

Now our web service is allowing only HTTP from the internet. And then it should be able to forward on to the App Service, because of the security group rules we set up before. So let's test that layer. Now back in EC two, let's go to instances. And what I want to do here is connect to my public one instance, over instance, connect. And I'm going to check the private IP address of my instance in my private subnet. And that's 10 04148. Now I've just noticed one of the things we have done here, we've got to

secure so we've locked ourselves out. Now if you just click on this note here, it takes you over to an article. And we can see that we actually need Port 22 from our IP address to be able to access the instance. So let's go back and set this up as a secure configuration. So going back into security groups, what we need to do is go to public web, edit inbound rules, add a rule. And this one can be SSH. And what we'll do here is we're just going to add any internet address because I might

be changing my internet address a couple of times. So otherwise, of course, you could use my IP, or have a range of addresses that you trust, that will be a more secure configuration. But for now we will be changing IPS. So I'm happy to have that as open. So let's save those rules. Now let's try and retry this instance Connect, and we're in. So the way I want to try and test that we can connect to our AP layer is using curl dash s and then putting in the IP 10 04 dash 148. Let's hit

Enter, and we get a response. So that's great. Now remember, we didn't have an outbound rule from that security group. So the response traffic is coming back purely because this is a stateful firewall. So that's it for security groups. Let's move on and have a look at configuring a network ACL back into VPC Management Console. Let's go to network ACLs. And what we'll see is there are already network ACLs. So we've got one here for our custom VPC. Now let's go in and have a look at the configuration. So we have inbound rules, we have

a rule number 100, allowing all traffic inbound. And then at the end, we have a deny rule. So remember, these get processed in order. So in this case, everything gets allowed because of the allow rule. So the deny rule doesn't get processed. outbound, we've got exactly the same thing. So let's try something, what I'm going to do is edit the inbound rules. And I'm going to add a rule. And I'm going to make this one on one. And what I'm going to do is specify HTTP source is going to be my IP address. So I

know my IP address is this one at the moment. So I put slash 32 for an exact match. And I'm going to click on deny. So I'm going to deny access from this particular IP address to http. Now do you think this is going to work? Hopefully, you realize there's an error here, but let's just save the changes. And we'll go and check it out. Back in easy too. I'm just going to copy the public IP of my instance, go to a new web page, hit Enter, and I get access. So of course, that didn't

work. Now let's go and see why. Back in the VPC Management Console, let's edit these rules for the network ACL. Now as you know, rules get processed in order. So we've got a deny rule here that's after and allow the allow allows everything. So actually, this is not going to work. Let's change this to 99 sort by rule order. And now we have a specific deny before and allow. So essentially, it's going to look through the rule set, it's going to see that traffic's coming in on port 80 from this particular IP, and it's going

to deny it. So we never get to the alarm rule for this particular traffic. So let's save changes. So we'll go and test this out now. But there's just one thing that you need to understand with security group rules, when you apply them, they do actually get put into effect pretty much immediately, there can be a bit more of a delay with a network ACL. So if you find you still have access to your instance, then it's probably just because you're a bit too fast. So just give it a couple of minutes and try again.

And we should find that we do get denied in a browser window here. Let's paste in our IP address. And sure enough, it looks like it's hanging. So that's clearly not working. Now what if I change my IP So this time I can change to somewhere different and very quickly, this time, the connection did actually change, and it did allow me in. So sometimes the network ACL rules apply super fast. And sometimes there's a bit of a delay. So it really can vary. So that shows you how to use a deny rule with a network

ACL. Now I'm just going to come back in and clean up that rule. So I don't want to have any deny rules in my network ACL. So let's just remove that one out from the inbound rules, and save changes. Now there are a couple of things we can clean up now to make sure that we don't get any bills. Firstly, let's go to our Nat gateway, these can cost money. So let's just delete this Nat gateway. And that's gone. And don't forget, you will also need to make sure that the elastic IP has also been

removed from your account back in easy to Now I do want to keep one public and one private instance. But I can terminate the other public instance. Now we will actually use the command line for this, I just want to show you another ci command. Back in our file here, we can specify the values for our DC two instances. So I've just got one here. So I'm going to put it in inverted commas. Copy this command, and back in my command line, let's just try and terminate this instance. And when you do that, you'll see

that the current state is shutting down, and the previous state was running. So we now know that our EC two instance is being terminated. So that's it for now, but do leave those other two instances running because we will be using them in subsequent lessons. Hello, and welcome to this lesson. There are quite a few circumstances where we might want to be able to connect machines that were running in different v PCs together using ipv4 or ipv6. So for instance, we might have two v PCs, which could be in the same region. It could be

in a different region or even a different account. And we want the easy two instances in those two v PCs to be able to communicate using private ipv4 addresses or maybe ipv6 addresses. Now a way that we can do that is to use VPC, peering. VPC peering allows routing for those addresses internally between those v PCs. And when I say internally, what I mean is, it's not going out to the internet. It's using the AWS global network to route traffic between the VPC so it never touches the internet. It does get encrypted when it moves

between regions, and it uses private ipv4 and also ipv6 addresses. So it's a great technology for lots of use cases. Let's have a look at how we can use VPC peering. So let's say we have a VPC, this is VPC a, and then we have another VPC, VPC B, and we want to be able to route connections between these two. So we got easy two instances, maybe RDS databases, even lambda functions, anything that communicates inside a VPC and we want to be able to connect those resources together using private ipv4 addresses. So what we can

do is establish a VPC peering connection between those two v PCs. So this will enable routing using private ipv4 addresses, or ipv6 addresses. Now, the cider blocks for our VP C's must not overlap. So this is a very important consideration when you're choosing the cider blocks to use your VP C's. Because even if they're in different accounts, you might someday want to connect your VP C's together. And if they have the same cider blocks or cider blocks to overlap with each other, then that won't work. So you must have cider blocks that don't overlap. Now

what if we have another VPC, VPC and VPC d A fourth one? So they all have their own cider blocks so looks good. We can definitely set up VPC peering between these. So what we do we establish a VPC peering connection between BBC a and VPC c between VPC B and VPC D and then with VBC C and BBC D. So we now have four peering connection sets up. But the problem with VPC peering is it doesn't support transitive peering. Now what that means is, let's say we have resources and VPC a, and it has

a peering connection with VPC B. VPC B then has a peering connection with VPC D. So does that mean that bpca can communicate with resources in VPC d? By going via the VPC B Well, no, it doesn't work. transitive routing doesn't work. So what we actually have to do is set up two more peering connections. We've now got a peering connection between A and D, and between B and C. So we've got a full mesh topology. Because VPC peering doesn't support transitive relationships. We do need this full mesh. So that becomes quite a lot of

connections. Now with these four v PCs, it's not too bad. But you can imagine if you spread this out across a lot more v PCs, soon this full mesh topology means you've got a huge number of connections to set up and to manage. So it becomes a bit unwieldy. And there are other solutions, which we're going to look at later on in the section and in sections to come. Now, as I mentioned before, the VP C's can be in different accounts, and they can be in different regions as well. Now let's have a look in

a bit more detail about how we set this up. So we've got Region One, and we've got region two. So in this example, we got two v PCs in different regions could be in the same account or different accounts, and we want to pair them together. Now they each have their own cider blocks, which are unique, they're not overlapping, so that's good. And then we've got some subnets. Now these could be private or public subnets. Because remember, it's the private addresses of the instances that will be used for the VPC, to VPC communication. And we've

got some instances running in these subnets. Now I'm showing public because we're going to set up a lab very much like this, it makes it easier for us to connect to our EC two instances if they're in public subnets. So we create a VPC peering connection. And I'll show you how to do this in the console. Now the next thing we need to do is set up our security groups. So let's say we want to use the ICMP protocol to send a ping request from one instance to another, and the other instance back again. Well,

in that case, we have to set up a security group rules as well. And we can use the cider of the other region. So we can use the cider block as the source and say that anything coming from that cider block is going to be allowed based on this rule. Now another thing we have to set up for this to work is the route tables. And what we do is we have a destination route, which goes to the cider block of the remote VPC. And we specify the peering IDs, when we set up the peering

connection will have a peering ID, and we're going to specify that as a target. And then we do the reverse on the other side, so that the route table will send any traffic destined for this cider block to the peering connection, and then it gets routed across to the correct VPC. Hi, guys, in this lesson, we're going to create a VPC peering connection between two v PCs in two different accounts. So the configuration is going to be pretty much what we see on the screen here, we have our management account in our AWS organization and

our production account. And we're going to have a VPC in each using these cider blocks. And then we're going to create security groups. And we're going to specify these particular rules. Now, firstly, let's have a look at how we establish the connection, we need to establish a peering connection between the VP C's, and we can do that in the console. Then we need to update the route table really important that you have a route to your target. So the route table for this VPC must specify as a destination the cider block of the other VPC

and the pairing target, and then the reverse is true. Over on the right hand side. Our security group rules will ensure we can use SSH and ICMP to connect and the way we will test the connectivity is to ping from one instance to the other using the private IP address and that will show us that we're using the VPC peering connection and not the internet. Now there is a bit of background work you need to do before we get started. So unless you want to use the default VPC in your production account, you should create

a new VPC using the same ranges I just showed you. So from the VPC Management Console, you're going to want to change to DCT production, go to your VP C's and then create a VPC. Now I've already created mine, and I have the values for you in a file. So just open the code Amazon VPC, custom VPC dash prod file, and this is the information you need there. You know how to do this, you've done it earlier on in this section. So just create this VPC and add the subnets. Add your internet gateway, your private

route table, and then we're good to go. Now we don't need all of this for this particular exercise, but let's just create it standard as per the VPC in our management account, and then we might use some of these subnets later on. So let's get started. Now I need a couple of pieces of information. With my VPC selected in my product count. I'm going to copy this owner ID that's the account ID and I'm going to put that into my file. Next I need the VPC ID and let's put that in the file. Now we're

going to switch back to the management account. Let's go to peering connections create peering connection. We need to give it a name. Let's just call it my peer. Select the local VPC, which is my VPC We can choose another account rather than my account and copy this account ID. we'll paste that in. We're going to stick to the same region, but we need the VPC ID on the other end as well. So that's the one that we copied here. So let's copy that to our clipboard, paste that in and create the peering connection. So it

says here a VPC peering connection, PC x, and then it's going to number my peer has been requested, the owner of the remote VPC must accept the peering connection. So let's go back and do that. Let's go to DCC production, go to peering connections, and we can see the request pending acceptance. So just select it on the left, and then go to actions accept request. And we can accept that one. And that's done. Now one of the things we're going to need to test is going to be an easy to instance. So let's launch an

easy to instance. But before we actually launch that one, I'm going to create the security group, the security group is going to be called VPC pair dash prod. And these are the rules we're going to set up. So let's create a security group. Give it a name. I just put that in the description as well. Choose the correct VPC and the outbound rule is fine. For now. All we need is the inbound rules to be set up. The first rule I'm going to set up is ICMP ipv4. So all ICMP that's going to allow ping

requests, and it's going to come from 10.0 dot 0.0 slash 16. The next row is SSH, you can either do custom TCP and put in the port range, or choose SSH, and it will do it for you. And same as the one above, we just want to give it the same addresses. So this should allow inbound connections from the VPC in the other account in the management account using from any IP address in the entire cider block. So we can save the security group. Now let's launch an instance that uses that security group. So I'm

going to launch an instance, it's going to be Linux to ami, T to micro, make sure you select your VPC, I'm going to put it into my public subnet public one a. Let's click on Next, go through to security group. And we're going to select a security group. And that's going to be VPC peer prod, click on review and launch and launch. If you don't have a key pair for this region, which I don't at the stage, then I'm going to create a new one. I've called it prod dash and V or download that key

pair and then launch my instance. So now let's go back in the city management console to the management account. In the management account, we need to set up this security group and we're going to assign that to one of our instances in a public subnet. So in this account, we've got two instances running, let's go to security groups create a security group. It's called VPC, pair dash MGMT. I'll put the same in the description, select the correct VPC. And then let's add the same rules as before. This time, the block is going to be 10.1

dot 0.0 slash 16. So now we have the same protocol specified so we should be able to connect from the prod VPC to the management VPC using these protocols as well. So let's create that security group. Go back to instances public one a actions security, change security groups. And we're going to add in VPC pair dash MGMT. And the reason I'm not going to remove public web is because we have a role in there allowing access from the internet to Port 22, which we need for instance, connect. So with those two added, let's save the

security group configuration. And the very last thing that we don't want to forget is our route tables. So let's go and do that. Now. Back in the VPC console for my management account, I'm going to go to my main route table, choose routes, edit, add, this one's going to be 10.1 dot 0.0 slash 16. And it's going to go over a peering connection. We've only got one of those, and it's called my pair. So let's save that switch across to the DCT production account. We need to choose the main route table. I didn't label this

one. Let's do it now. But I can see that it's attached to my VPC. So let's go to routes, edit routes, add. And this one should be for 10.0 dot 0.0 slash 16. And again, we're going to specify peering connection, it's going to see the same peering connection, and we can save changes. So that's it hopefully it's all set up. Now we've updated our route tables. We've got these two security groups with rules so that we should be able to use these protocols based on our private IP addresses. So that's that's the real test areas

to Use private IP addresses to see if we can connect, we can definitely ping via the public IPs if we've got our security group rules set up correctly, but we want to do it via private IP is because that shows that rather than going out to an internet gateway, we're sticking within the private space across the peering connection, back in easy to, let's select the instance ID, and we want to copy the private IP address, I'm going to just put that into my file here. And coming back here, let's switch to the management account. Choose

the public one a instance, connect by instance Connect. And let me just try and remember this IP 10 11221. So let's ping 10.1 dot 1.2 to one and hit Enter. And there we go, we get a response. That's across accounts. And it's also across regions. And it shows we've got this bi directional traffic going between these two v PCs. The other protocol we enabled was SSH. So let's just make sure that we can create an SSH connection 10.1 dot 1.2 to one. And we can now I'm not actually going to log in, because I need

my key pair. And I'd need to specify some more details as well. But I just want to see that the port is open. And that shows that the security groups are set up correctly, as well as the underlying networking to allow this traffic over private IP addresses. So that's really it for this lesson. Now, the only other thing you might want to do is you can practice by doing the same thing and extending this configuration through to your instance in your private subnet. Use your public subnet instance as a bastion host, you might have to

use agent forwarding, and then make sure you can connect bidirectionally from there as well. So that's just an additional bit of fun that you might want to have if you want to practice a bit more. So now that we've finished with this lab, we can actually terminate our instance, in the private subnet. We didn't use that in this lab unless you carried on with the configuration. But we will leave the public instance running for now. So let's terminate this instance. And then you should go over to your production environment as well and terminate your EC

two instance there, and then we're all cleaned up. You'll remember that earlier in the course I talked about how some AWS services are private in that they run within a VPC like EC two, whereas other services are public because they have a public endpoint like Amazon s3, for example. So that means when you connect to Amazon s3, you use a public DNS name, so connect to it as a public endpoint. Now, what if you wanted to connect an instance to Amazon s3, but you didn't want to use the public Internet, it might be an instance

in a private subnet. Well, that's where VPC endpoints come in. And there's a few use cases for VPC endpoints with connecting privately to s3 being one of them. And there are two different types. There's a VPC interface endpoint and a VPC gateway endpoint, the gateway endpoint is one which we can use for s3. And the interface endpoint is slightly different is used for other services. So let's start there. First, let's look at an example using a VPC interface endpoint. So we've got AC two running in a private subnet. And we don't want this instance to

have a public IP. And we don't want it to be routed out to the internet via a NAT gateway. So we provision an interface endpoint, which creates an EMI in the subnet. And then the instance can connect via that EMI to public services, but it's using private IP addresses to connect to them. Now each interface endpoint can connect to one of many AWS services. And you can connect to an AWS private link powered service as well. We'll look at that shortly to see what that means. So this is a way that we can connect our

EC two instances to these services using private IP addresses. Now let's look at the difference between that and a gateway endpoint. So in this case, I want to connect to Amazon s3 to store data in an s3 bucket. And again, I don't want to have a public IP address. So an instance in a public subnet, in this case, it is in a private subnet. And I don't want to provision a NAT gateway, or at least I don't want this traffic to go out to the internet. So I could provision a s free gateway endpoint. This

is slightly different. It uses a route table entry. So we now have to put a route table entry to point our traffic to the s3 gateway endpoints. And that uses the prefix list for the s3 and the gateway ID. The instance again connects using a private IP address to the gateway endpoint. And then from there, it connects to Amazon s3. Now you can secure this with Im policies so you can apply a policy to the endpoint. And you can also apply bucket policies. So for example, you can have a bucket policy that limits access to

any traffic that's coming from the gateway endpoint. So you now have a bucket Which will only accept traffic from instances that are using the s3 gateway endpoint. So let's just recap the differences with the interface endpoint. You've got an elastic network interface with a private IP with a gateway endpoint, you have a target in your route table for the gateway. So interface endpoints, we use DNS entries to redirect traffic, whereas gateway endpoints use the prefix list in the route table to redirect traffic. Now what services Well, there's quite a few with an interface endpoint API

gateway cloudformation. And cloud watch are just a few examples. Lots of the public services can be accessed via an interface endpoint. But a gateway endpoint is restricted to Amazon s3 and dynamodb. Only with an interface endpoint, you use security groups to control traffic, whereas with a gateway endpoint, you can use VPC endpoint policies. Now lastly, let's look at how we can use this in a service provider model. So what I mean is we have a consumer VPC and a service provided VPC. So we've got a couple of subnets in each VPC. And what's happening is

the service provider is creating a service. And that service is behind a network load balancer. And they want to provide that service to consumers. So what happens as a consumer is you provision an endpoint, and then you use that endpoint to access the service. So we're actually publishing a service in one side, and then we're consuming it in the VPC on the left, and using an interface endpoint to actually consume that service. So that's how it works. And in the next lesson, we're going to set up a gateway endpoint. Welcome to a nother hands on

In this lesson, we're going to create a VPC endpoint, it's going to be a gateway endpoint. And we're going to use some policies to see how we can control access to an Amazon s3 buckets. So this is basically the configuration we already have a VPC and a public subnet, and we've got an instance running in it from earlier on. Now we're going to create an Amazon s3 bucket. I'm getting ahead of myself a little bit here, because we actually cover s3 in a lot of detail in the next section. If you're completely unfamiliar with it,

and you want to get a primer, you could flick forward, but we won't be doing too much here, it's gonna be fairly straightforward stuff. Now when we create our endpoint, a route will be added to our route table. And that will point to a destination which will resolve to the IP addresses of Amazon s3. Now what happens is, this is a more specific route than any other route, like the route going out to the internet. So it should follow this path, which means any connections that go to the AWS s3 endpoints should be routed via

the gateway endpoint, and we'll be able to prove that that's happening, and that we're not using the public Internet. So we will modify the policy here to do that, you'll see what I mean shortly. And on the s3 bucket, we'll add a policy. Now bucket policies are basically just resource based policies. It uses JSON language, just like we do with Iam policies, but we just use them to control access to our buckets. So we apply them directly to the bucket, rather than to a principle like an identity based policy. The first thing to do is

to head over and create the VPC endpoint. I'm in my management account in North Virginia. On the left here, under endpoints, we can create an endpoint. Let's click this button Create endpoint. And under services, if we put in s3 and search, we get these options, we're going to choose gateway for Amazon s3. Now we need to specify which route table to actually update. Now as you can see the route table for our VPC, the custom one is not there. That's because we need to make sure we specify our custom VPC. Now we can see our

route tables. And I'm going to choose the one that's the main route table. So that's the one associated with my public subnets. Now the policy by default is full access. So we have a statement here, that's action, any action star effects allow, and then any resource and any principal. So it's very open, but you can customize that. So let's just create the endpoint, and it's being created for us. So here is our endpoint. Now what we want to do is go to route tables and just make sure that the route table has been updated. So

that's this one here, the main route table for our custom VPC. Under routes, we can now see that we have the destination, and this is going viral and VPC endpoints. So that's the route to Amazon s3 going via the endpoint. So that's set up correctly. Another thing we need to do, we're going to run commands against Amazon s3 from our EC two instance. So I need to give it some privileges, I'm going to create a role. So let's choose Create role here in the Iam service. common use cases is going to be easy to so

we're going to allow EC to to call an AWS service for permissions, just type in s3 and search. And we're going to give full access. I'm going to copy the name of this policy. And we're going to use that for the role name as well. So let's just paste that in, create the role. And now we have a roll that we can assign to our EC two instance. So over in EC two, let's choose our instance, go to actions, security, modify Iam role, and we're going to choose a role and we should see it in

here. And there it is Amazon s3, full access. So let's save an instance now has the privileges it needs. Over in the Amazon s3 console which you can find under services and storage, we're going to create an s3 bucket. So a bucket is just a container into which we add objects objects or files and videos or whatever you want to add. I'm gonna call mine DCT VPC test, and it's going to be in North Virginia, I can scroll down, don't need to change anything else at this point and create this bucket. So now that we

have a bucket, we can add some objects objects, as I say, are just files. This is an object based storage system. So we can come in and add files, I'm just going to add a couple of JPEG images and upload. So simple as that we have some files on Amazon s3. Now let's come back to easy to choose our public one a instance, go to instance connect and connect. Now we haven't specified any policies yet, but let's just check that we can connect to Amazon s3. So now we should be able to run commands against

s3. Let's try running AWS s3 Ls and hit Enter. And we can see our buckets, we should be able to run AWS s3 Ls and then s3 colon slash slash and our bucket name as well. And if we hit enter here, we should see the contents of the bucket. So at the moment, everything is working great. Now how do we know this is going over the endpoint rather than going over the internet because we are in a public subnet? Well, let's go back to our endpoint. With my endpoints selected, I'm going to choose policy. I'm

going to copy this code here in the endpoint policy, choose Custom paste it in. And let's just change the policy to deny. So this should deny everything. Now if we're going by the internet, this shouldn't make any difference. But if we're going via the endpoint, then this should block access. So back in our instance, let's try and rerun that command and we get an Access denied. Let's try and run the ls command. Again, we get an Access denied. So it's definitely not working back in my endpoint. I'm just going to change this back again, because

I don't really want that to deny me from access at this point. So let's just go back to full access, click on Save. The next thing we're going to do is set up our bucket policy. And the bucket policy is going to prevent any access except from the VPC endpoint. And that's something that comes up in a lot of exam scenarios. So let's go into our bucket here. Go to permissions. Come down to bucket policy, click Edit, and I'm going to copy the bucket AR n. Now this is the bucket policy. So it's in your

code Amazon VPC directory bucket policy VPC, what you need to do is take this whole AR n here and just paste your correct AR n over the top for your bucket. And there's two options here. One is without the slash star, and one is with. So the one with a slash star means that you can also look at the objects within the bucket. Now the last thing we need here is the VPC ID. So back at my endpoint here, I'm going to copy the endpoint ID and then come back and paste that into my policy.

So that's it, this policy should now apply. Now what does it do? Let's have a look. The policy is a deny. So it's going to deny any principle any s free action on these resources specifically, if the condition does not equal, this VPC endpoint ID so in other words, if you're not coming from this VPC endpoint ID you're going to get denied. If you are coming from this VPC The endpoint ID, it doesn't apply. So let's copy all of this code to our clipboard. And back in the bucket policy editor here, I'm going to paste

it all in and just save these changes. So let's go back and make sure we haven't broken access. Back in our instance, let's try them to run the AWS s3 ls command, and we see our buckets, let's check that we can see inside our bucket and that works correctly. That's good because this instance is coming from the VPC endpoint. So again, we've proven we're coming via the endpoint. But the other thing we can do is check from our own computers. And we shouldn't be allowed access. So back in a terminal here, I'm going to run

AWS s3 Ls. And I do see the buckets. But what about if I try to see inside the bucket, so the full command is AWS s3 lS s3 colon, slash slash, and then your bucket name and hit enter. So I've got an access is denied. So that proves that I'm not able to access the bucket from my computer because I'm not coming via the endpoint. Now let's just go back to the console and have a look at the bucket in the bucket here, you can see that we no longer have permissions to this bucket, we've

actually locked ourselves out because I'm actually coming through the console here, and the console doesn't come by the end point. So what we need to do is go back to our 82 instance. Now that is it for this lesson, we have finished with the easy to instance, and the VPC endpoint with the endpoint, you can simply select the endpoint, go to actions, and then delete endpoint. And that should clean up the entry in your route table as well. But you can always just go and check, you might need to refresh the page. And then it

has gone. So once you've done that terminate your instance. And we've finished for this lesson. Hi, guys, welcome to this lesson. This lesson is about the AWS client VPN. So it is exactly what it sounds like. This is a way that you can connect your client computer to the AWS data center to a VPC via a VPN connection. So a virtual private network connection. So let's say you've got a computer which is Windows or Mac or Linux, you're able to set up a client connection from there into a VPC. And that means you're then able

to communicate with resources in that VPC. So you might be able to connect to an EC two instance, directly using private IP addresses. Now, of course, it's a virtual private network. So that does mean that it's encrypted as well end to end. So let's look at how you set them up. So here we have a region. in that region, we have a VPC, we have a couple of subnets. Now we create a VPN endpoints. And the VPN endpoint is associated with subnets. So the client VPN network interfaces are created in the subnet. And that is

the method by which the VPN connection is then able to communicate with resources in the subnets. Because there is an association between this network adapter that's provisioned into the subnet, and the VPN endpoint, we then have the client computer, and that's going to be running some VPN software. The VPN software is not AWS software. So you need to choose one of the available options. There's lots of free options in the hands on in the next lesson, we're going to use open VPN, the client software will establish a connection with the VPN endpoint over SSL TLS.

So Port 443, and that's going to be via the internet, the VPN endpoint will actually perform source network address translation from the cider block that's associated with the VPN client to the cider block that's associated with the VPC. And on the client side, if you look in your route table, you can run a command on Windows, which is route print, and you would then see your route table and you'd be able to see that you have a destination for the cider block of the VPC and a gateway, which is pointing at the VPN endpoint. So

that's the theory behind how our client VPN works. Again, this is an encrypted connection over the internet from your computer. So your computer is then able to communicate using private IP addresses over to your instances in your subnets within your VPC. So that's how it all works. And in the next lesson, we're going to set this up using a Windows client on Amazon workspaces and a VPN endpoint. Guys The other type of VPN that we can establish in AWS is a site to site VPN. So a site to site VPN is where you might connect

for instance, a customer data center or office location into AWS And have a private network established over the internet. So an encrypted connection, which you can then tunnel through your traffic, and again, use internal IP addresses private IP addresses. So the setup looks something like this. We've got an AWS VPC on the left. And then on the right hand side, we've got a corporate data center, that could be a data center or an office, and you want to connect that into AWS. So AWS VPN is a managed IPsec VPN. And what we do is we

create something called a virtual private gateway, which is also known as VG W. On the AWS side, the VG W is deployed on the AWS and then a customer gateway is deployed. On the customer side, when you have those two components, you can then establish a encrypted VPN connection over the internet. The VPN connection supports either static routes, or BGP peering and routing. So in our route tables, we can actually specify a destination for the cider block of the corporate data center, and then point it to a Virtual Gateway ID. So that's this device here.

So that means any traffic going to this IP range will be sent over the VPN connection. So it's fairly straightforward. And the most common use case for this is what we see here, it's connecting in data centers, or office locations, to AWS, so that you can then tunnel your traffic over an encrypted connection using the internet. It can also be used sometimes as a backup connection for Direct Connect. And we'll look at that later on in this section. That's all the theory I wanted to cover for now. And what we'll do in the next lesson

is it's going to be practical, we're going to do a hands on lab where we're going to set up a VPN connection. AWS VPN cloud hub is not actually a service that you can go and find in the AWS console. What this really is, is a pattern and architectural pattern that you can use when you utilize the AWS site to site VPN technology. So let's have a look at the architecture in which you can implement cloud hub. So we've got a VPC. And we've implemented a virtual private gateway a VG W. And that's obviously deployed

on the AWS side. We then have multiple customer offices, or these could be customer data centers. But they're different on premises environments that we want to connect using a virtual private network to AWS. Now, the way that we connect them in a cloud hub topology, is using a hub and spoke model. So in other words, AWS is the hub, the VPC. And then the spokes go out to each of these offices. So what we do is we deploy a customer gateway into each of these offices. Each of these customer gateways has a unique BGP ASN,

that's a Border Gateway Protocol autonomous system number. So BGP is a protocol that you can use for advertising routes to different parts of your network. And each environment has its own ASN. And that corresponds with the routes that would be advertised into the network, so the IP prefixes, so you must have a unique BGP ASN for each office. And then we can establish a VPN connection between each of those customer gateways and the same Virtual Gateway on the AWS side. Now network traffic can originate from an office and go to the VPC or the VPC

back to an office. But also, it can go between the customer offices or the customer on premises environments, whether their offices or data centers. So the customer office here can communicate via the VG W. So this custom office here. So we're using the AWS site to site VPN to establish a routing topology, which connects multiple customer offices, as well as the VPC itself. Now, this is using IPsec VPN, the same VPN, as we just looked at in previous lessons. So that's it. That's VPN cloud hub. As I mentioned, if you go around looking in the

AWS console, you won't find cloud hub. But if you actually do a search online, you'll find some articles about this architecture, which can give you a bit more insight as to how it's set up. But basically, we're just connecting multiple customer gateways to a single virtual private gateway. And then it's up to you to configure your BGP protocol accordingly to advertise the routes that you want to advertise into the network. So that's it for a quick overview of cloud hub. I'll see you in the next lesson. We've already talked about virtual private network connections VPN.

Now VPN is typically run over the public Internet That means that we are subject to the bandwidth constraints and the potential latency issues on the internet, we can't control the internet, we don't know from minute to minute hour to hour, what's going to happen, we can get a good service provider. But still, sometimes there's a long way between us and our services on AWS. And that means somewhere along that path, we could have congestion or latency. So one of the solutions to that is using direct connect or dx dx means that you have a private

connection into AWS, that means it's not shared, it's not public, it's dedicated to you, it's a connection all the way into your AWS data center and into your Amazon VPC. So let's have a look at how we set this up. So let's say we have a VPC, we have a couple of subnets. And then we've got our corporate data center, or it could be your office. Now in the middle here is something called a direct connect location. These are different two AWS regions. And there's lots of these around the world. So there could well be

direct connect locations in the data center where your equipment is, or somewhere nearby in your city. In the Direct Connect location, AWS have a cage so they have a rack full of their own equipment. And then there's the customer or partner cage. So either you have a rack with some equipment in that data center, or you leverage an AWS partner. Now both of these cages will have a router. So we got the Direct Connect endpoint on the AWS cage. And then in the customer or partner cage, we have the customer or partner router, and you

must use certain types of connectors, a dx port is actually allocated for you. And then what you do is cross connects between the customer or partner router, and AWS, we then have a customer router, actually in your data center, and direct connects in AWS. And we can form the Direct Connect connection. So now, from your customer router, you need to have a physical connection into the customer or partner cage. So that might be something you need to speak to your local ISP to get that connection from this point into your data center unless you happen

to have all your equipment in a direct connect location, which can often be the case. Then from there, we have the cross connects into AWS and then a physical connection all the way in to an AWS region where your VPC is, that's a physical fiber connection, running at either one, or 10 gigabits per second. Now, 100 gig has just been released recently for some locations. If you want slower speeds, you can talk to a partner, and they can give you speeds from 50 megabits per second upwards. So let's have a look at some of the

benefits. You've got private connectivity between AWS and your data center or office, you get a consistent network experience, you can control the network path, it's not like on the internet where you just don't know what's happening. That means you can increase the speed, improve latency, get better bandwidth and throughput for your connection. dx can be quite expensive for many customers. But for those who transfer a lot of data from their data center into AWS, it can be cost effective. Now let's go a level deeper. So we've got the same configuration here. And you can see

some of the AWS services that are in the public space at the bottom of this box set. So how do we provision connectivity across this private line? Well, we have to create something called a private viff. A Vf is a virtual interface. A private viff is the way that you connect into your VPC in the same region using a Virtual Gateway. So there's a virtual private gateway attached your VPC and the private viff will send data across the DX connection into your VPC is a virtual interface that uses 802 point one Q, virtual local area

networks VLANs and a BGP session as well. Now what about connecting to the public space, you don't connect to the public AWS services via a private viff. Instead, you need a public fifth, our public This will allow you to connect to AWS services in the public space that are in any AWS region. But you can't connect to the internet via the public fifth. Now what if you want to connect to multiple v PCs in the same region, when in that case, you have multiple virtual private gateways and multiple private this to connect to each VPC

You can also create something called a hosted Vf, which means you can share a Vf with another AWS account as well. As I mentioned a bit earlier, you can get lower speeds from APN partners. So these are partners in the AWS partner network. And those speeds can then be from 50 to 500 megabits per second 100 gig is also featuring in some select locations, those are the AWS Direct Connect locations. So that could be where you are might not be probably won't be on the exam, yet, it's very, very new. Something that is really important

for the exam is to remember that dx connections are not encrypted, you cannot encrypt a dx connection. So there's no way that you can select a checkbox and enable encryption in transit. It just isn't a feature. So what do you do if you want to encrypt your traffic? Well, you can then create an IPsec site to site VPN over the top of the connection. So you have your dx connection, and you're basically running a VPN over that connection. So now your traffic is private, it's on your private DNS connection, you've got the latency and bandwidth

features. And you're also encrypting your traffic as well using a VPN tunnel. So that's really important to remember, it does come up in a lot of exam questions. Now that's it for the core theory around Direct Connect. And in the next lesson, we're going to look at another feature called direct connect gateway. Welcome to this lesson. In this lesson, I'm going to cover AWS Direct Connect gateway. Now the best way to understand the benefits of direct connect gateway is to have a look at an architecture where we don't use it and how complex it can

get. And then we're going to look at when we use direct connect gateway and how it can solve some problems. So here's an example architecture where we're not using direct connect gateway. Now we have multiple regions, and we have an office. And we have multiple dx locations in different parts of the world. And what we're doing is we're connecting each of those regions to a dx location that's close to that region and then into a corporate office. And we're doing the same in the EU central one region at the bottom here, as we are in

US West one. So this company now has multiple locations, where they then have connections into AWS using dx, then must establish a private viff. And that connects to a single VPC in the same region using a Virtual Gateway, we do the same in the second region. Now dx is a regional service. So obviously multiple DNS locations have to be used for this topology, and also requires at regional offices, or long distance, expensive links. So in other words, these customer routers here have to either be in one low physical location, one geographic location, and you've got

a very long distance link coming from Europe, or the US, or these are multiple offices in different geographical areas. So when we want to start connecting our offices to multiple regions, using direct connects, it can become quite expensive, and quite complex. So now let's look at an architecture where we use direct connect gateway. So in this case, we have the same two regions, we have a single corporate office and a single dx location. And so we now only have that connection into our office from one location. And we have a dx gateway. And then the

DX gateway is actually connecting to multiple regions, a private Vf is associated with the DX gateway. And then the DX gateway is associated with a Virtual Gateway. In each of the regions, BGP advertises around to all v PCs via the DX gateway. And the traffic that's going from the DX gateway to these different regions is going over the AWS backbone, so it's using that consistent network experience of the AWS global network. Now network traffic can go from the office to either region, so any of the VPC is connected. And of course, I'm only showing two

here. But you can have many, many regions that are connected to a dx gateway. Now, what you can't do is actually route regional traffic from one region to another via the DX gateway, it doesn't support that. But you can use it to connect from your corporate office using a single dx connection into multiple regions around the world. So that's the x gateway. It's a really useful technology if you're a global company, but you don't have global offices or you want a single office location to have this consistent network experience into multiple regions around the world

and this is a great technology to use AWS transit gateway is a really awesome service. It's described by AWS as being a Cloud Router, and it connects v PCs and on premises locations together using a central hub. So let's have a look at what this means. Now again, what I want to do is show you a fully meshed architecture without AWS transit gateway to help you understand the problem we're trying to solve, because when we have lots of VP C's, and on premises locations, it can get really complex, the peering connections that we set up

if we use VPC peering can become extremely complex. So let's say we have VPC A, B, C, and D again, and we've established our VPC peering links. And as you know, there's going to be quite a few peering links here, we've got six peering links that we've got to set up just for for V PCs. And as you increase the number of VP C's, it gets very complex. So here we have six VPC peering connections, we then have a corporate office connected via a customer gateway. So how do we connect the corporate office using a

site to site VPN to each of these v PCs? Well, we need a Virtual Gateway in each VPC, then we need to establish a connection to the customer gateway from each VPC. And each of those is its own encrypted IPsec VPN. So there's for site to site VPN connections. And that's not even including redundancy. If you wanted to add redundancy, you'd need another customer gateway, and double the amount of sts VPN connections. So it starts getting super complex. Let's now look at the same architecture. But with transit gateway. In this case, the same for V

PCs and a corporate office, we stick transit gateway in the middle, and it becomes the network transit hub that interconnects the V PCs and on premises networks. So now we have connections into each of these v PCs, the V PCs become attached to the transit gateway. And you specify one subnet from each availability zone, and that enables routing within that availability zone for any other subnets. We then have the customer data center, we've got the corporate office here with a customer gateway, and the customer gateway connects in. And that's it. This is now a service,

which is allowing us to connect through this Cloud Router, the central hub to any of these v PCs, tgw. W's can be attached to VPNs, Direct Connect gateways, third party appliances, and also transit gateways in other regions and also other accounts. So let's have a look at how it works with the x gateway. So in this case, rather than using a site to site VPN, our corporate office has a customer router, and we're connecting into a dx location, and we're using a dx gateway. So now the DX gateway has a connection to transit gateway. And

that's called an association. We then have the physical connection back to the corporate office from direct connect, and we create something called a transit van. So this is another type of virtual interface specifically used for Direct Connect gateways, when are associated to a transit gateway. So transit Vf is only used when you're attaching a dx gateway to a transit gateway. Now this architecture then supports for transitive routing between on premises, the transit gateway and all of those connected v PCs. As you can imagine, when your company gets bigger and starts using more VP C's in

more regions, and you want to have that transitive pairing between them, it can get so complex, that transit gateway will really solve a lot of challenges. So that's it for this lesson. I'll see you in the next lesson. Hello, and welcome to this lesson. I'm now going to talk about using the ipv6 protocol in an Amazon VPC. So remember, I mentioned earlier in the course that there's two versions of IP, which are used extensively. One of them is ipv4, that's by far the most commonly used, it's been around for quite a long time. And then

there's ipv6. Now, ipv6 has also been around quite a few years, but it's not being used anywhere near as extensively. But that needs to change over time because we are running short of ipv4 addresses. So we're going to have a look at how you can use ipv6 in a V PC. So let's start by looking at the structure of the IP v4 address. So remember, it's made up of four numbers separated by dots. And those numbers come from an octet. So that's eight binary bits, which are either one or zero. So an ipv4 address is

32 bits long. Now let's have a look at how many addresses you get for that you get 4.3 billion addresses, which sounds like a big number. And it's a big number of its dollars in your bank account. But when it's addresses that needs to be assigned to all sorts of different devices all over the world, in a world full of 7 billion people, it's just not anywhere near enough. And it might have sounded like more than enough, quite a few years ago, but it was became apparent, even in the 90s, that it was not going

to suffice, and it hasn't. So we are close to exhausting these addresses. And Nat has to be used extensively. So if you're in a company, and your company has 1000s of computers internally, then those computers will most likely be using ipv4 addresses. And those will be private addresses. And when they access the internet, they go for a NAT device or some sort. And that means that a public IP address is used to represent many, many PCs. So that's a workaround that we have to put in place with ipv4. With ipv6, we don't have to worry

about that. So let's look at the structure of an ipv6 address. So this is the structure of ipv6. It also has a network part and a node part. But it's 128 bits long. So it's a much, much bigger number. But also it uses hexadecimal. Whereas ipv4 uses dotted decimal. So that means there's a lot more potential values that you can use in hexadecimal versus decimal. So that means the amount of addresses is much, much bigger. And this is the number that's the number of addresses you can get out of ipv6. And it's absolutely huge. So

put it into some kind of perspective. And by the way, if you look on Google for analogies for the size of the ipv6 address base, there's all sorts of fantastic analogies, because it really is massive. So one that I like is that you can get 100 ipv6 addresses for every atom on Earth. So that is a huge, huge number, which means we never ever have to worry about running out of ipv6 addresses. So let's have a look at how we need to set up our VPC. So we've got a VPC with a couple of subnets,

we need to have an ipv4 cider block. And then we need the individual subnet ranges for our subnets. Now, we also need an ipv6 cider block now, so we've allocated one to this account. Now, AWS will assign a slash 56 ipv6 address range to the VPC, then you can create your subnet ranges within that address space. And those become slash 64 subnets. Now, a slash 64 subnet will allow 18 million trillion addresses. So again, it's an example of why you really don't need to worry about how many addresses you're going to have for your computers,

because it's just huge. Now, you'll notice there's two numbers highlighted in red at the end of the IP address. This is a hexadecimal pair, which has values from 00 to FF. And this designates the individual subnet. So it has to be unique for each subnet. And it means that you're going to have a possible 256 subnets, with ipv6 blocks in them. And each of those is a slash 64. So each of those will support 18 million trillion addresses. So lots of flexibility for your VPC. Now let's look at the route table once we've enabled ipv6,

so we now have a local route for the ipv6 cider block. And we need a route to the internet gateway for everything that's outside of that range, just like we did for ipv4, we have the colon colon slash zero for ipv6, pointing at the Internet gateways ID. And that means that anything that's not an ipv6 address in this range will go to the internet gateway. So we'll make sure that we have that specified in our route table when we enable ipv6. Now all ipv6 addresses are publicly routable. That means there's no network address translation. Now,

if you want to, you can use something called an egress only internet gateway. Now the purpose of this is when you want to allow outbound access only using ipv6. So it's kind of like having a EC two instance in a private subnet with ipv4 and then adding a NAT gateway into a public subnet. It means that that instance is protected from the internet, no one can access it directly from the internet, but it does have internet access outbound. So that's what an egress only internet gateway does. So that's it for the ferry on this topic,

and in the next lesson, we're going to go in and enable ipv6 for our VPC. Hi, guys, in this lesson you're going to learn about VPC flow logs And then we're also going to set a flow log up to see how it works and what data actually captures. So VPC flow logs capture information about the IP traffic going to and from network interfaces. In a VPC, the data is stored using cloud watch, or Amazon s3. And you can create the flow log at different levels. So at the VPC level, at the subnet level, or at

the interface level, service at the interface level, it's associated with the ENI, that's attached to an EC two instance, you can capture a lot of traffic, which is really useful for troubleshooting purposes and security as well. So let's go and create a flow log in easy to I still have an instance running, if you don't have an instance running, just launch an instance, just as we have done before, and put it into your public one, a subnet, and it should have a public IP address. Next, we're going to actually send our data to cloudwatch logs.

So in the cloud watch service, I'm going to go to log groups, create log group, and create myself a log group, I'm going to call it my subnet logs, I can set a retention setting. For me, let's put five days so after five days, I don't need that data anymore. And let's create the log group. Next, we need to create a role. So the flow log service has the permissions it needs in the identity and access management service, we're going to create a role. So let's create a role. choose Create role, we're going to choose

easy to for now we're going to modify that soon, because that's not actually the service that's going to be assuming this role, we're going to go straight past policies, because we're going to add an inline policy. And I'm going to call my role flow logs cloud watch, I'm gonna remove the description and create this role. Now let's find the role. And under permissions, we're going to add an inline policy, we're going to go to JSON. And we have this JSON code here in your code, Amazon VPC directory. And it's VPC flow logs dot JSON. So

all we need to do is copy all of this. As you can see, the service is going to be provided with the permissions to create a log group, create a log stream, but log events, describe log groups and describe log streams. So with that copied, let's come back, override all that code, click on review, give it a name, I'll just call it cloud watch permissions and create the policy. Now we do need to edit the trust relationship is not actually easy to that's going to assume this role. So coming back here, the trust policy can

be replaced, we can literally just copy this piece of text here. And we're going to paste it over where it says EC to dot Amazon aws.com. So now the service that is able to assume this role is VPC flow logs. Let's update that trust policy. That's it, we're now ready to go and create our flow log. Back in easy two, I've only got one instance running. So it's going to be easy to identify the network interface, we're going to create the flow log here at the network interface level. So flick over to flow logs, create

flow log, I'll just call it my flow log. Let's put it for all traffic, and a one minute aggregation. So we get some data nice and fast. we'll delete it afterwards when we terminate our instance anyway. And we're going to send a cloud watch logs. So we've got our log group. And let's find our role, which is starts with flow. So it's flow logs cloud watch. And we're going to leave the default format, and then just create that flow log. So now let's try a couple of things. We want to send some successful connections. So

let's copy our public IP, go to a new window here and put that in. And we've now generated some HTTP traffic. I might refresh that a couple of times. And what about sending some traffic, which we're going to get rejected on that's another thing that we could do. So let's come back to instances, check out what security group this instance is in. And it's actually got two. So let's go to the public web one, because I think that's the one that's got some rules which allow certain protocols from the internet. And yes, we can see

the SSH and HTTP rules are in there. So let's go and edit the inbound rules. And I'm just going to temporarily delete my SSH rule and save. Now from a command line, I'm simply going to try without any arguments to SSH to that instance. And that shouldn't work, it should just keep failing because we don't have the security rules to allow this. So that's basically it just generating a bit of traffic. So what we can do now is go to cloud watch logs, and see if some data is starting to be sent there. Back in

cloud. Watch logs, I'm going to select my log group. And let's see if we've got a stream. And I do have a stream that's nice and fast. Now, don't worry if it's not there yet, you might have to wait a few minutes, and it will turn up. So let's select my log stream and see what data we have in here. And you can see there's a few entries here, we can see some rejects. And associated with those is various information, including the elastic network interface, the source and destination IP addresses, we've got port numbers, we've

got protocol numbers, we've got various bits of information in there that could be useful in whatever analysis you're doing. If you want to refresh, you can click on resume, and then you should see some more data coming in over time. So there we go, we've got quite a few more rejects coming in as well. And just a couple of minutes later, I've refreshed my screen. And we can see some accepts as well. So there's quite a few, we can see the port number here, Port 80. So those are successful connections go into our web server.

So that's it. There's lots of data there that you can use for various analysis. And it's really useful to understand the different types of logs, we've got an AWS, what data is included in them so you know which ones to use for your troubleshooting or your analysis. So that's it for this lesson. And we have finished with our EC two instance now, so we can go ahead and delete it. Once you've terminated your instance, you're all cleaned up