AZ-305 High Availability Design: Availability Zones, Scale Sets, App Service, AKS, Azure SQL, Cosmos DB and Storage

High availability design makes a workload keep serving users through a failure, automatically and with little or no data loss, instead of recovering it afterwards. The AZ-305 task has three skills: recommend a high availability solution for compute, for relational data, and for semi-structured and unstructured data. Backup, Azure Site Recovery and restore-based recovery belong to the sibling task on backup and disaster recovery, which the AZ-305 backup and disaster recovery design lesson covers.

Every design starts by naming the failure the workload must survive, because each Azure feature protects against a specific scope:

Composite availability

A request succeeds only if every component on its path is up, so the least redundant dependency caps the availability of the whole workload. A zone-redundant web tier that calls a licence service on one zonal VM, a frontend IP address pinned to one zone, or a database without high availability all turn a zone failure into a full outage. The Well-Architected Framework's reliability pillar asks you to map the request path, find each single point of failure and give every dependency the same failure isolation as the tier that calls it. Region-level design follows the same rule: two regions of compute behind Azure Front Door still fail together if both read and write a database that exists in only one region.

Two practical consequences follow. Fix the weakest tier rather than adding capacity to a tier that is already redundant, and prefer the cheapest scope that meets the stated requirement: if only a zone failure must be survived, zone redundancy inside one region usually meets it at much lower cost and effort than a second region.

For VMs in a region with availability zones, deploy the VMs into different zones behind a zone-redundant Standard Load Balancer; use availability sets only in regions without zones. The three placement features are often confused, but they answer different questions:

An existing VM can't be added to an availability set. To protect a standalone VM, delete it and re-create it inside the availability set, attaching its existing managed disks.

Low latency and zone resilience together

A proximity placement group that holds VMs from two zones contradicts itself. When an application tier needs very low latency to its database tier and must also survive a zone failure, deploy a complete stack (application and database VMs) in each zone and create one proximity placement group per zone holding that zone's VMs. Latency stays low inside each stack and a zone outage leaves the other stack running.

The network path

A zone-redundant Standard Load Balancer frontend is served from every zone, so it survives a zone failure. A zonal frontend is served from one zone: if that zone fails, traffic stops reaching even the healthy VMs in other zones. A public IP address's zone setting can't be changed after creation, so moving to a zone-redundant frontend means creating a new zone-redundant public IP and frontend. Internal dependencies need the same treatment: run them in every zone behind a zone-redundant internal load balancer so callers keep one address.

A zone-spanning scale set, created with several zones selected, distributes its instances across those zones so one zone failure leaves instances running in the others. Flexible orchestration is Microsoft's recommended mode for new scale sets. There are three zone configurations:

• Zone-spanning (zones 1, 2 and 3 selected): one scale set, instances spread across zones. The usual choice for a resilient stateless tier.
• Zonal (one zone selected): every instance is in that zone, so the zone is a single failure domain. Spreading across fault domains inside it doesn't help when the zone fails.
• Nonzonal (no zones selected): instances are spread across fault domains, but Azure gives no guarantee about zones.

Inside a zone, max spreading spreads instances across as many fault domains as possible; a fixed fault-domain count is the alternative. Neither changes zone resilience.

Zone balancing: best effort versus strict

A zone-spanning scale set tries to keep each zone within one instance of the others. In best-effort balancing it may scale out unevenly, so during a zone outage autoscale can add instances in the healthy zones and capacity recovers. In strict balancing the scale set refuses any scale-out that would create an imbalance, which blocks replacement capacity while a zone is down. This applies to every scale-out, whatever triggers it.

Over-provisioning for immediate capacity

Azure doesn't guarantee that new instances can be created during a zone outage, when many customers are scaling out at once. If the surviving zones must carry peak load immediately, over-provision. With C instances spread evenly over N zones, a zone failure leaves C × (N − 1) ÷ N. For example, to keep four instances after a zone failure you need six across three zones (each zone holds two, so four remain), or eight across two; four across three zones (two, one and one) could leave only two. Spreading over more zones therefore costs less for the same guarantee, because each zone carries a smaller share. Autoscale is still useful to restore headroom later, but it is not a substitute when capacity must be there without waiting.

App Service becomes zone resilient by enabling zone redundancy on a Premium v2, v3 or v4 plan (or an Isolated v2 plan in an App Service Environment v3) with at least two instances; AKS becomes zone resilient by spreading node pools, replicas and storage across zones.

App Service

