‫So now let's talk about cache behaviors.
‫The idea is that you may want to have different origin,
‫different caches for different URL path patterns.
‫For example, you want to have one specific cache behavior
‫for all your JPEG images based on your origin web server.
‫Or you may want to route different origins
‫or origin groups based on the content type
‫or the path pattern.
‫For example, you're saying, hey, for /images/*
‫just go to S3 for /api/*, go to my origin
‫and for /* then go to my default origin.
‫It's called also the default cache behavior.
‫So in this example of CloudFront,
‫we have two cache behaviors.
‫The first one is /api/*
‫which is sending us to our application load balancer origin.
‫And then we have the /* that is the default cache behavior
‫that is always /*.
‫And you can redirect, for example,
‫to an S3 bucket as an origin.
‫And so the users based on the resource they will get out
‫of CloudFront may be redirected
‫into the first cache behavior or the second cache behavior.
‫Now, when you add additional cache behaviors,
‫the default cache behavior, which is always /*
‫is always also going to be the last to be processed.
‫So we're going to see whether or not
‫there is a more specific match, and if not,
‫then we revert back to the default cache behavior.
‫So a use case for this, for example,
‫would be how to gate access
‫into an S3 bucket because we want to make sure
‫that users are properly signed in through a sign in page.
‫So the way we do it is that we define a cache behavior
‫for /login and so the users who hit the /login page
‫will be redirected to our EC2 instance.
‫And the role of our EC2 instance
‫is to generate CloudFront signed cookies.
‫So these signed cookies are sent back to the user
‫and the user will then use the signed cookies
‫to be able to access our default cache behavior,
‫which is any other URL, then /login
‫and then access our S3 bucket files.
‫And if the users are trying to access
‫the default cache behavior
‫without doing a login first, what we can do
‫is that we can set up the cache behavior
‫to only accept the request if signed cookies are present.
‫Therefore, we can redirect
‫to the /login page and we're good to go.
‫So this is a very good use case.
‫Another one of using different cache behaviors
‫is to maximize cache hit.
‫So for example, the static request may go into Amazon S3.
‫Here we don't have any cache policy
‫with any headers or session.
‫We maximize the cache hit based on just the resource we hit.
‫And then for dynamic, for example,
‫for a REST HTTP server that is using a load balancer
‫and EC2, you may want to cache based
‫on the correct headers and cookies based
‫on the cache policy you've defined as before.
‫So hopefully that makes sense.
‫I hope you liked it and I will see you in the next lecture.