Update Domain in Cloud Computing
Short Answer
An update domain is a logical grouping of cloud resources that are updated or rebooted together during planned platform maintenance. By spreading redundant workload instances across multiple update domains, you prevent a maintenance event from taking down every instance at the same time. Update domains exist to turn a potentially service-disrupting maintenance operation into a sequenced, non-overlapping process.
Why the Concept of an Update Domain Exists
Cloud providers patch hypervisors, upgrade host operating systems, and replace hardware regularly — activities that often require the physical hosts running your virtual machines to be rebooted. If all instances of your application were placed on hosts that reboot simultaneously, your service would experience a full outage, not because of a hardware failure, but because of a routine maintenance operation.
The update domain concept eliminates this risk. It groups resources into separate maintenance buckets. When the provider performs a planned update, it takes down one update domain at a time, waits for the resources to recover, and only then proceeds to the next domain. As long as your workload spans multiple update domains, at least some instances remain available throughout the maintenance window.
This is not about hardware failure. It is about controlled, predictable disruptions introduced by the people who keep the cloud platform running. Both types of disruption — planned and unplanned — threaten availability, and both require architectural defenses. Update domains are the defense against the planned kind.
What an Update Domain Usually Represents
An update domain is an abstraction; you won't find it on a physical rack diagram. It's a label the cloud platform attaches to resources to sequence maintenance work. All virtual machines in the same update domain are likely to be rebooted at the same time when the platform applies an update. VMs in different update domains are guaranteed (or nearly guaranteed) to be rebooted at different times.
The number of update domains available and how resources are assigned to them varies by provider and configuration. In many cases, the platform automatically distributes resources across update domains when you use constructs designed for high availability. In other cases, you can configure the number of domains yourself.
Key characteristics:
- Maintenance sequencing: The primary role is to order planned reboots so they don't happen all at once.
- No physical meaning: Unlike a fault domain, which often maps to a rack or a power bus, an update domain has no fixed physical location. It's purely operational.
- Provider-managed: The timing, scope, and sequencing are controlled by the cloud provider, not the customer. You can influence the grouping through placement constructs, but you don't schedule the updates.
- Transient impact: When an update domain is serviced, the resources inside it may become briefly unavailable, but they are not destroyed or replaced.
Update Domain vs Fault Domain
This is the most critical distinction to grasp, because the two terms are often introduced together and easily confused.
A fault domain isolates resources against unplanned hardware or infrastructure failures — a rack losing power, a network switch dying, a cooling unit failing. An update domain isolates resources against planned maintenance operations — host patching, hypervisor upgrades, platform-initiated reboots.
| Aspect | Fault Domain | Update Domain |
|---|---|---|
| Primary purpose | Isolate against unplanned hardware/infrastructure failures | Isolate against planned maintenance and platform update events |
| Event type | Unexpected: rack power loss, switch failure, hardware fault | Scheduled: host OS patches, hypervisor updates, platform maintenance reboots |
| Planned vs unplanned | Unplanned | Planned |
| Role in workload placement | Ensures that redundant instances do not sit on the same hardware that could fail together | Ensures that redundant instances are not all rebooted at the same time during a maintenance cycle |
| Typical architecture concern | "If a rack dies, will my application stay up?" | "If the provider patches the hypervisor, will my application stay up?" |
| Example | Three VMs in an Azure availability set distributed across three fault domains; a rack power loss might affect one | Those same three VMs distributed across three update domains; a host reboot cycle affects one domain at a time |
A highly available architecture typically needs to consider both. If you only isolate against hardware failure, a planned maintenance event could still cause a full restart of your application tier. If you only isolate against maintenance, a rack-level power loss could still take down everything. Fault domains and update domains are complementary layers, not alternatives.
Update Domain vs Availability Zone
An Availability Zone is a physically separate location within a region, with independent power, cooling, and networking. It isolates against large-scale failures — a data center fire, a major power event, a regional fiber cut. An update domain is a much smaller operational boundary focused on sequencing maintenance within a single zone or deployment group.
| Aspect | Update Domain | Availability Zone |
|---|---|---|
| Scope | A logical grouping of resources for maintenance sequencing, typically within a single zone or availability set | A fully isolated physical location within a region, with independent infrastructure |
| Type of isolation | Operational: prevents simultaneous planned reboots | Physical: prevents a data-center-scale event from affecting multiple zones |
| Main purpose | Maintain availability during provider-initiated maintenance | Maintain availability during large-scale infrastructure failures |
| Relation to resilience | Protects against planned downtime | Protects against unplanned, large-scale downtime |
| Example use | VMs in an availability set spread across update domains so a host patch doesn't reboot all of them | VMs placed in us-east-1a, us-east-1b, and us-east-1c so that a zone failure leaves two zones running |
Update domains and Availability Zones work at different scales and on different failure types. You can — and often should — use both: deploy across multiple Availability Zones for broad resilience, and within each zone, distribute instances across multiple update domains to handle maintenance without service interruption.
Update Domain vs Rolling Deployments
Some engineers hear "update domain" and think of a rolling deployment, where a new version of an application is gradually rolled out to replace the old version. The two concepts share the idea of staged change, but they are not the same thing.
A rolling deployment is an application-level release strategy, controlled by your CI/CD pipeline. You decide when to deploy, which instances to update, and how to monitor for problems. An update domain is an infrastructure-level maintenance mechanism, controlled by the cloud provider. You don't control the timing or the content of the update; you only control how your instances are grouped into domains so that when the update happens, it doesn't cause a full outage.
Think of it this way: a rolling deployment protects your users from a bad code change by phasing the release. An update domain protects your users from a platform maintenance event by phasing the reboot. Both matter, but they live at different layers of the stack.
Why Update Domains Matter in Real Cloud Architecture
The practical impact of update domains is often felt during maintenance windows that the customer never explicitly schedules. The cloud provider announces a maintenance event, and resources begin rebooting across update domains. If you've designed correctly, your load balancer health checks mark the rebooting instances as unhealthy, traffic shifts to the remaining instances, and your users notice nothing. If you haven't, the maintenance event causes a partial or complete outage — one that could have been avoided without any additional cost, just through informed placement.
Stateful workloads are particularly sensitive. If you run a database or a stateful application on a single VM in one update domain, that VM will reboot during maintenance, and you will experience downtime. If you replicate that database across two VMs in different update domains, the primary might reboot while the secondary serves traffic — assuming your replication and failover are correctly configured.
The concept also reinforces a broader architectural principle: availability is not only about surviving failures; it's about surviving change. Planned maintenance is change. A system that cannot tolerate a controlled, expected reboot of one of its components is not highly available, even if it could theoretically survive a hardware failure. Update domains are a tool for building that tolerance.
Update Domains and High Availability
High availability requires redundancy, and redundancy only works if the redundant copies are not all vulnerable to the same event at the same time. Update domains ensure that redundancy is effective against planned maintenance, just as fault domains and Availability Zones ensure it is effective against unplanned failures.
The most common pattern is to place instances across both fault domains and update domains. In Azure, an availability set does this automatically: it distributes VMs across multiple fault domains (typically two or three) and multiple update domains (up to 20, depending on configuration). This way, a single rack failure cannot take down the entire workload, and a single maintenance wave cannot reboot every instance simultaneously.
It's worth noting that update domain separation is not a substitute for multi-zone or multi-region resilience. A large-scale platform event — like a network configuration error that affects an entire zone — can still cause disruption regardless of how many update domains you use within that zone. Update domains are a layer in the resilience stack, not the entire stack.
How Azure and Broader Cloud Architecture Use the Update Domain Concept
The term update domain is most visible in Azure's documentation and certification materials because it is an explicit, configurable parameter in availability sets and Virtual Machine Scale Sets. When you create an availability set, you specify the number of update domains (typically 5 or more), and Azure automatically distributes your VMs across them. During planned maintenance, Azure updates one update domain at a time, with a recovery time between domains so that your application has time to become healthy again.
Other cloud providers manage planned maintenance through different abstractions, but the underlying problem is the same. AWS, for example, does not expose "update domain" as a named construct, but its placement groups and Auto Scaling groups with rolling update policies serve analogous purposes. GCP offers live migration for many VM types, which can move running instances from a host that needs maintenance to a different host without a reboot, reducing the need for explicit update domain logic. However, when live migration is not available, GCP provides maintenance event notifications and scheduling options that achieve a similar effect.
In every case, the architectural reasoning is identical: the cloud provider needs to maintain the underlying infrastructure, and customers who want high availability must design their workloads so that a single maintenance operation does not cause a service outage.
Common Misunderstandings About Update Domains
“Update domain is just another name for a fault domain.”
No. Fault domains protect against unplanned hardware failures. Update domains protect against planned maintenance reboots. They are different concepts that work in parallel.
“Update domains only matter if my application is stateful.”
Any application with a single instance — stateless or stateful — will experience downtime during a maintenance reboot if that instance is the only one serving traffic. Multiple instances across update domains protect against this, whether the workload is stateful or not.
“If I deploy multiple instances, planned maintenance is already handled automatically.”
Not necessarily. If you manually deploy instances and don't place them in a construct that distributes them across update domains, they may all end up in the same domain and reboot together. Auto-distribution requires the right platform feature.
“Update domain is the same as an Availability Zone.”
An Availability Zone is a large-scale, physically isolated failure domain. An update domain is a small-scale, logical maintenance sequencing boundary. They operate at entirely different levels.
“Update domain is just a maintenance window.”
A maintenance window is a scheduling concept — a period during which maintenance is allowed. An update domain is a grouping concept that determines which resources are affected together during that window.
“Update domains only matter for Azure certification exams.”
Although the term is Azure-prominent, the underlying need to isolate against planned maintenance is universal. Any cloud engineer responsible for production availability must think about what happens when the provider patches its infrastructure.
When to Learn Next: Related Concepts
Once you understand the role of update domains in sequenced maintenance, these companion concepts will deepen your resilience knowledge.
Fault Domain is the direct counterpart — where update domains deal with planned events, fault domains deal with unplanned hardware failures. Together they form the twin pillars of workload placement within a zone.
Availability Zone extends the failure isolation model to a larger scale. Understanding update domains helps you see why zone-level isolation alone may not be enough for maintenance-related availability.
High Availability ties both update domains and fault domains into a cohesive design strategy. With the vocabulary in place, you can evaluate whether a proposed architecture truly protects against the range of disruption types.
Disaster Recovery and Region move beyond the zone entirely, addressing failures that are too large for zones or update domains to handle.
Replication is often the mechanism that keeps data available during both planned and unplanned events. Understanding how replication interacts with update domains helps you design stateful workloads that stay online during maintenance.
Update Domain in One Sentence
An update domain is a cloud provider's method for sequencing planned maintenance so that redundant resources are rebooted one group at a time, keeping at least part of your workload available throughout the process.
FAQ
What is an update domain in cloud computing?
An update domain is a logical grouping of cloud resources that are updated or rebooted together during planned platform maintenance. Distributing resources across update domains prevents a maintenance event from rebooting every instance simultaneously.
What problem does an update domain solve?
It prevents planned maintenance operations — such as host patching or hypervisor upgrades — from causing a full application outage by ensuring that only a subset of redundant instances is affected at any one time.
What is the difference between an update domain and a fault domain?
A fault domain isolates resources against unplanned hardware failures (rack power loss, switch failure). An update domain isolates resources against planned maintenance events (host reboots, platform updates). One deals with the unexpected; the other deals with the scheduled.
What is the difference between an update domain and an Availability Zone?
An Availability Zone is a physically isolated location within a region that protects against large-scale failures. An update domain is a logical maintenance sequencing boundary within a much smaller scope. They address failure isolation and maintenance isolation, respectively.
Why do update domains matter for high availability?
High availability requires that no single event — planned or unplanned — can take down the entire service. Update domains ensure that planned maintenance does not become a single point of failure for the application.
Is update domain mainly an Azure concept?
The term is most prominently used in Azure, but the architectural need — isolating planned maintenance impact — exists across all cloud platforms. Other providers use different mechanisms and names to achieve the same outcome.
Is an update domain the same as a maintenance window?
No. A maintenance window is a time period during which maintenance may occur. An update domain is a grouping of resources that are maintained together. The window defines when; the domain defines which.
Do update domains still matter if I use multiple Availability Zones?
Yes. Multiple zones protect against large-scale failures, but a single zone still contains resources that may require maintenance. Within each zone, you should still distribute instances across update domains to avoid a maintenance reboot affecting all instances in that zone simultaneously.