Azure compute and storage

Virtual machines

An Azure Virtual Machine is the same idea as an EC2 instance: you pick an image (Ubuntu, Windows Server), a size, a disk and a network, and you manage the operating system. Sizes are grouped into families by the job they do best.

Read a size name like Standard_D2s_v5 as: family D, 2 vCPUs, s means it can use premium SSD disks, v5 is the generation. There are also N (GPU), L (storage) and M (very large memory) families. Sizes and prices change often and differ by region, so check the current sizes page before you choose.

Staying up: availability sets and zones

An availability set spreads your VMs across fault domains (separate racks with their own power and network switch) and update domains (groups that Azure restarts one at a time during maintenance), all within one datacentre. Availability zones go further: VMs in different zones sit in different buildings with separate power and cooling. Zones protect against a whole datacentre failing; sets do not. For the exact uptime SLAs (for example two or more VMs across zones), check the current Azure SLA page.

A Virtual Machine Scale Set manages a group of similar VMs. It can add VMs when CPU is high and remove them at night (autoscale), and it can spread them across zones. It is the Azure match for an AWS Auto Scaling group.

App Service and Container Apps

Azure App Service is platform as a service (PaaS) for web apps and APIs in .NET, Java, Node.js, Python or PHP, or in a container. You push code and Azure handles the servers, patching and load balancing. The App Service plan sets the region, operating system, size and number of instances; several apps can share one plan. Higher tiers add features such as autoscale, deployment slots (a staging copy you swap into production) and private networking; check the docs for which tier has what.

az webapp up --name canteen-api-asha --resource-group rg-demo \
  --location centralindia --runtime "PYTHON:3.12" --sku B1

Azure Container Apps runs containers without you managing Kubernetes. It scales on HTTP traffic or queue length, can scale to zero, and keeps revisions so you can split traffic between versions. Containers are covered properly in a later module.

Storage accounts

A storage account is the container for Azure Storage data. Its name must be 3 to 24 lower-case letters and numbers and unique across all of Azure, because it becomes part of the address, such as https://stcanteen01.blob.core.windows.net. One general-purpose v2 account offers four services:

• Blob storage: objects such as images, videos, backups and logs (like Amazon S3).
• Azure Files: file shares over SMB or NFS that many machines can mount (like Amazon EFS or FSx).
• Queue storage: simple message queues between parts of an app.
• Table storage: a simple key and attribute NoSQL store.

Add RA- (read access), as in RA-GRS, if you want to read from the secondary region even before a failover.

Blob access tiers

Storage price and access price pull in opposite directions. Hot has the highest storage price and the lowest cost to read. Cool, Cold and Archive are cheaper to store but cost more to read, and they have a minimum retention period: if you delete or move a blob earlier, you pay an early deletion charge for the remaining days.

Archive is offline. To read an archived blob you rehydrate it to Hot, Cool or Cold, which can take up to about 15 hours at standard priority (high priority is faster for small blobs). Check the access tiers page for current details and prices. Lifecycle management policies move blobs between tiers automatically, for example to Cool after 30 days and Archive after 180.

{
  "rules": [
    {
      "enabled": true,
      "name": "age-out-reports",
      "type": "Lifecycle",
      "definition": {
        "filters": { "blobTypes": ["blockBlob"], "prefixMatch": ["reports/"] },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
            "delete": { "daysAfterModificationGreaterThan": 2555 }
          }
        }
      }
    }
  ]
}

Sharing safely with SAS tokens

A shared access signature (SAS) is a signed URL that grants limited access, such as read-only on one blob for two hours. Prefer a user delegation SAS, which is signed with Entra ID credentials instead of the account key. Keep SAS lifetimes short, give only the permissions needed, and use HTTPS only.

az storage blob generate-sas --account-name stcanteen01 \
  --container-name reports --name 2026-10.pdf \
  --permissions r --expiry 2026-10-20T18:00Z \
  --auth-mode login --as-user --https-only --full-uri