‫So let's take some time
‫to understand how caching works in CloudFront.
‫So the cache lives
‫at each CloudFront edge location.
‫So you'll have as many caches
‫as edge locations.
‫And each object in the cache
‫is going to be identified
‫by a Cache Key.
‫We'll see what the Cache Key is
‫in the next slide.
‫But the idea is that a request made
‫through CloudFront edge location.
‫The edge location is first going
‫to check whether or not the object
‫has been cached.
‫And if it's in the cache,
‫has it expired or not based
‫on the time to live.
‫And then if not,
‫if it's not in the cache,
‫then the request is forwarded
‫and we'll see how it's forwarded
‫to your origin.
‫And then the response from the origin
‫is cached into your edge location.
‫So that future request return a cache result.
‫So you want to maximize the Cache Hit ratio
‫by minimizing request to the origin.
‫That means that you want to cache
‫as much stuff as possible
‫in your edge locations.
‫We'll see as well that it's possible
‫for you to not wait
‫until the item expires based on a TTL.
‫If you wanna remove it from the cache,
‫you can create an invalidation.
‫So what is a CloudFront Cache Key
‫and what do we cache on?
‫Well, a Cache Key is a unique identifier
‫for each object in the cache.
‫And by default, if you don't do anything,
‫it's made up of the host name
‫and the resource portion of URL.
‫So in this example,
‫there is mywebsite.com.
‫So that's the host name.
‫And then there is the
‫GET/content/stories/example-story.html.
‫That is the resource portion of the URL.
‫That means that anyone
‫that makes a similar request
‫in case there is a cache miss,
‫well, first, we're going
‫to get the object from the origin
‫but then the object
‫is going to be cached
‫based on these two keys right here,
‫the host name
‫and the resource portion of the URL.
‫And then a request that looks similar
‫with the same host name
‫and the same resource portion
‫will hit the cache
‫and will get a cache hit.
‫But sometimes you want your Cache Key
‫to be a bit more complicated
‫because sometimes, well,
‫you have content that will vary
‫based on the user
‫or the device or the language
‫or the location the user
‫is from and so on.
‫And so we want to do
‫is to enhance the Cache Key
‫and add more information.
‫So we wanna add maybe HTTP headers
‫or cookies or query strings in it.
‫And to define how to create
‫that Cache Key, we have to define
‫what's called a CloudFront cache policy.
‫So this cache policy can be caching
‫based on the HTTP headers.
‫So you can select none of them
‫or a whitelist to say
‫which one you want to include.
‫You have the cookies.
‫So you can select none of them,
‫a whitelist or list you wanna include
‫or all or all accept.
‫And we have the query strings.
‫Again, similarly, do you want
‫to include none of them,
‫a whitelist, all except, or all?
‫And this is basically going
‫to configure how your Cache Key
‫is going to be created.
‫In the cache policy,
‫you can also control the TTL.
‫So from zero seconds up
‫to one year in the cache.
‫And then you can also control
‫that setting using specific headers
‫called the cache control header
‫or the expires header.
‫So you can create your own cache policies
‫or you can use predefined
‫managed policies by AWS.
‫And the very important thing
‫I want you to remember
‫is that all the HTTP headers,
‫cookies and query strings
‫that you include in the Cache Key
‫will be automatically included
‫and forwarded to your origin request.
‫So in the case of HTTP header
‫to give you an example,
‫let's say we have this request
‫and we have a language fr-fr,
‫meaning that we request the blog
‫in the French language.
‫How does that work?
‫Well, if we define a none
‫HTTP header cache policy,
‫then none of the headers
‫are going to be cached
‫and the headers will not be forwarded
‫unless and I will show you what happens
‫in the rest of this lecture.
‫So by default, headers
‫will not be forwarded.
‫But this gives you
‫the best caching performance
‫because you don't have any headers in it.
‫If you want to whitelist specific headers
‫and that may mean necessary
‫because while you want
‫to have the language as a Cache Key,
‫then you specify which headers you want
‫to include in the Cache Key,
‫for example, the language header.
‫And then this header, the language
‫will also be forwarded to your origin
‫so that the origin
‫can actually respond to the request
‫and give you the blog
‫in the correct language.
‫So this is a very similar mechanism
‫for query strings.
‫So query strings are what happens
‫in the URL after a question mark.
‫So for example, border equals red
‫and size equals large.
‫So here, we want a cat image.
‫But apparently, it's going to be customized
‫a little bit by the origin.
‫So again, if you have none,
‫then none of the query strings
‫are going to be used for the Cache Key
‫and they're not going
‫to be forwarded to your origin.
‫Whitelist, you specify
‫which query strings you want included.
‫Include all-except, you specify
‫which ones you don't want
‫but the rest passes
‫and all is including all the query strings
‫in the Cache Keys
‫and all the query strings
‫are going to be forwarded.
‫But of course, if you have many,
‫this gives you the worst caching performance.
‫So we've seen that
‫when we define a cache policy,
‫we can have query strings,
‫cookies and headers as whitelist.
‫For example, to choose (indistinct) want
‫and they will be forwarded to the origin.
‫But what if you want
‫to include some stuff
‫in the origin request, okay?
‫But you don't want to include them
‫in the Cache Key.
‫In that case, you can define
‫what's called an origin request policy.
‫So the idea is that
‫you can include extra HTTP headers
‫or cookies or query strings
‫but they will be forwarded to the origin
‫but they're not going to be used
‫in the Cache Key.
‫So you can also,
‫as part of the origin request policy,
‫add custom HTTP headers
‫or CloudFront HTTP headers to the origin
‫even though they were not present
‫in the viewer request.
‫For example, if you wanted
‫to pass an API key or a secret header.
‫So you can create your own policy
‫or you can use predefined managed policies.
‫And so at this point,
‫you may be confused like,
‫what is really the difference
‫between Cache Keys
‫and origin request policy?
‫Well, let me try to summarize
‫as best as I can.
‫So the request will come
‫with some query strings,
‫some cookies, some headers,
‫and then we will cache based
‫on the cache policy.
‫For example, we want to cache here
‫on the host name, the resource,
‫and a header called authorization.
‫But then, your origin may need more
‫than these three things to actually work
‫and to actually serve properly the request.
‫So you may want to add the user agents,
‫the session ID and the ref query string
‫as part of your request to the origin.
‫So in this case,
‫the request to the origin
‫is going to be enhanced
‫but then the caching will not happen
‫based on what we forwarded
‫to the origin request policy.
‫It's only going to be based
‫on the cache policy.
‫So I hope you see the synergy
‫between these two
‫and that should be enough
‫to answer questions at the exam.
‫All right, that's it.
‫I hope you liked it
‫and I will see you in the next lecture.