In the previous lesson you drew the complete blueprint of Contoso Airlines and the decision table that holds it up. The uncomfortable question remains: is it any good? Anybody can defend their own architecture — there is always a reason for what you decided yourself — and that is why organizations need a common language, detached from the pride of whoever designed each piece, to discuss whether a platform stands up.

That language is the Azure Well-Architected Framework: five pillars, a set of design principles per pillar and, above all, a method for finding architectural debt before it blows up. It is not a certification or a list of mandatory services: it is a set of questions anybody can put to any architecture, including their own.

This lesson goes through the five pillars auditing Contoso's platform pillar by pillar — what it meets, what it does not meet and what was consciously decided against — pauses on the most valuable thing the framework has to offer, which is the trade-offs between pillars, turns the review into a process with participants, cadence and an action plan, and finishes with a checklist you can take into your own job tomorrow morning.

A note on naming: in this course "WAF" has so far meant web application firewall (wafcontosoglobal). The Well-Architected Framework shares the acronym by accident. To avoid confusion, this lesson always calls it Well-Architected or "the framework".

1. What the framework is and what it is really for
2. The five pillars at a glance
3. Reliability
4. Security
5. Cost Optimization
6. Operational Excellence
7. Performance Efficiency
8. The trade-offs between pillars
9. The Well-Architected review as a process
10. Tools: the official assessment and Azure Advisor
11. Guidance for specific workloads
12. The framework day to day
13. Architecture checklist
14. Common Mistakes and Tips
15. Exercises
16. Conclusion

The Well-Architected Framework is Microsoft guidance that structures the design and review of workloads — not entire subscriptions, but concrete systems with an owner and users — around five pillars. Each pillar contributes design principles, checklists, recommendations and known trade-offs.

Its three real uses, in order of importance:

1. A common language. When somebody says "this is reliability debt" instead of "this is badly done", the conversation stops being personal. The framework turns opinions into categories.
2. Early detection. The framework's questions find the missing rollback plan, the backup that was never restored or the secret that is never rotated before an incident discovers them at three in the morning.
3. Making trade-offs explicit. No system scores highly on all five pillars at once. The framework forces you to say out loud what you are sacrificing and in exchange for what.

And two things it is not, which is worth knowing before you start: it is not a list of requirements to be met 100% — a platform that met everything would be extortionately expensive and unmanageable — and it does not replace judgment: the framework asks, the business context supplies the answer.

Design principles: design for failure, assuming every component will go down; define measurable availability, RPO and RTO targets agreed with the business; add redundancy at the right layer; use retries, timeouts and circuit breakers; simplify, because every dependency adds probability of failure; and test recovery, because a backup that has never been restored is not a backup.

Design principles: zero trust — do not trust the network, always verify; least privilege; defense in depth; encryption in transit and at rest; no credential in the code; segmentation; and detection with the ability to respond.

Design principles: match spending to business value; model and forecast cost before building; measure with a unit indicator; optimize before committing; and make cost a shared responsibility rather than an annual audit.

Design principles: infrastructure as code; automate everything repetitive; small, frequent, reversible deployments; end-to-end observability; living documentation; and a blameless culture with post-incident analysis.

Design principles: scale out before scaling up; measure before optimizing; choose the data model by access pattern; cache where the data tolerates it; process asynchronously whatever does not need an immediate answer; and run load tests that reproduce the expected peak.

Here is the real value of the framework. No decision improves all five pillars at once; almost all of them improve one and worsen another, and the architect's job is to choose which, not to pretend it is not happening.

A practical rule worth memorizing: a trade-off is only legitimate if it is written down, has an owner and has a review date. What is not written down is not a trade-off, it is an oversight with good PR.

A review is not a two-hour meeting where somebody shows a diagram. It is a process with participants, a script and an output.

How it is scored, without falling into the trap of the number: the official assessment produces a score per pillar, useful as a baseline for comparing yourself against yourself in six months' time, and useless as a target. Chasing 100% leads you to apply recommendations that do not apply — exactly the same mistake as chasing the Advisor score in module 8.

The result of Contoso's review, prioritized by risk per unit of effort:

Note what is not on the list: multi-region active-active, chaos testing and immutable logging. Not because they do not matter, but because their cost-benefit ratio, in this context and this quarter, is worse than that of the five above. A review that produces twenty actions produces none.

The Well-Architected assessment is a guided questionnaire that walks through the pillars, lets you mark questions as not applicable and generates a report with recommendations and links to documentation. It is a self-assessment: its quality depends entirely on the honesty of whoever answers, so it is best done as a group rather than alone.

They complement each other precisely at their blind spots: Advisor will never say "you have no rollback plan" and the assessment will never say "this machine has been at 3% for fourteen days". Both share the five pillars as a taxonomy, which lets you drop Advisor's recommendations straight into the matching pillar of the review.

