S068 · Azure Cloud — Identity, Storage, Networking, App Service
The four pillars of every real Azure workload — Entra ID + RBAC, Storage & Cosmos, VNets & Private Endpoints, App Service & Container Apps. What to pick and why.
🎯 Understand the four Azure pillars — Identity, Storage, Networking, Compute — well enough to design a small three-tier app on Azure without reaching for a tutorial.
Why this session exists
Azure is one of the top-3 clouds (with AWS and GCP) and, if you work in enterprise or Microsoft-shop territory, likely the one you'll ship on. It has ~200 services; you'll actually use ~10 daily. This session covers those ten under four crisp pillars so the console (and the Terraform) stops feeling like a wall of icons.
- Name the four Azure pillars and one flagship service in each.
- Explain the difference between Entra ID, Azure AD B2C, and RBAC assignments.
- Choose between Blob, Table, Cosmos DB, Azure SQL for a given workload.
- Design a VNet with subnets, NSGs, and a Private Endpoint to a PaaS service without asking Copilot.
Prerequisites
- S065 · Docker — you know what an image + registry are.
- S066 · Kubernetes basics — helpful when we cover AKS.
- S060 · Linux fundamentals — cloud VMs are just Linux boxes with cloud metadata.
(a) Intuition · 5 min
A large office building has four fundamental systems: security desk (who are you, where can you go), storage rooms (files, warehousing, cold storage), plumbing + wiring (the network that connects everything, plus firewalls between floors), and meeting rooms + offices (compute — where actual work happens).
Every tenant of the building needs all four. Getting them wrong costs you evenings; getting them right lets everyone do their job without thinking about the building.
Azure's four pillars map exactly: Identity (Entra ID + RBAC), Storage (Blob, Files, Cosmos, SQL), Networking (VNets, NSGs, Private Endpoints, Front Door), and Compute (VMs, App Service, AKS, Functions, Container Apps).
Every Azure architecture is some mix of these four. The 200 services are variations and specialisations — Azure ML is compute + storage + identity; Azure API Management is compute + networking + identity; Azure DevOps is identity + storage + compute.
The four pillars in one sentence each
- Identity — Microsoft Entra ID (formerly Azure AD). Every request in Azure is authenticated as some principal (user, service principal, managed identity) with role assignments controlling what it can do.
- Storage — Azure Storage Account (Blob is the flagship). Also Cosmos DB (globally distributed NoSQL), Azure SQL (managed OLTP), Data Lake Gen2 (hierarchical Blob for analytics).
- Networking — Virtual Network (VNet). Subnets carve up private IP space; NSGs are stateful firewalls; Private Endpoints let PaaS services (Storage, Cosmos) live inside your VNet.
- Compute — App Service (managed web hosting) for most CRUD apps; AKS (managed K8s) for microservice fleets; Functions for serverless events; Container Apps for ‘K8s without the K8s’.
A quick history so the naming makes sense
- 2008Windows Azure launches at PDCOriginally a PaaS-only offering (Web + Worker roles). Renamed ‘Microsoft Azure’ in 2014.
- 2013IaaS + VMs GAAzure catches up with EC2. Linux VMs become first-class.
- 2014Satya Nadella era + open source push‘Microsoft loves Linux’. Kubernetes-first cloud strategy from ~2017.
- 2019Azure Arc + hybrid strategyManage on-prem and multi-cloud resources through Azure's control plane.
- 2023Azure AD renamed Microsoft Entra IDIdentity becomes its own brand family (Entra ID, Entra Verified ID, Entra Permissions Management).
- 2024Azure Container Apps + Fabric‘K8s without the ops’ (ACA) and unified data platform (Fabric = Synapse + Data Factory + Power BI).
(b) Visual walkthrough · 15 min
A reference three-tier app on Azure — what talks to what
The storage-service decision tree
Big flat object store · pennies/GB
- Anything unstructured: images, PDFs, backups, logs
- Hot / Cool / Cold / Archive access tiers
- Global reads via read-access geo-redundant (RA-GZRS)
- Not for OLTP — no transactions, no indexes
Global NoSQL · single-digit ms
- Multi-region writes, tunable consistency (5 levels)
- APIs: SQL/NoSQL, MongoDB, Cassandra, Gremlin
- Priced per RU/s + storage — expensive at scale
- Fit: session store, product catalogue, user profiles, IoT ingest
Managed relational OLTP
- T-SQL you already know · zero patching
- Elastic Pools for many small DBs sharing capacity
- Serverless tier for spiky workloads (auto-pause)
- Fit: existing SQL Server workloads, complex joins, ACID
Petabyte-scale analytics
- Hierarchical namespace on top of Blob
- Read directly from Spark, Synapse, Databricks
- Delta / Iceberg tables for ACID on parquet
- Fit: warehouse, ML feature stores, event lakes
The Identity model — what is a Managed Identity, and why do you care?
Three principal types in Entra ID
Networking — the five pieces you'll wire up
Your private IP space in a region. Non-overlapping with other VNets you might peer to.
Slice the VNet into logical zones — /24 for AKS, /26 for App Service, /28 for the DB, /27 for the private endpoints.
Stateful firewall rules attached to a subnet or NIC. Default deny-inbound-from-internet is applied unless you allow.
Give a PaaS service (Cosmos, Blob) a private IP inside YOUR subnet. Traffic never touches the public internet.
L7 public entry point. Front Door is global anycast + CDN + WAF; App Gateway is regional. Pick Front Door for user-facing apps.
Compute — pick one; don't shop
‘Managed web hosting’
- Deploy a container OR a git push, auto-provisioned
- Slots for blue/green (staging + prod swap in 5 s)
- Auto-scale on CPU/queue, SSL managed
- Fit: most CRUD web apps, APIs — starts here
‘K8s without the K8s’
- Serverless containers, scale to zero
- KEDA-driven autoscaling (Kafka, HTTP, cron)
- Dapr sidecar integration
- Fit: microservices, event handlers, replacement for App Service for containers
Full Kubernetes if you need it
- Everything from S066/S067 applies
- Control plane free; you pay for nodes
- Deep integration with Entra ID, Azure Policy, ACR
- Fit: existing K8s workloads, multi-tenant fleets
Serverless events
- One function per file/handler, triggers = HTTP, Queue, Blob, Timer
- Consumption plan = pay-per-execution
- Cold starts + short max duration (10 min consumption)
- Fit: cron jobs, small event processors
"Azure regions are independent datacenters, and a region is a failure domain. If I deploy across two availability zones I'm protected from anything short of losing the whole region."
Zones protect against datacenter-level failures — power, cooling, a network fabric fault in one building. They do not protect against a regional control-plane issue, a bad configuration deployed region-wide, a subscription-level quota exhaustion, or a dependency your service has on a single-region resource. Zone redundancy is necessary and it is not sufficient, and the failures that actually cause multi-hour outages are usually control-plane or configuration failures rather than physical ones.
The myth is sticky because zone redundancy is the thing you can configure and see in a checkbox, so it becomes the mental summary of "we are highly available". Physical redundancy is also the failure mode that is easiest to reason about. The failures that get missed are the ones with no checkbox: a Key Vault in one region that every region depends on, a resource-group-scoped policy, a DNS record with a single origin.
Find your true single points of failure by tracing dependencies rather than trusting your topology diagram:
# every resource and its actual location
az resource list --query "[].{n:name, loc:location, t:type}" -o table
# which of these are referenced by services in OTHER regions?
# key vaults, storage accounts, private DNS zones and
# container registries are the usual hidden singletons
az account list-locations --query "[?metadata.regionType=='Physical'].{name:name, pair:metadata.pairedRegion[0].name}" -o tableWhy does every cloud provider organise resources into a hierarchy — management group, subscription, resource group — instead of one flat pool you tag?
- 1A cloud platform must enforce access control, quotas, billing separation and policy across millions of resources belonging to mutually distrusting tenants.forced by · multi-tenancy means isolation is a correctness requirement, not a convenience
- 2Evaluating any of those against a flat set requires a predicate over every resource, and predicates over tags are mutable by whoever can edit tags.forced by · if a permission boundary depends on a tag, then editing a tag is a privilege escalation
- 3Therefore the boundary must be structural and immutable-ish — something a resource belongs to at creation and cannot silently change.forced by · an access boundary that can be altered by the thing it constrains is not a boundary
- 4A hierarchy additionally allows policy to be inherited, so a rule set at the top applies to everything below without enumerating it, and cannot be removed by someone lower down.forced by · containment gives you a natural, cheap "applies to all descendants" semantics with a clear precedence order
- 5Quotas and billing then attach naturally to levels of that hierarchy, because a level is a set with a known owner.forced by · a limit needs an entity to be enforced against, and containment defines exactly such entities
Therefore the hierarchy is the enforcement substrate for isolation, policy inheritance, quota and billing simultaneously. Tags complement it for reporting; they cannot replace it for enforcement.
And note what this predicts: quotas are enforced per subscription per region, so a workload that grows will hit a limit that is invisible until it blocks a deployment — and the fix is a support request with lead time, not a code change. It also predicts that the subscription is your real blast radius boundary: an error affecting a subscription affects everything in it, which is exactly why separating production from non-production at the subscription level matters far more than separating them by resource group or naming convention.
Every cloud resource has two halves. The control plane creates, configures and deletes it — that is ARM, the portal, the CLI, Terraform. The data plane is the resource actually doing its job: serving queries, storing blobs, running containers. They have separate endpoints, separate authentication, separate SLAs and separate failure modes.
An outage in one does not imply an outage in the other. Your VMs keep running while ARM is degraded — you just cannot create new ones.
- Design so that a control-plane outage does not become a data-plane outage. Anything that requires creating a resource to recover — scaling out, failing over by reconfiguration, provisioning a replacement — is unavailable exactly when you need it most. Pre-provision your recovery capacity.
- Managed identity over secrets, everywhere it is supported. The identity is issued and rotated by the platform, so there is no credential to leak, expire unnoticed, or check into a repository. A connection string in configuration is a future incident with a long fuse.
- Understand each service's scaling and pricing unit, because it determines both cost and failure behaviour: request units in Cosmos DB, DTUs or vCores in SQL, DWUs in Synapse. Throttling at the limit produces retriable errors that look like transient network faults until you correlate them with the limit.
- Private endpoints change DNS resolution, not just routing. This is why a service works from one network and fails from another with a confusing name-resolution error — the private DNS zone must be linked to every virtual network that needs to resolve it.
Fire this model when you see: a deployment failing while running workloads are fine · intermittent 429s under load · a service that resolves to a public IP from inside the VNet · a failover plan that depends on provisioning something · a subscription quota discovered during an incident.
How do you carve up subscriptions and resource groups for a platform with multiple teams and environments?
Separate production into its own subscription on day one — that boundary is nearly free to establish early and extremely expensive to retrofit, because moving resources between subscriptions ranges from disruptive to impossible depending on the service.
Split further by team only when you feel a specific pain: quota contention, cost attribution arguments, or blast radius concerns. Each new subscription is a recurring management cost, so add them in response to evidence rather than in anticipation. The one thing worth doing before you have any pain at all is enforcing ownership and environment tags at creation time via policy — that is the metadata you cannot retrofit, and everything else can be reorganised later.
(c) Hands-on · 25 min
Deploy a Container Apps app that uses a Managed Identity to read a secret from Key Vault — no secrets in code, no client IDs floating around. Everything via Azure CLI so you see the exact primitives.
What each block does
Anatomy of the deployment
# Rough outline — expand per Azure docs
az network vnet create -g $RG -n vnet-s068 --address-prefix 10.10.0.0/16 --subnet-name snet-pe --subnet-prefix 10.10.1.0/24
az network private-endpoint create -g $RG -n pe-kv -v vnet-s068 --subnet snet-pe \
--private-connection-resource-id $(az keyvault show -n $KV --query id -o tsv) \
--group-id vault --connection-name pe-kv-conn
az keyvault update -n $KV --public-network-access Disabled
# Container Apps in the same VNet still reach KV; the world doesn't.You've just moved from "public with a firewall" to "no public surface at all". This is the standard enterprise posture on Azure.
(d) Production reality · 15 min
An Azure AD (now Entra ID) rollout deployed a change to the token service in one region. A latent bug caused key material to be inaccessible; token issuance failed. Cascading impact: every Azure service that authenticates via AAD started returning 401 — Office 365, Xbox Live, Teams, and thousands of customer apps.
Because AAD is a global control plane, the blast radius was near-universal.
A state-affiliated actor stole a Microsoft consumer signing key and used a validation bug to forge tokens for enterprise Exchange Online mailboxes — including US government tenants. Attackers read emails for ~a month before detection.
Common footguns you'll hit
- Confusion of subscriptions, resource groups, tenants — a tenant is your Entra ID directory; subscriptions live inside; resource groups organise resources within a subscription. Get the hierarchy wrong and you make a resource nobody has access to.
- Role assignment propagation delay — RBAC changes take up to ~5 min to propagate. Add a sleep in scripts; expect the first call after a change to sometimes 403.
- Public endpoints on Storage / Cosmos by default — new accounts are public-network-enabled. Turn it off; add Private Endpoints or firewall rules.
- Az CLI logged in as the wrong subscription —
az account set --subscription "your-sub". Add this to every script; don't rely on default context.
Where this shows up in the rest of the plan
(e) Recall + stretch · 10 min
Explain-out-loud test
- What are the four Azure pillars and which service anchors each?
- Why is Managed Identity better than a Service Principal with a secret?
- When would you pick App Service over AKS, and vice versa?
What comes next
Hub: The 6-Month Learning Plan
Part of a 130-session evergreen learning series. Session structure: intuition → visual → hands-on → production war stories → recall. Duration: 90 minutes.