1
00:00:06,960 --> 00:00:08,950
- Now let's review an introduction to

2
00:00:08,950 --> 00:00:10,453
Amazon Elasticsearch Service.

3
00:00:11,290 --> 00:00:14,470
With Amazon Elasticsearch
Service we gain access to

4
00:00:14,470 --> 00:00:17,320
fully managed Elasticsearch clusters.

5
00:00:17,320 --> 00:00:22,320
Now, very similar to RDS,
where AWS is managing

6
00:00:22,480 --> 00:00:25,320
the operating system
and the database engine.

7
00:00:25,320 --> 00:00:28,330
The same kind of thing
applies here to Elasticsearch.

8
00:00:28,330 --> 00:00:30,620
AWS is managing the operating system and

9
00:00:30,620 --> 00:00:32,330
the Elasticsearch engine for us.

10
00:00:32,330 --> 00:00:35,210
So again, it's another
opportunity for us to

11
00:00:35,210 --> 00:00:37,413
offload operational burdens.

12
00:00:39,245 --> 00:00:41,510
If we have a need for Elasticsearch we can

13
00:00:41,510 --> 00:00:43,680
leverage the Elasicsearch service,

14
00:00:43,680 --> 00:00:48,083
rather than managing
Elasticsearch ourselves on EC2.

15
00:00:49,450 --> 00:00:54,030
When we build an Elsaticsearch cluster,

16
00:00:54,030 --> 00:00:56,480
even if there's only one
note in that cluster,

17
00:00:56,480 --> 00:00:59,630
we gain built in
intergrations with a number of

18
00:00:59,630 --> 00:01:03,210
very useful services such as one, Kibana.

19
00:01:03,210 --> 00:01:06,920
Kibana is a very powerful, very useful UI

20
00:01:06,920 --> 00:01:09,133
for interacting with Elasticsearch.

21
00:01:10,220 --> 00:01:13,900
In the least you can
search through records

22
00:01:13,900 --> 00:01:16,670
within Elasticsearch or create dashboards

23
00:01:16,670 --> 00:01:20,170
and even create analytical
dashboards to help you

24
00:01:20,170 --> 00:01:23,843
derive meaning from whatever
data you have in Elasticsearch.

25
00:01:25,420 --> 00:01:29,190
Elasticsearch clusters also
provide built-in integration

26
00:01:29,190 --> 00:01:33,620
with Logstash, with AWS Lambda so that as

27
00:01:36,345 --> 00:01:39,700
data is coming in through
perhaps Kinesis, for example.

28
00:01:39,700 --> 00:01:44,370
And Lambda can automatically
pull that data out of Kinesis,

29
00:01:44,370 --> 00:01:45,940
do some type of processing,

30
00:01:45,940 --> 00:01:49,150
and then store something in Elasticsearch.

31
00:01:49,150 --> 00:01:51,380
Or vice versa, perhaps
Lambda can pull data

32
00:01:51,380 --> 00:01:56,270
out of Elasticsearch, and
create some kind of output

33
00:01:56,270 --> 00:01:57,103
somewhere else.

34
00:01:57,103 --> 00:02:01,220
Be it a record in another
data store, or a notification

35
00:02:01,220 --> 00:02:03,050
going out through the
notification service,

36
00:02:03,050 --> 00:02:03,993
or pinpoint.

37
00:02:04,890 --> 00:02:07,110
And then, all kinds of other integrations

38
00:02:07,110 --> 00:02:09,141
with other Amazon services.

39
00:02:09,141 --> 00:02:11,620
Elasticsearch service clusters can scale

40
00:02:11,620 --> 00:02:13,870
to well over a petabyte, right?

41
00:02:13,870 --> 00:02:17,183
So we're not necessarily
limited in our data.

42
00:02:18,330 --> 00:02:19,163
And of course

43
00:02:19,163 --> 00:02:22,360
when we create an
Elasticsearch service cluster,

44
00:02:22,360 --> 00:02:26,500
we do get direct access
to the Elasticsearch API.

45
00:02:26,500 --> 00:02:28,850
Which means that once
we create that cluster,

46
00:02:28,850 --> 00:02:31,270
very similar to RDS, we can connect to

47
00:02:31,270 --> 00:02:34,720
an RDS instance directly,
without having to go through

