Azure, service by service.
Nine pages, one per service or service-family, each ending in an az CLI lab you can actually run. The goal is the model, not the menu: know how a resource group scopes everything inside it, why Entra ID sits above every subscription, and what a Cosmos DB consistency level actually buys you. Pairs with the Cloud Codex above, which covers the same ground organised by topic instead of by service.
What this is, and why service-shaped
The Cloud Codex above is organised by topic — compute, storage, networking, identity, databases. That's the right shape for system-design conversations. This subtree is organised by Azure service, because that's the shape you need when you're actually building or debugging on Azure: someone tells you "the Function behind the Application Gateway is returning 503s," and the move is to know exactly which layer to look at before you start clicking through the portal.
Each page covers the same five-or-six things: the model the service implements, the parts you'll actually configure, how it bills, what breaks at scale, what to use it for and what not to, and a small CLI lab you can run to feel it work. Reading sequence is recommended but not strict — most pages cross-link to the others where it matters.
How Azure thinks differently from AWS
If you know AWS, the services map roughly one-to-one — Blob Storage is S3, Cosmos DB is DynamoDB with more dials, Functions is Lambda. The mental model underneath does not map, and that's where AWS habits get you in trouble.
- Everything lives in a resource group. In AWS, resources float in a region inside an account and tagging discipline is how you group them. In Azure, every resource belongs to exactly one resource group from the moment it exists, and the group is a real boundary: you can apply RBAC to it, see its combined cost, and delete it in one command. Lifecycle by group is the idiom, not a convention.
- ARM is the declarative control plane. Every create, update, or delete — portal, CLI, SDK, Bicep — goes through Azure Resource Manager as a declarative request against a resource provider. There's one consistent API shape, one place policy is enforced, and one activity log. AWS gives you a per-service API and bolts CloudFormation on top; Azure built the deployment engine in first.
- Entra ID is the centre of gravity. AWS IAM lives inside each account. Entra ID sits above subscriptions: one tenant holds your users, groups, and service principals, and subscriptions trust it. RBAC, managed identities, AKS sign-in, even SaaS app access all hang off the same directory. You can't reason about Azure access control without starting from the tenant.
- The enterprise and hybrid tilt is real. Azure's defaults assume an organisation that already runs Active Directory, has compliance teams, and keeps some workloads on-premises. Management groups, Azure Policy, Arc, and ExpressRoute aren't add-ons — they're why many companies pick Azure in the first place. Features often arrive enterprise-grade and developer-rough, which is the opposite of how AWS tends to ship.
Each page calls out the AWS equivalent where it helps, and flags the places where carrying the AWS model over would lead you to a wrong design.
The map
The map.
How Azure is organised before any workload exists — tenants, subscriptions, resource groups, the identity plane, and the network. Read these first; everything later assumes you know where a resource lives and who is allowed to touch it.
- 01
Foundations
Tenants, subscriptions, resource groups, and ARM — the hierarchy every resource hangs off.
Read - 02
Entra ID
Tenants, service principals, managed identities, and RBAC — who you are and what you can do.
Read - 03
VNets
Regional VNets, NSGs, peering, Private Link, and telling the four load balancers apart.
Read
Compute.
The three ways your code runs — raw VMs, managed Kubernetes, and functions. Each carries its own pricing model, its own failure modes, and its own opinion about how much of the machine you should see.
- 04
Virtual Machines
VM series, managed disks, availability zones vs sets, VMSS, and where Spot pricing fits.
Read - 05
AKS
Node pools, AAD integration, and the CNI choices that decide how your pods get IPs.
Read - 06
Functions
Hosting plans, triggers and bindings, and Durable Functions for stateful orchestration.
Read
Data & events.
Where state lives and how services tell each other things happened — object storage, the planet-scale database, and the messaging family. This is where most of the interesting design trade-offs sit.
- 07
Blob Storage
Storage accounts, blob types, access tiers, and LRS / ZRS / GRS redundancy choices.
Read - 08
Cosmos DB
Request units, the five consistency levels, partitioning, and global distribution.
Read - 09
Service Bus & Event Hubs
Queues and topics vs the event log vs Event Grid — picking the right messaging shape.
Read
Planned Azure SQL, Key Vault, and Front Door are next in the queue — they'll slot into the data and edge phases when they land.
How the labs work
Every page closes with a section called "Build it yourself" — an ordered list of az CLI commands that creates the resource, exercises it, observes it, and tears it down. You won't understand a service from reading about it; you understand it from watching the first az storage blob upload succeed, then changing the access tier and seeing what the next read costs.
- Use a dedicated subscription. A free Azure account comes with $200 of credit for 30 days. Set a budget alert at $25 in Cost Management so you find out fast if you forget to tear something down.
- CLI first. Every lab is written for the az CLI. The portal is friendlier when a service is new to you; the CLI is what you'll script, and it makes the ARM request underneath visible.
- Tear down by resource group. Every lab creates its resources inside one resource group, so cleanup is a single az group delete. This is the best habit Azure's model gives you — use it from day one.
- Region affects availability. Not every region has availability zones, and some VM series are missing in smaller regions. eastus and westeurope have nearly everything. Pick one region and stay in it for the whole sequence.
brew install azure-cli on macOS, or the official install script on Linux), run az login, set your subscription with az account set --subscription <id>, and verify with az account show. From here every page assumes those four things are true.Adjacent reading
- Cloud Codex (topic shape). Same ground organised by problem — compute, storage, networking, identity, databases, multi-region, observability, cost. Read this first if you don't already know what services to look up.
- AWS Codex. The sibling subtree. If you're moving between the clouds in either direction, reading the matching pages side by side is the fastest way to see where the models diverge.
- Kubernetes Codex. For the AKS side of containers — the page here covers the Azure-side configuration; that codex covers what's running inside.
- Networking Codex. The protocol-layer companion to VNets, NSGs, and the load-balancer family.
- Distributed Systems Codex. The consistency and replication background that makes Cosmos DB's five consistency levels make sense instead of sounding like marketing.