1
00:00:06,620 --> 00:00:09,860
- Now lets talk about
instance store volumes.

2
00:00:09,860 --> 00:00:14,290
With EC2, some EC2 instances include

3
00:00:14,290 --> 00:00:16,220
instance store volumes, right?

4
00:00:16,220 --> 00:00:19,890
So it's worth noting that
not every instance type

5
00:00:19,890 --> 00:00:23,410
does include instance based volumes.

6
00:00:23,410 --> 00:00:28,410
There are several different
instance types that only use EBS

7
00:00:28,490 --> 00:00:32,035
but for those that do
include instance volumes

8
00:00:32,035 --> 00:00:34,944
they are included with the instance,

9
00:00:34,944 --> 00:00:38,940
and again they are powered
by the physical host.

10
00:00:38,940 --> 00:00:43,420
So remember that when we get an instance

11
00:00:43,420 --> 00:00:45,463
on EC2, this is a virtual machine,

12
00:00:46,650 --> 00:00:50,520
usually a virtual machine,
and that virtual machine

13
00:00:50,520 --> 00:00:52,650
is powered by a physical host.

14
00:00:52,650 --> 00:00:55,820
So for those instance types that include

15
00:00:55,820 --> 00:00:58,960
instance store volumes,
those volumes are powered

16
00:00:58,960 --> 00:01:00,560
by the physical host, it goes straight

17
00:01:00,560 --> 00:01:04,430
through the hypervisor, to the actual disk

18
00:01:04,430 --> 00:01:08,900
that's right there in the same chassis.

19
00:01:08,900 --> 00:01:11,970
There's no network latency,
it's straight through.

20
00:01:11,970 --> 00:01:15,690
So as a result, we can see
a very, very high degree

21
00:01:15,690 --> 00:01:19,900
of IOPs, in many cases
beyond 100,000 IOPs.

22
00:01:19,900 --> 00:01:24,900
So if you have very intensive applications

23
00:01:26,010 --> 00:01:29,500
that need a very high degree of IOPs,

24
00:01:29,500 --> 00:01:31,720
then you can look to
instance store volumes

25
00:01:31,720 --> 00:01:35,623
to solve that, but keep in
mind again they are ephemeral.

26
00:01:36,480 --> 00:01:40,750
So EC2 instance, they can be stopped

27
00:01:40,750 --> 00:01:43,680
and then started again
later, they can be terminated

28
00:01:43,680 --> 00:01:46,820
and then relaunched anew, and either way

29
00:01:46,820 --> 00:01:49,200
it's very likely that an instance

30
00:01:49,200 --> 00:01:51,690
that is stopped and started will come back

31
00:01:51,690 --> 00:01:54,530
to life on a different
host, and because it's on

32
00:01:54,530 --> 00:01:58,557
a different host, the
storage volume is not there.

33
00:01:58,557 --> 00:02:03,557
So there's also no ability
to perform snapshots,

34
00:02:04,470 --> 00:02:07,080
so between the ephemeral
nature in those snapshots

35
00:02:07,080 --> 00:02:10,890
there is really no durability built in.

36
00:02:10,890 --> 00:02:13,310
There is absolutely no inherent durability

37
00:02:13,310 --> 00:02:14,510
to that storage volume.

38
00:02:14,510 --> 00:02:16,380
So the trade-off is that we get

39
00:02:16,380 --> 00:02:20,070
really high IOPs with no durability.

40
00:02:20,070 --> 00:02:23,630
If durability is important,
if you need persistence

41
00:02:23,630 --> 00:02:27,060
in your data, if you need
some inherent durability,

42
00:02:27,060 --> 00:02:29,940
then we would look to
EBS, but there are plenty

43
00:02:29,940 --> 00:02:34,170
of use cases where ephemeral
storage may make sense.

44
00:02:34,170 --> 00:02:38,310
One example might be
that you are performing

45
00:02:38,310 --> 00:02:42,180
some type extract, transform,
and load operation.

46
00:02:42,180 --> 00:02:45,130
Maybe you are extracting
data from some data source

47
00:02:45,130 --> 00:02:47,500
and now you have this very large dataset,

48
00:02:47,500 --> 00:02:49,910
and you're doing some type of a transform

