Deploy and manage Azure compute resources

ARM templates and Bicep

An ARM template is declarative JSON deployed through Azure Resource Manager. Bicep is a cleaner language that compiles to ARM JSON. Both are idempotent: deploying twice gives the same result.

ARM template structure

• dependsOn or a reference()/resourceId() call sets ordering; Resource Manager otherwise deploys in parallel. copy loops (copyIndex()) create several instances; condition makes a resource optional.
• Common functions: concat, resourceGroup().location, uniqueString(resourceGroup().id), resourceId, reference, parameters, variables.
• Deployment mode: Incremental (default) adds or updates resources in the template and leaves others alone. Complete also deletes resources in the group that aren’t in the template.
• Scopes: resource group, subscription, management group, tenant. Pick the matching CLI command.
• Template specs store versioned templates in Azure for sharing with RBAC; linked/nested templates or Bicep modules split large files.
• What-if previews the change before deploying.

az deployment group create -g rg-app --template-file main.bicep --parameters env=prod
az deployment group what-if -g rg-app --template-file main.bicep
az deployment sub create -l westeurope --template-file sub.json
az group export -n rg-app > exported.json
az deployment group export -g rg-app -n deploy1

New-AzResourceGroupDeployment -ResourceGroupName rg-app -TemplateFile main.bicep -env prod
Export-AzResourceGroup -ResourceGroupName rg-app

Bicep

param location string = resourceGroup().location
param storageName string
@allowed(['Standard_LRS','Standard_GRS'])
param sku string = 'Standard_LRS'

resource st 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageName
  location: location
  sku: { name: sku }
  kind: 'StorageV2'
}
output endpoint string = st.properties.primaryEndpoints.blob

• Elements: param, var, resource, module, output, existing (reference an existing resource), for loops, if conditions, decorators (@secure(), @allowed, @minLength).
• Dependencies are implicit when one resource references another’s symbolic name. Use dependsOn only when no reference exists.
• Convert: az bicep decompile --file template.json (ARM to Bicep, best effort and may need fixes) and az bicep build --file main.bicep (Bicep to ARM). In the portal use Export template on a resource, group or a deployment (the deployment export contains only what that deployment created).
• Interpret and modify questions: change a parameter default, add a dependsOn, switch a mode, add a tag, fix a wrong apiVersion or resource type string. Resource type format is Microsoft.Provider/type.

Virtual machines

Creating a VM

Decisions: Region, availability option, image (marketplace, custom image, Azure Compute Gallery), size, authentication (SSH key or password), disks, networking (VNet, subnet, public IP, NSG), management (boot diagnostics, managed identity, auto-shutdown).

az vm create -g rg-vm -n vm1 --image Ubuntu2204 --size Standard_D2s_v5 \
  --admin-username azureuser --generate-ssh-keys --zone 1 \
  --vnet-name vnet1 --subnet snet1 --public-ip-address "" --nsg nsg1

New-AzVM -ResourceGroupName rg-vm -Name vm1 -Location westeurope -Image Win2022AzureEditionCore -Size Standard_D2s_v5 -Credential (Get-Credential)

• The VM’s NIC, disks and public IP are separate resources. Deleting a VM leaves its disks, NIC and public IP unless delete options were set.
• Stopped (Deallocated) releases compute so you stop paying for the VM (disks still cost). Shutting down from inside the OS leaves it Stopped (still allocated and billed). Dynamic public IPs and non-reserved private IPs can change after deallocation.
• Management features: Run command, custom script extension, Azure Automation, auto-shutdown, Update Manager, Serial console, boot diagnostics, redeploy (moves to a new host), reapply.

Sizes

• Families: B (burstable), D (general purpose), E (memory-optimised), F (compute-optimised), L (storage), M (large memory), N (GPU), H (HPC).
• Resize: if the new size is available on the current hardware cluster, the VM restarts. Otherwise you must deallocate first, which may change its dynamic IP. Resizing is blocked when the target size isn’t available in the Region or zone, or your vCPU quota is too low (raise via a quota request). Resizing doesn’t change the OS disk contents. Spot VMs offer discounts but can be evicted.

Disks

• Managed disks abstract the storage account. Resize a disk up only (never shrink). Resizing a data disk may need the VM deallocated (not for all types). After resizing, extend the partition in the guest OS.
• Disk snapshots (full or incremental) and images capture state. An unattached disk can be attached to another VM.
• Shared disks let a disk attach to multiple VMs for clustering.
• Disk encryption:
  • Server-side encryption (SSE) with platform-managed keys is default and always on. Option for customer-managed keys through a disk encryption set backed by Key Vault.
  • Encryption at host encrypts temp disk and caches too, from the VM host to storage.
  • Azure Disk Encryption (ADE) uses BitLocker (Windows) or dm-crypt (Linux) inside the guest, with keys in Key Vault. The vault must be in the same Region and subscription as the VM and have “Azure Disk Encryption for volume encryption” enabled (and soft delete/purge protection recommended). ADE isn’t supported on some VM series and images, and it can’t be combined with encryption at host on the same VM.
  • Confidential disk encryption is for confidential VMs.

