Expand my Community achievements bar.

SOLVED

Using Cloudfront

Avatar

Level 5

Is anyone using Cloudfront in front of their dispatchers?

I think I've read there's no built-in invalidation of Cloudfront cache in AEM replication agents. 

 

One would think even a Cloudfront distribution with a fairly low TTL could increase performance across the world while potentially causing issues with the need for immediate updates and invalidations. 

 

I'm not yet familiar with how Cloudfront can be configured or perhaps targeted more aggressively to unchanging static assets vs more dynamic content like HTML text. 

 

Please tell me how you are using, or thinking of using Cloudfront. If you plan to build a custom invalidation agent for Cloudfront, how important is this vs. just going with a short lived cache, or perhaps customized TTLs for different parts of a page (if that is possible).

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

@this-that-the-otter Many of our clients use Cloudfront as their preferred CDN and problem statement of choosing between short lived TTLs vs Long lived TTLs with cache invalidations is always present irrespective of CDN we choose.

 

For me, I always prefer to have longer TTL and build custom invalidation logic which flush the page/asset cache upon publishing of it. But metric always depend on the client/customer/product you work on, ex: Assets, CSS and JS 30days and HTML - 1 day.

 

View solution in original post

5 Replies

Avatar

Correct answer by
Community Advisor

@this-that-the-otter Many of our clients use Cloudfront as their preferred CDN and problem statement of choosing between short lived TTLs vs Long lived TTLs with cache invalidations is always present irrespective of CDN we choose.

 

For me, I always prefer to have longer TTL and build custom invalidation logic which flush the page/asset cache upon publishing of it. But metric always depend on the client/customer/product you work on, ex: Assets, CSS and JS 30days and HTML - 1 day.

 

Thanks for sharing your experience Shashi. We would also prefer to do better (per page/per asset) invalidations vs. short-TTL CloudFront caching across-the-board - but until there is an out of the box integration within AEM, this would appear to involve development. 

As Arun mentioned, https://helpx.adobe.com/ie/experience-manager/kb/Flush-content-from-Amazon-CloudFront-CDN-AEM.html

explains some of the details. It would be great if the desired CloudFront invalidation functionality were a part of the ACS AEM Commons project. 

In the meantime, do you know of any open source projects that provide this functionality for AEM?

Or, can you share the steps you have used to achieve it in your work? 

If no, how much effort would you say is needed for a basic CloudFront invalidation mechanism?

With your solution, do you cache on the dispatchers too, and invalidate both dispatcher cache and CloudFront cache?

Avatar

Community Advisor

@this-that-the-otter yes we love to have it part of ACS Commons as it is more common problem stmt.. as it's open source we can try to contribute.

 

For now you can follow this document 

 

https://aem.design/blog/2021/04/25/creating-akamai-flush-agent

 

 

Basically you need a custom replication agent template, using which you can create replication agent, transport handler to execute cdn flush logic..(consider adding a delay logic just in case you are flushing cdn cache before resource gets published and flushed from dispatcher)

 

With above base snippets, and readily available cloudfront java api using aws Java sdk or http post should be closer.

 

I will keep dispatcher flush separate from above as it will be one to one with publisher and I will configure it on publisher itself.