49
00:02:49,910 --> 00:02:53,860
or an analysis on it that
requires a lot of random IO

50
00:02:53,860 --> 00:02:56,250
before shipping it somewhere else.

51
00:02:56,250 --> 00:03:01,250
You could have some type of
a high performing database

52
00:03:01,670 --> 00:03:05,333
that, such as Mongo or
Cassandra, running on EC2,

53
00:03:06,320 --> 00:03:11,100
and you want access to that
high IOPs instance store volume.

54
00:03:11,100 --> 00:03:14,500
In that regard, you
could achieve durability

55
00:03:14,500 --> 00:03:17,990
by leveraging replication,
and by replicating

56
00:03:17,990 --> 00:03:22,800
those datasets between two
or three different machines,

57
00:03:22,800 --> 00:03:24,800
then you can solve the durability issue

58
00:03:24,800 --> 00:03:27,970
in that if you lost one
machine, you would still have

59
00:03:27,970 --> 00:03:32,120
another, some number of machines,
two or three or whatever.

60
00:03:32,120 --> 00:03:35,900
So let's take a look at a few instance

61
00:03:35,900 --> 00:03:39,450
store volume examples here,
and you'll notice here,

62
00:03:39,450 --> 00:03:42,360
and this is by no means
an exhaustive list,

63
00:03:42,360 --> 00:03:44,840
this is just a small
sample to give you an idea

64
00:03:44,840 --> 00:03:48,580
of what's possible, with
certain instances, let's say

65
00:03:48,580 --> 00:03:51,700
the m3.large for example, some instances

66
00:03:51,700 --> 00:03:53,920
may come with only one volume.

67
00:03:53,920 --> 00:03:58,920
So here the m3.large comes
with one 32GB SSD volume.

68
00:04:00,370 --> 00:04:02,840
Other instances may come with two volumes.

69
00:04:02,840 --> 00:04:07,840
So the c3.large comes
with two 16GB SSD volumes,

70
00:04:08,270 --> 00:04:11,050
and in that regard you
can treat them as two

71
00:04:11,050 --> 00:04:14,570
separate volumes and use them
for two different purposes,

72
00:04:14,570 --> 00:04:19,460
or you could include them
in a RAID configuration

73
00:04:19,460 --> 00:04:21,830
or include them within
a logical volume manager

74
00:04:21,830 --> 00:04:24,393
and use them as a single volume.

75
00:04:26,240 --> 00:04:28,440
Some of the other instances
that are available,

76
00:04:28,440 --> 00:04:31,293
and you'll notice here that
we have the d2.8xlarge,

77
00:04:32,700 --> 00:04:37,700
this particular instance
comes with 24 2TB volumes.

78
00:04:38,270 --> 00:04:41,695
So if you were to RAID
those, you could end up with

79
00:04:41,695 --> 00:04:45,951
48TB worth of storage, and
of course in that instance

80
00:04:45,951 --> 00:04:49,783
that is using hard disks rather than SSDs.

81
00:04:50,750 --> 00:04:52,840
Now the later ones, the ones that I'm most

82
00:04:52,840 --> 00:04:57,840
excited about recently,
would be the 5D instances.

83
00:04:58,510 --> 00:05:03,510
The C5D, M5D, and R5D series

84
00:05:04,270 --> 00:05:08,760
generally come with
some number of volumes.

85
00:05:08,760 --> 00:05:11,850
Some come with one, some
come with two or four,

86
00:05:11,850 --> 00:05:16,370
but they're all, the D
series come with NVMe SSDs,

87
00:05:16,370 --> 00:05:20,720
so these are going to be the
fastest, most highly performing

88
00:05:20,720 --> 00:05:25,340
volumes that you can get
for instance store volumes.

89
00:05:25,340 --> 00:05:29,740
So the takeaway here is that
if you do have an application,

90
00:05:29,740 --> 00:05:32,750
or some type of a use case
or workload that needs

91
00:05:32,750 --> 00:05:35,880
a very high degree of
IOPs, and you're willing

92
00:05:35,880 --> 00:05:38,470
to make the trade-off in durability,

93
00:05:38,470 --> 00:05:41,293
then take a look at the
instance store volumes.