-Create a service principal using the [az ad sp create-for-rbac](/cli/azure/ad#az-ad-sp-create-for-rbac) command. The following example first uses the [az apic show](/cli/azure/apic#az-apic-show) command to retrieve the resource ID of the API center. The service principal is then created with the Contributor role for the API center.

-az ad sp create-for-rbac --name $spName --role Contributor --scopes $apicResourceId --json-auth

-az ad sp create-for-rbac --name $spName --role Contributor --scopes $apicResourceId --json-auth

-2. Download the Java agent from NewRelic. It has a file name similar to *newrelic-java-x.x.x.zip*.

- ::: zone pivot="java-javase"

- ::: zone pivot="java-jboss"

- For **JBoss EAP**, `[TODO]`.

- ::: zone-end

- ::: zone pivot="java-jboss"

- For **JBoss EAP**, `[TODO]`.

- ::: zone-end

-> If you already have an environment variable for `JAVA_OPTS` or `CATALINA_OPTS`, append the `-javaagent:/...` option to the end of the current value.

- For **JBoss EAP**, `[TODO]`.

- ::: zone pivot="java-jboss"

- For **JBoss EAP**, `[TODO]`.

- ::: zone-end

-* The configuration options are different depending on which Datadog site your organization is using. See the official [Datadog Integration for Azure Documentation](https://docs.datadoghq.com/integrations/azure/)

-* The configuration options are different depending on which Datadog site your organization is using. See the official [Datadog Integration for Azure Documentation](https://docs.datadoghq.com/integrations/azure/)

-* Dynatrace provides an [Azure Native Dynatrace Service](https://www.dynatrace.com/monitoring/technologies/azure-monitoring/). To monitor Azure App Services using Dynatrace, see the official [Dynatrace for Azure documentation](https://docs.datadoghq.com/integrations/azure/)

-* Dynatrace provides an [Azure Native Dynatrace Service](https://www.dynatrace.com/monitoring/technologies/azure-monitoring/). To monitor Azure App Services using Dynatrace, see the official [Dynatrace for Azure documentation](https://docs.datadoghq.com/integrations/azure/)

-> By default, the Linux Tomcat containers can automatically configure shared data sources for you in the Tomcat server. The only thing for you to do is add an app setting that contains a valid JDBC connection string to an Oracle, SQL Server, PostgreSQL, or MySQL database (including the connection credentials), and App Service automatically adds the cooresponding shared database to */usr/local/tomcat/conf/context.xml* for you, using an appropriate driver available in the container. For an end-to-end scenario using this approach, see [Tutorial: Build a Tomcat web app with Azure App Service on Linux and MySQL](tutorial-java-tomcat-mysql-app.md).

-There are three core steps when [registering a data source with JBoss EAP](https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/configuration_guide/datasource_management): uploading the JDBC driver, adding the JDBC driver as a module, and registering the module. App Service is a stateless hosting service, so the configuration commands for adding and registering the data source module must be scripted and applied as the container starts.

-1. Obtain your database's JDBC driver.

-2. Create an XML module definition file for the JDBC driver. The following example shows a module definition for PostgreSQL.

- ```xml

- <?xml version="1.0" ?>

- <module xmlns="urn:jboss:module:1.1" name="org.postgres">

- <resources>

- <!-- ***** IMPORTANT : REPLACE THIS PLACEHOLDER *******-->

- <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />

- </resources>

- <dependencies>

- <module name="javax.api"/>

- <module name="javax.transaction.api"/>

- </dependencies>

- </module>

- ```

-1. Put your JBoss CLI commands into a file named `jboss-cli-commands.cli`. The JBoss commands must add the module and register it as a data source. The following example shows the JBoss CLI commands for PostgreSQL.

- ```bash

- #!/usr/bin/env bash

- module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml

- /subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)

- data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker

- ```

-1. Create a startup script, `startup_script.sh` that calls the JBoss CLI commands. The following example shows how to call your `jboss-cli-commands.cli`. Later, you'll configure App Service to run this script when the container starts.

- ```bash

- $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli

- ```

-1. Using an FTP client of your choice, upload your JDBC driver, `jboss-cli-commands.cli`, `startup_script.sh`, and the module definition to `/site/deployments/tools/`.

-2. Configure your site to run `startup_script.sh` when the container starts. In the Azure portal, navigate to **Configuration** > **General Settings** > **Startup Command**. Set the startup command field to `/home/site/deployments/tools/startup_script.sh`. **Save** your changes.

-To confirm that the datasource was added to the JBoss server, SSH into your webapp and run `$JBOSS_HOME/bin/jboss-cli.sh --connect`. Once you're connected to JBoss, run the `/subsystem=datasources:read-resource` to print a list of the data sources.

-SSH into your App Service and run the `jcmd` command to see a list of all the Java processes running. In addition to jcmd itself, you should see your Java application running with a process ID number (pid).

-> [!NOTE]

->

-App Service supports clustering for JBoss EAP versions 7.4.1 and greater. To enable clustering, your web app must be [integrated with a virtual network](overview-vnet-integration.md). When the web app is integrated with a virtual network, it restarts, and the JBoss EAP installation automatically starts up with a clustered configuration. The JBoss EAP instances communicate over the subnet specified in the virtual network integration, using the ports shown in the `WEBSITES_PRIVATE_PORTS` environment variable at runtime. You can disable clustering by creating an app setting named `WEBSITE_DISABLE_CLUSTERING` with any value.

-> You can avoid JBOSS clustering timeouts by [cleaning up obsolete discovery files during your app startup](https://github.com/Azure/app-service-linux-docs/blob/master/HowTo/JBOSS/avoid_timeouts_obsolete_nodes.md)

-This feature isn't yet supported in the Azure App Configuration Kubernetes Provider.

-Azure Boost delivers industry leading throughput performance at up to 12.5-GBps throughput and 650K IOPS. This performance is enabled by accelerated storage processing and exposing NVMe disk interfaces to VMs. Storage tasks are offloaded from the host processor to dedicated programmable Azure Boost hardware in our dynamically programmable FPGA. This architecture allows us to update the FPGA hardware in the fleet enabling continuous delivery for our customers.

-By fully applying Azure Boost architecture, we deliver remote, local, and cached disk performance improvements at up to 17-GBps throughput and 3.8M IOPS. Azure Boost SSDs are designed to provide high performance optimized encryption at rest, and minimal jitter to NVMe local disks for Azure VMs with local disks.

-## Force-unlink if there's a region outage

-In case one of the caches in your replication group is unavailable due to region outage, you can forcefully remove the unavailable cache from the replication group.

-az redisenterprise create --location "East US" --cluster-name "Cache1" --sku "Enterprise_E10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"

-az redisenterprise create --location "West US" --cluster-name "Cache2" --sku "Enterprise_E10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"

-New-AzRedisEnterpriseCache -Name "Cache1" -ResourceGroupName "myResourceGroup" -Location "East US" -Sku "Enterprise_E10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}'

-This example creates a new Enterprise E10 cache instance called _Cache2_ in the West US region. Then, the script adds the cache to the "replicationGroup" active geo-replication group created in the previous procedure. the links the two caches, _Cache1_ and _Cache2_, in an active-active configuration.

-New-AzRedisEnterpriseCache -Name "Cache2" -ResourceGroupName "myResourceGroup" -Location "West US" -Sku "Enterprise_E10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}', '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"}'

-It is possible to scale instances that are configured to use active geo-replication. However, a geo-replication group with a mix of different cache sizes can introduce problems. To prevent these issues from occurring, all caches in a geo replication group need to be the same size and capacity.

-Since it is difficult to simultaneously scale all instances in the geo-replication group, Azure Cache for Redis has a locking mechanism. If you scale one instance in a geo-replication group, the underlying VM will be scaled, but the memory available will be capped at the original size until the other instances are scaled up as well. And any other scaling operations for the remaining instances are locked until they match the same configuration as the first cache to be scaled.

-For example, you may have three instances in your geo-replication group, all Enterprise E10 instances:

-At this point, the `Redis01` and `Redis02` instances can only scale up to an Enterprise E20 instance. All other scaling operations are blocked.

-Once each instance has been scaled to the same tier and size, all scaling locks are removed:

- "storageAccountId": "/subscriptions/df602c9c-7aa0-407d-a6fb-eb20c8bd1192/resourceGroups/apptest/providers/Microsoft.Storage/storageAccounts/appteststorage1",

- "eventHubAuthorizationRuleId": "/subscriptions/1a66ce04-b633-4a0b-b2bc-a912ec8986a6/resourceGroups/montest/providers/microsoft.eventhub/namespaces/mynamespace/eventhubs/myeventhub/authorizationrules/myrule",

- "workspaceId": "/subscriptions/4b9e8510-67ab-4e9a-95a9-e2f1e570ea9c/resourceGroups/insights-integration/providers/Microsoft.OperationalInsights/workspaces/myworkspace",

- "storageAccountId": "/subscriptions/df602c9c-7aa0-407d-a6fb-eb20c8bd1192/resourceGroups/apptest/providers/Microsoft.Storage/storageAccounts/myteststorage",

- "eventHubAuthorizationRuleID": "/subscriptions/1a66ce04-b633-4a0b-b2bc-a912ec8986a6/resourceGroups/montest/providers/microsoft.eventhub/namespaces/mynamespace/authorizationrules/myrule",

- "marketplacePartnerId": "/subscriptions/abcdeabc-1234-1234-ab12-123a1234567a/resourceGroups/test-rg/providers/Microsoft.Datadog/monitors/mydatadog",

- "workspaceId": "/subscriptions/4b9e8510-67ab-4e9a-95a9-e2f1e570ea9c/resourceGroups/insights integration/providers/Microsoft.OperationalInsights/workspaces/myworkspace",

- "resourceId": "/SUBSCRIPTIONS/E6761CE7-A7BC-442E-BBAE-950A121933B5/RESOURCEGROUPS/AZURE-CACHE/PROVIDERS/MICROSOFT.CACHE/REDIS/MYCACHE",

- "resourceId": "/SUBSCRIPTIONS/4A1C78C6-5CB1-422C-A34E-0DF7FCB9BD0B/RESOURCEGROUPS/TEST/PROVIDERS/MICROSOFT.CACHE/REDISENTERPRISE/AUDITING-SHOEBOX/DATABASES/DEFAULT",

- "resourceId": "/SUBSCRIPTIONS/4A1C78C6-5CB1-422C-A34E-0DF7FCB9BD0B/RESOURCEGROUPS/TEST/PROVIDERS/MICROSOFT.CACHE/REDISENTERPRISE/AUDITING-SHOEBOX/DATABASES/DEFAULT",

- "resourceId": "/SUBSCRIPTIONS/4A1C78C6-5CB1-422C-A34E-0DF7FCB9BD0B/RESOURCEGROUPS/TEST/PROVIDERS/MICROSOFT.CACHE/REDISENTERPRISE/AUDITING-SHOEBOX/DATABASES/DEFAULT",

-1. Next, process the data by adding an `id` index, removing spaces from the column titles, and filters the movies to take only movies made after 1970 and from English speaking countries. This filtering step reduces the number of movies in the dataset, which lowers the cost and time required to generate embeddings. You're free to change or remove the filter parameters based on your preferences.

-If you run on an App Service plan, you should enable the **Always on** setting so that your function app runs correctly. On an App Service plan, the functions runtime goes idle after a few minutes of inactivity, so only HTTP triggers will "wake up" your functions. The **Always on** setting is available only on an App Service plan. On a Consumption plan, the platform activates function apps automatically.

-Even with Always On enabled, the execution timeout for individual functions is controlled by the `functionTimeout` setting in the [host.json](functions-host-json.md#functiontimeout) project file.

-Zip deployment is also an easy way to run your functions from the deployment package. To learn more, see [Run your functions from a package file in Azure](run-functions-from-deployment-package.md).

- .AddSingleton<IHttpResponderService, DefaultHttpResponderService>()

- .Configure<LoggerFilterOptions>(options =>

- // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override.

- // Log levels can also be configured using appsettings.json. For more information, see https://learn.microsoft.com/azure/azure-monitor/app/worker-service#ilogger-logs

- LoggerFilterRule toRemove = options.Rules.FirstOrDefault(rule => rule.ProviderName

- == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");

-

- if (toRemove is not null)

- {

- options.Rules.Remove(toRemove);

- }

- });

-You can configure your isolated process application to emit logs directly to [Application Insights](/azure/azure-monitor/app/app-insights-overview?tabs=net). This behavior replaces the default behavior of [relaying logs through the host](./configure-monitoring.md#custom-application-logs), and is recommended because it gives you control over how those logs are emitted.

-module.exports = async function (context, req, products) {

- body: products

-dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues --version 5.0.0

-This article shows you how to estimate plan costs for the Consumption and Flex Consumption hosting plans.

-Azure Functions currently offers four different hosting plans for your function apps, with each plan having its own pricing model:

-| [**Consumption**](consumption-plan.md) | You're only charged for the time that your function app runs. This plan includes a [free grant][pricing page] on a per subscription basis.|

-| [**Flex Consumption plan**](flex-consumption-plan.md)| You pay for execution time on the instances on which your functions are running, plus any _always ready_ instances. Instances are dynamically added and removed based on the number of incoming events. Also supports virtual network integration. |

-You should always choose the plan that best supports the feature, performance, and cost requirements for your function executions. To learn more, see [Azure Functions scale and hosting](functions-scale.md).

-This article focuses on Consumption and Flex Consumption plans because in these plans billing depends on active periods of executions inside each instance.

-### [Consumption plan](#tab/consumption-plan)

-The execution *cost* of a single function execution is measured in *GB-seconds*. Execution cost is calculated by combining its memory usage with its execution time. A function that runs for longer costs more, as does a function that consumes more memory.

-Consider a case where the amount of memory used by the function stays constant. In this case, calculating the cost is simple multiplication. For example, say that your function consumed 0.5 GB for 3 seconds. Then the execution cost is `0.5GB * 3s = 1.5 GB-seconds`.

-Since memory usage changes over time, the calculation is essentially the integral of memory usage over time. The system does this calculation by sampling the memory usage of the process (along with child processes) at regular intervals. As mentioned on the [pricing page], memory usage is rounded up to the nearest 128-MB bucket. When your process is using 160 MB, you're charged for 256 MB. The calculation takes into account concurrency, which is multiple concurrent function executions in the same process.

-> [!NOTE]

-> While CPU usage isn't directly considered in execution cost, it can have an impact on the cost when it affects the execution time of the function.

-For an HTTP-triggered function, when an error occurs before your function code begins to execute you aren't charged for an execution. This means that 401 responses from the platform due to API key validation or the App Service Authentication / Authorization feature don't count against your execution cost. Similarly, 5xx status code responses aren't counted when they occur in the platform before your function processes the request. A 5xx response generated by the platform after your function code has started to execute is still counted as an execution, even when the error isn't raised from your function code.

-| Tools-based | &bull;&nbsp;[Visual&nbsp;Studio&nbsp;Code&nbsp;publish](functions-develop-vs-code.md#publish-to-azure)<br/>&bull;&nbsp;[Visual Studio publish](functions-develop-vs.md#publish-to-azure)<br/>&bull;&nbsp;[Core Tools publish](functions-run-local.md#publish) | Deployments during development and other improvised deployments. Deploying your code on-demand using [local development tools](functions-develop-local.md#local-development-environments). |

-| [OneDeploy](#one-deploy) |Γ£ö| | | | |

-The following deployment methods are available in Azure Functions.

->__When to use it:__ The portal is a good way to get started with Azure Functions. For more advanced development work, we recommend that you use one of the following client tools:

-The following table shows the operating systems and languages that support in-portal editing:

-| Language | Windows Consumption | Windows Premium | Windows Dedicated | Linux Consumption | Linux Premium | Linux Dedicated |

-|-|:--: |:-:|:--:|:--:|:-:|::|

-| C#¹ | | | | | |

-| Java | | | | | | |

-| JavaScript (Node.js) |Γ£ö|Γ£ö|Γ£ö| |Γ£ö|Γ£ö|

-| Python² | | | |Γ£ö |Γ£ö |Γ£ö |

-| PowerShell |Γ£ö|Γ£ö|Γ£ö| | | |

-| TypeScript (Node.js) | | | | | | |

-¹ In-portal editing is only supported for C# script files, which run in-process with the host. For more information, see the [Azure Functions C# script (.csx) developer reference](functions-reference-csharp.md).

-² In-portal editing is only supported for the [v1 Python programming model](functions-reference-python.md?pivots=python-mode-configuration).

-> You can complete this tutorial using any other [hosting plan](functions-scale.md) for your function app.

-1. In Visual Studio Code, open your function app.

-1. Press F1 to open the command palette, enter `Azure Functions: Create Function...`, and select **Create new project**.

-1. For your project workspace, select the directory location. Make sure that you either create a new folder or choose an empty folder for the project workspace.

-1. At the prompts, provide the following information:

- |**Provide a function name**| Enter `BlobTriggerEventGrid`. |

- |**Select subscription**| Select your subscription.|

- |**This is the path within your storage account that the trigger will monitor**| Accept the default value `samples-workitems`. |

- |**Select a template for your project's first function**| Select `Azure Blob Storage trigger (using Event Grid)`. |

- |**Provide a function name**| Enter `BlobTriggerEventGrid`. |

- |**Select subscription**| Select your subscription.|

- |**This is the path within your storage account that the trigger will monitor**| Accept the default value `samples-workitems`. |

- ::: zone-end

- | **Provide an artifact ID** | Select `BlobTriggerEventGrid`. |

- | **Provide an app name** | Accept the generated name starting with `BlobTriggerEventGrid`. |

- ::: zone-end

- ::: zone pivot="programming-language-typescript"

- |Prompt|Action|

- |**Provide a function name**| Enter `BlobTriggerEventGrid`. |

- |**Select subscription**| Select your subscription.|

- |**This is the path within your storage account that the trigger will monitor**| Accept the default value `samples-workitems`. |

- |**Provide a function name**| Enter `BlobTriggerEventGrid`. |

- |**Select subscription**| Select your subscription.|

- |**This is the path within your storage account that the trigger will monitor**| Accept the default value `samples-workitems`. |

- |**Provide a function name**| Enter `BlobTriggerEventGrid`. |

- |**Select subscription**| Select your subscription.|

- |**This is the path within your storage account that the trigger will monitor**| Accept the default value `samples-workitems`. |

-1. If haven't already done so, install the [Azurite v3 extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=Azurite.azurite).

-| Part | Example |

-| | |

-| Blob-specific path | `/runtime/webhooks/blobs` |

-| Function query string | `?functionName=Host.Functions.BlobTriggerEventGrid` |

-| Blob extension access key | `&code=<BLOB_EXTENSION_KEY>` |

- https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/blobs?functionName=Host.Functions.BlobTriggerEventGrid&code=<BLOB_EXTENSION_KEY>

- In this example, replace `<FUNCTION_APP_NAME>` with the name of your function app and replace `<BLOB_EXTENSION_KEY>` with the value you got from the portal. If you used a different name for your function, you'll also need to change the `functionName` query string value to your function name.

-1. select the **Events** option from the left menu.

-1. Select **Create** to create the event subscription.

-+ [Working with blobs](storage-considerations.md#working-with-blobs)

-+ When using GitHub Actions, the code is deployed to your function app using [Zip deployment for Azure Functions](deployment-zip-push.md).

-This article describes the networking features available across the hosting options for Azure Functions. All the following networking options give you some ability to access resources without using internet-routable addresses or to restrict internet access to a function app.

-Using service endpoints, you can restrict many Azure services to selected virtual network subnets to provide a higher level of security. Regional virtual network integration enables your function app to reach Azure services that are secured with service endpoints. This configuration is supported on all [plans](functions-scale.md#networking-features) that support virtual network integration. To access a service endpoint-secured service, you must do the following:

-If you need someone else to enable service endpoints on the subnet, select the **Ignore missing Microsoft.Web service endpoints** check box. Your app is configured for service endpoints in anticipation of having them enabled later on the subnet.

-## Virtual network integration

-Virtual network integration allows your function app to access resources inside a virtual network.

-Azure Functions supports two kinds of virtual network integration:

-Virtual network integration in Azure Functions uses shared infrastructure with App Service web apps. To learn more about the two types of virtual network integration, see:

-* [Regional virtual network integration](../app-service/overview-vnet-integration.md#regional-virtual-network-integration)

-* [Gateway-required virtual network integration](../app-service/configure-gateway-required-vnet-integration.md)

-To learn how to set up virtual network integration, see [Enable virtual network integration](#enable-virtual-network-integration).

-### Enable virtual network integration

-1. In your function app in the [Azure portal](https://portal.azure.com), select **Networking**, then under **VNet Integration** select **Click here to configure**.

-1. Select **Add VNet**.

- :::image type="content" source="./media/functions-networking-options/vnet-int-function-app.png" alt-text="Select VNet Integration":::

-1. The drop-down list contains all of the Azure Resource Manager virtual networks in your subscription in the same region. Select the virtual network you want to integrate with.

- :::image type="content" source="./media/functions-networking-options/vnet-int-add-vnet-function-app.png" alt-text="Select the VNet":::

- * The Functions Flex Consumption and Elastic Premium plans only supports regional virtual network integration. If the virtual network is in the same region, either create a new subnet or select an empty, pre-existing subnet.

- * To select a virtual network in another region, you must have a virtual network gateway provisioned with point to site enabled. Virtual network integration across regions is only supported for Dedicated plans, but global peerings work with regional virtual network integration.

-During the integration, your app is restarted. When integration is finished, you see details on the virtual network you're integrated with. By default, Route All is enabled, and all traffic is routed into your virtual network.

-If you wish for only your private traffic ([RFC1918](https://datatracker.ietf.org/doc/html/rfc1918#section-3) traffic) to be routed, please follow the steps in the [app service documentation](../app-service/overview-vnet-integration.md#application-routing).

-* **Network security groups (NSGs)**: You can block outbound traffic with an NSG that's placed on your integration subnet. The inbound rules don't apply because you can't use virtual network integration to provide inbound access to your app.

-* **Route tables (UDRs)**: You can place a route table on the integration subnet to send outbound traffic where you want.

-For the Flex Consumption plan:

-1. Ensure that the `Microsoft.App` Azure resource provider is enabled for your subscription by [following these instructions](../azure-resource-manager/management/resource-providers-and-types.md#register-resource-provider). The subnet delegation required by Flex Consumption apps is `Microsoft.App/environments`.

-1. The subnet delegation required by Flex Consumption apps is `Microsoft.App/environments`. This is a change from Elastic Premium and App Service which have a different delegation requirement.

-1. You can plan for 40 IP addresses to be used at the most for one function app, even if the app scales beyond 40. For example, if you have fifteen Flex Consumption function apps that will be VNet integrated into the same subnet, you can plan for 15x40 = 600 IP addresses used at the most. This limit is subject to change, and is not enforced.

-1. The subnet can't already be in use for other purposes (like private or service endpoints, or [delegated](../virtual-network/subnet-delegation-overview.md) to any other hosting plan or service). While you can share the same subnet with multiple Flex Consumption apps, the networking resources will be shared across these function apps and this can lead to one function app impacting the performance of others on the same subnet.

-There are some limitations with using virtual network:

-* The feature is available from Flex Consumption, Elastic Premium, and App Service Premium V2 and Premium V3. It's also available in Standard but only from newer App Service deployments. If you are on an older deployment, you can only use the feature from a Premium V2 App Service plan. If you want to make sure you can use the feature in a Standard App Service plan, create your app in a Premium V3 App Service plan. Those plans are only supported on our newest deployments. You can scale down if you desire after that.

-* The integration subnet can be used by only one App Service plan.

-* The feature requires an unused subnet that's a /28 or larger in an Azure Resource Manager virtual network.

-* You can't delete a virtual network with an integrated app. Remove the integration before you delete the virtual network.

-Virtual network integration depends on a dedicated subnet. When you provision a subnet, the Azure subnet loses five IPs from the start. For the Elastic Premium and App Service plans, one address is used from the integration subnet for each plan instance. When you scale your app to four instances, then four addresses are used. For Flex Consumption this does not apply and instances share IP addresses.

-When you scale up or down in size, the required address space is doubled for a short period of time. This affects the real, available supported instances for a given subnet size. The following table shows both the maximum available addresses per CIDR block and the effect this has on horizontal scale:

-When you want your apps in another plan to reach a virtual network that's already connected to by apps in another plan, select a different subnet than the one being used by the pre-existing virtual network integration.

-You can use network security groups to block inbound and outbound traffic to resources in a virtual network. An app that uses regional virtual network integration can use a [network security group][VNETnsg] to block outbound traffic to resources in your virtual network or the internet. To block traffic to public addresses, you must have virtual network integration with Route All enabled. The inbound rules in an NSG don't apply to your app because virtual network integration affects only outbound traffic from your app.

-To control inbound traffic to your app, use the Access Restrictions feature. An NSG that's applied to your integration subnet is in effect regardless of any routes applied to your integration subnet. If your function app is virtual network integrated with Route All enabled, and you don't have any routes that affect public address traffic on your integration subnet, all of your outbound traffic is still subject to NSGs assigned to your integration subnet. When Route All isn't enabled, NSGs are only applied to RFC1918 traffic.

-You can use route tables to route outbound traffic from your app to wherever you want. By default, route tables only affect your RFC1918 destination traffic. When Route All is enabled, all of your outbound calls are affected. When [Route All](../app-service/overview-vnet-integration.md#application-routing) is disabled, only private traffic (RFC1918) is affected by your route tables. Routes that are set on your integration subnet won't affect replies to inbound app requests. Common destinations can include firewall devices or gateways.

-## Restrict your storage account to a virtual network

-This feature is supported for all Windows and Linux virtual network-supported SKUs in the Dedicated (App Service) plan and for the Elastic Premium plans, as well as the Flex Consumption plan. The Consumption plan isn't supported. To learn how to set up a function with a storage account restricted to a private network, see [Restrict your storage account to a virtual network](configure-networking-how-to.md#restrict-your-storage-account-to-a-virtual-network).

-## Use Key Vault references

-## Virtual network triggers (non-HTTP)

-Currently, you can use non-HTTP trigger functions from within a virtual network in one of two ways:

-+ Run your function app in a Flex Consumption, App Service plan or App Service Environment.

-### Elastic Premium plan with virtual network triggers

-The [Elastic Premium plan](functions-premium-plan.md) lets you create functions that are triggered by services inside a virtual network. These non-HTTP triggers are known as _virtual network triggers_.

-By default, virtual network triggers don't cause your function app to scale beyond their pre-warmed instance count. However, certain extensions support virtual network triggers that cause your function app to scale dynamically. You can enable this _dynamic scale monitoring_ in your function app for supported extensions in one of these ways:

-### App Service plan and App Service Environment with virtual network triggers

-When your function app runs in either an App Service plan or an App Service Environment, you can use non-HTTP trigger functions. For your functions to get triggered correctly, you must be connected to a virtual network with access to the resource defined in the trigger connection.

-## Hybrid Connections

-[Hybrid Connections](../azure-relay/relay-hybrid-connections-protocol.md) is a feature of Azure Relay that you can use to access application resources in other networks. It provides access from your app to an application endpoint. You can't use it to access your application. Hybrid Connections is available to functions that run on Windows in all but the Consumption plan.

-As used in Azure Functions, each hybrid connection correlates to a single TCP host and port combination. This means that the hybrid connection's endpoint can be on any operating system and any application as long as you're accessing a TCP listening port. The Hybrid Connections feature doesn't know or care what the application protocol is or what you're accessing. It just provides network access.

-To learn more, see the [App Service documentation for Hybrid Connections](../app-service/app-service-hybrid-connections.md). These same configuration steps support Azure Functions.

->[!IMPORTANT]

-> Hybrid Connections is only supported on Windows plans. Linux isn't supported.

-## Outbound IP restrictions

-Outbound IP restrictions are available in a Flex Consumption plan, Elastic Premium plan, App Service plan, or App Service Environment. You can configure outbound restrictions for the virtual network where your App Service Environment is deployed.

-When you integrate a function app in an Elastic Premium plan or an App Service plan with a virtual network, the app can still make outbound calls to the internet by default. By integrating your function app with a virtual network with Route All enabled, you force all outbound traffic to be sent into your virtual network, where network security group rules can be used to restrict traffic. For Flex Consumption all traffic is already routed through the virtual network and Route All is not needed.

-To learn how to control the outbound IP using a virtual network, see [Tutorial: Control Azure Functions outbound IP with an Azure virtual network NAT gateway](functions-how-to-use-nat-gateway.md).

-## Automation

-The following APIs let you programmatically manage regional virtual network integrations:

-+ **Azure CLI**: Use the [`az functionapp vnet-integration`](/cli/azure/functionapp/vnet-integration) commands to add, list, or remove a regional virtual network integration.

-+ **ARM templates**: Regional virtual network integration can be enabled by using an Azure Resource Manager template. For a full example, see [this Functions quickstart template](https://azure.microsoft.com/resources/templates/function-premium-vnet-integration/).

-| **[Consumption plan]** | Azure Functions | Generally available (GA) | None |

-| **[Flex Consumption plan]** | Azure Functions | Preview | None |

-|**[Consumption plan]**| Pay for compute resources only when your functions are running (pay-as-you-go) with automatic scale.<br/><br/>On the Consumption plan, instances of the Functions host are dynamically added and removed based on the number of incoming events.<br/><br/> Γ£ö Default hosting plan that provides true _serverless_ hosting.<br/>Γ£ö Pay only when your functions are running.<br/>Γ£ö Scales automatically, even during periods of high load.|

-|**[Flex Consumption plan]**| Get high scalability with compute choices, virtual networking, and pay-as-you-go billing.<br/><br/>On the Flex Consumption plan, instances of the Functions host are dynamically added and removed based on the configured per instance concurrency and the number of incoming events. <br/><br/> Γ£ö Reduce cold starts by specifying a number of pre-provisioned (always ready) instances.<br/> Γ£ö Supports virtual networking for added security.<br/>Γ£ö Pay when your functions are running.<br/>Γ£ö Scales automatically, even during periods of high load.|

-| **[Consumption plan]** | ✅ Code-only<br/>❌ Container (not supported) | ✅ Code-only |

-| **[Consumption plan]** | [Event driven](event-driven-scaling.md). Scales out automatically, even during periods of high load. Functions infrastructure scales CPU and memory resources by adding more instances of the Functions host, based on the number of incoming trigger events. | **Windows:** 200<br/>**Linux:** 100¹ |

-| **[Consumption plan]** | Apps can scale to zero when idle, meaning some requests might have more latency at startup. The consumption plan does have some optimizations to help decrease cold start time, including pulling from prewarmed placeholder functions that already have the host and language processes running. |

-| **[Consumption plan]** | Pay only for the time your functions run. Billing is based on number of executions, execution time, and memory used. |

-| **[Flex Consumption plan]** | Billing is based on number of executions, the memory of instances when they're actively executing functions, plus the cost of any [always ready instances](./flex-consumption-plan.md#always-ready-instances). For more information, see [Flex Consumption plan billing](flex-consumption-plan.md#billing).

-description: Learn about Azure Functions language runtime support policy

-# Language runtime support policy

-This article explains Azure functions language runtime support policy.

-Azure Functions runtime is built around various components, including operating systems, the Azure Functions host, and language-specific workers. To maintain full-support coverages for function apps, Functions support aligns with end-of-life support for a given language. To achieve this goal, Functions implements a phased reduction in support as programming language versions reach their end-of-life dates. For most language versions, the retirement date coincides with the community end-of-life date.

-### Notification phase

-The Functions team sends notification emails to function app users about upcoming language version retirements. When you receive the notification, you should prepare to upgrade functions apps to use to a supported version.

-### Retirement phase

-After the language end-of-life date, function apps that use retired language versions can still be created and deployed, and they continue to run on the platform. However your apps aren't eligible for new features, security patches, and performance optimizations until you upgrade them to a supported language version.

-> [!IMPORTANT]

->You're highly encouraged to upgrade the language version of your affected function apps to a supported version.

->If you're running functions apps using an unsupported runtime or language version, you may encounter issues and performance implications and will be required to upgrade before receiving support for your function app.

-Any Azure Functions supported exceptions to language-specific retirement policies are documented here.

-|Language | Configuration guides |

-This historical table shows the highest language level for specific Azure Functions runtime versions that are no longer supported:

-|Language |2.x | 3.x |

-To enable your function app to run from a package, add a `WEBSITE_RUN_FROM_PACKAGE` app setting to your function app. The `WEBSITE_RUN_FROM_PACKAGE` app setting can have one of the following values:

-This section provides information about how to run your function app from a package deployed to a URL endpoint. This option is the only one supported for running from a Linux-hosted package with a Consumption plan.

-You get this error when the deployment exceeds an allowed limit. Typically, you see this error when either your template or the job that runs the deployment is too large.

-The deployment job can't exceed 1 MB and that includes metadata about the request. For large templates, the metadata combined with the template might exceed a job's allowed size.

-The template can't exceed 4 MB, and each resource definition can't exceed 1 MB. The limits apply to the final state of the template after it has been expanded for resource definitions that use loops to create many instances. The final state also includes the resolved values for variables and parameters.

-## Solution 1: Use dependencies carefully

-Use an [implicit dependency](../bicep/resource-dependencies.md#implicit-dependency) that's created when a resource references another resource by its symbolic name. For most deployments, it's not necessary to use `dependsOn` and create an [explicit dependency](../bicep/resource-dependencies.md#explicit-dependency).

-When using [copy](../templates/copy-resources.md) loops to deploy resources, don't use the loop name as a dependency:

-```json

-dependsOn: [ "nicLoop" ]

-```

-Instead, use the instance of the resource from the loop that you need to depend on. For example:

-```json

-dependsOn: [

- "[resourceId('Microsoft.Network/networkInterfaces', concat('nic-', copyIndex()))]"

-]

-```

-## Solution 3: Reduce name size

-Try to shorten the length of the names you use for [parameters](../bicep/parameters.md), [variables](../bicep/variables.md), and [outputs](../bicep/outputs.md). When these values are repeated in loops, a long name gets multiplied many times.

-Try to shorten the length of the names you use for [parameters](../templates/parameters.md), [variables](../templates/variables.md), and [outputs](../templates/outputs.md). When these values are repeated through copy loops, a long name gets multiplied many times.

-To help you understand media quality in VoIP and video calls that use Azure Communication Services, there's a feature called *media quality statistics*. Use it to examine the low-level audio, video, and screen-sharing quality metrics for incoming and outgoing call metrics.

-description: Overview of Pre-Call Diagnostic APIs

-# Pre-Call diagnostic

-The Pre-Call API enables developers to programmatically validate a clientΓÇÖs readiness to join an Azure Communication Services Call. The Pre-Call APIs can be accessed through the Calling SDK. They provide multiple diagnostics including device, connection, and call quality. Pre-Call APIs are available only for Web (JavaScript). We'll be enabling these capabilities across platforms in the future, provide us with feedback on what platforms you would like to see Pre-Call APIs on.

- For details, see [Use Azure CLI to Create and Manage Access Tokens](../../quickstarts/identity/access-tokens.md?pivots=platform-azcli).

-## Accessing Pre-Call APIs

->Pre-Call diagnostics are available starting on the version [1.9.1-beta.1](https://www.npmjs.com/package/@azure/communication-calling/v/1.9.1-beta.1) of the Calling SDK. Make sure to use that version when trying the next instructions.

-To Access the Pre-Call API, you need to initialize a `callClient`, and provision an Azure Communication Services access token. There you can access the `PreCallDiagnostics` feature and the `startTest` method.

-The Pre-Call API returns a full diagnostic of the device including details like device permissions, availability and compatibility, call quality stats and in-call diagnostics. The results are returned as a `PreCallDiagnosticsResult` object.

-Individual result objects can be accessed as such using the `preCallDiagnosticsResult` constant. Results for individual tests be returned as they're completed with many of the test results being available immediately. If you use the `inCallDiagnostics` test, the results might take up to 1 minute as the test validates quality of the video and audio.

-Browser compatibility check. Checks for `Browser` and `OS` compatibility and provides a `Supported` or `NotSupported` value back.

-In the case that the test fails and the browser being used by the user is `NotSupported`, the easiest way to fix that is by asking the user to switch to a supported browser. Refer to the supported browsers in our [documentation](./calling-sdk-features.md#javascript-calling-sdk-support-by-os-and-browser).

-Permission check. Checks whether video and audio devices are available from a permissions perspective. Provides `boolean` value for `audio` and `video` devices.

-In the case that the test fails and the permissions are false for audio and video, the user shouldn't continue into joining a call. Rather you need to prompt the user to enable the permissions. To do it, the best way is provided the specific instruction on how to access permission access based on the OS, version and browser they are on. For more information on permissions, check out our [recommendations](https://techcommunity.microsoft.com/t5/azure-communication-services/checklist-for-advanced-calling-experiences-in-mobile-web/ba-p/3266312).

-Device availability. Checks whether microphone, camera and speaker devices are detected in the system and ready to use. Provides an `Available` or `NotAvailable` value back.

-In the case that devices aren't available, the user shouldn't continue into joining a call. Rather the user should be prompted to check device connections to ensure any headsets, cameras or speakers are properly connected. For more information on device management, check out our [documentation](../../how-tos/calling-sdk/manage-video.md?pivots=platform-web#device-management)

-Performs a quick call to check in-call metrics for audio and video and provides results back. Includes connectivity (`connected`, boolean), bandwidth quality (`bandWidth`, `'Bad' | 'Average' | 'Good'`) and call diagnostics for audio and video (`diagnostics`). Diagnostic are provided `jitter`, `packetLoss` and `rtt` and results are generated using a simple quality grade (`'Bad' | 'Average' | 'Good'`).

-InCall diagnostics uses [media quality stats](./media-quality-sdk.md) to calculate quality scores and diagnose issues. During the pre-call diagnostic, the full set of media quality stats are available for consumption. These stats include raw values across video and audio metrics that can be used programatically. The InCall diagnostic provides a convenience layer on top of media quality stats to consume the results without the need to process all the raw data. See section on media stats for instructions to access.

-At this step, there are multiple failure points to watch out for. The values provided by the API are based on the threshold values required by the service. Those raw thresholds can be found in our [media quality stats documentation](./media-quality-sdk.md#best-practices).

-### Media stats

-For granular stats on quality metrics like jitter, packet loss, rtt, etc. `callMediaStatistics` are provided as part of the `preCallDiagnosticsResult` feature. See the [full list and description of the available metrics](./media-quality-sdk.md) in the linked article. You can subscribe to the call media stats to get full collection of them. This stat is the raw metrics that are used to calculate InCall diagnostic results and which can be consumed granularly for further analysis.

-```javascript

-const mediaStatsCollector = callMediaStatistics.startCollector();

-mediaStatsCollector.on('mediaStatsEmitted', (mediaStats: SDK.MediaStats) => {

- // process the stats for the call.

- console.log(mediaStats);

-});

-```

-When the Pre-Call diagnostic test runs, behind the scenes it uses calling minutes to run the diagnostic. The test lasts for roughly 30 seconds, using up 30 seconds of calling which is charged at the standard rate of $0.004 per participant per minute. For the case of Pre-Call diagnostic, the charge will be for 1 participant x 30 seconds = $0.002.

-Different logging frameworks support different log levels. In the JVM diagnostics platform, some frameworks are better supported than others. Before changing logging levels, make sure the log levels you're using are supported by both the framework and platform.

-| Framework | OFF | FATAL | ERROR | WARN | INFO | DEBUG | TRACE | ALL |

-||-|-|-|||-|-|--|

-| Log4j2 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |

-| Logback | Yes | No | Yes | Yes | Yes | Yes | Yes | Yes |

-| jboss-logging | No | Yes | Yes | Yes | Yes | Yes | Yes | No |

-| **Platform** | Yes | No | Yes | Yes | Yes | Yes | Yes | No |

-| Log Level | FATAL | ERROR | WARN | INFO | DEBUG | TRACE | ALL |

-|--|-|-|||-|-|--|

-| **OFF** | | | | | | | |

-| **FATAL** | Yes | | | | | | |

-| **ERROR** | Yes | Yes | | | | | |

-| **WARN** | Yes | Yes | Yes | | | | |

-| **INFO** | Yes | Yes | Yes | Yes | | | |

-| **DEBUG** | Yes | Yes | Yes | Yes | Yes | | |

-| **TRACE** | Yes | Yes | Yes | Yes | Yes | Yes | |

-| **ALL** | Yes | Yes | Yes | Yes | Yes | Yes | Yes |

-For example, if you set log level to `DEBUG`, your app will print logs with level `FATAL`, `ERROR`, `WARN`, `INFO`, `DEBUG` and will NOT print logs with level `TRACE` AND `ALL`.

-# Use Event Hubs Data Explorer to run data operations on Event Hubs

- * Check out [Event Hubs features and terminology](event-hubs-features.md)

-### 1490 An application whitelisting solution is implemented on all servers to restrict the execution of executables, software libraries, scripts and installers to an approved set

-## 1.1 Least Functionality | Authorized Software / Whitelisting

-# Connect to Azure AI services from Standard workflows in Azure Logic Apps (Preview)

-> [!NOTE]

-> This capability is in preview and is subject to the

-> [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-> Round-trip latency to West India from other Azure regions is included in the table. However, West India is not a source region so roundtrips from West India are not included in the table.]

- - Determine the deployment model for API support in the target region: [Distributed managed functions](../static-web-apps/distributed-functions.md) or [Bring Your own functions](../static-web-apps/functions-bring-your-own.md). Understand the differences between the two models.

-## Use one Dynatrace resource with multiple subscriptions

-You can now monitor all your subscriptions through a single Dynatrace resource using **Monitored Subscriptions**. Your experience is simplified because you don't have to set up a Dynatrace resource in every subscription that you intend to monitor. You can monitor multiple subscriptions by linking them to a single Dynatrace resource that is tied to a Dynatrace environment. This provides a single pane view for all resources across multiple subscriptions.

-To manage multiple subscriptions that you want to monitor, select **Monitored Subscriptions** in the **Dynatrace environment configurations** section of the Resource menu.

-From **Monitored Subscriptions** in the Resource menu, select **Add Subscriptions**. The **Add Subscriptions** experience that opens and shows the subscriptions you have *Owner* role assigned to and any Dynatrace resource created in those subscriptions that is already linked to the same Dynatrace environment as the current resource.

-If the subscription you want to monitor has a resource already linked to the same Dynatrace org, we recommend that you delete the Dynatrace resources to avoid shipping duplicate data and incurring double the charges.

-Select the subscriptions you want to monitor through the Dynatrace resource and select **Add**.

-If the list doesn't get updated automatically, select **Refresh** to view the subscriptions and their monitoring status. You might see an intermediate status of *In Progress* while a subscription gets added. When the subscription is successfully added, you see the status is updated to **Active**. If a subscription fails to get added, **Monitoring Status** shows as **Failed**.

-The set of tag rules for metrics and logs defined for the Dynatrace resource applies to all subscriptions that are added for monitoring. Setting separate tag rules for different subscriptions isn't supported. Diagnostics settings are automatically added to resources in the added subscriptions that match the tag rules defined for the Dynatrace resource.

-If you have existing Dynatrace resources that are linked to the account for monitoring, you can end up with duplication of logs that can result in added charges. Ensure you delete redundant Dynatrace resources that are already linked to the account. You can view the list of connected resources and delete the redundant ones. We recommend consolidating subscriptions into the same Dynatrace resource where possible.

-| **Name** | Virtual machine name. |

-| **Status** | Indicates whether the virtual machine is stopped or running. Dynatrace OneAgent can only be installed on virtual machines that are running. If the virtual machine is stopped, installing the Dynatrace OneAgent will be disabled. |

-| **Auto-update** | Whether auto-update has been enabled for the OneAgent. |

-To establish single sign-on or change the application, select **Enable single sign-on through Microsoft Entra ID**. The portal retrieves Dynatrace application from Microsoft Entra ID. The app comes from the enterprise app name selected during the [pre-configuration steps](dynatrace-how-to-configure-prereqs.md).

-# Activate eligible Azure role assignments (Preview)

-> [!IMPORTANT]

-> Azure role assignment integration with Privileged Identity Management is currently in PREVIEW.

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

-You can have up to **4000** role assignments in each subscription. This limit includes role assignments at the subscription, resource group, and resource scopes. [Eligible role assignments](./role-assignments-portal.yml#step-6-select-assignment-type-(preview)) and role assignments scheduled in the future do not count towards this limit. You can have up to **500** role assignments in each management group. For more information, see [Troubleshoot Azure RBAC limits](troubleshoot-limits.md).

-## Integration with Privileged Identity Management (Preview)

-> [!IMPORTANT]

-> Azure role assignment integration with Privileged Identity Management is currently in PREVIEW.

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

-If you have a Microsoft Entra ID P2 or Microsoft Entra ID Governance license, [Microsoft Entra Privileged Identity Management (PIM)](/entra/id-governance/privileged-identity-management/pim-configure) is integrated into role assignment steps. For example, you can assign roles to users for a limited period of time. You can also make users eligible for role assignments so that they must activate to use the role, such as request approval. Eligible role assignments provide just-in-time access to a role for a limited period of time. You can't create eligible role assignments for applications, service principals, or managed identities because they can't perform the activation steps. You can create eligible role assignments at management group, subscription, and resource group scope, but not at resource scope. This capability is being deployed in stages, so it might not be available yet in your tenant or your interface might look different.

-The assignment type options available to you might vary depending or your PIM policy. For example, PIM policy defines whether permanent assignments can be created, maximum duration for time-bound assignments, roles activations requirements (approval, multifactor authentication, or Conditional Access authentication context), and other settings. For more information, see [Configure Azure resource role settings in Privileged Identity Management](/entra/id-governance/privileged-identity-management/pim-resource-roles-configure-role-settings).

-If you don't want to use the PIM functionality, select the **Active** assignment type and **Permanent** assignment duration options. These settings create a role assignment where the principal always has permissions in the role.

-To better understand PIM, you should review the following terms.

-| Term or concept | Role assignment category | Description |

-| | | |

-| eligible | Type | A role assignment that requires a user to perform one or more actions to use the role. If a user has been made eligible for a role, that means they can activate the role when they need to perform privileged tasks. There's no difference in the access given to someone with a permanent versus an eligible role assignment. The only difference is that some people don't need that access all the time. |

-| active | Type | A role assignment that doesn't require a user to perform any action to use the role. Users assigned as active have the privileges assigned to the role. |

-| activate | | The process of performing one or more actions to use a role that a user is eligible for. Actions might include performing a multifactor authentication (MFA) check, providing a business justification, or requesting approval from designated approvers. |

-| permanent eligible | Duration | A role assignment where a user is always eligible to activate the role. |

-| permanent active | Duration | A role assignment where a user can always use the role without performing any actions. |

-| time-bound eligible | Duration | A role assignment where a user is eligible to activate the role only within start and end dates. |

-| time-bound active | Duration | A role assignment where a user can use the role only within start and end dates. |

-| just-in-time (JIT) access | | A model in which users receive temporary permissions to perform privileged tasks, which prevents malicious or unauthorized users from gaining access after the permissions have expired. Access is granted only when users need it. |

-| principle of least privilege access | | A recommended security practice in which every user is provided with only the minimum privileges needed to accomplish the tasks they're authorized to perform. This practice minimizes the number of Global Administrators and instead uses specific administrator roles for certain scenarios. |

-For more information, see [What is Microsoft Entra Privileged Identity Management?](/entra/id-governance/privileged-identity-management/pim-configure).

-Azure supports up to **4000** role assignments per subscription. This limit includes role assignments at the subscription, resource group, and resource scopes, but not at the management group scope. [Eligible role assignments](./role-assignments-portal.yml#step-6-select-assignment-type-(preview)) and role assignments scheduled in the future do not count towards this limit. You should try to reduce the number of role assignments in the subscription.

-| [Distributed functions (preview)](./distributed-functions.md) for dynamic global distribution of backend compute. | Γ£ö | Γ£ò |

-> [!NOTE]

-> [Distributed functions](./distributed-functions.md) is available with managed functions. Distributed functions automatically distribute your managed functions to regions of high request loads.

-description: Configure dynamic distribution of your Static Web Apps managed functions to high request load regions.

-# Distributed managed functions in Azure Static Web Apps (preview)

-As requests to your APIs increase, you often want to distribute your APIs to the Azure regions getting the most demand. When you enable dynamic distribution, your API functions are automatically replicated to the regions closest to highest levels of incoming requests. For each request, Azure automatically directs traffic to the most appropriate region. Distributing your APIs reduces network latency and increases application performance and reliability of your static web app.

-Distributed functions are only available on the [Standard hosting plan](plans.md).

-Distributed functions can help reduce your network latency by up to 70%. Decreased network latency leads to improved performance and responsiveness of web applications with global audiences. Distributed functions can also improve application performance when quick response times are needed for responsive personalization, routing or authorization.

-Distributed functions only apply to the production environment of your static web app.

-> [!NOTE]

-> Distributed functions is not compatible with Next.js hybrid rendering applications.

-## Enable distributed functions

-Before enabling distributed functions, make sure your static web app is under the Standard hosting plan with managed functions.

-Use the following steps to enable distributed functions.

-1. Open your static web app in the Azure portal.

-

-1. From the *Settings* section, select **APIs**.

-1. Check the box labeled **Distributed functions**.

-1. Select **Confirm**.

-## Next steps

-> [!div class="nextstepaction"]

-> [Use preview environments](preview-environments.md)

-This article provides the release notes for Azure Container Storage. It's important to note that minor releases introduce new functionalities in a backward-compatible manner (for example, 1.1.0 GA). Patch releases focus on bug fixes, security updates, and smaller improvements (for example, 1.1.2).

-Minor versions introduce small improvements, performance enhancements, or minor new features without breaking existing functionality. For example, version 1.1.0 would move to 1.2.0. Patch versions are released more frequently than minor versions. They focus solely on bug fixes and security updates. For example, version 1.1.2 would be updated to 1.1.3.

-description: Learn about using managed identities in Azure Synapse.

-# Managed identity for Azure Synapse

-There are two types of supported managed identities:

-> System-assigned managed identity is also referred to as 'Managed identity' elsewhere in the documentation and in the Synapse Studio UI for backward compatibility purpose. We will explicitly mention 'User-assigned managed identity' when referring to it.

-#### Retrieve system-assigned managed identity using Azure portal

-You can find the managed identity information from Azure portal -> your Synapse workspace -> Properties.

-The managed identity information will also show up when you create linked service, which supports managed identity authentication, like Azure Blob, Azure Data Lake Storage, Azure Key Vault, etc.

-To grant permissions, follow these steps. For detailed steps, see [Assign Azure roles using the Azure portal](../role-based-access-control/role-assignments-portal.yml).

-1. Select **Access control (IAM)**.

-1. Select **Add** > **Add role assignment**.

- :::image type="content" source="~/reusable-content/ce-skilling/azure/media/role-based-access-control/add-role-assignment-menu-generic.png" alt-text="Screenshot that shows Access control (IAM) page with Add role assignment menu open.":::

-1. On the **Members** tab, select **Managed identity**, and then select **Select members**.

-1. Select your Azure subscription.

-1. Under **System-assigned managed identity**, select **Synapse workspace**, and then select a workspace. You can also use the object ID or workspace name (as the managed-identity name) to find this identity. To get the managed identity's application ID, use PowerShell.

-1. On the **Review + assign** tab, select **Review + assign** to assign the role.

-#### Retrieve system-assigned managed identity using PowerShell

-The managed identity principal ID and tenant ID will be returned when you get a specific service instance as follows. Use the **PrincipalId** to grant access:

-```powershell

-PS C:\> (Get-AzSynapseWorkspace -ResourceGroupName <resourceGroupName> -Name <workspaceName>).Identity

-IdentityType PrincipalId TenantId

- -- --

-SystemAssigned aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb aaaabbbb-0000-cccc-1111-dddd2222eeee

-```

-You can get the application ID by copying above principal ID, then running below Microsoft Entra ID command with principal ID as parameter.

-```powershell

-PS C:\> Get-AzADServicePrincipal -ObjectId aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb

-ServicePrincipalNames : {00001111-aaaa-2222-bbbb-3333cccc4444, https://identity.azure.net/P86P8g6nt1QxfPJx22om8MOooMf/Ag0Qf/nnREppHkU=}

-ApplicationId : 00001111-aaaa-2222-bbbb-3333cccc4444

-DisplayName : <workspaceName>

-Id : aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb

-Type : ServicePrincipal

-```

-#### Retrieve managed identity using REST API

-The managed identity principal ID and tenant ID will be returned when you get a specific service instance as follows.

-Call below API in the request:

-```

-GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Synapse/workspaces/{workspaceName}?api-version=2018-06-01

-```

-**Response**: You will get response like shown in below example. The "identity" section is populated accordingly.

-```json

-{

- "properties": {

- "defaultDataLakeStorage": {

- "accountUrl": "https://exampledatalakeaccount.dfs.core.windows.net",

- "filesystem": "examplefilesystem"

- },

- "encryption": {

- "doubleEncryptionEnabled": false

- },

- "provisioningState": "Succeeded",

- "connectivityEndpoints": {

- "web": "https://web.azuresynapse.net?workspace=%2fsubscriptions%2{subscriptionId}%2fresourceGroups%2f{resourceGroupName}%2fproviders%2fMicrosoft.Synapse%2fworkspaces%2f{workspaceName}",

- "dev": "https://{workspaceName}.dev.azuresynapse.net",

- "sqlOnDemand": "{workspaceName}-ondemand.sql.azuresynapse.net",

- "sql": "{workspaceName}.sql.azuresynapse.net"

- },

- "managedResourceGroupName": "synapseworkspace-managedrg-f77f7cf2-XXXX-XXXX-XXXX-c4cb7ac3cf4f",

- "sqlAdministratorLogin": "sqladminuser",

- "privateEndpointConnections": [],

- "workspaceUID": "e56f5773-XXXX-XXXX-XXXX-a0dc107af9ea",

- "extraProperties": {

- "WorkspaceType": "Normal",

- "IsScopeEnabled": false

- },

- "publicNetworkAccess": "Enabled",

- "cspWorkspaceAdminProperties": {

- "initialWorkspaceAdminObjectId": "3746a407-XXXX-XXXX-XXXX-842b6cf1fbcc"

- },

- "trustedServiceBypassEnabled": false

- },

- "type": "Microsoft.Synapse/workspaces",

- "id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Synapse/workspaces/{workspaceName}",

- "location": "eastus",

- "name": "{workspaceName}",

- "identity": {

- "type": "SystemAssigned",

- "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",

- "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222"

- },

- "tags": {}

-}

-```

-> [!TIP]

-> To retrieve the managed identity from an ARM template, add an **outputs** section in the ARM JSON:

-```json

-{

- "outputs":{

- "managedIdentityObjectId":{

- "type":"string",

- "value":"[reference(resourceId('Microsoft.Synapse/workspaces', parameters('<workspaceName>')), '2018-06-01', 'Full').identity.principalId]"

- }

- }

-}

-```

-### Execute Azure Synapse Spark Notebooks with system assigned managed identity

-You can create, delete, manage user-assigned managed identities in Microsoft Entra ID. For more details refer to [Create, list, delete, or assign a role to a user-assigned managed identity using the Azure portal](../active-directory/managed-identities-azure-resources/how-to-manage-ua-identity-portal.md).

-See the following topics that introduce when and how to use managed identity:

-description: In this article, learn how to route network traffic with a route table using the Azure CLI.

-# Customer intent: I want to route traffic from one subnet, to a different subnet, through a network virtual appliance.

-# Route network traffic with a route table using the Azure CLI

-Azure automatically routes traffic between all subnets within a virtual network, by default. You can create your own routes to override Azure's default routing. The ability to create custom routes is helpful if, for example, you want to route traffic between subnets through a network virtual appliance (NVA). In this article, you learn how to:

-* Create a route table

-* Create a route

-* Create a virtual network with multiple subnets

-* Associate a route table to a subnet

-* Create a basic NVA that routes traffic from an Ubuntu VM

-* Deploy virtual machines (VM) into different subnets

-* Route traffic from one subnet to another through an NVA

-## Create a route table

-Before you can create a route table, create a resource group with [az group create](/cli/azure/group) for all resources created in this article.

-```azurecli-interactive

-# Create a resource group.

-az group create \

- --name test-rg \

- --location westus2

-```

-Create a route table with [az network route-table create](/cli/azure/network/route-table#az-network-route-table-create). The following example creates a route table named *route-table-public*.

-```azurecli-interactive

-# Create a route table

-az network route-table create \

- --resource-group test-rg \

- --name route-table-public

-```

-## Create a route

-Create a route in the route table with [az network route-table route create](/cli/azure/network/route-table/route#az-network-route-table-route-create).

-```azurecli-interactive

-az network route-table route create \

- --name to-private-subnet \

- --resource-group test-rg \

- --route-table-name route-table-public \

- --address-prefix 10.0.1.0/24 \

- --next-hop-type VirtualAppliance \

- --next-hop-ip-address 10.0.2.4

-```

-## Associate a route table to a subnet

-Before you can associate a route table to a subnet, you have to create a virtual network and subnet. Create a virtual network with one subnet with [az network vnet create](/cli/azure/network/vnet).

-```azurecli-interactive

-az network vnet create \

- --name vnet-1 \

- --resource-group test-rg \

- --address-prefix 10.0.0.0/16 \

- --subnet-name subnet-public \

- --subnet-prefix 10.0.0.0/24

-```

-Create two more subnets with [az network vnet subnet create](/cli/azure/network/vnet/subnet).

-```azurecli-interactive

-# Create a private subnet.

-az network vnet subnet create \

- --vnet-name vnet-1 \

- --resource-group test-rg \

- --name subnet-private \

- --address-prefix 10.0.1.0/24

-# Create a DMZ subnet.

-az network vnet subnet create \

- --vnet-name vnet-1 \

- --resource-group test-rg \

- --name subnet-dmz \

- --address-prefix 10.0.2.0/24

-```

-Associate the *route-table-subnet-public* route table to the *subnet-public* subnet with [az network vnet subnet update](/cli/azure/network/vnet/subnet).

-```azurecli-interactive

-az network vnet subnet update \

- --vnet-name vnet-1 \

- --name subnet-public \

- --resource-group test-rg \

- --route-table route-table-public

-```

-## Create an NVA

-An NVA is a VM that performs a network function, such as routing, firewalling, or WAN optimization. We create a basic NVA from a general purpose Ubuntu VM, for demonstration purposes.

-Create a VM to be used as the NVA in the *subnet-dmz* subnet with [az vm create](/cli/azure/vm). When you create a VM, Azure creates and assigns a network interface *vm-nvaVMNic* and a subnet-public IP address to the VM, by default. The `--public-ip-address ""` parameter instructs Azure not to create and assign a subnet-public IP address to the VM, since the VM doesn't need to be connected to from the internet.

-The following example creates a VM and adds a user account. The `--generate-ssh-keys` parameter causes the CLI to look for an available ssh key in `~/.ssh`. If one is found, that key is used. If not, one is generated and stored in `~/.ssh`. Finally, we deploy the latest `Ubuntu 22.04` image.

-```azurecli-interactive

-az vm create \

- --resource-group test-rg \

- --name vm-nva \

- --image Ubuntu2204 \

- --public-ip-address "" \

- --subnet subnet-dmz \

- --vnet-name vnet-1 \

- --generate-ssh-keys

-```

-The VM takes a few minutes to create. Don't continue to the next step until Azure finishes creating the VM and returns output about the VM.

-For a network interface **vm-nvaVMNic** to be able to forward network traffic sent to it, that isn't destined for its own IP address, IP forwarding must be enabled for the network interface. Enable IP forwarding for the network interface with [az network nic update](/cli/azure/network/nic).

-```azurecli-interactive

-az network nic update \

- --name vm-nvaVMNic \

- --resource-group test-rg \

- --ip-forwarding true

-```

-Within the VM, the operating system, or an application running within the VM, must also be able to forward network traffic. We use the `sysctl` command to enable the Linux kernel to forward packets. To run this command without logging onto the VM, we use the [Custom Script extension](/azure/virtual-machines/extensions/custom-script-linux) [az vm extension set](/cli/azure/vm/extension):

-```azurecli-interactive

-az vm extension set \

- --resource-group test-rg \

- --vm-name vm-nva \

- --name customScript \

- --publisher Microsoft.Azure.Extensions \

- --settings '{"commandToExecute":"sudo sysctl -w net.ipv4.ip_forward=1"}'

-```

-The command might take up to a minute to execute. This change won't persist after a VM reboot, so if the NVA VM is rebooted for any reason, the script will need to be repeated.

-## Create virtual machines

-Create two VMs in the virtual network so you can validate that traffic from the *subnet-public* subnet is routed to the *subnet-private* subnet through the NVA in a later step.

-Create a VM in the *subnet-public* subnet with [az vm create](/cli/azure/vm). The `--no-wait` parameter enables Azure to execute the command in the background so you can continue to the next command.

-The following example creates a VM and adds a user account. The `--generate-ssh-keys` parameter causes the CLI to look for an available ssh key in `~/.ssh`. If one is found, that key is used. If not, one is generated and stored in `~/.ssh`. Finally, we deploy the latest `Ubuntu 22.04` image.

-```azurecli-interactive

-az vm create \

- --resource-group test-rg \

- --name vm-public \

- --image Ubuntu2204 \

- --vnet-name vnet-1 \

- --subnet subnet-public \

- --admin-username azureuser \

- --generate-ssh-keys \

- --no-wait

-```

-Create a VM in the *subnet-private* subnet.

-```azurecli-interactive

-az vm create \

- --resource-group test-rg \

- --name vm-private \

- --image Ubuntu2204 \

- --vnet-name vnet-1 \

- --subnet subnet-private \

- --admin-username azureuser \

- --generate-ssh-keys

-```

-The VM takes a few minutes to create. After the VM is created, the Azure CLI shows information similar to the following example:

-```output

-{

- "fqdns": "",

- "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/test-rg/providers/Microsoft.Compute/virtualMachines/vm-private",

- "location": "westus2",

- "macAddress": "00-0D-3A-23-9A-49",

- "powerState": "VM running",

- "privateIpAddress": "10.0.1.4",

- "publicIpAddress": "203.0.113.24",

- "resourceGroup": "test-rg"

-}

-```

-## Enable Microsoft Entra ID sign in for the virtual machines

-The following code example installs the extension to enable a Microsoft Entra ID sign-in for a Linux VM. VM extensions are small applications that provide post-deployment configuration and automation tasks on Azure virtual machines.

-```bash

-az vm extension set \

- --publisher Microsoft.Azure.ActiveDirectory \

- --name AADSSHsign-inForLinux \

- --resource-group test-rg \

- --vm-name vm-private

-```

-```bash

-az vm extension set \

- --publisher Microsoft.Azure.ActiveDirectory \

- --name AADSSHsign-inForLinux \

- --resource-group test-rg \

- --vm-name vm-public

-```

-## Route traffic through an NVA

-Using an SSH client of your choice, connect to the VMs created previously. For example, the following command can be used from a command line interface such as [Windows Subsystem for Linux](/windows/wsl/install) to create an SSH session with the *vm-private* VM. In the previous steps, we enabled Microsoft Entra ID sign-in for the VMs. You can sign-in to the virtual machines using your Microsoft Entra ID credentials or you can use the SSH key that you used to create the VMs. In the following example, we use the SSH key to sign-in to the VMs.

-For more information about how to SSH to a Linux VM and sign in with Microsoft Entra ID, see [Sign in to a Linux virtual machine in Azure by using Microsoft Entra ID and OpenSSH](/entra/identity/devices/howto-vm-sign-in-azure-ad-linux).

-```bash

-### Store IP address of VM in order to SSH

-Run the following command to store the IP address of the VM as an environment variable:

-```bash

-export IP_ADDRESS=$(az vm show --show-details --resource-group test-rg --name vm-private --query publicIps --output tsv)

-```

-```bash

-ssh -o StrictHostKeyChecking=no azureuser@$IP_ADDRESS

-```

-Use the following command to install trace route on the *vm-private* VM:

-```bash

-sudo apt update

-sudo apt install traceroute

-```

-Use the following command to test routing for network traffic to the *vm-public* VM from the *vm-private* VM.

-```bash

-traceroute vm-public

-```

-The response is similar to the following example:

-```output

-azureuser@vm-private:~$ traceroute vm-public

-traceroute to vm-public (10.0.0.4), 30 hops max, 60 byte packets

- 1 vm-public.internal.cloudapp.net (10.0.0.4) 2.613 ms 2.592 ms 2.553 ms

-```

-You can see that traffic is routed directly from the *vm-private* VM to the *vm-public* VM. Azure's default routes, route traffic directly between subnets. Close the SSH session to the *vm-private* VM.

-### Store IP address of VM in order to SSH

-Run the following command to store the IP address of the VM as an environment variable:

-```bash

-export IP_ADDRESS=$(az vm show --show-details --resource-group test-rg --name vm-public --query publicIps --output tsv)

-```

-```bash

-ssh -o StrictHostKeyChecking=no azureuser@$IP_ADDRESS

-```

-Use the following command to install trace route on the *vm-public* VM:

-```bash

-sudo apt update

-sudo apt install traceroute

-```

-Use the following command to test routing for network traffic to the *vm-private* VM from the *vm-public* VM.

-```bash

-traceroute vm-private

-```

-The response is similar to the following example:

-```output

-azureuser@vm-public:~$ traceroute vm-private

-traceroute to vm-private (10.0.1.4), 30 hops max, 60 byte packets

- 1 vm-nva.internal.cloudapp.net (10.0.2.4) 1.010 ms 1.686 ms 1.144 ms

- 2 vm-private.internal.cloudapp.net (10.0.1.4) 1.925 ms 1.911 ms 1.898 ms

-```

-You can see that the first hop is 10.0.2.4, which is the NVA's private IP address. The second hop is 10.0.1.4, the private IP address of the *vm-private* VM. The route added to the *route-table--public* route table and associated to the *subnet-public* subnet caused Azure to route the traffic through the NVA, rather than directly to the *subnet-private* subnet.

-Close the SSH session to the *vm-public* VM.

-## Clean up resources

-When no longer needed, use [az group delete](/cli/azure/group) to remove the resource group and all of the resources it contains.

-```azurecli-interactive

-az group delete \

- --name test-rg \

- --yes \

- --no-wait

-```

-## Next steps

-In this article, you created a route table and associated it to a subnet. You created a simple NVA that routed traffic from a subnet-public subnet to a private subnet. Deploy various preconfigured NVAs that perform network functions such as firewall and WAN optimization from the [Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps/category/networking). To learn more about routing, see [Routing overview](virtual-networks-udr-overview.md) and [Manage a route table](manage-route-table.yml).

-While you can deploy many Azure resources within a virtual network, resources for some Azure PaaS services can't be deployed into a virtual network. You can still restrict access to the resources of some Azure PaaS services to traffic only from a virtual network subnet though. To learn how, see [Restrict network access to PaaS resources](tutorial-restrict-network-access-to-resources-cli.md).

-description: In this article, learn how to route network traffic with a route table using PowerShell.

-# Customer intent: I want to route traffic from one subnet, to a different subnet, through a network virtual appliance.

-# Route network traffic with a route table using PowerShell

-Azure automatically routes traffic between all subnets within a virtual network, by default. You can create your own routes to override Azure's default routing. The ability to create custom routes is helpful if, for example, you want to route traffic between subnets through a network virtual appliance (NVA). In this article, you learn how to:

-* Create a route table

-* Create a route

-* Create a virtual network with multiple subnets

-* Associate a route table to a subnet

-* Create an NVA that routes traffic

-* Deploy virtual machines (VM) into different subnets

-* Route traffic from one subnet to another through an NVA

-If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-If you choose to install and use PowerShell locally, this article requires the Azure PowerShell module version 1.0.0 or later. Run `Get-Module -ListAvailable Az` to find the installed version. If you need to upgrade, see [Install Azure PowerShell module](/powershell/azure/install-azure-powershell). If you are running PowerShell locally, you also need to run `Connect-AzAccount` to create a connection with Azure.

-## Create a route table

-Before you can create a route table, create a resource group with [New-AzResourceGroup](/powershell/module/az.resources/new-azresourcegroup). The following example creates a resource group named *myResourceGroup* for all resources created in this article.

-```azurepowershell-interactive

-New-AzResourceGroup -ResourceGroupName myResourceGroup -Location EastUS

-```

-Create a route table with [New-AzRouteTable](/powershell/module/az.network/new-azroutetable). The following example creates a route table named *myRouteTablePublic*.

-```azurepowershell-interactive

-$routeTablePublic = New-AzRouteTable `

- -Name 'myRouteTablePublic' `

- -ResourceGroupName myResourceGroup `

- -location EastUS

-```

-## Create a route

-Create a route by retrieving the route table object with [Get-AzRouteTable](/powershell/module/az.network/get-azroutetable), create a route with [Add-AzRouteConfig](/powershell/module/az.network/add-azrouteconfig), then write the route configuration to the route table with [Set-AzRouteTable](/powershell/module/az.network/set-azroutetable).

-```azurepowershell-interactive

-Get-AzRouteTable `

- -ResourceGroupName "myResourceGroup" `

- -Name "myRouteTablePublic" `

- | Add-AzRouteConfig `

- -Name "ToPrivateSubnet" `

- -AddressPrefix 10.0.1.0/24 `

- -NextHopType "VirtualAppliance" `

- -NextHopIpAddress 10.0.2.4 `

- | Set-AzRouteTable

-```

-## Associate a route table to a subnet

-Before you can associate a route table to a subnet, you have to create a virtual network and subnet. Create a virtual network with [New-AzVirtualNetwork](/powershell/module/az.network/new-azvirtualnetwork). The following example creates a virtual network named *myVirtualNetwork* with the address prefix *10.0.0.0/16*.

-```azurepowershell-interactive

-$virtualNetwork = New-AzVirtualNetwork `

- -ResourceGroupName myResourceGroup `

- -Location EastUS `

- -Name myVirtualNetwork `

- -AddressPrefix 10.0.0.0/16

-```

-Create three subnets by creating three subnet configurations with [New-AzVirtualNetworkSubnetConfig](/powershell/module/az.network/new-azvirtualnetworksubnetconfig). The following example creates three subnet configurations for *Public*, *Private*, and *DMZ* subnets:

-```azurepowershell-interactive

-$subnetConfigPublic = Add-AzVirtualNetworkSubnetConfig `

- -Name Public `

- -AddressPrefix 10.0.0.0/24 `

- -VirtualNetwork $virtualNetwork

-$subnetConfigPrivate = Add-AzVirtualNetworkSubnetConfig `

- -Name Private `

- -AddressPrefix 10.0.1.0/24 `

- -VirtualNetwork $virtualNetwork

-$subnetConfigDmz = Add-AzVirtualNetworkSubnetConfig `

- -Name DMZ `

- -AddressPrefix 10.0.2.0/24 `

- -VirtualNetwork $virtualNetwork

-```

-Write the subnet configurations to the virtual network with [Set-AzVirtualNetwork](/powershell/module/az.network/Set-azVirtualNetwork), which creates the subnets in the virtual network:

-```azurepowershell-interactive

-$virtualNetwork | Set-AzVirtualNetwork

-```

-Associate the *myRouteTablePublic* route table to the *Public* subnet with [Set-AzVirtualNetworkSubnetConfig](/powershell/module/az.network/set-azvirtualnetworksubnetconfig) and then write the subnet configuration to the virtual network with [Set-AzVirtualNetwork](/powershell/module/az.network/set-azvirtualnetwork).

-```azurepowershell-interactive

-Set-AzVirtualNetworkSubnetConfig `

- -VirtualNetwork $virtualNetwork `

- -Name 'Public' `

- -AddressPrefix 10.0.0.0/24 `

- -RouteTable $myRouteTablePublic | `

-Set-AzVirtualNetwork

-```

-## Create an NVA

-An NVA is a VM that performs a network function, such as routing, firewalling, or WAN optimization.

-Before creating a VM, create a network interface.

-### Create a network interface

-Before creating a network interface, you have to retrieve the virtual network Id with [Get-AzVirtualNetwork](/powershell/module/az.network/get-azvirtualnetwork), then the subnet Id with [Get-AzVirtualNetworkSubnetConfig](/powershell/module/az.network/get-azvirtualnetworksubnetconfig). Create a network interface with [New-AzNetworkInterface](/powershell/module/az.network/new-aznetworkinterface) in the *DMZ* subnet with IP forwarding enabled:

-```azurepowershell-interactive

-# Retrieve the virtual network object into a variable.

-$virtualNetwork=Get-AzVirtualNetwork `

- -Name myVirtualNetwork `

- -ResourceGroupName myResourceGroup

-# Retrieve the subnet configuration into a variable.

-$subnetConfigDmz = Get-AzVirtualNetworkSubnetConfig `

- -Name DMZ `

- -VirtualNetwork $virtualNetwork

-# Create the network interface.

-$nic = New-AzNetworkInterface `

- -ResourceGroupName myResourceGroup `

- -Location EastUS `

- -Name 'myVmNva' `

- -SubnetId $subnetConfigDmz.Id `

- -EnableIPForwarding

-```

-### Create a VM

-To create a VM and attach an existing network interface to it, you must first create a VM configuration with [New-AzVMConfig](/powershell/module/az.compute/new-azvmconfig). The configuration includes the network interface created in the previous step. When prompted for a username and password, select the user name and password you want to log into the VM with.

-```azurepowershell-interactive

-# Create a credential object.

-$cred = Get-Credential -Message "Enter a username and password for the VM."

-# Create a VM configuration.

-$vmConfig = New-AzVMConfig `

- -VMName 'myVmNva' `

- -VMSize Standard_DS2 | `

- Set-AzVMOperatingSystem -Windows `

- -ComputerName 'myVmNva' `

- -Credential $cred | `

- Set-AzVMSourceImage `

- -PublisherName MicrosoftWindowsServer `

- -Offer WindowsServer `

- -Skus 2016-Datacenter `

- -Version latest | `

- Add-AzVMNetworkInterface -Id $nic.Id

-```

-Create the VM using the VM configuration with [New-AzVM](/powershell/module/az.compute/new-azvm). The following example creates a VM named *myVmNva*.

-```azurepowershell-interactive

-$vmNva = New-AzVM `

- -ResourceGroupName myResourceGroup `

- -Location EastUS `

- -VM $vmConfig `

- -AsJob

-```

-The `-AsJob` option creates the VM in the background, so you can continue to the next step.

-## Create virtual machines

-Create two VMs in the virtual network so you can validate that traffic from the *Public* subnet is routed to the *Private* subnet through the network virtual appliance in a later step.

-Create a VM in the *Public* subnet with [New-AzVM](/powershell/module/az.compute/new-azvm). The following example creates a VM named *myVmPublic* in the *Public* subnet of the *myVirtualNetwork* virtual network.

-```azurepowershell-interactive

-New-AzVm `

- -ResourceGroupName "myResourceGroup" `

- -Location "East US" `

- -VirtualNetworkName "myVirtualNetwork" `

- -SubnetName "Public" `

- -ImageName "Win2016Datacenter" `

- -Name "myVmPublic" `

- -AsJob

-```

-Create a VM in the *Private* subnet.

-```azurepowershell-interactive

-New-AzVm `

- -ResourceGroupName "myResourceGroup" `

- -Location "East US" `

- -VirtualNetworkName "myVirtualNetwork" `

- -SubnetName "Private" `

- -ImageName "Win2016Datacenter" `

- -Name "myVmPrivate"

-```

-The VM takes a few minutes to create. Don't continue with the next step until the VM is created and Azure returns output to PowerShell.

-## Route traffic through an NVA

-Use [Get-AzPublicIpAddress](/powershell/module/az.network/get-azpublicipaddress) to return the public IP address of the *myVmPrivate* VM. The following example returns the public IP address of the *myVmPrivate* VM:

-```azurepowershell-interactive

-Get-AzPublicIpAddress `

- -Name myVmPrivate `

- -ResourceGroupName myResourceGroup `

- | Select IpAddress

-```

-Use the following command to create a remote desktop session with the *myVmPrivate* VM from your local computer. Replace `<publicIpAddress>` with the IP address returned from the previous command.

-```

-mstsc /v:<publicIpAddress>

-```

-Open the downloaded RDP file. If prompted, select **Connect**.

-Enter the user name and password you specified when creating the VM (you may need to select **More choices**, then **Use a different account**, to specify the credentials you entered when you created the VM), then select **OK**. You may receive a certificate warning during the sign-in process. Select **Yes** to proceed with the connection.

-In a later step, the `tracert.exe` command is used to test routing. Tracert uses the Internet Control Message Protocol (ICMP), which is denied through the Windows Firewall. Enable ICMP through the Windows firewall by entering the following command from PowerShell on the *myVmPrivate* VM:

-```powershell

-New-NetFirewallRule -DisplayName "Allow ICMPv4-In" -Protocol ICMPv4

-```

-Though trace route is used to test routing in this article, allowing ICMP through the Windows Firewall for production deployments is not recommended.

-You enabled IP forwarding within Azure for the VM's network interface in Enable IP forwarding. Within the VM, the operating system, or an application running within the VM, must also be able to forward network traffic. Enable IP forwarding within the operating system of the *myVmNva*.

-From a command prompt on the *myVmPrivate* VM, remote desktop to the *myVmNva*:

-```

-mstsc /v:myvmnva

-```

-To enable IP forwarding within the operating system, enter the following command in PowerShell from the *myVmNva* VM:

-```powershell

-Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name IpEnableRouter -Value 1

-```

-Restart the *myVmNva* VM, which also disconnects the remote desktop session.

-While still connected to the *myVmPrivate* VM, create a remote desktop session to the *myVmPublic* VM, after the *myVmNva* VM restarts:

-```

-mstsc /v:myVmPublic

-```

-Enable ICMP through the Windows firewall by entering the following command from PowerShell on the *myVmPublic* VM:

-```powershell

-New-NetFirewallRule ΓÇôDisplayName "Allow ICMPv4-In" ΓÇôProtocol ICMPv4

-```

-To test routing of network traffic to the *myVmPrivate* VM from the *myVmPublic* VM, enter the following command from PowerShell on the *myVmPublic* VM:

-```

-tracert myVmPrivate

-```

-The response is similar to the following example:

-```

-Tracing route to myVmPrivate.vpgub4nqnocezhjgurw44dnxrc.bx.internal.cloudapp.net [10.0.1.4]

-over a maximum of 30 hops:

-1 <1 ms * 1 ms 10.0.2.4

-2 1 ms 1 ms 1 ms 10.0.1.4

-Trace complete.

-```

-You can see that the first hop is 10.0.2.4, which is the NVA's private IP address. The second hop is 10.0.1.4, the private IP address of the *myVmPrivate* VM. The route added to the *myRouteTablePublic* route table and associated to the *Public* subnet caused Azure to route the traffic through the NVA, rather than directly to the *Private* subnet.

-Close the remote desktop session to the *myVmPublic* VM, which leaves you still connected to the *myVmPrivate* VM.

-To test routing of network traffic to the *myVmPublic* VM from the *myVmPrivate* VM, enter the following command from a command prompt on the *myVmPrivate* VM:

-```

-tracert myVmPublic

-```

-The response is similar to the following example:

-```

-Tracing route to myVmPublic.vpgub4nqnocezhjgurw44dnxrc.bx.internal.cloudapp.net [10.0.0.4]

-over a maximum of 30 hops:

-1 1 ms 1 ms 1 ms 10.0.0.4

-Trace complete.

-```

-You can see that traffic is routed directly from the *myVmPrivate* VM to the *myVmPublic* VM. By default, Azure routes traffic directly between subnets.

-Close the remote desktop session to the *myVmPrivate* VM.

-## Clean up resources

-When no longer needed, use [Remove-AzResourcegroup](/powershell/module/az.resources/remove-azresourcegroup) to remove the resource group and all of the resources it contains.

-```azurepowershell-interactive

-Remove-AzResourceGroup -Name myResourceGroup -Force

-```

-## Next steps

-In this article, you created a route table and associated it to a subnet. You created a simple network virtual appliance that routed traffic from a public subnet to a private subnet. Deploy a variety of pre-configured network virtual appliances that perform network functions such as firewall and WAN optimization from the [Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps/category/networking). To learn more about routing, see [Routing overview](virtual-networks-udr-overview.md) and [Manage a route table](manage-route-table.yml).

-While you can deploy many Azure resources within a virtual network, resources for some Azure PaaS services cannot be deployed into a virtual network. You can still restrict access to the resources of some Azure PaaS services to traffic only from a virtual network subnet though. To learn how, see [Restrict network access to PaaS resources](tutorial-restrict-network-access-to-resources-powershell.md).

-You can also create this type of P2S VPN Gateway configuration using the steps for the new [Microsoft-registered VPN Client app](point-to-site-entra-gateway.md). Using the newer version bypasses the steps to register the Azure VPN Client with your Microsoft Entra tenant. It also supports more client operating systems. However, it might not yet support certain audience values. For more information about point-to-site protocols and authentication, see [About VPN Gateway point-to-site VPN](point-to-site-about.md).

-* For frequently asked questions, see the **Point-to-site** section of the [VPN Gateway FAQ](vpn-gateway-vpn-faq.md#P2S).

-VPN gateways begins with a VNet migration from classic to Resource Manager. This migration is done by customers one VNet at a time. There aren't additional requirements in terms of tools or prerequisites to begin the VNet migration. Migration steps are identical to the existing VNet migration and are documented at [IaaS resources migration page](/azure/virtual-machines/migration-classic-resource-manager-ps).