az keyvault update -n kv1 -g rg --enabled-for-disk-encryption true
az vm encryption enable -g rg-vm -n vm1 --disk-encryption-keyvault kv1 --volume-type All
az vm encryption show -g rg-vm -n vm1

Moving a VM

Some resources can’t move (for example VMs backed up with a Recovery Services vault need handling of the backup first, and VNets with some gateways). Moving between subscriptions needs write on both sides.

Availability

• Availability set: fault domains (up to 3, separate power and network) and update domains (up to 20, planned maintenance). Set at creation; you can’t add an existing VM to a set without recreating (redeploy through snapshot/re-create). Each set must be in a single Region and can’t be combined with zones on the same VM.
• Availability zones are physically separate zones (1, 2, 3). Choose a zone at creation. Zonal services: VM. Zone-redundant services: load balancer (Standard), ZRS storage, zone-redundant gateways.
• Proximity placement groups put VMs physically close for low latency (at the cost of resilience).

Virtual machine scale sets (VMSS)

• Deploys and manages a group of load-balanced VMs from one model, scales automatically, and spreads across zones and fault domains.
• Orchestration modes: Flexible (recommended, mixes VM sizes, regular VMs, zones, up to 1,000) and Uniform (identical VMs, optimised for large stateless scale, up to 1,000, or 600 for custom images). Flexible is the default for new scale sets.
• Autoscale: metric-based rules (CPU %, memory via the agent, queue length), scheduled scale, minimum/maximum/default instance count, cooldown (default 5 minutes). Scale out and in rules should be a pair with a gap to avoid flapping. Autoscale on predictive can pre-provision.
• Scale-in policy: Default (balance across zones/fault domains, then highest ID), NewestVM, OldestVM.
• Upgrade policy (Uniform): Manual, Automatic, Rolling. Rolling uses batches and health probes. Changing the model doesn’t affect existing instances under Manual until you upgrade them.
• Attach a Standard load balancer or Application Gateway, and an instance repairs policy for health-based replacement.
• Custom script extension and cloud-init install apps on each instance; images from an Azure Compute Gallery keep them consistent.

az vmss create -g rg-vmss -n vmss1 --image Ubuntu2204 --instance-count 2 --vm-sku Standard_D2s_v5 \
  --zones 1 2 3 --orchestration-mode Flexible --lb lb1
az monitor autoscale create -g rg-vmss --resource vmss1 --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name auto1 --min-count 2 --max-count 10 --count 2
az monitor autoscale rule create -g rg-vmss --autoscale-name auto1 --condition "Percentage CPU > 70 avg 5m" --scale out 2

Containers

Azure Container Registry (ACR)

• Private registry for container images and OCI artifacts (Helm charts). Registry name is globally unique, name.azurecr.io.
• SKUs: Basic, Standard, Premium. Premium adds geo-replication, private link, customer-managed keys, content trust, zone redundancy, higher storage and throughput.
• Auth: Entra ID (az acr login), service principal, managed identity (with AcrPull, AcrPush roles), repository-scoped tokens, and the admin user (single shared credential; disabled by default, avoid).
• ACR Tasks build images in Azure (az acr build), trigger on commit or base image update.

az acr create -g rg-c -n contosoacr --sku Premium
az acr build -r contosoacr -t app:v1 .
az acr login -n contosoacr
docker push contosoacr.azurecr.io/app:v1

Azure Container Instances (ACI)

• Run a container (or a container group that shares network, storage and lifecycle, similar to a Kubernetes pod) with no servers to manage and per-second billing.
• Set CPU and memory per container, restart policy (Always, OnFailure, Never), OS (Linux, Windows), environment variables (secure variables), a public IP with DNS label or VNet deployment (private IP, dedicated delegated subnet), and volumes: Azure Files share, emptyDir, secret, git repo.
• No built-in autoscale or load balancing. Scale by creating more groups. Use for batch jobs, simple tasks, bursts. Changing CPU or memory means recreating the group.

az container create -g rg-c -n web1 --image mcr.microsoft.com/azuredocs/aci-helloworld --cpu 1 --memory 1.5 \
  --dns-name-label contoso-web1 --ports 80 --restart-policy OnFailure

Azure Container Apps

