Azure Essentials

Core Structure: Tenants, Subscriptions, Resource Groups

Everything in Azure hangs off a hierarchy: an Azure AD (Entra ID) tenant contains one or more subscriptions (billing + access boundary), and every subscription contains resource groups — logical containers for resources that share a lifecycle. You almost never deploy a resource directly into a subscription; it goes into a resource group, and deleting the group deletes everything in it. Resources also always live in a region (e.g. eastus, westeurope), which affects latency, pricing, and data residency compliance.

• Management group — optional top layer above subscriptions, for applying policy/RBAC across many subscriptions at once

• Subscription — billing boundary and default scope for quotas/limits

• Resource group — logical container, unit of deployment and deletion; resources within it can span regions

• Region / Availability Zone — a region is a geography (e.g. East US); Availability Zones are physically separate datacenters within a region for high availability

# az CLI — login and set active subscription
az login
az account list --output table
az account set --subscription "Production"

# Create a resource group (region choice matters — pick close to users)
az group create --name my-app-rg --location eastus

# List everything in a resource group
az resource list --resource-group my-app-rg --output table

# Delete a resource group and everything inside it (irreversible)
az group delete --name my-app-rg --yes --no-wait

Compute: VMs & App Service

Azure Virtual Machines give you full OS-level control (IaaS) — pick when you need custom OS configuration, licensed software, or lift-and-shift from on-prem. App Service is Azure's PaaS for web apps and APIs — you deploy code or a container and Azure handles the OS, patching, scaling, and load balancing. For most new web workloads, App Service is the faster path; reach for VMs only when App Service's constraints (supported runtimes, no root access) don't fit.

# Virtual Machine — quick create
az vm create \
  --resource-group my-app-rg \
  --name web-vm-1 \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys

az vm open-port --resource-group my-app-rg --name web-vm-1 --port 443
az vm start --resource-group my-app-rg --name web-vm-1
az vm deallocate --resource-group my-app-rg --name web-vm-1   # stop billing for compute

# App Service — PaaS web app, no VM management
az appservice plan create \
  --name my-app-plan \
  --resource-group my-app-rg \
  --sku B1 \
  --is-linux

az webapp create \
  --resource-group my-app-rg \
  --plan my-app-plan \
  --name my-unique-app-name \
  --runtime "NODE:20-lts"

az webapp config appsettings set \
  --resource-group my-app-rg \
  --name my-unique-app-name \
  --settings DATABASE_URL="postgres://..." NODE_ENV=production

az webapp deployment source config-zip \
  --resource-group my-app-rg \
  --name my-unique-app-name \
  --src dist.zip

Storage

One storage account can host multiple service types: Blob Storage for unstructured files (images, backups, static assets — the equivalent of S3), Table Storage for schemaless NoSQL key-value data, Queue Storage for simple messaging, and Azure Files for SMB/NFS file shares. Blob has three access tiers (hot/cool/archive) trading retrieval speed for cost — archive can take hours to rehydrate, so it's only for long-term cold data.

az storage account create \
  --name myappstorage001 \
  --resource-group my-app-rg \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2

az storage container create --account-name myappstorage001 --name uploads --auth-mode login

az storage blob upload \
  --account-name myappstorage001 \
  --container-name uploads \
  --name report.pdf \
  --file ./report.pdf \
  --auth-mode login

# Move cold data to the archive tier to cut storage cost
az storage blob set-tier \
  --account-name myappstorage001 \
  --container-name uploads \
  --name old-report.pdf \
  --tier Archive

Networking: VNets

A Virtual Network (VNet) is your private, isolated network within Azure — resources inside it communicate over private IPs by default. Subnets divide a VNet into segments (e.g. a subnet for web tier, one for database tier), and Network Security Groups (NSGs) act as stateful firewalls filtering inbound/outbound traffic per subnet or network interface. VNet peering connects two VNets (even across subscriptions) with private, low-latency routing — no gateway or public internet involved.

az network vnet create \
  --resource-group my-app-rg \
  --name my-vnet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name web-subnet \
  --subnet-prefix 10.0.1.0/24

az network nsg create --resource-group my-app-rg --name web-nsg

az network nsg rule create \
  --resource-group my-app-rg \
  --nsg-name web-nsg \
  --name allow-https \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --destination-port-ranges 443

az network vnet subnet update \
  --resource-group my-app-rg \
  --vnet-name my-vnet \
  --name web-subnet \
  --network-security-group web-nsg

Identity & Access: Azure AD (Entra ID), IAM

Azure AD (rebranded Microsoft Entra ID) is the identity provider behind every Azure login and app authentication flow. Access to resources is controlled by Azure RBAC — role assignments that bind a security principal (user, group, or service identity) to a role definition (what actions are allowed) at a scope (management group, subscription, resource group, or single resource). Prefer built-in roles like Reader, Contributor, and Owner over custom roles unless you have a real least-privilege gap, and prefer Managed Identities over storing service credentials for app-to-Azure-resource auth.

# Grant a user Contributor on a resource group
az role assignment create \
  --assignee user@company.com \
  --role "Contributor" \
  --scope /subscriptions/<sub-id>/resourceGroups/my-app-rg

# System-assigned managed identity for a web app — no secrets to manage
az webapp identity assign \
  --resource-group my-app-rg \
  --name my-unique-app-name

# Grant that identity read access to a Key Vault, no client secret needed
az keyvault set-policy \
  --name my-app-kv \
  --object-id <managed-identity-object-id> \
  --secret-permissions get list

Pricing, Regions & Practical Tips

• Set up budgets and cost alerts (Cost Management + Billing) on day one — App Service plans, VMs, and Load Balancers bill continuously even when idle unless you scale/deallocate them

• Stopping a VM in the Azure Portal UI is not the same as deallocating it — a merely "stopped" VM can still incur compute charges; use az vm deallocate to actually stop billing

• Reserved Instances and Savings Plans cut compute cost 30-70% over pay-as-you-go for steady-state workloads — commit once usage patterns are known, not on day one

• Not every service is available in every region — check regional availability before designing multi-region architecture, especially for newer services

• Resource names for globally-unique services (storage accounts, App Service default hostnames, Key Vault) must be unique across all of Azure, not just your subscription — expect to append random suffixes

• Use Azure Resource Manager (ARM) templates or Bicep instead of clicking through the Portal for anything you'll need to reproduce — infrastructure-as-code catches config drift and makes environments reproducible