• With zone redundancy on, the platform spreads the plan's instances across zones and reroutes traffic if a zone fails. Every app in the plan becomes zone redundant, so deployment pipelines don't change.
• The plan needs at least two instances, so one survives the loss of a zone. An autoscale rule that starts from one instance leaves a window where the only instance is in the failed zone.
• Lower tiers (Basic, Standard) spread instances across fault domains only. Deployment slots and extra instances don't create zone isolation, and a second plan in the same region isn't a zone design.
• Zone support belongs to the plan's scale unit, which is assigned when the plan is created based on its resource group. An existing plan can be switched to zone redundant only if its scale unit supports zones. If it doesn't, a new plan in the same resource group tends to land on the same scale unit; Microsoft's guidance is to create the zone-redundant plan in a new resource group and redeploy the apps, because apps can't be moved between plans on different scale units.
• An App Service Environment v3 also supports zone redundancy, at a far higher cost; choose it for isolation needs, not for zone redundancy alone.
• App Service is a single-region service: zone redundancy doesn't survive a region outage (see the multi-region section).

Azure Kubernetes Service

• The AKS control plane is zone resilient by default in regions with zones. The financially backed uptime SLA for the API server applies only to the Standard and Premium pricing tiers; the Free tier is for testing.
• Node pool zones are set when the node pool is created and can't be changed later. To make an existing single-zone or nonzonal pool zone resilient without downtime, add a new node pool across zones 1, 2 and 3, cordon and drain the old nodes so pods reschedule while replicas keep serving, then delete the old pool.
• Nodes in three zones don't guarantee that replicas are spread: the scheduler can still pack them into one zone. Add a topology spread constraint with topologyKey: topology.kubernetes.io/zone and maxSkew: 1. Spreading or anti-affinity on kubernetes.io/hostname only separates replicas across nodes, which can all be in one zone.
• Run several replicas of each service so losing a zone leaves some running.

Persistent storage for stateful pods

A pod rescheduled to another zone must be able to attach its volume there. LRS managed disks, including Premium SSD v2 and Ultra Disk, are zonal: they attach only to a node in their own zone, so the pod stays Pending. Two choices work across zones: zone-redundant (ZRS) managed disks, which replicate synchronously across zones and can attach in another zone, and Azure Files shares on a ZRS storage account, which nodes in every zone can mount. From Kubernetes 1.29, AKS clusters deployed across zones use ZRS disks in the built-in disk storage classes, so the risk usually comes from a custom storage class that asks for an LRS SKU. A disk's redundancy is fixed by its SKU (LRS or ZRS); other storage class settings don't change it.

Single-region compute survives a region outage only if you deploy it in a second region and put a global entry point in front of both regions. Scaling out, adding slots, or spreading a regional gateway across zones improves zone resilience but leaves every resource in the region failing together. The entry point is chosen by protocol and failover behaviour:

For HTTP workloads that also need web application firewall inspection after a regional failover, the regional Application Gateway WAF is replaced (or fronted) by Front Door with a WAF policy and both regions' apps in one origin group. Remember composite availability: the second region needs a data tier it can use after failover, such as a failover group listener for Azure SQL or a multi-region Cosmos DB account.

Azure SQL Database survives a zone failure with zone redundancy and a region failure with a failover group. Both keep the application's connection target stable, but they protect different scopes.

Zone redundancy

• Supported in the General Purpose, Business Critical and Hyperscale vCore tiers and the Premium DTU tier. Basic and Standard DTU don't support it, so a Standard DTU database must change tier first.
• A zone-redundant database fails over inside the region automatically with an RPO of zero for a zone failure, keeping the same server name and connection string. General Purpose places data and log files on zone-redundant storage with spare compute in other zones; Business Critical and Premium spread their local-SSD replicas across zones and include zone redundancy at no extra charge.
• Choose General Purpose when the workload doesn't need Business Critical features (in-memory OLTP, local SSD latency, a built-in readable replica): it meets a zone requirement at lower cost.
• For Hyperscale, zone redundancy can be set only at creation. It also needs at least one high-availability replica and zone- or geo-zone-redundant backup storage. To change an existing database, create a copy, point-in-time restore or geo-replica with the new setting and cut over. Named replicas are read-only and are not an HA design.
• Zone-redundant backup storage protects backups, not the running database.

Active geo-replication versus failover groups

Both replicate asynchronously across regions. A failover group is the answer when several databases must move together or the app must not edit connection strings. Read-only workloads such as nightly reports connect to the read-only listener with ApplicationIntent=ReadOnly, so they keep reaching the secondary after any failover; a server name is tied to a role only until the next failover. Geo-secondaries that a failover group creates don't inherit zone redundancy (outside Hyperscale), so enable it on the secondary if the failover region must also survive a zone failure.

Failover policy and failover types

