1

00:00:03,090  -->  00:00:08,530
welcome back to back space Academy in
this lecture on that cloud front which

2

00:00:08,530  -->  00:00:14,950
is AWS's content delivery network I'll
talk about how cloud front is used to

3

00:00:14,950  -->  00:00:22,599
cache regularly use content to edge
locations located across AWS is global

4

00:00:22,599  -->  00:00:28,960
infrastructure I'll talk about origin
servers which contain our content to be

5

00:00:28,960  -->  00:00:35,800
cached and I'll talk about a cloud front
distribution which defines what is to be

6

00:00:35,800  -->  00:00:40,210
cached and how it is to be cached and
I'll talk about dynamic content how do

7

00:00:40,210  -->  00:00:46,149
we manage content to be cached that is
changing on a regular basis and finally

8

00:00:46,149  -->  00:00:52,719
I'll talk about the options available to
us for using cloud front. Cloud front is

9

00:00:52,719  -->  00:00:59,170
a web service for high performance
delivery of content and it uses a

10

00:00:59,170  -->  00:01:04,839
worldwide network of data centers or
edge locations to deliver that content

11

00:01:04,839  -->  00:01:12,130
with very low latency it helps to reduce
a number of hops that a request has to

12

00:01:12,130  -->  00:01:16,210
go to to get the information that it
requires so we can see there on that

13

00:01:16,210  -->  00:01:22,600
diagram going from from a requester to
to a server over the wider Internet can

14

00:01:22,600  -->  00:01:29,409
take quite a significant route so having
a closer edge location will reduce the

15

00:01:29,409  -->  00:01:37,810
number of hops and obviously the latency
in responding to requests edge locations

16

00:01:37,810  -->  00:01:42,340
are basically data centers that are
located across the AWS infrastructure

17

00:01:42,340  -->  00:01:48,969
and they provide a closer access and
lower latency for our cached content to

18

00:01:48,969  -->  00:01:54,159
the end user, currently there are
at least 50 edge locations is probably

19

00:01:54,159  -->  00:02:01,329
more than a hundred I would think at the
time of this video and those contain

20

00:02:01,329  -->  00:02:06,369
cloud front distributions at those edges
locations and they enable us to have

21

00:02:06,369  -->  00:02:12,130
high performance delivery of that
content looking at the the picture of

22

00:02:12,130  -->  00:02:16,670
the globe there we've got
edge locations located in blue at

23

00:02:16,670  -->  00:02:23,060
January 2016 so quite a significant time
ago but but clearly you can see there

24

00:02:23,060  -->  00:02:30,769
are a lot of edge locations available to
cache our content, a cloud front origin

25

00:02:30,769  -->  00:02:34,579
server will be the location of the
content that we are going to be

26

00:02:34,579  -->  00:02:40,280
delivering across the cloud front
content delivery network the origin

27

00:02:40,280  -->  00:02:45,730
server can be either an s3 bucket
containing our content or it can be a

28

00:02:45,730  -->  00:02:53,359
HTTP server for example it could be an
ec2 instance it can also be it doesn't

29

00:02:53,359  -->  00:02:57,919
have to actually be on a AWS
infrastructure can it actually be a web

30

00:02:57,919  -->  00:03:04,659
server that we manage outside of AWS
this is a case for web only not rtmp

31

00:03:04,659  -->  00:03:10,540
cloud front distributions but we could
have a web server outside of AWS

32

00:03:10,540  -->  00:03:16,340
provided that cloud front has access to
that server so if it's a publicly

33

00:03:16,340  -->  00:03:23,299
accessible content then we can use that
as a basis for our cloud front

34

00:03:23,299  -->  00:03:29,329
distribution so a cloud front
distribution now that tells cloud front

35

00:03:29,329  -->  00:03:35,840
which our origin servers to get your
files from and the time for that case to

36

00:03:35,840  -->  00:03:43,359
live cloud front automatically assigns a
domain name to your new distribution and

37

00:03:43,359  -->  00:03:50,780
you can also define your own alternate
domain name using route 53 a cname

38

00:03:50,780  -->  00:03:57,109
record entry if an edge location
contains a requested file within the

39

00:03:57,109  -->  00:04:05,090
time-to-live it is delivered directly
from the case if it is not it is fetched

40

