What Is Azure Dedicated Host?

Microsoft announced a public preview of Azure Dedicated Host in August 2019, a service that provides organizations with exclusive access to physical Azure servers — hardware that is not shared with any other customer. This model is commonly called single-tenant infrastructure, as opposed to the multitenant model in which multiple customers share the same underlying hardware.

For most Azure customers, virtual machines (VMs) run on shared physical hardware alongside workloads from other organizations. While Azure’s hypervisor and security architecture isolate those workloads, certain industries — healthcare, finance, defence and government contracting, for example — operate under regulatory or compliance mandates that explicitly require dedicated, unshared hardware. Azure Dedicated Host was designed to satisfy those requirements.

Supported Workloads

Azure Dedicated Host supports a range of common enterprise workloads on its single-tenant physical servers:

• Linux VMs — any Azure-supported Linux distribution running on a dedicated host.
• Windows Server VMs — Windows workloads with the option to bring existing licenses.
• SQL Server on Azure VMs — SQL Server instances hosted inside Azure VMs on dedicated hardware.

How Azure Dedicated Host Compares to Competing Services

Azure Dedicated Host is broadly comparable to similar offerings from the other major cloud providers:

• AWS Dedicated Hosts — Amazon Web Services launched dedicated hosting several years before this Azure preview, giving AWS customers a head start with the single-tenant model.
• Google Cloud Sole-Tenant Nodes — Google Cloud Platform offers an equivalent feature called a sole-tenant node, which reserves a physical Compute Engine server for a single project.

It is worth noting that Azure Government is not a single-tenant service. According to a Microsoft spokesperson at the time: “Azure Government is a cloud service that is shared but dedicated to government customers. As a shared cloud service, Azure Government does not provide customers control over the actual VM to physical host mapping.” Azure Dedicated Host fills a different and complementary role.

Hardware Options and VM Series

Customers provisioning an Azure Dedicated Host select a host type that determines the underlying hardware characteristics — VM series, RAM capacity, processor brand, and core count. A single host type supports only one VM series, though multiple VM sizes within that series can be mixed on the same host.

At preview launch, Microsoft documented two dedicated host types on its pricing page:

• Dedicated Host Type 1 — supports the Dsv3 and Esv3 Series VMs (general purpose and memory-optimised workloads).
• Dedicated Host Type 2 — supports the Fsv2 Series VMs (compute-optimised workloads).

Additional host types were expected to become available as the service moved toward general availability.

Maintenance Control: Deferring Updates Up to 35 Days

One of the most operationally significant features of Azure Dedicated Host is granular control over host-level maintenance. On multitenant Azure infrastructure, Microsoft schedules and applies host OS updates on behalf of all customers. With a dedicated host, that control shifts to the customer.

“With an Azure Dedicated Host, you can control all host-level platform maintenance initiated by Azure (e.g., host OS updates). An Azure Dedicated Host gives you the option to defer host maintenance operations and apply them within a defined maintenance window, 35 days. During this self-maintenance window, you can apply maintenance to your hosts at your convenience, thus gaining full control over the sequence and velocity of the maintenance process.”

— Microsoft Azure announcement, August 2019

This is particularly valuable for organisations running high-availability applications where unplanned reboots can cause costly downtime or SLA breaches. A 35-day deferral window allows teams to align host maintenance with pre-approved change control periods.

Pricing Model

Azure Dedicated Host uses a layered pricing structure:

• Host cost — a charge for reserving the entire physical host, regardless of how many VMs are actually running on it.
• VM hourly cost — standard Azure VM charges for each virtual machine provisioned on the host.
• Windows licensing cost — an additional hourly charge when running Windows Server VMs, unless existing licenses are applied via Azure Hybrid Benefit (see below).

Because customers pay for the entire host upfront, right-sizing the host type relative to actual VM density is essential for cost efficiency. Underutilised dedicated hosts can be significantly more expensive per workload than equivalent multitenant VMs.

Licensing: Azure Hybrid Benefit and the October 2019 Deadline

