Sunday, 9 November 2025

Building a Rapid Development Environment (RDE) in Adobe Experience Manager (AEM)

In today’s fast-paced digital world, speed and agility are essential. Developers need an environment where they can quickly experiment, test, and deploy without lengthy setup times. This is where a Rapid Development Environment (RDE) in Adobe Experience Manager (AEM) becomes invaluable.

What Is an RDE in AEM?

A Rapid Development Environment (RDE) is a cloud-based instance of AEM designed for rapid feature development, testing, and validation. It is a key part of AEM as a Cloud Service (AEMaaCS) and provides a lightweight, developer-friendly setup that closely mirrors your production environment.

Unlike local SDK setups, an RDE can be provisioned instantly in the cloud, allowing developers to push code, content, and configurations in minutes.

Key Benefits of Using an RDE

Instant Provisioning: RDEs are created within minutes, removing long setup times.
Cloud Alignment: They replicate your AEM Cloud Service setup, ensuring consistent behavior between development, staging, and production environments.
Team Collaboration: Multiple developers can use the same RDE instance to test shared features.
Real Content Testing: RDEs allow you to test features with realistic content and user flows before merging to main branches.
Faster Debugging: Logs, Sling consoles, and error reports are available instantly through AEM Cloud Manager, making debugging faster.

How an RDE Fits into the AEM Cloud Workflow

Here’s a simplified overview of how RDEs fit into your AEM Cloud Service workflow:

Develop locally using the AEM SDK.
Push changes to Git on a feature branch.
Deploy the code to the RDE using Cloud Manager CLI or APIs.
Test and validate features directly in the cloud.
Once approved, merge the feature branch into the main branch to trigger a full deployment pipeline.

This process reduces iteration time dramatically, taking development cycles from hours or days to just minutes.

Setting Up an RDE

Follow these steps to create and use a Rapid Development Environment in AEM:

Access AEM Cloud Manager: Go to your AEM Cloud Manager project.
Provision the RDE: Under “Environments,” click Add Environment and select Rapid Development Environment.
Install and Configure the AEM Cloud Manager CLI:

npm install -g @adobe/aio-cli
aio plugins:install @adobe/aio-cli-plugin-cloudmanager

Deploy Code or Content: Deploy packages using the CLI command below:

aio cloudmanager:rde:deploy <PROGRAM_ID> <ENVIRONMENT_ID> --file <ZIP_FILE>

You can deploy complete code packages, OSGi bundles, or content packages directly to the RDE.

Test and Debug: Use the AEM Developer Console and logs to verify deployments, troubleshoot issues, and monitor application behavior.

Best Practices for Using RDEs

Keep your RDE clean: Reset or redeploy regularly to maintain stability.
Automate deployments: Integrate RDE deployments into your CI/CD pipeline.
Use separate RDEs for each team: Assign dedicated environments for isolated testing.
Leverage Cloud Manager APIs: Automate repetitive tasks such as deployments and resets.

Real-World Example

Consider a marketing team preparing a new campaign component. A developer builds the component locally and deploys it to the RDE in minutes. Content authors then log in, test the new component with real content, and provide instant feedback. After validation, the developer merges the feature branch, and the change is deployed to staging and production — all in the same day.

This process allows for faster iteration, early feedback, and reduced production risk.

Conclusion

The Rapid Development Environment (RDE) in Adobe Experience Manager Cloud Service transforms how teams develop and test digital experiences. By providing instant provisioning, cloud consistency, and seamless collaboration, RDEs empower organizations to innovate faster and more efficiently.

If your team still relies solely on traditional development and staging pipelines, it’s time to adopt RDEs — the next step toward agile, cloud-native AEM development.

Friday, 7 November 2025

Log Forwarding in AEM as a Cloud Service – Splunk vs S3

Adobe Experience Manager (AEM) as a Cloud Service allows you to forward system and application logs to external destinations. This feature is called Log Forwarding, and it helps teams monitor, analyze, and store logs outside AEM.

Why Log Forwarding?

Log forwarding lets you centralize logs from AEM environments like dev, stage, and prod into your preferred logging platform. You can use tools like Splunk for live analytics or Amazon S3 for long-term storage and compliance.

1. Forwarding Logs to Splunk

To send AEM logs to Splunk, configure your log-forwarding.yaml file with Splunk details such as the host, port, and access token.


kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["stage", "prod"]
data:
  splunk:
    default:
      enabled: true
      host: "collector.xyz.com"
      port: 6580
      token: ${{YOUR_SPLUNK_TOKEN}}
      index: "aemaacs"
    aem:
      advancedNetworking: true

How it works:

Logs from AEM Author and Publish instances are forwarded to your Splunk collector.
The token provides authentication to the Splunk endpoint.
advancedNetworking allows secure data transfer within Adobe’s managed network setup.

When to use: Choose Splunk if you want real-time log monitoring, dashboards, and alerting.

2. Forwarding Logs to Amazon S3

If you need to store logs for auditing or long-term retention, you can forward them to an S3 bucket. Here’s an example configuration:


kind: "LogForwarding"
version: "1"
metadata:
    envTypes: ["dev", "stage", "prod"]
data:
    awsS3:
        default:
            enabled: true
            region: "us-east-1"
            bucket: "YOUR_BIT_BUCKET"
            accessKey: "${{YOUR_AWS_S3_LOG_FORWARD_ACCESS_KEY}}"
            secretAccessKey: "${{YOUR_AWS_S3_LOG_FORWARD_ACCESS_SECRET_KEY}}"
        aem:
            advancedNetworking: true

How it works:

Logs are written to your specified S3 bucket in the given AWS region.
Access keys authenticate the upload process securely.
Useful for cost-effective, long-term log retention and analysis using AWS tools like Athena or CloudWatch.

When to use: Choose S3 if you want to store logs for future analysis or compliance without needing real-time dashboards.

Splunk vs S3 – Quick Comparison

Feature	Splunk	Amazon S3
Use Case	Real-time log analysis and alerting	Long-term storage and auditing
Integration	Requires Splunk collector endpoint	Requires AWS S3 bucket and credentials
Access	Search and dashboard in Splunk UI	Access logs from S3 console or via AWS tools
Best For	Monitoring, operations, DevOps teams	Compliance, audit, and archival needs

Best Practices

Always store access tokens and keys as environment secrets in Cloud Manager.
Limit log forwarding only to necessary environments to manage cost and data flow.
Use advancedNetworking for secure connections when available.
Test log forwarding in the dev environment before enabling in production.

With AEM’s log forwarding flexibility, you can integrate your cloud logs easily into enterprise monitoring systems or cloud storage platforms depending on your operational needs.

How to Enable or Disable Caching in AEM as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service uses caching to speed up content delivery and reduce load on the publish servers. Caching works across multiple layers- the CDN, Dispatcher, and browser - to store and serve content quickly. However, you may need to enable or disable caching depending on your project requirements.

Understanding Caching

Caching stores copies of responses so users can access content faster. When caching is enabled, repeated requests are served directly from the cache instead of the AEM origin. Disabling caching ensures fresh content is always fetched directly from AEM.

How to Enable Caching

To enable caching, you can configure HTTP response headers that tell the CDN and browser how long to keep content in cache. You can apply this through the dispatcher configuration or programmatically in your code.

Dispatcher Configuration Example:


Header unset Cache-Control
Header unset Surrogate-Control
Header unset Expires

Header set Cache-Control "max-age=600, stale-while-revalidate=600, stale-if-error=600"
Header set Surrogate-Control "max-age=600, stale-while-revalidate=600, stale-if-error=600"

In this setup, the content remains fresh for 10 minutes (max-age=600) and continues to serve cached data briefly during revalidation or errors for improved performance.

Programmatic Approach: You can also set the same headers from a Sling Servlet or Filter to apply caching rules to specific responses.

How to Disable Caching

In some cases, such as dynamic, personalized, or secure content, you may not want caching. To disable caching, adjust your response headers to mark the response as private or non-cacheable.

Dispatcher Configuration Example:


Header unset Cache-Control
Header unset Surrogate-Control
Header unset Expires

Header always set Cache-Control "private"
Header always set Surrogate-Control "private"

This configuration ensures that content is not stored in the CDN or shared caches. You can also apply the same logic in a custom servlet or filter by adding the header Cache-Control: private.

When to Enable or Disable Caching

Scenario	Recommended Action
Public or static content (images, HTML pages)	Enable caching with a defined time-to-live (TTL) for better performance.
Personalized or dynamic data	Disable caching or set responses to `private` to prevent serving outdated or user-specific data.
Development or testing environments	Disable caching to see real-time changes immediately.
Mixed content types	Use selective caching rules in dispatcher or via code to manage caching per path or content type.