00:04:05,090  -->  00:04:09,739
from the origin server and then
delivered and then cached at the edge

41

00:04:09,739  -->  00:04:20,030
location if l if we want our our content
to be changed before that time to live

42

00:04:20,030  -->  00:04:23,960
is expired we can do that for example
it's got new content we want to put out

43

00:04:23,960  -->  00:04:27,710
there and we want to make sure that our
end-users are getting the most current

44

00:04:27,710  -->  00:04:31,259
content
we can invalidate that distribution or

45

00:04:31,259  -->  00:04:36,180
we can invalidate parts of that
distribution for example directories

46

00:04:36,180  -->  00:04:40,349
within that distribution or we could
individual files or we could actually

47

00:04:40,349  -->  00:04:45,750
use a wild-card signal which could
actually say well all of our HTML files

48

00:04:45,750  -->  00:04:51,840
we're going to update or invalidate and
that takes a certain amount of time okay

49

00:04:51,840  -->  00:04:56,970
takes quite a number of minutes for a
distribution to be invalidated then just

50

00:04:56,970  -->  00:05:05,940
redistributed across the content
delivery network one concern that we

51

00:05:05,940  -->  00:05:11,520
need to understand is how do we manage
dynamic content so if we've got dynamic

52

00:05:11,520  -->  00:05:17,729
content and it's going to be cached and
we've got a time to live if one day is

53

00:05:17,729  -->  00:05:22,680
not necessarily going to going to be
dynamic content anymore from a user's

54

00:05:22,680  -->  00:05:27,199
perspective so the options available to
us is that we can have a very very low

55

00:05:27,199  -->  00:05:35,009
time to live or we can actually not
cache dynamic content only the static

56

00:05:35,009  -->  00:05:41,039
content in cloud front makes it quite
easy to do that because not all HTTP

57

00:05:41,039  -->  00:05:47,279
methods occasionally run only responses
to get and head requests although you

58

00:05:47,279  -->  00:05:53,310
can also configure cloud front to cache
responses two options requests also if

59

00:05:53,310  -->  00:06:00,060
we use a different HTTP map method such
as post put or delete those requests

60

00:06:00,060  -->  00:06:07,289
will not be cached by cloud front they
will be simply proxy back to our to our

61

00:06:07,289  -->  00:06:15,150
origin server so that's how we could
allow our static content to be cached

62

00:06:15,150  -->  00:06:22,199
and our dynamic content to be proxy back
directly to our origin server so we can

63

00:06:22,199  -->  00:06:29,310
combine dynamic and static content in
that way so just finally I just want to

64

00:06:29,310  -->  00:06:34,319
go through the cloud front options of
all the options that are available from

65

00:06:34,319  -->  00:06:38,940
a strategy perspective of how we could
use cloud front for different scenarios

66

00:06:38,940  -->  00:06:45,300
so the first thing here is we may
have a static site and that could be a

67

00:06:45,300  -->  00:06:53,090
html5 website that's that doesn't change
or it is not a dynamic site so we could

68

00:06:53,090  -->  00:07:01,140
have our HTML our CSS and our code we
could have that located on for example

69

00:07:01,140  -->  00:07:07,200
an Origin server on s3
and we could have that not not case your

70

00:07:07,200  -->  00:07:10,140
cloud funds so we could keep that
separate from cloud front cloud front

71

00:07:10,140  -->  00:07:15,420
and we could use cloud front just to
catch our big files our images our

72

00:07:15,420  -->  00:07:21,630
videos our documents our code libraries
you don't have jQuery libraries and that

73

00:07:21,630  -->  00:07:26,280
sort of thing and that way we're still
getting the benefits of cloud from

74

00:07:26,280  -->  00:07:30,330
because all our videos and these big
stuff is it's not going to be fetched

75

00:07:30,330  -->  00:07:34,230
back from our server or we're not going
to get get these costs from Amazon s3

76

00:07:34,230  -->  00:07:40,290
service for for bandwidth for using it
so the advantage that it also allows for

77

00:07:40,290  -->  00:07:45,000
us to easily update our update our site
so we're going to get the benefits of

78

00:07:45,000  -->  00:07:51,450
cloud front there but at the same time
if we've got HTML web pages we can

79

00:07:51,450  -->  00:07:55,380
quickly update those quote quite
straight forward and some if we're going

