Edit

Customization at the edge using Azure Front Door edge actions (preview)

Azure Front Door edge actions is a transformative capability that empowers organizations to run custom JavaScript logic directly at Microsoft's global Azure Front Door PoP locations. Designed for modern web applications, Edge Actions enable ultra-low latency execution of business logic against user requests and responses.

This capability addresses the growing demand for secure, scalable, and intelligent content delivery in an era of digital transformation. As enterprises face increasing threats and performance expectations, Edge Actions offer a powerful solution to optimize request and response flows, enhance security posture, and reduce origin load, all while maintaining high availability and performance standards.

Important

  • Azure Front Door edge actions is currently in preview. See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
  • During the preview, use the Edge Actions preview portal link https://aka.ms/edgeaction/publicpreview for all Edge Action operations in the Azure portal. Continue the workflow in the portal session opened by this link. This workflow includes creating and managing Edge Action resources and versions, configuring execution filters and diagnostic settings, and attaching, managing, verifying, or detaching Edge Actions from Azure Front Door routes. If you open the Azure portal directly without first using the preview portal link, you might not see Edge Action resources and Azure Front Door integration options.

Diagram showing Azure Front Door edge actions.

Supported capabilities

During the preview, Edge Actions support only client request invocations, which support the following scenarios:

  • A/B experimentation
  • Request and response header manipulation
  • Request rejection
  • Dynamic origin selection
  • URL rewrite
  • URL redirect
  • JWT token validation

Sample JavaScript code samples for supported scenarios

You can get sample Edge Action code samples for previous use cases from the Azure/EdgeActionsSamples GitHub community repo.

Edge Actions size and resource limits

During the preview, each Edge Action resource has the following constraints:

  • Code size: 16 KB
  • Version counts: 3
  • Execution time: 10 ms
  • Maximum number of Edge Actions resources per subscription: 100

Currently, JavaScript is the only supported language.

For more information about service limits, see Azure Front Door Standard and Premium service limits.

Important considerations

  • Set one version of the code as the default version to execute against the request.
  • Don't implement any unsupported methods in your code.
  • The service supports code execution for up to 10 ms. If the execution goes beyond this limit, the service terminates the code execution and sends the request without Edge Action processing.
  • You need to attach an Edge Action to the Azure Front Door route before it can execute against the client request.
  • You can create and attach Edge Actions by using the portal UI or the Visual Studio Code extension.

High-level flow with Edge Actions

The following diagram shows a high-level flow of request and response to an Azure Front Door endpoint when you use Edge Actions.

Diagram showing a high-level flow of request/response to Azure Front Door endpoint with Edge Actions in use.

When a user initiates a request to a resource that Azure Front Door fronts, the request follows Azure Front Door routing architecture. For more information, see Routing architecture overview. When you attach an Edge Action to a route, the request follows this flow:

  1. The request lands in one of the Azure Front Door edge PoP locations.

  2. The request matches an Azure Front Door profile.

  3. If the domain is enabled with WAF rules, Azure Front Door evaluates them. If not, this step is skipped.

  4. If the request matches a rule configured in the Azure Front Door rule engine, Azure Front Door processes it.

  5. If the request matches a rule configured to invoke Edge Action, the rules engine invokes Edge Action, and the request is routed to Edge Actions.

  6. Edge Action creates a Hyperlight sandbox and loads:

    1. Custom and secure JavaScript runtime.

    2. Immutable context variable that contains all the data of the server variables, list of healthy origins in the matched route, user's request originating country code, user's device type from user-agent header of the request, and current date-time stamp.

    3. Edge Actions code that is set as default. If execution filter is configured and corresponding header is set, then configured version is executed.

  7. Edge Actions code executes and modifies the request, sends the response (if content found in cache), or sends the request to origin to be fulfilled.

Create and manage an Edge Action

Important

