CODEWITHSUNDEEP
amazon-web-servicesamazon-s3routescdncloudflare
Assaf Moldavsky
Assaf Moldavsky

Reputation: 1721

CloudFlare or AWS CDN links

I have a script that I install on a page and it will load some more JS and CSS from an S3 bucket.

I have versions, so when I do a release on Github for say 1.1.9 it will get deployed to /my-bucket/1.1.9/ on S3.

Question, if I want to have something like a symbolic link /my-bucket/v1 -> /my-bucket/1.1.9, how can I achieve this with AWS or CloudFlare?

The idea is that I want to release a new version by deploying it, to my bucket or whatever CDN, and than when I am ready I want to switch v1 to the latest 1.x.y version released. I want all websites to point to /v1 and get the latest when there is new release.

Is there a CDN or AWS service or configuration that will allow me to create a sort of a linux-like symbolic link like that?

Upvotes: 0

Views: 230

Answers (1)

Michael - sqlbot
Michael - sqlbot

Reputation: 178956

A simple solution with CloudFront requires a slight change in your path design:

Bucket:

/1.1.9/v1/foo

Browser:

/v1/foo

CloudFront Origin Path (on the Origin tab)

/1.1.9

Whatever you configure as the Origin Path is added to the beginning of whatever the browser requested before sending the request to the Origin server.

Note that changing this means you also need to do a cache invalidation, because responses are cached based on what was requested, not what was fetched.

There is a potential race condition here, between the time you change the config and invalidate -- there is no correlation in the order of operations between configuration changes and invalidation requests -- a config change followed by an invalidation may be completed after,¹ so will probably need to invalidate, update config, invalidate, verify that the distribution had progressed a stable state, then invalidate once more. You don't need to invalidate objects individually, just /* or /v1*. It would be best if only the resource directly requested is subject to the rewrite, and not it's dependencies. Remember, also, that browser caching is a big cost-saver that you can't leverage as fully if you use the same request URI to represent a different object over time.

More complicated path rewriting in CloudFront requires a Lambda@Edge Origin Request trigger (or you could use Viewer Request, but these run more often and thus cost more and add to overall latency).

¹ Invalidation requests -- though this is not documented and is strictly anecdotal -- appear to involve a bit of time travel. Invalidations are timestamped, and it appears that they invalidate anything cached before their timestamp, rather than before the time they propagate to the edge locations. Architecturally, it would make sense if CloudFront is designed such that invalidations don't actively purge content, but only serve as directives for the cache to consider any cached object as stale if it pre-dates the timestamp on the invalidation request, allowing the actual purge to take place in the background. Invalidations seem to complete too rapidly for any other explanation. This means creating an invalidation request after the distribution returns to the stable Deployed state would assure that everything old is really purged, and that another invalidation request when the change is initially submitted would catch most of the stragglers that might be served from cache before the change is propagated. Changes and invalidations do appear to propagate to the edges via independent pipelines, based on observed completion timing.

Upvotes: 1

Related Questions