Best Practices

Always set explicit caching headers to avoid default or unintended behavior.
Test your caching configuration in staging before applying to production.
Use stale-while-revalidate and stale-if-error for better user experience under load.
Regularly review which pages should bypass caching (e.g., forms, user dashboards).

By managing caching properly, AEM as a Cloud Service can balance high performance with real-time content accuracy — ensuring users always get the right experience.

Understanding CDN Cache Purge in AEM as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service uses a global Content Delivery Network (CDN) to cache content closer to users for faster performance. Sometimes, when you update or delete content, you may need to remove the outdated version from the CDN cache. This process is called purging the cache.

Why Purge the Cache?

Purge requests help ensure users always see the latest version of your content. Without purging, the CDN might continue serving stale or old data from its cache instead of fetching new content from AEM Publish.

Types of Purge

Single URL Purge: Removes a specific resource from cache.
Surrogate Key Purge: Purges multiple related resources grouped under the same key.
Full Purge: Clears all cached resources from the CDN.

Fast vs Soft Purge

Fast (Hard) Purge: Instantly removes cached content from all CDN nodes. Users will immediately fetch fresh content from AEM. This is best for critical updates but may cause a temporary spike in origin load.

Soft Purge: Marks cached content as stale but keeps serving it until new content is fetched from AEM. This approach reduces load on the origin and ensures a smoother user experience.

How to Issue a Purge Request

You can trigger a purge using an HTTP request with the PURGE method. Authentication is done using a purge key defined in your CDN configuration.


curl -X PURGE "https://publish-<your-environment>.adobeaemcloud.com/path/to/resource.html" \
  -H "X-AEM-Purge-Key: <your_purge_key>" \
  -H "X-AEM-Purge: hard"

The above command removes a single cached resource immediately (hard purge).

Surrogate Key Purge Example

If your responses include surrogate keys like:

Surrogate-Key: product-page product-images

You can purge all related resources together:


curl -X PURGE "https://publish-<env>.adobeaemcloud.com" \
  -H "X-AEM-Purge-Key: <your_purge_key>" \
  -H "Surrogate-Key: product-page" \
  -H "X-AEM-Purge: soft"

Important Notes

Use purge operations carefully, especially full purges, as they can cause a sudden increase in requests to AEM Publish.
Store purge keys securely and rotate them periodically.
Test purge behavior in development or stage environments before applying to production.
Always ensure that updated content is available on AEM Publish before triggering a purge.

Best Practices

Use surrogate keys to control purging in groups instead of URLs for efficiency.
Prefer soft purges for non-critical updates to minimize system load.
Schedule purges during off-peak hours if possible.
Monitor CDN and origin response times after purging.

By using the CDN purge features wisely, you can maintain high performance while ensuring users always access the latest content.

Credential-Based Authentication in AEM as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service supports credential-based authentication for CDN integrations. This ensures secure communication between your CDN and Adobe’s managed edge network, as well as controlled access and cache management.

Why Credentials Are Needed

When you use a customer-managed CDN or require restricted access, credentials are used to:

Authenticate trusted CDNs using edge keys
Authorize cache purge requests
Enable basic authentication for restricted areas

Key Configuration Elements

Feature	Description
Edge Key	Authenticates customer-managed CDN traffic to Adobe’s edge network using secrets like `${{CDN_EDGEKEY}}`.
Purge Token	Allows authorized cache purge requests with credentials like `${{CDN_PURGEKEY}}`.
Basic Auth	Enables username-password access control for preview or restricted areas.

Sample Configuration

kind: "CDN"
version: "1"
metadata:
  envTypes: ["publish"]
data:
  authentication:
    authenticators:
      - name: edge-auth
        type: edge
        edgeKey1: ${{CDN_EDGEKEY_NEW}}
    rules:
      - name: edge-auth-rule
        when:
          reqProperty: tier
          equals: "publish"
        action:
          type: authenticate
          authenticator: edge-auth

Best Practices

Store credentials as environment secrets, not in plain text.
Rotate keys safely by using dual key entries (e.g., edgeKey1 and edgeKey2).
Use basic auth only for light access control, not for full user login systems.
Ensure CDN requests include headers like X-AEM-Edge-Key and X-Forwarded-Host.

Generate and manage your own purge keys

AEM as a Cloud Service allows you to generate and manage your own purge keys through the self-service configuration process. These keys authenticate cache purge requests at the CDN layer, ensuring that only authorized users or systems can clear cached content.

