welcome back to back space Academy in this lecture on that cloud front which 2
is AWS's content delivery network I'll talk about how cloud front is used to 3
cache regularly use content to edge locations located across AWS is global 4
infrastructure I'll talk about origin servers which contain our content to be 5
cached and I'll talk about a cloud front distribution which defines what is to be 6
cached and how it is to be cached and I'll talk about dynamic content how do 7
we manage content to be cached that is changing on a regular basis and finally 8
I'll talk about the options available to us for using cloud front. Cloud front is 9
a web service for high performance delivery of content and it uses a 10
worldwide network of data centers or edge locations to deliver that content 11
with very low latency it helps to reduce a number of hops that a request has to 12
go to to get the information that it requires so we can see there on that 13
diagram going from from a requester to to a server over the wider Internet can 14
take quite a significant route so having a closer edge location will reduce the 15
number of hops and obviously the latency in responding to requests edge locations 16
are basically data centers that are located across the AWS infrastructure 17
and they provide a closer access and lower latency for our cached content to 18
the end user, currently there are at least 50 edge locations is probably 19
more than a hundred I would think at the time of this video and those contain 20
cloud front distributions at those edges locations and they enable us to have 21
high performance delivery of that content looking at the the picture of 22
the globe there we've got edge locations located in blue at 23
January 2016 so quite a significant time ago but but clearly you can see there 24
are a lot of edge locations available to cache our content, a cloud front origin 25
server will be the location of the content that we are going to be 26
delivering across the cloud front content delivery network the origin 27
server can be either an s3 bucket containing our content or it can be a 28
HTTP server for example it could be an ec2 instance it can also be it doesn't 29
have to actually be on a AWS infrastructure can it actually be a web 30
server that we manage outside of AWS this is a case for web only not rtmp 31
cloud front distributions but we could have a web server outside of AWS 32
provided that cloud front has access to that server so if it's a publicly 33
accessible content then we can use that as a basis for our cloud front 34
distribution so a cloud front distribution now that tells cloud front 35
which our origin servers to get your files from and the time for that case to 36
live cloud front automatically assigns a domain name to your new distribution and 37
you can also define your own alternate domain name using route 53 a cname 38
record entry if an edge location contains a requested file within the 39
time-to-live it is delivered directly from the case if it is not it is fetched 40
from the origin server and then delivered and then cached at the edge 41
location if l if we want our our content to be changed before that time to live 42
is expired we can do that for example it's got new content we want to put out 43
there and we want to make sure that our end-users are getting the most current 44
content we can invalidate that distribution or 45
we can invalidate parts of that distribution for example directories 46
within that distribution or we could individual files or we could actually 47
use a wild-card signal which could actually say well all of our HTML files 48
we're going to update or invalidate and that takes a certain amount of time okay 49
takes quite a number of minutes for a distribution to be invalidated then just 50
redistributed across the content delivery network one concern that we 51
need to understand is how do we manage dynamic content so if we've got dynamic 52
content and it's going to be cached and we've got a time to live if one day is 53
not necessarily going to going to be dynamic content anymore from a user's 54
perspective so the options available to us is that we can have a very very low 55
time to live or we can actually not cache dynamic content only the static 56
content in cloud front makes it quite easy to do that because not all HTTP 57
methods occasionally run only responses to get and head requests although you 58
can also configure cloud front to cache responses two options requests also if 59
we use a different HTTP map method such as post put or delete those requests 60
will not be cached by cloud front they will be simply proxy back to our to our 61
origin server so that's how we could allow our static content to be cached 62
and our dynamic content to be proxy back directly to our origin server so we can 63
combine dynamic and static content in that way so just finally I just want to 64
go through the cloud front options of all the options that are available from 65
a strategy perspective of how we could use cloud front for different scenarios 66
so the first thing here is we may have a static site and that could be a 67
html5 website that's that doesn't change or it is not a dynamic site so we could 68
have our HTML our CSS and our code we could have that located on for example 69
an Origin server on s3 and we could have that not not case your 70
cloud funds so we could keep that separate from cloud front cloud front 71
and we could use cloud front just to catch our big files our images our 72
videos our documents our code libraries you don't have jQuery libraries and that 73
sort of thing and that way we're still getting the benefits of cloud from 74
because all our videos and these big stuff is it's not going to be fetched 75
back from our server or we're not going to get get these costs from Amazon s3 76
service for for bandwidth for using it so the advantage that it also allows for 77
us to easily update our update our site so we're going to get the benefits of 78
cloud front there but at the same time if we've got HTML web pages we can 79
quickly update those quote quite straight forward and some if we're going 80
to update it do any code updates we can update those without having to 81
invalidate our cloud front distribution and go through all that at that time of 82
doing that the disadvantages is going to be the latency of those HTML CSS and 83
those those files that are going to be accessed directly so another option for 84
static web sites would be to have nothing going direct and have cloud 85
fronts doing all of our static content so everything on the site going through 86
to well being in a cloud front distribution that obviously is going to 87
give us the best performance from a latency perspective so from a user 88
perspective we're going to get the lowest latency the disadvantage of that 89
will be if your site is going to be changing on a regular basis so you know 90
every day you're making changes to your size then that's going to require you to 91
invalidate that site and invalidate that cloud front 92
distribution and that's going to take time and that's going to take time for 93
that to propagate across those edge locations as well so then we can look at 94
a dynamic site for example we might have a wordpress site of PHP site or whatever 95
so we could look at going direct with our dynamic pages as we said we could do 96
our different types of post commands and whatever but to actually have our 97
dynamic pages being proxied through to the origin server not cased by cloud 98
front and then have our images video document all those large static files 99
located on or cached through clear front that's going to give us the advantages 100
that we're going to have the most up-to-date content delivered we're going 101
to have our static content delivered with low latency and we're also going to 102
have our dynamic pages delivered with the most up-to-date content the 103
disadvantage is going to be the latency of those PHP files and also we're still 104
going to be having traffic going through to that server so we're going to you 105
know we might have a large hit of traffic and so we need to accommodate 106
that so the next option is that we can we can have everything going through 107
cloud front for our dynamic and F static page is going to give us great latent 108
low latency it's going to massively reduce the load on our on our web server 109
because all of those are Kressel be going straight to cloud front and the 110
only request will be coming from the cloud front service to invalidate or 111
update the the distribution the disadvantage is that with the TTL the 112
time to live will need to be low but it needs to be low enough to balance 113
between having reasonably current content so a low content age but at the 114
same time balancing between that and having the load on your origin server so 115
if the cloud front service is continually going back and updating its 116
its distribution and that's going to at the same time put a load on your 117
server so that's although I will discuss for 118
now on cloud front we have a lab on html5 websites and using cloud front in 119
front of that so I'll look forward to seeing you in that lab