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.