How It Works

Define secret keys in AEM as cloud : [Secret Type env. variables with complex format]
```
For e.g. CDN_PURGEKEY_CURRENT, CDN_PURGEKEY_PREVIOUS
```
In your AEM project, create or update a cdn.yaml file under your /config folder. Define a purge authenticator that references your purge key stored as an environment secret:


kind: "CDN"
version: "1"
metadata:
  envTypes: ["publish"]
data:
  authentication:
    authenticators:
      - name: purge-auth
        type: purge
        purgeKey1: ${{CDN_PURGEKEY_CURRENT}}
        purgeKey2: ${{CDN_PURGEKEY_PREVIOUS}}

Deploy the configuration through Cloud Manager.
Use the generated key in your purge API calls to invalidate cached content.

Best Practices

Rotate purge keys periodically for security.
Keep at least two keys (purgeKey1 and purgeKey2) active during rotation.
Store all keys as environment secrets in Cloud Manager, never in plain text.

This self-service model provides flexibility and security, allowing organizations to control when and how cache purges occur across environments.

Summary

Credential-based authentication secures how your CDN interacts with AEM’s edge delivery system. With proper configuration of edge keys, purge tokens, and basic auth, you can ensure safe, authenticated, and controlled content delivery in AEM as a Cloud Service.

Tags: AEM Cloud, Adobe Experience Manager, CDN Authentication, Edge Key, Purge Token, Basic Auth, AEM Security, Content Delivery

Edge Side Include (ESI) vs Sling Dynamic Include (SDI) in AEM as a Cloud Service

When delivering high-performance websites with Adobe Experience Manager (AEM), caching plays a vital role. However, not all content can be cached the same way — some sections (like user info or personalized banners) need to be rendered dynamically while most of the page remains cached.

To address this, AEM supports two major approaches:

Edge Side Include (ESI)
Sling Dynamic Include (SDI)

This article explains how each works, their differences, and when to use them.

What is Sling Dynamic Include (SDI)?

Sling Dynamic Include (SDI) is an AEM-specific feature that lets you replace specific parts of a cached page with dynamically rendered fragments. It works within the AEM Dispatcher or Apache Sling layer.

SDI replaces a component’s output with a server-side include () so that only those parts are fetched dynamically on every request, while the rest of the page is cached.

Example


<!-- Original AEM component -->
<div data-sly-resource="/content/site/en/userinfo"></div>

<!-- After SDI processing -->
<!--#include virtual="/content/site/en/userinfo.html" -->

In this setup, even when the page is cached at the dispatcher, the user info component is re-fetched dynamically.

Key Use Cases

Personalized welcome messages
Shopping cart status or counts
Dynamic banners or time-sensitive content

Advantages

Works fully within the AEM–Dispatcher setup
Easy to configure using OSGi settings
No dependency on CDN

Limitations

Runs at the origin (dispatcher), not at the edge
Can add server-side overhead for multiple dynamic fragments
Less efficient for globally distributed traffic

What is Edge Side Include (ESI)?

Edge Side Include (ESI) is a CDN-level technology that allows partial page assembly at the network edge. It is supported by CDNs such as Fastly, Akamai, and CloudFront.

With ESI, cached pages can contain <esi:include> tags. These fragments are fetched and rendered dynamically at the CDN before sending the response to the user. This reduces load on AEM and speeds up delivery.

Example


<html>
  <body>
    <esi:include src="/fragments/userinfo.html"/>
  </body>
</html>

Key Use Cases

Global personalization via CDN edge
Dynamic fragments in high-traffic websites
Reducing origin load while keeping partial freshness

Advantages

Personalization at the CDN edge (faster delivery)
Reduces requests to AEM Publish
Scales globally for high traffic

Limitations

Requires CDN that supports ESI (e.g., Fastly, Akamai)
More complex debugging at edge level
Limited testing in local environments

Comparison: ESI vs SDI

Feature / Aspect	Sling Dynamic Include (SDI)	Edge Side Include (ESI)
Processing Location	AEM Dispatcher / Origin	CDN Edge (Fastly, Akamai)
Purpose	Dynamic inclusion at origin	Fragment assembly at CDN edge
Performance Impact	Moderate, depends on dispatcher load	High performance, offloads AEM
Caching Level	Dispatcher or AEM Cache	CDN-level Cache
Best For	Small-scale personalization	Global personalization & edge caching
Dependencies	AEM + SDI bundle	CDN (Fastly, Akamai)
Setup Complexity	Low	Medium to High
Personalization Depth	User/session-based at origin	Anonymous user personalization at edge
Example Tag	<!--#include virtual="..." -->	<esi:include src="..." />

