← All Posts
AEM Adobe Architecture

AEM Edge Delivery Services: Architecture Decisions You'll Make in Week One

· 6 min read

Adobe's Edge Delivery Services reframes how AEM content reaches your CDN. Here are the architecture decisions that will define your project before your first sprint is over — and the traps that catch teams by surprise.

Edge Delivery Services (EDS) represents a genuine architectural shift in how Adobe Experience Manager delivers content — not just a new feature. Content lives in Google Drive or SharePoint, authoring happens in familiar tools, and delivery goes through a globally distributed edge network without a traditional publish tier. For teams that have lived in the AEM Sites / Dispatcher world for years, the mental model shift is real.

Here are the decisions you’ll be making in your first week, and how I’d approach each one.

Document-Based Authoring vs. Universal Editor

The first fork in the road: where does content live?

Document-based authoring puts content in Google Drive or SharePoint. Authors use Google Docs or Word. No AEM UI at all. Franklin’s “blocks” pattern means structured content is expressed through tables in a Word document. It’s fast, familiar, and means zero AEM authoring training.

Universal Editor brings a visual, in-context editing experience similar to traditional AEM Sites page editing, but delivers through the EDS pipeline. Content may live in AEM’s content repository or in an external source, depending on your integration pattern.

In most enterprise contexts, the pressure is toward Universal Editor because:

  • Content teams have existing governance workflows tied to AEM
  • Legal and compliance teams require approval workflows that live inside AEM
  • Personalisation integrations (Adobe Target, Real-Time CDP) are better supported with structured content in the AEM repo

Document-based authoring wins when the content team is small, agile, and technically comfortable. I’ve seen it work beautifully for marketing microsites and campaign landing pages. I’ve seen it become a governance nightmare for regulated content at scale.

The Block Library Is Your Component Library

In the EDS world, “blocks” are your components. Each block is a folder in your project with two files: block-name.js and block-name.css. The block receives a section of the DOM that EDS has parsed from your document structure, and it decorates/enhances it.

This is fundamentally different from AEM Core Components. There is no Sling model. There is no HTL template. There is no dialog definition in a CRX node structure. It’s just JavaScript and CSS running at the edge.

The implications for your component governance process are significant:

  • Your component library lives in a GitHub repo, not in CRX/DE
  • Versioning is Git versioning — tags, branches, releases
  • Component review is a pull request, not a package deployment
  • A/B testing a component variant means branching the block folder

Teams that treat EDS blocks like AEM components (designing elaborate config dialogs, complex inheritance hierarchies) fight the framework. Teams that embrace the simplicity ship faster.

CDN Strategy: Franklin CDN vs. Bring Your Own

EDS ships with a Fastly-backed CDN that is genuinely fast and zero-config. For many projects, you’d be done here. But enterprise customers frequently have requirements that push them toward layering their own CDN in front:

  • Akamai SureRoute / Ion for specific routing and performance contracts
  • WAF rules that must sit at the edge per InfoSec policy
  • Custom cache-busting tied to release pipelines
  • Regional routing requirements for data residency

If you bring your own CDN, you’re responsible for:

  1. Configuring origin pull from Franklin’s origin correctly (respect Surrogate-Key headers for cache invalidation)
  2. Forwarding X-Forwarded-Host so EDS knows which project config to serve
  3. Not caching error responses — EDS returns transient errors during content publish propagation; caching a 503 for 24 hours will ruin your day

This is an area I’m actively exploring as I look at rolling out EDS to give our business partners more delivery options. The cache invalidation choreography between AEM publish events and Akamai cache purges is one of the more complex integration points — plan two weeks for this, not two days.

Getting Started with EDS

The fastest path to a working EDS project is Adobe’s boilerplate repo. Fork it, connect it to a SharePoint or Google Drive folder via the Sidekick, and you have a functioning site in under an hour. That quick win is intentional — Adobe wants you to feel the speed before you feel the complexity.

From there, the practical first steps:

  1. Install the AEM Sidekick browser extension. Authors need it to preview and publish. It’s the primary production control surface for document-based authoring.

  2. Map out your block inventory early. Before writing any code, list the content patterns your site needs — hero, cards, accordion, navigation, etc. EDS blocks are small and self-contained, but a bloated block library is still a bloated block library. Scope it like a component audit.

  3. Set up your local dev environment with aem-cli. The aem up command proxies your local block code against live content from your SharePoint/Drive folder. You develop locally against real content without a build step — this is one of EDS’s best developer experience advantages.

  4. Treat your GitHub repo as your deployment pipeline. There’s no Cloud Manager, no package deployment. Merging to main is a deploy. Set up branch protection and at minimum a pull request review requirement before your first content team member gets authoring access.

  5. Do one content operations dry run before go-live. Have an author create a page, get it reviewed, publish it, and unpublish it — end to end. The gaps in your workflow design will surface immediately, and it’s much cheaper to find them in a test run than in production.