What is the difference between Uniform and Flexible orchestration?

Uniform orchestration manages identical VM instances based on a VM profile — all VMs use the same image, size, and configuration. It is optimized for large-scale stateless workloads. Flexible orchestration lets you mix VM sizes, use individually created VMs, and spread instances across availability zones and fault domains with more granular control. Flexible mode supports features like adding existing VMs to the scale set and per-instance configuration overrides. Microsoft recommends Flexible orchestration for new deployments, and Uniform is being superseded over time.

How do autoscale rules handle flapping?

Flapping occurs when scale-out and scale-in rules trigger alternately, constantly adding and removing instances. Azure mitigates this with cooldown periods — after a scale action, the autoscaler waits for the cooldown duration before evaluating rules again. Set the scale-in cooldown longer than scale-out to allow new instances to warm up and stabilize metrics. Additionally, use different thresholds for scale-out and scale-in (e.g., scale out at 75% CPU, scale in at 40%) to create a deadband that prevents oscillation.

VM Scale Set Config Builder

ComputeAzure

Build VM Scale Set autoscaling rules, upgrade policies, and instance repair.

Last verified: May 2026

VM Scale Sets Configuration

Build VM Scale Set auto-scaling configs with upgrade policies, repair policies, and scheduled profiles.

Required Fields

nameresourceGroupsku.namesku.capacityautoscaleSettingsautoscaleSettings.minCountautoscaleSettings.maxCount

{
  "name": "vmss-web-prod",
  "resourceGroup": "rg-compute",
  "location": "eastus2",
  "sku": {
    "name": "Standard_D4s_v5",
    "tier": "Standard",
    "capacity": 3
  },
  "orchestrationMode": "Flexible",
  "platformFaultDomainCount": 3,
  "upgradePolicy": {
    "mode": "Rolling",
    "rollingUpgradePolicy": {
      "maxBatchInstancePercent": 20,
      "maxUnhealthyInstancePercent": 20,
      "maxUnhealthyUpgradedInstancePercent": 20,
      "pauseTimeBetweenBatches": "PT2S"
    }
  },
  "automaticRepairsPolicy": {
    "enabled": true,
    "gracePeriod": "PT30M",
    "repairAction": "Replace"
  },
  "scaleInPolicy": {
    "rules": ["OldestVM"],
    "forceDeletion": false
  },
  "autoscaleSettings": {
    "enabled": true,
    "minCount": 2,
    "maxCount": 10,
    "defaultCount": 3,
    "rules": [
      {
        "metricName": "Percentage CPU",
        "metricResourceUri": "[resourceId]",
        "timeGrain": "PT1M",
        "statistic": "Average",
        "timeWindow": "PT10M",
        "timeAggregation": "Average",
        "operator": "GreaterThan",
        "threshold": 75,
        "direction": "Increase",
        "type": "ChangeCount",
        "value": 1,
        "cooldown": "PT5M"
      },
      {
        "metricName": "Percentage CPU",
        "metricResourceUri": "[resourceId]",
        "timeGrain": "PT1M",
        "statistic": "Average",
        "timeWindow": "PT10M",
        "timeAggregation": "Average",
        "operator": "LessThan",
        "threshold": 25,
        "direction": "Decrease",
        "type": "ChangeCount",
        "value": 1,
        "cooldown": "PT5M"
      }
    ],
    "scheduledProfiles": [
      {
        "name": "weekday-peak",
        "capacity": { "minimum": 4, "maximum": 15, "default": 6 },
        "recurrence": {
          "frequency": "Week",
          "days": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
          "hours": [8],
          "minutes": [0]
        }
      }
    ]
  },
  "networkProfile": {
    "subnetId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-networking/providers/Microsoft.Network/virtualNetworks/vnet-prod/subnets/snet-web",
    "loadBalancerBackendPoolIds": ["/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-networking/providers/Microsoft.Network/loadBalancers/lb-web-prod/backendAddressPools/bepool-web"]
  },
  "identity": {
    "type": "SystemAssigned"
  }
}

