The Azure Well-Architected Reliability Pillar: What Most Environments Are Missing
The Azure Well-Architected reliability pillar surfaces the same gaps in nearly every environment: no documented RTO, single points of failure, untested failover. For platform engineers.
Marc Dekeyser |
The Azure Well-Architected Reliability Pillar: What Most Environments Are Missing
TL;DR: the reliability pillar almost never fails on infrastructure. It fails because nobody wrote down what “recovered” is supposed to mean.
Nearly every reliability assessment lands on the same finding. The recovery commitments were never written down, so there is nothing to measure against. The pillar checks whether a workload meets its availability and recovery commitments under real failure conditions, not whether it runs on a good day.
That is the actual gap. Not the infrastructure. Most mid-market Azure environments were built by competent teams who kept services running and shipped. But “it hasn’t gone down yet” is not a reliability posture. It’s an absence of evidence. The Well-Architected reliability pillar asks you to make the implicit explicit, and that is where the findings come from.
What the five design principles actually require
Five principles, each one translating to a concrete artifact an assessment looks for. They sound abstract. The findings are not.
Start with designing for business requirements. That means a documented RTO and RPO for each workload, agreed with the business, not assumed by the platform team. This is the one that fails most often. Recovery Time Objective is how long you can be down. Recovery Point Objective is how much data you can lose. Leave them undocumented and every downstream decision (backup frequency, replication tier, failover design) is guesswork dressed as architecture.
Designing for resilience means the workload survives the failure of a component without failing as a whole. In practice the assessment hunts for redundancy at each tier and the single points of failure nobody put there on purpose.
Designing for recovery means you can restore service after a failure you didn’t design out, and you’ve proven you can. This is where Azure Backup and Azure Site Recovery come under scrutiny.
Keep it simple is a reliability control in its own right. Complexity you didn’t earn against a requirement is a risk. Over-engineered failover that nobody understands fails during the incident, not before it.
Designing for operations means the workload is observable enough that you know it’s degrading before it fails. That connects straight to health modelling.
Where the single points of failure actually live
Compute redundancy usually gets handled. Teams understand that one virtual machine is a risk. The data tier is where the gap sits, because the failure mode is quieter and the default configuration looks like it works. And none of it shows up in an Architecture Decision Record.
Here is the pattern. An Azure SQL Database on the General Purpose tier without zone redundancy. A storage account set to Locally Redundant Storage (LRS), three copies all in one datacentre, backing a workload the business considers critical. An Azure Cache for Redis on the Basic tier: a single node, no replication. None are wrong by default. All are single points of failure nobody chose deliberately.
The table maps each design principle to the finding it produces and the configuration setting behind it.
| Design principle | Finding in nearly every assessment | The setting behind it |
|---|---|---|
| Design for business requirements | No documented RTO/RPO per workload | Absent — no artifact exists |
| Design for resilience | Single-zone database in a critical path | zoneRedundant set to false on Azure SQL |
| Design for resilience | Storage with no regional redundancy | Storage account SKU set to Standard_LRS |
| Design for recovery | Backups configured but never test-restored | Azure Backup recovery points present, no restore log |
| Design for recovery | Failover never exercised | Azure Site Recovery plan with no test failover history |
One observation ties them together. These are configuration defaults that were never revisited. The team that built the environment optimised for delivery, not for auditing resilience. Running an environment and auditing it are different jobs, and that difference is the whole reason a structured review surfaces what the operators couldn’t see.
Why availability zones get skipped
Zonal deployment is a provisioning-time decision. Miss it, and enabling zone redundancy later usually means a redeploy nobody schedules. That is the mechanism behind the finding.
An availability zone is a physically separate datacentre inside an Azure region, with its own power, cooling, and networking. Spread a workload across zones and a datacentre-level failure stops taking the workload down with it, for marginal cost. Most regions Dutch and EU organisations use — West Europe, North Europe — support them. The finding is almost never that zones weren’t available. It’s that the resource shipped zone-redundant=false because that was the path of least resistance in the portal or the template, and the decision never became an ADR.
Region pairing is the next layer up. Azure pairs regions (West Europe with North Europe) for geo-redundant services and coordinated platform updates. Geo-Redundant Storage (GRS) replicates to the paired region. The assessment checks whether critical data stores use GRS, or RA-GRS where read access during an outage matters. The common finding is LRS on data the business would consider unrecoverable if the primary region were lost. Worth cross-linking with the cost optimization pillar, because the inverse turns up too: GRS paid for on data that’s genuinely disposable.
What health modelling and failure-mode analysis surface
Can the team tell a degraded workload from a healthy one before users do? In most environments, no. Monitoring reports component status, not workload health. A health model defines what “healthy” means at the workload level: not “the VM is up” but “the application is serving requests within its latency budget.”
The finding repeats. Azure Monitor and Application Insights are deployed. They report CPU, memory, instance availability. What they don’t report is a composite health signal tied to the business function, because nobody defined one. Failure-mode analysis (systematically asking “what happens when this component fails?”) is almost never written down. The dependencies live in people’s heads. When the dependency fails, the knowledge fails with it.
This links to operational excellence: reliability asks whether you can see degradation, operational excellence whether you can respond to it.
How untested failover fails
The configuration looks correct. That’s the trap. Azure Site Recovery replicates virtual machines to a secondary region, the replication health shows green, and the team assumes recovery works. It frequently doesn’t, for reasons that stay invisible until a test failover runs.
The recovered VMs come up, but the network security group rules in the secondary region don’t match. Or DNS still points at the primary. Or the application references a Key Vault with no private endpoint in the failover region. Or the recovery plan boots the database after the application tier, and the application crashes on startup. Each one is discoverable only by running a test failover, which Azure Site Recovery supports without touching production, and which most teams have never done.
Azure Backup has the twin finding. Recovery points exist. Nobody has run a test restore. A backup you’ve never restored from is a hypothesis, not a recovery capability. DORA Article 12 is explicit: backup and restoration procedures must be tested periodically. “We have backups” doesn’t satisfy it. “We test-restored on this date and it succeeded” does.
The evidence a reliable configuration produces
It shows up by construction: a documented RTO/RPO register, zone-redundant resources visible in Azure Resource Graph, GRS on critical data, dated test-failover and test-restore logs, a defined health model. That is what turns a reliability claim into a defensible position in front of a DORA or NIS2 auditor.
The mapping is direct. DORA Article 12 wants backup policies, restoration procedures, and periodic testing of both, so your Azure Backup configuration and test-restore logs are the evidence. NIS2 Article 21(2)(c) wants business continuity and disaster recovery measures, so your documented recovery objectives, zone and region redundancy, and exercised failover plans are the evidence. A well-architected environment generates this material as a byproduct. You are not assembling evidence for the audit. The configuration is the evidence.
Platform Architecture Authority reads an Azure environment through Azure Resource Graph and surfaces these findings against the running configuration: the single-zone databases, the LRS storage on critical workloads, the Site Recovery plans with no test history. It maps each to the DORA and NIS2 article it touches. It is read-only, and it generates the remediation as infrastructure-as-code you review and apply on your own schedule. A senior consultant still brings the judgment about which workloads genuinely warrant zone redundancy. The platform surfaces the gap so the judgment has something to act on.
The short version
- Workloads with no documented RTO or RPO is the most common finding. You cannot design redundancy against a target that does not exist.
- The single points of failure that matter sit in the data tier (single-zone database, storage with no geo-redundancy) and were defaults, not decisions.
- Availability zones are the cheapest reliability control Azure offers and the most often skipped, because nobody selected zonal deployment at provisioning time.
- Failover you have never tested is not a recovery plan. Untested Site Recovery configs fail in ways nobody anticipated.
- All of it maps to DORA Article 12 (backup and recovery) and NIS2 Article 21(2)(c) (business continuity).
FAQ
What is the difference between RTO and RPO in the reliability pillar? RTO (Recovery Time Objective) is the maximum acceptable time a workload can be unavailable after a failure. RPO (Recovery Point Objective) is the maximum acceptable amount of data loss, measured in time. RTO drives failover design; RPO drives backup and replication frequency. The reliability pillar requires both, documented per workload.
Are availability zones enough, or do I need a second region? Availability zones protect against a datacentre-level failure within one Azure region and cover most reliability requirements. A second region, via region pairing and geo-redundant storage, protects against a full regional outage. Whether you need it depends on the documented RTO and RPO for the workload, which is why those come first.
How often should failover be tested under DORA? DORA Article 12 requires backup and restoration procedures to be tested periodically, without prescribing a fixed interval. Annual test failover and test restore is a defensible baseline for most mid-market workloads; critical workloads warrant more frequent exercises. The evidence that matters is a dated log showing the test occurred and succeeded.
A reliability posture is not the absence of outages. It is the documented, tested, evidenced ability to recover from them on a schedule you control rather than one an incident imposes.