During the preview, use the Edge Actions preview portal link https://aka.ms/edgeaction/publicpreview for all Edge Action operations in the Azure portal. Continue the workflow in the portal session opened by this link. This workflow includes creating and managing Edge Action resources and versions, configuring execution filters and diagnostic settings, and attaching, managing, verifying, or detaching Edge Actions from Azure Front Door routes. If you open the Azure portal directly without first using the preview portal link, you might not see Edge Action resources and Azure Front Door integration options.

  1. Sign in to the Azure portal at aka.ms/edgeaction/publicpreview.

  2. In the search box at the top of the portal, enter Edge Actions. Select Edge Actions from the search results.

  3. Select + Create.

  4. In Create Edge Action, enter or select the required details.

    Screenshot that shows the Basic tab of creating an Edge Action.

  5. Select Review + create, and then select Create.

  6. After the deployment finishes, select Go to resource to go to the Edge Action resource page.

    Screenshot that shows the Overview page of an Edge Action.

Create a new version of Edge Action

To execute client requests successfully, each Edge Action must include at least one code version object with an uploaded JavaScript file. By using versions, you can safely manage and release updates for Edge Actions while keeping multiple versions available. You can upload a new version and set it as the default without experiencing downtime during the switch. If an issue arises with the latest code, you can easily roll back to the previous version. You can create up to three versions for each Edge Action.

  1. Under Settings of your Edge Action, select Versions.

  2. Select + Add.

  3. Enter the name of the version and upload the JavaScript code.

  4. Select Set default if you want this version to be the default for requests, and select OK to complete the creation.

    This operation creates a new version and uploads the JavaScript code. The portal displays the status for both operations separately. (During the preview period, the Upload code operation can take up to 10 minutes.)

  5. When the new version is created, the portal shows the provisioning state as succeeded.

    Screenshot that shows the versions list.

  6. Select Download code if you want to verify the content of the JavaScript code. It downloads a ZIP folder named EdgeActionCode, which contains your .js file.

Attach Edge Action to Azure Front Door route

Important

During the preview, use the Edge Actions preview portal link https://aka.ms/edgeaction/publicpreview for all Edge Action operations in the Azure portal. Continue the workflow in the portal session opened by this link. This workflow includes creating and managing Edge Action resources and versions, configuring execution filters and diagnostic settings, and attaching, managing, verifying, or detaching Edge Actions from Azure Front Door routes. If you open the Azure portal directly without first using the preview portal link, you might not see Edge Action resources and Azure Front Door integration options.

This part of the configuration is the most important. Currently, you can invoke Edge Actions only through Azure Front Door route configurations. You can attach an Edge Action to an Azure Front Door route in three ways:

  1. Easy attach experience in Azure Front Door profile

  2. Create a new ruleset in Azure Front Door profile

  3. Attach view in Edge Action resource

Easy attach experience in Azure Front Door profile

This flow is useful for users who aren't familiar with the Azure Front Door rules engine and want to attach the Edge Action to the Azure Front Door.

Note

  • For any advanced operations such as custom ruleset name, custom conditions, or actions, use the rules engine UI.
  • The easy attach creation flow checks to see if a default ruleset exists.
  • If it doesn't, it creates one, along with a default invocation rule. If a default ruleset exists with a default rule for another Edge Action, the flow creates a new default rule with a number increment at the end (for example, 002) to attach the new Edge Action.

  1. In the Azure portal, go to your Azure Front Door profile.

  2. Under Settings, select Front Door manager and then select the specific endpoint.

  3. In the Routes section, select the name of the route.

  4. In Update route, scroll down and select Attach Edge Actions link. This link opens the pop-up pane. You see all Edge Actions available in that subscription with their corresponding default versions.

    Screenshot that shows how to update a route.

  5. Select the Edge Action that you want to attach, and then select Associate to confirm selection.

    Screenshot that shows how to attach an Edge Action.

  6. Select Update to commit the changes.

Create a new ruleset in Azure Front Door profile

This flow is more elaborate and requires manual creation of the rule set before associating the Edge Action to the route configuration. At a high level, follow these steps:

  1. In the Azure portal, go to your Azure Front Door profile.

  2. Under Settings, select Rule sets.

  3. Create a new rule set and a rule with the required condition. Select the action as Invoke Edge Action.

  4. Select Save to complete creation of the rule set.

    Screenshot that shows rule set configuration.

  5. Associate this rule set to a route like any other rule set. For more information, see Configure rule sets.

Attach view in Edge Action resource

