VM Scale Sets for auto scaling in Azure - Commands & Configuration
provider "azurerm" { features {} } resource "azurerm_resource_group" "example" { name = "example-resources" location = "East US" } resource "azurerm_virtual_network" "example" { name = "example-vnet" address_space = ["10.0.0.0/16"] location = azurerm_resource_group.example.location resource_group_name = azurerm_resource_group.example.name } resource "azurerm_subnet" "example" { name = "example-subnet" resource_group_name = azurerm_resource_group.example.name virtual_network_name = azurerm_virtual_network.example.name address_prefixes = ["10.0.1.0/24"] } resource "azurerm_linux_virtual_machine_scale_set" "example" { name = "example-vmss" location = azurerm_resource_group.example.location resource_group_name = azurerm_resource_group.example.name sku = "Standard_DS1_v2" instances = 2 admin_username = "azureuser" source_image_reference { publisher = "Canonical" offer = "UbuntuServer" sku = "18.04-LTS" version = "latest" } os_disk { caching = "ReadWrite" storage_account_type = "Standard_LRS" } network_interface { name = "example-nic" primary = true ip_configuration { name = "internal" subnet_id = azurerm_subnet.example.id primary = true } } automatic_instance_repair { enabled = true grace_period = "PT10M" } upgrade_mode = "Manual" } resource "azurerm_monitor_autoscale_setting" "example" { name = "example-autoscale" resource_group_name = azurerm_resource_group.example.name target_resource_id = azurerm_linux_virtual_machine_scale_set.example.id profile { name = "autoscale-profile" capacity { minimum = "1" maximum = "5" default = "2" } rule { metric_trigger { metric_name = "Percentage CPU" metric_resource_id = azurerm_linux_virtual_machine_scale_set.example.id time_grain = "PT1M" statistic = "Average" time_window = "PT5M" time_aggregation = "Average" operator = "GreaterThan" threshold = 75 } scale_action { direction = "Increase" type = "ChangeCount" value = "1" cooldown = "PT5M" } } rule { metric_trigger { metric_name = "Percentage CPU" metric_resource_id = azurerm_linux_virtual_machine_scale_set.example.id time_grain = "PT1M" statistic = "Average" time_window = "PT5M" time_aggregation = "Average" operator = "LessThan" threshold = 30 } scale_action { direction = "Decrease" type = "ChangeCount" value = "1" cooldown = "PT5M" } } } }
This Terraform file creates a resource group and a virtual network with a subnet to host the virtual machines.
The azurerm_linux_virtual_machine_scale_set resource defines a scale set with 2 Ubuntu VMs, automatic repair enabled, and manual upgrade mode.
The azurerm_monitor_autoscale_setting resource sets up auto scaling rules based on CPU usage: it adds a VM if average CPU goes above 75% and removes one if it falls below 30%, with cooldown periods to avoid rapid changes.
terraform init
terraform apply -auto-approve
-auto-approve - Skip manual approval to apply changes immediatelyaz vmss list-instances --resource-group example-resources --name example-vmss --output table
--output table - Display output in a readable table formataz monitor autoscale show --resource-group example-resources --name example-autoscale
If you remember nothing else from this pattern, remember: VM Scale Sets let you automatically add or remove virtual machines based on demand to keep your app responsive and cost-efficient.
Practice
Solution
Step 1: Understand VM Scale Sets function
VM Scale Sets allow running multiple VMs that can increase or decrease automatically.Step 2: Identify the main benefit
This automatic adjustment helps handle changes in workload efficiently.Final Answer:
To automatically adjust the number of virtual machines based on demand -> Option CQuick Check:
Auto scaling = Adjust VM count [OK]
- Confusing VM Scale Sets with storage services
- Thinking it manages user permissions
- Assuming it creates only one VM
Solution
Step 1: Identify correct metric and operator
The autoscale rule should trigger when CPU usage is greater than 70%, so metric 'Percentage CPU' and operator 'GreaterThan' are correct.Step 2: Confirm action to add instances
The rule must add instances when the condition is met, not decrease or use wrong metrics.Final Answer:
Set a rule to add instances when CPU > 70% using metric 'Percentage CPU' and operator 'GreaterThan' with threshold 70 -> Option AQuick Check:
CPU > 70% triggers add instances [OK]
- Using 'LessThan' instead of 'GreaterThan'
- Confusing CPU with memory metrics
- Setting decrease action instead of add
{
"metricTrigger": {
"metricName": "Percentage CPU",
"operator": "GreaterThan",
"threshold": 80
},
"scaleAction": {
"direction": "Increase",
"value": "2"
}
}What happens when CPU usage goes above 80%?
Solution
Step 1: Analyze metric trigger
The rule triggers when CPU usage is greater than 80%.Step 2: Analyze scale action
The action is to increase the VM count by 2 instances.Final Answer:
The VM Scale Set increases by 2 instances -> Option BQuick Check:
CPU > 80% triggers increase by 2 [OK]
- Confusing increase with decrease
- Ignoring the value number
- Assuming default increase of 1
Solution
Step 1: Check metric name correctness
If the metric name is wrong, the rule never triggers because it can't read CPU usage.Step 2: Verify other options
Direction 'Decrease' would scale down, threshold 10 is too low but would still trigger, and initial instances are usually at least one.Final Answer:
The metric name is misspelled or incorrect -> Option AQuick Check:
Wrong metric name blocks scaling [OK]
- Setting wrong scale direction
- Ignoring metric name spelling
- Assuming zero initial instances
Solution
Step 1: Confirm instance limits
The requirement is minimum 3 and maximum 10 instances, so only Set minimum 3, maximum 10 instances; add 2 when CPU > 75%; remove 1 when CPU < 30% matches this.Step 2: Check autoscale rules
Set minimum 3, maximum 10 instances; add 2 when CPU > 75%; remove 1 when CPU < 30% adds 2 instances when CPU > 75% and removes 1 when CPU < 30%, exactly as required.Final Answer:
Set minimum 3, maximum 10 instances; add 2 when CPU > 75%; remove 1 when CPU < 30% -> Option DQuick Check:
Limits and rules match requirements [OK]
- Mixing up CPU thresholds for add/remove
- Setting wrong min or max instance counts
- Reversing scale directions
Ready to prove it?
Pass the test and this pattern moves unknown
