---
title: "Reliability, upgrades, and disaster recovery"
chapter: "14"
---

# Reliability, upgrades, and disaster recovery

Reliability comes from removing single failure assumptions and rehearsing
change.

## Availability

Spread nodes and Pods across Availability Zones. Use topology constraints,
anti-affinity, readiness, and disruption budgets. Ensure databases, queues,
DNS, certificates, identity, quotas, and external integrations meet the same
user journey SLO.

## EKS upgrades

EKS Kubernetes versions have a standard support period and then extended
support. Extended support costs more; it is a bridge, not an upgrade strategy.
Use EKS Upgrade Insights to find deprecated APIs. Test in a lower environment
and upgrade one minor version at a time.

The control plane, EKS add-ons, node images, and applications have separate
lifecycle work. Managed node groups are not automatically upgraded when the
control plane changes. Roll nodes safely and confirm workloads, PDBs, and
capacity.

## Disaster recovery

Select backup/restore, pilot light, warm standby, or active/active from RTO/RPO
and business cost. Preserve IaC, Kubernetes objects, images, data, identity,
secrets, DNS, and capacity. A green backup job is not proof; a timed restore is.

## Feynman check

High availability handles expected local breakage while the system stays
running. Disaster recovery rebuilds service after a larger loss. You need both
when the business requires both.