Generated Output

Output will appear here...

About This Tool

Azure Virtual Machine Scale Sets (VMSS) let you deploy and manage a set of identical, auto-scaling VMs behind a load balancer. Configuration involves selecting the orchestration mode (Uniform for identical instances or Flexible for mixed configurations), defining autoscale rules based on metrics like CPU or custom metrics, setting upgrade policies (automatic, rolling, or manual), and configuring instance repair policies for automatic replacement of unhealthy VMs. The VMSS Config Builder helps you define scaling rules, upgrade policies, health probes, and instance protection settings for production-grade scale sets.

Real-World Scenario

Your team has been running 30 always-on VMs to handle peak traffic that lasts only 4 hours/day. The builder generates a VMSS Flexible config with: min=5, max=30, target tracking on CPU at 60%. Scale-in cooldown 10 min, scale-out cooldown 5 min. Instance repair on with 30-min grace. The fleet now runs at avg ~12 instances during off-peak, scales to 25 during morning rush. Monthly cost drops from $2,400 (30 always-on) to ~$1,000. Plus, the auto-repair feature catches a stuck instance once a week that previously went unnoticed for hours.

When to Use This Tool

•Configuring auto-scale rules that scale out based on CPU utilization and scale in based on memory pressure with different thresholds
•Setting up rolling upgrade policies with max batch percentage, pause time, and automatic rollback on failure
•Building instance repair policies that automatically replace VMs that fail health probe checks

Pro Tips

TIP

Flexible orchestration is the right choice for new VMSS deployments in 2026. Uniform mode is being superseded — Microsoft is investing all new features in Flexible. Migrating existing Uniform VMSSs is non-trivial; greenfield Flexible avoids that future migration.

TIP

Set scale-out threshold lower than scale-in threshold by AT LEAST 30 percentage points. Scale out at 75% CPU, scale in at 40% — anything narrower causes oscillation as new instances briefly drop the avg below the scale-in threshold. The 'deadband' between thresholds is your stability margin.

TIP

Instance repair policies are the underused VMSS feature. Enable automatic repair with a 30-minute grace period after a health probe fails. The scale set replaces the unhealthy instance automatically — eliminating the all-too-common 'one bad instance is silently serving 500s for hours because no one noticed' incident.

How It Works Under the Hood

The builder constructs Azure VMSS configurations: orchestration mode (Uniform or Flexible), VM profile (size, image, OS disk, networking, identity), autoscale settings (min/default/max instances, autoscale rules with metric/threshold/direction/cooldown), upgrade policy (manual/rolling/automatic with batch settings), and instance repair policy (enabled, grace period). Output is generated as az vmss + az monitor autoscale commands and Terraform azurerm_linux_virtual_machine_scale_set / azurerm_windows_virtual_machine_scale_set + autoscale_setting resources.

Frequently Asked Questions

What is the difference between Uniform and Flexible orchestration?: Uniform orchestration manages identical VM instances based on a VM profile — all VMs use the same image, size, and configuration. It is optimized for large-scale stateless workloads. Flexible orchestration lets you mix VM sizes, use individually created VMs, and spread instances across availability zones and fault domains with more granular control. Flexible mode supports features like adding existing VMs to the scale set and per-instance configuration overrides. Microsoft recommends Flexible orchestration for new deployments, and Uniform is being superseded over time.
How do autoscale rules handle flapping?: Flapping occurs when scale-out and scale-in rules trigger alternately, constantly adding and removing instances. Azure mitigates this with cooldown periods — after a scale action, the autoscaler waits for the cooldown duration before evaluating rules again. Set the scale-in cooldown longer than scale-out to allow new instances to warm up and stabilize metrics. Additionally, use different thresholds for scale-out and scale-in (e.g., scale out at 75% CPU, scale in at 40%) to create a deadband that prevents oscillation.

Related Learning Guides

Azure VM Series Guide22 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.