1 00:00:15,930 --> 00:00:20,890 Welcome back to BackSpace Academy. In this lecture we're going to be building 2 00:00:20,890 --> 00:00:26,529 on what we already know about VPC and we're going to go into a little bit more 3 00:00:26,529 --> 00:00:31,059 of an advanced detail on this. This is quite important if you're going to be 4 00:00:31,059 --> 00:00:36,610 going on and doing one of the associate level certifications. We're going to 5 00:00:36,610 --> 00:00:42,399 start off by having a look at subnet addressing how do we address our VPCs 6 00:00:42,399 --> 00:00:47,110 and our subnets and the IP addressing of those and the components that go inside 7 00:00:47,110 --> 00:00:53,050 of those subnets. We'll talk about how we can connect to a VPC from an external 8 00:00:53,050 --> 00:00:58,420 source. We'll talk about route tables that control the routing of traffic 9 00:00:58,420 --> 00:01:03,790 within our VPC. We'll talk about public and private subnets, how do we create 10 00:01:03,790 --> 00:01:09,670 those and the differences between those. We'll talk about network address 11 00:01:09,670 --> 00:01:14,920 translation and how we can get requests for a public IP address and for them 12 00:01:14,920 --> 00:01:22,270 over to our ec2 instances in a private IP address and, finally we'll look at the 13 00:01:22,270 --> 00:01:31,090 core security functions of VPC. So here we have the AWS cloud. We have a region 14 00:01:31,090 --> 00:01:37,060 of that AWS cloud and that region is divided up into availability zones. 15 00:01:37,060 --> 00:01:42,420 We've created a VPC that's spanning those multiple availability zones and 16 00:01:42,420 --> 00:01:48,219 inside of that VPC we've created two subnets. One subnet in each of those 17 00:01:48,219 --> 00:01:53,049 availability zones. What we're going to talk about is how do we address 18 00:01:53,049 --> 00:02:00,069 that VPC and the range of IP addresses that can live within that VPC and 19 00:02:00,069 --> 00:02:05,709 also the same with the subnets. What is the IP range of those and how do we 20 00:02:05,709 --> 00:02:12,730 define those? There are two different types of IP addresses 21 00:02:12,730 --> 00:02:20,319 there are version 4 and version 6. A TCP IP version 4 address, it's a 32-bit 22 00:02:20,319 --> 00:02:25,630 binary number. If you don't know what a binary number is then please go away and 23 00:02:25,630 --> 00:02:28,630 learn a little bit about it because you certainly need to know that 24 00:02:28,630 --> 00:02:34,030 to do anything in the IT industry. Now that is represented as four bytes, so 25 00:02:34,030 --> 00:02:38,890 four eight bits, so 4 times 8 is 32 and you convert those over to a decimal 26 00:02:38,890 --> 00:02:43,320 number. There we can see we might have something that says 27 00:02:43,320 --> 00:02:53,520 192.173.255.000 and that would be an IP address a version 4 IP address. 28 00:02:53,850 --> 00:03:01,209 There are private and public network addresses. A public address if it's 29 00:03:01,209 --> 00:03:06,160 assigned to a server for example a web server, that allows that web server to be 30 00:03:06,160 --> 00:03:12,190 found on the wider internet. A private network or a private IP on a private 31 00:03:12,190 --> 00:03:18,120 network, that will not be accessible from outside of that network and so that IP 32 00:03:18,120 --> 00:03:25,510 addressing in that range will only be for communication between that local 33 00:03:25,510 --> 00:03:32,400 network. There are defined ranges or network ranges that are reserved 34 00:03:32,400 --> 00:03:39,580 specifically for private addresses. We have Class A which is 10.0.0.0/8 35 00:03:39,580 --> 00:03:44,019 and we're going to talk a bit more about that /8 and 36 00:03:44,019 --> 00:03:49,030 what that means, but that represents the range of IP addresses in that block of 37 00:03:49,030 --> 00:03:54,880 IP addresses. If an IP address begins with the number 10 it will be a class A 38 00:03:54,880 --> 00:03:59,560 private address and you won't be able to use it on the wider Internet you can 39 00:03:59,560 --> 00:04:05,890 only use that on your private local area network. 40 00:04:05,890 --> 00:04:13,540 Class B addresses which 172.16.0.0/12, again we'll talk about 41 00:04:13,540 --> 00:04:18,519 that /12 what that means. So if the IP address begins with 172 or 42 00:04:18,519 --> 00:04:25,750 anywhere between 16 and 31 after that that will be a Class B private address. 43 00:04:25,750 --> 00:04:33,400 Finally we have Class C there which is 192.168.0.0 /16 this time and so 44 00:04:33,400 --> 00:04:40,060 that means that if an IP address starts with 192 .168 it has a or it is a 45 00:04:40,060 --> 00:04:44,530 Class C private address. Those addresses will only be used on 46 00:04:44,530 --> 00:04:52,020 your private network they're not used to broadcast for a public address point. 47 00:04:52,020 --> 00:05:27,990 We'll talk more about what that means as far as /16 etc coming up 48 00:05:33,120 --> 00:05:37,900 the network portion so that defines where your network actually starts. 49 00:05:37,900 --> 00:05:43,740 The starting address of that block of network IP addresses and the zeros 50 00:05:43,740 --> 00:05:50,170 represents the hosts. That's the IP range of hosts that can live within our 51 00:05:50,170 --> 00:05:57,790 IP address or our IP address range. Amazon on the AWS cloud they will 52 00:05:57,790 --> 00:06:03,040 reserve the first four IP addresses so you can't use those and the last IP 53 00:06:03,040 --> 00:06:10,870 address of every subnet for their own IP networking purposes. So five of those IP 54 00:06:10,870 --> 00:06:16,480 addresses you cannot use so although you might have for example 20 available in 55 00:06:16,480 --> 00:06:20,380 reality you're only going to have 15 available because five of those will be 56 00:06:20,380 --> 00:06:28,120 used by by AWS. So here's an example so what we've got here is 192 168 1 0 is 57 00:06:28,120 --> 00:06:35,470 our network or our network IP address and we have to find there a subnet mask 58 00:06:35,470 --> 00:06:45,010 of 255 255 255 0. So looking at that in binary we can see our subnet mask the 59 00:06:45,010 --> 00:06:52,600 first 3 bytes of our subnet mask are ones and then the last byte are zeros. 60 00:06:52,600 --> 00:06:59,690 That red line that I've drawn there is where the network portion ends and 61 00:06:59,690 --> 00:07:06,180 the hosts or the range of hosts are defined after that. What we're going 62 00:07:06,180 --> 00:07:10,710 to do is we're going to have a range of IP addresses which are going to go 63 00:07:10,710 --> 00:07:19,830 from 192 168 1 all the way up to the last which will be 255 but again we 64 00:07:19,830 --> 00:07:29,280 don't use 255 that will be used by AWS. Our first available host will be, it 65 00:07:29,280 --> 00:07:35,610 won't be 0, it won't be 1, it won't be 2, and it won't be 3 because 66 00:07:35,610 --> 00:07:45,900 those 4 IP addresses at 168 1 0 1 2 & 3 they're used by AWS. Our first 67 00:07:45,900 --> 00:07:53,910 host address is going to be 4 so to be 192.168.1.4 is the first available 68 00:07:53,910 --> 00:08:01,320 host address in that range of IP addresses and the last one will be 254 69 00:08:01,320 --> 00:08:09,780 because 255 is is used by AWS for its own internal networking purposes. 70 00:08:09,780 --> 00:08:16,560 That will define a range of IP addresses for our VPC and within that we 71 00:08:16,560 --> 00:08:24,660 could define subnets of a smaller range inside that as well. Now a picture tells 72 00:08:24,660 --> 00:08:29,520 a thousand words so here we can see we've got a network ID that we defined 73 00:08:29,520 --> 00:08:36,659 in the last slide of 192 168 1 0. That had a subnet mask remember of 255 74 00:08:36,659 --> 00:08:43,979 255 255 and 0 so what does it look like when we're launching servers or ec2 75 00:08:43,979 --> 00:08:48,060 servers inside of that network what are the available ones? So the first one 76 00:08:48,060 --> 00:08:54,870 there is going to be 192 168 1.4 is the first one that will be available for us 77 00:08:54,870 --> 00:09:00,839 to use we can't use 0 we can't use 1 we can't use 2 and we can't use 3 so those 78 00:09:00,839 --> 00:09:06,600 first 4 IP addresses will be used by AWS and then the last one that we can use 79 00:09:06,600 --> 00:09:14,699 there will be 192 168 1 . 254 we can't use 255 because 80 00:09:14,699 --> 00:09:21,629 that is being used by AWS, That is the maximum range of instances that we can 81 00:09:21,629 --> 00:09:29,610 launch based on that subnet mask. Now if you remember at the start of the lecture 82 00:09:29,610 --> 00:09:36,360 I did mention that we could define our IP address ranges using a notation of 83 00:09:36,360 --> 00:09:42,990 /24 or /16 or whatever. The way that works is that 84 00:09:42,990 --> 00:09:51,480 instead of using a subnet mask for example 255 255 255 0 0 0 which is quite 85 00:09:51,480 --> 00:09:58,559 long, we could shorten that to simply /24 what that means is that 86 00:09:58,559 --> 00:10:08,730 the 24 defines the number of network portion bits so a /24 will 87 00:10:08,730 --> 00:10:17,490 have the first 24 bits allocated to defining the network address and then 88 00:10:17,490 --> 00:10:24,720 the last 8 bits will be for defining the network IP address range. 89 00:10:24,720 --> 00:10:32,610 A /24 is just a short way of writing that long 255 255 255 0 0 0 90 00:10:32,610 --> 00:10:38,730 subnet mask. The next one down there we can see is a /16, The 91 00:10:38,730 --> 00:10:47,339 first 16 bits are for defining the network portion and the last 16 are for 92 00:10:47,339 --> 00:10:53,490 defining the IP address range of that network and so that would be in a subnet 93 00:10:53,490 --> 00:11:02,069 mask 255 255 .0 0 0 .0 0 0 The final one there we've got is /20 94 00:11:02,069 --> 00:11:13,709 As a subnet mask it will be 255 255 .240.000 because the first 95 00:11:13,709 --> 00:11:21,980 20 bits so the first 2 bytes plus the next 4 bits so the first 20 bits 96 00:11:21,980 --> 00:11:29,870 we'll be defining our network address and then the last 12 bits will be 97 00:11:29,870 --> 00:11:37,640 defining our network IP address range. One thing to take consideration or take 98 00:11:37,640 --> 00:11:43,940 note of is that the smaller the number for our shorthand the larger the IP 99 00:11:43,940 --> 00:11:48,860 address range because there's more available for defining our IP address 100 00:11:48,860 --> 00:11:53,210 range. There's more bits available and less bits that are used for 101 00:11:53,210 --> 00:11:59,930 defining the actual network portion itself. So a /24 only has 8 102 00:11:59,930 --> 00:12:07,010 bits available for defining an IP address range whereas a /16 has 16 bits 103 00:12:07,010 --> 00:12:16,430 available for defining that IP range. Let's have a look at one a little bit 104 00:12:16,430 --> 00:12:22,960 more difficult here. We've got an IP address range of 170 2.31.6.0/20 105 00:12:22,960 --> 00:12:32,090 The first 20 bits are going to define our network 106 00:12:32,090 --> 00:12:37,280 address and then the final 12 bits are going to be defining the range of 107 00:12:37,280 --> 00:12:45,040 addresses that are available to us. We're going to start off with 108 00:12:45,040 --> 00:12:52,460 172.31.16.0 in our address range but the first four addresses so that will be 0 1 2 and 109 00:12:52,460 --> 00:12:58,640 3, they will be used by AWS. The very first address in that address range will 110 00:12:58,640 --> 00:13:07,250 be 172.31.16.4. Now because we've defined where that red line is where 111 00:13:07,250 --> 00:13:13,160 our /20 goes, our last host address it's going to be, it won't 112 00:13:13,160 --> 00:13:19,460 be at the position 255 it's going to be at 172.31 and then it's going to be 113 00:13:19,460 --> 00:13:25,220 31 again, so that third byte will be a 31 as you can see there on the last 114 00:13:25,220 --> 00:13:31,160 there binary and the last host address will be 254 and won't be 255 because 115 00:13:31,160 --> 00:13:35,840 that last address is used by AWS. That's a quite 116 00:13:35,840 --> 00:13:39,980 tricky one there but you can see there that when you break it down using the 117 00:13:39,980 --> 00:13:43,340 binary and you just draw it out in binary and then convert the individual 118 00:13:43,340 --> 00:13:49,700 binary over to decimal, you can see there you'll get 172 31 16 4 all the way out 119 00:13:49,700 --> 00:13:59,840 to 172 31 31 254. When we have our VPC it's going to have its 120 00:13:59,840 --> 00:14:05,450 own defined range of IP addresses and then inside that our subnets are also 121 00:14:05,450 --> 00:14:11,900 going to have a defined set of IP addresses. The range of IP addresses 122 00:14:11,900 --> 00:14:18,140 within each subnet must of course be less than the range of the VPC 123 00:14:18,140 --> 00:14:22,960 otherwise that subnet just physically won't fit within the range of the VPC. 124 00:14:22,960 --> 00:14:29,030 Again when we have a larger number in our CIDR notation it's going to produce 125 00:14:29,030 --> 00:14:33,890 a smaller range of IP addresses there so there we can see we've got our VPC 126 00:14:33,890 --> 00:14:41,330 which is 172.31.0.0/16. It's quite a large range of IP addresses 127 00:14:41,330 --> 00:14:45,290 and then we're going to have two subnets in there that are going to define a 128 00:14:45,290 --> 00:14:51,860 smaller range of IP addresses which are /20 range. That's how 129 00:14:51,860 --> 00:14:58,910 we do our IP addressing within a VPC. One good thing about the AWS 130 00:14:58,910 --> 00:15:03,290 VPC service or the console, is that when you're creating a VPC and you're doing 131 00:15:03,290 --> 00:15:08,540 it manually like this, if you make a mistake and the the range of IP addresses 132 00:15:08,540 --> 00:15:14,570 is too big to to fit in that VPC then the VPC service will specifically tell 133 00:15:14,570 --> 00:15:19,760 you, "hey that's too big make it smaller" and likewise if you make a VPC subnet 134 00:15:19,760 --> 00:15:24,290 that's too small a range that can fit any instances in, then it'll tell you 135 00:15:24,290 --> 00:15:30,470 that as well. So it does provide you a little bit of assistance as well. 136 00:15:30,470 --> 00:15:35,630 There's a few things to understand about the AWS VPC service, in particular with 137 00:15:35,630 --> 00:15:42,650 ipv4 addressing. By default when you create an AWS account a default VPC 138 00:15:42,650 --> 00:15:50,030 will be created for you and it will have the private side a range of 172.31.0.0/16 139 00:15:50,030 --> 00:15:57,260 So you're free to use other private address ranges if you like 140 00:15:57,260 --> 00:16:02,120 for example if you want to use a 10.0.0.0/16 range you could do that as 141 00:16:02,120 --> 00:16:07,460 well, but by default, out of the box, there is a default VPC there already created 142 00:16:07,460 --> 00:16:13,670 for you ready to go in that IP address range. Amazon VPC it will support 143 00:16:13,670 --> 00:16:20,090 between /28 and /16 address ranges in size. 144 00:16:20,090 --> 00:16:27,140 If it's larger than that, if it's larger than a /6 or or less than a 145 00:16:27,140 --> 00:16:32,300 /28 then you'll receive an error saying change the size of that 146 00:16:32,300 --> 00:16:38,990 VPC. so the minimum size of a subnet is a /28. Now a /28 will 147 00:16:38,990 --> 00:16:44,930 have 16 IP addresses in that range, of which, because five of those will be used 148 00:16:44,930 --> 00:16:51,640 by AWS, 11 are available. If you do a /28 you can only put 11 149 00:16:51,640 --> 00:16:57,580 resources within that VPC or you can only address 11 resources within that 150 00:16:57,580 --> 00:17:04,880 VPC. Obviously the subnets can't be larger than the VPC that's surrounding 151 00:17:04,880 --> 00:17:09,110 it. You need to make sure that your subnets are smaller than that VPC or the 152 00:17:09,110 --> 00:17:19,820 IP address range is smaller than that of the VPC. Now there is also IPv6 addressing 153 00:17:19,820 --> 00:17:25,100 available with Amazon VPC but it has more restrictions around it. Although it 154 00:17:25,100 --> 00:17:32,300 allows you to provide very large size of VPCs there are restrictions around how 155 00:17:32,300 --> 00:17:38,240 you can size those. It does support ipv6 addressing and that format is not a 156 00:17:38,240 --> 00:17:45,590 32-bit it's now a 128 bit, so it's eight groups of four hexadecimal digits is how 157 00:17:45,590 --> 00:17:53,600 you define an ipv6 address. The CIDR block is fixed at 56 so if you want 158 00:17:53,600 --> 00:18:00,290 anything other than slash 56 you can't use it, and the subnet CIDR block that 159 00:18:00,290 --> 00:18:05,610 is fixed at /64, so you need a different CIDR 160 00:18:05,610 --> 00:18:09,809 block range you can't use that. So they're the restrictions around it. 161 00:18:09,809 --> 00:18:16,620 Also AWS chooses the CIDR block for your VPC, you cannot choose that yourself. 162 00:18:16,620 --> 00:18:24,059 AWS will choose it from those that are available. All ipv6 addresses 163 00:18:24,059 --> 00:18:30,990 are public, there are no private address ranges available on ipv6 for you to use 164 00:18:30,990 --> 00:18:37,200 with AWS. Now elastic IP addresses, so having an IP address available that you 165 00:18:37,200 --> 00:18:42,690 can use with different ec2 instances and disconnect them and 166 00:18:42,690 --> 00:18:47,610 reconnect them to others. Elastic IP addresses are not supported with version 6 167 00:18:47,610 --> 00:18:56,280 only with ipv4 addresses. So there are some restrictions around how you use 168 00:18:56,280 --> 00:19:05,280 VPC addressing with AWS. So to change the IP range of an existing 169 00:19:05,280 --> 00:19:09,990 VPC or an existing subnet. For example if you wanted to change it from a 24 and 170 00:19:09,990 --> 00:19:15,179 then make it a /20 you just can't do that, you just kind of go into 171 00:19:15,179 --> 00:19:21,299 the console and and type that in and change it, you must terminate that VPC 172 00:19:21,299 --> 00:19:27,390 and create a new one but, there are ways around this. You can expand an 173 00:19:27,390 --> 00:19:36,390 existing VPC by adding up to four secondary ipv4 address ranges to that VPC 174 00:19:36,390 --> 00:19:41,010 Although you can't get an existing subnet and just create that or change 175 00:19:41,010 --> 00:19:47,630 that IP address range from a 24 to a 20 for example but you can add a whole new 176 00:19:47,630 --> 00:19:53,190 set of CIDR blocks here as well and, of course you can shrink it by deleting 177 00:19:53,190 --> 00:19:58,500 those secondary CIDR blocks at any time if you want to as well. A big 178 00:19:58,500 --> 00:20:04,230 restriction, you cannot change the size of an ipv6 address 179 00:20:04,230 --> 00:20:07,700 range on your VPC. 180 00:20:08,610 --> 00:20:15,549 Now in our past lessons we've launched EC2 instances and we've launched them 181 00:20:15,549 --> 00:20:22,240 with a Wordpress AMI and created a web server with a public IP address and 182 00:20:22,240 --> 00:20:25,720 we've been able to access that web server over the Internet through a 183 00:20:25,720 --> 00:20:32,710 browser. Now to achieve that we needed to have an Internet gateway and so in our 184 00:20:32,710 --> 00:20:37,899 default VPC there is one of those already created and so that will allow 185 00:20:37,899 --> 00:20:44,039 us to receive traffic from the wider Internet. That is a scalable 186 00:20:44,039 --> 00:20:50,559 redundant and highly available VPC component, so although it appears to be a 187 00:20:50,559 --> 00:20:56,710 single point of failure in reality it is actually a highly available and fault 188 00:20:56,710 --> 00:21:02,980 tolerant VPC component that won't go down on you. It provides a target in your 189 00:21:02,980 --> 00:21:09,429 VPC and you define that in your route tables for internet routable traffic. 190 00:21:09,429 --> 00:21:13,779 If you want traffic to go out to the wider internet you need to put in an 191 00:21:13,779 --> 00:21:19,029 entry in your route table, and we'll talk about that soon, to get to that internet 192 00:21:19,029 --> 00:21:26,259 gateway. It also performs network address translation or NAT so if your instance 193 00:21:26,259 --> 00:21:30,009 has a public IP address and, if it's a web server it will no doubt have a 194 00:21:30,009 --> 00:21:36,039 public IP address, so when the internet gateway receives traffic for that public 195 00:21:36,039 --> 00:21:42,070 IP address it will do network address translation. It will forward that on to 196 00:21:42,070 --> 00:21:53,759 the private IP address of that EC2 instance in your VPC. If you don't want 197 00:21:53,759 --> 00:22:00,190 public access to your your private network what you can do is that you can, 198 00:22:00,190 --> 00:22:06,269 instead of using an Internet gateway, you can use a virtual private network or 199 00:22:06,269 --> 00:22:11,259 create a virtual private network. To do that that will consist of a virtual 200 00:22:11,259 --> 00:22:17,009 private gateway and a customer gateway and a VPN connection between those two. 201 00:22:17,009 --> 00:22:22,330 The virtual private gateway that is the VPN 202 00:22:22,330 --> 00:22:28,510 concentrator that's on the Amazon side of that VPN connection, and the customer 203 00:22:28,510 --> 00:22:34,179 gateway that is at your remote premises. If it's a data center for example you 204 00:22:34,179 --> 00:22:37,990 would have a customer gateway which could be a software application or it 205 00:22:37,990 --> 00:22:44,950 could be a physical hardware device that connects to that VPN. Now looking at that 206 00:22:44,950 --> 00:22:48,429 diagram there we can see that we've got our Virtual Private Gateway, we've got 207 00:22:48,429 --> 00:22:52,450 our customer gateway and, we've got our VPN connection between the two. You 208 00:22:52,450 --> 00:22:55,299 may ask "Isn't that a single point of failure?" 209 00:22:55,299 --> 00:23:00,250 What happens if our virtual private gateway goes down or any one of those 210 00:23:00,250 --> 00:23:05,590 components goes down? You may think that we've got no redundancy there but 211 00:23:05,590 --> 00:23:11,740 in reality the VPN connection is a dual tunnel connection and the Virtual 212 00:23:11,740 --> 00:23:17,289 Private Gateway will connect to both of those tunnels on that VPN 213 00:23:17,289 --> 00:23:24,519 connection, and it will also address two public IP addresses. So if you wanted to 214 00:23:24,519 --> 00:23:28,899 take advantage of that dual tunnel connection and that dual tunnel traffic 215 00:23:28,899 --> 00:23:34,029 all you need to do is to attach another customer gateway so you've got two 216 00:23:34,029 --> 00:23:38,889 customer gateways then you will have both of those tunnels in that VPN 217 00:23:38,889 --> 00:23:43,720 connection used and you will have redundancy there, you will 218 00:23:43,720 --> 00:23:48,850 not have a single point of failure. Other options that are available, if 219 00:23:48,850 --> 00:23:53,500 you're looking for a very high-speed connection to the AWS network, that is 220 00:23:53,500 --> 00:23:59,230 going to be private, then by all means consider AWS Direct Connect. That is 221 00:23:59,230 --> 00:24:02,519 what you would consider if you had a large enterprise that wanted a 222 00:24:02,519 --> 00:24:11,740 high-speed private connection to AWS. We already know by now that we can use 223 00:24:11,740 --> 00:24:18,669 an Internet gateway for public access to the wider Internet. We also know from our 224 00:24:18,669 --> 00:24:23,710 our experience from launching EC2 instances with WordPress that we need to 225 00:24:23,710 --> 00:24:28,570 have a public IP address so that web server can be found on the wider 226 00:24:28,570 --> 00:24:35,830 Internet but, we also need to define a route from our VPC 227 00:24:35,830 --> 00:24:42,220 subnet through to our internet gateway. Without that our traffic 228 00:24:42,220 --> 00:24:47,470 won't get routed through our VPC. The way that we do that is that we use a 229 00:24:47,470 --> 00:24:55,059 route table and we create a custom route table entry that will point to that 230 00:24:55,059 --> 00:25:02,049 internet gateway and it will be explicitly associated to the subnets 231 00:25:02,049 --> 00:25:07,149 that are containing those instances that need public access. So we're launching 232 00:25:07,149 --> 00:25:12,429 EC2 instances into a subnet we need to make sure that there is a route table 233 00:25:12,429 --> 00:25:18,760 associated to that subnet that has an entry that points to the Internet 234 00:25:18,760 --> 00:25:25,110 gateway for traffic that is destined for the wider Internet. 235 00:25:25,110 --> 00:25:33,760 If you don't specifically or explicitly define a route table with a subnet by 236 00:25:33,760 --> 00:25:40,090 default when you create a VPC a route table called the main route table will 237 00:25:40,090 --> 00:25:46,690 be automatically created and, if you don't associate or explicitly associate 238 00:25:46,690 --> 00:25:52,000 a route table to a subnet then by default the main route table will be 239 00:25:52,000 --> 00:25:56,230 associated to it. So by default that will allow all 240 00:25:56,230 --> 00:26:04,480 local traffic within the VPC but it will not allow any traffic to the wider 241 00:26:04,480 --> 00:26:09,010 internet. That is how you create a private subnet is that you use a main 242 00:26:09,010 --> 00:26:14,279 route table and so that will be implicitly associated to all subnets 243 00:26:14,279 --> 00:26:22,450 only unless you explicitly associate a different route table to that subnet. 244 00:26:22,450 --> 00:26:27,639 A custom route table it is also automatically created when you create a 245 00:26:27,639 --> 00:26:33,610 VPC with the VPC wizard so it will automatically create an Internet gateway 246 00:26:33,610 --> 00:26:38,080 it will automatically create a custom route table and it will also create a 247 00:26:38,080 --> 00:26:43,320 route entry within that route table that will point from your public subnet 248 00:26:43,320 --> 00:26:49,000 through to that internet gateway. That will allow local traffic within the 249 00:26:49,000 --> 00:26:52,070 VPC. It will create a route to the public 250 00:26:52,070 --> 00:26:57,649 Internet gateway and it will be explicitly associated to the public 251 00:26:57,649 --> 00:27:05,440 subnet that is if you use a VPC wizard and you ask it to create a public subnet. 252 00:27:07,149 --> 00:27:12,139 If we have a look at the table below we've got 2 253 00:27:12,139 --> 00:27:18,409 sample route entries in a route table. The first one there is the main route 254 00:27:18,409 --> 00:27:23,779 table and that is automatically created for you when you create a VPC and if you 255 00:27:23,779 --> 00:27:28,639 don't associate a route table to a subnet then that will be automatically 256 00:27:28,639 --> 00:27:35,479 associated for you. That will have destination of 10.0.0.0/16. That is if 257 00:27:35,479 --> 00:27:41,359 your VPC is within that range if it's 172 dot whatever then it will say that 258 00:27:41,359 --> 00:27:46,999 there but all the traffic that is destined within that VPC will be 259 00:27:46,999 --> 00:27:54,259 allowed, any traffic that is outside of that VPC will not be allowed as opposed 260 00:27:54,259 --> 00:27:59,509 to the next route table entry there which is for a custom route table. So 261 00:27:59,509 --> 00:28:04,999 that again allows traffic within the VPC, between subnets within that local 262 00:28:04,999 --> 00:28:10,639 VPC that's fine, but it also allows traffic to the wider internet. We can 263 00:28:10,639 --> 00:28:17,509 see there 0 0 0 0 /0. It also allows that to go through the internet gateway 264 00:28:17,509 --> 00:28:23,059 and so we've defined a route for all of that public or that wider Internet 265 00:28:23,059 --> 00:28:31,129 traffic to go through the internet gateway within our VPC. We have two 266 00:28:31,129 --> 00:28:35,450 different types of subnets that are available to us. We have public subnets 267 00:28:35,450 --> 00:28:41,179 that can retrieve traffic from the wider internet from outside of our VPC and we 268 00:28:41,179 --> 00:28:46,669 have private subnets that can only allow traffic within that VPC. So there we 269 00:28:46,669 --> 00:28:53,479 can see we've got our VPC which is 10.0.0.0/16 and within there we've 270 00:28:53,479 --> 00:29:00,259 got a route table explicitly associated to our public subnet and that is 271 00:29:00,259 --> 00:29:03,170 allowing local traffic within the 272 00:29:03,170 --> 00:29:09,290 VPC but it's also allowing traffic through to the wider Internet through to 273 00:29:09,290 --> 00:29:16,100 our Internet gateway. On the right there we've got a private subnet so that does 274 00:29:16,100 --> 00:29:22,190 not have a route to an Internet gateway and so that cannot have or the instances 275 00:29:22,190 --> 00:29:26,570 inside of that cannot have access through to the wider Internet and vice 276 00:29:26,570 --> 00:29:31,580 versa and, they cannot receive traffic from the wider Internet and so that is 277 00:29:31,580 --> 00:29:37,460 if we just create a subnet that is what our some that will look like it will be 278 00:29:37,460 --> 00:29:44,840 by default a private subnet until we explicitly associate a route table that 279 00:29:44,840 --> 00:29:50,990 makes it a public subnet, and by being a public subnet it will have a route from 280 00:29:50,990 --> 00:30:00,920 that subnet through to the Internet gateway. Now if you create a private 281 00:30:00,920 --> 00:30:07,610 subnet and for example you launch a database application on ec2 for example 282 00:30:07,610 --> 00:30:14,090 it could be MongoDB. That application that's running on the EC2 in that 283 00:30:14,090 --> 00:30:22,850 private subnet will need to download its updates from the wider Internet but if 284 00:30:22,850 --> 00:30:28,190 that EC2 instance is located in a private subnet that can't occur because 285 00:30:28,190 --> 00:30:32,810 we're not going to have a route to the Internet and it's going to be a private 286 00:30:32,810 --> 00:30:35,230 something that's not going to allow that to happen. 287 00:30:35,230 --> 00:30:42,290 Also there are a number of AWS services that may require access to the wider Internet 288 00:30:42,290 --> 00:30:46,970 A good example of that is elastic beanstalk. So you might want to 289 00:30:46,970 --> 00:30:53,840 launch this MongoDB application on Elastic Beanstalk and it won't work 290 00:30:53,840 --> 00:30:58,990 because Elastic Beanstalk needs to have access to the Internet gateway. 291 00:30:58,990 --> 00:31:06,260 So when you create a private subnet it is always a very good idea to also launch 292 00:31:06,260 --> 00:31:14,090 either a NAT server or a NAT gateway. What that does with, for example a NAT 293 00:31:14,090 --> 00:31:20,010 server, you can launch an EC2 instance that will have a NAT server AMI that 294 00:31:20,010 --> 00:31:26,700 will be running on it and that will have a route in a public subnet to the 295 00:31:26,700 --> 00:31:30,690 Internet gateway. So that NAT instance will have access to the wider 296 00:31:30,690 --> 00:31:37,140 Internet and your Elastic Beanstalk or your EC2 environment or whatever it is, 297 00:31:37,140 --> 00:31:43,950 that needs to download updates from the wider Internet, can connect privately to 298 00:31:43,950 --> 00:31:48,690 that NAT instance and can download those updates. That way you 299 00:31:48,690 --> 00:31:54,120 get all the benefits of having a private subnet but your resources inside of 300 00:31:54,120 --> 00:32:01,490 there can contact the wider Internet to receive any data or any application 301 00:32:01,490 --> 00:32:06,870 uploads or updates that it needs. So you have two options here. You have an 302 00:32:06,870 --> 00:32:13,940 option to launch an EC2 instance in a public subnet or you can launch a NAT 303 00:32:13,940 --> 00:32:19,350 Gateway and so that is a highly available service it's a serverless service. 304 00:32:19,350 --> 00:32:24,210 It's a lot more expensive than running just a simple micro EC2 instance, so you 305 00:32:24,210 --> 00:32:28,890 need to take into consideration how much traffic and how much bandwidth you're 306 00:32:28,890 --> 00:32:33,720 going to need because all it's basically doing is providing a proxy from your 307 00:32:33,720 --> 00:32:40,110 private subnet through to the wider Internet. Okay so looking at the NAT 308 00:32:40,110 --> 00:32:45,570 Gateway side of things there, we've got a VPC main route table now that will be 309 00:32:45,570 --> 00:32:50,640 implicitly associated to the private subnet and our elastic beanstalk 310 00:32:50,640 --> 00:32:55,380 environment is inside of that private subnet. The Elastic Beanstalk service 311 00:32:55,380 --> 00:33:00,120 needs access to the wider internet no matter what it's doing it will need 312 00:33:00,120 --> 00:33:06,419 access and so if you don't have either a NAT server or a NAT 313 00:33:06,419 --> 00:33:12,390 Gateway it won't work. So that main route table will of course have its local 314 00:33:12,390 --> 00:33:19,740 traffic allowed but it will also allow outgoing traffic to the wider Internet 315 00:33:19,740 --> 00:33:26,520 but it will need to go through to the NAT gateway that will be located inside 316 00:33:26,520 --> 00:33:30,900 of that public subnet. On the right there we've got a net instance. 317 00:33:30,900 --> 00:33:34,320 We could launch a very small NAT instance a micro instance or something 318 00:33:34,320 --> 00:33:38,370 like that to keep the cost down. If we didn't need a highly available solution 319 00:33:38,370 --> 00:33:43,380 like a NAT gateway and again so that wider all that traffic that needs to 320 00:33:43,380 --> 00:33:49,350 come in from the wider internet will have a target route table 321 00:33:49,350 --> 00:33:54,330 entry they're pointing to the elastic network interface a network interface 322 00:33:54,330 --> 00:33:59,610 card of that NAT instance and so all traffic will go through to that NAT 323 00:33:59,610 --> 00:34:04,260 instance it will act as a proxy through to the wider Internet. 324 00:34:04,260 --> 00:34:09,870 So the Golden Rule, if you're creating a private subnet it is always a good 325 00:34:09,870 --> 00:34:16,110 practice to either create a NAT instance in the public subnet or a NAT gateway as 326 00:34:16,110 --> 00:34:21,360 well because if you don't and you run into problems they can be very difficult 327 00:34:21,360 --> 00:34:29,460 to troubleshoot. AWS has a very broad range of security offerings that are 328 00:34:29,460 --> 00:34:35,669 available that you can use within a V PC but the three core services that you 329 00:34:35,669 --> 00:34:39,960 need to really understand and that is, first of all, security groups that you 330 00:34:39,960 --> 00:34:44,760 apply or you associate to an instance. You can associate the same security 331 00:34:44,760 --> 00:34:50,310 group to multiple instances but they're associated at the instance level and 332 00:34:50,310 --> 00:34:56,010 they act as a firewall for that instance. You can also have network access control 333 00:34:56,010 --> 00:35:02,700 lists or NACLs. Now they will operate as a firewall, again similar to security 334 00:35:02,700 --> 00:35:08,670 groups, but they operate at the subnet. So you define them at a subnet and any 335 00:35:08,670 --> 00:35:14,120 instance that is located within that subnet will have the protection from 336 00:35:14,120 --> 00:35:19,980 that network access control list. Finally we've got flow logs. They can 337 00:35:19,980 --> 00:35:26,400 capture information as cloudwatch logs. If you have some unusual activity you 338 00:35:26,400 --> 00:35:29,910 can go and have a look at those flow logs and see what's going on. You 339 00:35:29,910 --> 00:35:32,940 might be getting hit with a DDoS attack or something. That will be picked up 340 00:35:32,940 --> 00:35:40,920 on those flow logs. One thing that a lot of students seem to get a 341 00:35:40,920 --> 00:35:44,490 little bit confused around is what is the difference between a secure 342 00:35:44,490 --> 00:35:51,920 group and a network access control list? First off as we stated before a 343 00:35:51,920 --> 00:35:57,960 security group it operates at the instance level. You associate a 344 00:35:57,960 --> 00:36:04,860 security group to a particular instance or multiple instances. A network ACL 345 00:36:04,860 --> 00:36:11,490 that operates at the sub net level. If you define a subnet with a network 346 00:36:11,490 --> 00:36:18,869 access control list any instance that is inside of that subnet will receive the 347 00:36:18,869 --> 00:36:24,540 security of that network access control list. A security group it 348 00:36:24,540 --> 00:36:31,080 supports allow rules only. You don't have deny, you only have allow. 349 00:36:31,080 --> 00:36:37,470 If you don't have any allow rules then no traffic will be allowed. You need 350 00:36:37,470 --> 00:36:43,110 to allow traffic in using those security groups with a network access control 351 00:36:43,110 --> 00:36:50,310 list. It has both allow and deny rules and we'll talk a bit about how they work 352 00:36:50,310 --> 00:36:53,400 when they're conflicting. A security group 353 00:36:53,400 --> 00:37:00,000 it's stateful. What that means is that return traffic is automatically allowed. 354 00:37:00,000 --> 00:37:06,359 If an ec2 instance receives traffic that is allowed then the return traffic 355 00:37:06,359 --> 00:37:11,760 that it sends back to that request will also be allowed, its stateful. That's 356 00:37:11,760 --> 00:37:17,730 what we mean by stateful. Network access control list its state less. 357 00:37:17,730 --> 00:37:24,470 Although you may receive traffic, the traffic going the other way to the same 358 00:37:24,470 --> 00:37:30,240 location that you received it from may not necessarily be allowed. 359 00:37:30,240 --> 00:37:36,540 Return traffic as well as incoming traffic must be explicitly allowed by those network 360 00:37:36,540 --> 00:37:43,140 access control list rules. We evaluate the rules differently depending on 361 00:37:43,140 --> 00:37:46,800 whether it's a security group or a network access control there. With a 362 00:37:46,800 --> 00:37:54,390 security group we will evaluate all of the rules before deciding whether 363 00:37:54,390 --> 00:37:58,200 to allow that traffic. If there is more than one 364 00:37:58,200 --> 00:38:03,810 rule for a specific port, because we apply these rules based on a port, it will 365 00:38:03,810 --> 00:38:10,440 apply the most permissive rule. What that means is if you have a rule that allows 366 00:38:10,440 --> 00:38:15,260 everything in and you have another rule that only allows a little bit in 367 00:38:15,260 --> 00:38:20,550 everything will come in. The most permissive, or the least 368 00:38:20,550 --> 00:38:26,369 restrictive, the most permissive will will allow everything in. So that's 369 00:38:26,369 --> 00:38:30,200 something that you need to be very important with security groups. 370 00:38:30,200 --> 00:38:34,320 As opposed to the network access control list that will process the rules in 371 00:38:34,320 --> 00:38:38,730 number order and once it's gone through all of those rules it will make a 372 00:38:38,730 --> 00:38:45,510 decision on whether to allow that traffic in and as opposed to a security 373 00:38:45,510 --> 00:38:50,760 group the most restrictive denied applies. If you have and allow that 374 00:38:50,760 --> 00:38:55,970 allows everything and then you have a deny that restricts everything 375 00:38:55,970 --> 00:39:00,720 nothing will be allowed to come through. That is a very big difference, 376 00:39:00,720 --> 00:39:07,520 the network access control list, the most restrictive deny applies there. 377 00:39:07,520 --> 00:39:13,680 A security group, it applies to an instance only if someone specifies that security 378 00:39:13,680 --> 00:39:19,319 group when you launch that instance or if you associate that 379 00:39:19,319 --> 00:39:25,440 security group with that instance at a later stage. A network ACL is 380 00:39:25,440 --> 00:39:31,650 applied to all instances in that subnet. If you launch an instance inside of a 381 00:39:31,650 --> 00:39:36,060 private subject that has a network access control list, it will receive the 382 00:39:36,060 --> 00:39:41,040 protection of that network access control list. All instances inside of 383 00:39:41,040 --> 00:39:46,740 that subnet will. It acts as a backup layer of defense so you don't have to 384 00:39:46,740 --> 00:39:51,240 rely upon on someone specifying the security group and making a mistake on 385 00:39:51,240 --> 00:39:55,700 that. You can set up a network access control list that can really provide 386 00:39:55,700 --> 00:40:05,400 overall across all of those instances in that subnet a basic level of security. 387 00:40:05,400 --> 00:40:11,450 That brings us to the end of a very long very complicated lecture. I 388 00:40:11,450 --> 00:40:15,020 hope you got a lot out of it and if you're becoming a Cloud practitioner 389 00:40:15,020 --> 00:40:19,340 you just really need to know this high-level stuff. If you're going on to 390 00:40:19,340 --> 00:40:25,010 become an associate level certified with AWS then you're going to need to know 391 00:40:25,010 --> 00:40:30,950 this very well and you also need to know how to apply that as well and if you're 392 00:40:30,950 --> 00:40:33,860 going on to further courses with Backspace' Academy then you will 393 00:40:33,860 --> 00:40:39,410 certainly get a lot more hands-on on how to actually use this stuff as well. So I 394 00:40:39,410 --> 00:40:43,600 look forward to seeing you in the next lecture.