AEM as a Cloud Service

🔍 What Is It?

AEM as a Cloud Service is Adobe's fully managed, cloud-native version of AEM. Key characteristics:

• →Always up-to-date — Adobe pushes updates automatically, no manual upgrades
• →Auto-scaling — scales up and down based on traffic automatically
• →Containerized — runs on Kubernetes, with separate Author, Publish, and Dispatcher pods
• →CI/CD native — code is deployed through Cloud Manager pipelines, not manual package installs
• →CDN included — Fastly CDN is built in, in front of every AEMaaCS environment
• →Separated storage — content is stored in a cloud-based Oak repository, not a local disk

AEMaaCS is not just "AEM in the cloud" — it's a re-architected platform with different deployment models, different APIs, and different constraints than AEM 6.5.

🎯 Why Do We Need It?

The Problems with AEM 6.x (on-premise):

• →Manual upgrades every 1–2 years — expensive, risky, time-consuming
• →Infrastructure management — servers, OS, JVM, networking
• →Manual scaling — traffic spikes require pre-provisioning
• →Slow deployments — package installs could take 30+ minutes

AEMaaCS Solves This:

• →Zero-downtime updates — Adobe updates AEM automatically, no manual effort
• →Elastic scaling — handles Black Friday traffic automatically
• →Fast deployments — Cloud Manager pipelines deploy in minutes
• →Global CDN — built-in Fastly CDN reduces latency worldwide
• →Security — Adobe manages patches, security updates, and compliance

🏗️ What Happens in Real Projects?

How a Typical AEMaaCS Project Works:

1. Development — Developers work locally using the AEM SDK (a downloadable JAR that mimics AEMaaCS)
2. Code Review — Code goes through Git (usually GitHub/GitLab/Azure DevOps)
3. Pipeline — Cloud Manager detects the commit and runs the CI/CD pipeline
4. Testing — Automated tests run (unit tests, integration tests, UI tests)
5. Deployment — Code deploys to Dev → Stage → Production environments
6. Content — Content authors work in the cloud Author environment
7. Delivery — Users get content via CDN → Dispatcher → Publish

Environments in AEMaaCS:

• →Development — For developer testing
• →Stage — For QA and UAT
• →Production — Live site

Each environment has Author, Publish, and Dispatcher tiers.

⚙️ How It Works

Architecture Differences from AEM 6.5:

Immutable vs Mutable Content:

This is the biggest conceptual shift from AEM 6.5:

• →/apps, /libs, /oak:index — Immutable — only deployable via Cloud Manager pipeline
• →/content, /conf, /var — Mutable — manageable through AEM UI and replication

Implications:

• →You can't install packages directly to /apps in production
• →All code changes go through the pipeline
• →OSGi configurations are deployed as code, with secrets and environment-specific values supplied by Cloud Manager
• →Content changes are published through the managed AEM publication flow; cache invalidation is handled by AEM, Dispatcher, and CDN rules

Cloud Manager:

Cloud Manager is Adobe's CI/CD platform for AEMaaCS. It:

• →Connects to your Git repository
• →Runs build pipelines (Maven build + quality checks)
• →Deploys to AEMaaCS environments
• →Manages environment variables (for OSGi config)
• →Runs code quality, security, and performance checks
• →Provides access to deployment history, build logs, and environment status for production support

💻 Example

AEMaaCS Development Setup — Key differences and configurations for developing on AEM as a Cloud Service.

# .cloudmanager/config.yaml
# Defines pipeline behavior

kind: "PipelineConfig"
version: "1"
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  # Dispatcher configuration validation
  dispatcher:
    enabled: true
  # Frontend build pipeline
  frontend:
    enabled: false
  # Code quality thresholds
  codeQuality:
    coverageMinimum: 80
    duplications: 5

🤔 Common Confusions

🚨 Common Production Issues

✅ Best Practices

🏛️ Architect's Note

💬 Frequently Asked Questions

🎯 Key Takeaways

🔗 Related Topics

🎯 Practice this topic in interviews

↗ Where this topic fits