Beyond the five generic pillars, the framework publishes specialized guidance applying the same principles to a specific type of workload. It is worth knowing these exist and consulting them when the time comes:

The mission critical guidance is especially instructive even if you do not need it: reading it teaches you what "zero downtime" really costs and, almost always, convinces you that 99.9% with a 4 h RTO was the right decision.

A framework used only once a year is a ritual. The way to make it useful is to break it into two small touchpoints:

• In the design review, before building: five questions, one per pillar, answered in a single page. What happens if this fails? Who can get in and with what credential? How much will it cost per month? How is it deployed and how is it rolled back? What load does it take and how does it scale?
• In the pull request, as a one-line-per-pillar template. It is not bureaucracy if it fits in the repository template and can be answered in a minute.

To take away and use on any project, not just this course.

Reliability: are RPO and RTO written down and agreed with the business? Which component is a single point of failure? Which synchronous dependency could be made asynchronous? Are there retries with backoff and timeouts? Has any backup been restored this half-year? Is the recovery plan tested?

Security: is any credential outside a secret store? Does anybody hold permanent Owner? Is any data reachable from the internet? Is MFA mandatory for everyone? Are accesses reviewed periodically? Is data encrypted in transit and at rest? Is there active detection and somebody watching it?

Cost: is there a budget with an alert? Is everything tagged with an owner and cost center? What is the unit cost and which way is it heading? Which resources have gone a month without use? Was there optimization before committing? Are the rejected cuts written down?

Operational excellence: can the environment be recreated from code? Is it deployed with no manual intervention? How long does a rollback take? Which alert would have caught the last incident? Is the architecture documented and up to date?

Performance efficiency: what is the latency target and is it measured? Does it scale automatically, and has that been tested against the peak? Does the data model match the access pattern? What can be cached without risking correctness? What can be made asynchronous?

• Treating the framework as a list of obligations. Meeting all of it is extortionately expensive; the framework asks, the business answers.
• Chasing the score. The score is for comparing yourself against yourself, not for showing off or for setting targets.
• Reviewing the whole cloud at once. You review one workload; a review of "everything" produces no concrete actions.
• Doing the assessment alone. The bias of whoever designed the system cancels out the result; you need somebody who asks "and what if this goes down?".
• Not including the business or finance. Without them you cannot decide trade-offs, and the whole review stays theoretical.
• Coming out with twenty actions. Five with an owner and a date are worth more than twenty on a spreadsheet.
• Not recording what you decide not to do. It is the information most sorely missed a year later.
• Tip: do the first review before building, when changing your mind is free.
• Tip: keep the report from every review in the repository, with its date. Comparing two reviews teaches you more than either one of them.
• Tip: whenever somebody proposes something that improves one pillar, always ask out loud which pillar it worsens. If the answer is "none", the analysis is missing.

Exercise 1. Take three concrete decisions from Contoso's platform — the WAF in prevention mode, the fg-contoso-reservas replica and switching the development environments off overnight — and analyze each one as a trade-off: which pillar it improves, which pillar it worsens, how each side is quantified, and under what business conditions the decision should be reversed.

Exercise 2. You are responsible for an e-commerce platform with 20,000 orders a month, a single region, App Service, SQL Database and manual deployments from the portal on Fridays. There are no tested backups, the secrets are in the application configuration and there is no cost budget. Carry out an abbreviated Well-Architected review: identify the status of each pillar and produce five prioritized actions with an owner and a deadline, justifying why those five and not others.

Exercise 3. Contoso's management asks to raise the target availability from 99.9% to 99.99% "because it sounds better". Prepare the technical response: what that difference really means in minutes of downtime, what architectural changes it would demand, roughly what it would cost, which pillars would get worse, and what questions you would put back to the business before accepting the trade-off.

Solution 1: WAF in prevention mode. It improves security — it blocks injection, cross-site scripting and bots before they reach the region — and it worsens performance — a few milliseconds per request, irrelevant against the 400 ms target — and, above all, perceived availability through false positives: an over-strict rule blocks legitimate customers, which is a far greater risk than the latency. It is quantified with the added latency in Application Insights and with the number of legitimate requests blocked. It should be reversed — moved to detection only — solely if it were shown to block real traffic repeatedly and rule tuning did not fix it; never for performance. The fg-contoso-reservas replica. It improves reliability — an RTO of 4 h instead of days and protection against a regional failure — and it worsens cost by ≈€1,180/month. Quantifying the other side is the key: you have to estimate the cost of a day-long outage in high season, which with booking revenue is far higher. It would be reversed if the business accepted an RTO of days in writing, or if volume fell so far that the outage cost less than the replica. Switching -dev off overnight. It improves cost; it worsens availability and, knock-on, agility — somebody who wants to work in the early hours finds the environment stopped — and the reliability of the runbook itself, which if badly filtered could switch production off. It is quantified with hours saved times the hourly price and with issues reported by the team. It would be reversed if there were a team in another time zone or nightly pipelines that needed the environment: then the savings are found in sizing, not in switching off.

