AEM Replication: Why Cloud Service Doesn't Have Replication Agents

The Traditional AEM Replication Model (AMS/On-Premise)

In AEM 6.5 and AEM Managed Services, replication is the mechanism for moving content from Author to Publish instances. It's based on replication agents—configurable transport mechanisms that push content packages from one instance to another.

How Traditional Replication Works

When you activate a page in AEM AMS:

1. The replication agent serializes the content into a package
2. The agent opens an HTTP connection to the publish instance
3. The package is transmitted and deserialized on publish
4. Optionally, dispatcher cache is flushed via a flush agent

Configuring Replication Agents in AMS

In AEM 6.5/AMS, you configure agents at /etc/replication/agents.author:

// Typical replication agent configuration
Name: Publish Agent
Transport URI: https://publish.example.com/bin/receive?sling:authRequestLogin=1
Transport User: replication-user
Transport Password: ********
Serialization Type: Default
Retry Delay: 60000
Log Level: Info
Agent Enabled: true

Why AEM Cloud Service Removed Replication Agents

AEM as a Cloud Service is built on a fundamentally different architecture. Adobe removed replication agents for several reasons:

• Auto-scaling: Cloud publish instances scale automatically. Manual agent configuration for each instance is impossible.
• Immutable infrastructure: You can't modify /etc or system configurations in Cloud Service.
• Reliability: Queue-based distribution is more resilient than point-to-point HTTP.
• Security: No need to manage replication user credentials across instances.
• Simplicity: Authors shouldn't care about infrastructure—just click "Publish."

How Content Distribution Works in AEM Cloud

AEM Cloud Service replaces replication agents with Sling Content Distribution, backed by Adobe's pipeline infrastructure.

The Distribution Process Step-by-Step

1. Author triggers publish: User clicks "Quick Publish" or "Manage Publication" in the AEM UI.
2. Content serialization: Sling Content Distribution serializes the content tree into distribution packages using Apache Jackrabbit Oak.
3. Queue submission: Packages are placed in a distribution queue (not an HTTP call to a specific publish instance).
4. Adobe pipeline processing: Adobe's infrastructure manages the queue, ensuring reliable delivery.
5. Publish consumption: All publish pods subscribe to the queue and pull content packages automatically.
6. CDN invalidation: Adobe's CDN layer (Fastly) is automatically invalidated when content is published.

Comparison: AMS vs Cloud Replication

Feature	AEM AMS / 6.5	AEM Cloud Service
Mechanism	Replication Agents	Sling Content Distribution
Configuration	Manual per-agent setup	Zero configuration (managed by Adobe)
Transport	HTTP POST to each publish	Queue-based distribution pipeline
Scaling	Add agent per publish instance	Automatic—all pods subscribe to queue
Credentials	Replication user/password	No credentials (Adobe-managed auth)
Queue visibility	/etc/replication/agents.author	Distribution UI in Tools menu
Custom agents	Yes (custom transport handlers)	No (use Content Distribution SDK)
Reverse replication	Supported via reverse agents	Not supported (use APIs/workflows)
Dispatcher flush	Separate flush agents	Automatic via CDN invalidation

Working with Content Distribution in Cloud

Viewing the Distribution Queue

In AEM Cloud, you can monitor distribution status at:
Tools → Deployment → Distribution

The Distribution UI shows:

• Queue status and pending items
• Distribution history
• Failed packages and retry options
• Agent status (Golden Publish reference)

Programmatic Publishing

To trigger distribution programmatically in Cloud Service, use the Sling Content Distribution API:

import org.apache.sling.distribution.DistributionRequest;
import org.apache.sling.distribution.DistributionRequestType;
import org.apache.sling.distribution.DistributionResponse;
import org.apache.sling.distribution.Distributor;
import org.apache.sling.distribution.SimpleDistributionRequest;

@Reference
private Distributor distributor;

public void publishContent(String path) {
    DistributionRequest request = new SimpleDistributionRequest(
        DistributionRequestType.ADD,  // ADD = publish, DELETE = unpublish
        path
    );
    
    DistributionResponse response = distributor.distribute(
        "publish",  // agent name
        resourceResolver,
        request
    );
    
    if (response.isSuccessful()) {
        log.info("Content distributed: {}", path);
    } else {
        log.error("Distribution failed: {}", response.getMessage());
    }
}

Handling Distribution Events

import org.apache.sling.distribution.event.DistributionEventTopics;
import org.osgi.service.event.Event;
import org.osgi.service.event.EventHandler;

@Component(
    service = EventHandler.class,
    property = {
        "event.topics=" + DistributionEventTopics.AGENT_PACKAGE_DISTRIBUTED
    }
)
public class DistributionEventListener implements EventHandler {
    
    @Override
    public void handleEvent(Event event) {
        String[] paths = (String[]) event.getProperty("distribution.paths");
        String type = (String) event.getProperty("distribution.type");
        
        log.info("Content distributed: {} - {}", type, Arrays.toString(paths));
    }
}

Common Migration Challenges

1. Custom Replication Agents

If you had custom replication agents in AMS (e.g., pushing to external systems), you'll need to refactor. Options in Cloud Service:

• Use Adobe I/O Events to trigger external workflows on publish
• Implement Sling Jobs that run on publish and push to external systems
• Use Content Distribution SDK for custom distribution handlers

2. Reverse Replication

Reverse replication (publish-to-author) isn't supported in Cloud Service. Alternatives:

• Use AEM Forms for user-generated content that needs to reach author
• Implement custom APIs on publish that write to external storage (S3, database)
• Use Adobe I/O Runtime as an intermediary

3. Dispatcher Flush Agents

No need for flush agents—AEM Cloud's CDN (Fastly) handles cache invalidation automatically when content is published. You can still configure TTLs and cache rules in dispatcher configs.

Best Practices for Cloud Content Distribution

1. Don't fight the model: Embrace queue-based distribution rather than trying to replicate agent behavior.
2. Use Manage Publication: For bulk publishing, use "Manage Publication" which batches items efficiently.
3. Monitor the queue: Check Distribution UI regularly, especially after large content updates.
4. Handle failures gracefully: Distribution can fail—build retry logic and alerting into your workflows.
5. Understand timing: Distribution isn't instant. Factor in queue processing time for time-sensitive content.

Conclusion

The move from agents to Sling Content Distribution is a big change. Developers used to AMS need to adjust. But the benefits are worth it: auto-scaling, no setup, and better reliability.

If you're moving to Cloud Service, learn this early. It helps you avoid surprises and build solutions that work with the cloud, not against it.