When I push a new site, I update the Origin ID to point at a new version, per screenshot:

enter image description here

This in turn triggers the Status change from Deployed to In progress on the main CF Distributions console. My understanding is that this does NOT trigger actual invalidation of the edge caches. Does this mean, I have to wait for the status to change again to Deployed before I can trigger the invalidation? If so, that's a terrible dependency for any automated deployment to manage. I suppose it has to keep checking until the deployment status shows done then trigger invalidation.

In a nutshell, why is updating the CF's Origin Path so painfully slow?

If there is a better way to deploy a new site that has the index page in S3/CF, I'm all ears :)


Use asset versioning.

V1 of your site will refer to /v1/js/app.js, /v1/img/logo.png, etc.

When you push a new version it will refer to /v2/js/app.js, /v2/img/logo.png, etc.

That way clients that still need to refer to v1 assets due to some cached content on their side can do so and won't be disrupted by the invalidation. New visitors will get all-v2 content and will not be confused by any v1 stuff laying around.

Eventually a day later you can remove and invalidate v1, but that won't be a time-sensitive task.

Of course you don't have to use v1, v2, etc, use git hash if you prefer or date or something else.

Update: As @Michael-sqlbot pointed out in the comments the root object returned for "GET /" is a special case as it won't benefit from this path-based versioning. There you've got a couple of options:

  1. Set a short expiration time, say 5 minutes for the root object. That way it will auto-expire shortly after you upload the new website version.

  2. Alternatively upload the new version and invalidate that /index.html - it will be much faster and cheaper than invalidating potentially thousands of file assets.

In both cases there will be a short overlap between uploading V2 and expiring V1's /index.html from all CloudFronts but it doesn't matter because all the V1 assets are still available. Regardless if your visitors receive V1 or V2 index.html in that period they will still get a functional website.

Hope that helps :)

  • This is valid but it doesn't address the fact that the object returned for GET / isn't a candidate for path-based asset versioning, and still needs to be invalidated. Aug 13 '19 at 0:22
  • @Michael-sqlbot true but that’s invalidating a single object, not thousands potentially. Possible workaround is to have a short expiration for the ‘/‘ object, say 5 minutes, so it will auto expire soon after pushing out the new site.
    – MLu
    Aug 13 '19 at 0:29
  • @mlu I'm already doing versioned assets. The problem is that the index page (GET /) needs to be refreshed since it in turn points at the versioned-asset files. My specific beef is with this: "why is updating the CF's Origin Path so painfully slow?" I consider it a bug of CF since changing the origin path should have no delay, it's not like it's invaliding the edges.
    – Slawomir
    Aug 13 '19 at 3:03
  • @Slawomir it’s slow because it has to talk to 187 CloudFront locations around the world (as of today) and confirm with each one that the change has been made before returning a success to you. However you shouldn’t need to remove the previous version when uploading a new one. Keep both sets of assets in place and let it roll over at its own pace, e.g. through setting an expiration header on the root object as detailed above.
    – MLu
    Aug 13 '19 at 3:11
  • @mlu I'm not removing anything. I think you're missing the point. The invalidation can take its time I understand the need for reaching out to all the edges. The lag in the change of the origin-path is the problem. Once the origin-path is marked as finished (minutes later) then the invalidation is triggered with a "/*". That second part is justified to take time, not the first part.
    – Slawomir
    Aug 13 '19 at 3:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.