1 00:00:12,620 --> 00:00:18,060 Welcome back to Backspace Academy. In this lecture on Elastic Compute cloud or 2 00:00:18,060 --> 00:00:22,350 ec2 for short, we're going to start off by looking at the different ways that 3 00:00:22,350 --> 00:00:28,080 you can purchase an ec2 server and also look at the different instance types are 4 00:00:28,080 --> 00:00:32,219 available and for the different applications you may use those. Then 5 00:00:32,219 --> 00:00:36,780 we'll look at the instance lifecycle what happens to an instance from when it 6 00:00:36,780 --> 00:00:42,030 is launched through that process through to when it is actually terminated. We'll 7 00:00:42,030 --> 00:00:48,020 look at cluster networking and how we can group clusters of ec2 servers and 8 00:00:48,020 --> 00:00:52,649 interconnect them with high-speed networking. We'll look at the storage 9 00:00:52,649 --> 00:00:58,320 options that are available to attach to our EC2 instances and finally we'll look 10 00:00:58,320 --> 00:01:03,539 at the options that are available for us to connect remotely in to our ec2 server 11 00:01:03,539 --> 00:01:11,070 operating system. There are a number of different options that are available for 12 00:01:11,070 --> 00:01:15,990 us when we're purchasing ec2 servers. Up till now we've been using on-demand 13 00:01:15,990 --> 00:01:19,020 instances and they're the most easy to understand. 14 00:01:19,020 --> 00:01:23,759 We simply launch an instance and from that point onwards we're paying by the 15 00:01:23,759 --> 00:01:29,159 second at a flat rate for that instance. There's no upfront cost for launching it 16 00:01:29,159 --> 00:01:33,990 and there's no cost when we terminate it. We just pay by the second for what we use. 17 00:01:33,990 --> 00:01:41,460 Now for AWS to have capacity available for these on-demand instances 18 00:01:41,460 --> 00:01:48,090 AWS needs to have at a certain level of reserve capacity available to 19 00:01:48,090 --> 00:01:51,780 fulfill that. So if all of a sudden everyone just comes along and wants to 20 00:01:51,780 --> 00:01:56,280 start launching ec2 instances, there needs to be a little bit of reserve 21 00:01:56,280 --> 00:02:02,670 capacity available. Now instead of having that capacity just sitting there doing 22 00:02:02,670 --> 00:02:06,030 nothing what AWS does is that they have 23 00:02:06,030 --> 00:02:11,970 that capacity available for people to bid on and so whoever bids with the 24 00:02:11,970 --> 00:02:16,800 highest price get that capacity and it's a little bit 25 00:02:16,800 --> 00:02:22,950 like eBay for reserve capacity of ec2 and that helps you to significantly 26 00:02:22,950 --> 00:02:28,130 reduce the cost of running instances and it's generally the cheapest option 27 00:02:28,130 --> 00:02:35,640 although not always. The reason is, if all of that capacity has been taken and the 28 00:02:35,640 --> 00:02:40,770 spot price goes through the roof and your maximum spot price is above an 29 00:02:40,770 --> 00:02:48,120 on-demand instance then you're going to be paying a premium for that instance. 30 00:02:48,120 --> 00:02:52,380 So you're really putting down there a maximum price that you are willing to 31 00:02:52,380 --> 00:02:59,490 pay. The downside is that AWS they can take that capacity back whenever they 32 00:02:59,490 --> 00:03:04,710 want and that's called a spot instance interruption and they can also take it 33 00:03:04,710 --> 00:03:11,670 back when the spot price for that next hour exceeds your maximum price. So that 34 00:03:11,670 --> 00:03:17,490 is something that you need to take into consideration. It's really best for batch 35 00:03:17,490 --> 00:03:22,590 type compute processes, for example if you had big data stuff that need to be 36 00:03:22,590 --> 00:03:27,180 processed and once it's processed you don't need that capacity anymore. A spot 37 00:03:27,180 --> 00:03:32,790 instance is great for that. Now if your spot instance is terminated or stopped 38 00:03:32,790 --> 00:03:39,570 by AWS within that first instance hour you won't be charged anything for that usage. 39 00:03:39,570 --> 00:03:45,090 If you terminate that instance within the first error or any other hour 40 00:03:45,090 --> 00:03:51,450 after that you're going to be charged per second or the per nearest second for 41 00:03:51,450 --> 00:03:59,340 the use of that instance. So as we mentioned before there is a significant 42 00:03:59,340 --> 00:04:04,980 amount of reserve capacity available for these on-demand instances and for the 43 00:04:04,980 --> 00:04:12,450 variation in usage of those instances. Now there is also a very unlikely 44 00:04:12,450 --> 00:04:17,310 possibility that that reserved capacity is actually used up as well by all the 45 00:04:17,310 --> 00:04:21,900 on-demand instances. So there are a number of other options that are 46 00:04:21,900 --> 00:04:27,500 available for you to reserve capacity outside of on-demand. 47 00:04:27,500 --> 00:04:34,500 The first option there is a reserved instance. Now what that means is that if 48 00:04:34,500 --> 00:04:40,470 you find that you are going to be using a certain level of capacity of EC2 over 49 00:04:40,470 --> 00:04:45,840 the next year or two years or up to three years, you can go to AWS and say 50 00:04:45,840 --> 00:04:50,460 right I would like to have this capacity available for me for that period of time 51 00:04:50,460 --> 00:04:58,380 and you can use that capacity and, by making that commitment to AWS over that 52 00:04:58,380 --> 00:05:05,300 period of time you are going to get a discount on the cost of your instances. 53 00:05:05,300 --> 00:05:10,410 A scheduled instance is where you can purchase instances but instead of being 54 00:05:10,410 --> 00:05:16,370 over a one year period continuously you can have it over a one year period 55 00:05:16,370 --> 00:05:22,020 intermittently on a schedule, for example you might use it for one day in a month 56 00:05:22,020 --> 00:05:27,180 for, I don't know, accounts processing or something like that and so that will 57 00:05:27,180 --> 00:05:32,790 give you that reserved capacity that you need for that specific time of every 58 00:05:32,790 --> 00:05:39,440 month or week or whatever. On demand capacity reservations are different to 59 00:05:39,440 --> 00:05:45,270 reserved and scheduled instances in that you're not entering into a long term 60 00:05:45,270 --> 00:05:50,610 contract. These reservations are on demand you use them when you need them 61 00:05:50,610 --> 00:05:55,830 or you create a capacity reservation when you need it, when you don't need it 62 00:05:55,830 --> 00:06:00,120 you just stop it and there's no long term contract. 63 00:06:00,120 --> 00:06:05,640 Now the downside is that, it is at the on-demand rate. So you might have a 64 00:06:05,640 --> 00:06:11,970 capacity reservation that you never use but you will still be paying for the 65 00:06:11,970 --> 00:06:17,370 cost of an on-demand instance. So that needs to be taken into consideration 66 00:06:17,370 --> 00:06:23,640 because there is no cost benefit with a on demand capacity reservation but it 67 00:06:23,640 --> 00:06:30,180 does reserve capacity for you in the event that something goes wrong with AWS 68 00:06:30,180 --> 00:06:35,070 and they run out of on-demand instances that are available. You will always have 69 00:06:35,070 --> 00:06:40,470 an on-demand instance of available for you, and finally we have 70 00:06:40,470 --> 00:06:46,320 dedicated instances and dedicated hosts. With a dedicated instance, you're going 71 00:06:46,320 --> 00:06:51,540 to be paying by the hour for an instance that will be running on single tenant 72 00:06:51,540 --> 00:06:56,310 hardware. They will be hardware that only you will be using and we also have 73 00:06:56,310 --> 00:07:01,290 dedicated hosts where you're going to be paying for a physical host that is 74 00:07:01,290 --> 00:07:11,070 fully dedicated to running your dedicated instances. Another way that you 75 00:07:11,070 --> 00:07:18,120 can reduce your ec2 costs is through a savings plan. That allows for reduced 76 00:07:18,120 --> 00:07:24,270 pricing in exchange for consistent usage in dollars per hour over a one or three 77 00:07:24,270 --> 00:07:30,360 year commitment. The difference between this and a reserved instance is that 78 00:07:30,360 --> 00:07:36,150 this is based on your historical usage in the AWS Cost Explorer and those 79 00:07:36,150 --> 00:07:41,370 recommendations within the AWS Cost Explorer will be used as a basis for 80 00:07:41,370 --> 00:07:47,490 that saving plan. There are two types of savings plan you can have. A compute 81 00:07:47,490 --> 00:07:52,110 savings plan, that will be the most flexible and that will apply to all the 82 00:07:52,110 --> 00:07:57,030 different instance types, the size of the instance, the operating system or any 83 00:07:57,030 --> 00:08:03,390 tenancy type, and that is going to provide up to 66% off your normal 84 00:08:03,390 --> 00:08:10,530 on-demand rates. The other option there is an ec2 instance savings plan and that 85 00:08:10,530 --> 00:08:16,320 is applied to an individual instance family, for example if you select an m2 86 00:08:16,320 --> 00:08:21,810 type, and that is applied to a specific region as well and that can provide up 87 00:08:21,810 --> 00:08:28,950 to 72 percent off of the on demand rates. You can also reduce cost depending on 88 00:08:28,950 --> 00:08:33,750 what payment option you come up with. So if you decide to have no upfront payment 89 00:08:33,750 --> 00:08:38,430 and just simply pay on a monthly basis that is one option. If you want to reduce 90 00:08:38,430 --> 00:08:44,130 it from that you can go to a partial upfront cost and that is going to reduce 91 00:08:44,130 --> 00:08:49,620 a price over a no upfront, or you can do everything upfront in one payment and 92 00:08:49,620 --> 00:08:54,270 that will provide you with the lowest price of your savings plan. 93 00:08:54,270 --> 00:09:00,300 Another thing to take into consideration is that a savings plan does not provide 94 00:09:00,300 --> 00:09:05,490 capacity reservations, but that said there is nothing stopping you from 95 00:09:05,490 --> 00:09:11,610 including your capacity reserved instances into a savings plan, but the 96 00:09:11,610 --> 00:09:19,110 savings plan itself does not provide that capacity reservation. To prepare 97 00:09:19,110 --> 00:09:23,280 for the cloud practitioner exam you will need to understand these different 98 00:09:23,280 --> 00:09:27,320 reserving options that are available, but it can be a little bit confusing. 99 00:09:27,320 --> 00:09:32,400 So having a look here, I've got the capacity reservations and the two different types 100 00:09:32,400 --> 00:09:37,170 of reserved instances. So we have reserved instances that are reserved 101 00:09:37,170 --> 00:09:41,310 based upon an availability zones they're the zonal reserved instances we have 102 00:09:41,310 --> 00:09:47,160 regional reserved instances that are reserved within a specific region and 103 00:09:47,160 --> 00:09:53,010 then finally we've had our Savings Plan. The first point there is the term with a 104 00:09:53,010 --> 00:09:57,870 capacity reservation there is no long-term commitment required, whereas 105 00:09:57,870 --> 00:10:03,060 with the others there is a required either a fixed one year or a three-year 106 00:10:03,060 --> 00:10:10,110 commitment, with capacity benefits the capacity reservations and the zonal 107 00:10:10,110 --> 00:10:17,820 reserved instances they reserve capacity within a specific availability zone but 108 00:10:17,820 --> 00:10:23,520 if you're going for a regional reserved instance not a zonal reserved instance 109 00:10:23,520 --> 00:10:28,140 that will not provide capacity in that availability zone. So although you're 110 00:10:28,140 --> 00:10:33,270 going to get the cost benefits that capacity will not be reserved. The same 111 00:10:33,270 --> 00:10:38,670 again with a savings plan. That does not provide a capacity reservation but with 112 00:10:38,670 --> 00:10:43,890 a savings plan you can always include as part of that savings plan a capacity 113 00:10:43,890 --> 00:10:49,530 reservation as well. Capacity reservations do not provide for a 114 00:10:49,530 --> 00:10:55,170 billing and discount but that said you can use capacity reservations with a 115 00:10:55,170 --> 00:11:01,530 savings plan or as part of a regional reserved instance plan as well. So both 116 00:11:01,530 --> 00:11:07,020 the zonal reserved instance and the regional reserved instances and the 117 00:11:07,020 --> 00:11:12,110 savings plan all the those provide for a billing discount, and 118 00:11:12,110 --> 00:11:16,290 finally there are different instance limits that are applied to these 119 00:11:16,290 --> 00:11:20,940 different plans as well. So if you're going for a capacity reservation that is 120 00:11:20,940 --> 00:11:25,740 simply going to be limited by your ec2 on-demand instance limits which are 121 00:11:25,740 --> 00:11:30,300 applied per region. If you're going for a zonal reserved instance that's going to 122 00:11:30,300 --> 00:11:35,790 be limited to 20 per availability zone. If it's a regional reserved instance 123 00:11:35,790 --> 00:11:40,740 that will be limited to 20 per region but both of those if you find that you 124 00:11:40,740 --> 00:11:45,540 need to exceed that, you need more than 20, you can put in an application to AWS 125 00:11:45,540 --> 00:11:51,750 support to have that limit increase effected for you, and with a savings plan 126 00:11:51,750 --> 00:11:56,310 there is no limit on the amount of instances that can be applied to that 127 00:11:56,310 --> 00:12:02,790 savings plan. There are a number of different instance types that are 128 00:12:02,790 --> 00:12:07,290 available for us to select with ec2. The first one and the one that we've been 129 00:12:07,290 --> 00:12:13,080 using so far is the general-purpose types they're great for as a name 130 00:12:13,080 --> 00:12:18,720 suggests for general-purpose databases data processing tasks, back-end servers 131 00:12:18,720 --> 00:12:23,310 and the like. The next one there is compute optimized. It's going to have 132 00:12:23,310 --> 00:12:28,230 a lot of compute capacity available and that's going to be good for web servers, 133 00:12:28,230 --> 00:12:33,690 for batch processing and the like. Memory optimize is great for high performance 134 00:12:33,690 --> 00:12:40,230 databases and for in-memory cases where we need to respond very quickly to 135 00:12:40,230 --> 00:12:45,330 requests instead of having to go back to a hard disk to retrieve that that 136 00:12:45,330 --> 00:12:50,190 information, and we've got GPU or graphics processing units and 137 00:12:50,190 --> 00:12:55,710 accelerator computing instant types and they're great for 3d applications, for 138 00:12:55,710 --> 00:13:01,550 video encoding, they're great for machine learning and AI applications as well, and 139 00:13:01,550 --> 00:13:06,840 finally we've got storaged optimized which is going to be great for your Big 140 00:13:06,840 --> 00:13:12,420 Data stuff. It's going to be great for no SQL databases, for MongoDB, it's going 141 00:13:12,420 --> 00:13:17,250 to be great for elastic MapReduce, for data warehousing anything that requires 142 00:13:17,250 --> 00:13:21,990 a large amount of storage. Now with all these ec2 instance types 143 00:13:21,990 --> 00:13:27,330 we have a choice of Linux and a whole heap of varieties of Linux or 144 00:13:27,330 --> 00:13:31,680 Windows Server and if you want more information on those types there is a 145 00:13:31,680 --> 00:13:39,450 link there to the ec2 instance types page. The instance types that we've 146 00:13:39,450 --> 00:13:45,959 looked at previously are running under a virtualized environment. So what that 147 00:13:45,959 --> 00:13:52,470 means is that the ec2 service has physical hardware and on top of that 148 00:13:52,470 --> 00:13:59,640 hardware is running a hypervisor and on top of that hypervisor are virtualized 149 00:13:59,640 --> 00:14:06,360 servers running on that, and so a Linux operating system is not actually running 150 00:14:06,360 --> 00:14:13,020 on physical Hardware it's running on a hypervisor a virtual environment and 151 00:14:13,020 --> 00:14:19,649 that goes the same whether it's Windows or Linux under EC2. EC2 bare metal 152 00:14:19,649 --> 00:14:24,899 instances are running on a non virtualized environment and the 153 00:14:24,899 --> 00:14:33,270 operating system is running directly on that ec2 physical Hardware. It's 154 00:14:33,270 --> 00:14:40,050 particularly suitable for applications that benefit from deep analysis of the 155 00:14:40,050 --> 00:14:46,170 performance of the underlying hardware or specialized workloads that require 156 00:14:46,170 --> 00:14:53,430 direct access to that physical hardware as well. There could be legacy workloads 157 00:14:53,430 --> 00:14:57,690 that are just not running on a virtualized environment and you need to 158 00:14:57,690 --> 00:15:03,320 have the actual access to a physical environment to run it. There may also be 159 00:15:03,320 --> 00:15:10,230 licensing restricted applications that rely upon that physical hardware for 160 00:15:10,230 --> 00:15:18,120 license validation. Examples of bare metal instances are the i3, m5 metal, r5 161 00:15:18,120 --> 00:15:23,660 metal and z1 D metal instance types. 162 00:15:24,260 --> 00:15:30,960 The t2 burstable performance instances now they don't blow up on you they don't 163 00:15:30,960 --> 00:15:35,940 explode or burst but they're a very important instance that you need to 164 00:15:35,940 --> 00:15:39,810 understand. So what burstable means is that this 165 00:15:39,810 --> 00:15:46,050 instance will operate at what we define as a baseline performance but it will 166 00:15:46,050 --> 00:15:52,260 have an ability to burst above that for a short period of time if need be, and 167 00:15:52,260 --> 00:15:58,410 that will be governed by what we call CPU credits. So the more CPU credits that 168 00:15:58,410 --> 00:16:02,730 we have available the longer that we can burst and for the most amount that we 169 00:16:02,730 --> 00:16:07,380 can burst above our baseline performance. So that's great 170 00:16:07,380 --> 00:16:12,120 if we have demand that is not predictable, it's a bit all over the place, 171 00:16:12,120 --> 00:16:19,040 but we kind of know where our average for that 24-hour period is. 172 00:16:19,040 --> 00:16:24,570 T2 instances are great when used with an auto scaling group because when an 173 00:16:24,570 --> 00:16:31,260 instance is launched it may take 15, 20, 25 minutes or whatever to go through 174 00:16:31,260 --> 00:16:37,680 that whole launch process that may be required. So that may be too long and by 175 00:16:37,680 --> 00:16:45,120 that period of time that burst of demand has disappeared. So the t2 burstable 176 00:16:45,120 --> 00:16:49,950 performance instance will fill that void and provide instantaneous 177 00:16:49,950 --> 00:16:56,460 response to that increased demand. Credits they're built up over a 24-hour 178 00:16:56,460 --> 00:17:03,030 period. So if you stay below that baseline you're going to build up 179 00:17:03,030 --> 00:17:08,010 credits for every hour that you are under that baseline and then you can use 180 00:17:08,010 --> 00:17:13,770 those credits where needed to burst above that baseline capacity, and after 181 00:17:13,770 --> 00:17:20,490 the 24-hour period that will be reset. Now if you're finding that you're never 182 00:17:20,490 --> 00:17:26,520 having enough CPU credit balance to burst, that means that the average demand 183 00:17:26,520 --> 00:17:30,440 that you're getting over that period of time, that 24 hour period of time, 184 00:17:30,440 --> 00:17:35,730 is above what your baseline capacity that you're paying for is. So you need to 185 00:17:35,730 --> 00:17:39,720 consider upgrading to a larger instance to keep 186 00:17:39,720 --> 00:17:45,390 below that baseline capacity. Now there's another option there called the t2 187 00:17:45,390 --> 00:17:52,140 unlimited and that will provide that burstable high CPU availability and a 188 00:17:52,140 --> 00:18:01,290 flat additional rate of five cents per Vcpu hour, and that is for as long as you 189 00:18:01,290 --> 00:18:06,330 need it. So instead of building up CPU credits, you just get billed for what you use. 190 00:18:06,330 --> 00:18:14,430 Graviton instance types they are based upon a 64-bit ARM Neoverse core. 191 00:18:14,430 --> 00:18:19,500 If you've used a Raspberry Pi before you have obviously taken advantage of an ARM 192 00:18:19,500 --> 00:18:26,130 Cortex core that provides very low cost high performance but this is a ARM 193 00:18:26,130 --> 00:18:31,950 Neoverse cores and are optimized for large infrastructures such as cloud 194 00:18:31,950 --> 00:18:37,230 infrastructure, and they will provide a very low cost and high performance 195 00:18:37,230 --> 00:18:42,000 compute capacity. So if you have something that is really compute 196 00:18:42,000 --> 00:18:47,850 intensive and it will run on an ARM core then by all means use that and it will 197 00:18:47,850 --> 00:18:53,340 provide a fantastic performance for you at a much more reasonable cost. 198 00:18:53,340 --> 00:18:57,450 The first-generation are called the a1 instance type and the second generation 199 00:18:57,450 --> 00:19:04,470 are the graviton2 processors and they can provide up to 40% better price 200 00:19:04,470 --> 00:19:12,120 performance over the comparable current generation x86 based instances. 201 00:19:12,120 --> 00:19:17,520 Graviton instances are perfect for scale out applications that can run on multiple 202 00:19:17,520 --> 00:19:23,310 small cores, but you need to take into consideration that not all software will 203 00:19:23,310 --> 00:19:28,920 run on an ARM core, but if it does, this is a great option for compute intensive 204 00:19:28,920 --> 00:19:35,640 applications. If you find that you want to have a mix 205 00:19:35,640 --> 00:19:40,470 of different instance types and you might have a mix of on-demand and spot 206 00:19:40,470 --> 00:19:47,820 instance options available you can create an ec2 fleet of instances, and you 207 00:19:47,820 --> 00:19:54,150 can create an unlimited number of instance types per ec2 fleet. So you can 208 00:19:54,150 --> 00:20:00,120 mix and match. You can put a t2 in there with a m1 whatever and you have the 209 00:20:00,120 --> 00:20:04,980 choice of mixing both on-demand instances and spot instances. So you can 210 00:20:04,980 --> 00:20:10,350 have a baseline capacity there but you can also have also spot instances 211 00:20:10,350 --> 00:20:16,800 available in that ec2 fleet as well. So it's only available through using the 212 00:20:16,800 --> 00:20:22,020 AWS API or one of the software development kits or using the 213 00:20:22,020 --> 00:20:26,580 command-line interface. You cannot do this through the console and it's 214 00:20:26,580 --> 00:20:32,520 available across multiple availability zones but not across multiple regions. So 215 00:20:32,520 --> 00:20:38,040 you need to create an ec2 fleet in each region if you want to have that 216 00:20:38,040 --> 00:20:44,630 happening in each region, and there's no additional charge for using EC2 fleet. 217 00:20:47,399 --> 00:20:53,769 We already know what an Amazon machine image is or an AMI we have used an AMI 218 00:20:53,769 --> 00:20:59,109 to launch a wordpress server and we know that it provides the information 219 00:20:59,109 --> 00:21:05,229 that is required to launch that instance, and that includes a template for the 220 00:21:05,229 --> 00:21:09,399 root volume of that instance, for example the operating system will have 221 00:21:09,399 --> 00:21:15,129 the Linux operating system, it will have the WordPress application there that 222 00:21:15,129 --> 00:21:19,629 will be required, that goes on that root volume. It will also have launch 223 00:21:19,629 --> 00:21:25,629 permissions for the AMI. So if it's a public AMI it will have availability to 224 00:21:25,629 --> 00:21:31,570 all AWS accounts. If it's a private one it will be private to that AWS account 225 00:21:31,570 --> 00:21:37,419 or certain AWS accounts. It will also have a block device mapping and that 226 00:21:37,419 --> 00:21:42,849 will specify any volumes that are attached to that instance when it's 227 00:21:42,849 --> 00:21:49,570 launched. We have the AWS marketplace where people can put AMIs on there and 228 00:21:49,570 --> 00:21:54,190 sell them or give them away for free. So they can be paid, they can be free, they 229 00:21:54,190 --> 00:22:00,789 can be trial versions of AMI or of software or they could be BYO license 230 00:22:00,789 --> 00:22:04,239 software, for example it could be an Oracle database saying you bring your 231 00:22:04,239 --> 00:22:09,249 own license to use it, and so you can normally find a great deal of 232 00:22:09,249 --> 00:22:13,599 applications on that AWS marketplace and we've already used that before because 233 00:22:13,599 --> 00:22:20,679 we've used it to launch a WordPress application. There are a number of 234 00:22:20,679 --> 00:22:28,479 different states of an ec2 instance depending on whether the root volume of 235 00:22:28,479 --> 00:22:35,639 the instance is an EBS or elastic block storage type and we'll talk more about 236 00:22:35,639 --> 00:22:41,559 EBS and instance store volumes but if you have an EBS type you can actually 237 00:22:41,559 --> 00:22:47,679 stop and start those instances but you can't do that if you have an instance 238 00:22:47,679 --> 00:22:53,200 store type of root volume attached to that instance. So with an EBS backed 239 00:22:53,200 --> 00:22:57,700 instance you can stop it and their instance will be shut down and you're 240 00:22:57,700 --> 00:23:02,680 not going to be get getting any more instance charges but you will still be 241 00:23:02,680 --> 00:23:11,410 charged for any EBS volumes or any drives, volumes that are attached to that ec2 242 00:23:11,410 --> 00:23:17,530 instance, and if you stop an instance in less than one minute then you're still 243 00:23:17,530 --> 00:23:21,850 going to be charged for that one minute when you restart it. There is another 244 00:23:21,850 --> 00:23:25,930 option and that is stop hibernate and again it's only for EBS backed 245 00:23:25,930 --> 00:23:31,900 volumes and that is very good because it will suspend all of your RAM to disk. So 246 00:23:31,900 --> 00:23:38,560 it will save your RAM to the EBS volume. So it will allow for your instance to 247 00:23:38,560 --> 00:23:44,170 come back online very quickly and it will keep all of that session data that 248 00:23:44,170 --> 00:23:50,710 was stored in that RAM. The other option there is that we can reboot and an 249 00:23:50,710 --> 00:23:54,910 instance and we can do that for either an EBS or an instance store backed 250 00:23:54,910 --> 00:24:00,220 volume and that is simply an operating system reboot, and finally we can 251 00:24:00,220 --> 00:24:08,080 terminate those instances when we don't need them anymore. Ok so first off we can 252 00:24:08,080 --> 00:24:14,500 use our ami to launch an ec2 instance, while that instance is launching it will 253 00:24:14,500 --> 00:24:20,890 have the state of pending, after a period of time it will then transition to the 254 00:24:20,890 --> 00:24:25,270 running state after it's done all of its checks, while it's running we have an 255 00:24:25,270 --> 00:24:29,560 option there to reboot the operating system, we can do that no matter what 256 00:24:29,560 --> 00:24:35,980 type of instance at it is it's simply an operating system reboot, if we have an 257 00:24:35,980 --> 00:24:41,770 EBS backed instance and not an instance source instance we have the opportunity 258 00:24:41,770 --> 00:24:46,900 there to stop that instance when we're not using it and then restart it later 259 00:24:46,900 --> 00:24:51,730 on, it'll go back to that pending stage and then obviously on to running again, 260 00:24:51,730 --> 00:24:57,520 and finally we can issue a terminate command and while that terminate is in 261 00:24:57,520 --> 00:25:02,230 process it will be at the status of shutting down and then it will 262 00:25:02,230 --> 00:25:07,050 transition to terminated after that. 263 00:25:10,010 --> 00:25:16,770 If you require a cluster of ec2 instances that need to be connected 264 00:25:16,770 --> 00:25:22,980 between each other with high-speed networking, you can place those inside of 265 00:25:22,980 --> 00:25:32,610 an ec2 placement group. An ec2 placement group will provide a low network latency 266 00:25:32,610 --> 00:25:38,550 it will be using a 10 gig interconnect between those instances which will allow 267 00:25:38,550 --> 00:25:44,730 for a high network throughput. It's available for all instances that support 268 00:25:44,730 --> 00:25:51,510 enhanced networking. It can't span multiple availability zones. The cluster 269 00:25:51,510 --> 00:25:57,090 or the placement group must be in a single availability zone but it can span 270 00:25:57,090 --> 00:26:04,860 a peared VPC but you're not going to get that full bandwidth between that cluster 271 00:26:04,860 --> 00:26:12,510 and you cannot merge placement groups. The enhanced networking required within 272 00:26:12,510 --> 00:26:19,370 a placement group uses single route IO virtualization or SI-IOV for short and 273 00:26:19,370 --> 00:26:26,670 it provides a higher IO performance and lower CPU utilization at no additional 274 00:26:26,670 --> 00:26:33,300 charge. It's supported in a number of instances but not all of them and it 275 00:26:33,300 --> 00:26:38,880 requires an EBS optimized instance and they are designed to deliver the 276 00:26:38,880 --> 00:26:48,320 provisioned IOPS that you specified for 99.9% of the time that they're operating. 277 00:26:52,910 --> 00:26:59,690 There are two options available for storage directly to an ec2 instance and 278 00:26:59,690 --> 00:27:05,520 that's not including the external storage for example using an Amazon s3 279 00:27:05,520 --> 00:27:11,280 bucket or using elastic file service. So the two options there are elastic block 280 00:27:11,280 --> 00:27:18,870 store or instant store. Now the EBS is the most common type and and maybe as 281 00:27:18,870 --> 00:27:24,780 volume will be replicated within an availability zone which is great so if 282 00:27:24,780 --> 00:27:32,070 your drive fails there will be another copy in another availability zone. Now 283 00:27:32,070 --> 00:27:38,750 the EBS volumes if they're attached at instance launch they will be by default 284 00:27:38,750 --> 00:27:44,490 deleted when that instance is terminated. Now that is a default behavior and you 285 00:27:44,490 --> 00:27:50,190 can modify that by changing the delete on terminate checkbox in the console or 286 00:27:50,190 --> 00:27:53,669 the delete on terminate flag if you're using the 287 00:27:53,669 --> 00:28:00,150 command line interface or an SDK. The EBS volumes that are attached to a 288 00:28:00,150 --> 00:28:06,030 running instance are not deleted by default when the instance is terminated 289 00:28:06,030 --> 00:28:11,280 but they will be detached with that data intact and you will still be getting 290 00:28:11,280 --> 00:28:17,250 billed for those abs volumes even though you won't be getting billed for that ec2 291 00:28:17,250 --> 00:28:24,590 instance, but again that behavior can be modified on the delete on terminate flag. 292 00:28:24,590 --> 00:28:30,809 Instance store volumes they are physically attached to that host ec2 293 00:28:30,809 --> 00:28:37,500 instance and data is not lost when the operating system is rebooted and that's 294 00:28:37,500 --> 00:28:42,780 the same for an elastic block store backed ec2 instance as well but the data 295 00:28:42,780 --> 00:28:48,240 will definitely be lost if there's an underlying drive failure because we 296 00:28:48,240 --> 00:28:54,330 don't have any replication there and also if the instance is terminated that 297 00:28:54,330 --> 00:29:00,630 will be lost as well. So you don't rely on an instance store for any valuable 298 00:29:00,630 --> 00:29:05,200 long-term data but they are good because they do 299 00:29:05,200 --> 00:29:12,280 provide a little bit of a performance advantage over EBS and you cannot detach 300 00:29:12,280 --> 00:29:22,090 an instance store volume and attach it over to another instance. There 301 00:29:22,090 --> 00:29:28,419 are a number of storage options available for EBS, the first one there is 302 00:29:28,419 --> 00:29:35,140 the default choice and is a general-purpose SSD or it's called a GP2. 303 00:29:35,140 --> 00:29:41,200 The next one there is if you've got some IO intensive applications such as a 304 00:29:41,200 --> 00:29:47,289 large relational database or a no sequel database you can use a provisioned IOps 305 00:29:47,289 --> 00:29:54,850 Drive SSD as well and that's called an IO1drive and that will give you high 306 00:29:54,850 --> 00:30:00,220 performance consistent and low latency. The next one there are or the next two 307 00:30:00,220 --> 00:30:05,980 magnetic drives so they're going to be lower cost lower performance options . So 308 00:30:05,980 --> 00:30:10,179 the first one there is a cold hard disk drive and that will provide you the 309 00:30:10,179 --> 00:30:15,789 lowest cost per GB it's a standard magnetic drive. The next one 310 00:30:15,789 --> 00:30:20,380 there is a throughput optimized hard disk drive and that's going to provide a 311 00:30:20,380 --> 00:30:27,750 low cost per bit per gigabyte but not as low as the cold but it is very good for 312 00:30:27,750 --> 00:30:32,289 frequently accessed workloads for example if you had a large amount of 313 00:30:32,289 --> 00:30:36,010 data and you wanted to low costs but you were going to be accessing that data 314 00:30:36,010 --> 00:30:43,450 quite a bit for example for a big data data warehouse. If we want to back up our 315 00:30:43,450 --> 00:30:50,049 EBS volumes we can take EBS snapshots and they are a point-in-time backup of 316 00:30:50,049 --> 00:30:56,260 that EBS volume and they will be backed up to the Amazon s3 service. They're an 317 00:30:56,260 --> 00:30:59,620 incremental backup so if you take another snapshot after that it will be 318 00:30:59,620 --> 00:31:06,100 incremental and it can be copied to other regions or other accounts to 319 00:31:06,100 --> 00:31:12,909 create new EBS volumes from that snapshot. We also have encryption 320 00:31:12,909 --> 00:31:19,910 available on EBS. We can use the AWS KMS master keys or you can use your own 321 00:31:19,910 --> 00:31:25,760 customer master key for that encryption and the data stored at rest will be 322 00:31:25,760 --> 00:31:32,180 encrypted including any snapshots that are created from that encrypted drive 323 00:31:32,180 --> 00:31:38,990 and also as well as data that is in transit between the EBS volume and that 324 00:31:38,990 --> 00:31:42,370 ec2 instance. 325 00:31:46,610 --> 00:31:54,330 Another feature of ec2 is that we can connect remotely into our ec2 instances 326 00:31:54,330 --> 00:32:00,590 so for example if we're sitting here at our desktop with our Windows or Mac PC 327 00:32:00,590 --> 00:32:08,460 we can have a AWS access key which will have an access key ID and a secret 328 00:32:08,460 --> 00:32:13,680 access key provided we've got that we can use that to connect over the 329 00:32:13,680 --> 00:32:22,050 Internet to our ec2 instance and access and run commands on the operating system 330 00:32:22,050 --> 00:32:28,110 of that instance. Not only do you require those AWS access keys but you also need 331 00:32:28,110 --> 00:32:34,020 to have permission to access that network so you need to have a security 332 00:32:34,020 --> 00:32:40,680 group inbound rule that will allow access from your desktop you can connect 333 00:32:40,680 --> 00:32:48,750 to a Linux system using the secure shell or SSH and mac or linux desktops will 334 00:32:48,750 --> 00:32:53,460 use a console straight out of the box to do that. Windows computers will require 335 00:32:53,460 --> 00:33:00,870 an ssh client such as putty or a bash clients such as cygwin to be installed 336 00:33:00,870 --> 00:33:06,320 on their computer before they can access their Linux instance over SSH and 337 00:33:06,320 --> 00:33:12,030 connecting to a Windows Server instance can be done using the remote desktop 338 00:33:12,030 --> 00:33:18,240 protocol or RDP. So that brings us to the end of this lecture coming up we're 339 00:33:18,240 --> 00:33:24,000 going to be having quite a number of pretty complicated labs on ec2 I look 340 00:33:24,000 --> 00:33:27,320 forward to seeing you in those.