Decorative double Helix

Configuration Examples for 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.

https://youtu.be/VpUThxk8O3U?si=Ea-oXZaS4n-Ldyqh

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:

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

How to Redirect to Different Backends Based on Path

Let’s say you have a mapping like this:

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'

Hopefully this helps!

About the Author

Tad Reeves

Principal Architect at Arbory Digital

Tad has been working with Adobe products since 2010 and has extensive experience in website infrastructure. Starting in 1996, he has worn nearly every hat in website delivery from solution architecture to product management, and has over two decades of experience. He loves that Arbory gives him the opportunity to provide honest and effective solutions, even if it means challenging prevailing sales perspectives. When Tad isn’t working, he enjoys mountain biking and exploring nature with his wife & 3 kids.

Contact Tad on Linkedin

Monolithic vs Composable vs Microservice CMS's - What's the right tool for the job?
Are monoliths all bad? What’s the difference between a monolith, composable and microservice based CMS?
Making AEM & Edge Delivery Go CRAZY FAST - Interview with StreamX Co-Founder
How do you solve the constant problem of cache freshness and backend system latency in any modern CMS (especially AEM or Edge Delivery?) In this episode we talk to Michał Cukierman, CTO of Dynamic Solutions and co-founder of StreamX - a digital experience mesh for dramatically and reliably accelerating complicated dynamic content requests from the many constituent systems that make up a modern CMS deployment.
Adobe Summit 2024: AEM Architecture Disruption
It’s not hyperbole that if you haven’t put considerable effort into rethinking your full site delivery stack in the last few months, you are going to want to. So please - stop reading this right now, pop in some headphones and take this podcast for a walk and consider how it might affect your environment!