Introduction to Cloud Computing & Microsoft Azure
Microsoft Azure is a public cloud platform. Instead of buying and running your own servers, you rent computing power, storage, networking and higher-level services from Microsoft's global datacenters — and pay only for what you actually use.
Why organizations move to the cloud
CapEx → OpEx
No big upfront hardware purchase. You rent capacity monthly and treat it as an operating expense.
Elastic scale
Add capacity for a traffic spike, then remove it an hour later. You're never sized for the worst case year-round.
Global reach
Deploy close to your users in dozens of countries without building a single datacenter.
Built-in resilience
Redundant power, cooling and networking, plus replication options, come as part of the platform.
Try it: who manages what?
Cloud computing comes in three flavors — IaaS, PaaS and SaaS — and the only real difference is how much of the stack you manage yourself versus how much Azure manages for you. Click each one and watch the stack change.
The shared responsibility model
A common exam topic. No matter which service model you pick, some things are always yours and some are always Microsoft's:
Always yours
Your data, your user accounts and access rights, and the devices people connect from.
Always Microsoft's
Physical hosts, physical network and the physical datacenter itself.
Cloud deployment models
How you manage Azure
Azure Portal
A web UI for clicking through resource creation and configuration.
CLI & PowerShell
Command-line tools for scripting repeatable actions.
ARM & Bicep
Infrastructure as code, so environments can be version-controlled and redeployed.
Everything you create in Azure — a VM, a database, a web app — is called a resource, and every resource lives inside a resource group. That single idea underpins almost all of Azure's structure, and it's the subject of the next lesson.
Azure Portal, Regions & Resource Groups
Before you deploy anything, you need to understand three things: where your resources physically live (regions), how they're organized (resource groups), and how the whole account structure fits together.
Azure's physical hierarchy
You never pick a datacenter directly. You pick a region, and Azure decides which underlying buildings host your resources.
Choosing a region
Latency
Pick a region physically close to the users who'll be hitting it.
Service availability
Not every Azure service exists in every region — check before you design around one.
Compliance
Some data is legally required to stay inside a specific geography.
Pricing
The same VM size can cost noticeably more in one region than another.
Not every region has Availability Zones. If zone-level resiliency matters to your design, confirm the target region supports zones before you build on top of it.
Region pairs
Most regions are paired with another region at least 300 miles away in the same geography — for example Central India ↔ South India. During a broad outage Azure prioritizes restoring one region of each pair first, and several services replicate across the pair automatically for disaster recovery.
The management hierarchy
Separately from the physical hierarchy above, there's an organizational hierarchy that controls billing and permissions:
Resource groups in practice
A resource group is a logical container holding related resources — a VM together with its disk, network interface and public IP. A few rules worth memorizing:
Exactly one group
Every resource belongs to one resource group — never zero, never two.
Groups can span regions
A group has its own location (for metadata), but resources inside it can live in different regions.
Resources can move
You can move most resources between groups or subscriptions later.
Deleting cascades
Deleting a resource group permanently deletes everything inside it.
Because deleting a resource group is permanent and cascades to every resource inside, always double-check its contents before confirming. Use resource locks on production groups to prevent accidents.
Navigating the Azure Portal
Global search
The fastest way to reach any service or resource — faster than the menus.
Favorites
Pin the services you use daily to the left sidebar.
Dashboards
Build custom tile views per project or environment, and share them with your team.
Cloud Shell
A browser-based Bash or PowerShell terminal, already authenticated as you.
Tagging
Tags are simple name:value labels you attach to resources — for example Environment:Production, Owner:Finance, CostCenter:4412. They don't change how a resource behaves, but they're what makes cost reports and bulk governance actually usable at scale.
A practical naming convention pays for itself fast. Something like rg-projectname-env-region (e.g. rg-shop-prod-cin) tells you what a group is for at a glance, six months later.
Module 1 Exam
Eight questions covering cloud service models, the shared responsibility model, regions and resource groups. Instant feedback after each answer, then a final score. Aim for 70% or better before moving on.
Create and Manage Azure Virtual Machines
A virtual machine is Azure's classic IaaS offering: a full computer — CPU, memory, disk, network card — running on Microsoft's hardware, where you control the operating system and everything installed on it.
When a VM is the right choice
Choose a VM when…
You need full OS control, must install specific software, are migrating a legacy app as-is, or need a custom kernel/driver.
Prefer PaaS when…
You just want to run a web app or API. App Service or Functions remove the patching and scaling burden entirely.
Rule of thumb: the more control you need over the operating system, the more a VM makes sense. The less you want to manage, the further up the PaaS/serverless stack you should go.
What gets created alongside your VM
Creating one VM actually creates several linked resources. Deleting the VM does not automatically delete all of them — a very common source of surprise costs.
VM size families
Azure groups VM sizes into families optimized for different workloads. The letter tells you the purpose:
| Family | Optimized for | Typical use |
|---|---|---|
| B-series | Burstable, low cost | Dev/test, low-traffic sites that occasionally spike |
| D-series | General purpose | Most production workloads, web servers, small databases |
| E-series | Memory optimized | In-memory caching, large relational databases |
| F-series | Compute optimized | Batch processing, application servers, analytics |
| L-series | Storage optimized | Big data, NoSQL, high disk throughput |
| N-series | GPU | Machine learning, rendering, visualization |
Creating a VM in the portal
The creation wizard walks through tabs. The decisions that actually matter:
Basics
Subscription, resource group, VM name, region, image (Windows/Linux), size, and admin credentials.
Disks
OS disk type (Premium SSD, Standard SSD, HDD) and any extra data disks.
Networking
Virtual network, subnet, public IP, and which inbound ports to open.
Management
Boot diagnostics, auto-shutdown schedules, backup and patch settings.
The same thing with the CLI is a single command:
az vm create \
--resource-group rg-lab-prod-cin \
--name web-vm-01 \
--image Ubuntu2204 \
--size Standard_D2s_v3 \
--admin-username azureuser \
--generate-ssh-keys
Connecting to your VM
| Method | OS | Port | Notes |
|---|---|---|---|
| RDP | Windows | 3389 | Graphical desktop session |
| SSH | Linux | 22 | Key-based auth strongly preferred over passwords |
| Azure Bastion | Both | — | Browser-based, no public IP or open port needed |
| Serial Console | Both | — | Works even when networking is broken |
Never leave RDP (3389) or SSH (22) open to the whole internet on a production VM. Use Azure Bastion, or restrict the NSG rule to your office IP, or enable just-in-time VM access so the port opens only when requested.
VM power states and what you pay for
| State | Compute charges | Storage charges |
|---|---|---|
| Running | Yes | Yes |
| Stopped (from inside the OS) | Yes — still allocated | Yes |
| Stopped (deallocated) | No | Yes |
| Deleted | No | Only for disks you kept |
This catches people out constantly: shutting a VM down from inside Windows or Linux leaves it allocated, and you keep paying for compute. To actually stop billing, use Stop (deallocate) from the portal or az vm deallocate.
Common troubleshooting
Can't connect via RDP/SSH
Check the NSG allows your IP on the right port, the VM is running (not deallocated), and it has a reachable IP.
VM is slow
Check CPU/memory metrics in Monitor. Often it's disk — a Standard HDD on a busy workload is a frequent culprit.
Won't boot
Use boot diagnostics for a screenshot of the console, or the serial console to fix it from inside.
A single VM has no high-availability guarantee. To get an SLA you need at least two VMs across an availability set or, better, availability zones — covered when we reach scale sets later in this module.
Azure VM Disks & Core Architecture
Disk choice is where VM performance is won or lost — and where a surprising share of the bill comes from. This lesson covers the three disk roles, the four performance tiers, and how resiliency options fit together.
The three disks attached to a VM
OS disk
Holds the operating system. Always present, persistent, labelled C: on Windows or mounted at / on Linux.
Data disk(s)
Optional, persistent storage for your application data and databases. Attach as many as the VM size allows.
Temporary disk
Local SSD on the physical host. Fast, but wiped on deallocation or host maintenance.
Never store anything you care about on the temporary disk (usually D: on Windows, /dev/sdb on Linux). It's designed for page files, swap and scratch data only — Azure will wipe it without warning.
Managed disk performance tiers
| Tier | Backed by | Best for | Relative cost |
|---|---|---|---|
| Ultra Disk | NVMe SSD | SAP HANA, top-tier databases needing sub-ms latency | Highest |
| Premium SSD | SSD | Production workloads — the safe default | High |
| Standard SSD | SSD | Web servers, light production, dev/test | Medium |
| Standard HDD | Spinning disk | Backups, archives, infrequent access | Lowest |
Only Premium SSD and above qualify for the single-instance VM SLA. If a workload matters, Standard HDD is a false economy — the performance hit usually costs more in wasted compute than the disk saves.
Managed vs unmanaged disks
Modern Azure uses managed disks exclusively for new deployments. Azure handles the underlying storage accounts, replication and scaling for you — you just say "I want a 256 GB Premium SSD." Unmanaged disks (where you managed your own storage accounts) are legacy and shouldn't be used for anything new.
Disk encryption
SSE — Storage Service Encryption
On by default for every managed disk, at no cost. Encrypts data at rest on the platform side.
ADE — Azure Disk Encryption
Uses BitLocker (Windows) or DM-Crypt (Linux) inside the guest OS, with keys held in Azure Key Vault.
Snapshots and images
| Concept | What it captures | Used for |
|---|---|---|
| Snapshot | A point-in-time copy of one disk | Backup before a risky change; cloning a single disk |
| Image | A whole generalized VM (OS + data disks) | A reusable template for deploying many identical VMs |
Before you deploy from a custom image, the source VM must be generalized (sysprep on Windows, waagent -deprovision on Linux). Skipping this produces VMs with duplicate machine identities that misbehave on the network.
Resiliency: how VMs stay available
| Option | Protects against | SLA |
|---|---|---|
| Single VM (Premium SSD) | Nothing structural | 99.9% |
| Availability Set (2+ VMs) | Rack & host failure, planned maintenance | 99.95% |
| Availability Zones (2+ VMs) | An entire datacenter failing | 99.99% |
Fault domains and update domains
These two terms are what an availability set actually does, and they're a reliable exam question:
Fault domain
A group of hardware sharing a power source and network switch. Spreading VMs across fault domains survives a rack failure.
Update domain
A group rebooted together during planned maintenance. Spreading across update domains means patching never takes everything down at once.
Availability sets keep all VMs inside a single datacenter — so they don't protect against that whole datacenter going down. Availability zones spread VMs across physically separate buildings, which is why they carry the higher 99.99% SLA.
Use zones when your region supports them and resiliency matters. Fall back to an availability set in regions without zone support, or when cross-zone network latency would hurt a chatty application.
Virtual Machine Scale Sets & Auto Scaling
A Virtual Machine Scale Set (VMSS) manages a group of identical VMs as a single resource — and grows or shrinks that group automatically based on demand. It's how you stop paying for peak capacity 24 hours a day.
Scaling up vs scaling out
Scale up (vertical)
Replace one VM with a bigger one. Simple, but requires a restart and has a hard ceiling.
Scale out (horizontal)
Add more identical VMs. No downtime, and virtually unlimited — this is what VMSS does.
Try it: watch autoscale react
This scale set is configured to scale out above 70% CPU and scale in below 30%, with a minimum of 2 and a maximum of 8 instances. Drag the slider to simulate changing load.
Scale out > 70% · Scale in < 30% · Min 2 · Max 8
How a scale set is defined
A single model
One image, size and configuration is applied to every instance — they're deliberately identical.
Instance limits
A minimum (your always-on floor) and maximum (your cost ceiling).
Load balancer
Traffic is distributed across instances automatically as they come and go.
Scaling rules
Metric, threshold, direction, instance change and cooldown period.
Autoscale rule anatomy
| Setting | Example | What it means |
|---|---|---|
| Metric | Percentage CPU | What's measured. Can also be memory, queue length or a custom metric. |
| Operator + threshold | Greater than 70 | The trigger point. |
| Duration | 10 minutes | How long it must stay past the threshold — prevents reacting to brief spikes. |
| Action | Increase count by 2 | How many instances to add or remove. |
| Cool-down | 5 minutes | Wait before the rule can fire again, so instances have time to warm up. |
Always pair a scale-out rule with a matching scale-in rule. A scale set that only grows will happily sit at maximum capacity — and maximum cost — forever.
Set your scale-in threshold well below scale-out (e.g. out at 70%, in at 30%, not 65%). If they're too close you get flapping — instances added and removed repeatedly, which is both slow and expensive.
Scaling modes
Manual
You set the instance count yourself. Fine for predictable, steady workloads.
Metric-based
Reacts to live CPU, memory or custom metrics. The general-purpose choice.
Schedule-based
Scale up every weekday at 8am, down at 8pm. Ideal for known business-hours patterns.
Upgrade policies
| Policy | Behaviour |
|---|---|
| Automatic | All instances updated at once. Fastest, but causes downtime. |
| Rolling | Updated in batches with health checks between. The safe production choice. |
| Manual | Nothing changes until you upgrade each instance yourself. |
Creating a scale set from the CLI:
az vmss create \
--resource-group rg-lab-prod-cin \
--name web-vmss \
--image Ubuntu2204 \
--instance-count 2 \
--vm-sku Standard_D2s_v3 \
--upgrade-policy-mode rolling \
--admin-username azureuser \
--generate-ssh-keys
VMSS suits workloads where any instance can be destroyed and replaced without losing data — web front ends, API tiers, batch workers. It's a poor fit for stateful single-instance apps like a primary database server, which should keep its data on persistent managed disks instead.
Module 2 Exam
Ten questions on virtual machines, disks, availability and scale sets. Instant feedback after each answer, then a final score. Aim for 70% or better before moving on.
Introduction to Azure Storage Accounts
A storage account is the container that holds all your Azure storage data services. It provides a unique namespace, and every blob, file share, queue and table lives inside one.
The four data services
Blob
Unstructured objects — images, video, backups, logs. The most-used service by far.
File
Fully managed SMB/NFS file shares you can mount like a network drive.
Queue
Simple message store for decoupling application components.
Table
NoSQL key-value store for large volumes of structured, non-relational data.
Account types
| Type | Supports | Use when |
|---|---|---|
| Standard general-purpose v2 | All four services, all tiers | The default recommendation for almost everything |
| Premium block blobs | Blob only | High transaction rates, low latency needs |
| Premium file shares | Files only | Enterprise file shares needing SSD performance |
| Premium page blobs | Page blobs | Unmanaged VM disks (legacy) |
Redundancy — the most-tested topic
Redundancy decides how many copies of your data exist and where. Every option keeps at least three copies.
| Option | Copies | Spread across | Survives |
|---|---|---|---|
| LRS — Locally redundant | 3 | One datacenter | Disk/rack failure |
| ZRS — Zone redundant | 3 | Three availability zones | A datacenter failing |
| GRS — Geo redundant | 6 | Primary (LRS) + paired region | A whole region failing |
| GZRS — Geo-zone redundant | 6 | Primary (ZRS) + paired region | Both, highest durability |
The RA- prefix (RA-GRS, RA-GZRS) means read access: you can read from the secondary region at any time. Without it, the secondary is only reachable after Microsoft initiates a failover.
Access tiers for blob data
| Tier | Storage cost | Access cost | Minimum stay |
|---|---|---|---|
| Hot | Highest | Lowest | None |
| Cool | Lower | Higher | 30 days |
| Cold | Lower still | Higher still | 90 days |
| Archive | Lowest | Highest + rehydration delay | 180 days |
Archive is offline. Reading data requires rehydration, which can take hours. It's for compliance archives you almost never touch — not for backups you might need in a hurry.
Use lifecycle management policies to move blobs down the tiers automatically — for example Hot → Cool after 30 days, Cool → Archive after 180. It's the single easiest storage cost saving available.
Securing access
Access keys
Two keys giving full control. Powerful and risky — rotate regularly, never embed in client apps.
SAS tokens
Time-limited URLs scoped to specific permissions and resources. The right choice for sharing.
Entra ID + RBAC
Identity-based access with roles like Storage Blob Data Reader. The most secure option.
Network rules
Firewall the account to specific VNets or IP ranges, or use a private endpoint.
Creating an account from the CLI:
az storage account create \
--resource-group rg-lab-prod-cin \
--name veplearnstorage01 \
--location centralindia \
--sku Standard_ZRS \
--kind StorageV2 \
--access-tier Hot
Storage account names must be globally unique across all of Azure, 3–24 characters, lowercase letters and numbers only. No hyphens — a common source of failed deployments.
Azure Blob Storage & File Storage
Blob and File are the two storage services you'll use most. They solve different problems: blobs are for objects your application reads and writes, file shares are for drives your servers and users mount.
Blob storage structure
A blob's URL follows a predictable pattern:
https://veplearnstorage01.blob.core.windows.net/images/logo.png
└── account ──┘ └container┘└ blob ┘
The three blob types
| Type | Optimized for | Typical use |
|---|---|---|
| Block blob | Reading whole objects | Images, documents, video, backups — the default |
| Append blob | Adding to the end | Log files, audit trails, telemetry |
| Page blob | Random read/write | Virtual hard disks (VHDs) |
Container access levels
Private
No anonymous access. Credentials required for everything. The safe default.
Blob
Anonymous read of individual blobs if you know the exact URL, but the container can't be listed.
Container
Anonymous read and listing — anyone can enumerate every file. Use with real caution.
Public container access is behind a documented history of data leaks. Prefer private containers with SAS tokens or Entra ID. Azure now lets you disable anonymous access at the account level — turn it on for anything sensitive.
Blob data protection
Soft delete
Deleted blobs are recoverable for a retention window you set. Protects against accidents.
Versioning
Every write creates a new version, so you can roll back to any earlier state.
Snapshots
Manual read-only point-in-time copies of a single blob.
Immutability
WORM policies that block modification or deletion for a legally-defined period.
Azure Files
Azure Files gives you a fully managed network file share, reachable over SMB (Windows/Linux/macOS) or NFS (Linux, premium only). Unlike blobs, applications need no rewriting — it mounts as a normal drive.
Lift-and-shift
Move a legacy app that expects a UNC path without changing its code.
Shared config
Several VMs reading the same configuration or content directory.
Azure File Sync
Cache the share on on-premises Windows Servers, with the cloud as the source of truth.
Mounting a share on Linux:
sudo mount -t cifs \
//veplearnstorage01.file.core.windows.net/appdata /mnt/appdata \
-o vers=3.0,username=veplearnstorage01,password=<key>,serverino
Blob vs Files — choosing
| Blob Storage | Azure Files | |
|---|---|---|
| Access | REST API / SDK | Mounted drive (SMB/NFS) |
| Structure | Flat, with virtual folders | True hierarchical folders |
| Best for | App-managed objects, static content | Shared drives, legacy apps |
| App changes | Code must use the SDK | None — it's just a path |
Quick rule: if your application code reads the data, use Blob. If an operating system or user needs to browse it like a folder, use Files.
Blob storage has no real folders. A blob named 2024/reports/q1.pdf is one flat name containing slashes — tools just display it as a tree. This is why "renaming a folder" means copying every blob underneath it.
Azure Queue Storage & Table Storage
The two remaining storage services are less flashy but solve real architectural problems: queues decouple components so they can fail independently, and tables store huge volumes of structured data cheaply.
Why queues exist
Without a queue, a web app that resizes uploaded images must do it while the user waits — and if the resizer crashes, the request is lost. A queue turns that into a durable hand-off:
Decoupling
Producer and consumer never talk directly, so either can be down without losing work.
Load levelling
A traffic spike grows the queue, not your error rate. Workers drain it at their own pace.
A scaling signal
Queue length is an excellent autoscale metric — far better than CPU for worker tiers.
How a message is consumed
Queue Storage doesn't delete a message when it's read. Instead it becomes invisible for a set time while the worker processes it:
| Step | What happens |
|---|---|
| 1. Get message | Worker receives it; it becomes invisible to other workers |
| 2. Process | Worker does the job within the visibility timeout |
| 3. Delete | Worker explicitly deletes the message on success |
| If the worker crashes | The timeout expires, the message reappears, another worker retries it |
This design means delivery is at-least-once, not exactly-once — a message can be processed twice if a worker is slow. Make your processing idempotent so a repeat run causes no harm.
Queue Storage limits: messages max 64 KB and live at most 7 days by default. For large payloads, store the file in blob storage and put only its URL in the message.
Queue Storage vs Service Bus
| Queue Storage | Service Bus Queues | |
|---|---|---|
| Complexity | Very simple | Feature-rich |
| Message size | 64 KB | Up to 100 MB (premium) |
| Ordering | Not guaranteed | FIFO with sessions |
| Extras | — | Topics, dead-letter, transactions, duplicate detection |
| Choose when | Simple work hand-off, huge volume, lowest cost | Enterprise messaging, ordering or pub/sub needed |
Table Storage
Table Storage is a NoSQL key-value store: schemaless rows (entities) that can each carry different properties. It's very cheap and scales to billions of rows, but it is not a relational database — no joins, no foreign keys, no complex queries.
The two keys that decide everything
PartitionKey
Groups related entities and determines which physical partition stores them.
RowKey
Uniquely identifies an entity within its partition.
Together they form the primary key. A query supplying both is a point lookup — the fastest operation available. Supplying neither forces a full table scan.
| Query supplies | Performance |
|---|---|
| PartitionKey + RowKey | Fastest — direct point query |
| PartitionKey + a range of RowKeys | Fast — scans one partition |
| RowKey only | Slow — scans every partition |
| Neither | Slowest — full table scan |
Design your PartitionKey around how you'll query, not how the data naturally groups. For per-customer lookups use CustomerId; for time-series use something like 2026-08. Getting this wrong is the number-one cause of slow Table Storage.
For new projects, Microsoft generally steers people to Azure Cosmos DB for Table — the same API with global distribution, guaranteed low latency and secondary indexes. We cover Cosmos DB in Module 9.
Module 3 Exam
Ten questions on storage accounts, redundancy, access tiers, blobs, files, queues and tables. Aim for 70% or better before moving on.
Introduction to Azure Virtual Networks
A Virtual Network (VNet) is your own private, isolated slice of the Azure network. It's the foundation everything else sits on — VMs, databases, app services with private access all attach to a VNet.
What a VNet gives you
Isolation
Your VNet is invisible to every other customer, even on shared physical hardware.
Your own IP space
You choose the private address range and how it's divided.
Connectivity
Link to other VNets (peering) or to your office (VPN / ExpressRoute).
Traffic control
NSGs, route tables and firewalls decide exactly what can talk to what.
Scope and boundaries
| Property | Rule |
|---|---|
| Region | A VNet exists in exactly one region — it cannot span regions |
| Subscription | Belongs to one subscription |
| Availability Zones | Automatically spans all zones within its region |
| Cross-region | Connect separate VNets using peering |
Private address ranges (RFC 1918)
VNets use private IP space. These three ranges are reserved for private networks worldwide:
| Range | CIDR | Available addresses |
|---|---|---|
| 10.x.x.x | 10.0.0.0/8 | ~16.7 million |
| 172.16–31.x.x | 172.16.0.0/12 | ~1 million |
| 192.168.x.x | 192.168.0.0/16 | ~65,000 |
Plan your address space before you build. VNets you intend to peer must not have overlapping ranges — and fixing an overlap later means rebuilding, not editing. Reserve a distinct block per environment and region from day one.
Public vs private IPs
| Private IP | Public IP | |
|---|---|---|
| Reachable from | Inside the VNet (and peered/VPN networks) | The internet |
| Assigned to | Every VM automatically | Only if you add one |
| Cost | Free | Charged per IP |
| SKUs | — | Basic (retiring) and Standard |
Static allocation
The address never changes. Required for DNS records, firewall allow-lists and domain controllers.
Dynamic allocation
May change when the VM is deallocated and restarted. Fine for most workloads.
Best practice: keep databases and backend VMs on private IPs only. Expose just the front door to the internet — ideally through a load balancer or Application Gateway rather than a raw public IP on the VM.
Name resolution
By default, Azure provides DNS for every VNet automatically — VMs can resolve each other by hostname with no configuration. You can override this with custom DNS servers (common when integrating with on-premises Active Directory), or use Azure Private DNS zones for your own private domain names.
Creating a VNet with a subnet:
az network vnet create \
--resource-group rg-lab-prod-cin \
--name vnet-prod-cin \
--address-prefix 10.20.0.0/16 \
--subnet-name snet-web \
--subnet-prefix 10.20.1.0/24
VNets themselves are free. You pay for what runs inside them and for certain gateways — VPN Gateway, NAT Gateway and ExpressRoute all carry hourly charges, so remember to delete lab gateways when you're done.
Subnets & IP Addressing in Azure
A subnet divides your VNet's address space into smaller segments. Subnets are how you separate tiers — web, application, database — so each can have its own security rules and routing.
Reading CIDR notation
The number after the slash says how many bits are fixed as the network portion. A bigger number means a smaller network:
| CIDR | Total addresses | Azure usable | Typical use |
|---|---|---|---|
/16 | 65,536 | 65,531 | A whole VNet |
/24 | 256 | 251 | A standard subnet |
/26 | 64 | 59 | A small tier |
/27 | 32 | 27 | Gateway subnet minimum |
/29 | 8 | 3 | Smallest allowed subnet |
Azure reserves five addresses in every subnet, not the usual two. In 10.0.1.0/24: .0 network, .1 gateway, .2 and .3 Azure DNS, .255 broadcast. So a /24 gives 251 usable, not 254 — a very common exam question.
A typical three-tier layout
| Subnet | Range | Contains | Internet access |
|---|---|---|---|
| snet-web | 10.20.1.0/24 | Front-end servers, load balancer | Inbound 80/443 |
| snet-app | 10.20.2.0/24 | Application servers, APIs | None inbound |
| snet-data | 10.20.3.0/24 | Databases | None at all |
| GatewaySubnet | 10.20.255.0/27 | VPN / ExpressRoute gateway | Managed by Azure |
Some subnets must use exact reserved names: GatewaySubnet for VPN/ExpressRoute gateways, AzureFirewallSubnet for Azure Firewall, AzureBastionSubnet for Bastion. Get the spelling wrong and the service simply won't deploy.
Sizing subnets
Don't go too small
Resizing a subnet that already has resources in it is painful. Leave headroom for growth.
Account for scale sets
A VMSS that can reach 50 instances needs 50 free IPs — plus Azure's five reserved.
Private endpoints eat IPs
Every private endpoint consumes an address from the subnet it lands in.
/24 is a sane default
251 usable addresses covers most tiers without wasting space.
Service endpoints vs private endpoints
Both let VNet resources reach PaaS services like Storage or SQL more securely, but they work differently:
| Service endpoint | Private endpoint | |
|---|---|---|
| How it works | Traffic stays on Azure's backbone; service still has a public IP | Service gets a private IP inside your subnet |
| Uses a subnet IP | No | Yes |
| Reachable from on-premises | No | Yes, over VPN/ExpressRoute |
| Cost | Free | Charged hourly + data |
Private endpoints are the more secure and more flexible option, and are where Microsoft is steering new designs. Use service endpoints when cost matters more and on-premises access isn't needed.
Routing basics
Azure creates system routes automatically so everything inside a VNet can reach everything else. You override them with a User Defined Route (UDR) in a route table — most often to force traffic through a firewall or network virtual appliance before it leaves.
az network vnet subnet create \
--resource-group rg-lab-prod-cin \
--vnet-name vnet-prod-cin \
--name snet-data \
--address-prefix 10.20.3.0/24
Network Security Groups (NSG)
An NSG is a distributed firewall that filters traffic to and from Azure resources. It holds a prioritized list of allow/deny rules, evaluated in order until one matches.
The rules that matter
Priority 100–4096
Lower numbers evaluate first. Leave gaps (100, 200, 300) so you can insert rules later.
First match wins
Evaluation stops at the first matching rule. Everything below it is never considered.
Stateful
Allow traffic in and the reply is automatically allowed out. No return rule needed.
Two attach points
Associate to a subnet, a NIC, or both. Subnet rules apply first for inbound traffic.
Try it: watch rule evaluation
This NSG protects a web server. Pick an incoming packet and watch which rule catches it — notice how everything below the matching rule is never even reached.
What defines a rule
| Field | Example |
|---|---|
| Priority | 100 — lower is evaluated first |
| Source / destination | IP, CIDR, service tag or ASG |
| Protocol | TCP, UDP, ICMP or Any |
| Port range | 443, 1000-2000, or * |
| Direction | Inbound or Outbound |
| Action | Allow or Deny |
Default rules you can't delete
| Priority | Rule | Effect |
|---|---|---|
| 65000 | AllowVnetInBound | Anything inside the VNet can talk to anything else |
| 65001 | AllowAzureLoadBalancerInBound | Health probes can reach your resources |
| 65500 | DenyAllInBound | Everything else inbound is blocked |
Because AllowVnetInBound exists at 65000, resources in different subnets of the same VNet can reach each other by default. If you want tier isolation, you must add explicit deny rules at a lower priority number.
Service tags
Rather than maintaining IP lists, use service tags — Microsoft-managed labels that stay current automatically: Internet, VirtualNetwork, AzureLoadBalancer, Storage, Sql, AzureCloud.
Two NSGs in the path (one on the subnet, one on the NIC) means traffic must be allowed by both. This is the most common cause of "my rule looks right but it's still blocked" — always check both layers.
When connectivity breaks, use NSG diagnostics or IP flow verify in Network Watcher. It tells you exactly which rule allowed or denied the packet, instead of guessing — covered in the last lesson of this module.
Application Security Groups & VNet Peering
Two features that make networks easier to manage as they grow: ASGs let you write rules about roles instead of IP addresses, and peering connects VNets together privately.
The problem ASGs solve
Without ASGs, NSG rules reference IP addresses. Add a web server and you must edit every rule that mentions the web tier. With ASGs you group NICs by role and write rules against the group name — new servers just join the group.
| Without ASG | With ASG | |
|---|---|---|
| Rule source | 10.20.1.4, 10.20.1.5, 10.20.1.6 | asg-web |
| Adding a server | Edit every affected rule | Add the NIC to the ASG |
| Readability | Which IP was the database? | Self-documenting |
ASGs are attached to network interfaces, not subnets — so two VMs in the same subnet can belong to different ASGs and get completely different rules. All ASGs used together in one rule must be in the same VNet.
VNet peering
Peering connects two VNets so resources talk over Microsoft's backbone using private IPs — no VPN gateway, no public internet, low latency.
Low latency
Traffic stays on the Azure backbone at near-native speed.
Global peering
Works across regions and even across subscriptions or tenants.
No gateway needed
Nothing to deploy or maintain — it's a configuration, not a resource.
Charged on data
You pay per GB in and out. Global peering costs more than same-region.
Three rules that trip people up
No overlapping ranges
Peering fails outright if address spaces overlap. Plan IP space in advance.
Peering isn't automatic both ways
A link must be created from each VNet. One-sided peering shows "Initiated" and doesn't work.
Not transitive
If A↔B and B↔C, A still cannot reach C. You need A↔C, or routing through an appliance.
Non-transitivity is the single most-tested peering fact. In a hub-and-spoke design, spokes cannot talk to each other through the hub by default — that requires user-defined routes pointing at a firewall or NVA in the hub.
Hub-and-spoke
The standard enterprise pattern: a central hub VNet holds shared services (firewall, VPN gateway, DNS, Bastion), and each workload lives in its own spoke peered to the hub. It centralizes security and cuts costs, since one gateway serves every spoke.
| Peering setting | What it does |
|---|---|
| Allow forwarded traffic | Accept traffic that didn't originate in the peer VNet — needed for hub routing |
| Allow gateway transit | Let spokes use the hub's VPN/ExpressRoute gateway |
| Use remote gateways | Set on the spoke to consume the hub's gateway |
az network vnet peering create \
--resource-group rg-lab-prod-cin \
--name hub-to-spoke1 \
--vnet-name vnet-hub \
--remote-vnet vnet-spoke1 \
--allow-vnet-access --allow-forwarded-traffic
Connecting to on-premises
| Option | Runs over | Best for |
|---|---|---|
| Point-to-Site VPN | Internet | Individual remote users |
| Site-to-Site VPN | Encrypted internet tunnel | Connecting a whole office |
| ExpressRoute | Private dedicated circuit | Enterprise workloads needing guaranteed bandwidth |
Azure Network Watcher & Network Troubleshooting
Network Watcher is the diagnostic toolbox for Azure networking. Rather than guessing why traffic is blocked, these tools tell you exactly which rule or route is responsible.
The diagnostic tools
IP flow verify
Answers "can this packet get through?" and names the exact NSG rule that allowed or denied it.
Next hop
Shows where a packet goes next — internet, VNet, virtual appliance — revealing bad routes.
Connection troubleshoot
Tests real connectivity between two endpoints and reports latency and hop-by-hop results.
NSG flow logs
Records every allowed and denied flow to storage for later analysis.
Packet capture
Captures actual traffic on a VM for deep inspection in Wireshark.
Connection monitor
Ongoing reachability and latency monitoring with alerting.
Network Watcher is enabled automatically, per region, when you create a VNet. It's a regional service — check you're looking at the right region if the tools appear missing.
A troubleshooting method that works
| Step | Check | Tool |
|---|---|---|
| 1 | Is the VM actually running (not deallocated)? | Portal overview |
| 2 | Is traffic allowed by NSG rules? | IP flow verify |
| 3 | Are BOTH the subnet and NIC NSGs allowing it? | Effective security rules |
| 4 | Is the packet routed where you expect? | Next hop |
| 5 | Is the service listening inside the OS? | Serial console / netstat |
| 6 | Is the guest OS firewall blocking it? | Serial console |
Effective security rules is the most underused view in Azure. It merges every NSG applying to a NIC — subnet plus NIC, custom plus default — into one list showing what's genuinely in force. Start there instead of reading NSGs separately.
Common failures and their causes
| Symptom | Usual cause |
|---|---|
| Can't RDP/SSH from the internet | NSG missing an allow rule, or VM has no public IP |
| Rule looks correct but traffic still blocked | A second NSG on the other layer is denying it |
| VMs in peered VNets can't communicate | Peering only created from one side, or overlapping ranges |
| Spoke can't reach another spoke | Peering isn't transitive — needs a UDR via the hub firewall |
| Load balancer backend shows unhealthy | Health probe port blocked, or the app isn't listening |
| Can reach by IP but not by name | DNS misconfiguration or a missing private DNS zone link |
| Outbound internet stopped working | A UDR is forcing traffic to an appliance that's down |
Reading NSG flow logs
Flow logs write every connection to storage as JSON. Paired with Traffic Analytics, they answer questions raw logs can't: which hosts talk most, what's being denied repeatedly, and whether anything is scanning your subnets.
# Is this packet allowed, and by which rule?
az network watcher test-ip-flow \
--vm web-vm-01 \
--direction Inbound \
--protocol TCP \
--local 10.20.1.4:443 \
--remote 198.51.100.7:60000
Remember NSGs are stateful. If inbound is allowed, the response is automatically permitted — so a blocked reply almost never means a missing outbound rule. Look at routing or the guest OS firewall instead.
Enable NSG flow logs on production subnets before you have an incident. They're inexpensive, and without them you're reconstructing an outage from memory rather than evidence.
Module 4 Exam
Twelve questions on virtual networks, subnets, IP addressing, NSGs, ASGs, peering and troubleshooting. Aim for 70% or better before moving on.
Azure Load Balancer
Azure Load Balancer distributes incoming traffic across a pool of backend servers. It operates at Layer 4 — it sees IP addresses and ports, not URLs or content — which makes it extremely fast and protocol-agnostic.
Try it: watch traffic get distributed
Send requests through the load balancer and watch which backend server receives each one. Then take a server down and see how health probes reroute traffic away from it.
The four components
Frontend IP
The address clients connect to — public for internet traffic, private for internal.
Backend pool
The VMs or scale set instances that actually serve requests.
Health probe
Periodically tests each backend. Failing instances are removed from rotation.
Load balancing rule
Maps a frontend port to a backend port and ties the pieces together.
Public vs internal
| Public Load Balancer | Internal (Private) Load Balancer | |
|---|---|---|
| Frontend IP | Public | Private, inside the VNet |
| Reachable from | The internet | Only the VNet and connected networks |
| Typical use | Public web tier | Balancing an internal app or database tier |
Basic vs Standard SKU
| Feature | Basic | Standard |
|---|---|---|
| Backend instances | Up to 300 | Up to 1,000 |
| Availability Zones | Not supported | Zone redundant |
| SLA | None | 99.99% |
| Secure by default | Open unless an NSG blocks | Closed unless an NSG allows |
| Status | Being retired | Use this for anything new |
Standard Load Balancer is closed by default — traffic is denied unless an NSG explicitly allows it. Migrating from Basic and forgetting this is a classic "everything broke after the upgrade" moment.
Health probes
| Probe type | Considers healthy when… | Best for |
|---|---|---|
| TCP | The TCP handshake completes on the probe port | Non-HTTP services |
| HTTP | The path returns HTTP 200 | Web apps — can test real app health |
| HTTPS | The path returns HTTP 200 over TLS | Secure web apps (Standard SKU only) |
Point HTTP probes at a dedicated endpoint like /health that checks the app's real dependencies (database reachable, cache up). Probing / only proves the web server is running — not that your application actually works.
Distribution modes
| Mode | Hashes on | Effect |
|---|---|---|
| 5-tuple (default) | Source IP, source port, dest IP, dest port, protocol | Even spread; a client may hit different servers |
| Source IP affinity (2-tuple) | Source and destination IP | A client sticks to one server — "session persistence" |
| 3-tuple | Source IP, dest IP, protocol | Middle ground |
Needing source IP affinity usually signals that your app stores session state in server memory. The more scalable fix is externalizing session state to Redis or a database, so any server can serve any request.
az network lb create \
--resource-group rg-lab-prod-cin \
--name lb-web-prod \
--sku Standard \
--frontend-ip-name fe-public \
--backend-pool-name bp-web
If every backend shows unhealthy, check three things in order: the probe port is open in the NSG, the application is actually listening on that port, and the probe path returns exactly HTTP 200 (a 301 redirect counts as a failure).
Azure Application Gateway
Application Gateway is a Layer 7 load balancer. Unlike the Layer 4 Load Balancer, it can read the actual HTTP request — the URL path, the hostname, the headers — and route based on what it finds.
Try it: path-based routing
Click a URL and watch which backend pool the gateway selects by inspecting the path.
What Layer 7 makes possible
Path-based routing
Send /api/* to one pool and /images/* to another.
Multi-site hosting
Host many domains behind one gateway, routed by hostname.
SSL termination
Decrypt TLS at the gateway so backends don't spend CPU on it.
Cookie affinity
Keep a user's session pinned to the same backend server.
Web Application Firewall
Block SQL injection, XSS and the rest of the OWASP top 10.
Redirects & rewrites
Force HTTPS, or rewrite URLs and headers in flight.
How a request flows through
Web Application Firewall modes
| Mode | Behaviour | Use when |
|---|---|---|
| Detection | Logs threats but allows them through | Initial tuning, to find false positives safely |
| Prevention | Blocks matching requests outright | Production, once tuned |
Always start WAF in Detection mode and review the logs for a week. Switching straight to Prevention on a real app frequently blocks legitimate traffic — file uploads and rich text editors are common false positives.
Choosing between the load balancers
| Load Balancer | Application Gateway | |
|---|---|---|
| Layer | 4 (TCP/UDP) | 7 (HTTP/HTTPS) |
| Routing on | IP and port | URL path, hostname, headers |
| Scope | Regional | Regional |
| SSL termination | No | Yes |
| WAF | No | Yes |
| Protocols | Any TCP/UDP | HTTP/HTTPS only |
| Choose for | Databases, non-HTTP services, raw speed | Web apps needing content-aware routing |
Application Gateway needs its own dedicated subnet — nothing else can live in it. Size it at least /24 for the v2 SKU, which needs room to scale out its instances.
Application Gateway is regional. To route users between regions you need Traffic Manager or Front Door in front of it — covered in the next lessons.
Azure DNS
Azure DNS hosts your domain's DNS records on Microsoft's global network of name servers. It doesn't sell you domains — you register elsewhere and delegate the name servers to Azure.
How a DNS lookup works
Record types you'll actually use
| Type | Maps | Example |
|---|---|---|
| A | Name → IPv4 address | www → 20.44.12.8 |
| AAAA | Name → IPv6 address | www → 2603:1010::4 |
| CNAME | Name → another name | shop → app.azurewebsites.net |
| MX | Domain → mail server | @ → mail.example.com |
| TXT | Arbitrary text | SPF, DKIM, domain verification |
| NS | Zone → authoritative name servers | Created automatically |
| SRV | Service → host and port | SIP, Microsoft Teams |
| PTR | IP → name (reverse lookup) | Mail server reputation |
You cannot create a CNAME at the zone apex (example.com itself) — DNS standards forbid it. Azure's answer is the alias record, which points the apex directly at an Azure resource such as a public IP, Traffic Manager profile or Front Door endpoint.
Alias records
Apex support
Point example.com straight at an Azure resource — no CNAME needed.
Auto-updating
If the target resource's IP changes, the record follows automatically.
Dangling-record protection
Delete the resource and the record resolves to nothing rather than to someone else's takeover.
Public vs private zones
| Public DNS zone | Private DNS zone | |
|---|---|---|
| Resolvable from | The whole internet | Only linked VNets |
| Typical use | Your public website and mail | Internal names, private endpoints |
| Auto-registration | No | Optional — VMs register themselves |
Private DNS zones are essential for private endpoints. Without the right zone linked to your VNet, a name like mystorage.blob.core.windows.net still resolves to its public IP, and traffic bypasses your private link entirely.
TTL — time to live
TTL tells resolvers how long to cache a record. Long TTLs reduce lookups and cost; short TTLs let changes propagate fast.
Before a planned migration, lower the TTL to 300 seconds a day or two in advance. Then the cutover propagates in minutes. Lowering it at the same time as the change doesn't help — resolvers are still holding the old, long-TTL answer.
az network dns record-set a add-record \
--resource-group rg-lab-prod-cin \
--zone-name veplearn.example \
--record-set-name www \
--ipv4-address 20.44.12.8
Azure Traffic Manager
Traffic Manager is a DNS-based global load balancer. It doesn't carry your traffic — it answers DNS queries with the IP of whichever endpoint its routing method selects, and the client then connects directly.
This DNS-level design has one big consequence: because clients cache DNS answers, failover isn't instant. It takes as long as the record's TTL to fully take effect — which is why TTLs on Traffic Manager profiles are usually set very low (30–60 seconds).
The six routing methods
| Method | Sends users to | Use case |
|---|---|---|
| Priority | The highest-priority healthy endpoint | Active/passive failover to a DR region |
| Weighted | Endpoints in proportion to assigned weights | Blue/green and canary releases |
| Performance | The region with lowest measured latency | Global apps optimizing speed |
| Geographic | The endpoint mapped to the user's country | Data sovereignty, localized content |
| Multivalue | Several healthy IPs at once | Client-side retry across endpoints |
| Subnet | An endpoint mapped to the user's IP range | Different experience for office vs public users |
Priority vs Performance vs Geographic
Priority
Everyone goes to endpoint 1. Only if it fails does traffic move to endpoint 2. Classic DR.
Performance
Each user reaches the fastest region for them — based on real latency tables, not distance.
Geographic
Users are routed by the country their DNS query came from — a compliance tool, not a speed tool.
Don't confuse Performance and Geographic. Performance optimizes speed and may send an Indian user to Singapore if it's faster. Geographic guarantees an Indian user goes to the India endpoint even if it's slower — which is what data-residency rules actually require.
Endpoint types
| Type | Points at |
|---|---|
| Azure endpoint | An Azure resource — App Service, public IP, Application Gateway |
| External endpoint | Any public IP or FQDN, including on-premises or another cloud |
| Nested endpoint | Another Traffic Manager profile, for combining routing methods |
Nested profiles are how you combine methods. A common pattern: a Geographic parent sends EU users to an EU child profile, which then uses Performance to pick the fastest EU region. Compliance and speed together.
Traffic Manager vs Front Door
| Traffic Manager | Front Door | |
|---|---|---|
| Works at | DNS layer | HTTP layer (reverse proxy) |
| Carries traffic | No — client connects directly | Yes — traffic flows through it |
| Protocols | Any | HTTP/HTTPS only |
| Failover speed | Limited by DNS TTL | Near-instant |
| Caching / WAF | No | Yes |
For modern web applications, Front Door is usually the better choice. Traffic Manager remains the right tool when you need to route non-HTTP protocols globally — or to direct traffic to endpoints outside Azure entirely.
Azure Front Door & CDN
Front Door is Microsoft's global entry point for web applications: a reverse proxy running at edge locations worldwide that combines global load balancing, caching, SSL offload and a web application firewall.
Why the edge matters
A user in Chennai requesting content from a server in Virginia waits for the round trip. An edge node in Chennai serving a cached copy answers in milliseconds. Front Door also terminates TLS at the edge, so the expensive handshake happens close to the user.
What Front Door provides
Global load balancing
Routes each user to the nearest healthy backend, across regions.
Edge caching
Static content served from the POP nearest the user.
WAF & DDoS
Attacks are absorbed at the edge, far from your origin.
Free managed TLS
Certificates issued and auto-renewed by Microsoft.
Path routing & rewrites
Layer 7 rules just like Application Gateway, but global.
Rules engine
Custom header, redirect and caching logic evaluated at the edge.
Caching behaviour
| Concept | Meaning |
|---|---|
| Cache hit | The edge had the content and served it directly — fastest path |
| Cache miss | The edge fetched from origin, then stored it for next time |
| TTL | How long the edge keeps content, driven by Cache-Control headers |
| Purge | Manually evicting content after a deployment |
| Query string handling | Whether ?v=2 counts as a different cached object |
Never cache authenticated or personalized responses at the edge — you risk serving one user's private page to another. Set Cache-Control: private, no-store on anything user-specific.
Rather than purging after every deploy, use cache-busting filenames like app.4f2a91.js. A new build produces a new filename, so the edge fetches it immediately while old files expire naturally.
Front Door vs CDN
| Azure CDN | Front Door | |
|---|---|---|
| Primary purpose | Caching static content | Global app delivery and acceleration |
| Load balancing | No | Yes, with health probes |
| WAF | Limited | Full |
| Dynamic content | Not accelerated | Accelerated over the backbone |
Microsoft has consolidated these into Azure Front Door Standard/Premium, which merges classic CDN and Front Door capabilities into one product. Premium adds the full WAF ruleset, private-link origins and bot protection.
Choosing the right service — the summary
| Need | Service |
|---|---|
| Balance TCP/UDP inside one region | Load Balancer |
| URL-based routing + WAF in one region | Application Gateway |
| Route any protocol globally via DNS | Traffic Manager |
| Global HTTP delivery with caching and WAF | Front Door |
The two questions that resolve almost every exam scenario: regional or global? and HTTP or any protocol? Regional + any protocol → Load Balancer. Regional + HTTP → Application Gateway. Global + any protocol → Traffic Manager. Global + HTTP → Front Door.
Module 5 Exam
Twelve questions on Load Balancer, Application Gateway, DNS, Traffic Manager and Front Door. Aim for 70% or better before moving on.