Skip to main content

What Is an Update Domain?

Cloud infrastructure is not static. Underlying physical servers, hypervisors, and network devices must be patched, upgraded, or replaced regularly. These operations—planned maintenance—can disrupt the virtual machines and services running on the affected hardware if not managed carefully. An Update Domain is the mechanism cloud platforms use to control the impact of such planned maintenance, ensuring that your workloads stay available even while the infrastructure beneath them is being refreshed.

Understanding Update Domains is critical for architects and engineers who design for high availability. It is not enough to protect against unexpected hardware failures; your system must also tolerate the routine, scheduled work that keeps the cloud platform secure and reliable. This article explains what an Update Domain is, how it works, and how to use it as part of a layered resilience strategy.

Definition of an Update Domain​

An Update Domain is a logical grouping of infrastructure resources—typically virtual machines or the hosts they run on—that are updated, rebooted, or otherwise taken out of service together during a planned maintenance event. Cloud providers perform maintenance one Update Domain at a time. By spreading your application instances across multiple Update Domains, you ensure that a planned operation only affects a subset of your resources while the rest continue serving traffic.

Crucially, an Update Domain is not a physical boundary like a rack or a data center. It is an operational construct designed to sequence maintenance. The exact implementation varies by provider, but the principle is the same: group resources so that no single maintenance window can take down the entire application.

Why Update Domains Exist​

Update Domains solve a fundamental conflict: the cloud platform must be continuously maintained, but customer workloads must remain available. Their objectives include:

  • Reduce planned downtime – By phasing maintenance across groups, the platform avoids the need for a full‑service outage.
  • Maintain service availability – Redundant instances spread across Update Domains allow the application to keep running even while some instances are restarted.
  • Enable rolling infrastructure updates – Providers can patch hypervisors, upgrade firmware, and replace hardware in a controlled, step‑by‑step manner.
  • Improve operational resilience – Customers who design for maintenance events build stronger operational practices and reduce incident risk.
  • Support business continuity – Workloads remain accessible to users during routine platform operations, aligning with uptime commitments.

Planned Maintenance vs Unplanned Failure​

It is important to distinguish between two types of disruption that affect cloud workloads:

  • Planned maintenance includes activities like host OS security patches, hypervisor upgrades, firmware updates, or hardware replacements that the provider schedules in advance. The provider controls the timing and impact, often notifying customers before the operation begins.
  • Unplanned failures are unexpected events: a power supply failure, a network switch crash, a disk corruption. These occur without warning and require the application to detect and recover automatically.

Update Domains address planned maintenance. They ensure that during a scheduled update, only a portion of your resources is affected. Fault Domains, in contrast, address unplanned failures by isolating resources that share a common physical failure point. The two concepts work together: Fault Domains protect against the random, Update Domains protect against the routine.

How Update Domains Work​

During a planned maintenance event, the cloud provider selects an Update Domain and performs the required operations on all hosts belonging to that domain. This might involve live‑migrating virtual machines to other hosts, or briefly pausing and restarting them. Once the domain’s maintenance completes and the workloads inside it are verified as healthy, the provider moves to the next domain.

The process is sequential and typically respects a minimum recovery time between domains, allowing your application to stabilize before the next batch is touched. Your role as the workload owner is to have enough instances distributed across a sufficient number of Update Domains so that a single domain going offline does not cause a service outage.

Some cloud platforms expose Update Domains as a configurable setting when you create availability sets or virtual machine scale sets. Other platforms abstract the concept away, automatically distributing instances across maintenance groups without a named “Update Domain” construct. Regardless of how it is surfaced, the underlying behavior is designed to avoid simultaneous restarts of all your replicas.

Update Domain vs Fault Domain​

Update Domains and Fault Domains are often mentioned together because they both influence how you place workloads, but they serve distinct roles.

  • Primary purpose: An Update Domain sequences planned maintenance events. A Fault Domain isolates unplanned hardware failures.
  • Type of event addressed: Update Domain → scheduled patching, host reboots, software upgrades. Fault Domain → power loss, switch failure, physical component breakdown.
  • Physical basis: Update Domain is a logical grouping with no fixed physical location. Fault Domain corresponds to a physical failure boundary, such as a rack or a shared power bus.
  • Impact of overlapping placement: If all instances of your application are in the same Update Domain, a maintenance reboot takes down the entire service. If they are all in the same Fault Domain, a rack power failure does the same. Both risks need to be mitigated.

A resilient deployment uses both: instances are spread across multiple Fault Domains to survive hardware faults, and across multiple Update Domains to survive maintenance events. Neither alone is sufficient for high availability.

Update Domain vs Availability Zone​

