Before Azure makes sense, the underlying idea has to. Cloud computing is simply renting computing resources — servers, storage, databases, networking — over the internet, instead of buying and running the physical machines yourself.
The old way was on-premises: a company bought servers, put them in a room, cooled them, patched them, and replaced them when they died. The cloud way is to let a provider (here, Microsoft) own that hardware in giant datacenters, and you pay only for the slice you use — like electricity from a utility rather than a generator in your basement.
Figure 1. The shift from on-premises to cloud. The lower you push responsibility onto the provider, the less you maintain — and the faster you ship.
Three properties make this worth doing:
Pay-as-you-go. You're billed for consumption (compute-hours, gigabytes stored), not for idle hardware.
Elasticity. Need 100 servers for an hour during a traffic spike? Spin them up, then release them. Scale up and down on demand.
Global reach. Deploy close to your users anywhere in the world without building a datacenter there.
02 What Azure is
Microsoft Azure is Microsoft's cloud computing platform: a catalogue of hundreds of individual services, delivered over the internet, that you assemble like building blocks to run almost any kind of application or workload.
It launched in 2010 (originally "Windows Azure") and today sits alongside Amazon AWS and Google Cloud as one of the three dominant public clouds. The mental model that matters: Azure is not one product — it's a marketplace of services, each solving a specific need (run code, store a file, train a model, authenticate a user), all billed and managed through one account and one control surface called the Azure Portal.
Mental model
Think of Azure as a hardware store the size of a city. You rarely use the whole store — you walk in, grab the four or five services your project needs, and wire them together. The skill is knowing which aisle to visit.
03 The three service models: IaaS, PaaS, SaaS
Every cloud service sits somewhere on a spectrum of how much the provider manages versus how much you do. These are the three classic tiers. The single most useful diagram in all of cloud computing is the one that shows who is responsible for what.
Figure 2. The responsibility ladder. Reading left to right, more of the stack turns blue — Microsoft takes over more layers, you manage fewer. Cream = your job · Blue = Azure's job.
IaaS — Infrastructure as a Service
You rent raw building blocks: virtual machines, disks, networks. You still install the OS, patch it, and run your software — but you never touch physical hardware. Example:Azure Virtual Machines. Most control, most work.
PaaS — Platform as a Service
You hand Microsoft the OS and runtime worries and just deploy your code. Example:Azure App Service or Azure SQL Database — you bring the app or the data; the platform handles patching, scaling, and uptime underneath.
SaaS — Software as a Service
Finished software you simply log into and use. You manage nothing technical. Example:Microsoft 365 (Outlook, Teams). The provider owns the entire stack.
Rule of thumb
More control needed? Move toward IaaS. Less maintenance wanted? Move toward SaaS. Most modern projects live in the middle (PaaS) — enough control, little babysitting.
04 The three core service families
Hundreds of services sound overwhelming, but almost everything reduces to three primal needs: run something, store something, connect something. Master these and the rest are variations.
Figure 3. The three pillars. Nearly every Azure architecture is some arrangement of compute (runs logic), storage (holds state), and networking (moves traffic) — exactly mirroring a physical computer's CPU, disk, and bus.
A quick map from physical computer to cloud, since the analogy holds tightly:
Compute ≈ the processor and RAM. Where your program's instructions actually execute.
Storage ≈ the hard drive. Where data survives after the program stops.
Networking ≈ the motherboard bus and the cables. How the parts — and your users — reach each other.
05 Beyond the basics
On top of the three pillars, Azure layers specialized service families. You don't need all of them, but knowing the categories helps you find the right aisle.
AI & Machine Learning — Azure AI Foundry, Azure OpenAI, Azure Machine Learning: train models, or call ready-made vision/language/speech APIs.
Identity — Microsoft Entra ID (formerly Azure Active Directory): who is allowed to sign in and what they may touch. The security backbone.
Every resource you create in Azure lives inside a strict containment hierarchy. This is not the same as the physical region hierarchy in the next section — this one is about ownership, billing, and permissions. Get it right early and large accounts stay sane; get it wrong and you drown in untraceable costs.
Figure 4. The management hierarchy. A resource (a single VM, database, vault) lives in a resource group (a folder you create, delete, and permission as a unit — usually one per app or environment), which lives in a subscription (the billing line), which can be governed in bulk by a management group.
Resource — a single thing you create: one VM, one storage account, one database.
Resource group — a logical folder holding related resources that share a lifecycle. Deleting the group deletes everything in it — handy for tearing down a whole environment cleanly.
Subscription — the unit of billing and quota. Costs roll up here; you get one invoice per subscription. Many orgs use separate subscriptions for prod vs dev.
Management group — an optional layer above subscriptions for applying policy and access rules across many of them at once.
Naming & tagging
Adopt a naming convention (rg-prod-webapp-eastus) and apply tags (env=prod, owner=team-x, cost-center=1234) from the start. Tags are how you later slice the bill and find who owns a runaway resource.
07 Global infrastructure: regions & zones
Azure's physical footprint is organized as a hierarchy. Understanding it is what lets you make an app both fast (close to users) and resilient (survives a datacenter fire).
Figure 5. The geography → region → availability zone → datacenter hierarchy. Spreading copies of your app across zones survives a single datacenter failure; pairing across regions survives a whole-region disaster.
Region — a named geographic area (e.g. "West Europe") containing one or more datacenters. You choose a region to put resources near your users and to satisfy data-residency laws.
Availability Zone — physically separate datacenters within a region, with independent power and cooling. Deploy across zones for high availability.
Region pair — two regions linked for backup and disaster recovery, far enough apart that one disaster won't hit both.
08 A worked example: a web app on Azure
Abstractions click once you see them assembled. Here's a common, real architecture — a typical web application — built from the services above. Follow a single user request as it travels through the system.
Figure 6. Request flow. The user hits Front Door (fast global entry + caching), which routes to App Service (the running app). The app checks identity via Entra ID, reads/writes structured data in Azure SQL, and serves media from Blob Storage — five services, one coherent app.
Notice that no virtual machines appear here. This is a PaaS-first design: you wrote the app and clicked deploy; Microsoft runs the servers, patches the OS, and scales App Service automatically when traffic rises. That's the modern default for most teams.
09 Networking internals
The single "Networking" box from Figure 3 unfolds into the pieces that actually keep traffic private and safe. You won't need all of them for a hobby project, but any production system uses most.
Figure 7. Inside a VNet. Traffic enters the web subnet (guarded by a Network Security Group allowing only HTTPS), which alone may reach the data subnet. A private endpoint connects to a managed database over a private IP, and peering links to a second VNet — all without exposing anything publicly.
Virtual Network (VNet) — your own private, isolated network in the cloud, defined by an IP address range.
Subnet — a slice of the VNet that groups resources of a tier (web, app, data) so you can apply different rules to each.
Network Security Group (NSG) — a stateful firewall of allow/deny rules attached to a subnet or interface. The core tool for "who may talk to whom."
Private Endpoint — gives a PaaS service (SQL, Storage) a private IP inside your VNet, so traffic never traverses the public internet.
Peering — privately connects two VNets so they communicate as one network, even across regions.
VPN / ExpressRoute — bridge your on-premises network to the VNet, over the internet (VPN) or a dedicated private circuit (ExpressRoute).
10 Identity, security & API keys
Authentication is the part newcomers get wrong most often, so it's worth seeing the patterns explicitly. Azure offers a spectrum of ways to prove "I'm allowed to call this," from simplest-but-riskiest (a static key) to safest (no secret at all).
The authentication spectrum
API key / access key — a long static string. Simple, but a leaked key = full access. Fine for prototypes; rotate often.
Connection string — a key bundled with endpoint details in one string. Common for Storage, Service Bus, SQL.
SAS token (Shared Access Signature) — a scoped, time-limited, signed URL grant for storage. Better than handing out the account key.
Entra ID bearer token (OAuth 2.0) — a short-lived token obtained by signing in. The enterprise standard.
Managed identity — Azure itself vouches for your app; no secret is stored anywhere. The gold standard for service-to-service calls.
The Azure-style schema formats
Here are the canonical request shapes you'll actually type. The header name differs by service — that inconsistency is a frequent source of 401 errors, so note which is which.
# 1 — API KEY as a header (Azure AI / OpenAI style)
POST https://{resource}.openai.azure.com/openai/deployments/{deployment}/chat/completions?api-version=2024-10-21
api-key: {YOUR_KEY}
Content-Type: application/json
# 2 — API KEY, Cognitive / AI Services style (different header!)
POST https://{resource}.cognitiveservices.azure.com/...
Ocp-Apim-Subscription-Key: {YOUR_KEY}# 3 — STORAGE connection string (key embedded)
DefaultEndpointsProtocol=https;AccountName={name};AccountKey={key};EndpointSuffix=core.windows.net
# 4 — SAS token (scoped, expiring, appended to the URL)
https://{acct}.blob.core.windows.net/{container}/{blob}?sv=2024-11-04&ss=b&srt=o&sp=r&se=2026-12-31T00:00:00Z&sig={signature}# 5 — ENTRA ID bearer token (OAuth2 — recommended over keys)Authorization: Bearer {access_token}# 6 — MANAGED IDENTITY (no secret stored — the gold standard)# your code asks the local Azure SDK; Azure injects the token:
from azure.identity import DefaultAzureCredential
cred = DefaultAzureCredential() # resolves managed identity automatically
Figure 8. The recommended pattern. The app uses its managed identity to get a token from Entra ID, then calls the database with that token — no key in code. Anything that must be a secret (a third-party key) lives in Key Vault, never in source.
Never hard-code keys
Keys in source control are the #1 cloud leak. Prefer managed identity; when a real secret is unavoidable, store it in Key Vault and read it at runtime. Treat RBAC (role-based access control) as the master switch — grant the least privilege that works (e.g. "Storage Blob Data Reader," not "Owner").
11 Cost mechanics, with real numbers
The hardest cloud skill is predicting the bill. Pricing has a few moving parts; once you see them on one example, most services follow the same logic. (Figures below are illustrative ballparks — always confirm against the live Azure pricing calculator.)
You pay for…
Billed as
Example
Compute
per second/hour a VM or plan runs
A small VM ≈ a few cents/hour → ~$30–70/mo if left on 24/7
Storage
per GB-month stored
100 GB Blob (hot) ≈ a couple dollars/month
Egress (data out)
per GB leaving Azure
Inbound is free; outbound to the internet is charged
Requests / operations
per million transactions
Functions, storage reads/writes priced per call
Managed PaaS tier
fixed per chosen SKU/tier
App Service "Basic" vs "Premium" is a flat monthly rate
The three pricing modes
Pay-as-you-go — full price, zero commitment. Best for unpredictable or short-lived workloads.
Reserved instances / savings plans — commit to 1 or 3 years for steady workloads and save roughly 40–70%.
Spot — bid on spare capacity for up to ~90% off, but Azure can reclaim it anytime. Great for fault-tolerant batch jobs.
Cost hygiene
Set a budget with alerts per subscription on day one. Use auto-scale and auto-shutdown for dev VMs. Watch egress on data-heavy apps — it surprises people. The Azure Pricing Calculator and Cost Management dashboard are your two essential tools.
12 The Well-Architected Framework
Microsoft distills "is this a good design?" into five pillars. Treat them as a checklist to interrogate any architecture — including the Figure 6 app. They constantly trade off against one another, and naming the trade-off is half the job.
Figure 9. The five pillars. A "well-architected" system isn't one that maxes every pillar — it's one that makes deliberate, documented trade-offs among them for its specific goals.
13 Build Figure 6 yourself
Concepts stick when something real exists. Here's the example web app, deployed two ways: imperatively with the CLI (good for learning), then declaratively with Bicep infrastructure-as-code (good for repeating).
The fast way — Azure CLI
# sign in, then create a resource group
az login
az group create --name rg-demo-webapp --location eastus2
# an App Service plan + the web app on it (PaaS — no VM to manage)
az appservice plan create -g rg-demo-webapp -n plan-demo --sku B1
az webapp create -g rg-demo-webapp -p plan-demo -n demo-web-unique123 --runtime "PYTHON:3.12"
# a storage account for files/images
az storage account create -g rg-demo-webapp -n demostore123 --sku Standard_LRS
# tear the whole thing down when done — one command, zero leftovers
az group delete --name rg-demo-webapp --yes
The repeatable way — Bicep (Infrastructure as Code)
Instead of typing commands, you describe the desired state in a file and let Azure reconcile to it. Version-controlled, reviewable, redeployable identically every time.
# deploy the file (idempotent — run it again and nothing duplicates)
az deployment group create -g rg-demo-webapp --template-file main.bicep
Why IaC wins
The CLI is fine once; Bicep (or Terraform) is how teams rebuild an identical environment for dev, test, and prod, review infra changes in pull requests, and recover from disaster by re-running one file.
14 Hybrid & edge
Not everything lives purely in Azure's datacenters. Regulation, latency, or legacy hardware keep some workloads on-premises — and Azure has services to span that gap.
Azure Arc — projects servers, Kubernetes clusters, and databases running anywhere (your datacenter, another cloud) into the Azure control plane, so you govern and monitor them with the same tools.
Azure Stack (HCI / Hub / Edge) — runs Azure services on hardware in your facility, for data that legally cannot leave or sites with poor connectivity.
Hybrid networking — VPN and ExpressRoute (from §9) stitch your local network to Azure as one address space.
When it matters
Hybrid is common in manufacturing, automotive, healthcare, and finance — anywhere real-time control loops, factory-floor equipment, or strict data-residency rules keep compute physically close while still wanting cloud-grade management.
15 Azure vs AWS vs Google Cloud
The big three offer broadly the same capabilities with different names. A small translation table prevents most confusion when reading docs or tutorials written for another cloud.
Need
Azure
AWS
Google Cloud
Virtual machines
Virtual Machines
EC2
Compute Engine
Serverless functions
Functions
Lambda
Cloud Functions
Object storage
Blob Storage
S3
Cloud Storage
Managed Kubernetes
AKS
EKS
GKE
Managed SQL
Azure SQL Database
RDS
Cloud SQL
Identity
Entra ID
IAM
Cloud IAM
Azure's particular strengths: deep integration with the Microsoft ecosystem (Windows Server, Active Directory, Microsoft 365, .NET), strong hybrid-cloud tooling (Azure Arc) for companies keeping some workloads on-premises, and enterprise/compliance features. AWS leads on breadth and maturity; Google Cloud is often favored for data and ML. The right choice usually follows the skills and existing software a team already has.
16 Choose-a-service decision tree
"Which compute service should I use?" is the most common starting question. Walk the tree below — it mirrors how an architect actually narrows the choice.
I need to run some code. What best describes it?
Interactive · simplified. Real decisions also weigh cost, team skills, and existing tooling.
17 Glossary
The acronym soup, decoded.
IaaS / PaaS / SaaS
Infrastructure / Platform / Software as a Service — how much the provider manages.
VM
Virtual Machine — a rented computer in the cloud.
AKS
Azure Kubernetes Service — managed container orchestration.
Blob
Binary Large Object — Azure's object storage for files and unstructured data.
VNet
Virtual Network — your private, isolated network in Azure.
NSG
Network Security Group — firewall rules on a subnet or interface.
SKU
Stock Keeping Unit — the specific tier/size of a resource you pick (and pay for).
RBAC
Role-Based Access Control — granting permissions by assigning roles.
Entra ID
Microsoft's identity service (formerly Azure Active Directory / AAD).
SAS
Shared Access Signature — a scoped, time-limited signed access token for storage.
Managed identity
An Azure-managed credential so apps authenticate with no stored secret.
RG
Resource Group — a folder grouping related resources by lifecycle.
IaC
Infrastructure as Code — defining your environment in files (Bicep, Terraform).
ARM / Bicep
Azure Resource Manager — the deployment engine; Bicep is its readable language.
Egress
Data leaving Azure for the internet — the part of the bill people forget.
Region pair
Two linked regions for backup and disaster recovery.
AZ
Availability Zone — physically separate datacenter within a region.
WAF
Well-Architected Framework (also: Web Application Firewall — context tells which).
18 Practical notes
Watch your bill
Pay-as-you-go cuts both ways. A virtual machine left running, or an over-provisioned database, quietly burns money 24/7. Set budgets and cost alerts on day one, and prefer auto-scaling services that shrink when idle.
Start free
Azure offers a free tier with a credit for the first 30 days plus a set of services that stay free within limits. It's the right way to learn — build the Figure 6 app for near-zero cost before committing.
Three ways to drive it
You interact with Azure through the Portal (point-and-click, great for learning), the CLI / PowerShell (scriptable, repeatable), or Infrastructure-as-Code tools like Bicep and Terraform (define your whole environment in version-controlled files). Teams graduate from Portal to IaC as projects mature.
Security is shared
The provider secures the cloud infrastructure; you secure what you put in it — your configurations, access rules, and data. Default to least-privilege access in Entra ID, keep secrets in Key Vault, and never bake passwords into code.
A sensible learning path
Create a free account and explore the Portal until it stops feeling foreign.
Deploy one static website or simple App Service app — make something real exist.
Add a database and a storage account; wire them to your app (you've now built Figure 6).
Learn Entra ID basics — identity underpins everything else.
If pursuing it formally, the AZ-900: Azure Fundamentals certification covers exactly this monograph's ground.
Note: Azure service names and offerings change frequently (e.g. "Azure Active Directory" → "Microsoft Entra ID"). Always confirm current names and free-tier limits against the live Microsoft documentation linked above.