How They Fit in AEM Cloud

In AEM as a Cloud Service, both SDI and ESI are supported. However, Adobe recommends using ESI for cloud deployments because:

It integrates natively with the Fastly CDN used by AEM Cloud.
Personalization and fragment assembly happen at the edge, improving time-to-first-byte (TTFB).
It reduces load on AEM’s origin servers, improving scalability.

Still, SDI remains useful in lower environments, development, or internal networks where a CDN may not be available.

Best Practices

Use ESI for edge personalization and global traffic.
Use SDI for simple dispatcher-level dynamic includes.
Avoid nested includes (either ESI or SDI).
Always check cache headers for fragment freshness.
Monitor performance using AEM Cloud metrics.

Conclusion

Both Edge Side Include (ESI) and Sling Dynamic Include (SDI) allow partial page caching in AEM without sacrificing personalization. The choice depends on scale and infrastructure:

Use SDI for small-scale or internal personalization.
Use ESI for large-scale, global personalization and high-performance delivery.

Together, they help AEM developers balance caching efficiency with personalized content delivery.

Tags: AEM Cloud, Adobe Experience Manager, Edge Side Include, Sling Dynamic Include, Fastly CDN, AEM Performance, Caching, Personalization

Pipeline-Free URL Redirects in AEM as a Cloud Service

In Adobe Experience Manager (AEM) as a Cloud Service, managing redirects efficiently is essential for maintaining SEO ranking, user experience, and link consistency when pages are moved, renamed, or deleted. The new pipeline-free URL redirects feature allows teams to manage redirects easily without needing a full pipeline deployment.

This feature is especially useful when marketing or content teams handle redirects directly without relying on developer or DevOps pipelines.

When to Use Pipeline-Free Redirects

Pipeline-free redirects are ideal in the following scenarios:

When business or marketing users need to add or modify redirects quickly.
If your team manages thousands of redirects and doesn’t want to trigger a Cloud Manager pipeline each time.
When using UI-based tools such as ACS Commons Redirect Manager or Redirect Map Manager.
When redirect management is part of daily operations rather than code deployments.

How It Works

Pipeline-free redirects are stored in a publish repository and mapped dynamically by the AEM Dispatcher configuration. Here’s how it functions step-by-step:

Redirect mappings are stored in one or more rewrite map files inside the /content/dam repository.
A configuration file, such as managed-rewrite-maps.yaml, defines which rewrite maps to load from the repository.
The AEM Dispatcher (Apache) loads and caches these maps for use in URL rewriting.


maps:
  - name: my.map
    path: /content/dam/redirectmaps/mysite-redirectmap.txt

The above YAML tells AEM where to find your redirect map file stored in the DAM.

Apache Rewrite Rule Example


RewriteMap map.foo dbm=sdbm:/tmp/rewrites/my.map
RewriteCond ${map.foo:$1} !=""
RewriteRule ^(.*)$ ${map.foo:$1|/} [L,R=301]

When a request matches an entry in the rewrite map, Apache issues a 301 Redirect to the mapped destination.

Configuration Options

Adobe provides several useful configuration options to control reload frequency and startup behavior:

TTL (time-to-live): Defines how often Apache reloads the rewrite map. Default is 300 seconds.
wait: If set to true, Apache waits until the map is fully loaded before serving requests (avoiding temporary inconsistencies).
Entry limit: Each redirect map entry supports up to 1024 characters.

Example:


maps:
  - name: my.map
    path: /content/dam/redirectmaps/mysite-redirectmap.txt
    ttl: 600
    wait: true

Things to Remember

Use this method only for redirects, not for complex rewrite logic.
Ensure redirect maps are updated and published to the correct environments (e.g., stage, production).
Keep the number of maps manageable — each map file can contain thousands of entries efficiently.
Monitor redirect performance via logs or Cloud Manager metrics.

Summary

The pipeline-free URL redirect feature in AEM Cloud gives organizations flexibility and speed. Redirects can now be managed dynamically from the AEM repository without triggering a deployment pipeline. This empowers content teams to maintain SEO and user navigation effectively while keeping developers focused on core code changes.

