1
00:00:07,247 --> 00:00:11,414
- Let's talk about Amazon
Elastic Compute Cloud or EC2.

2
00:00:12,966 --> 00:00:15,526
With Amazon Elastic Compute Cloud,

3
00:00:15,526 --> 00:00:19,809
what we get are virtual machines
and we call them instances

4
00:00:19,809 --> 00:00:24,283
so one virtual machine
would be an instance of EC2.

5
00:00:24,283 --> 00:00:27,564
These are based on the Xen hypervisor

6
00:00:27,564 --> 00:00:31,095
and they come with sort of a
price-fixed menu you could say

7
00:00:31,095 --> 00:00:34,675
of CPU, memory, disk and network IO.

8
00:00:34,675 --> 00:00:38,298
We don't really get to
control CPU and memory

9
00:00:38,298 --> 00:00:41,298
and disk or network IO individually,

10
00:00:42,258 --> 00:00:44,371
but Amazon has done a really good job

11
00:00:44,371 --> 00:00:47,503
of creating a collection of machines,

12
00:00:47,503 --> 00:00:50,605
various types of EC2 instances,

13
00:00:50,605 --> 00:00:53,733
for different types of workloads.

14
00:00:53,733 --> 00:00:55,810
And they come with various degrees

15
00:00:55,810 --> 00:00:59,643
of CPU, memory, disk and
of course network IO.

16
00:01:01,269 --> 00:01:05,005
With EC2 we can launch
from one EC2 instance

17
00:01:05,005 --> 00:01:07,956
to thousands of instances if we need to.

18
00:01:07,956 --> 00:01:09,645
Now it's important to understand

19
00:01:09,645 --> 00:01:11,648
that there are service limits.

20
00:01:11,648 --> 00:01:14,905
Typically from the start
your account is initially

21
00:01:14,905 --> 00:01:17,987
limited to a certain number of instances

22
00:01:17,987 --> 00:01:20,511
depending on the instance type.

23
00:01:20,511 --> 00:01:22,601
That's considered a soft limit,

24
00:01:22,601 --> 00:01:26,828
meaning that you can submit
a support ticket request

25
00:01:26,828 --> 00:01:28,431
to lift that limit.

26
00:01:28,431 --> 00:01:30,770
They put that in place just as a way

27
00:01:30,770 --> 00:01:33,969
to limit resource consumption in the case

28
00:01:33,969 --> 00:01:36,597
where people might have runaway scripts

29
00:01:36,597 --> 00:01:39,071
or maybe they aren't paying
attention to what they're doing.

30
00:01:39,071 --> 00:01:40,894
So with EC2 instances,

31
00:01:40,894 --> 00:01:44,727
we have very powerful
range of compute options

32
00:01:45,567 --> 00:01:47,585
for various types of workloads.

33
00:01:47,585 --> 00:01:48,736
It's important to understand

34
00:01:48,736 --> 00:01:50,826
that this is a very different paradigm

35
00:01:50,826 --> 00:01:52,806
than what we might be used to.

36
00:01:52,806 --> 00:01:56,973
In traditional IT where
we had long living servers

37
00:01:58,048 --> 00:02:00,747
that we assumed would be
there for years on end

38
00:02:00,747 --> 00:02:02,692
in a rack somewhere,

39
00:02:02,692 --> 00:02:04,269
that is not the case anymore.

40
00:02:04,269 --> 00:02:06,273
We're getting away from that paradigm

41
00:02:06,273 --> 00:02:07,777
and we're assuming a paradigm

42
00:02:07,777 --> 00:02:11,631
where our EC2 instances are disposable,

43
00:02:11,631 --> 00:02:13,268
where if there's something wrong with it,

44
00:02:13,268 --> 00:02:15,497
we throw it away and start anew.

45
00:02:15,497 --> 00:02:18,084
And we have systems that
we'll talk about later

46
00:02:18,084 --> 00:02:21,502
that can help that machine
bootstrap and configure

47
00:02:21,502 --> 00:02:23,862
and so to have it right
back up and running

48
00:02:23,862 --> 00:02:24,892
where it should be

49
00:02:24,892 --> 00:02:28,256
simply by throwing it
away and recreating it.