Capstone: Deploying a Simple Web Application on Azure

AWS Fundamentals Chapter 10 built a small photo-upload web application — metadata in a database, originals in object storage, an automated thumbnail job. This capstone deliberately rebuilds the exact same real application on Azure, using every one of this course's own nine chapters — letting the two capstones be compared side by side, service for service, on genuinely different real architecture.

Step 1 — Region & Availability Zone Planning

Chapter 1: before anything else, confirm the target Region actually supports Availability Zones — a real, necessary check that AWS Fundamentals' own capstone never needed, since every AWS Region always has them.

Step 2 — A Scoped Managed Identity

Chapter 2: a Managed Identity is attached to the web VM, with an RBAC role assignment scoped narrowly to the Resource Group holding the application's own Storage Account — Contributor, not Owner, since the VM needs to manage resources but never needs to grant access to others.

Step 3 — VNet & Subnet

Chapter 5: one VNet, one subnet — genuinely simpler than AWS Fundamentals' own capstone, which needed separate public and private subnets per AZ. Because an Azure subnet spans every AZ in the region at once, both the web VM and the database sit in the same subnet, with each resource's own zone chosen independently at creation time.

Step 4 — The Web VM

Chapter 3: a D-series VM (the real, balanced general-purpose default) runs the application. Its own NSG allows inbound traffic only from Application Gateway (Step 8) — never directly from the internet.

Step 5 — Blob Storage

Chapter 4: the application's photo container uses ZRS redundancy (real 12-nines durability, since the target region supports Availability Zones per Step 1), with versioning enabled. Any SAS tokens issued to the application are scoped narrowly to this one specific container, with a real, genuine expiration date — a direct, deliberate lesson learned from Chapter 4's own 2023 Microsoft AI research leak case study.

Step 6 — Azure SQL Database

Chapter 6: a vCore-based, General Purpose-tier Azure SQL Database stores photo metadata (uploader, timestamp, blob key) — General Purpose, not Business Critical, since this small application doesn't need the real ~2.7x cost of Business Critical's own extra replicas.

Step 7 — An Azure Function for Thumbnails

Chapter 7: a Blob Storage trigger fires an Azure Function on the Flex Consumption plan the moment a new photo lands, generating a thumbnail and writing it back via a Blob output binding — the function's own code never constructs a Storage SDK client at all, a real, direct contrast with AWS Fundamentals' own capstone Lambda function, which reads and writes S3 via manual SDK calls.

Step 8 — Application Gateway & a Virtual Machine Scale Set

Chapter 8: Application Gateway (Layer 7, regional — genuinely the right real choice here, since this is a single-region deployment, not Front Door's global scope) sits in front of a VM Scale Set running the web tier, with autoscale rules holding CPU near a target. The scale set's own orchestration mode — Flexible — is chosen deliberately and explicitly at creation, since that real decision can never be changed afterward.

Step 9 — Azure Monitor & a Budget With a Real Action Group

Chapter 9: the Azure Monitor Agent is deployed to the web VM specifically so its own real guest-OS-layer memory and disk-space metrics actually exist to alert on — closing the exact gap the chapter's own four-layer model warns about. A Budget is set at a real, planned monthly threshold, with an Action Group attached directly to it — a real, more automated response path than AWS Fundamentals' own capstone Budget had, which was left deliberately unattached to any automated action.

The Full Picture

What's Still Out of Scope, Honestly

Matching AWS Fundamentals' own capstone's honesty, this deployment deliberately stops short of several real, genuine next steps: no CI/CD deployment pipeline, no Azure Front Door or WAF, no Azure DNS configuration, no cross-region disaster recovery, and no containerization (AKS) as a VM alternative. Each is a real, legitimate next step for a production system, named honestly rather than treated as solved here.

Closing the Course

From Chapter 1's real 2008 origin story and global infrastructure through this chapter's own working, multi-service architecture — every chapter covered one genuine piece of what it actually takes to run something real on Azure, and, deliberately, how that differs from the equivalent AWS approach at almost every single step. Compute, storage, networking, databases, serverless, scaling, and monitoring together — not any single service in isolation — are what make a real Azure deployment resilient and secure.

Hands-On Exercises