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