The Azure Well-Architected Reliability Pillar: A Practical Walkthrough
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
The Azure Well-Architected reliability pillar measures whether a workload meets its availability and recovery commitments under real failure conditions — not whether it runs on a good day. The finding that appears in nearly every assessment is the same: the recovery commitments were never written down, so there is nothing to measure against.
That is the actual gap. Not the infrastructure. Most mid-market Azure environments are built by competent teams who kept services running and got the job done. But “it has not gone down yet” is not a reliability posture. It is an absence of evidence. The Microsoft Azure Well-Architected Framework reliability pillar asks you to make the implicit explicit — and that is where the findings come from.
Key takeaways
- The most common reliability finding is workloads with no documented RTO or RPO. You cannot design redundancy against a target that does not exist.
- Single points of failure in the data tier — a single-zone database, a storage account with no geo-redundancy — rarely appear in any Architecture Decision Record. They were defaults, not decisions.
- Availability zones are the cheapest reliability control Azure offers, and the most frequently skipped because zonal deployment was not selected at provisioning time.
- Failover that has never been tested is not a recovery plan. Untested Azure Site Recovery configurations fail in ways nobody anticipated.
- Reliability evidence maps directly to DORA Article 12 (backup and recovery) and NIS2 Article 21(2)(c) (business continuity).
What do the reliability design principles actually require?
The Azure Well-Architected reliability pillar organises around five design principles, and each one translates to a concrete artifact an assessment looks for. The principles sound abstract. The findings are not.
Design for business requirements means a documented RTO and RPO exists for each workload, agreed with the business, not assumed by the platform team. This is the principle that fails most often. Recovery Time Objective is how long you can be down. Recovery Point Objective is how much data you can lose. When these are undocumented, every downstream decision — backup frequency, replication tier, failover design — is guesswork dressed as architecture.
Design for resilience means the workload survives the failure of a component without failing as a whole. In practice the assessment looks for redundancy at each tier and the absence of single points of failure.
Design for recovery means you can restore service after a failure you did not design out — and you have proven you can. This is where Azure Backup configuration and Azure Site Recovery come under scrutiny.
Keep it simple means complexity not earned by a requirement is itself a reliability risk. Over-engineered failover that nobody understands fails during the incident, not before it.
Design for operations means the workload is observable enough that you know it is degrading before it fails. This connects directly to health modelling.
Where do the single points of failure actually live?
The single points of failure in nearly every assessed environment live in the data tier, and they were never captured in an Architecture Decision Record. Compute redundancy is usually 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.
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 with no replication. None are wrong by default. All are single points of failure that no one chose deliberately.
The table below maps the design principle to the finding the assessment 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 |
The unifying observation: these are configuration defaults that were never revisited. The team that built the environment was optimising for delivery, not auditing for resilience. That distinction — running the environment versus auditing it — is the whole reason a structured reliability review surfaces what the operators could not see.
Why do availability zones get skipped?
Availability zones get skipped because zonal deployment is a provisioning-time decision, and once a resource is created without it, enabling zone redundancy often requires a redeploy nobody schedules. An availability zone is a physically separate datacentre within an Azure region, with independent power, cooling, and networking. Spreading a workload across zones protects it from a datacentre-level failure for a marginal cost.
Most Azure regions used by Dutch and EU organisations — West Europe, North Europe — support availability zones. The finding is rarely that zones are unavailable. It is that the resource was deployed zone-redundant=false because that was the path of least resistance in the portal or the template, and the decision was never an ADR.
Region pairing is the next layer. 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, where read access during an outage matters, RA-GRS. The common finding is LRS on data the business would consider unrecoverable if the primary region were lost. Cross-link this with the cost optimization pillar, because the inverse also appears: GRS paid for on data that is genuinely disposable.
What does health modelling and failure-mode analysis surface?
Health modelling surfaces whether the team can tell the difference between a degraded workload and a healthy one before users do — and in most environments, the answer is no, because 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 is consistent. Azure Monitor and Application Insights are deployed. They report CPU, memory, and instance availability. What they do not 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 documented. The dependencies are in people’s heads. When the dependency fails, the knowledge fails with it.
This connects to operational excellence: reliability asks whether you can see degradation, operational excellence whether you can respond to it.
How does untested failover fail?
Untested failover fails because the configuration looks correct and the recovery process has hidden dependencies that only surface when you actually run it. Azure Site Recovery replicates virtual machines to a secondary region. The replication health shows green. The team assumes recovery works. It frequently does not, for reasons that are invisible until a test failover runs.
The recovered VMs come up, but the network security group rules in the secondary region do not match. Or DNS still points at the primary region. 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 is discoverable only by performing a test failover — which Azure Site Recovery supports without disrupting production, and which most teams have never run.
Azure Backup has the parallel finding. Recovery points exist. Nobody has performed a test restore. A backup you have 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” does not satisfy it. “We test-restored on this date and it succeeded” does.
What evidence does a reliable configuration produce?
A reliable configuration produces evidence 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, and a defined health model. This evidence 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 requires backup policies, restoration procedures, and periodic testing of both — your Azure Backup configuration and test-restore logs are the evidence. NIS2 Article 21(2)(c) requires business continuity and disaster recovery measures — 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 reliability findings against the running configuration — the single-zone databases, the LRS storage on critical workloads, the Site Recovery plans with no test history — and 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.
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.