• Serverless container platform on Kubernetes (KEDA, Dapr, Envoy under the hood) without managing a cluster. Apps run in an environment (shared VNet and logging) with a Consumption or Dedicated (workload profile) plan.
• Revisions are immutable snapshots of an app version. Single revision mode (default) swaps traffic to the newest; multiple revision mode enables traffic splitting for blue-green and A/B.
• Ingress: external or internal, HTTP or TCP, target port, automatic HTTPS and custom domains.
• Scaling is driven by KEDA scale rules: HTTP concurrent requests, TCP connections, CPU, memory, and event sources such as Azure Queue or Service Bus length. Set min replicas (0 enables scale to zero) and max replicas (up to 1,000). CPU and memory are set per container and constrained by plan allowed combinations.
• Jobs run to completion (manual, scheduled, event-driven).

az containerapp env create -g rg-c -n env1 -l westeurope
az containerapp create -g rg-c -n app1 --environment env1 --image contosoacr.azurecr.io/app:v1 \
  --target-port 80 --ingress external --min-replicas 0 --max-replicas 10 --scale-rule-name http --scale-rule-type http --scale-rule-http-concurrency 50

Azure App Service

Plans

• An App Service plan defines the compute (region, OS, size, pricing tier) shared by all apps in it. Scale up means a bigger plan or tier; scale out means more instances. Billing is per plan, not per app.

• Windows and Linux apps can’t share one plan, and the plan sets the Region. You can move apps between plans within the same resource group, Region and OS.
• Moving the plan or deleting it affects all apps. A plan must be empty to be deleted by some paths.

az appservice plan create -g rg-web -n plan1 --sku P1V3 --is-linux
az webapp create -g rg-web -p plan1 -n contoso-web1 --runtime "NODE:20-lts"
az appservice plan update -g rg-web -n plan1 --number-of-workers 3
az monitor autoscale create -g rg-web --resource plan1 --resource-type Microsoft.Web/serverFarms --min-count 1 --max-count 5 --count 1

Scaling

• Manual instance count, autoscale rules on metrics (CPU, memory, HTTP queue) or schedule (Standard and above), and automatic scaling (Premium, pre-warmed instances). Scale rules apply to the plan, so all apps scale together. Always On keeps an app loaded (Basic and up) and avoids cold starts; ARR affinity sticks a client to one instance.

Deployment slots

• Standard and above. A slot is a live app with its own hostname (app-staging.azurewebsites.net), sharing the plan’s resources.
• Swap exchanges slots (warm-up first, then switches routing), giving near-zero downtime and an instant rollback by swapping back. Slot settings (sticky/deployment slot setting) stay with the slot (connection strings for staging database); other settings travel with the app.
• Traffic routing: send a percentage of production traffic to a slot for testing in production. Swap with preview applies target-slot settings first so you can validate before completing.
• Content, WebJobs and config swap, but the slot’s custom domain names and certificates don’t.

az webapp deployment slot create -g rg-web -n contoso-web1 --slot staging
az webapp deployment slot swap -g rg-web -n contoso-web1 --slot staging --target-slot production
az webapp traffic-routing set -g rg-web -n contoso-web1 --distribution staging=10

Custom domain, certificates and TLS

• Custom domains need Basic or higher for TLS. Verify ownership with DNS:
  • Subdomain (www): CNAME to app.azurewebsites.net plus asuid.www TXT with the domain verification ID.
  • Apex/root (contoso.com): A record to the app’s inbound IP plus an asuid TXT record (an alias record is possible in Azure DNS).
• Certificates: App Service Managed Certificate (free, auto-renewed, no wildcard, not exportable), App Service Certificate (purchased, stored in Key Vault), import from Key Vault, upload a PFX (private key, password, with the full chain). Public cert (.cer) is for outbound use by the app.
• Create a TLS/SSL binding to the hostname: SNI SSL (most clients, free) or IP-based SSL (dedicated IP).
• Settings: HTTPS Only redirects HTTP to HTTPS; Minimum TLS version (1.2 recommended); client certificate mode.

Backup

• Standard tier and above (custom backups). Backs up app content, configuration, and linked databases (such as Azure SQL, MySQL) into a storage account container you specify. Manual or scheduled, with retention (0 = keep forever) and a size limit of about 10 GB of content plus database. Restore overwrites an existing app or creates a new one (restore into a slot is supported).
• Automatic platform backups are hourly with 30-day retention and aren’t customisable.

Networking

• Inbound: access restrictions (allow/deny IP or subnet rules, service tags, with the main site and SCM site separate), private endpoint (private IP for incoming traffic, needs Basic+ and DNS), service endpoints to restrict by subnet.
• Outbound: regional VNet integration needs a dedicated delegated subnet (Microsoft.Web/serverFarms), outbound only (the app reaches resources in the VNet and via peering; it doesn’t get inbound private access). With it, Route All sends all outbound traffic through the VNet (NSGs, UDRs and NAT gateway apply). Hybrid Connections reach on-prem TCP endpoints via a relay without a VPN.
• Don’t confuse the two directions: private endpoint = inbound, VNet integration = outbound.