CloudFront with multiple origins

A while ago I had bragged about how this site is published – heavily customized WordPress deployed on S3. Though I had left out some of the indigenous parts which I would like to explain in this article. The main aspect explained would be the convergence of multiple origins with CloudFront and configuring behaviours for different cache settings.

The flow started with the static site on S3 with the origin access identity configured. The behaviours were configured such that wp-content/* and wp-includes/* were having a bit higher caching than the blog pages.

Initial Origin
Cache for Default Behaviour
High Cache Settings

I had a lot of downloads on the site, which was originally running on a lightsail and before on a shared host. There was the download manager plugin with an extension to show the download count also. I wanted to incorporate this feature into the new hosting solution. Well, this turned out to be a bit more complicated than I thought.

I had to add an API Gateway – Lambda combination to log the count and then redirect to the S3 signed URL. Client-Side Javascript would find and update contents of a download link with the count and title when and where required. There the CORS would add overhead to every request which I wanted to avoid, and the download URL wanted to look like part of the main site itself. Hence declared these as two different origins and configured with required request types, and low or no caching.

Final Origins Configured
Final Behaviors Configured
The cache is disabled for the Count and Download URL


The outcome is really good that the count of downloads are updated when it occurs and the display shows the counts properly. As the article is strictly for the explanation of multiple origins and behaviours, the supporting lambda and javascript code is intentionally left out.