Tags: AEM Cloud, Adobe Experience Manager, URL Redirects, Pipeline-Free Redirects, AEM Dispatcher, Cloud Manager, ACS Commons

Standard Traffic Rules vs WAF Traffic Rules in AEM as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service offers an enterprise-grade, secure, and scalable environment for delivering digital experiences. One of the key aspects of maintaining that security and performance is the ability to define and manage

Two major rule sets manage this behavior: Standard Traffic Rules and Web Application Firewall (WAF) Traffic Rules. While they might sound similar, they serve distinct purposes within Adobe’s Cloud Manager and the underlying Adobe I/O Runtime and Fastly CDN architecture.

WAF traffic filter rules require an additional WAF-DDoS Protection or Enhanced Security license. Standard traffic filter rules are available to Sites and Forms customers by default.

Understanding Traffic Rules in AEM Cloud

Traffic rules in AEM as a Cloud Service act as a control layer that filters, redirects, or restricts HTTP traffic before it reaches your author or publish environments. These rules are applied at the CDN and dispatcher levels, ensuring optimized performance and security across environments — dev, stage, and prod.

What Are Standard Traffic Rules?

Standard Traffic Rules are configuration-level rules that control the behavior of traffic — not necessarily to block it, but to redirect, rewrite, or allow it conditionally.

Typical Use Cases

Redirecting traffic from HTTP → HTTPS.
Defining vanity URLs or SEO-friendly redirects.
Restricting access to author instances from public networks.
Allowing traffic only from specific IP ranges for certain paths.
Applying geo-based routing or maintenance page redirection.

How They Work

These rules are defined and managed via AEM Cloud Manager under the Environment Configuration section. They leverage Adobe’s edge configuration capabilities, meaning requests are filtered before they hit the AEM dispatcher layer, minimizing load and latency.


rules:
  - name: redirectToHTTPS
    when:
      condition: request.scheme == "http"
    action:
      type: redirect
      url: "https://${request.host}${request.path}"
      status: 301

Key Goal: Optimize routing and performance, control access, and ensure consistent user experience.

What Are WAF (Web Application Firewall) Traffic Rules?

WAF Traffic Rules focus purely on security. They protect AEM environments against malicious attacks, bots, and exploits such as:

SQL Injection
Cross-Site Scripting (XSS)
DDoS attacks
Path traversal or request forgery

Adobe’s WAF is powered by Fastly’s edge security services, providing real-time inspection and blocking of malicious requests before they enter the AEM infrastructure.

Typical Use Cases

Blocking suspicious user agents or crawlers.
Enforcing rate limiting to prevent DDoS.
Preventing uploads with disallowed file types.
Mitigating known CVEs or OWASP Top 10 vulnerabilities.

How They Work

WAF rules analyze request headers, body content, IP, and payload patterns. You can define custom rule exceptions in Cloud Manager or rely on Adobe-managed default protection policies.


rules:
  - name: blockSQLInjection
    when:
      condition: request.query contains "select%20from" or "union%20all"
    action:
      type: block

Key Goal: Protect AEM from external threats and vulnerabilities while maintaining availability and compliance.

Standard vs WAF Traffic Rules — Comparison Table

Feature / Aspect	Standard Traffic Rules	WAF Traffic Rules
License	Available by default	Requires add-on license
Primary Purpose	Control routing, access, and optimization	Block malicious or suspicious traffic
Focus Area	Functional behavior	Security enforcement
Managed By	Developers / Cloud Admins	Adobe Security / Admins
Examples	Redirects, IP allow-list, maintenance mode	SQL injection, XSS, DDoS, bot filtering
Configuration Scope	Project-level or environment-level	Global or environment-level
Where Applied	Edge/CDN before AEM dispatcher	WAF Layer (Fastly Edge Security)
Performance Impact	Improves routing and response time	Protects at slight inspection overhead
Customization	High (YAML configuration)	Moderate (Custom rule exceptions)

Deployment & Sync Across Environments

To ensure consistent behavior across Dev → Stage → Prod:

Define and version-control traffic rules in your AEM Cloud Manager Git repository.
Deploy via Cloud Manager pipeline to validate and apply rules.
Adobe-managed WAF rules are synced automatically; custom overrides can differ by environment.
Test in Stage before promoting to Production.

Best Practices

Keep Standard Traffic Rules minimal — focus on routing and logic only.
Let WAF handle malicious traffic; avoid duplication.
Use environment variables for IP or domain conditions.
Review WAF logs periodically via Adobe Support or Cloud Manager.
Maintain version history and documentation for audit compliance.