48
00:02:34,720 --> 00:02:36,470
the Amazon API.

49
00:02:36,470 --> 00:02:39,077
Same applies to Elasticsearch clusters.

50
00:02:39,077 --> 00:02:43,540
Once that search cluster is created,

51
00:02:43,540 --> 00:02:47,040
it has it's own DNS endpoint
that we can connect to,

52
00:02:47,040 --> 00:02:50,123
and gain direct access
to the Elasticsearch API,

53
00:02:51,400 --> 00:02:53,480
to which we can program against.

54
00:02:53,480 --> 00:02:57,490
And then because there are instances,

55
00:02:57,490 --> 00:03:00,890
because Elasticsearch does include

56
00:03:00,890 --> 00:03:04,040
some type of an instance that is running,

57
00:03:04,040 --> 00:03:08,070
we can provide network
isolation for that instance

58
00:03:08,070 --> 00:03:10,750
by putting that in our own VPC,

59
00:03:10,750 --> 00:03:13,610
and controlling the networking environment

60
00:03:13,610 --> 00:03:14,933
around that instance.

61
00:03:15,927 --> 00:03:19,300
Elasticsearch clusters also
support encryption at rest

62
00:03:19,300 --> 00:03:21,580
with the AWS Key Management Service.

63
00:03:21,580 --> 00:03:25,930
We'll talk in great
detail about KMS later on,

64
00:03:25,930 --> 00:03:29,840
but if you need this data
to be encrypted at rest,

65
00:03:29,840 --> 00:03:34,250
then we can gain that
by integrating with KMS,

66
00:03:34,250 --> 00:03:36,720
where KMS is managing the keys,

67
00:03:36,720 --> 00:03:39,723
and Elasticsearch is
preforming the encryption.

68
00:03:41,350 --> 00:03:45,380
We can also rest well
at night knowing that

69
00:03:45,380 --> 00:03:49,080
the data that is stored in
that cluster is replicated.

70
00:03:49,080 --> 00:03:51,080
Very much like other services,

71
00:03:51,080 --> 00:03:54,480
the data that we store
in Elasticsearch clusters

72
00:03:54,480 --> 00:03:58,340
is replicated across multiple AZs.

73
00:03:58,340 --> 00:04:02,130
So again, its inherently
fault tolerant and durable.

74
00:04:02,130 --> 00:04:05,190
So if any one data center is offline,

75
00:04:05,190 --> 00:04:07,030
our data is still available.

76
00:04:07,030 --> 00:04:10,360
And of course, Elasticsearch
is also very tightly integrated

77
00:04:10,360 --> 00:04:11,630
with other services.

78
00:04:11,630 --> 00:04:15,830
It makes it very easy to
pull data in from one place,

79
00:04:15,830 --> 00:04:18,660
and then get that data
in to Elasticsearch.

80
00:04:18,660 --> 00:04:22,350
One example may be CloudWatch logs.

81
00:04:22,350 --> 00:04:25,250
We're gonna see an
example of this later on,

82
00:04:25,250 --> 00:04:28,330
where perhaps we are, our application logs

83
00:04:28,330 --> 00:04:30,200
are going to CloudWatch logs.

84
00:04:30,200 --> 00:04:34,330
And we can very easily
with one command line

85
00:04:34,330 --> 00:04:38,240
on the CLI tools, or two clicks
in the management console,

86
00:04:38,240 --> 00:04:42,880
we could very easily pipe data
coming into CloudWatch logs,

87
00:04:42,880 --> 00:04:45,960
and have that go to an
Elasticsearch cluster.

88
00:04:45,960 --> 00:04:48,810
So that we could use something like Kibana

89
00:04:48,810 --> 00:04:52,750
in order to preform viewing, searching

90
00:04:52,750 --> 00:04:57,093
or analytical processes on
that data in Elasticsearch.

91
00:04:57,960 --> 00:05:02,960
So, if you currently have
a need for Elasticsearch,

92
00:05:03,000 --> 00:05:06,320
and you don't want to
manage the operating system

93
00:05:06,320 --> 00:05:09,900
and the Elasticsearch
engine yourself on EC2,

94
00:05:09,900 --> 00:05:12,303
take a look at the Amazon
Elasticsearch service.