In certain cases, clients may have the requirement to use their own CDN(Bring Your Own CDN) in conjunction with Adobe Fastly CDN in AEM as a Cloud Service (AEMaaCS). This allows them to have greater flexibility in configuring the CDN according to their specific needs, as compared to Fastly which may have more restrictions. However, setting up this configuration requires careful planning and proper configuration to ensure it functions correctly.

In a Bring Your Own CDN (BYOCDN) setup with Adobe Fastly CDN in AEM as a Cloud Service (AEMaaCS), the following considerations apply:

  • All ingress traffic is routed through Adobe CDN, which means that having a static ingress IP is not possible.
  • Adobe CDN can be configured to only allow requests from specific IP addresses by using Cloud Manager’s allowlist configurations. This configuration is beneficial when the customer has their own CDN and domain, as there is no need to expose the publish-p<PROGRAM_ID>-e<ENV_ID> Fastly CDN domain to the internet. The domain only needs to be exposed to the customer’s infrastructure, allowing their CDN and developers to connect to it.
  • In the scenario of BYOCDN (Bring Your Own CDN), the domain certificates are installed on their own CDN infrastructure rather than on Fastly. As a result, during the cutover process, there is no need to modify DNS settings because the DNS will still direct traffic to the client’s CDN. The only necessary adjustment is to configure the BYOCDN origin to point to the Adobe CDN.

Setup instructions

  • Direct your CDN to use the Adobe CDN’s ingress as its origin domain. For instance, use publish-p<PROGRAM_ID>-e<ENV-ID>
  • Configure SNI to point to the Adobe CDN’s ingress.
  • Host Header: Set the Host header to the point to origin domain i.e. the Adobe publish-p* domain. For example: Host: publish-p<PROGRAM_ID>-e<ENV-ID>
  • X-Forwarded-Host: Include the domain name in the X-Forwarded-Host header to enable AEM to identify the host header. This is the actual domain of your website. For instance: X-Forwarded-Host:
  • X-AEM-Edge-Key: This header contains a unique key assigned to each request by the BYOCDN. This should be provided by Adobe.

    This edge key is essential for the Adobe CDN to validate the source of the requests and correctly pass the X-Forwarded-* headers to the AEM application. For example, X-Forwarded-For is used to determine the client IP. It is the responsibility of the the customer-managed CDN to set the X-Forwarded-* headers.

Please note that these request headers will not be directly visible in the browser. To troubleshoot and access the request headers, you can refer to the Apache logs.

For more details refer to Adobe documentation here.

Specific BYOCDN Use Cases

Disable caching at Fastly.

In certain cases, it may be necessary to disable caching at Fastly and instead rely on caching at the customer’s CDN. This approach can be beneficial when specific caching requirements or configurations are better suited to the customer’s CDN infrastructure.

To prevent caching specifically on Fastly CDN, you can utilize the "Surrogate-Control" header. This header is Fastly-specific and is stripped by Fastly as the response is rendered upstream to other CDNs. By setting the “Surrogate-Control” header with “max-age=0”, you can effectively prevent caching on Fastly.

In addition to the “Surrogate-Control” header, you can use the standard “Cache-Control” headers to set the max age directives that are honoured by browsers and customer CDNs. For managing cache at different levels, you can set:

  • Fastly (Response Header): Set "Surrogate-Control: max-age" to control caching behaviour specifically on Fastly CDN.
  • Intermediate CDN/Customer CDN: Set "Cache-Control: s-maxage". This directive will also guide Fastly if you are not using “Surrogate-Control”. The “s-” prefix indicates shared caches, such as CDNs.
  • Browser: Set "Cache-Control: max-age" to control caching behaviour on the end user’s browser.

By properly setting these headers, you can manage caching at different levels and ensure that the desired cache control directives are respected by Fastly, intermediate CDNs, and browsers. You can refer to the Fastly documentation for more details on controlling caching behaviour.

Geolocation based redirects in case of BYOCDN

There might be a requirement to redirect the user to specific country website based on user location. So there might be a need to pass the user country to Apache to handle redirects unless the redirects are directly handled on the customer CDN.

Fastly service initialises the headers "x-aem-client-country" and "x-aem-client-continent". However, when using a BYOCDN setup, these headers will reflect the location of the customer CDN proxy server instead of the actual client’s location. In the case of BYOCDN, it is the responsibility of the customer CDN to manage geolocation information rather than relying on the Fastly headers. Customer CDN would need to take the responsibility of passing the Geolocation country headers to the Fastly CDN.


Problem: The specific vhost for the domain, let’s say mysite.vhost, is not resolving correctly, and instead, the default/fallback vhost is being selected.

Cause: The misconfiguration lies in the customer’s CDN, which fails to send the necessary headers to the Fastly CDN. In our case, the issue occurred because the X-Forwarded-Host header was mistakenly set in the response header instead of the request header on the customer’s CDN.

The incorrect configuration can be identified from the logs.

In the below provided logs, it is evident that the vhost being selected is publish-p<PROGRAM_ID>-e<ENV-ID>, whereas the expected domain vhost should be mysite.vhost.

Ideally, if the configuration is correct, we should expect to see in the logs(shown below) that the appropriate Vhost, “”, is being selected instead of publish-p<PROGRAM_ID>-e<ENV-ID>

[Wed Mar 02 11:41:00.034834 2022] [dispatcher:debug] [pid 330:tid 139845054466872] [client] Changing Host header to:

If the CDN configuration is correct, you should observe the domain vhost being selected when executing the following curl commands:

To verify if the CDN configuration is correct and the domain vhost is being selected, you can perform the following tests using curl:

curl https://publish-p<PROGRAM_ID>-e<ENV-ID> -H 'X-Forwarded-Host:' -H 'X-AEM-Edge-Key: <PROVIDED_EDGE_KEY>'

Executing the provided command will provide you with the vhost that is currently being selected.

curl -s -I https://publish-p<PROGRAM_ID>-e<ENV-ID> -H 'X-Forwarded-Host:' -H 'X-AEM-Edge-Key: <PROVIDED_EDGE_KEY>' | grep "x-vhost"