Visual Flow Diagram (Text Representation)

[Client Request]
      │
      ▼
 ┌───────────────┐
 │   Fastly CDN  │
 └───────────────┘
      │
      ▼
 ┌────────────────────────────┐
 │ WAF Traffic Rules Layer     │  ← Security Filtering (malicious requests blocked)
 └────────────────────────────┘
      │
      ▼
 ┌────────────────────────────┐
 │ Standard Traffic Rules Layer│  ← Redirects, Access Control, Geo Rules
 └────────────────────────────┘
      │
      ▼
 ┌───────────────┐
 │ AEM Dispatcher │
 └───────────────┘
      │
      ▼
 ┌───────────────┐
 │  AEM Publish  │
 └───────────────┘

Conclusion

Both Standard Traffic Rules and WAF Traffic Rules play vital roles in securing and managing traffic in AEM as a Cloud Service.

Use Standard Traffic Rules for operational control and routing efficiency.
Rely on WAF Traffic Rules for proactive defense against web threats.

Together, they form a multi-layered security and traffic governance framework that ensures high availability, compliance, and seamless digital experiences.

Tags: AEM Cloud, Adobe Experience Manager, WAF, Traffic Rules, Cloud Security, Fastly CDN, AEM DevOps

Wednesday, 5 November 2025

Set Up Adobe IMS Groups for Content Author Permissions and Sync with AEM Dev, Stage, and Prod

Managing user permissions efficiently is critical in large-scale Adobe Experience Manager (AEM) environments, especially when integrated with Adobe’s

This guide walks you through the end-to-end setup — from creating an IMS group in Adobe Admin Console to syncing and mapping it in AEM Cloud environments.

Step 1: Understand How IMS and AEM Permissions Work Together

Before diving into setup, let’s clarify the relationship:

Adobe IMS (Identity Management System): Centralized user/group management for Adobe solutions, including AEM as a Cloud Service.
AEM Cloud Service: Uses IMS authentication — meaning users log in with their Adobe ID and their roles/permissions are derived from IMS groups.

When an IMS group is synced with AEM:

A corresponding group is auto-created in AEM (prefixed by ims:).
You can then map that IMS group to AEM groups or permissions.

This ensures that when a new user is added to the IMS group, they automatically get the same permissions in AEM across all environments.

Step 2: Create an IMS Group for Content Authors

Log in to the Adobe Admin Console.
Navigate to your AEM Product Configuration:
- Go to Products → AEM as a Cloud Service.
Select the specific Environment or Program (e.g., “Marketing Sites” or “Corporate Portal”).
Under Product Profiles, click New Profile or select an existing one.
Create a new IMS group for content authors, for example:
aem-authors-marketing
Assign relevant permissions and entitlements:
- Access to AEM environments (Dev, Stage, Prod).
- Permissions for Assets, Sites, or Forms as needed.

Notes: Follow a naming convention like aem-[role]-[project] (e.g., aem-author-corporate, aem-admin-commerce) to maintain clarity across multiple AEM programs.

Step 3: Assign Users to the IMS Group

Once your IMS group exists:

Go to Users in the Adobe Admin Console.
Add users or bulk import them.
Assign them to the IMS group you just created.

These users will inherit permissions as soon as they log into AEM environments tied to that IMS group.

Step 4: Sync IMS Groups with AEM Environments

Adobe automatically syncs IMS groups with all linked AEM environments — Dev, Stage, and Prod — under the same Cloud Manager program.

Verify the Sync:

Log in to your AEM Author instance (e.g., Dev).
Go to: Tools → Security → Groups
Search for the group with prefix ims: (e.g., ims:aem-authors-marketing).
You’ll see the group auto-created by the IMS sync process.

Flow Diagram: IMS Group to AEM Sync

Diagram: How Adobe IMS groups map and sync across AEM Dev, Stage, and Prod environments.

Step 5: Map IMS Groups to AEM Local Groups or Roles

IMS groups define who can log in; AEM groups define what they can do.

Go to AEM Author → Tools → Security → Groups.
Open your IMS group (e.g., ims:aem-authors-marketing).
Add this group as a member of local AEM groups such as:
- content-authors
- asset-contributors
- workflow-users
Save changes.

Step 6: Ensure Consistency Across Environments