You can associate a route to an Edge Action through Attachments.

  1. Under Settings of your Edge Action, select Attachments.

  2. Select + Associate route, and then select the corresponding Azure Front Door profile.

    Screenshot that shows how to associate a route using Edge Action Attachment.

  3. Select Next and then select the route name.

  4. Select Next to configure rule sets, and then select Save.

    When the route association is complete, you can see the details of the route you added listed in the Attachments view of your Edge Actions.

Verify Edge Action is attached

You can check in Azure Front Door route whether the corresponding Edge Action is attached.

  1. Under Settings of your Azure Front Door, select Front Door manager.

  2. Select the route that you want to check.

  3. In Update route, select Manage Edge Actions to verify Edge Action details or detach.

    Screenshot that shows how to check Edge Action details.

Detach Edge Action from route

To detach an Edge Action from a route, you can go to the route as shown in the previous section or from the Edge Action itself as follows:

  1. Under Settings of your Edge Action, select Attachments.

  2. Choose the Edge Action that you want to detach and select Dissociate.

    Screenshot that shows how to dissociate and Edge Action from a route.

Execution filters

Execution filters control which version of an Edge Action runs on an Azure Front Door route:

  • Selective version routing: Only the default version and versions that execution filters explicitly reference can run. Execution filters can override the default version.

  • Version protection: Any version that an execution filter references is active. You can't delete or upgrade it while it's in use.

  • Zero-downtime switching: Execution filters enable seamless version transitions without downtime or complex configuration updates.

Execution filters work well for scenarios like:

  • Canary rollouts

  • A/B testing through header-based routing

  • Safely deploying and validating new versions

Apply an execution filter

To safely roll out a new version of Edge Action to production, follow these steps.

  1. Under Settings of your Edge Action, select Versions to verify the versions you have. The following image shows two versions. The First version is the default version and the Second version is the newer version that you want to roll out.

    Screenshot that shows the list of versions.

  2. Select Execution filters.

  3. Select + Add to create a new execution filter that runs the Second version if the request has an HTTP header called test with value execution as shown in the following image:

    Screenshot that shows how to add an execution filter.

  4. On your client side, pass these HTTP headers in dogfood requests to test the new behavior by using the Second version for selected customers who registered to corresponding versions. When everything appears satisfactory, set this version as the default on the Edge Actions resource side.

In the following logs, you see that First runs for regular requests and Second runs when you inject headers in the request:

Screenshot that shows the logs.

Edge Action logs

You can configure Edge Action logs the same way you configure Azure Front Door logs. For more information, see Configure Azure Front Door logs.

  1. Under Monitoring of your Edge Action, select Diagnostic settings.

  2. Select + Add diagnostic setting.

  3. In Diagnostic setting, select allLogs and Send to Log Analytics workspace checkboxes. Then, select the Log Analytics workspace that you want to use and its subscription.

    Screenshot that shows the diagnostic setting.

  4. Select Save.

The EdgeActionConsoleLog table has the following schema:

ColumnName ColumnType Description
TimeGenerated datetime UTC time when the log was generated
TrackingReference string The unique reference string that identifies a request served by Azure Front Door. The tracking reference is sent to the client and to the origin by using the X-Azure-Ref headers. Use the tracking reference when searching for a specific request in the access or WAF logs.
LogMessage string Any message that you specify using the console.log statement in your Edge Action code
EdgeActionVersion string Edge Action version that generated this log message
Type string Type of the log. Currently, there's only one type supported (EdgeActionConsoleLog)
ResourceId string Resource ID of your edge action

Azure Front Door logs

You can also use Azure Front Door logs to verify whether the edge action got executed.

Screenshot that shows Azure Front Door logs.

ColumnName ColumnType Description
edgeActionsStatusCode string Status code representing execution success of edge action.
- 200: Successful
- 503: Error during execution

Pricing

Edge actions follow a simple two-part pricing model based on the number of invocations and execution time beyond 1 ms for each invocation. For details about edge actions pricing, see Azure Front Door pricing, including applicable billing meters and usage-based charges on invocations and execution time. For more information, see Understanding Azure Front Door billing: Example 7.

Related content

  • Last updated on