Chapter 12 · AZ-305 bridge

The Azure Well-Architected Framework

CAF (chapter 11) prepared the whole organisation. The Well-Architected Framework (WAF) zooms in on one workload and asks: is it reliable, secure, cost-efficient, easy to operate, and fast enough? You already made many WAF decisions in this guide without calling them that. In the lab you review the environment you built as an architect would.

What WAF is

The Azure Well-Architected Framework is a set of guiding principles for designing and improving a workload: the collection of application code, data, and infrastructure that together deliver one business outcome (a web shop, a payroll system, a data platform).

WAF is built on five pillars. For each pillar it gives you:

• Design principles: the high-level goals.
• A design review checklist: concrete questions to check your design against.
• Recommendations: how to implement each checklist item on Azure.
• Trade-offs: what you give up in other pillars.

WAF comes with tools you've partly met already:

• Azure Advisor (chapter 2): its recommendation categories are the five WAF pillars, and the Advisor score measures how well your resources follow them.
• Azure Well-Architected Review: a free self-assessment questionnaire on Microsoft Learn that scores a workload per pillar and gives a list of recommendations.
• Service guides: a WAF page per Azure service ("Architecture best practices for Azure Virtual Machines", "…for App Service", …), with the pillar checklists applied to that service.
• Azure Architecture Center: reference architectures that apply WAF to common scenarios.

Reliability

Goal: the workload keeps doing what it's supposed to, and when something fails (something always fails), it recovers to a working state quickly.

Start with what the business needs. Three numbers drive almost every reliability decision:

• Service level objective (SLO): the availability you target for the workload, e.g. 99.9% per month. (An SLA is what Microsoft promises for one service.)
• Recovery time objective (RTO): how long the workload may be down after a disaster.
• Recovery point objective (RPO): how much data (measured in time) you may lose.

Design principles, with what you used in this guide:

• Design for business requirements: don't build 99.99% when 99.9% is enough; it costs more.
• Design for resilience: remove single points of failure with redundancy: VMs in two zones (chapter 5) behind a zone-redundant load balancer with health probes (chapter 6), ZRS/GZRS storage (chapter 7).
• Design for recovery: backups (chapter 10), a disaster recovery plan to a second region (Site Recovery, chapter 10), and test it (test failover).
• Design for operations: health monitoring and alerts (chapter 9) so you notice problems before users do.
• Keep it simple: every extra component is something else that can fail.

Composite SLA

When a request passes through several services in series, all of them must work, so you multiply their SLAs. The result is always lower than the weakest component:

Web app (App Service) 99.95%  ×  Azure SQL Database 99.99%
= 0.9995 × 0.9999 = 0.99940  →  99.94%  ≈ 26 minutes of downtime per month allowed

Redundant copies in parallel do the opposite: the combination fails only if all copies fail. Two independent deployments at 99.9% each give 1 − (0.001 × 0.001) = 99.9999%. That's why multi-zone and multi-region designs reach higher numbers than any single service.

Security

