Test private endpoints by deploying Azure Load Testing in an Azure virtual network

In this article, learn how to test private application endpoints with Azure Load Testing Preview. You'll create an Azure Load Testing resource and enable it to generate load from within your virtual network (VNET injection).

This functionality enables the following usage scenarios:

  • Generate load to an endpoint that is deployed in an Azure virtual network.
  • Generate load to a public endpoint with access restrictions, such as restricting client IP addresses.
  • Generate load to an on-premises service, not publicly accessible, that is connected to Azure via ExpressRoute.

Learn more about the scenarios for deploying Azure Load Testing in your virtual network.

The following diagram provides a technical overview:

Diagram that shows the Azure Load Testing VNET injection technical overview.

When you start the load test, Azure Load Testing service injects the following Azure resources in the virtual network that contains the application endpoint:

  • The test engine virtual machines. These VMs will invoke your application endpoint during the load test.
  • A public IP address.
  • A network security group (NSG).
  • An Azure Load Balancer.

These resources are ephemeral and exist only during the load test run. If you restrict access to your virtual network, you need to configure your virtual network to enable communication between these Azure Load Testing and the injected VMs.

Note

Virtual network support for Azure Load Testing is available in the following Azure regions: Australia East, East US, East US 2, North Europe, South Central US, UK South, and West US 2.

Important

Azure Load Testing is currently in preview. For legal terms that apply to Azure features that are in beta, in preview, or otherwise not yet released into general availability, see the Supplemental Terms of Use for Microsoft Azure Previews.

