High Availability: 99.9% vs 99.99% vs 99.999%

High availability is quantified as a percentage of uptime over a defined period, typically one year. The term 'nines' refers to the number of 9s after the decimal point: 99.9% (three nines), 99.99% (four nines), and 99.999% (five nines). Each additional nine reduces allowable downtime by a factor of 10. The GCDL exam expects you to know the exact annual downtime values: - 99.9%: 8.77 hours (or 525.6 minutes) - 99.99%: 52.6 minutes - 99.999%: 5.26 minutes

These values are calculated as: (1 - availability) * 365.25 * 24 * 60 = downtime minutes. For monthly SLAs, divide by 12. For example, 99.9% monthly is about 43.8 minutes.

Achieving high availability requires eliminating single points of failure (SPOFs) through redundancy, fault isolation, and automated failover. Google Cloud provides services that map to each tier:

99.9% (Three Nines) – Suitable for development, test, or non-critical workloads. Achieved by deploying a single resource (e.g., one Compute Engine VM) with basic monitoring and manual recovery. Google's infrastructure itself offers 99.9% availability for individual zonal resources. No special design needed.

99.99% (Four Nines) – Requires multi-zone deployment. For Compute Engine, use managed instance groups (MIGs) with autoscaling across at least two zones. A regional load balancer distributes traffic. If one zone fails, traffic is rerouted within seconds. Cloud SQL offers 99.99% for regional instances (with automatic failover to a standby in another zone). Key: you must configure multi-zonal or regional resources.

99.999% (Five Nines) – Demands multi-region deployment with active-active or active-passive failover. For example, Spanner provides 99.999% availability by replicating data across three or more regions using synchronous replication and Paxos consensus. Cloud Load Balancing with global anycast IP can direct users to the nearest healthy region. Achieving five nines often requires custom application-level redundancy and careful planning for planned maintenance windows.

To configure a multi-zone MIG for 99.99%:

gcloud compute instance-groups managed create my-mig \
    --zone=us-central1-a \
    --template=my-template \
    --size=3 \
    --zones=us-central1-a,us-central1-b,us-central1-c

This creates instances across three zones. The regional load balancer must be set up:

gcloud compute backend-services create my-backend \
    --load-balancing-scheme=EXTERNAL \
    --protocol=HTTP \
    --health-checks=my-health-check \
    --global

Then add the MIG as a backend:

gcloud compute backend-services add-backend my-backend \
    --instance-group=my-mig \
    --instance-group-zone=us-central1-a \
    --balancing-mode=RATE \
    --max-rate-per-instance=100

Each additional nine roughly doubles infrastructure cost. A single zonal VM costs ~$50/month; a multi-region Spanner instance can cost thousands. The exam tests that you understand the cost vs. benefit tradeoff: not every workload needs five nines. For example, a batch processing job that runs nightly can tolerate hours of downtime – three nines is sufficient.

Scenario 1: E-commerce Platform (99.99% required) A mid-size e-commerce company runs its website on Google Cloud. They need four nines during peak shopping seasons (Black Friday). They deploy a regional managed instance group across three zones (us-central1-a, b, c) with a global HTTP(S) load balancer. The backend service uses a Cloud SQL regional instance for the product catalog. They configure health checks with a 5-second interval and 2 unhealthy thresholds (so ~10 seconds to detect failure). During a zone outage, the load balancer routes traffic to healthy zones within seconds. The Cloud SQL failover completes in under 60 seconds. Total downtime per year is under 52.6 minutes. Common misconfiguration: not setting up read replicas for the database, causing read-heavy traffic to overwhelm the primary during failover. They learned to use Cloud SQL read replicas in each zone to offload reads.

Scenario 2: Financial Trading System (99.999% required) A financial services firm requires five nines for its trading application. They use Spanner multi-region (e.g., us-central1, us-east1, us-west1) to achieve 99.999% availability. Spanner automatically handles synchronous replication across regions. For compute, they deploy a global MIG with instances in three regions, each behind a global load balancer. They use Cloud CDN for static content. The challenge: planned maintenance (e.g., OS patching) must not cause downtime. They use rolling updates with a max surge of 1 and a max unavailable of 0. They also implement canary deployments to test new code. Cost is high (~$10k/month for Spanner alone) but justified by the cost of downtime: each minute of outage costs $100k in lost trades.

Scenario 3: Internal HR Portal (99.9% sufficient) A company's HR portal is used for employee self-service (benefits, time-off requests). It runs on a single Compute Engine VM with a Cloud SQL standard instance. If the VM goes down, IT manually restores from a snapshot. Downtime of a few hours is acceptable because employees can submit requests later. They save costs by not implementing multi-zone redundancy. The GCDL exam tests that you can identify when three nines is appropriate: non-critical, batch, or internal tools.