The Architecture Principles a Real Azure Assessment Measures Against

TL;DR: twenty-eight design principles, five tracks, each mapped to a Well-Architected pillar or the Cloud Adoption Framework, and to the regulation it supports. This post is the index; the detail lives in the five linked walkthroughs.

In my experience, most Azure environments are never assessed against principles. They get assessed against whatever the last consultant happened to open, or whatever Advisor flagged that week. So the review finds symptoms and walks straight past the design decisions sitting underneath them.

Which is how you end up with a forty-page report that changes nothing.

A principle-based assessment works the other way round. Start from what good architecture requires. Then read the environment to see where the requirement is met, half-met, or simply absent.

These are not a vendor framework you adopt wholesale. They’re the specific, testable design decisions that separate an architecture surviving an audit and an incident from one that merely runs. Each maps to a Microsoft Azure Well-Architected Framework pillar or to the Cloud Adoption Framework, and to the regulatory controls it supports.

What follows is the full rubric, with a link to the detailed walkthrough for each track.

Principle versus recommendation

An Azure architecture principle is a design rule, specific to the platform, stating what a workload must do to be reliable, cost-efficient, operable, secure, and aligned to the business. It’s also the unit a defensible assessment measures against.

A principle outlasts a recommendation. “Enable Microsoft Azure DDoS Protection” is a recommendation. “No single security control should be the sole protection mechanism” is a principle, and it generates dozens of recommendations across the network, host, application, and data layers.

The difference is not academic. Environments drift, services change, Advisor recommendations come and go. Principles hold still. Anchor an assessment to them and every finding becomes explainable: this configuration fails because it violates least privilege, here is the control that codifies least privilege, here is the remediation that restores it.

A finding with no principle behind it is just an opinion about a setting.

Microsoft organises its own guidance this way. The Well-Architected Framework is built on pillars, and each pillar rests on design principles. This rubric maps to that structure on purpose, then extends it with business-architecture principles that draw on the Microsoft Cloud Adoption Framework, where Well-Architected stops.

How the five tracks fit together

Each track governs a different question about the same workload. Reliability: does it survive failure? Cost: does it earn its spend? Operational excellence: can you run it without heroics? Security: can it be trusted? Business architecture: does it serve a capability the organisation actually needs?

A workload passes this rubric only when all five have an answer. Miss one and the others cover nothing. A perfectly secure system nobody can recover is not well-architected.

It’s just expensively broken.

Four of the five Microsoft Azure Well-Architected Framework pillars are represented, plus the business-architecture concerns the Cloud Adoption Framework addresses. Performance Efficiency has no track of its own.

Track	Principles	Well-Architected pillar	Walkthrough
Reliability	R01–R05: business requirements, resilience, recovery, operations, simplicity	Reliability	Azure reliability design principles
Cost optimisation	CO01–CO05 + O03: cost discipline, efficiency mindset, usage and rate optimisation, monitoring, cost as a feature	Cost Optimization	Azure cost optimization principles
Operational excellence	O01, O02, O04 + C03: automation, event-driven design, observability, infrastructure as code	Operational Excellence	Azure operational excellence principles
Security	S01–S05 + C02: defence in depth, least privilege, secure by design, data classification, continuous validation, Zero Trust	Security	Azure security design principles
Business architecture	BA01–BA04 + C01, C04, C05: capability mapping, platform thinking, compliance as code, vendor lock-in, cloud-native, API-first, microservices	Cloud Adoption Framework	Cloud-native and compliance as code

The tracks lean on each other. Reliability’s recovery principle depends on operational excellence’s observability principle, because you cannot start recovering from a degradation nobody has seen. Security’s least privilege principle depends on business architecture’s compliance-as-code principle to stay enforced as time passes.

It’s a system, not a list. Which is why an assessment that touches one pillar hands you a distorted picture and calls it a result.

Every principle leaves an artifact

Met, a principle produces something concrete you can check. Most of it sits in the Azure environment; some of it sits in the repository or the runbook. The assessment finds the principle by finding that thing, or by failing to find it. Principles stay abstract right up until you read them against a real tenant, and then each one becomes a specific object that is either present or absent.

“Design for recovery” produces a documented Recovery Time Objective and Recovery Point Objective per workload, plus dated test-failover or test-restore records: Microsoft Azure Site Recovery for replicated virtual machines, a restore test for everything else. A successful job is not a validated recovery. “Least privilege” produces a Microsoft Entra ID Privileged Identity Management configuration with just-in-time activation and no standing Owner assignments. “Infrastructure as code” produces version-controlled Bicep or Terraform modules in a repository, plus the absence of portal-created snowflake resources. Azure Resource Graph shows the second half for the last 14 days: its change history records which client made each change, the Azure portal included. “Compliance as code” produces Microsoft Azure Policy assignments with the deny effect, enforced rather than left in DoNotEnforce, that codify the regulatory control instead of describing it in a document.

