7.2 AEM Deployment Topologies & Cloud Architecture

7.2 AEM Deployment Topologies & Cloud Architecture

Quick Answer: AEM 6.5 deployments are sized and operated by the customer or managed-service team, often using SegmentNodeStore for standalone instances and DocumentNodeStore where supported clustering is required. AEM as a Cloud Service provides managed Author, Publish, Dispatcher, and CDN services, separates immutable code from mutable content with Composite NodeStore, distributes content between Author and Publish, and offloads eligible asset processing.

Functional Tiers

A production Sites request normally travels through these responsibilities:

1. Adobe-managed CDN: Terminates edge traffic and can serve responses permitted by HTTP caching rules.
2. Apache HTTP Server and Dispatcher: Applies rewrites and security filters, serves its filesystem cache, and forwards misses.
3. AEM Publish: Resolves Sling resources and renders HTML or JSON for public delivery.
4. AEM Author: Provides authenticated authoring, workflow, and publication controls. It is not on the public page-rendering path.

Content publication moves approved repository state from Author toward Publish. Do not diagram Author and Publish as two compute groups directly reading the same mutable content database. They are separate services with a managed content-distribution path between them.

AEM 6.5 Persistence Choices

SegmentNodeStore (often called TarMK) stores repository segments on a filesystem. It is a common default for standalone AEM 6.5 author and publish instances and can be paired with supported standby or availability designs. It offers simple local I/O but is not an active-active multi-writer cluster.

DocumentNodeStore stores node documents in a supported MongoDB or relational backend and enables clustered repository nodes. It adds networked-database operations and requires database administration, monitoring, and topology planning. Binary storage can be external to either NodeStore through a Data Store.

The choice is not merely a speed contest. Recovery objectives, clustering needs, storage layout, operational skill, and Adobe support guidance all matter.

Composite NodeStore in Cloud Service

AEM as a Cloud Service uses Oak Composite NodeStore so a running release can combine:

• an immutable mount containing the product and deployed application code, including /libs and /apps; and
• a mutable DocumentNodeStore-backed repository containing paths such as /content and /conf.

During a rolling version update, the old release and new release each have their own immutable code mount while both can reference the applicable mutable repository for that service. This separation allows ready nodes with new code to replace old nodes gradually. It does not mean that Author and Publish share one universal mutable repository.

Runtime writes to /apps or /libs are unsupported in Cloud Service. Deploy application code through Cloud Manager, keep mutable content in supported mutable paths, and use repoinit or supported configuration for required repository initialization.

Managed Scaling and Availability

Customers do not manage individual Cloud Service virtual machines or wire fixed Publish hosts into replication agents. Adobe operates the service instances and adjusts capacity. Application code must therefore avoid:

• dependence on local filesystem persistence;
• in-memory state that must be shared across requests or nodes;
• direct addressing of a particular container;
• startup logic that assumes it is the only active instance;
• incompatible content changes during rolling deployment.

Use external systems and supported cloud APIs for durable integration state. Treat local disk as ephemeral except where the product explicitly manages it, such as Dispatcher cache behavior.

CDN and Dispatcher

The Adobe-managed CDN is in front of Dispatcher. A CDN cache miss reaches the Dispatcher layer, which applies customer configuration and may serve a cached representation or call AEM Publish.

Dispatcher still matters in Cloud Service:

• /filter limits which requests reach Publish;
• /virtualhosts and Apache virtual-host rules choose the site configuration;
• /cache rules, invalidation, and optional TTL behavior control Dispatcher storage;
• rewrites map public URLs to repository-backed resources;
• supported CDN configuration is deployed through its documented configuration mechanisms rather than assumed to be any arbitrary Dispatcher directive.

Cache-Control headers influence CDN behavior. Dispatcher time-based expiration additionally depends on its /enableTTL setting. Diagnose the two cache layers separately.

Binary Upload and Asset Compute

AEM as a Cloud Service can upload asset binaries directly to cloud binary storage rather than streaming the full payload through the Author JVM. Asset microservices then process eligible assets outside AEM and write renditions and extracted metadata back for AEM to use.

Typical externally processed work includes image renditions, metadata extraction, and text extraction. Capabilities vary by asset type and enabled services, so do not claim that every video conversion or every Sensei feature is performed by the same worker in every program.

The key performance benefit is isolation: expensive binary transfer and processing do not monopolize Author request threads and heap in the way a synchronous in-JVM workflow could.

Exam Comparisons

Keep the boundaries clear: CDN and Dispatcher are delivery layers, NodeStore is repository metadata persistence, Blob Store holds binaries, and content distribution connects separate Author and Publish services.