Microsoft used the Azure Dedicated Host launch to introduce updated licensing rules that rewarded early adoption. Organisations could apply their existing on-premises Windows Server and SQL Server licenses to Azure Dedicated Host workloads through the Azure Hybrid Benefit program — the mechanism that allows on-premises volume licenses to be re-used on Azure infrastructure.

The key licensing conditions at the time of the preview announcement were:

• Licenses purchased before October 1, 2019 could be used on Azure Dedicated Host without requiring active Software Assurance coverage.
• Licenses purchased on or after October 1, 2019 would require Software Assurance to qualify for Azure Hybrid Benefit on dedicated hosts.
• The October 2019 deadline also applied to software hosted by what Microsoft called Listed Providers: Microsoft itself, Alibaba, Amazon (including VMware Cloud on AWS), and Google. Other hosting providers were not subject to this change.

This licensing approach gave organisations running compliant on-premises estates an economic incentive to migrate to Azure Dedicated Host before the deadline, while aligning future dedicated-host licensing more closely with Microsoft’s standard Software Assurance requirements.

Key Takeaways for DevOps and Cloud Engineers

• Compliance-driven architectures — if your organisation requires physical host isolation for regulatory reasons (PCI-DSS, HIPAA, FedRAMP equivalents, etc.), Azure Dedicated Host provides a documented single-tenant boundary within the Azure public cloud.
• Maintenance windows matter — the ability to defer host OS patching by up to 35 days gives platform and SRE teams meaningful control over change management schedules.
• VM series constraints are real — plan host type selection carefully; mixing VM series on a single dedicated host is not supported.
• Cost modelling is non-trivial — pay-for-the-whole-host pricing requires higher VM density to achieve cost parity with standard Azure VMs.
• Azure Hybrid Benefit is the cost lever — organisations with existing Windows Server and SQL Server volume licenses should evaluate whether Azure Hybrid Benefit applies before provisioning.

Even well-architected software frequently has weak exception handling. Experienced teams can design clean domain models, solid persistence layers, and elegant APIs—and still ship software that crashes with cryptic stack traces or bombards users with meaningless error dialogs. Exception handling is a discipline of its own, and getting it right requires deliberate design, not an afterthought.

What Is an Exception, Really?

An exception occurs when a function cannot do what it was designed to do. The cause may be technical (a file is locked, a network socket timed out) or functional (business rules are violated, input data is invalid). Before writing any catch block, a developer should answer three questions:

• What went wrong and why?
• What happens if this exception is ignored?
• What steps return the application to a defined, consistent state?

Not every error condition is equally serious, and the correct response varies dramatically depending on the context in which the error occurs.

User Experience and Exceptions

When Should You Show the User an Error?

Showing an error popup is appropriate in exactly two situations:

1. The user made a mistake or can resolve the situation themselves. For example, they tried to save a file that is already locked by another process. A prompt asking them to choose a different file location is genuinely useful.
2. The error is serious enough that the program must stop, and the user needs to know why. A fatal failure that cannot be recovered from warrants a clear explanation before shutdown.

In every other scenario, showing a popup adds noise without helping the user. If the error is internal—for example, a cache file that could not be written—the user had no intention of triggering that operation and cannot act on the message. Silently degrading (running without cache, logging internally) is almost always the right call.

Anatomy of a Good Error Message

When a user-facing error message is warranted, it should contain three elements:

• The loss of functionality (what failed): “Your file could not be saved.”
• The reason (why it failed): “The destination folder is not accessible.”
• Actionable guidance (what the user can do): “Check that you have write permission to that folder, or choose a different save location.”

Most developers stop after describing the problem. The third element—actionable guidance—is the hardest to write and the most valuable to the user. Omitting it leaves people stranded.

Functional vs. Technical Exceptions

A technical exception stems from infrastructure: a missing file, a full disk, a refused network connection. A functional exception stems from business rules: invalid input, a constraint violation, a workflow precondition that was not met.

For functional exceptions, consider whether the situation is truly exceptional. If your application is designed to tolerate an unavailable neighbor system and degrades gracefully when that system is unreachable, a SocketException at the network layer may not require any user notification—it may not even warrant a log entry if the condition is frequent and expected. Design your exception strategy around what is normal for your system, not around what the underlying framework considers exceptional.

