This course has been updated! We now recommend you take the AWS For Front-End Engineers, v2 course.

Check out a free preview of the full AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course:
The "Cache Invalidations" Lesson is part of the full, AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course featured in this preview video. Here's what you'd learn in this lesson:

To deploy a new version of an application, Steve demonstrates how to invalidate versions of the previous version at the edge nodes of CloudFront.

Get Unlimited Access Now

Transcript from the "Cache Invalidations" Lesson

>> Steve Kinney: You cache, then you change, right? What is the process of deploying? Well, we build the app and then we push it to S3. Let's think about that. We know that the good thing about CloudFront is that if it thinks it has the page, it doesn't go to S3.

[00:00:23] So how do you deploy your app?
>> Steve Kinney: Right, technically, you could deploy, but it's probably unacceptable to have a day go by, right? And so you have a bunch of options. You can, this is an argument that we had, you can lower the caching time to five minutes.

[00:00:44] So t as long as people are hitting it relatively consistently, somebody will eat that longer term cost, and then everyone else will get the fresh one for the next five minutes, right? But that all depends on how much traffic you're getting. And it also means that somebody, every five minutes, is suffering the situation we had before.

[00:01:06] I don't love that, right? It's the easiest thing to do, but I don't love it.
>> Steve Kinney: The other thing we can do is we can create invalidations. Which is basically, with browser caching, you don't control people's browsers, right? You can't evict something from their cache. That's why service workers can be very dangerous if you get them wrong.

[00:01:28] Because it's really hard for you to take a cached version out of somebody's computer, right? You can't send messages to their computer. It's not cool, [LAUGH] right? On the other hand, CloudFront, you can be like, yo, get everything out of cache right now. Let's take a look at that real quick.

[00:01:48] So you can basically create an invalidation. So over here, see this Invalidations tab. We can say hey, CloudFront, I want you to kick everything out of cache. I know that I have made a change. I have deployed said change, please don't serve the version you have. Go back to S3 and get the latest and greatest version of my website.

>> Steve Kinney: We at Sun Grid create an invalidation every single time we deploy, right? Cuz that is where we have our fresh version application to which every time I say that, a backend engineer on my team goes, well, you only get 1,000 free invalidations a month. To which I say, if I am deploying more than 1,000 times a month, I will happily eat that cost, right?

[00:02:39] If we get to the fact that we are so efficient that we're deploying literally 1,000 or more times a month, for whatever that costs, for whatever number of pennies it costs, that is a high class problem to solve. I have personally not run into that, where we're deploying that frequently.

[00:02:55] But it is a thing to keep in mind. It's maybe important not to get willy nilly with it. Let's show what happens if we hit the Create Invalidation button. It's basically, what do you want to invalidate? So you can be like, I just wanna invalidate index.html, right? Or I just wanna invalidate these images.

[00:03:15] Personally, the way we deploy our application is Webpack is hashing each of those files, so the files are always unique, right? But index.html will have the reference to the new one, there's images. Here's the thing, each invalidation either counts towards your 1,000 invalidations a month or costs you money.

[00:03:35] However, it doesn't matter how much stuff you invalidate, right? So generally speaking, I would rather one person per edge node per deploy pay that cost of going back to S3 for everything than think that I have deployed a new version of some asset that I didn't properly invalidate and have it lingering around forever causing who knows what chaos.

[00:03:59] So what I'll usually do is I'll put a nice little star in there. Which is invalidate everything, everything you have in cache, invalidate it, right? Doesn't really matter for my client-side asset, or my JavaScript, my CSS, cuz they're fingerprinted anyway. They were gonna get new ones no matter what.

[00:04:15] It's just really index.html, which I want out, but it's a little sledge hammery, right? But I would like to feel safe that everything is out of cache, and I have something lingering around, cuz I don't know what, right? I don't need that in my life. You can go ahead and create an invalidation.

[00:04:35] And this will go ahead and clear out everything. You see it's in progress. It does need to distribute. Nothing with CloudFront is instantaneous. If you do something in CloudFront and go to the browser, try it out, but be pleasantly surprised if it is in any sense immediate. That seems annoying, but also remember you are literally distributing something to, I think, 114 locations around the world.

[00:05:01] It's cool. [LAUGH] Don't worry about it, but it is. And once you have this set up and running, you are probably not playing with CloudFront that much, right? And we'll talk about the fact that we'll trigger these when we get our CI/CD process in place, right? We will not be going into CloudFront as a step to invalidate.

[00:05:22] We'll create the invalidations programmatically.