• Customer-managed (recommended): you decide when to fail over, and you can fail over any single group at any time.
• Microsoft-managed: the Azure SQL team triggers failover only during a widespread regional outage, for every Microsoft-managed group in the region, after a grace period that can't be less than one hour, and possibly well after it.
• A planned failover synchronizes the secondary first, so it needs both regions reachable and loses no data. A forced failover works when the primary is unreachable and may lose transactions that hadn't replicated.

SQL Managed Instance uses zone redundancy and its Business Critical replicas within a region and failover groups across regions; SQL Server on Azure VMs uses Always On availability groups with replicas in different availability zones.

SQL Managed Instance

• No active geo-replication. The cross-region option is a failover group between two instances in different regions. It replicates every user database on the instance, keeps the secondary readable and provides read-write and read-only listeners that follow the roles.
• Business Critical runs as a cluster of synchronized replicas on local storage with automatic failover inside the region. One secondary replica serves read-only connections when the client sets ApplicationIntent=ReadOnly (read scale-out), offloading reports with no second instance. General Purpose has no readable replica.
• Zone redundancy spreads the instance across zones for zone failures; it is not a cross-region design.
• The managed instance link replicates between SQL Server and Managed Instance for hybrid and migration scenarios; it is not the instance-to-instance HA option.

SQL Server on Azure VMs

• Choose it when an application needs the full SQL Server engine or a specific version. High availability is your design: an Always On availability group (or a failover cluster instance).
• To survive a datacenter failure, put each replica VM in a different availability zone. A proximity placement group across the replicas works against this.
• In a single subnet, the availability group listener needs an Azure Load Balancer or a distributed network name to route clients to the primary. In a multi-subnet deployment, each replica has its own subnet and the listener has an IP in each, so clients connect with MultiSubnetFailover=True and no load balancer is needed.
• Both choices are independent: separate subnets in one zone still fail with that zone, and separate zones in one subnet still need the load balancer.

Azure Database for PostgreSQL and MySQL flexible server provide high availability through a standby server: zone-redundant HA places it in another zone, same-zone HA in the same zone.

• HA is not available on the Burstable tier; move to General Purpose or Memory Optimized (Business Critical for MySQL) first.
• The standby is billed like the primary, and synchronous commit adds write latency.
• Read replicas can't have HA enabled. A common two-scope design is zone-redundant HA on the primary for zone failures plus a cross-region read replica for regional outages, with a virtual endpoint (PostgreSQL) so applications keep the same connection string after the replica is promoted.

Azure Cosmos DB survives a zone failure through zone redundancy configured for each region, and a region failure through additional regions with either multi-region writes or service-managed failover.

Zone redundancy

• Configured per region, when the region is added to the account. It needs no code or consistency change. Microsoft recommends it especially for single-region accounts; a single-region zone-redundant account keeps read-write availability through a zone failure, which is the lowest-cost design when region outages don't need to be survived.
• To make an existing region zone redundant on a provisioned-throughput account, use the documented process: add a temporary region, make it the write region, remove the original region, add it back with zone redundancy, and fail back.
• Serverless accounts are single-region and choose zone redundancy only at account creation, so an existing serverless account without it needs a new zone-redundant account and a data migration (switching capacity mode would abandon serverless billing).
• Zone redundancy carries a premium on provisioned throughput, waived for accounts with multi-region writes and for autoscale.

Multi-region writes versus a single write region

• If readers in every region must see the latest committed write, the account needs strong consistency, which rules out multi-region writes: use one write region and service-managed failover.
• Service-managed failover lets the platform promote a region without operator action; a manual or forced failover needs a person. An alternative for single-write-region accounts is per-partition automatic failover (PPAF): Azure fails over only the affected partitions to a secondary region, while healthy partitions keep writing in the primary. Under weaker consistency, writes not yet replicated may be lost if the write region's data is permanently lost.
• The SDK's preferred regions list sets where requests go (reads always, writes only with multi-region writes); on its own it doesn't move the write region.

Azure Storage keeps blob reads available through a primary-region outage when the account is read-access geo-redundant (RA-GRS or RA-GZRS) and the application reads from the secondary endpoint. Choosing redundancy for durability is covered in the lesson on storage design; here the focus is how redundancy behaves on the request path.

• The secondary endpoint is a separate name, <account>-secondary.blob.core.windows.net. The application must be designed to send failed reads there (for example through its client retry policy); writes wait for the primary.
• Geo-replication is asynchronous. Last Sync Time, in the account's geo-replication statistics, is the point before which every primary write is guaranteed on the secondary. A reader uses it to judge staleness, and it estimates data loss before any failover.
• Account failover is a recovery action, not the read-availability mechanism. A customer-managed planned failover needs both regions available. An unplanned failover discards data not yet replicated and leaves the account locally redundant in the new primary until you reconfigure geo-redundancy.