Welcome to Tech Mastery, your expert source for insights into technology and digital strategy. Explore topics like Adobe Experience Manager, AWS, Azure, generative AI, and advanced marketing strategies. Delve into MACH architecture, Jamstack, modern software practices, DevOps, and SEO. Our blog is ideal for tech professionals and enthusiasts eager to stay ahead in digital innovations, from Content Management to Digital Asset Management and beyond.
In this post, we’ll explore some of the recent enhancements to the out-of-the-box CDN capabilities in AEM as a Cloud.
AEM as a Cloud’s CDN(Fastly) has recently enabled several key features that help us quickly address various issues. Some of these features are not yet in general availability but are accessible through the Early Adopter Program.
Image from Adobe Document
The above image outlines the process flow for request and response handling in AEM as a Cloud CDN. Let’s examine some key features that are either currently enabled or available at the early adopter stage. These CDN configurations can be set through the cdn.yaml file and deployed separately via the Cloud Manager config pipeline.
For example below config folders in your code repository and configure the required features into the cdn.yaml file.
The Origin Selector feature enables the CDN to route traffic to non-AEM backends according to the configuration, functioning similarly to a reverse proxy.
You can define rules to determine when requests should be directed to a specific origin. You can specify the backend domain or Ip address to connect, this allows for the configuration of various options such as useCache(default is true), forwardHost(default is false), forwardCookie(default is false), forwardAuthorization(default is false), and timeout (default is 60) settings.
Request Transformations:
Request transformation rules enable you to modify incoming requests by setting, unsetting, and altering paths, query parameters, and headers (including cookies) based on a variety of matching conditions, such as regular expressions. The supported actions — set, unset, and transform — can be chained together. Additionally, these rules allow you to set variables and reference these variables later in the pipeline, such as in Response Transformers.
Response Transformations:
Response transformation rules allow you to set and unset headers of the CDN’s outgoing responses. The supported actions — set (Sets a specified header to a given value in the response) and unset (Removes a specified header from the response)
Client-side Redirects(Early Adopter Program):
This feature is not yet generally available. To join the early-adopter program, email [email protected].
the client-side redirect rules for 301, 302 and similar client-side redirects. If a rule matches, the CDN responds with a status line that includes the status code and message (for example, HTTP/1.1 301 Moved Permanently), as well as the location header set. Both absolute and relative locations with fixed values are allowed.
CDN Error Pages:
When the CDN is unable to reach the AEM origin, a generic, unbranded error page is displayed. However, this default error page can be overridden by hosting static files in self-hosted storage solutions such as Amazon S3, Azure Blob Storage, or any external servers. These can then be referenced through CDN configuration.
Edge Side Includes (ESI) for Loading Dynamic Content (Early Adopter Program):
This feature is not yet generally available. To join the early-adopter program, email [email protected].
The Adobe Managed CDN now supports Edge Side Includes (ESI), enabling dynamic content replacement directly at the CDN level. Sling Dynamic Include facilitates various include types such as SSI (Server Side Include), ESI (Edge Side Include), and JavaScript includes. To leverage ESI, specific CDN configurations are necessary, allowing dynamic content placeholders to be replaced at the CDN level, which permits full-page caching. While SSI allow content to be fully cached at the dispatcher (not at the CDN), as the dispatcher retains the full page with dynamic include placeholders and substitutes them with actual content upon request. ESI, on the other hand, enables the complete content along with dynamic placeholders to be stored at the CDN, with placeholders replaced with real content as needed. For a more detailed understanding, refer to the article ‘Sling Dynamic Include — Deep Dive | Dynamically Include Page Components in AEM | by Albin Issac | Tech Learnings | Medium.
Traffic filter rules at the CDN layer can be employed to either block or allow requests, providing crucial control in various scenarios. These include:
Restricting access to specific domains exclusively to internal company traffic before a new site goes live.
Establishing rate limits to reduce susceptibility to volumetric DoS attacks.
Blocking access from IP addresses known to be associated with malicious activities.
Rate Limit Rules — to block traffic if it exceeds a certain rate of incoming requests, based on a specific condition. Setting a value for the rateLimit property limits the rate of those requests that match the rule condition.
Additionally, you can implement WAF (Web Application Firewall) traffic filter rules, which utilize WAF flags. These rules require either an Enhanced Security license or a WAF-DDoS Protection license.
Please note, that there is a size limit to the configuration file (the cumulative size of the configuration file cannot exceed 100KB) so organizations with larger requirements should define rules in the apache/dispatcher layer.
In this post, we will explore some of my key learnings from migrating to AEM as a Cloud Service. In a previous post, ‘Key Considerations for Migrating to AEM as a Cloud Service,’ we discussed the essential factors to consider when moving to this platform
Content and asset migration to AEM as a Cloud is a complex task, especially depending on the size and nature of your existing repository. While the Content Transfer tool from Cloud Acceleration Manager can assist, the first hurdle is ensuring adequate infrastructure, such as sufficient disk space, CPU, and disk I/O, to handle the migration process.
If you are migrating from AMS, one strategy is to set up a new dedicated AMS environment specifically for migration. This approach prevents disruption to ongoing work on the current platform but does incur additional costs. Alternatively, repurposing one of the existing environments might be more cost-effective, though it may still require upgrades — Disk Space, Environment Size, and disk I/O capabilities, to meet migration demands.
The recommended steps are to clone your current production environment to this dedicated migration environment, ensure the environment is upgraded to meet your capacity needs mainly disk space and DISK IO (Higher DISK I/O is critical to extract and ingest high volume content seamlessly) then use it to extract and ingest content/assets to the AEM Cloud environments. This ensures a smoother transition and helps manage the load effectively during the migration.
Configuring Environment-Specific ETC MAPs in AEM Cloud:
Custom run modes are not supported in AEM as a Cloud; only ‘dev’, ‘stage’, and ‘prod’ run modes are available. This makes enabling environment-specific variables challenging, especially when multiple development environments are used for different purposes. However, this issue can be addressed by using Cloud Manager to support custom run modes. For more details, see my article: Support Custom Run Modes in AEM as a Cloud.
Another challenge is enabling environment-specific ETC MAPs for resource resolving, particularly when defining site-specific test domains in different environments. Although AEM does not support run mode-specific ETC MAPs directly, this can be managed by configuring the Resource Resolver Factory to point to environment-specific ETC MAP folders. In the cloud, where all development environments are typically set to ‘dev’ run mode, this can be managed using Cloud Manager environment variables. For more information, refer to my article: How to Configure Environment-Specific ETC MAPs for AEM as a Cloud Service?.
Migration of existing users and groups:
User migration is a critical component in AEM as a Cloud, where user management is facilitated through IMS. First, create the necessary groups in IMS and associate the existing users to the corresponding groups. For efficiency, you may consider using a bulk CSV upload to map current users to the appropriate IMS groups. User permissions can be managed through local AEM groups by linking them with IMS groups. If needed, local group ACLs can be defined through repo init scripts. For more information on this process, refer to ‘AEM as a Cloud: IMS based SSO Authentication for Authors’ by Albin Issac on Tech Learnings.
If CUG (Closed User Group) based users and groups are enabled in your current AEM publishers, use the ACL Packager to migrate the users to the cloud publisher. Upload the package to the Author environment and then replicate it. Make sure that the CUG users are not installed into the Author environment to avoid any permission overlaps, especially if some users are common between Authors and CUG. Live user synchronization between publish pods is not enabled by default. Create a support ticket to enable user sync across publisher pods.
Environment-specific SAML configurations within AEM for supporting Author login through the customer’s IAM system are no longer necessary. This configuration has now been centralized and is managed globally through IMS.
DAM Asset Update Workflow:
The default DAM Asset Update workflow in previous versions of Experience Manager is no longer available. Instead, asset microservices provide a scalable, readily available service that covers most of the default asset processing (renditions, metadata extraction, and text extraction for indexing). Refer to the configuration and use of asset microservices for more details. To include customized workflow steps in the processing, post-processing workflows can be used.
Synthetic URL Monitoring:
Synthetic URL monitoring is a crucial tool in web performance monitoring, used to assess the availability, functionality, and responsiveness of web applications, services, and APIs. If you currently utilize custom monitoring tools such as New Relic or Datadog, these can be effectively used to monitor URLs and APIs. However, it’s important to note that while New Relic is integrated into AEM as a Cloud, it does not support specific URL monitoring for AMS platforms.
In AEM as a Cloud, URL monitoring is only available through the Advanced Cloud Support package, which incurs additional costs. If you opt out of Advanced Cloud Support and do not have an existing custom monitoring setup, your only alternative is to find a custom solution that meets your URL monitoring needs.
Supporting Parallel Development and Content Authoring:
Supporting the ongoing development of projects on the platform and content authoring is critical. Ensure you plan this in advance while selecting System Integrators and during the planning phase. Supporting parallel development and content authoring can alter your project’s timeline and required effort, so it’s crucial to develop a strategy for parallel development and content authoring. This includes merging ongoing development code to the cloud, ensuring cloud compatibility, conducting tests, and migrating delta content.
Static Templates and ETC Designs:
Although static templates and ETC/Designs are supported in the cloud, they are not recommended. You should migrate ETC/Designs folders from the current platform to the cloud. However, a challenge arises as there are no miscadmin pages available to manage and publish ETC/Designs. While designs can be modified through design mode, there is no direct method to activate these changes. To activate design changes, you could use one of the following approaches: package the changes and install them on the publisher, or utilize a tree activation workflow.
Splunk Log forwarding:
The AEM logs, including CDN logs, can be forwarded to a customer-owned Splunk instance. To enable this forwarding, please create a support ticket with the necessary details: the Splunk HEC endpoint address, Splunk port, and Splunk HEC token. Three different indexes — dev, stage, and prod — are created; logs from all dev-type instances are sent to the dev index.
SSL and DNS Configurations:
The SSL and DNS configurations can be managed through Cloud Manager as a Self-Service. To support site-specific test domains across various environments, create a test domain strategy. It’s advisable to use a common domain pattern to simplify management, such as site1-dev.test.com, site1-uat.test.com, and site1-stage.test.com.
Enable a separate wildcard SSL, for example, *.test.com, to support various test domains across different environments (site1-dev.test.com, site1-uat.test.com, site1-stage.test.com). Additionally, consider enabling individual or SAN SSL to support live domains in production.
Domains can be directed to either the Preview or Publish environments. The Preview environment allows you to preview changes before they are published. After publishing changes to the Preview server and conducting tests, you can then move the changes to the Publish environment. By default, the Preview service is blocked for all traffic, but you can manage IP allowlisting through Cloud Manager
CDN Configurations:
The caching headers for the CDN can be enabled through dispatcher configurations. For more details, please refer to the ‘Caching in AEM as a Cloud Service’ section on the Adobe Experience Manager website. It’s important to assess the current CDN cache behavior configurations as well. When migrating from AMS and CloudFront to AEM as a Cloud, I recommend not merely transferring individual configurations from the current CDN directly. Instead, identify your specific caching needs and implement the necessary configurations. This might include common configuration files used in every virtual host to control caching behaviors.
Additionally, you can define other CDN configurations such as rate limiting, filtering rules, and WAF rules, if licensed, through the cdn.yml file in a separate config folder, refer to Traffic Filter Rules including WAF Rules | Adobe Experience Manager for more details. Deploy these configurations separately through the Config Cloud Manager Pipeline. The CDN configuration also supports enabling a Reverse Proxy (Origin Selector) for non-AEM servers, as well as request and response transformers, refer to Configuring Traffic at the CDN | Adobe Experience Manager for more details.
Purge-Key. You should request the environment-specific purge key from the Adobe team by creating a support ticket.
There are two types of purges available: soft and hard. A soft purge marks the affected object as stale rather than making it completely inaccessible, whereas a hard purge immediately makes the object inaccessible to new requests. To execute a hard purge, simply remove Fastly-Soft-Purge:1 from the request.
Adjusting and updating your current DevOps process to adapt to cloud best practices is critical. The cloud platform enables additional deployment pipelines, such as the Dispatcher pipeline for deploying Dispatcher configurations and the Config pipeline for deploying CDN configurations. If you are not currently using Cloud Manager to manage deployments, you should define an end-to-end DevOps process that includes both your code repository and the Cloud Manager repository, along with the deployment pipelines.
Testing:
Testing is critical for the success of the project. Ensure that a comprehensive test strategy is defined to cover all required tests: Functional, Content, Integration, Regression, Performance, and Security. If any integrations require IP whitelisting, you will need to enable dedicated IP configuration in AEM Cloud and whitelist the IP. For more details, refer to ‘Demystifying Dedicated Egress IPs in AEM Cloud Services’ by Albin Issac on Tech Learnings | Medium.
Another challenge involves functionalities that cannot be tested in non-production environments. You may need to enable test services to assess these functionalities. If it’s not feasible to test ahead of the go-live, consider testing these functionalities by adding host entries on your local machine to point the sites to the AEM Cloud platform.
Adobe Support:
Adobe Support is critical. If you opt for Ultimate Support, you will gain access to focused ticket support. Additionally, Launch Advisory services provide extra guidance from an Adobe Architect and their team during the project, including any necessary reviews and monitoring during the migration. If you decide against Ultimate Support, you will need to plan how to navigate support tickets in case of any blockers. Furthermore, if you currently use AMS, you may need to arrange for the required support from a Customer Success Engineer (CSE) for tasks such as cloning the environment, supporting content migration, or obtaining details from the current platform, such as CDN configurations.
Restrict release orchestration for Production:
You can raise a support ticket to prevent the production environment from automatically upgrading during your go-live window, thereby avoiding any unexpected issues. The request should be submitted at least one week in advance, specifying the period during which the release orchestration for production should be disabled (i.e., preventing the production environment from receiving updates).
If you have enabled scheduled content back-sync from production to non-production environments in AMS or your own AEM platform, be aware that this functionality is not supported in AEM as a Cloud. Instead, AEM as a Cloud allows you to create content sets and migrate content between Author instances as needed, but this is not scheduled nor does it extend to the Publisher. You should consider implementing a package-based batch content sync, such as using the Multi-Channel Publishing (MCP) tool, from Author to Publisher.
Operational Changes:
Some of the operations previously performed by CSE on the AMS platform can now be managed directly by customers. These include managing deployments, installing mutable content packages through the Package Manager, provisioning new environments, and configuring IP whitelisting, SSL, and DNS, among others. Additionally, the repositories on stage and production can be accessed through the repository browser available in the Developer Console.
ETC Map Usage: The ETC map, used in conjunction with the JCR Resource Resolver, supports resource resolution and mapping across multiple domains. Unfortunately, ETC map configurations do not consider run modes during the application, necessitating a combination with run mode-specific configurations using org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
Creating Environment-Specific Folders: Create specific /etc/map folders like /etc/map.dev.publish, /etc/map.uat.publish, /etc/map.stage.publish, and /etc/map.prod.publish
Run Mode-Specific JCR Resolver Configurations: These should be set up as follows:
Dev/Publish(config.dev.publish) run modes: org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl.cfg.json
Although Stage and Prod environments load specific ETC maps properly, the challenge arises in Dev environments. These are always enabled with a Dev run mode but can be designated for various purposes like Development or UAT. This mismatch can cause disruptions if not handled correctly.
Define an ETC_MAP_PATH variable in Cloud Manager corresponding to the environment-specific ETC MAP path (e.g., /etc/map.dev.publish, /etc/map.uat.publish) and apply this variable to the Publish environment. This approach ensures uniformity across all environments, including Stage and Prod.
Applying the Configuration: (config.publish) — org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl.cfg.json
This refined approach ensures each cloud environment loads the ETC map based on the path specified in the Cloud Manager variable ETC_MAP_PATH, allowing for precise environment-specific resource mapping.
