Study guide
1.3 High Availability, Resiliency & Redundancy
CompTIA Cloud+ Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Cloud Architecture Fundamentals
1.1 Cloud Service Models & Shared Responsibility 1.2 Cloud Deployment Models & Multi-Cloud Strategies 1.3 High Availability, Resiliency & Redundancy 1.4 Disaster Recovery & Business Continuity 1.5 Evolving Cloud Technologies: AI/ML Services, IoT & Edge Computing
2 Chapter 2: Cloud Compute & Storage Architecture
2.1 Virtualization & Hypervisor Architectures 2.2 Containerization & Microservices Architecture 2.3 Container Orchestration & Kubernetes Architecture 2.4 Cloud Storage Architectures & Performance
3 Chapter 3: Cloud Networking Architecture
3.1 Virtual Private Clouds & Subnetting Architecture 3.2 Hybrid & Multi-Cloud Connectivity 3.3 DNS, Load Balancing & Traffic Routing 3.4 Cloud Network Security Architecture
4 Chapter 4: Workload Assessment & Migration Planning
4.1 Cloud Migration Strategies (The 6/7 Rs) 4.2 Pre-Migration Workload Assessment & Sizing 4.3 Data & Database Migration Methods 4.4 Migration Execution, Cutover & Post-Migration Validation
5 Chapter 5: Infrastructure as Code & Provisioning
5.1 Infrastructure as Code Fundamentals & State Management 5.2 IaC Tooling & Template Authoring 5.3 Provisioning Automation & Image Management 5.4 Deployment Strategies & Release Patterns
6 Chapter 6: Cloud Operations & Lifecycle Management
6.1 Resource Lifecycle & Patch Management 6.2 Cloud Scaling Strategies & Elasticity 6.3 Cloud Cost Management & Optimization (FinOps) 6.4 Capacity Planning & Service Quotas
7 Chapter 7: Cloud Backup, Recovery & Business Continuity Operations
7.1 Backup Strategies, Storage Media & Retention Policies 7.2 Immutable Backups, Vault Locking & Ransomware Defense 7.3 Point-in-Time Recovery & Data Integrity Validation 7.4 High Availability Failover Drills & Chaos Engineering
8 Chapter 8: Cloud Security Controls & Identity and Access Management
8.1 Identity & Access Management, RBAC & ABAC 8.2 Identity Federation, SSO & Directory Integration 8.3 Multi-Factor Authentication, PAM & Machine Identities 8.4 Secrets Management & Cryptographic Credential Hygiene
9 Chapter 9: Data Protection, Vulnerability & Compliance
9.1 Data Encryption, Key Management & Confidential Computing 9.2 Vulnerability Management, Posture Assessment & CWPP 9.3 Container, Workload & Runtime Security 9.4 Cloud Compliance Frameworks & Governance Auditing
10 Chapter 10: DevOps Fundamentals & CI/CD Pipelines
10.1 Version Control Systems & Branching Strategies 10.2 Continuous Integration & Automated Testing Pipelines 10.3 Continuous Delivery, Deployment Automation & GitOps 10.4 Configuration Management & Systems Integration
11 Chapter 11: Cloud Observability & Monitoring
11.1 The Three Pillars of Observability: Metrics, Logs & Traces 11.2 Cloud Monitoring Architecture, Alerting & SLOs 11.3 Centralized Log Aggregation, SIEM & Log Analytics
12 Chapter 12: Troubleshooting Cloud Architecture & Deployments
12.1 Structured Cloud Troubleshooting Methodology 12.2 Troubleshooting Compute, Container & Storage Failures 12.3 Troubleshooting Provisioning, IaC & Automation Failures
13 Chapter 13: Troubleshooting Cloud Networking & Security
13.1 Troubleshooting Cloud Network Connectivity & Routing 13.2 Troubleshooting IAM, Permissions & Encryption 13.3 Troubleshooting Disaster Recovery & Performance Degradation
1.3 High Availability, Resiliency & Redundancy
Key Takeaways Explain This Topic AI
High availability (HA) minimizes operational downtime through redundant components across fault domains, while resiliency enables a system to withstand, absorb, and gracefully recover from component failures.
Cloud physical infrastructure is structured hierarchically into geographic Regions, multi-datacenter Availability Zones (AZs), Local Zones, and globally distributed Edge Points of Presence (PoPs).
Availability 'nines' mathematically define permissible annual downtime, scaling from 99.9% (~8.76 hours downtime/year) up to 99.999% (~5.26 minutes downtime/year).
Fault domains isolate physical hardware, power distribution units (PDUs), and network switches, while update domains ensure staggered hypervisor patching to prevent concurrent system outages.
Active-Active global architectures route live traffic across multiple operational nodes simultaneously, whereas Active-Passive topologies maintain standby nodes that require health-check automated failover cutover.
Last updated: August 2026
High Availability, Resiliency & Redundancy
In enterprise cloud engineering, designing for failure is a non-negotiable principle. Physical servers fail, network fiber cuts occur, storage controllers degrade, and entire power grids experience disruptions. High Availability (HA) and Resiliency represent the architectural disciplines that ensure applications remain accessible and performant despite inevitable underlying component failures.
While High Availability focuses on maximizing system uptime and eliminating single points of failure (SPOFs), Resiliency describes the system's capacity to absorb disruptions, gracefully degrade functionality, and autonomously recover to normal operational state without manual human intervention.
1. Geographic Cloud Topologies: Regions, AZs, Local Zones & Edge PoPs
Public Cloud Service Providers organize their global physical infrastructure in a strict hierarchical topology designed to isolate failures and minimize latency. +-----------------------------------------------------------------------------------------+
- | GLOBAL CLOUD INFRASTRUCTURE HIERARCHY |
- | |
- | GLOBAL INFRASTRUCTURE |
- | +---------------------------------------------------------------------------------+ |
- | | REGION (e.g., us-east-1 / East US) | |
- | | Geographically isolated area (>100 miles from other regions) | |
- | | | |
- | | +--------------------------+ <-- Ultra-Low Latency --> +------------------+ | |
- | | | AVAILABILITY ZONE 1 (AZ) | Private Fiber Ring | AVAILABILITY | | |
- | | | - 1+ Physical Datacenters| (< 1-2 ms RTT) | ZONE 2 (AZ) | | |
- | | | - Isolated Power Grid A | | - Isolated Power | | |
- | | | - Dedicated Generators | | Grid B | | |
- | | +--------------------------+ +------------------+ | |
- | +---------------------------------------------------------------------------------+ |
- | |
- | EDGE & METROPOLITAN EXTENSIONS |
- | +------------------------------------+ +------------------------------------+ |
- | | LOCAL ZONES / WAVELENGTH | | EDGE LOCATIONS (PoPs) | |
- | | - Single-digit ms latency compute | | - Global CDN caching (CloudFront) | |
- | | in major cities / 5G telecom edge| | - Anycast DNS resolution / WAF | |
- | +------------------------------------+ +------------------------------------+ |
- +-----------------------------------------------------------------------------------------+
- Cloud Regions
A Region is a specific geographic location in the world containing a cluster of multiple, physically isolated data centers. Regions are separated by significant geographic distances (typically hundreds of miles) to ensure that natural disasters (hurricanes, earthquakes, regional power grid blackouts) cannot incapacitate multiple regions simultaneously. Organizations select regions based on user latency , service availability , and data sovereignty legislation .
Availability Zones (AZs)
An Availability Zone (AZ) consists of one or more discrete, physical data center facilities located within a region. Each AZ is engineered with independent, redundant support infrastructure:
Isolated Power Subsystems: Separate utility feeds, backup diesel generator farms, and Uninterruptible Power Supply (UPS) battery rooms.
Independent Cooling Subsystems: Dedicated chiller plants and HVAC systems.
Redundant Network Connectivity: Separate physical fiber entry paths.
Crucially, all AZs within a region are interconnected through a private, ultra-high-speed fiber ring delivering round-trip latency under 1 to 2 milliseconds . This sub-millisecond connectivity allows architects to deploy synchronous data replication and active-active clustering across multiple AZs without degrading application write performance.
Local Zones, Outposts & Edge Locations
Local Zones / Edge Compute: Extensions of a cloud region that place compute, storage, and database services in major metropolitan centers (e.g., Los Angeles, Chicago) or inside telecommunication carrier 5G networks (e.g., AWS Wavelength). Designed for real-time applications requiring sub-10ms latency, such as financial trading, game streaming, and industrial AR/VR.
Hybrid Edge Appliances (AWS Outposts, Azure Stack Hub): Physical racks of proprietary cloud hardware installed directly in a customer's on-premises data center, managed via the central cloud console.
Edge Locations / Points of Presence (PoPs): Globally distributed network nodes (often hundreds worldwide) hosting Content Delivery Networks (CDNs / AWS CloudFront, Azure CDN), Anycast DNS resolvers (Amazon Route 53), and DDoS mitigation engines (AWS Shield, Cloudflare). PoPs cache static and dynamic content close to end users.
2. Fault Domains, Update Domains & Anti-Affinity
To prevent concurrent infrastructure failures within a single data center or Availability Zone, hypervisors and cloud control planes implement logical isolation constructs. +-----------------------------------------------------------------------------------------+
- | FAULT DOMAINS VS. UPDATE DOMAINS MATRIX |
- | |
- | FAULT DOMAINS (Physical Failure Isolation) UPDATE DOMAINS (Maintenance Isolation) |
- | +---------------------------------------+ +-------------------------------------+ |
- | | FAULT DOMAIN 0 | FAULT DOMAIN 1 | | UPDATE DOMAIN 0 | UPDATE DOMAIN 1 | |
- | | Physical Rack A| Physical Rack B | | Patch Group 1 | Patch Group 2 | |
- | | PDU A / ToR A | PDU B / ToR B | | (Rebooted First) | (Rebooted Second)| |
- | | [VM Web-01] | [VM Web-02] | | [VM Web-01] | [VM Web-02] | |
- | +---------------------------------------+ +-------------------------------------+ |
- | * Power surge on Rack A only affects | * Host OS patch applied to UD 0 while | |
- | VM Web-01. VM Web-02 stays online! | UD 1 continues processing traffic! | |
- +-----------------------------------------------------------------------------------------+
- Fault Domains (FDs)
A Fault Domain represents a physical hardware boundary that shares common single points of failure, such as a physical server rack, a Power Distribution Unit (PDU), or a Top-of-Rack (ToR) network switch. When deploying redundant virtual machines, placing them in separate fault domains guarantees that a hardware failure, power supply blowout, or network switch crash in one rack will not bring down the redundant instance.
Update Domains (UDs)
An Update Domain is a logical grouping of underlying physical hypervisors and virtual machines that can be rebooted, patched, or upgraded concurrently during cloud platform maintenance. When the CSP applies hypervisor kernel patches, update domains are rebooted in a sequential, staggered fashion. The CSP guarantees that only one update domain is taken offline at any given moment, ensuring the application remains available.
Anti-Affinity & Placement Groups
Anti-Affinity Rules: Scheduler policies enforcing that redundant instances of a critical application layer (e.g., two primary database nodes) are never placed on the same physical underlying hypervisor host.
Placement Groups (AWS / Azure):
Spread Placement: Instances are strictly distributed across distinct physical racks (separate fault domains), ideal for small clusters of critical nodes.
Cluster Placement: Instances are packed tightly within a single rack to achieve ultra-low latency and 100 Gbps network throughput, at the cost of shared fault domain risk (ideal for High-Performance Computing / HPC).
Partition Placement: Instances are divided into logical partitions that do not share physical racks with other partitions.
3. Availability Mathematics & The "Nines" Table
Availability is mathematically defined as the ratio of operational uptime to total time, expressed as: Availability = MTBF MTBF + MTTR × 100 % \text{Availability} = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}} \times 100\% Availability = MTBF + MTTR MTBF × 100%
Where MTBF is Mean Time Between Failures and MTTR is Mean Time To Repair.
Permissible Downtime Across Availability "Nines"
- Availability Target Annual Downtime Limit Monthly Downtime Limit Weekly Downtime Limit
- 99.0% ("Two Nines") 3 days, 15 hours, 39 mins 7 hours, 18 mins 1 hour, 40 mins
- 99.9% ("Three Nines") 8 hours, 45 mins, 57 secs 43 minutes, 49 secs 10 minutes, 5 secs
- 99.95% (Standard Cloud VM) 4 hours, 22 mins, 58 secs 21 minutes, 54 secs 5 minutes, 2 secs
- 99.99% ("Four Nines") 52 minutes, 35 secs 4 minutes, 23 secs 1 minute, 0 secs
- 99.999% ("Five Nines") 5 minutes, 15 secs 26.3 seconds 6.0 seconds
- 99.9999% ("Six Nines") 31.5 seconds 2.6 seconds 0.6 seconds
- Serial vs. Parallel Availability Calculation
When designing complex cloud architectures composed of multiple tiers (e.g., DNS, Load Balancer, Web Tier, Database), architects must calculate the composite SLA : +-----------------------------------------------------------------------------------------+
- | SERIAL VS. PARALLEL AVAILABILITY MATH |
- | |
- | 1. SERIAL ARCHITECTURE (Single Chain - Availability Decreases) |
- | [DNS: 99.99%] ---> [App VM: 99.9%] ---> [Database: 99.9%] |
- | Formula: A_total = A_1 * A_2 * A_3 |
- | Calculation: 0.9999 * 0.999 * 0.999 = 0.9979 (99.79% -> 18.4 hours downtime/yr!) |
- | |
- | 2. PARALLEL ARCHITECTURE (Redundant Nodes - Availability Increases) |
- | [App VM 1: 99.9%] |
- | [App VM 2: 99.9%] (Load Balanced Redundant Pair) |
- | Formula: A_total = 1 - ((1 - A_1) * (1 - A_2)) |
- | Calculation: 1 - (0.001 * 0.001) = 1 - 0.000001 = 0.999999 (99.9999% -> 31.5 sec/yr!)|
- +-----------------------------------------------------------------------------------------+
4. Traffic Routing & Failover Architectures +-----------------------------------------------------------------------------------------+
- | ACTIVE-ACTIVE VS ACTIVE-PASSIVE FAILOVER |
- | |
- | ACTIVE-ACTIVE GLOBAL ROUTING ACTIVE-PASSIVE (HOT STANDBY) |
- | +---------------------------------------+ +-------------------------------------+ |
- | | Global DNS / Anycast Traffic Manager | | Global DNS / Anycast Traffic Manager| |
- | | (50% Traffic) (50% Traffic) | | (100% Traffic) (0% Standby) | |
- | | | | | | | : | |
- | | v v | | v : (Dead) | |
- | | [Primary Region] [Secondary Region]| | [Primary Region] [Standby Region]| |
- | | Both process transactions live! | | Live processing Idle / Replicating| |
- | +---------------------------------------+ +-------------------------------------+ |
- +-----------------------------------------------------------------------------------------+
- Active-Active vs. Active-Passive Configurations
Active-Active Topology: Two or more identical environments in different AZs or regions process production traffic simultaneously. Requests are distributed via Global Server Load Balancing (GSLB), Anycast IP routing, or latency-based DNS policies. If Region A suffers an outage, the global router instantly redirects 100% of traffic to Region B with zero downtime. Requires distributed data stores supporting multi-region writes or fast active replication.
Active-Passive Topology: Primary Region A handles 100% of production traffic, while Secondary Region B remains in a standby state, receiving continuous asynchronous data updates. A health-checking monitoring service tests Region A. If Region A fails health checks, automated scripts or administrators initiate a DNS cutover to promote Region B.
Anycast DNS vs. Unicast Routing
Unicast Routing: A single IP address resolves to a single physical location. If that server fails, DNS records must be updated, subject to DNS caching Time-To-Live (TTL) propagation delays.
Anycast IP Routing: The same single IP address is advertised simultaneously from dozens of edge PoPs globally using BGP (Border Gateway Protocol). Client traffic is automatically routed over the internet to the topologically closest PoP. If an edge PoP goes offline, BGP instantly converges traffic to the next closest PoP without requiring DNS changes.