The Technical Side of Exception Handling

Avoid Unnecessary Custom Exceptions

A common anti-pattern is creating a deep hierarchy of custom exceptions that add no real information. For instance, catching a FileNotFoundException only to wrap it in a CustomFileNotFoundException extends CustomIOException extends CustomTechnicalException serves no purpose. The underlying cause is unchanged; you have only added indirection.

Introduce a custom exception only when it provides a genuine semantic benefit—specifically, when the same underlying framework exception can arise from two distinct application-level problems that require different handling strategies. For example:

// Catching FileNotFoundException and branching on root cause
try {
    saveFile(path, data);
} catch (FileNotFoundException ex) {
    if (!hasWritePermission(path)) {
        throw new InsufficientPrivilegesException(path, ex);
    }
    throw new LocationDoesNotExistException(path, ex);
}

Here, two distinct custom exceptions are justified because they represent different problems with different remediation paths. Use platform-provided exceptions wherever the semantics are already correct; introduce custom ones sparingly.

Throw Early, Catch Late

“Throw early, catch late” is a well-established principle. It means:

• Throw early: Validate preconditions and detect errors as soon as possible, before state can become inconsistent.
• Catch late: Handle exceptions at the layer that has enough context to respond meaningfully—not deep in a data-access routine that knows nothing about the UI or security subsystem.

If a FileNotFoundException is caught immediately inside a low-level persistence method, that method has no access to the security layer, no ability to inspect user permissions, and no path to the UI. The exception should be allowed to propagate up to a caller that has all of that context. At that outer layer, you can inspect permissions, transform the exception into something meaningful, and decide how to respond.

A concern sometimes raised against this approach is logging: “We need to catch early so we can log the stack trace.” This is not necessary. When you let an exception bubble up naturally, the full stack trace is preserved. You can log it at the point where you handle it, and the trace will still show you the original call site where the error originated.

Encapsulate Exceptions at Layer Boundaries

When an exception crosses an architectural layer boundary—for example, from the persistence layer into the service layer, or from the service layer into the presentation layer—it is good practice to transform it into an exception appropriate for the receiving layer.

The presentation layer should not need to know about FileNotFoundException or SocketException. It should receive something like PersistenceException or ExternalServiceUnavailableException. Two implementation strategies are common:

1. Inheritance: Make your specific exception extend the layer-boundary exception (InsufficientPrivilegesException extends PersistenceException). No explicit transformation is needed; the exception passes through automatically, and the stack trace is unbroken from top to bottom.
2. Wrapping: Throw a new layer-boundary exception with the original as an inner/cause exception. This allows the original exception to derive from a more appropriate base class (e.g., the platform’s own FileNotFoundException) rather than being forced into your custom hierarchy. Log the full chain at the transformation point so the stack trace is captured even if the inner exception is not re-thrown.

Both approaches are valid. The key requirement is that no exception should cross a layer boundary carrying semantics that the receiving layer cannot understand or act upon.

Practical Checklist

Use the following checklist when designing exception handling for any significant feature:

• For each error condition, ask: what went wrong, can it be ignored, and how do we recover?
• Only surface errors to users when they can act on the information.
• Write error messages that include the problem, the cause, and actionable guidance.
• Do not wrap platform exceptions in custom exceptions unless the custom type adds meaningful semantic distinction.
• Throw early (validate preconditions immediately); catch late (handle at the layer with context).
• Transform exceptions at layer boundaries; do not let low-level technical exceptions leak into higher-level layers.
• Log exceptions with their full stack trace at the point of handling, not at every intermediate catch block.
• Budget time for exception handling design—it is frequently as complex as the happy-path logic itself.

Summary

Good exception handling requires the same deliberate design as any other part of the system. The most common failures are showing too many messages to users, wrapping exceptions in meaningless custom types, catching errors too early before enough context is available, and allowing low-level exceptions to leak across architectural boundaries. Addressing these patterns systematically produces software that fails gracefully, gives users actionable information when they need it, and gives developers clean, traceable diagnostics when things go wrong.