1
00:00:06,840 --> 00:00:11,580
- If reliability is a
priority for your application,

2
00:00:11,580 --> 00:00:16,580
it is worthwhile to look
at the individual services

3
00:00:16,820 --> 00:00:18,293
that can provide that.

4
00:00:19,230 --> 00:00:22,610
But it is also good to
have an overall strategy

5
00:00:22,610 --> 00:00:25,720
from both a network perspective

6
00:00:25,720 --> 00:00:28,210
and an application perspective.

7
00:00:28,210 --> 00:00:31,780
And so let's take a look
at network reliability.

8
00:00:31,780 --> 00:00:36,230
And one of the easiest
ways to improve this

9
00:00:36,230 --> 00:00:39,150
is to deploy a VPC

10
00:00:39,150 --> 00:00:43,040
into more than one availability zone

11
00:00:43,040 --> 00:00:44,473
within a single region.

12
00:00:45,410 --> 00:00:50,090
This not only guarantees
separate data centers

13
00:00:50,090 --> 00:00:53,950
for your resources, but it also guarantees

14
00:00:53,950 --> 00:00:58,490
a bit of geographic distance between them

15
00:00:58,490 --> 00:01:00,553
for fault isolation purposes.

16
00:01:02,070 --> 00:01:06,660
If you're following best
practices and principles

17
00:01:06,660 --> 00:01:08,990
of the well-architected framework,

18
00:01:08,990 --> 00:01:10,680
this is a really

19
00:01:11,624 --> 00:01:14,790
highly regarded mechanism

20
00:01:14,790 --> 00:01:17,010
for achieving reliability,

21
00:01:17,010 --> 00:01:20,620
but there are always trade-offs.

22
00:01:20,620 --> 00:01:25,620
When you are looking at
well-architected infrastructures,

23
00:01:26,490 --> 00:01:28,220
it is impossible

24
00:01:29,220 --> 00:01:31,890
to focus on all of the pillars

25
00:01:31,890 --> 00:01:33,763
and optimize them at the same time.

26
00:01:34,870 --> 00:01:39,500
And so if we are going to
optimize for reliability

27
00:01:39,500 --> 00:01:42,393
by deploying into more
than one availability zone,

28
00:01:43,410 --> 00:01:47,780
we might look at cost as
a potential trade-off.

29
00:01:47,780 --> 00:01:50,280
If our applications are
gonna communicate cross AZ,

30
00:01:50,280 --> 00:01:52,293
we have to pay for that traffic.

31
00:01:54,010 --> 00:01:58,050
We might incur a bit of
operational overhead,

32
00:01:58,050 --> 00:02:00,410
because we now have to consider

33
00:02:00,410 --> 00:02:03,080
more than one availability zone

34
00:02:03,080 --> 00:02:04,853
in all of our configurations.

35
00:02:06,630 --> 00:02:09,890
And finally, we could potentially incur

36
00:02:09,890 --> 00:02:12,653
a bit of a performance penalty,

37
00:02:13,580 --> 00:02:17,430
if again, we're having that
cross AZ communication,

38
00:02:17,430 --> 00:02:19,700
because we're going to have to deal

39
00:02:19,700 --> 00:02:23,420
with an extra few milliseconds of latency.

40
00:02:23,420 --> 00:02:26,870
So it's important to understand
all of the trade-offs

41
00:02:26,870 --> 00:02:28,333
when you set your priorities.

42
00:02:29,360 --> 00:02:33,860
Now within a VPC beyond
multiple availability zones,

43
00:02:33,860 --> 00:02:35,960
we look at the internet gateway.

44
00:02:35,960 --> 00:02:40,290
It is virtual, it's fault
tolerant, it scales horizontally

45
00:02:40,290 --> 00:02:42,983
and it's entirely a logical resource.

46
00:02:43,990 --> 00:02:48,367
This absolutely counts as
a highly available object.

47
00:02:50,700 --> 00:02:53,070
NAT Gateways are a little different.

48
00:02:53,070 --> 00:02:56,580
A NAT Gateway while it
is highly available,

49
00:02:56,580 --> 00:03:00,810
it's not fault tolerant and
it doesn't scale horizontally.

50
00:03:00,810 --> 00:03:05,120
And that means that it can be
an individual building block

51
00:03:05,120 --> 00:03:07,650
towards a fault tolerant infrastructure,

52
00:03:07,650 --> 00:03:09,983
but by itself, it doesn't qualify.

53
00:03:10,890 --> 00:03:13,440
And a strategy for addressing that

54
00:03:13,440 --> 00:03:18,440
might be to deploy a NAT Gateway
into each availability zone

55
00:03:18,450 --> 00:03:20,893
to have a little bit of redundancy.

56
00:03:23,870 --> 00:03:27,550
Now, as we move into our
application architecture,

57
00:03:27,550 --> 00:03:29,340
let's think of a three-tier app

58
00:03:29,340 --> 00:03:33,023
with web, application and database tiers.

59
00:03:34,230 --> 00:03:38,170
At the frontend, we have
an Elastic Load Balancer.

60
00:03:38,170 --> 00:03:43,170
The ELB will take advantage
of multiple availability zones

61
00:03:43,850 --> 00:03:47,023
and it is a fault tolerant
resource on its own.

62
00:03:49,300 --> 00:03:52,050
If we deploy the application tier

63
00:03:52,050 --> 00:03:55,623
as an auto-scaled group of EC2 instances,

64
00:03:56,900 --> 00:04:00,560
we can also take advantage of multiple AZs

65
00:04:00,560 --> 00:04:02,270
and we retain redundancy,

66
00:04:02,270 --> 00:04:05,500
because we have multiple EC2 instances

67
00:04:05,500 --> 00:04:07,423
in multiple availability zones.

68
00:04:10,280 --> 00:04:14,290
And on the backend, we can choose RDS

69
00:04:14,290 --> 00:04:17,430
in a multi-AZ configuration,

70
00:04:17,430 --> 00:04:19,570
but this is active/passive

71
00:04:19,570 --> 00:04:22,150
and that means we still
have a single right endpoint

72
00:04:22,150 --> 00:04:23,943
in a single availability zone.

73
00:04:24,930 --> 00:04:29,930
To improve that, we
could switch it to Aurora

74
00:04:30,220 --> 00:04:35,220
using the multi-primary option
so that we have two writers

75
00:04:35,600 --> 00:04:40,110
one in each availability zone
to retain some redundancy

76
00:04:40,110 --> 00:04:43,363
and become active/active
instead of active/passive.