An Availability Zone is a physically separate infrastructure location within a region, designed to withstand large‑scale failures like a building fire or a regional power grid issue. An Update Domain operates at a much finer granularity, often within a single zone.

  • Geographic scope: Availability Zone is a physical site, typically kilometers away from other zones. Update Domain is a logical grouping within a single zone, with no geographic separation.
  • Isolation boundary: An Availability Zone isolates against catastrophic failures. An Update Domain isolates against maintenance‑induced reboots.
  • Typical deployment: You deploy applications across multiple Availability Zones for regional resilience. Within each zone, you further distribute instances across Update Domains to handle maintenance.

The two concepts are complementary. A multi‑zone architecture without Update Domain awareness could still suffer a zone‑wide maintenance impact if all instances within a zone are updated simultaneously.

Designing Highly Available Applications​

To withstand planned maintenance without downtime, consider the following design principles:

  • Deploy at least two instances of each critical component. A single instance in a single Update Domain guarantees a brief outage whenever that domain is updated.
  • Use load balancers to distribute traffic. The load balancer can detect when instances in one Update Domain become unavailable and automatically route requests to the healthy ones in other domains.
  • Replicate stateful data across independent domains. Databases, caches, and file stores should have standby replicas in different Update Domains so that a maintenance reboot of the primary does not cause data unavailability.
  • Design stateless application tiers. Stateless services are easier to restart and redistribute; they don’t require complex replication to survive a brief maintenance pause.
  • Perform regular failover testing. Simulate an Update Domain failure (or a maintenance event) to verify that traffic shifts smoothly and that your monitoring and alerting work as expected.
  • Combine Update Domains with Fault Domains and Availability Zones. Layering these protections gives you defense against both planned and unplanned disruptions at multiple scales.

Typical Use Cases​

Update Domain awareness is beneficial wherever uptime is a priority.

  • Virtual machine clusters: A web server cluster should have members distributed across Update Domains so that a platform reboot doesn’t take every server offline simultaneously.
  • Enterprise business applications: Even traditional applications lifted and shifted to the cloud can gain maintenance‑time resilience by being placed in an availability set that spans Update Domains.
  • Stateful services: A database’s primary and standby should not be in the same Update Domain. If the primary’s host is patched, the standby can take over.
  • Kubernetes worker nodes: Distributing worker nodes across Update Domains helps ensure that pods have surviving nodes even when some hosts are restarted for maintenance.
  • Mission‑critical production systems: Any system that must meet strict availability SLOs needs to be designed with maintenance in mind. Update Domains are a key tool.

Best Practices​

  • Assume maintenance is inevitable. Design your application to tolerate the temporary loss of one instance without user impact.
  • Never run a single‑instance production workload. A single instance is a single point of failure for both planned and unplanned events.
  • Use platform constructs that provide Update Domain distribution. If your cloud provider offers availability sets, scale sets with fault/update domain placement, or managed instance groups, enable them.
  • Validate rolling update behavior during testing. Schedule maintenance windows or simulate them to observe application behavior under controlled conditions.
  • Monitor application health during maintenance events. Track error rates, latency, and throughput to catch regressions that may be introduced by the update.
  • Combine infrastructure redundancy with application resilience patterns. Circuit breakers, retries, and health checks complement infrastructure‑level isolation.

Common Misconceptions​

  • “Update Domains prevent hardware failures.” They do not. Update Domains are for planned maintenance; Fault Domains and Availability Zones protect against hardware failures.
  • “Update Domains replace disaster recovery.” Disaster recovery addresses region‑scale outages and requires cross‑region replication and failover planning. Update Domains are a localized maintenance mechanism.
  • “Every cloud provider exposes Update Domains directly.” Some providers, like Azure, make the concept explicit. Others, like AWS and Google Cloud, achieve the same effect through internal placement logic or live migration without a named “Update Domain” construct.
  • “Update Domains eliminate all application downtime.” They minimize downtime caused by platform maintenance, but application‑level updates, human errors, or code bugs can still cause outages.
  • “Maintenance‑free infrastructure exists in the cloud.” All physical infrastructure requires maintenance. The cloud model abstracts much of it, but the physical layer still needs patching and replacement, which Update Domains accommodate.

Key Takeaways​

  • An Update Domain is a logical grouping used to sequence planned platform maintenance so that not all redundant resources are affected simultaneously.
  • It is distinct from a Fault Domain (which isolates hardware failures) and an Availability Zone (which isolates large‑scale disasters).
  • By distributing workloads across multiple Update Domains, you protect your application from downtime during routine cloud infrastructure updates.
  • Update Domains are a fundamental component of a layered resilience strategy, complementing Fault Domains, Availability Zones, and multi‑region deployments.
  • While some cloud platforms expose the concept directly, all major providers implement analogous mechanisms to minimize the impact of maintenance on customer workloads.

Continue Learning​