App Service, Functions, and Logic Apps on Azure Arc (Preview)

You can run App Service, Functions, and Logic Apps on an Azure Arc-enabled Kubernetes cluster. The Kubernetes cluster can be on-premises or hosted in a third-party cloud. This approach lets app developers take advantage of the features of App Service. At the same time, it lets their IT administrators maintain corporate compliance by hosting the App Service apps on internal infrastructure. It also lets other IT operators safeguard their prior investments in other cloud providers by running App Service on existing Kubernetes clusters.


To learn how to set up your Kubernetes cluster for App Service, Functions, and Logic Apps, see Create an App Service Kubernetes environment (Preview).

In most cases, app developers need to know nothing more than how to deploy to the correct Azure region that represents the deployed Kubernetes environment. For operators who provide the environment and maintain the underlying Kubernetes infrastructure, you need to be aware of the following Azure resources:

Public preview limitations

The following public preview limitations apply to App Service Kubernetes environments. They will be updated as changes are made available.

Limitation Details
Supported Azure regions East US, West Europe
Cluster networking requirement Must support LoadBalancer service type and provide a publicly addressable static IP
Cluster storage requirement Must have cluster attached storage class available for use by the extension to support deployment and build of code-based apps where applicable
Feature: Networking Not available (rely on cluster networking)
Feature: Managed identities Not available
Feature: Key vault references Not available (depends on managed identities)
Feature: Pull images from ACR with managed identity Not available (depends on managed identities)
Feature: In-portal editing for Functions and Logic Apps Not available
Feature: FTP publishing Not available
Logs Log Analytics must be configured with cluster extension; not per-site

Pods created by the App Service extension

When the App Service extension is installed on the Azure Arc-enabled Kubernetes cluster, you see several pods created in the release namespace that was specified. These pods enable your Kubernetes cluster to be an extension of the Microsoft.Web resource provider in Azure and support the management and operation of your apps. Optionally, you can choose to have the extension install KEDA for event-driven scaling.

The following table describes the role of each pod that is created by default:

Pod Description
<extensionName>-k8se-app-controller The core operator pod that creates resources on the cluster and maintains the state of components.
<extensionName>-k8se-envoy A front-end proxy layer for all data-plane requests. It routes the inbound traffic to the correct apps.
<extensionName>-k8se-activator An alternative routing destination to help with apps that have scaled to zero while the system gets the first instance available.
<extensionName>-k8se-build-service Supports deployment operations and serves the Advanced tools feature.
<extensionName>-k8se-http-scaler Monitors inbound request volume in order to provide scaling information to KEDA.
<extensionName>-k8se-img-cacher Pulls placeholder and app images into a local cache on the node.
<extensionName>-k8se-log-processor Gathers logs from apps and other components and sends them to Log Analytics.
placeholder-azure-functions-* Used to speed up cold starts for Azure Functions.

App Service Kubernetes environment

The App Service Kubernetes environment resource is required before apps may be created. It enables configuration common to apps in the custom location, such as the default DNS suffix.

Only one Kubernetes environment resource may be created in a custom location. In most cases, a developer who creates and deploys apps doesn't need to be directly aware of the resource. It can be directly inferred from the provided custom location ID. However, when defining Azure Resource Manager templates, any plan resource needs to reference the resource ID of the environment directly. The custom location values of the plan and the specified environment must match.

FAQ for App Service, Functions, and Logic Apps on Azure Arc (Preview)

How much does it cost?

App Service on Azure Arc is free during the public preview.

Are both Windows and Linux apps supported?

Only Linux-based apps are supported, both code and custom containers. Windows apps are not supported.

Which built-in application stacks are supported?

All built-in Linux stacks are supported.

Are all app deployment types supported?

FTP deployment is not supported. Currently az webapp up is also not supported. Other deployment methods are supported, including Git, ZIP, CI/CD, Visual Studio, and Visual Studio Code.

Which App Service features are supported?

During the preview period, certain App Service features are being validated. When they're supported, their left navigation options in the Azure portal will be activated. Features that are not yet supported remain grayed out.

Are networking features supported?

No. Networking features such as hybrid connections, Virtual Network integration, or IP restrictions, are not supported. Networking should be handled directly in the networking rules in the Kubernetes cluster itself.

Are managed identities supported?

No. Apps cannot be assigned managed identities when running in Azure Arc. If your app needs an identity for working with another Azure resource, consider using an application service principal instead.

Are there any scaling limits?

All applications deployed with Azure App Service on Kubernetes with Azure Arc are able to scale within the limits of the underlying Kubernetes cluster. If the underlying Kubernetes Cluster runs out of available compute resources (CPU and memory primarily), then applications will only be able to scale to the number of instances of the application that Kubernetes can schedule with available resource.

What logs are collected?

Logs for both system components and your applications are written to standard output. Both log types can be collected for analysis using standard Kubernetes tools. You can also configure the App Service cluster extension with a Log Analytics workspace, and it will send all logs to that workspace.

By default, logs from system components are sent to the Azure team. Application logs are not sent. You can prevent these logs from being transferred by setting logProcessor.enabled=false as an extension configuration setting. This will also disable forwarding of application to your Log Analytics workspace. Disabling the log processor may impact time needed for any support cases, and you will be asked to collect logs from standard output through some other means.

What do I do if I see a provider registration error?

When creating a Kubernetes environment resource, some subscriptions may see a "No registered resource provider found" error. The error details may include a set of locations and api versions that are considered valid. If this happens, it may be that the subscription needs to be re-registered with the Microsoft.Web provider, an operation which has no impact on existing applications or APIs. To re-register, use the Azure CLI to run az provider register --namespace Microsoft.Web --wait. Then re-attempt the Kubernetes environment command.

Can I deploy the Application services extension on an ARM64 based cluster?

ARM64 based clusters are not supported at this time.

Extension Release Notes

Application services extension v 0.9.0 (May 2021)

  • Initial public preview release of Application services extension.
  • Support for code and container-based deployments of Web, Function, and Logic Applications.
  • Web application runtime support - .NET 3.1 and 5.0; Node JS 12 and 14; Python 3.6, 3.7, and 3.8; PHP 7.3 and 7.4; Ruby 2.5, 2.5.5, 2.6, and 2.6.2; Java SE 8u232, 8u242, 8u252, 11.05, 11.06 and 11.07; Tomcat 8.5, 8.5.41, 8.5.53, 8.5.57, 9.0, 9.0.20, 9.0.33, and 9.0.37.

Application services extension v 0.10.0 (November 2021)

If your extension was in the stable version and auto-upgrade-minor-version is set to enabled the extension will upgrade automatically. To manually upgrade the extension to the latest version of the extension you can run the command below

  • Removed requirement for pre-assigned Static IP Address required for assignment to the Envoy endpoint
  • Upgrade Keda to v2.4.0
  • Upgrade Envoy to v1.19.0
  • Upgrade Azure Function runtime to v3.3.1
  • Set default replica count of App Controller and Envoy Controller to 2 to add further stability

If your extension was in the stable version and auto-upgrade-minor-version is set to true, the extension will upgrade automatically. To manually upgrade the extension to the latest version, you can run the command below:

    az k8s-extension update --cluster-type connectedClusters -c <clustername> -g <resource group> -n <extension name> --release-train stable --version 0.10.0

Next steps

Create an App Service Kubernetes environment (Preview)