Super Simple .NET Run Program.cs
June 22, 2025
Why Azure Load Testing Matters for Integration
Azure Load Testing is a key service for running performance and stress tests in an integrated cloud. When deploying Azure Load testing, the governance around Azure metrics and fine-grained cost control is important. The pay-as-you-go model lets teams easily monitor separate billing reports, and future landing zone support with virtual network (VNET) integration and private endpoints further enhances enterprise security and scalability.
Key benefits for (enterprise) integration:
- Direct integration with Azure metrics
- Pay-as-you-go billing with clear cost visibility
- Support for VNET integration and private endpoints
- Potential to incorporate landing zones for standardised deployments
Cost Control and Granularity
In larger (enterprise) environments, it is often necessary to manage Azure Load Testing instances in a way that balances team autonomy with strong governance and cost control. This typically involves:
- Centrally managing Azure Load Testing instances for multiple teams (optional)
- Implementing resource tagging for billing visibility
- Restricting permissions to specific test cases
- Protecting against large bills caused by accidental misuse
Resource creation
You could decide that each team would have its own Azure Load Testing instance, all provisioned centrally. Below is a sample Azure Bicep script demonstrating how to create a resource group and an Azure Load Test resource for each team. The foreach function iterates over a list of teams:
@description('List of load tests to create')
param loadTests array = [
{ teamname: 'teamname1' }
{ teamname: 'teamname2' }
]
@description('Azure region for deployment')
param location string = 'uksouth'
// Create a resource group for each team
resource resourceGroups 'Microsoft.Resources/resourceGroups@2021-04-01' = [
for item in loadTests: {
name: 'prefix-loadtest-${item.teamname}'
location: location
}
]
// Deploy the Azure Load Test instance for each team
module azureLoadTest 'br/public:avm/res/load-test-service/load-test:0.4.2' = [
for item in loadTests: {
name: 'loadTestDeploy-${item.teamname}'
scope: resourceGroup('prefix-loadtest-${item.teamname}')
params: {
name: 'prefix-loadtest-${item.teamname}'
location: location
}
dependsOn: [
resourceGroups
]
}
]Billing Protection
Using a pre-created Azure Load Testing instance for each team helps isolate billing to those teams. Azure charges are based on Virtual User Hours (VUH):
- 10 users for 6 minutes = 1 VUH
- 2 users for 30 minutes = 1 VUH
You can set a monthly limit on each team’s VUH usage to avoid unexpected costs. Although setting these limits is currently only available via the REST API, you can integrate this with your Bicep deployments by using an inline Azure PowerShell script. Here is an example:
resource deploymentScript 'Microsoft.Resources/deploymentScripts@2023-08-01' = {
name: 'inlinePS'
location: ''
kind: 'AzurePowerShell'
properties: {
azPowerShellVersion: '10.0'
scriptContent: '''
$token = Get-AzAccessToken
$accessToken = $token.Token
$headers = @{ 'Authorization' = 'Bearer ' + $accessToken; 'Content-Type' = 'application/json' }
$body = @{ 'limit' = }
$uri = "https://management.azure.com/subscriptions//resourcegroups//providers/microsoft.loadtestservice/loadtests//limits/maxMonthlyVirtualUserHours/set?api-version=2024-12-01-preview"
Invoke-RestMethod -Uri $uri -Method Post -Headers $headers -Body ($body | ConvertTo-Json)
'''
retentionInterval: 'PT1H'
}
identity: {
type: 'UserAssigned'
userAssignedIdentities: {
'': {}
}
}
}RBAC Access
Once the usage limits are in place, you can control who can change them by configuring Role-Based Access Control (RBAC). For instance, assigning the Load Test Contributor role lets team members view, create, edit, or delete tests and test runs, but does not allow them to update VUH limits. This separation of duties helps maintain tight governance in an enterprise environment.
Restrict Creation of Load Testing
To prevent teams from creating unauthorised Azure Load Testing instances outside your shared service model, you can use Azure Policy. Below is a sample policy that denies creating new Load Testing resources:
{
"mode": "All",
"policyRule": {
"if": {
"field": "type",
"equals": "Microsoft.LoadTestService/loadTests"
},
"then": {
"effect": "deny"
}
},
"parameters": {}
}This policy ensures new instances can only be deployed through approved processes, improving governance and cost control.
Conclusion
By following the guidelines above and using a combination of Azure Bicep, DevOps practices, and strict governance policies, you can effectively deploy Azure Load Testing for enterprise environments, while managing costs, ensuring appropriate access, and supporting future expansion or landing zone integration.
The post Azure Load Testing at Scale: Governance Essentials Made Easy first appeared on AzureTechInsider.
