Redundancy vs. High Availability — The Difference in Practice
Two companies host identical e-commerce websites. Both companies experience a web server failure on a Friday evening during peak shopping traffic. Their response illustrates the practical difference between redundancy and high availability.
Company A — Redundancy only (spare on the shelf):
8:47 PM — Primary web server fails; website goes down
8:47 PM – 9:10 PM — On-call engineer paged; drives to data center
9:10 PM – 9:35 PM — Replacement server pulled from shelf; racked
9:35 PM – 10:05 PM — OS configured; application deployed; tested
10:05 PM — Website restored
TOTAL DOWNTIME: 1 hour 18 minutes
REVENUE LOST: Significant — Friday evening peak shopping window
Company B — High availability (active/active load-balanced cluster):
8:47 PM — Web server #1 fails
8:47 PM — Load balancer health check detects failure (within seconds)
8:47 PM — Load balancer removes Server #1 from pool; routes all traffic to Servers #2 and #3
8:47 PM — Website continues serving with slightly increased load on remaining servers
TOTAL DOWNTIME: 0 seconds (users experience no interruption)
Alert sent to on-call engineer for morning repair
Key distinction: Company A had redundancy — they had a spare server. But the spare being on a shelf meant 78 minutes of downtime to activate it. Company B's secondary servers were already running and serving traffic. The failure was invisible to customers. This is the operational difference between "having a spare" and "high availability."
Company B's additional costs: Three servers instead of one (plus a load balancer), all powered on and consuming resources simultaneously. Higher licensing costs for three servers. More complex infrastructure management. These costs are why not every organization implements HA — the decision is whether the cost of downtime exceeds the cost of the HA infrastructure.
Recovery Site Selection — Three Organizations, Three Choices
Three different organizations each evaluate their disaster recovery options. Their decisions illustrate how hot, warm, and cold sites suit different risk profiles and budgets.
Organization 1 — National bank, financial trading platform:
This bank's trading systems process billions of dollars in transactions daily. Each minute of downtime during trading hours results in measurable financial losses, regulatory reporting obligations, and client relationship damage. The bank's RTO requirement is less than one hour; its RPO requirement is less than five minutes of data loss.
Decision: Hot site. The bank maintains a second fully operational data center 400 miles away in a different region. Every transaction is replicated in real time to the hot site. All hardware is identical. Applications are continuously updated. In a disaster, DNS can redirect trading platform traffic to the hot site within minutes. The additional cost — effectively doubling the data center budget — is justified by the cost of even one hour of trading downtime, which exceeds the annual cost difference between a hot and warm site.
Organization 2 — Regional healthcare network, 8 hospitals:
The healthcare network's systems must remain operational for patient care, but a recovery time of 4–12 hours is medically acceptable for administrative systems (clinical systems have separate local redundancy). Budget is constrained by healthcare funding. RTO: 8 hours. RPO: 4 hours of data loss acceptable.
Decision: Warm site. The warm site maintains rack space, some servers, and basic network infrastructure. During normal operations, backups run every 4 hours to the warm site. In a disaster, the team transports remaining hardware (or activates pre-positioned equipment), restores the 4-hour backup, and has systems operational within 8 hours. Cost is roughly 30% of a hot site for equivalent coverage. The healthcare network accepts the 4-hour RPO because patient care relies primarily on local systems, not central administrative servers.
Organization 3 — Small manufacturing company, 200 employees:
The company's IT systems support order management and accounting. An outage of several days is disruptive but survivable — the company can process orders manually for a week. Disasters requiring site activation are extremely unlikely (no hurricane risk; located in a stable geographic region). The IT budget is small.
Decision: Cold site. The company leases a space in a shared commercial facility with power and network drops. Nightly backups go to cloud storage and external hard drives. In a disaster, the company could procure replacement equipment within 2–3 days, restore from backup, and resume operations within a week. Staff would work from home or the alternate site using laptops purchased for that purpose. Annual cost of the cold site arrangement is a small fraction of maintaining warm or hot infrastructure, and the company has documented COOP procedures for manual operations during the recovery window.
Geographic Dispersion Failure — Why "Close Enough" Is Not
A regional retail chain maintains its primary data center in Houston, Texas, and its disaster recovery site in Galveston, Texas — 50 miles away. The chain's IT leadership chose Galveston because the real estate was cheap, the network connection was fast, and the proximity made it easier to physically transport equipment in an emergency.
In August, a major hurricane makes landfall on the Texas Gulf Coast. The hurricane's path covers the entire Houston-Galveston metropolitan area. Both the primary data center in Houston and the recovery site in Galveston are simultaneously affected: power is lost at both locations, flooding damages network infrastructure in both locations, and both sites are inaccessible to personnel for several days.
The result: The company's disaster recovery plan — designed and tested carefully — is completely ineffective because the "disaster" took out both the primary and the recovery site at the same time. The two sites were not geographically dispersed enough to be protected from a single regional event.
What geographic dispersion should have looked like:
- Recovery site in Dallas or San Antonio (250+ miles away) — well outside any single hurricane's impact area
- Or recovery site in a different region entirely (Denver, Atlanta, Chicago) — no hurricane that hits Houston will reach those cities simultaneously
- The guiding principle: the recovery site must be far enough that a single realistic disaster scenario cannot affect both sites simultaneously
The operational tradeoff: Dallas is harder to reach than Galveston during a normal operation (though in a hurricane, neither is accessible from the flooded primary site). Staff relocation to Dallas requires air travel rather than driving. Equipment transport requires more coordination. But these operational challenges are manageable and plannable — a recovery site that fails in the same disaster as the primary is simply not a recovery site.
Platform Diversity in Practice — Limiting a Zero-Day's Blast Radius
Two organizations are notified about a critical zero-day vulnerability affecting Windows Server. The vulnerability allows unauthenticated remote code execution against any exposed Windows Server system. A patch is available but requires a maintenance window and testing; full deployment will take 72 hours across all systems.
Organization A — Homogeneous Windows environment:
All 200 servers run Windows Server. All web servers, database servers, application servers, email servers, and file servers are Windows. During the 72-hour patch window, 200 servers are at risk. Attackers scanning for the vulnerability can identify and exploit any of these servers. The organization must treat every server as a critical emergency and work around the clock to patch all 200 simultaneously — or take all systems offline for emergency patching, causing massive downtime.
Organization B — Mixed platform environment:
60 web servers and 40 application servers run Linux (Ubuntu/RHEL). 50 database servers, 20 email servers, and 30 file servers run Windows Server. When the Windows zero-day is announced, only 100 of the 200 servers are affected. The Linux servers are completely immune to this specific Windows vulnerability. The Linux web servers continue serving external traffic normally; the organization can take Windows application and database servers offline for emergency patching without losing the ability to serve basic requests. Recovery time is faster because only half the infrastructure requires emergency action.
The exam-relevant principle: Platform diversity does not prevent all vulnerabilities — Linux has its own vulnerabilities that Organization A's Windows-only environment would be immune to. The point is that no single vulnerability has blast radius across the entire infrastructure. When a critical vulnerability strikes, Organization B always has a portion of its infrastructure unaffected and available to maintain at least partial operations.
Regional Hospital System — Resiliency Architecture Review
You are reviewing the resiliency architecture of a regional hospital system with one main hospital and three satellite clinics. The hospital's CISO has asked you to evaluate their current setup and recommendations.
Part 1: The hospital's IT team describes their current setup: "We have two identical web servers running behind a load balancer for the patient portal. Both servers are always running. If one fails, the load balancer automatically routes everything to the other." The CISO asks: "Is this high availability?" Evaluate the current setup and identify what type of availability architecture this represents.
Show Answer
Yes — this is high availability, specifically an active/active load-balanced configuration.
Why it qualifies as HA: Both servers are always running and serving real traffic simultaneously (active/active). The load balancer distributes requests across both. When one fails, the other is already operational and immediately absorbs all traffic — there is no "startup" or "switchover" delay. Users experience no service interruption when one server fails.
What makes it active/active: Both servers handle production load simultaneously. Neither is a standby. When one server fails, the remaining server handles 100% of traffic — it was already handling 50% before the failure, so it has the capacity headroom to absorb the full load (assuming the servers are sized for this contingency).
What the CISO should verify: (1) The load balancer itself must not be a single point of failure — a redundant pair of load balancers should be configured in HA as well. (2) The servers must be sized to handle 100% of peak load from one server alone — if each server was running at 80% capacity, losing one would push the other to 160% during peak load, causing performance degradation. (3) The shared backend (database, storage) must also have HA — a patient portal that cannot fail over its web servers but can still lose access to its database has only partial HA.
Part 2: The hospital's disaster recovery documentation states: "In the event of a disaster affecting the main hospital data center, operations will fail over to our recovery site in the same city, 8 miles away." The CISO is concerned. Evaluate whether this geographic placement is adequate.
Show Answer
The placement is inadequate for the most common and severe disaster scenarios.
Why 8 miles is not enough: Geographic dispersion is designed to ensure that a single disaster cannot simultaneously affect both the primary site and the recovery site. At 8 miles, the hospital's primary and recovery sites are in the same metropolitan area and subject to the same regional events: a major storm affecting the city affects both sites; a regional power grid failure affects both sites; a widespread flooding event affects both sites; even a large-scale targeted cyberattack affecting the region's infrastructure could impact both sites' ISP connectivity simultaneously.
What adequate geographic dispersion looks like for a hospital: The recovery site should be in a different metropolitan area or region — ideally 100+ miles away. This ensures that a hurricane, flood, tornado, or regional power event that shuts down the primary hospital data center does not simultaneously affect the recovery site. For a hospital system, this is especially important because natural disasters that affect hospital operations (hurricanes, ice storms, flooding) are exactly the scenarios where the recovery site is most likely to be needed.
Practical recommendation: Move or establish the recovery site in a different city. Consider colocating with a data center in a different geographic region — many healthcare organizations use cloud-based disaster recovery precisely because cloud providers have data centers across multiple regions, providing geographic dispersion automatically. The additional cost of a geographically dispersed recovery site is justified by the critical nature of hospital operations during exactly the regional disasters that make both sites vulnerable when collocated.
Part 3: The hospital's COOP documentation has a section titled "Manual Operations During System Outage" but it contains only one line: "Staff should contact IT for instructions." The CISO asks you to evaluate this COOP plan. What is wrong, and what should it contain?
Show Answer
The COOP plan is essentially non-existent and will fail during any real disruption.
Why "contact IT for instructions" fails: (1) During a major IT outage or disaster, the IT team may not be reachable — they may be working to restore systems, at a different location, or themselves affected by the same disaster that caused the system outage. (2) This is not a plan — it is a delegation of planning responsibility to a team that will be overwhelmed during an actual incident. (3) Staff receiving this response during an outage will not know what to do and will likely cease critical operations until IT responds.
What the COOP plan should contain — for a hospital specifically:
1. Patient registration and admissions: Pre-printed paper registration forms; process for assigning temporary paper medical record numbers; chain of custody for paper records until systems are restored; printer access for paper forms with power-independent printer available.
2. Medication administration: Manual medication administration records (MARs) process; paper-based verification protocols to replace electronic medication verification; who authorizes medications manually and how documentation is maintained.
3. Communication: Internal phone numbers for all departments (printed directory); backup communications if internal VoIP goes down with main systems; paging/overhead procedure if digital communication is down.
4. Test requisitions and results: Paper lab order slips; process for manually transporting specimens and receiving paper results; what to do when electronic lab results are unavailable.
5. Training and testing: Staff must know these procedures before an outage. The plan must be tested (at least a tabletop drill annually) and forms and supplies must be physically available — printed, stored in accessible locations, not on the computer that is unavailable.
The core principle: COOP procedures must be documented specifically enough that staff can execute them without IT assistance, must be physically accessible when digital systems are down (printed copies), and must be tested before a real event. A one-line COOP plan provides false confidence without actual preparedness.
Part 4: The hospital is evaluating migrating its administrative systems to the cloud. The cloud team proposes using a single cloud provider (AWS) for all services to simplify management. The security architect proposes a two-provider strategy (primary workloads on AWS, disaster recovery on Azure). Evaluate both proposals from a resiliency perspective.
Show Answer
Single-provider proposal (AWS only) — adequate management simplicity, meaningful resiliency risk.
AWS is a highly reliable platform, but even AWS experiences outages — including large-scale regional outages affecting multiple Availability Zones simultaneously (the December 2021 US-EAST-1 outage affected major internet services for hours). A single-provider strategy means any AWS-wide or regional outage takes down all hospital administrative systems simultaneously. AWS does offer multi-region deployment within its own infrastructure (deploying across US-East-1 and US-West-2, for example), which addresses most regional failure scenarios. For administrative systems (not life-critical), single-provider with multi-region deployment within AWS may be an acceptable risk. The management simplicity is real: one console, one IAM model, one billing platform, one support contract, staff trained on one platform.
Two-provider proposal (AWS primary, Azure DR) — stronger resiliency, meaningful complexity cost.
A provider-level outage or security incident affecting AWS would not affect Azure-hosted systems. The hospital's administrative systems would fail over to Azure during an AWS outage. This provides both geographic dispersion (different physical infrastructure) and provider dispersion (different operational teams, systems, and failure domains). The tradeoff: managing two cloud environments requires staff trained on both platforms, security configurations maintained consistently across both environments (different IAM models, different networking, different compliance tooling), data synchronization between providers adds cost and complexity, and the failover process between providers must be documented and tested.
Recommendation for this specific case: For a hospital's administrative systems (patient portal, scheduling, billing — not real-time clinical systems), the two-provider approach provides a meaningful resiliency improvement and aligns with the CISO's existing concerns about geographic dispersion. However, a prerequisite is proper documentation and testing of the Azure failover process — a two-provider strategy that has never been tested is just a plan, not a capability. A pragmatic approach: use AWS with multi-region deployment for day-to-day HA, with Azure as the DR target for genuine provider-level failure scenarios. The single-provider multi-region approach handles 95% of failure scenarios with lower complexity; Azure adds coverage for the remaining provider-level scenarios.