80

00:07:55,380  -->  00:07:58,560
to update it do any code updates we can
update those without having to

81

00:07:58,560  -->  00:08:03,570
invalidate our cloud front distribution
and go through all that at that time of

82

00:08:03,570  -->  00:08:11,430
doing that the disadvantages is going to
be the latency of those HTML CSS and

83

00:08:11,430  -->  00:08:18,000
those those files that are going to be
accessed directly so another option for

84

00:08:18,000  -->  00:08:23,040
static web sites would be to have
nothing going direct and have cloud

85

00:08:23,040  -->  00:08:29,520
fronts doing all of our static content
so everything on the site going through

86

00:08:29,520  -->  00:08:34,350
to well being in a cloud front
distribution that obviously is going to

87

00:08:34,350  -->  00:08:38,610
give us the best performance from a
latency perspective so from a user

88

00:08:38,610  -->  00:08:43,160
perspective we're going to get the
lowest latency the disadvantage of that

89

00:08:43,160  -->  00:08:48,150
will be if your site is going to be
changing on a regular basis so you know

90

00:08:48,150  -->  00:08:53,180
every day you're making changes to your
size then that's going to require you to

91

00:08:53,180  -->  00:08:59,280
invalidate that site
and invalidate that cloud front

92

00:08:59,280  -->  00:09:03,490
distribution and that's going to take
time and that's going to take time for

93

00:09:03,490  -->  00:09:09,130
that to propagate across those edge
locations as well so then we can look at

94

00:09:09,130  -->  00:09:15,990
a dynamic site for example we might have
a wordpress site of PHP site or whatever

95

00:09:15,990  -->  00:09:21,040
so we could look at going direct with
our dynamic pages as we said we could do

96

00:09:21,040  -->  00:09:27,510
our different types of post commands and
whatever but to actually have our

97

00:09:27,510  -->  00:09:34,600
dynamic pages being proxied through to
the origin server not cased by cloud

98

00:09:34,600  -->  00:09:39,060
front and then have our images video
document all those large static files

99

00:09:39,060  -->  00:09:45,280
located on or cached through clear front
that's going to give us the advantages

100

00:09:45,280  -->  00:09:48,310
that we're going to have the most
up-to-date content delivered we're going

101

00:09:48,310  -->  00:09:51,700
to have our static content delivered
with low latency and we're also going to

102

00:09:51,700  -->  00:09:56,740
have our dynamic pages delivered with
the most up-to-date content the

103

00:09:56,740  -->  00:10:02,770
disadvantage is going to be the latency
of those PHP files and also we're still

104

00:10:02,770  -->  00:10:07,120
going to be having traffic going through
to that server so we're going to you

105

00:10:07,120  -->  00:10:10,030
know we might have a large hit of
traffic and so we need to accommodate

106

00:10:10,030  -->  00:10:16,060
that so the next option is that we can
we can have everything going through

107

00:10:16,060  -->  00:10:21,010
cloud front for our dynamic and F static
page is going to give us great latent

108

00:10:21,010  -->  00:10:27,160
low latency it's going to massively
reduce the load on our on our web server

109

00:10:27,160  -->  00:10:31,450
because all of those are Kressel be
going straight to cloud front and the

110

00:10:31,450  -->  00:10:37,780
only request will be coming from the
cloud front service to invalidate or

111

00:10:37,780  -->  00:10:44,470
update the the distribution the
disadvantage is that with the TTL the

112

00:10:44,470  -->  00:10:48,700
time to live will need to be low but it
needs to be low enough to balance

113

00:10:48,700  -->  00:10:55,330
between having reasonably current
content so a low content age but at the

114

00:10:55,330  -->  00:11:00,730
same time balancing between that and
having the load on your origin server so

115

00:11:00,730  -->  00:11:05,650
if the cloud front service is
continually going back and updating its

116

00:11:05,650  -->  00:11:12,100
its distribution and that's going to
at the same time put a load on your

117

00:11:12,100  -->  00:11:15,790
server
so that's although I will discuss for

118

00:11:15,790  -->  00:11:22,240
now on cloud front we have a lab on
html5 websites and using cloud front in

119

00:11:22,240  -->  00:11:27,570
front of that so I'll look forward to
seeing you in that lab