High availability

High availability means keeping a service usable for the required proportion of time, including when infrastructure fails or maintenance occurs. Availability should be measured from the user's perspective: a running server does not make an application available if users cannot log in or complete transactions. An availability target of 99.9% allows approximately 43 minutes of unavailability in a 30-day month. Higher targets generally require additional redundancy, automation, testing, and operational effort.

The central design principle is to avoid single points of failure. Two application servers provide limited protection if both depend on one database, one network appliance, or one power source. Engineers must examine the entire request path, including traffic routing, compute, storage, authentication, and external dependencies. Redundant capacity must also be sufficient to serve the required workload after a component or location fails.

Cloud infrastructure provides failure domains that help separate redundant components. In AWS, a Region is a geographic area containing multiple Availability Zones. Each Availability Zone consists of one or more discrete data centers with redundant power, networking, and connectivity. Deploying application instances across at least two Availability Zones in one Region is a common approach to surviving an instance failure or an Availability Zone disruption. Several instances in one Availability Zone do not provide the same protection.

A load balancer distributes incoming traffic across registered application targets and uses health checks to identify targets that should receive requests. For example, an online store can run application instances in two Availability Zones behind a load balancer. When one instance fails, the load balancer can direct requests to other healthy instances while an automated scaling group replaces the failed instance. This behavior depends on correct health checks, routing configuration, and sufficient healthy capacity; a load balancer alone does not make the entire application highly available.

Application state needs equal attention. Storing shopping carts only in an instance's memory can cause users to lose their carts when traffic moves elsewhere. Externalizing session state to an appropriately resilient data store makes application instances easier to replace. A database deployment with synchronous replication and automated failover can protect against certain infrastructure failures, although failover can still briefly interrupt connections. Clients need suitable timeouts, retries, and connection recovery.

Multiple Regions provide protection against a broader class of disruptions, including loss of an entire Region. An application might actively serve traffic in two Regions or maintain a standby environment in another Region. However, multi-Region operation introduces additional cost, replication delay, data consistency decisions, routing complexity, and failover procedures. It is not necessary for every highly available workload. Choose it when business requirements justify regional failure protection, and define recovery time and acceptable data loss explicitly.

High availability is related to, but different from, elasticity and agility. Elasticity adjusts capacity as demand changes, while agility enables teams to provision resources and deliver changes quickly. Elastic scaling can support availability during demand spikes, but it does not replace redundancy. Backups support recovery but do not keep a failed service immediately accessible. Fault tolerance generally aims to continue operating without interruption through specified failures, whereas high availability can allow brief recovery periods.

Practical operation includes monitoring successful user transactions, testing failover, deploying changes gradually, and checking that surviving resources can handle peak demand. Redundancy increases cost and complexity, and shared configuration errors can affect every replica at once. High availability is therefore an end-to-end engineering outcome, not a guarantee obtained simply by selecting multiple locations or buying a service with an availability commitment.