In an Elastic Cloud deployment, how do availability zones and replicas provide high availability?

## The two independent knobs High availability on Elastic Cloud is the product of two settings that live in different places and are easy to conflate. The first is **deployment topology**: for each tier — hot, warm, cold, frozen, plus Kibana and machine learning — you choose an instance size and a **number of availability zones**. This is a plan-level, infrastructure decision made in the console or the deployment API. The second is **index-level redundancy**: `number_of_replicas`, set per index (usually through an index template or component template). This is a data-layer decision that lives in Elasticsearch itself and is entirely yours. Zones decide where copies are placed. Replicas decide whether copies exist. Neither alone gives you availability. ## What the platform does with the zone count When a tier spans multiple zones, the platform provisions instances in each of them and configures **shard allocation awareness** on the zone attribute. Allocation awareness makes Elasticsearch refuse to place a primary and its replica on nodes sharing the same awareness value, so with one replica and two zones, each shard has exactly one copy per zone. This is what converts a zone outage from data loss into a capacity loss. Master elections need their own arrangement. A cluster needs a majority of master-eligible nodes to elect a master; an even split across two zones would deadlock if either zone were lost. Elastic Cloud handles this by adding a small **tiebreaker** node in a third zone for two-zone deployments, so the surviving zone plus the tiebreaker still forms a majority. A three-zone deployment has a natural majority and needs no tiebreaker. A single-zone deployment is explicitly not highly available: a zone outage takes the whole thing offline regardless of replica settings, though replicas still protect against the loss of an individual node within that zone. ## The failure mode candidates miss The classic production incident is a deployment carefully sized across three zones whose indices were created with zero replicas — often to save disk on a large log dataset, or because an index template silently applied a legacy default. When a zone goes away, roughly a third of the primaries vanish, the cluster goes **red**, searches over those indices return partial results or fail, and indexing into affected shards stops. No amount of zone spreading helps, because there was never a second copy of those shards. The complementary mistake is running one replica and sizing capacity so tightly that the surviving zones cannot absorb the traffic. Losing a zone in a three-zone deployment removes a third of the compute; if the cluster was already at 80% CPU, the survivors saturate and the outage becomes a performance outage instead of a data outage. Real HA planning sizes for **n-1 zones**. ## Recovery behaviour after a zone returns When a zone comes back or the platform replaces the lost instances, Elasticsearch promotes surviving replicas to primaries and then rebuilds the missing copies by recovering from the remaining ones. That recovery consumes network and disk I/O and competes with live traffic, so a large cluster is degraded for a while after the infrastructure is nominally healthy again. Recovery throttling settings exist for exactly this trade-off, and knowing that recovery is not instantaneous separates operators from users. ## Choosing a number **Three zones with one replica** is the default posture for anything user-facing: survive a full zone loss, keep a quorum, keep every shard available. **Two zones with one replica plus the tiebreaker** is a cost compromise that still survives a zone loss but leaves less headroom. **One zone** is legitimate for development, for data reconstructible from an upstream source, or for a frozen tier whose data lives in object storage anyway. Note that more replicas also add search throughput, so the choice is not purely about resilience — but each replica multiplies storage cost, which on a metered service is immediately visible. ## Frozen and searchable-snapshot tiers A nuance worth mentioning: data in a frozen tier is backed by searchable snapshots in object storage, with nodes holding only a local cache. Losing such a node loses cache, not data, so redundancy requirements there are different from a hot tier holding the only copy of recent writes. Applying hot-tier replica thinking uniformly across tiers wastes money. ## Answering well State the split in one sentence — zones place copies, replicas create them — then give the failure scenario, the tiebreaker's role in two-zone deployments, and the capacity point about surviving a zone loss without saturating. That covers the ground an interviewer is probing.