Configuration Examples for Adobe Managed CDN on AEM as a Cloud Service

When AEM as a Cloud Service was first released (and up until this past Adobe Summit, actually) the only way to configure the behavior of the CDN was to use your Apache configurations to update cache-control logic and use that to define cache behavior. But that didn’t help with more advanced needs that one would typically then configure on one’s own in a bring-your-own CDN layout in Fastly or Akamai or Cloudflare.
But as of this point there is a new set of Managed CDN functionality that you can leverage on your AEM Cloud Service program, which has massive implications for how to simplify a hybrid AEM Cloud Service and AEM Edge Delivery (now known as “AEM Live”) setup.

This video gives you the overview, and below I’ll go into some configuration examples.

What You Will Need

These examples assume that you are running AEM as a Cloud Service on a paid subscription. Unfortunately, these examples don’t work with a Sandbox (MUCH TO MY CHAGRIN) as the AEMaaCS Sandbox instances all share a number of configurations including the CDN configuration. So, custom hostnames, custom SSL certificates, and custom CDN configurations you will not be able to test out without a paid & licensed AEM as a Cloud Service installation.

Next, in order to do the redirection features noted below, you’ll need to join the early-adopter program and get this feature enabled on your AEM program as described here.

Setting Up Your Configuration Pipeline

First thing to do is to set up your configuration in your AEM project.

Make a configuration directory in the root of your project called /config and place a file in that directory named cdn.yaml. (other configs can be picked up by that pipeline as well, soon-to-include the ever-elusive LogForwarding pipeline.) See this documentation for more.

You can set up your pipeline to only work with Dev, or set up separate Config pipelines for DEV, STG and PROD. The only way to test your configurations will be to run them through these pipelines, so you definitely want this separated out from your Full-Stack pipeline.

Luckily the Config pipelines only take 1-2 minutes to run each time, so iteration is mostly painless.

An Example Set of Problems to Solve

As an example of the problems there are to be solved by this type of configuration, let’s say you have a setup with some elements like the diagram below:

I.e., you have:

• AEM as a Cloud Service
• Some elements that need to be served from your AEMaaCS Dispatcher/Publisher stack
• A few different AEM Edge Delivery (AEM.live/Helix/Franklin) sites
• Some legacy not-yet-migrated AEM 6.5 content that is in self-hosted gear
• Some other non-AEM resources like Commerce gear, a Wordpress site or two, or other resources that aren’t in your AEM stack at all.

With that, let’s talk about a few of the configurations you can employ.

Testing Adobe Managed CDN on RDE Environments

One of the very coolest thing about the way that Adobe Managed CDNs work is that you can set up your CDN config to be deployed to your AEM as a Cloud Service RDE environment (I know...that's like "ATM machine," deal with it). The reason that this is a big deal, is that now you can give developers a way to test configs semi-locally (and this means both linting the config for proper syntax, as that's never documented well-enough, as well as testing functionality) and all of that can be done before asking for a pull request to get it running on DEV.

Here are the steps to getting your CDN to deploy to RDE, with Adobe IO:

1. Get NPM, Node and NVM on your machine. You'll want to use nodejs 20
2. install aio with npm install -g @adobe/aio-cli
3. install and update your AIO plugins: aio plugins:install @adobe/aio-cli-plugin-cloudmanager aio plugins:install @adobe/aio-cli-plugin-aem-rde aio plugins:update
4. Authenticate with aio login which will pop a browser window - make sure you use your IMS profile for the AEMaaCS account you're working with, otherwise you may need to aio logout and re-select.
5. Set your program ID to your org's ID with aio config:set cloudmanager_programid {YOUR PROGRAM ID GOES HERE}
6. Initiate your RDE setup with aio aem:rde:setup - it will ask if you want to store locally, say yes please
7. Try aio aem:rde:status and see if it lets you use the RDE. It should respond like this:

tad@tad-proart:~/git/megacorp/my-aemaacs-pjt$ aio aem:rde:status
Running aem:rde:status on cm-p109099-e1819999 (Megacorp - megacorp-rde)
Info for cm-p109099-e1819999
Environment: Ready

This is how you know you're ready to rock & roll.

Then, deploy your RDE configs like so:

