Adobe Experience Manager (AEM) Cloud Topology: Architecture and Deployment
AEM’s Foundation
Cloud-Native Services
AEM’s Foundation
Adobe Experience Manager (AEM) is built on proven open-source technologies to provide a modular, scalable CMS. At its core, AEM uses the OSGi framework (via Apache Felix) for modules, Jackrabbit Oak as a JCR (Java Content Repository) storage, and Apache Sling as its web framework. In practice, this means all AEM features (sites, assets, forms, etc.) run as collections of OSGi bundles (Java JARs) managed by an OSGi container. This modular design (often called AEM’s architecture stack) allows bundles to be installed, updated, or removed dynamically without restarting the server.
Cloud-Native Services
As a Cloud Service (AEMaaCS), AEM further evolves this stack into a dynamic, microservices-based cloud platform.
AEMaaCS decomposes into logical services (e.g. authoring and publishing tiers, content repositories, asset compute, dispatchers, CDN) that all run in the cloud. Content is stored outside the author/publish JVMs in a shared blob store, enabling the system to “autoscale” – automatically adding or removing AEM instances on demand based on traffic.
For example, if a spike in site traffic occurs, AEMaaCS can provision more Publisher instances and dispatchers on the fly. Likewise, idle instances can be spun down during low load. This autoscaling ensures applications stay responsive and only use (and pay for) the resources needed.
Key Architectural Layers
At the bottom is the Content Repository Service (built on Jackrabbit Oak), which is shared by all author/preview/publish nodes. Above that are the container orchestration services running AEM itself – there are always at least two Author nodes (for high availability) and two Publish nodes (in a publish farm behind dispatchers). An Adobe-managed CDN fronts the Publish tier for fast delivery. Cloud Manager (Adobe’s CI/CD) sits atop everything, managing updates and deployments.
Adobe organizes Cloud setups hierarchically
Each customer is a Tenant (IMS Org), which can contain one or more Programs. Each Program can have multiple Environments – typically one Production environment plus matching Stage and Development (and optional Rapid Dev) environments. For example, every production run has a 1:1 Stage env for testing. This structure (Tenant → Program → Environment) is enforced by Cloud Manager to isolate resources and permissions.
Advantages of the Cloud Model
AEMaaCS brings features like continuous updates, zero downtime deployments, and native cloud scaling. Updates to AEM itself happen automatically on a quarterly cadence, and customer code is deployed through Cloud Manager’s pipelines with rolling updates to avoid any service interruption. Resources auto-adjust to traffic, binary assets live in a scalable datastore, and content delivery is accelerated via a global CDN. All these make AEMaaCS a highly resilient, ever-green platform for digital experiences.
Summary of AEM Cloud Topology
AEM’s architecture stack (OSGi, Oak/JCR, Sling) provides the base platform, while the Cloud Service wraps it in a dynamic, orchestrated topology. This topology includes multiple clustered tiers (authoring, preview, publishing) and services (content repository, asset processing, CI/CD) that Adobe manages centrally.
The result is an always-on, autoscaling CMS environment that abstracts away traditional server and dispatcher maintenance.