Availability and recovery

Availability is a service’s ability to continue responding when infrastructure fails. Recovery mechanisms differ for an instance, an availability zone, a region, and the platform’s federation plane.

Failure scopes

The runtime recovers failed component instances from persisted state on surviving nodes. Spreading a deployment across availability zones can protect it from the loss of one zone, provided its compute and storage configuration support that failure.

A second region adds a replica outside the first region’s failure boundary. Reads can continue from surviving replicas, but moving writes and traffic away from a failed region requires the documented failover procedure.

A single-region deployment instead relies on backups when its entire region is lost. Backup configuration and ownership depend on the deployment option; in BYOK8s, the customer owns database backups and point-in-time recovery.

Running applications can continue when the federation plane is unavailable, while management operations such as deployment are affected. Control-plane availability and application availability are separate concerns.

Recovery objectives and data loss

The recovery time objective (RTO) states how long recovery may take. The recovery point objective (RPO) states how much recent data may be lost.

Cross-region replication is asynchronous. A surviving region cannot recover writes it never received. If the failed region returns, its events can replicate later, but changes conflicting with writes made after failover are resolved according to the primary-region rules. Multi-region deployment therefore does not imply zero data loss.

Choose zones and regions from the failures the workload must tolerate, its recovery objectives, residency requirements, and cost. Additional regions provide another recovery option, with additional infrastructure and replication traffic.

Next steps