Absence of the artifact is the finding. Either the test-restore log exists with a date on it, or it does not. Either Owner is eligible-only in Privileged Identity Management, or standing access is your posture. PIM also holds active assignments that need no activation, so a configured PIM proves nothing until you check the assignment type.

Go and look at yours before someone else does.

That’s what makes this kind of assessment defensible in front of an auditor. Most of the evidence is the configuration itself, produced as a byproduct of building the workload correctly, not assembled after the fact to pass a review.

Where the compliance overlap lives

The regulator and the architect describe the same controls in different vocabularies. A principle-based assessment translates between them.

NIS2 Article 21(2)(c) requires business continuity and disaster recovery measures. Reliability principles R03 and R04 are how you build them on Azure. DORA Article 12(2) requires backup and restoration procedures that are tested periodically, and the same reliability principles produce the test-restore evidence. ISO 27001 Annex A.5.15 requires access control. Security principles S02 and C02, least privilege and Zero Trust, are the architecture that supports it.

“But we already run Azure Advisor and the tenant is mostly green. Isn’t that the same thing?”

No. Advisor tells you what Microsoft’s rules flag in your resource configuration and usage telemetry. It does not tell you whether a design decision was ever made, whether anyone tested the restore, or whether the standing Owner role is deliberate. Green is not evidence.

This is the through-line for regulated industries. You are not choosing between good architecture and compliant architecture. Same work. A well-architected Azure environment throws off much of the control evidence that NIS2, DORA, GDPR, ISO 27001, and SOC 2 examiners ask for, because many of the principles that make architecture sound are the ones those regulations codify.

So in the environments I assess, the bigger gap is usually documentation rather than configuration: the distance between a correctly built environment and the structured evidence that proves it. Closing that gap is exactly what an architecture assessment does. For a worked example at the landing-zone level, see the Azure landing zone compliance review.

Where this rubric comes from

These are the principles the assessments I run measure against. Drawn from the Microsoft Azure Well-Architected Framework and Cloud Adoption Framework, then sharpened by the patterns that keep showing up across real Azure environments in regulated industries. The single-zone database that was never an architecture decision. The standing Owner role nobody revoked. The backup nobody has restored from.

For years I carried that rubric around in a spreadsheet, and every engagement started the same way: rebuild the tabs, re-derive the same findings by hand, discover halfway through that my own template had drifted. The spreadsheet was, in fairness, the least well-architected thing in any tenant I opened. So I built Platform Architecture Authority to do the mechanical half, read-only, against the live estate, and leave the judgement where it belongs. It doesn’t decide which trade-offs are right for your business. It just stops me guessing at what’s actually deployed.

Five things worth holding onto:

• A real assessment measures against principles, not a checklist of resources. The principle says what good looks like; the assessment finds where you diverge.
• Five tracks: reliability, cost optimisation, operational excellence, security, business architecture. Each maps to a Well-Architected pillar or to the Cloud Adoption Framework.
• Every principle leaves an artifact. Absence of the artifact is the finding.
• The principles map to regulation. Reliability supports DORA Article 12 and NIS2 Article 21(2)(c); security supports NIS2 Article 21(2)(i) and ISO 27001 Annex A.5.15.
• They’re opinionated and Azure-specific. They name services, settings, and trade-offs, not generic cloud advice that would be equally true on any platform.

The five companion posts walk each track in detail. Start with the one that matches the question keeping you up: recovery, spend, operability, trust, or fit.

The principles don’t change with fashion. That is the entire point of having them.

FAQ

How many Azure architecture principles are there? Twenty-eight, across five tracks: five reliability, five cost, four operational, five security, and nine business and core. The count matters less than the coverage. Four of the five Microsoft Azure Well-Architected Framework pillars are represented, plus the business-architecture concerns the Cloud Adoption Framework addresses. Performance Efficiency has no track of its own.

Are these the same as the Microsoft Azure Well-Architected Framework pillars? They map to the pillars but go finer. Well-Architected defines five pillars; this rubric decomposes four of them into specific, testable principles, then adds the business-architecture principles the framework does not formally cover. The pillars are the structure. The principles are the measurable detail underneath.

Can I assess my own environment against these principles? Yes. Each companion post names the Azure services, settings, and artifacts a principle produces, so a competent platform team can self-assess by checking whether each artifact exists. The hard part is doing it consistently across a large tenant and keeping it current as the environment drifts. That’s where automated, continuous assessment earns its place.

Do these principles apply to small Azure environments? Yes, with proportion. A two-subscription environment still needs documented recovery objectives, least privilege, and infrastructure as code. It just needs less of the heavyweight platform tooling. The “keep it simple” reliability principle (R05) is itself a guard against over-engineering a small environment with controls it does not need.