Dynamic Content Delivery, Myth or Reality

by _karrect_, Thursday, 06 October 2016

Cloudfront is an awesome content delivery tool, but did you know you could also run your whole website (Yes, you read that right!) using it?

To few, this concept might be just another routine(Duh! I already knew that), but for my other friends, umm… Well, I think this post will help you understand exactly “How-To” use Cloudfront for Dynamic Content Delivery.

And yes, it is the Truth!

The Why-To before The How-To

One question that might arise, most definitely, is why do we need this kind of a setup. The AWS Elastic Load Balancer (ELB) claims to be more than capable of handling all these requests and with the addition of the Application Load Balancer, there is so much that the ELB can do now, but that’s a post for another time.

After attending a lot of AWS training sessions in my “early” years, I got pretty handy with architecting High-Availability solutions, and the ELB was a definite part of all the HA’s I was suggesting our customers to set up. Cloudfront was introduced to me as a (Static) Content Delivery Network with Akamai being the Oh!So!Famous! CDN. But Akamai, with all its beauty, ends up burning a hole in your pocket. Why not use a service that does not need any subscription fee, and charges only for the data delivered through its edge locations.

The Architecture

Below is a sample architecture of the intended deployment -

Multi-CDN Dynamic Delivery

Finally, The How-To

While the above architecture is self-explanatory, here is how you can setup multiple CDN’s with one(1) ELB and a fine tuned auto-scaling group with a Multi A-Z RDS. You can add more components as and when required.

Here I have assumed that we are running an Apache or Nginx Web Server along with multiple PHP applications that speak to a MySQL Multi A-Z RDS. All the Server(EC2 and RDS) Components are set up and we have to configure Cloudfront for serving (and caching) our website.

Now the next steps are very simple. Here goes -

  • Setup the ELB Listener configuration to allow traffic only on port 80 (or as per your custom port requirements) and set the listener configuration to forward requests to port 80 only.


  • Create 1 Cloudfront Distribution for each of the Websites (, and *

    • In the Origin Settings, select the target load balancer from the drop down and leave the other values default (or customise them according to your needs)

      Origin Settings

    • Add the relevant CNAMES to the distribution settings to make the website available through Cloudfront (Use Wildcards wherever applicable)

    • Apply a SSL Certificate for HTTPS delivery to the Distribution. Choose an ACM certificate or bring your own and convert it to a Cloudfront usable certificate.


    • Modify the default behaviour for the cache or create a new custom behaviour for delivering dynamic content. Below are some samples -

      Completely Dynamic [ Default (*) ] Behaviour

      Default Behaviour

      Customisations with header whitelisting

      Custom Behaviour

      and some cookie whitelisting

      Default Behaviour

  • Then save your distribution, make the relevant entries in your Route 53 Hosted Zones and Voila! You are now completely running off of Cloudfront and “truly” saving costs.

If your target websites have similar structures and are subdomains of the primary website, you can utilise 1 Cloudfront and 1 ELB for a similar configuration.

Example Wordpress Setup with Cloudfront

Here is a link to another post that elaborates on how to setup multiple behaviours to use the full capability of Wordpress with Cloudfront, without the need of additional plugins.

Get in touch with us on Email, Facebook or Twitter. We welcome reviews, criticism or general rantings any day of the week.




Rajit Kapoor aka _karrect_ is a "Senior Solutions Architect" with CloudCover. He is an upside down soul, and sometimes thinks about sleeping on the ceiling.