Stephane: So here is a deep dive lecture
on CloudFront Caching.
And on CloudFront you can cache on,
based on multiple things.
And we'll do a deep dive on all those.
So headers, session cookies, query string parameters.
And based on the combinations
of what you set for these parameters,
the cache is going to be less or more efficient.
Now the cache will live on
each CloudFront edge locations around the world.
So the idea is that the client will make a request
into an edge location
and if the Edge location has the data in the cache,
it will serve the data from the cache, okay,
based on the headers and the cookies
and it receives based on the TTL of what's in the cache.
And then if it's not from the cache
then it will forward the request to the origin, okay,
and reaches the data sent into the client's
and cache the results.
So you want to maximize the cache hit
to minimize requests on the origin.
This is the whole idea behind using
a CloudFront distribution.
And you can control the time to live, we'll see how,
using a header.
And there are two headers you can control,
there's the cache control header
and there is the expires header.
And you can invalidate parts of the cache
using the create invalidation API.
So now let's do a deep dive into the caching behavior
for each of the following.
So the first is headers.
And so when the client passes an HTTP request
to your CloudFront distribution,
it passes headers with it.
And headers is what you see in this diagram.
So it's the combination of host and then a value,
user agent and a value, date and a value,
authorization and a value, keep alive and a value,
accept range and a value.
And the headers could be really whatever you want.
So saying get this image, cat.jpg,
using the protocol HTTP 1.1,
and here are the headers that I want to pass to.
So you can configure CloudFront in three ways,
you can afford all the headers to your origin.
That means there's going to be no caching,
every request will go to the origin.
And so effectively you're not using CloudFront for caching
if you forward all headers.
And in this case,
this TTL must be set to zero
because you're not doing any caching in CloudFront.
If you forward a whitelist of headers,
that means you only forward some headers
as part of this request,
then the caching is going to be based
on all the values in the specified headers.
And if you do none,
suppose you forward zero headers,
then the forward is going to be
only done for the default headers, okay,
and is going to be no caching based on the request headers.
And is going to give you obviously
the best caching performance
because the headers are just removed from the request.
So whether or not you want to forward
all headers, whitelist header,
or if you want to forward zero headers, okay,
it's up to you and to what your application does.
Maybe your application needs some headers
or maybe it doesn't need some headers.
And it's very important for you to understand that
it's a more of an application specific behavior,
but here I'm explaining how CloudFront cache works.
Okay, so if you have a look,
then we have a request that's being made
with a lot of headers, okay?
And then this is going to have
a whitelisting in this example, okay?
So we're going to a whitelist a few headers,
we're going to whitelist the host
and the authorization header.
And so these are the headers
that are going to be passed on to your origin
and then the cache will happen, okay, at this stage.
And so what will happen is that,
because you are passing less values from your clients
all the way to your origin, less values of the headers,
you're going have better caching
because you have less values to cache, okay?
And the idea is that
if the same request comes with the same headers
then CloudFront will know how to respond
to that request directly.
So it's up to you again to see how you want
the behavior to be done.
So there is a big question that can come up with the exam
which is talking about CloudFront's origin headers
and CloudFront cache behavior.
So there is origin custom headers,
and this is a setting you can set on your origin itself.
So that means that's for every single request,
this is an origin-level setting,
and it will set a constant header, name and header value
for all requests made to your origin.
That means that every single request no matter what
comes with some headers
and CloudFront will add on some headers of its own
that you specify right here.
They're called origin custom headers.
A use case for that would be, for example,
if you wanted to tell your origin
that a request was coming from CloudFront
then you could define a custom header
for this if you want it to.
So this is going to be custom
and constant no matter what, okay?
But you have behavior settings.
And behavior settings
allow you to set your whitelist of headers.
And this is something you set at the behavior level, okay?
And this one is called the cache behavior
because this is going to be used for caching.
The first origin custom headers are not used for caching,
okay, they're used to just pass on headers to the origin,
but the second one is a cache behavior.
So this is cache-related settings
and it will contain a list of all the headers
to forward to your origin and to cache onto.
Cause you can see in my example I'm passing on
the CloudFront is desktop viewer
or CloudFront is mobile viewer
as headers that are going to be whitelisted
and passed on to origin.
So next we have the caching TTL.
So as I said,
the origin has to respond with a header if you want to.
So the header can be cache control max-age,
or there is an expires header as well
but the newest standard and the best way to do things
in CloudFront is to use the cache control max-age header
when replying from the origin to CloudFront.
And if the origin always sends back
to the cache control header
then you can set the TTL to be directly controlled
by the header and therefore by your application.
But in case you wanted to
set min and max boundaries for the TTL,
you can choose customize in the object caching settings.
So at the again, behavior level setting, okay,
because this is a caching behavior,
you can say for object caching, use origin cache headers.
In this case your application
will set the cache no matter what.
Or you can customize it to have a minimum TTL, a maximum TTL
and a default TTL.
And the idea is that if the cache control header is missing
from a reply, from your origin,
then it will default to default value.
So if you have a look, this is the TTL, okay,
there's going to be a min TTL no matter what,
a max TTL no matter what,
then your application will turn
a cache control header, okay?
And this is optional but recommended,
if the cache control is less than the min,
obviously the min is going to be used.
If the cache control is more than the max
then the max is going to be used, okay?
And if the cache control is missing
then the TTL that will be applied
is the default TTL that you set up in these settings.
So hopefully that helps you understand
how caching works and how the TTL works.
So now we're going to have a look at cookies
and query string parameters,
but the idea behind it is quite similar.
So cookies are what?
Well, cookies are a specific header,
but in the header named cookie
you're going to have a lot of key value pairs.
So in this example we'll have
username equals John Doe, location equals UK,
lang equals eng, and user ID equals 12342.
So the idea with this is that you're pricing
four cookies as part of this request.
And cookies can be again,
have three different settings.
So the default is to not process the cookies.
That mean that the caching will not be based on cookies
and the cookies are not going to be forwarded
from CloudFront to your origin.
Or you can forward a whitelist of cookies
in which case the caching will be based
on the values in all the specified cookies.
Or you can forward all cookies,
which gives you obviously the worst caching performance,
but allows your application to use all of them.
So, again, what you set depends on your application.
How are cookies used within your application
is very important.
And then you would set up CloudFront accordingly
to have the best caching performance.
So it's going to be the same idea here.
So here I have a request
and we're going to whitelist user ID.
So my origin is only going to receive this request
with a cookie, user ID equals 12342.
And then the,
this request going to be forwarded
and is going to be better caching
because you have less cookies values
from what is being sent from the client to CloudFront
and what is passed on from CloudFront to your origin.
Similar behavior for query string parameters.
So if we have a look at this,
this is a GET.
And this time there is a question mark
and there's border equals red and size equals large, okay?
And this is going to be always in the URL.
So you have three options,
default, it should not processed them.
That means they are not passed to your origin
and caching is not going to be based on this query strings.
Or you can forward a whitelist of query strings
and then the caching is going to be based on this whitelist.
Or you can forward all query strings
and then you're going to have caching
based on all parameters.
But again this is going to view
the worst caching performance
because you have many, many more values.
So as you can see, three different concepts,
we have headers, we have cookies
and we have query string parameters, okay?
But the idea is that the settings are very, very similar
and the behavior is very, very similar.
So in this example,
well I just whitelist the size query string parameter.
So the size only is passed to my origin
and then my origin can make a decision based on that.
And you get better caching
because you have less query string parameters values.
And I made a small typo,
but I will correct that in the PowerPoints.
Okay, so finally,
how do you maximize cache hits?
Well, you can separate static and dynamic distributions.
So, say you have a CloudFront layer,
all the static requests should go to CloudFront
into a static contents S3 bucket.
And here you don't use headers,
you don't use cookies,
you don't have your session caching rules, okay?
And you're going to have maximize cache hits
because while the content is coming back from S3 as static.
But then all the dynamic content,
all the stuff that can be dynamized
and then you pass onto your application running maybe
on your ALB plus EC2 instances or API gateway and lambda,
maybe they will be using some headers and some cookies.
Then you configure your CloudFront distribution
just like I just told you from the previous settings, okay,
and you best on exactly what's similar to your application.
And again, you would maximize cache there.
So it's quite recommended to split these two together.
So to summarize, to increase the cache hit ratio,
well, just have a look at the CloudWatch metric,
specify how long the objects should be in your cache.
So use the cache control max-age header.
Specify none of them,
or the minimally required headers.
Specify none or the minimally required cookies
and same for the query string parameters.
And finally separate the static and dynamic distribution.
So that means you can have two origins
for your CloudFront distribution, okay?
So I hope that helps.
I hope that's helpful to you.
I hope you understand what I mean behind caching.
This will help you
answer one or two questions at the exam.
I hope you like this lecture,
and I will see you in the next lecture.