Hybrid AMS & EDS Architecture
Hybrid AMS & EDS Architecture: Routing EDS + AMS from a Single Domain on AWS CloudFront
Introduction
One of the most complex — and increasingly common — enterprise AEM patterns is running a hybrid topology. Some pages of the website are served by AEM Edge Delivery Services (EDS) while others run on AEM Managed Services (AMS) with a traditional Dispatcher stack. Both serve from the same domain (www.example.com) with no visible difference to the end user.
The glue holding this together is the CDN layer. In most enterprise setups, that means AWS CloudFront. Getting this right requires careful path-based routing, origin separation, cache strategy, and edge-level redirects — particularly the common .html to clean URL problem.
This post covers everything you need to know to architect this correctly.
Why Hybrid Topology Happens
Organisations rarely migrate an entire AEM estate overnight. The typical journey looks like this:
- Marketing pages (
/blog,/articles,/news) migrate to EDS first — they benefit most from EDS speed and simple authoring in Google Docs or SharePoint. - Complex transactional pages (
/products,/account,/checkout) stay on AMS — they rely on AEM components, workflows, personalisation, and backend integrations that are not yet EDS-compatible. - Both need to live under the same domain, same navigation, same experience.
The result is a website where the CDN must silently route each request to the right origin based on the URL path.
The Architecture in Plain English
Think of AWS CloudFront as a smart traffic cop sitting in front of two completely different backend systems.
User visits www.example.com
↓
AWS CloudFront
↓
Is this path an EDS path?
↓ YES ↓ NO
Route to EDS Route to AMS
(hlx.live) (Dispatcher)
CloudFront decides which origin to send the request to based on path patterns you configure — called Cache Behaviours. The rules are evaluated top to bottom, first match wins.
Path Routing — How to Split Traffic
You define which URL paths belong to EDS and which belong to AMS.
EDS paths (examples):
/blog/*/articles/*/en/news/*/resources/*
AMS paths (examples):
/products/*/content/*/account/*/services/*- Everything else (default)
In CloudFront, each path pattern maps to an origin and a cache policy. The default behaviour (catch-all) should point to AMS since that is typically the larger part of the estate.
Key rule: Always pass
X-Forwarded-Host: www.example.comto both origins. AMS Dispatcher needs it for virtual host matching. EDS Franklin Bot needs it to identify the correct site configuration.
The .html to Clean URL Redirect Problem
This is one of the most overlooked issues in hybrid AEM setups.
The problem:
- AMS Dispatcher has historically served pages as
/products/overview.html - EDS serves clean URLs —
/blog/my-postwith no extension - Google may have indexed
.htmlversions of your pages - Users may have bookmarked
.htmlURLs - Internal links from AMS pages may point to
.htmlversions of EDS pages
If you don't handle this at the CDN, users hit broken pages or duplicate content issues.
The solution — a CloudFront Edge Function at the viewer-request stage:
The function runs before the request reaches either origin. The logic in plain English:
When a request comes in:
IF the URL ends with .html THEN
Remove the .html extension
Return a 301 redirect to the clean URL
Preserve any query parameters in the redirect
IF the URL starts with /content/sitename/ THEN
Strip the /content/sitename/ prefix
Remove .html extension
Return a 301 redirect to the clean external URL
OTHERWISE
Let the request pass through normally
This runs at the CloudFront edge — meaning the redirect happens in milliseconds before any origin is contacted. It applies consistently to both EDS and AMS paths.
Example redirects this handles:
| Incoming URL | Redirected To |
|---|---|
/blog/my-post.html |
/blog/my-post |
/products/overview.html |
/products/overview |
/content/mysite/en/home.html |
/en/home |
/articles/2026/april.html |
/articles/2026/april |
Cache Strategy — EDS vs AMS Are Very Different
This is where most teams get caught out. EDS and AMS have fundamentally different caching philosophies and you need separate cache policies for each.
EDS Cache Policy
EDS is built for aggressive edge caching. Pages are static HTML generated from Google Docs or SharePoint content. There are no sessions, no personalisation at origin, no cookies.
- Cache for 24 hours to 7 days at CloudFront
- Strip all cookies — EDS does not use them
- Strip all request headers from cache key — EDS responses do not vary by header
- Let EDS handle its own invalidation via Franklin purge API when content changes
AMS Cache Policy
AMS pages may vary by language, authentication state, or personalisation. The Dispatcher already does its own caching so CloudFront acts as a second cache layer.
- Cache for 1 to 24 hours depending on content type
- Forward authentication cookies (
login-token) for personalised pages - Vary on Accept-Language for multi-language sites
- For account / checkout pages — disable CloudFront caching entirely and let AMS/Dispatcher handle it
Origin Request Policy — What to Forward
Beyond caching, you need to control what CloudFront forwards to each origin.
For EDS origin:
- Forward the
Hostheader aswww.example.com - Do NOT forward cookies
- Do NOT forward unnecessary headers — keep it clean
For AMS origin:
- Forward
X-Forwarded-Forso Dispatcher sees the real client IP - Forward
X-Forwarded-Hostfor vhost resolution - Forward relevant cookies for authenticated experiences
- Forward
Accept-Languageif AMS uses language-based dispatching
Common Mistakes to Avoid
1. Not setting X-Forwarded-Host Both EDS and AMS use the Host header to determine which site/vhost to serve. Without it you get 404s or wrong content from both origins.
2. Letting AMS cookies bleed into EDS paths If CloudFront forwards AMS login cookies to EDS, the cache key becomes polluted. Every authenticated user gets a unique cache entry and your hit rate drops to near zero.
3. Ordering Cache Behaviours incorrectly
CloudFront matches path patterns top to bottom. More specific patterns must come before broader ones. /blog/featured/* must appear before /blog/* or it will never be evaluated.
4. Forgetting the .html redirect on AMS paths
Teams often add the .html redirect only for EDS paths. But AMS URLs indexed by Google also need clean URL redirects when you update your URL strategy. Apply the edge function to all paths.
5. Same cache policy for both origins Never use the same CloudFront cache policy for EDS and AMS. Their TTL, cookie, and header requirements are completely different. Sharing a policy will either break AMS personalisation or destroy EDS cache efficiency.
Key Takeaways
- AWS CloudFront is the right tool for hybrid EDS + AMS routing — its path-based Cache Behaviour model maps perfectly to split-origin topologies.
- Always pass
X-Forwarded-Hostto both origins — it is required by both EDS and AMS for correct resolution. - Handle
.htmlto clean URL redirects at the CloudFront edge function (viewer-request) — this is the only layer that can intercept and redirect before touching either origin. - Use separate cache policies for EDS and AMS — they have fundamentally different caching needs.
- Default Cache Behaviour should point to AMS as the fallback origin.
Comments
Post a Comment