Prerequisites

  • An existing virtual network and a subnet to use with Azure Load Testing.
  • The virtual network must be in the same subscription and the same region as the Azure Load Testing resource.
  • The virtual network address range cannot overlap with 172.29.0.0/30, the address range that Azure Load Testing uses.
  • You require the Network Contributor role, or a parent of this role, on the virtual network. See Check access for a user to Azure resources to verify your permissions.
  • The subnet you use for Azure Load Testing must have enough unassigned IP addresses to accommodate the number of load test engines for your test. Learn more about configuring your test for high-scale load.
  • The subnet shouldn't be delegated to any other Azure service. For example, it shouldn't be delegated to Azure Container Instances (ACI). Learn more about subnet delegation.
  • Azure CLI version 2.2.0 or later (if you're using CI/CD). Run az --version to find the version that's installed on your computer. If you need to install or upgrade the Azure CLI, see How to install the Azure CLI.

Configure your virtual network

To test private endpoints, you need an existing Azure virtual network. Your virtual network should have at least one subnet, and allow access for traffic coming from the Azure Load Testing service.

Create a subnet

When you deploy Azure Load Testing in your virtual network, it's recommended to use separate subnets for Azure Load Testing and for the application endpoint. This approach enables you to configure network traffic access policies specifically for each purpose. Learn more about how to add a subnet to a virtual network.

Configure traffic access

Azure Load Testing requires both inbound and outbound access for the injected VMs in your virtual network. If you plan to restrict traffic access to your virtual network, or if you're already using a network security group, configure the network security group for the subnet in which you deploy the load test.

  1. Go to the Azure portal.

  2. If you don't have an NSG yet, follow these steps to create a network security group.

    Create the NSG in the same region as your virtual network, and then associate it with your subnet.

  3. Search for and select your network security group.

  4. Select Inbound security rules in the left navigation.

  5. Select + Add, to add a new inbound security rule. Enter the following information to create a new rule, and then select Add.

    Field Value
    Source Service Tag
    Source service tag BatchNodeManagement
    Source port ranges *
    Destination Any
    Destination port ranges 29876-29877
    Name batch-node-management-inbound
    Description Create, update, and delete of Azure Load Testing compute instances.
  6. Add a second inbound security rule using the following information:

    Field Value
    Source Service Tag
    Source service tag AzureLoadTestingInstanceManagement
    Source port ranges *
    Destination Any
    Destination port ranges 8080
    Name azure-load-testing-inbound
    Description Create, update, and delete of Azure Load Testing compute instances.
  7. Select Outbound security rules in the left navigation.

  8. Select + Add, to add a new outbound security rule. Enter the following information to create a new rule, and then select Add.

    Field Value
    Source Any
    Source port ranges *
    Destination Any
    Destination port ranges *
    Name azure-load-testing-outbound
    Description Used for various operations involved in orchestrating a load tests.

Configure your load test script

The test engine VMs, which run the JMeter script, are injected in the virtual network that contains the application endpoint. You can now refer directly to the endpoint in the JMX file by using the private IP address or use name resolution in your network.

For example, for an endpoint with IP address 10.179.0.7, in a virtual network with subnet range 10.179.0.0/18, the JMX file could have this information:

<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="Internal service homepage" enabled="true">
  <elementProp name="HTTPsampler.Arguments" elementType="Arguments" guiclass="HTTPArgumentsPanel" testclass="Arguments" testname="Service homepage" enabled="true">
    <collectionProp name="Arguments.arguments"/>
  </elementProp>
  <stringProp name="HTTPSampler.domain">10.179.0.7</stringProp>
  <stringProp name="HTTPSampler.port">8081</stringProp>
  <stringProp name="HTTPSampler.protocol"></stringProp>
  <stringProp name="HTTPSampler.contentEncoding"></stringProp>
  <stringProp name="HTTPSampler.path"></stringProp>
  <stringProp name="HTTPSampler.method">GET</stringProp>
</HTTPSamplerProxy>

Configure your load test

To include privately hosted endpoints in your load test, you need to configure the virtual network settings for the load test. You can configure the VNET settings in the Azure portal, or specify them in the YAML test configuration file for CI/CD pipelines.

Important

When you deploy Azure Load Testing in a virtual network, you'll incur additional charges. Azure Load Testing deploys an Azure Load Balancer and a Public IP address in your subscription and there might be a cost for generated traffic. For more information, see the Virtual Network pricing information.

Configure the VNET in the Azure portal

You can specify the VNET configuration settings in the load test creation/update wizard.

  1. Sign in to the Azure portal by using the credentials for your Azure subscription.

  2. Go to your Azure Load Testing resource, and select Tests from the left pane.

  3. Open the load test creation/update wizard in either of two ways:

    • Select + Create > Upload a JMeter script, if you want to create a new test.

      Screenshot that shows the Tests page, highlighting the button for creating a new test.

    • Select an existing test from the list, and then select Edit.

      Screenshot that shows the Tests page, highlighting the button for editing a test.

  4. On the Load tab, select Private traffic mode, and then select your virtual network and subnet.

    If you have multiple subnets in your virtual network, make sure to select the subnet that will host the injected test engine VMs.

    Screenshot that shows the Load tab for creating or updating a load test.

    Important

    Make sure you have sufficient permissions for managing virtual networks. You require the Network Contributor role.

  5. Review or fill the load test information. Follow these steps to create or manage a test.

  6. Select Review + create and then Create (or Apply, when updating an existing test).

    When the load test starts, Azure Load Testing injects the test engine VMs in your virtual network and subnet. The test script can now access the privately hosted application endpoint in your VNET.

Configure the VNET for CI/CD pipelines

To configure the load test with your virtual network settings, update the YAML test configuration file.

  1. Open a terminal, and use the Azure CLI to sign in to your Azure subscription:

    az login
    az account set --subscription <your-Azure-Subscription-ID>
    
  2. Retrieve the subnet ID and copy the resulting value:

    az network vnet subnet show -g <your-resource-group> --vnet-name <your-vnet-name> --name <your-subnet-name> --query id
    
  3. Open your YAML test configuration file in your favorite editor.

  4. Add the subnetId property to the configuration file and provide the subnet ID you copied earlier:

    version: v0.1
    testName: SampleTest
    testPlan: SampleTest.jmx
    description: 'Load test the website home page'
    engineInstances: 1
    subnetId: <your-subnet-id>
    

    For more information about the YAML configuration, see test configuration YAML reference.

    Important

    Make sure you have sufficient permissions for managing virtual networks. You require the Network Contributor role.

  5. Save the YAML configuration file, and commit your changes to the source code repository.

  6. After the CI/CD workflow triggers, your load test starts, and can now access the privately hosted application endpoint in your VNET.

Troubleshooting

Creating or updating the load test fails with Subscription not registered with Microsoft.Batch (ALTVNET001)

When you configure a load test in a virtual network, the subscription has to be registered with Microsoft.Batch.

  1. Try to create or update the load test again after a few minutes.

  2. If the error persists, follow these steps to register your subscription with the Microsoft.Batch resource provider manually.

Creating or updating the load test fails with Subnet is not in the Succeeded state (ALTVNET002)

The subnet you're using for the load test isn't in the Succeeded state and isn't ready to deploy your load test into it.

  1. Verify the state of the subnet.

    Run the following Azure CLI command to verify the state. The result should be Succeeded.

    az network vnet subnet show -g MyResourceGroup -n MySubnet --vnet-name MyVNet
    
  2. Resolve any issues with the subnet. If you've just created the subnet, verify the state again after a few minutes.

  3. Alternately, select another subnet for the load test.

Create or updating the load test fails with Subnet is delegated to other service (ALTVNET003)

The subnet you use for deploying the load test can't be delegated to another Azure service. Either remove the existing delegation, or select another subnet that is not delegated to a service.

Learn more about adding or removing a subnet delegation.

Starting the load test fails with User doesn't have subnet/join/action permission on the virtual network (ALTVNET004)

To start a load test, you must have sufficient permissions to deploy Azure Load Testing to the virtual network. You require the Network Contributor role, or a parent of this role, on the virtual network.

  1. See Check access for a user to Azure resources to verify your permissions.

  2. Follow these steps to assign the Network Contributor role to your account.

Creating or updating the load test fails with IPv6 enabled subnet not supported (ALTVNET005)

Azure Load Testing doesn't support IPv6 enabled subnets. Select another subnet for which IPv6 isn't enabled.

Creating or updating the load test fails with NSG attached to subnet is not in Succeeded state (ALTVNET006)

The network security group (NSG) that is attached to the subnet isn't in the Succeeded state.

  1. Verify the state of the NSG.

    Run the following Azure CLI command to verify the state. The result should be Succeeded.

    az network nsg show -g MyResourceGroup -n MyNsg
    
  2. Resolve any issues with the NSG. If you've just created the NSG or subnet, verify the state again after a few minutes.

  3. Alternately, select another NSG.

Creating or updating the load test fails with Route Table attached to subnet is not in Succeeded state (ALTVNET007)

The route table attached to the subnet isn't in the Succeeded state.

  1. Verify the state of the route table.

    Run the following Azure CLI command to verify the state. The result should be Succeeded.

    az network route-table show -g MyResourceGroup -n MyRouteTable
    
  2. Resolve any issues with the route table. If you've just created the route table or subnet, verify the state again after a few minutes.

  3. Alternately, select another route table.

Creating or updating the load test fails with Inbound not allowed from AzureLoadTestingInstanceManagement service tag (ALTVNET008)

Inbound access from the AzureLoadTestingInstanceManagement service tag to the virtual network isn't allowed.

Follow these steps to enable traffic access for the AzureLoadTestingInstanceManagement service tag.

Creating or updating the load test fails with Inbound not allowed from BatchNodeManagement service tag (ALTVNET009)

Inbound access from the BatchNodeManagement service tag to the virtual network isn't allowed.

Follow these steps to enable inbound access for the BatchNodeManagement service tag.

Creating or updating the load test fails with Route Table has next hop set for address prefix 0.0.0.0/0

Your subnet route table has the next hop set type set to Virtual appliance for route 0.0.0.0/0. This configuration would cause asymmetric routing for network packets while provisioning the virtual machines in the subnet.

Perform either of two actions to resolve this error:

  • Use a different subnet, which doesn't have custom routes.
  • Modify the subnet route table and set the next hop type for route 0.0.0.0/0 to Internet.

Learn more about virtual network traffic routing.

Creating or updating the load test fails with Subnet is in a different subscription than resource (ALTVNET011)

The virtual network isn't in the same subscription and region as your Azure load testing resource. Either move or recreate the Azure virtual network or the Azure load testing resource to the same subscription and region.

Provisioning fails with An azure policy is restricting engine deployment to your subscription (ALTVNET012)

An Azure policy is restricting load test engine deployment to your subscription. Check your policy restrictions and try again.

Provisioning fails with Engines could not be deployed due to an error in subnet configuration (ALTVNET013)

The load test engine instances couldn't be deployed due to an error in the subnet configuration. Verify your subnet configuration. If the issue persists, raise a ticket with support along with the run ID of the test.

  1. Verify the state of the subnet.

    Run the following Azure CLI command to verify the state. The result should be Succeeded.

    az network vnet subnet show -g MyResourceGroup -n MySubnet --vnet-name MyVNet
    
  2. Resolve any issues with the subnet. If you've just created the subnet, verify the state again after a few minutes.

  3. If the problem persists, open an online customer support request.

    Provide the load test run ID within the support request.

Starting the load test fails with Subnet has {0} free IPs, {1} more free IP(s) required to run {2} engine instance load test (ALTVNET014)

The subnet you use for Azure Load Testing must have enough unassigned IP addresses to accommodate the number of load test engines for your test.

Follow these steps to update the subnet settings and increase the IP address range.

Next steps