ÃÛ¶¹ÊÓÆµ

CDN in AEM as a Cloud Service cdn

AEM as a Cloud Service comes with an integrated CDN, designed to reduce latency by delivering cacheable content from edge nodes close to the user’s browser. This fully managed CDN is optimized for AEM application performance.

The AEM-managed CDN meets most customers’ performance and security needs. For the publish tier, customers can choose to route traffic through their own CDN, which they must manage. This option is available on a case-by-case basis, particularly when customers have existing legacy integrations with a CDN provider that are hard to replace.

Customers looking to publish to the Edge Delivery Services tier can take advantage of ÃÛ¶¹ÊÓÆµâ€™s managed CDN. See ÃÛ¶¹ÊÓÆµ Managed CDN.

ÃÛ¶¹ÊÓÆµ Managed CDN aem-managed-cdn

To prepare for content delivery using AEM’s built-in CDN through Cloud Manager’s self-service UI, you can take advantage of ÃÛ¶¹ÊÓÆµâ€™s managed CDN features. This functionality lets you handle self-service CDN management, including configuring and installing SSL certificates such as DV (Domain Validation) or EV/OV (Extended/Organization Validation) certificates. For more details on these methods, see the following:

Restricting traffic

By default, for an AEM-managed CDN setup, all public traffic can make its way to the publish service, for both production and non-production (development and stage) environments. You can limit traffic to the publish service for a given environment (for example, limiting staging by a range of IP addresses) by way of the Cloud Manager user interface.

See Managing IP Allow Lists to learn more.

CAUTION
AEM’s managed CDN serves requests only from allowed IPs. If you point your own CDN to the AEM-managed CDN, then make sure the IPs of your CDN are included in the IP Allow List.

Configure traffic at the CDN cdn-configuring-cloud

You can configure traffic at the CDN in various ways, including:

Use YAML files in Git to configure these features. And, use the Cloud Manager Config Pipeline to deploy them.

Configure CDN error pages cdn-error-pages

You can configure a CDN error page to replace the default, unbranded page. This custom page is displayed in the rare event that AEM is unavailable. For more details, see Configuring CDN error pages.

Purge cached content at the CDN purge-cdn

Setting TTL using the HTTP Cache-Control header is an effective approach to balance content delivery performance and content freshness. However, in scenarios where it is critical to serve updated content immediately, it may be beneficial to purge the CDN cache directly.

Read about configuring a purge API token and purging cached CDN content.

Basic authentication at the CDN basic-auth

For light authentication use cases including business stakeholders reviewing content, protect content by displaying a basic auth dialog requiring a username and password. Learn more.

Customer managed CDN points to AEM managed CDN point-to-point-CDN

If a customer must use its existing CDN (or any kind of reverse proxy, for example a loadbalancer or a WAF), they can manage it and point it to the AEM-managed CDN, providing the following are satisfied:

  • The customer must have an existing CDN that would be onerous to replace.
  • The customer must manage it.
  • The customer must be able to configure the CDN to work with AEM as a Cloud Service - see the configuration instructions presented below.
  • The customer must have engineering CDN experts that are on call in case-related issues arise.
  • The customer must perform and successfully pass a load test before going to production.

Configuration instructions:

  1. Point your CDN to the ÃÛ¶¹ÊÓÆµ CDN’s ingress as its origin domain. For example, publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com.

  2. Set SNI to the ÃÛ¶¹ÊÓÆµ CDN’s ingress.

  3. Set the Host header to the origin domain. For example: Host:publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com.

  4. Set the X-Forwarded-Host header with the domain name so AEM can determine the host header. For example: X-Forwarded-Host:example.com.

  5. Set X-AEM-Edge-Key. The value should be configured using a Cloud Manager config pipeline, as described in this article.

    • Needed so that the ÃÛ¶¹ÊÓÆµ CDN can validate the source of the requests and pass the X-Forwarded-* headers to the AEM application. For example,X-Forwarded-For is used to determine the client IP. So, it becomes the responsibility of the trusted caller (that is, the customer managed CDN) to ensure the correctness of the X-Forwarded-* headers (see the note below).
    • Optionally, access to ÃÛ¶¹ÊÓÆµ CDN’s ingress can be blocked when an X-AEM-Edge-Key is not present. Inform ÃÛ¶¹ÊÓÆµ if you need direct access to ÃÛ¶¹ÊÓÆµ CDN’s ingress (to be blocked).

See the Sample CDN vendor configurations section for configuration examples from leading CDN vendors.

Before accepting live traffic, you should validate with ÃÛ¶¹ÊÓÆµâ€™s customer support that the end-to-end traffic routing is functioning correctly.

After setting the X-AEM-Edge-Key, you can test that the request is routed correctly as follows.

In Linux®:

curl https://publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com -H "X-Forwarded-Host: example.com" -H "X-AEM-Edge-Key: <PROVIDED_EDGE_KEY>"

In Windows:

curl https://publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com --header "X-Forwarded-Host: example.com" --header "X-AEM-Edge-Key: <PROVIDED_EDGE_KEY>"
NOTE
When using your own CDN, you do not need to install domains and certificates in Cloud Manager. The routing in the ÃÛ¶¹ÊÓÆµ CDN is done by using the default domain publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com, which should be sent in the request Host header. Overwriting the request Host header with a custom domain name may route the request incorrectly through the ÃÛ¶¹ÊÓÆµ CDN or result in 421 errors.
NOTE
Customers that manage their own CDN should ensure the integrity of the headers that are sent through to AEM’s CDN. For instance, it is recommended that customers clear all X-Forwarded-* headers and set them to known and controlled values. For example, X-Forwarded-For should contain the client’s IP address, while X-Forwarded-Host should contain the site’s host.
NOTE
Sandbox program environments do not support a customer provided CDN.

The extra hop between the customer CDN and the AEM CDN is only needed if there is a cache miss. By using the cache optimization strategies described in this article, the addition of a customer CDN should only introduce negligible latency.

This customer CDN configuration is supported for the publish tier, but not in front of the author tier.

Debugging configuration

To debug a BYOCDN configuration, use the x-aem-debug header with a value of edge=true. For example:

In Linux®:

curl https://publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com -v -H "X-Forwarded-Host: example.com" -H "X-AEM-Edge-Key: <PROVIDED_EDGE_KEY>" -H "x-aem-debug: edge=true"

In Windows:

curl https://publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com -v --header "X-Forwarded-Host: example.com" --header "X-AEM-Edge-Key: <PROVIDED_EDGE_KEY>" --header "x-aem-debug: edge=true"

This process reflects certain properties used in the request in the x-aem-debug response header. For example:

x-aem-debug: byocdn=true,edge=true,edge-auth=edge-auth,edge-key=edgeKey1,X-AEM-Edge-Key=set,host=publish-p87058-e257304-cmstg.adobeaemcloud.com,x-forwarded-host=wknd.site,adobe_unlocked_byocdn=true

This process allows verification of details such as the host values, edge authentication configuration, and the x-forwarded-host header value. It also identifies whether an edge key is set and which key is used if a match exists.

Sample CDN Vendor Configurations sample-configurations

Presented below are several configuration examples from several leading CDN vendors.

Akamai

Akamai1 Akamai2

Amazon CloudFront

CloudFront1