Solution 2: status by pillar. Reliability: critical — untested backups are equivalent to having no backups; a single region with no recovery plan; no written RPO/RTO. Security: critical — secrets in the application configuration, readable by anybody with read permission on the resource. Operational excellence: bad — manual deployment, on a Friday, with no rollback and no traceability of which version is in production. Cost: unknown, which for these purposes is bad — with no budget there is no anomaly alert. Performance: no data — measurement is not mentioned, so there probably is none. Five prioritized actions: (1) Restore a backup into a separate environment this week — owner operations, 5 days — it is the lowest-effort action with the greatest reduction in catastrophic risk, and it also reveals whether the backups genuinely exist. (2) Move the secrets to Key Vault with a managed identity — development, 2 weeks — it removes the most likely and cheapest exposure to exploit. (3) A deployment pipeline with a slot and rollback, and a ban on deploying on Fridays — development and operations, 3 weeks — it turns every deployment from a risk event into a routine. (4) A budget with an alert and minimal tagging of owner and environment — finance with operations, 1 week — very cheap, and without it you detect neither a mistake nor abuse. (5) Written availability and latency targets, with Application Insights measuring them — product and development, 1 month — with no target there is no way to know whether something is wrong. Why these and not others: all five attack risks with a catastrophic consequence and a low mitigation cost; multi-region, fine-grained autoscaling or automated access reviews look better but have a worse risk-to-effort ratio while the backups remain untested.

Solution 3: in minutes, 99.9% allows about 43 minutes of downtime a month; 99.99%, about 4.3 minutes. The difference is not "one more nine": it is that no human intervention fits inside the downtime budget, so everything has to be automatic. Changes required: automatic database failover with continuous testing, active-active across at least two regions with traffic already split — not cold — the elimination of every single point of failure including the deployment itself, progressive deployments with automatic metric-driven rollback, periodic chaos testing, and 24x7 on-call able to respond in minutes. Approximate cost: at least doubling the production platform plus the team's operational cost, in the region of an additional €25,000-30,000/month against the current €12,550. Pillars that get worse: cost, obviously, and operational excellence in the short term, because multi-region complexity introduces new classes of incident — data inconsistency, split brain, out-of-sync deployments — that do not exist today; agility also suffers, since every change has to be validated in two regions. Questions to put back to the business: how much does a minute of downtime actually cost, measured in lost bookings rather than estimated? How many minutes of downtime have we had in the last twelve months, and how many of those would 99.99% have avoided? Is there any contract, corporate customer or regulatory requirement demanding that level, or is it a preference? Is management willing to fund a permanent on-call team, which is the cost that does not appear on the Azure bill? And one honest observation: if most of the unavailability over the last year came from deployment errors rather than infrastructure failures, investing in progressive deployment and automatic rollback buys more real availability than doubling regions, and costs a fraction.

You now know what the Azure Well-Architected Framework is and what it is really for: not as a list of obligations or a certification, but as a common language that depersonalizes the discussion about architectures, as a mechanism for early detection of the debt that has not blown up yet and, above all, as a way of making explicit the trade-offs that would otherwise be taken without anybody mentioning them.

You know the five pillars with their design principles — Reliability, Security, Cost Optimization, Operational Excellence and Performance Efficiency — and you have seen Contoso's platform audited pillar by pillar, with the distinction that makes an audit useful: what it meets, what it does not meet — access reviews, circuit breakers, chaos testing, error budgets, immutable logging — and what was consciously decided against, which is not the same as an oversight.

You have the trade-offs between pillars with cases lived through and quantified: the WAF that adds milliseconds and false positives, the replica that costs €1,180 a month, the shutdown that saves at the expense of availability, the policy that blocked a deployment on a Friday; along with the rule that makes them legitimate — written down, with an owner and with a review date. You know how to run the review as a process: one workload, participants from architecture, development, operations, security and finance, a half-yearly cadence, and an output that is a plan of five prioritized actions, not a score; you know the official assessment and exactly how it complements Azure Advisor, the specialized guidance for AKS, AI, SaaS and mission critical, how to bring the framework into daily work with five questions in the design review and a template in the pull request, and you take away a checklist by pillar applicable to any platform.

The framework tells you how an architecture ought to be built. The next lesson tackles the other half of the craft: how they get built badly. The honest catalog of the mistakes that repeat themselves in every organization — cost, security, architecture, operations, governance and data — with their symptom, what it costs to fix them late, how they are prevented, and the four that the Contoso team did make during this course.