AEM Cloud Service automatically syncs IMS groups across environments. However, ensure that local AEM group mappings are consistent.

Use Cloud Manager pipelines or configuration sync tools to promote security configurations.
Optionally automate mappings with Repository Initialization (Repo Init) scripts:

Sample Repository Initialization (Repo Init) script

create group aem-authors
add "ims:aem-authors-marketing" to group aem-authors

Step 7: Test the Setup

Log in as a test user from the IMS group.
Verify access to AEM Author UI.
Confirm:
- Can they open and edit pages/assets?
- Are permissions consistent across environments?
- Does removal from IMS revoke access?

Summary

Step	Action	Outcome
1	Create IMS group	Centralized author group in Admin Console
2	Assign users	Access managed via Adobe ID
3	Sync with AEM	Auto-created in all environments
4	Map to AEM groups	Permissions applied correctly
5	Validate & Test	Consistent access across Dev, Stage, Prod

Final Thoughts

Using Adobe IMS groups to manage AEM permissions is a best practice that enhances security, scalability, and ease of management. By configuring groups once in IMS and mapping them in AEM, you can ensure consistent authoring permissions across Dev, Stage, and Production — saving time and preventing access drift.

SEO Metadata

SEO Title: How to Set Up Adobe IMS Groups for AEM Permissions Across Environments

Meta Description: Learn step-by-step how to create Adobe IMS groups, assign permissions, and sync them across AEM Dev, Stage, and Prod environments for secure and consistent author access.

Tags: AEM, Adobe IMS, Adobe Admin Console, AEM Cloud Service, AEM Permissions, AEM Security, AEM Author Roles, DevOps, Cloud Manager

Migrating Workflows from AEM On-Premise to AEM as a Cloud Service (or New Workflow Structure)

When working with Adobe Experience Manager (AEM), many teams encounter challenges while migrating existing workflows from an on-premise setup to the new cloud-based or modern AEM structure. One of the most common issues stems from the changes in workflow storage and runtime model generation.

This article outlines the key steps required to successfully migrate AEM workflows from the traditional /etc location to the newer /conf/global/settings/workflows structure.

Note:

Legacy workflow designs (both design-time and runtime) are held under the following path:

/etc/workflow/models/

Custom workflow designs are held under:

/conf/global/settings/workflow/models/...

Runtime workflow designs (both out-of-the-box and custom) are held under the following path:

/var/workflow/models/

Out-of-the-box workflow launchers are held under the following path:

/libs/settings/workflow/launcher/

Custom workflow launchers are held under:

/conf/global/settings/workflow/launcher/...

Legacy workflow launchers are held under the following path:

/etc/workflow/launcher/

Legacy workflow scripts are held under the following path:

/etc/workflow/scripts/

Custom workflow scripts are held under:

/apps/workflow/scripts/...

1. Verify Existing Workflows in the Legacy Location

Before starting the migration, confirm that all your current workflows exist in the legacy path:

/etc/workflow/models

This ensures you know exactly which models need to be transitioned and helps avoid missing dependencies during migration.

2. Update Workflow Locations

For each workflow model you plan to migrate, update its location reference from the old /etc structure to the new /conf path. The recommended destination is:

/conf/global/settings/workflows/models

You can perform this migration one workflow at a time to minimize potential errors. Be sure to update any internal or hardcoded URLs or references that point to the old /etc path.

3. Synchronize Workflow Models

Once the workflow has been moved to its new location, open it in the AEM Workflow Console and click on the Sync button.

This step is crucial : it generates the corresponding runtime models required for execution in the new environment.

4. Integrate Runtime Models into Your Source Code

After synchronization, locate the newly created runtime models. These are typically stored under the following paths:

/conf/global/settings/workflows/models

/var/workflow/models

Download or export these models and integrate them into your project’s source code repository. This ensures that your workflows are version-controlled and properly deployed across environments.

Now your filter looks as below,

Your filter could look like this (assuming you have your workflow model design and runtime version under appropriate paths)

<filter root="/conf/global/settings/workflow/models/your-workflow-model"/>

<filter root="/var/workflow/models/your-workflow-model"/>

Conclusion

Migrating workflows from /etc to /conf may seem complex at first, but by following these structured steps, you can ensure a smooth transition. The key is to migrate one workflow at a time, validate synchronization, and keep your runtime models aligned with your codebase.

This process not only modernizes your workflow architecture but also ensures full compatibility with AEM’s latest standards and best practices.