Sample Architecture Diagrams for Adobe Experience Manager

I was recently asked by a customer why I think Rackspace is the best place to host an Adobe Experience Manager site. After working on a number of wildly different AEM/CQ installations hosted on both VMware and Bare Metal at customer data centers, co-located Bare Metal, ISP-managed VMWare, AWS and OpenStack, I can say the biggest reason I recommend Rackspace for AEM is simple: Rackspace has the hosting industry’s deepest toolbox.

AEM, more so than many CMS frameworks, can have some intense CPU and I/O requirements. But it can also vary widely on how it needs to be deployed, depending on a vast number of factors. Things like spikiness of traffic, predictability of the traffic spikes, how cache-able the site is, the volume of published content, the presence of social features and user-generated content, authoring volume, number of concurrent authors and durability of the authoring environment (among other things) can drastically change what the “ideal” architecture is for an AEM environment.

Some AEM environments are deployed, and then once pushed out, never need to change their sizing. Two publishers, two dispatchers and an author are able to handle all of the site’s traffic spikes without a need for scaling. Sites like these sometimes lend themselves very well to a static private cloud environment, which is provisioned once and then basically left as-is.

Other environments have heavy usage on the author tier which, unfortunately, have always had the crippling limitation of an inability to scale horizontally. If you’ve got hundreds of AEM authoring users, or otherwise don’t have the ability to shard your author/DAM workflows to separate servers, your only option is to make the Author server as powerful as possible.

This type of requirement (not at all unusual for heavy digital asset management users or sites with a lot of authors) lends itself to an author hosted on Bare Metal, running on a dedicated multi-socket server with high-end CPUs, and its own dedicated, high-speed storage.

Other sites have widely varying traffic patterns and need to be able to expand relatively quickly from a handful of publish nodes up to 15, 20 or 30 publishers, to be able to handle traffic. Such sites pretty much require being deployed in an AWS or OpenStack type cloud, where you can quickly clone existing publish nodes, create replication queues on the fly and cut and paste until the site is performing well.

My point here is that there is absolutely no “one size fits all” for AEM sites, and it’s nice to be well-supported by expert sysadmins on whatever architecture makes sense for your setup. Rackspace has not only a crew of deeply-experienced AEM engineers and architects, but also literally thousands of customer-facing engineers who are available 24×7×365 to handle Linux, networking, security, load balancer and any other type of platform issue that might come up — regardless of what platform or symphony of platforms you happen to be deploying onto.

Sample AEM Architecture Diagrams

The above being said, I wanted to share a few basic AEM architecture diagrams, which highlight some of the various ways AEM can and has been deployed at Rackspace, depending on customer and business requirements.

Rackspace Managed Cloud for AEM

A large percentage of AEM installations can make use of a relatively straightforward architecture of two-to-three AEM Publisher/Dispatcher pairs, and a single AEM Author.   This type of configuration is handled extremely well by our flexible Managed Cloud for AEM solution:


This solution is a fully managed, as-a-service product for Adobe Experience Manager 6.1 and 6.2, built on top of AWS products and infrastructure, but supported entirely by Rackspace dedicated cloud engineers and AEM application support engineers. It’s a turnkey solution designed to rapidly deploy AEM infrastructure in a fraction of the time needed for dedicated infrastructure, using the power of AWS cloud infrastructure but with the backing and expertise of our AEM team.

The Managed Cloud for AEM product allows one to rapidly deploy as many publish instances as needed, with scalable instance sizes to match your workload, both on the author side as well as the publish side. The diagram above shows one potential configuration.

This solution is not a fit for all use cases, though, as some of the other architectures below illustrate.

Hybrid AEM deployment with Rackspace Private Cloud, separate Bare Metal authors for content and asset management


The architecture depicted above assumes a relatively constant load against publishers (or one where spikes are mitigated/swallowed by dispatcher cache and Akamai) so publishers can be statically deployed with VMware private cloud virtual machines. On the author tier, some companies find that there are two entirely separate activities that put load on the author —Digital Asset Management or DAM uploading (with all of the CPU-intensive activity that goes along with it, in terms of transcoding, image rendering, PDF resizing, etc), and separately, content authoring. In such a scenario, it makes sense to separate the DAM onto a separate AEM author server, so heavy uploads that max out all available CPUs don’t then make for an intolerably slow authoring experience.

AEM architecture diagram: sharded author with cloud publishers

The below diagram represents site with heavy authoring requirements so that it makes sense to shard out individual sites onto their own physical authoring environments. A Solr Cloud cluster plugs into the authors for indexing DAM assets and assisting with the custom authoring UI. The publish tier is served by Rackspace public cloud servers (OpenStack) which can easily be cloned and scaled up and down to meet load demands.


There are a vast number of other architecture diagrams I’d like to share (once anonymized and such!) including those for Rackspace’s new Managed Cloud AEM service which provides on-demand cloud instances for AEM at the click of a button, and others which are maintained and supported 24×7×365 by a team of experienced AEM, Linux, Cloud and Network Security folks.

Overall, I hope the above was a helpful introduction to just a few of the AEM deployments we specialize in at Rackspace, and a reflection of the deep set of tools we possess when it comes to optimizing AEM environments.

Tad Reeves is an Adobe Experience Manager engineer on the Rackspace Critical Application Support team. He came to Rackspace after working as a DevOps engineer on numerous AEM/CQ-driven websites, as well as having worn a number of other hats around site development, UX design, infrastructure architecture and dreaming of the perfect deployment pipeline. He lives in Portland, Oregon, and spends as much time as possible out mountain biking with his wife and three kids.


    • Thanks Sudesh! I’m just now (finally) working on a follow up to this with alternative architectures based on AEM 6.3. Which 3rd party integrations did you want details on?

  1. We are trying out for AEM deployments partnerships. This gives us a view on the Rackspace environment and services. Thanks for the details. Expecting more scenarios where deployments are done.


Please enter your comment!
Please enter your name here