Rules of AEM

aemrules.com Security Headers & Cookie Management in Hybrid AEM CDN Setup on AWS CloudFront 7 min read  ·  Anuj Gangwar  ·  AEM Architect @ Adobe TL;DR Ask AI 5 things to know in 30 seconds 1 Never manage security headers on both EDS and AMS independently — enforce all of them at CloudFront only using a Response Headers Policy. One place, consistent everywhere. 2 Your CSP policy must be a superset covering both EDS and AMS — scripts, fonts, and connect sources from both origins in one unified policy. 3 Strip ALL cookies before forwarding to EDS origin. EDS is stateless — forwarding AMS session cookies destroys cache efficiency and every user gets a unique cache entry. 4 For AMS authenticated paths, whitelist only the cookies you need — typically login-token. Never forward all cookies blindly. 5 For SSO across EDS and AMS pages, use a lightweight JWT shared cookie reada...

  Cache Invalidation in Hybrid AEM: Keeping EDS and AMS in Sync on AWS CloudFront Introduction In a hybrid AEM setup where EDS and AMS serve different parts of the same website through AWS CloudFront, cache invalidation is one of the trickiest problems to solve. Both systems have completely different invalidation mechanisms — and if you don't coordinate them properly, editors end up seeing stale content, confused about why their published changes aren't showing up. This post explains how cache invalidation works in each system, why hybrid setups make it harder, and how to build a reliable invalidation strategy across both origins. The Core Problem In a single-origin AEM setup, invalidation is straightforward: Editor publishes in AEM Dispatcher flush agent clears the Dispatcher cache CloudFront invalidation clears the CDN layer Done In a hybrid setup you have two completely separate invalidation pipelines that must never interfere with each other: EDS publish event ...

aemrules.com Hybrid AEM CDN Architecture: Routing EDS + AMS on AWS CloudFront 8 min read  ·  Anuj Gangwar  ·  AEM Architect @ Adobe TL;DR Ask AI 5 things to know in 30 seconds 1 AWS CloudFront acts as a single traffic cop — routing every request to either EDS or AMS based on the URL path pattern. 2 EDS paths like /blog/* go to hlx.live origin. AMS paths like /products/* go to the Dispatcher origin. Default catch-all points to AMS. 3 Consolidate all EDS static assets under /eds/* — fonts, scripts, styles, blocks, icons all under one folder. One CloudFront rule instead of six. 4 A CloudFront Edge Function handles .html to clean URL 301 redirects at the edge — before any origin is contacted. 5 Always pass X-Forwarded-Host to both origins. AMS needs it for vhost matching. EDS Franklin Bot needs it for site resolution. Ask a question in the Ask AI tab for more details on a...

  AEM Edge Delivery Services + AI: The Future of Content Delivery Introduction AEM Edge Delivery Services (EDS) — formerly known as Project Franklin / Helix — is Adobe's modern, high-performance content delivery layer. It decouples content authoring from delivery, serving pages at the edge with near-perfect Lighthouse scores. When you combine EDS with AI, you unlock capabilities like real-time content personalization, AI-generated blocks, and intelligent A/B testing — all at the edge. In this post, we'll walk through how to integrate AI into an EDS project with practical code examples. How Edge Delivery Services Works (Quick Recap) Author (Google Docs / SharePoint / AEM) ↓ AEM Pipeline (Franklin Bot) ↓ Content stored at Edge (Fastly CDN) ↓ User Request → Edge Worker → HTML served in <100ms EDS pages are built with plain HTML/CSS/JS blocks. There's no traditional AEM dispatcher — content is served directly from the CDN edge.       ...