Goal: protect the workload's confidentiality (only the right people see the data), integrity (data and systems aren't tampered with) and availability (it can't be taken down), the CIA triad.

WAF's security pillar applies Zero Trust and defense in depth (chapter 6) to one workload:

• Plan your security readiness: know your data classification, compliance needs and who is responsible for what (shared responsibility).
• Design to protect confidentiality: least-privilege RBAC (chapter 2), managed identities and Key Vault instead of stored secrets (chapter 6), private endpoints (chapter 7), encryption at rest and in transit.
• Design to protect integrity: secure supply chain for code and images (ACR, chapter 8), signed deployments, backups that can't be deleted (soft delete, immutable vaults, chapter 10).
• Design to protect availability: DDoS Protection, WAF on Front Door / Application Gateway, rate limits.
• Sustain and evolve your security posture: Defender for Cloud secure score, patching, incident response drills.

Cost Optimization

Goal: get the most business value per euro, not simply spend the least. A cheap design that fails its SLO isn't optimised.

• Develop cost-management discipline: budgets and alerts (chapter 2), tags for showing which team spends what, regular reviews.
• Design with a cost-efficiency mindset: pick the cheapest option that meets the requirements: PaaS instead of VMs, LRS instead of GRS for non-critical data, the Developer tier of Bastion for a lab.
• Design for usage optimisation: pay for what you use. Autoscale (VMSS, App Service, Container Apps scale to zero), deallocate VMs you don't need, lifecycle policies to cooler storage tiers (chapter 7).
• Design for rate optimisation: pay less for what you use: Azure Reservations (1 or 3 years for specific resources), Azure savings plan for compute (an hourly commitment across compute services), Spot VMs for interruptible work, Azure Hybrid Benefit (reuse Windows Server and SQL Server licenses), Dev/Test pricing.
• Monitor and optimise over time: Cost Management analysis and Advisor cost recommendations (unused disks, idle public IPs, oversized VMs).

Two calculators help before you build: the Azure pricing calculator (what will this design cost per month?) and the TCO calculator (on-premises costs compared to Azure).

Operational Excellence

Goal: the team can deploy, change and run the workload safely and predictably, and keeps getting better at it.

• Embrace DevOps culture: shared ownership between development and operations, blameless post-incident reviews.
• Establish development standards: version control, code reviews, naming and tagging conventions (chapter 11).
• Evolve operations with observability: metrics, logs, alerts and dashboards (chapter 9), so you can see what's happening and why.
• Deploy with confidence: infrastructure as code (Bicep, chapter 4) so environments are reproducible; safe deployment practices such as deployment slots and swaps (chapter 8), progressive rollouts, and a tested rollback.
• Automate for efficiency: automate repetitive tasks (patching with Update Manager, scaling, remediation tasks for Policy).

Performance Efficiency

Goal: the workload handles the load users put on it, efficiently, also when demand changes.

• Negotiate realistic performance targets: e.g. "95% of page loads under 1 second at 500 concurrent users".
• Design to meet capacity requirements: choose the right service, size and tier; scale out (more instances) rather than scale up (bigger instances) where possible, because scaling out has no hard ceiling and adds redundancy.
• Achieve and sustain performance: caching (Azure Cache for Redis, CDN / Front Door), partitioning data, moving long work to queues and background functions (chapter 8), placing resources close to users.
• Improve efficiency through optimisation: load testing (Azure Load Testing), and monitoring to find bottlenecks.

Trade-offs between the pillars

Almost every decision helps one pillar and costs another. WAF asks you to make trade-offs on purpose and write them down (for example in an architecture decision record), instead of discovering them later.

CAF and WAF together

A workload team builds a well-architected workload (WAF) inside an application landing zone that the platform team built according to CAF.

Self-check

This lab is a design review. You look at the environment from chapters 1–10 (use the diagram on the overview page) and at your subscription today, the way an architect reviews a workload. Most tasks are on paper; the Azure tasks only read, so they cost nothing.

The variables from chapter 0 ($RG, $LOC, $LOC2, $INIT, $ST, $ACR, $MYIP) load automatically in every terminal; if they don't, run . ~/az104.env. Any other variable a task needs is set at the top of that task's Azure CLI solution, so every solution works on its own in a fresh terminal.

1. Task · on paper

   Find the single points of failure

   Treat the lab environment as if it were a production web shop. List at least four components that are a single point of failure or that wouldn't survive a zone or region outage, and for each, one change that would fix it.

   Done when

   • You have four or more weak spots, each with a fix, and you've noted which fix you'd skip because it isn't worth the cost.
   Hint

   Walk the request path from the user to the data: public IP → load balancer → VMs → storage. Then look at what supports it: DNS, admin access, monitoring, backup.

   Example answer

   Weak spot	Fix
   The whole web tier runs in one region; only vm-web2 was replicated with Site Recovery	Replicate both VMs (or deploy a second region with IaC) and put Front Door or a cross-region load balancer in front
   Two VMs only: if one zone fails, a single VM carries all traffic	A VM scale set across three zones with autoscale
   The App Service plan was one S1 instance	Premium v3 with zone redundancy (at least 3 instances)
   Container App with min replicas 0: cold starts, no zone redundancy guaranteed	Min replicas ≥ 2 in a zone-redundant environment
   Bastion Developer: shared, one session, no SLA	Bastion Basic/Standard in the hub (or accept it: admin access isn't on the user path)
   Storage was RA-GRS: the primary copies are all in one zone, so a zone outage means failing over to the secondary region, with possible data loss	RA-GZRS (zone-redundant in the primary, geo-replicated too)

   A reasonable cost decision: keep Bastion Developer and accept it, because admin access doesn't affect users.

2. Task · on paper

   Calculate the composite SLA

   The web path is: Standard load balancer (99.99%) → two VMs across availability zones (99.99%) → files from a storage account (RA-GRS, assume 99.9% for writes). Calculate:

   • the composite SLA of the path;
   • how many minutes per month of downtime that allows (use 730 hours per month);
   • whether the path meets a business SLO of 99.95%, and if not, which component you'd improve first.
   Done when

   • You have a percentage, a number of minutes, and a yes/no with a reason.
   Solution

   0.9999 × 0.9999 × 0.999 = 0.99880   →  99.88%
   allowed downtime = (1 − 0.9988) × 730 h × 60 = 0.0012 × 43,800 min ≈ 53 minutes/month

   No, 99.88% is below 99.95%. The storage dependency is the weakest link. Options: make the app tolerate storage hiccups (cache the files locally or on a CDN, retry), or check the storage SLA for the redundancy you choose. Improving the 99.99% components further would hardly change the result.

3. Task

   Read Advisor through WAF glasses

   Open Azure Advisor for your subscription and find:

   • your Advisor score and the score per category;
   • for each category that has recommendations, one recommendation and the WAF pillar it belongs to.
   Done when

   • You've written down the overall score and at least two recommendations with their pillar.
   Hint

   After the chapter 10 cleanup there may be few or no resources left, and Advisor's list can be short. That's fine: note the categories and what an empty category means. Recommendations refresh about once a day.

   Solution · Portal

   Advisor → Overview (or Advisor score): the five categories are Reliability, Security, Cost, Operational excellence, Performance, the WAF pillars. Typical findings: "Enable soft delete for blobs" (reliability), "Machines should have vulnerability findings resolved" (security, from Defender for Cloud), "Right-size or shut down underutilised VMs" (cost).

   Solution · Azure CLI

   az advisor recommendation list \
     --query "[].{pillar:category, impact:impact, problem:shortDescription.problem, resource:impactedValue}" -o table

4. Task

   Run a Well-Architected Review

   Open the Azure Well-Architected Review on Microsoft Learn (link under "Read more") and assess the lab web shop for at least the Reliability and Cost Optimization pillars. Answer honestly for the environment as you built it.

   Done when

   • You have a score per assessed pillar.
   • You've picked the three recommendations you'd do first, and you can explain why those three.
   Hint

   You can do the assessment without signing in, but signing in with a Microsoft account saves it so you can compare a later review with this one. It takes about 15–20 minutes for two pillars.

   What a good answer looks like

   Your scores will differ, but the top recommendations usually include: define SLO, RTO and RPO for the workload (everything else depends on them), test the DR plan regularly, and set budgets and tag for cost ownership. Choose the ones that remove the most risk for the least effort; that's exactly the reasoning AZ-305 wants.

5. Task · on paper

   Make a trade-off on purpose

   Fabrikam (chapter 11) wants TrackIt to have an RTO of 12 hours and an RPO of 1 hour if the West Europe region fails, on a tight budget. Choose between these designs and write a short decision record (context, decision, consequences):

   • A. Active-active in two regions behind Front Door, with geo-replicated database.
   • B. App Service in one region, deployed with Bicep; database with geo-redundant backups; in a disaster, redeploy to the paired region from code and restore the latest backup.
   • C. One region, nightly backups only.
   Done when

   • Your record names the chosen design, why it meets RTO and RPO, and which pillar pays for it.
   Example answer

   Decision: B. Redeploying an App Service app from Bicep takes minutes. For Azure SQL Database, Microsoft documents geo-restore from geo-redundant backups with an RTO of up to 12 hours and an RPO of 1 hour, which exactly matches the requirement. (Always check these figures for the database service you actually use.)

   Rejected: A meets the targets with room to spare but roughly doubles the cost, which conflicts with the tight budget. C fails the RPO (up to 24 hours of data lost) and risks the RTO (no tested way to rebuild the app elsewhere).

   Consequences: Cost stays low; reliability depends on the redeploy actually working, so operational excellence pays: the team must keep the Bicep current and rehearse the recovery twice a year.