How to Integrate AEM with a CDN such as Akamai

Having a Content Delivery Network (CDN) such as Akamai, Amazon CloudFront, or CloudFlare in front of your CQ/AEM Dispatchers is of tremendous value if your audience spans the Globe and/or your request traffic is prone to unexpected spikes. A CDN allows you to run fewer CQ/AEM servers, saving on licensing as well as other runtime infrastructure costs.

What follows is a generic example based on integrating AEM 6 running on the Amazon Cloud with Akamai. You might not need to perform all of the steps detailed below.
Terminology

ELB : Elastic Load Balancer (Amazon)
It has its own Amazon-provided DNS name, and two associated IP addresses that can change on you without warning. It sits in front of your CQ/AEM Dispatchers which in turn sit in front of your CQ/AEM “publish” instances.

Origin (Akamai)
This is where Akamai will point their cache to when it’s time to refresh content in the cache.
Steps

1) Using Amazon Route 53, register your domain (company.com). This will automatically create a DNS “Hosted Zone” in Route 53 with two “Record Sets”, one of type “NS” (Name Server) containing a list at least four Amazon DNS (“name”) servers and the other of type “SOA” (Start of Authority).

2) Decide the domain names for your various environments such as DEV, STAGING etc. such as dev.company.com and stage.company.com For each, create a recordset of the type “CNAME”, and point the record set towards the respective ELBs that front those environments.

If your PROD domain (public-facing hostname) will be www.company.com, create two additional recordsets, one for www.company.com and the other origin-www.company.com See below.

4) Create a recordset for www.company.com of type CNAME, pointing to a name that Akamai will provide. It will look something like www.company.com.edgesuite.net

This will cause users typing in http://www.company.com to be directed to Akamai’s edge caches first.

5) Create a recordset for origin-www.company.com of type CNAME, pointing to the DNS name of the ELB that fronts your PRODUCTION CQ/AEM Dispatchers. It will look something like dualstack.company-elb1usea-Z6Z55BXTERAW-113753114.us-east-1.elb.amazonaws.com

If the Akamai edge cache happens to not contain the page that a user requested, Akamai will turn around and request the page from here.

6) Test

Requesting the page http://www.company.com/content/geometrixx-outdoors/en.html

will go to your nearest Akamai edge cache which will turn around and request the page

http://origin-www.company.com/content/geometrixx-outdoors/en.html

which will cause a request to be made to

http://dualstack.company-elb1usea-Z6Z55BXTERAW-113753114.us-east-1.elb.amazonaws.com/content/geometrixx-outdoors/en.html

which will in turn request the CQ/AEM Dispatcher for the page

which will then request one of the CQ/AEM Publish instances for the page.

Once this is all done, the next request for the same page will be (hopefully) served up quickly from the Akamai edge cache and none of the other servers in the chain will even see it coming their way :-)

7) Request Akamai for an account with their Luna Control Center which will let you further configure your Akamai cache.

NOTE:
Currently, there is no built-in feature in CQ/AEM to invalidate the Akamai cache when a web page is updated in CQ “author” and published/replicated. Of course, the Cache Flush Agent that is built into CQ/AEM will ensure that the CQ/AEM Dispatcher cache is invalidated.

Please ask your Adobe partner for this feature - they might already have something built which invokes the Akamai REST API for cache invalidation. Also, see if Adobe Consulting has built anything similar on their GitHub repo.