Fault Tolerance vs High Availability

Fault tolerance and high availability are two strategies for ensuring that an application or service remains operational despite failures. They are often confused, but they address different levels of reliability.

Fault tolerance is the property that enables a system to continue operating properly in the event of a failure of one or more of its components. The system is designed so that no single point of failure can bring it down. In a fault-tolerant system, there is no interruption of service—the failure is completely transparent to the end user. For example, a fault-tolerant web application might run on multiple virtual machines (VMs) behind a load balancer. If one VM crashes, the load balancer immediately redirects traffic to the remaining healthy VMs. The user never notices a glitch.

High availability (HA) is a characteristic of a system that aims to ensure an agreed level of operational performance, usually uptime, over a given period. High availability is measured as a percentage, such as 99.9% (three nines) or 99.99% (four nines). Unlike fault tolerance, HA allows for brief periods of downtime during failover. For example, an HA pair of VMs might use Azure Availability Sets. If one VM fails, the other takes over, but there may be a few seconds of disruption while the failover occurs. HA is often more cost-effective than full fault tolerance.

Both concepts address the business need for continuity and reliability. When you move to the cloud, you are responsible for architecting your applications to handle failures. Azure provides the building blocks, but you must choose the right one based on your recovery time objective (RTO) and recovery point objective (RPO).

For a fault-tolerant system, RTO is essentially zero—no downtime. For a highly available system, RTO might be a few seconds to minutes. The cost increases as you move from HA to fault tolerance.

Azure achieves fault tolerance through redundancy at every layer. The key mechanisms include:

High availability is typically achieved through redundancy with automatic failover, but with some acceptable downtime. Examples include:

Azure offers different SLA levels depending on the configuration:

These SLAs are financial guarantees—if Microsoft fails to meet the SLA, you may receive service credits.

In an on-premises datacenter, achieving fault tolerance requires duplicating hardware, power, and network paths. This is expensive and often only done for critical systems. High availability in on-premises might involve clustering with shared storage, which also has cost and complexity. Azure abstracts the physical infrastructure, allowing you to achieve high availability and fault tolerance without owning the hardware. You pay only for the redundant resources you consume.

You can configure fault tolerance and high availability through the Azure portal, CLI, or ARM templates.

Azure CLI example for creating VMs in an availability set:

az vm availability-set create \
  --resource-group myResourceGroup \
  --name myAvailabilitySet \
  --platform-fault-domain-count 2 \
  --platform-update-domain-count 2

Azure CLI example for creating VMs in availability zones:

az vm create \
  --resource-group myResourceGroup \
  --name myVM \
  --image UbuntuLTS \
  --zone 1 \
  --generate-ssh-keys

ARM template snippet for an availability set:

{
  "type": "Microsoft.Compute/availabilitySets",
  "apiVersion": "2023-03-01",
  "name": "myAvailabilitySet",
  "location": "[resourceGroup().location]",
  "properties": {
    "platformFaultDomainCount": 2,
    "platformUpdateDomainCount": 2
  }
}

Scenario 1: Financial Trading Platform

A hedge fund runs a real-time trading application that processes thousands of transactions per second. Even a few seconds of downtime could result in millions of dollars in losses. The team deploys the application across three availability zones in the East US region. Each zone contains multiple VM instances running the trading engine. An Azure Load Balancer with a health probe checks the status of each VM every 5 seconds. If a zone experiences a power outage, the load balancer immediately stops sending traffic to that zone's VMs and distributes the load among the remaining zones. The database layer uses Azure SQL Database with Zone Redundancy, which synchronously replicates data across zones. The entire failover is transparent to users. The cost is high—triple the compute and storage—but the business justifies it because the cost of downtime is even higher.

Scenario 2: E-Learning Platform

A university runs an online course portal that serves 10,000 students. The portal can tolerate up to 5 minutes of downtime per month. The IT team uses an availability set with two VMs running the web server and a separate VM for the database. The web VMs are behind an internal load balancer. During Azure planned maintenance, one VM is updated while the other remains online. There is a brief interruption (about 30 seconds) while the load balancer switches traffic. The database uses a simple backup and restore strategy with a 5-minute RPO. The total cost is moderate—double the VM cost for the web tier. This is a classic high-availability design.

Scenario 3: Global Social Media App

A social media startup wants to ensure their app is available even if an entire Azure region fails. They deploy the app in two regions: West Europe and North Europe. Traffic is routed using Azure Traffic Manager (DNS-based load balancing). The database uses Azure Cosmos DB with multi-region writes, which is fault tolerant at the global level. If West Europe goes down, Traffic Manager automatically directs users to North Europe. The failover takes 1-2 minutes because DNS propagation is not instantaneous. The cost is significant—double the infrastructure—but the startup considers it necessary for their global user base.

Common Pitfalls