tad@tad-proart:~/git/megacorp/my-aemaacs-pjt$ aio aem:rde:install -t env-config ./config
Running aem:rde:install on cm-p109099-e1819999 (Megacorp - megacorp-rde)
Zipped file /tmp/aio-rde-RF1WAb/config.zip of 2584 total bytes
Uploading ████████████████████████████████████████ 100% | ETA: 0s | 3/3 KB
#42: deploy completed for env-config config.zip on author,publish - done by 66E11EA86517050C0A495EAB@c23e2a2e64229a46495fae.e at 2025-10-24T21:15:59.387Z
Logs:
> State: complete

You'll want to then make sure that you've set up SSL certificates and domains for your RDE so that you can test CDN configs out there. But this frees up your developers to actually have a sensible development and PR process!

How to Redirect to Different Backends Based on Path

Let’s say you have a mapping like this:

• Anything in /content/dam should be served from your AEMaaCS Assets instance
• Anything in /blog/ should go out to your wordpress site
• Anything from / will be served from Edge Delivery

Here’s how you would configure that in the Managed CDN mapping. First off, the configs assume that the DEFAULT direction of all traffic will be to your AEMaaCS Dispatcher/Publish stack. There’s no way to explicitly say “such-and-such traffic goes to AEMaaCS”, you only say what DOESN’T go to AEMaaCS.
So, for this example:

originSelectors:
    rules:
      - name: support
        when: { reqProperty: path, like: /blog* } 
        action:
          type: selectOrigin
          originName: KRUSTY-WORDPRESS-BLOG
      - name: edge-delivery-site1
        when: 
          allOf: 
            - reqProperty: path
              like: /* 
            - reqProperty: path
              doesNotMatch: /content/dam* 
            - reqProperty: path
              doesNotMatch: /content/test-site*
            - reqProperty: path
              doesNotMatch: /systemready*
            - reqProperty: domain
              doesNotMatch: author* 
        action:
          type: selectOrigin
          originName: edge-delivery-site1
    origins:
      - name: KRUSTY-WORDPRESS-SITE
        domain: whyamiusingthisplatform.com
        forwardHost: false
      - name: edge-delivery-site1
        domain: main--projectname--siteowner.aem.live
        forwardHost: false

Note on the above: there are properties that we’ve added to ensure that /systemready and /content/test-site* are passed through to AEMaaCS. In this case, even if you’re only using your AEM instance as a DAM, the OOTB functional tests will need to pass through AEM, and will fail your pipelines unless they can reach AEM.

How to do Country-Based Geo-Redirection

To do country-based geo-redirection, you can use the clientCountry property that comes for free in the CDN to base your redirection on.
Your config here could look like this:

data:
  experimental_redirects:
    rules:
## HOMEPAGE REDIRECTS BY GEO
      - name: homepage-redirect-us
        when:
          allOf:
            - reqProperty: clientCountry
              - in: 
                - US
                - CA
                - UK
                - IR 
            - { reqProperty: path, equals: "/" }
        action:
          type: redirect
          location: https://mycoolsite/en/home

How to Do Client Redirect Logic

Let’s say you have some base redirection you want to do for your Edge Delivery site before requests get to it. For example, let’s say your legacy site used a locale-based directory structure (like en_uk, en_sg, en_us, etc), and you’ve moved to a flatter language-based model (i.e. just /en/home). Also, let’s say you used .html on the end of all your pages before, but on Edge Delivery you don’t.
The following redirect logic would take any page requests coming in from /en_us/home.html and redirect them to /en/home.

## LOCALE REDIRECTS BY GEO + STRIP *.HTML
      - name: redirect-en
        when: { reqProperty: path, like: "/en_*" }
        action:
          type: redirect
          status: 302
          location:
            reqProperty: path
            transform:
              - op: replace
                match: '^/en_(..)(.*).html*$'
                replacement: '/en\2' 

How to Redirect & Preserve Query String

In the Adobe Managed CDN there are different properties for url and path.

      - name: china-redirect-dotgeo
        when:
          allOf:
            - {reqProperty: path, like: "*.geo.html*" }
            - { reqProperty: clientCountry, equals: "CN" }
        action:
          type: redirect
          status: 302
          location:
            reqProperty: url
            transform:
              - op: replace
                match: '^\/(en_us)(.*)\.geo\.html(.*)$'
                replacement: '/zh-cn\2\3'

Hopefully this helps!

About the Author

Like what you heard? Have questions about what’s right for you? We’d love to talk! Contact Us

Podcast Episodes & Blog Posts