Changing "Origin Path" in CloudFront takes very long to kick in

Question

We have a static site hosted in S3 and delivered with CloudFront. The site works but rolling out updates takes quite long -- hours or longer. Specifically, changing the Origin Path is not reflected on edge locations nearly as quickly as desired.

Here is what we are trying to achieve...

Our S3 bucket is configured to host a website. It stores multiple versions of the same site. There is a sub-directory per git tag. For example:

/git-v1
/git-v2
/git-v3
..

The goal is to tell CF to start serving a new version of the site per Origin Path setting. We don't want to invalidate old objects, just keep advancing the version by creating a new directory and pointing CF at it. The status under CloudFront Distributions shows "Deployed" for a long time, yet the edge locations continue to ignore the new Origin Path.

Any idea for how to make CF start serving the new sub-directory quicker would be greatly appreciated.

Answer 1

The Origin Path setting is applied to the request after the cache is checked... not before. When the object requested in the URI is not in the cache, the object is requested from the Origin server. At that point, Origin Path is prepended to the incoming request path, then sent to the origin. Caching is based on the incoming request path.¹

The setting itself takes effect quickly, often in seconds, but doesn't purge the cache.

If this is just for versioning the root page, you can leave the origin path blank, change the Default Root Object to the new root object, and then just invalidate /. Or, you can keep doing what you are doing, and invalidate /* after making the change. Free invalidations are limited to 1000 per month, but invalidating /* (or any wildcard) only counts as 1 invalidation, no matter how many objects the wildcard matches.

---

¹ incoming request path also refers to the path as it stands after a Lambda@Edge Viewer Request trigger modifies it, if applicable.