Azure Dedicated Host
A complete, plain-English guide to Azure Dedicated Host: what it is, why some organisations rent a whole physical server instead of sharing one, how host groups, placement, licensing, maintenance control, availability and billing work, and how to decide whether it is worth the cost.
Imagine you need a place to live in a big city. Most people rent a flat in a shared apartment building. They share the lifts, the walls, the plumbing and the building’s management, and they never think about it. Now imagine a different need: a bank that wants to keep its most sensitive records in a building where no outsider is ever a neighbour, or a company that owns expensive software licences tied to a specific building and wants to use them there. For these customers, renting a whole private house, with their name alone on the deed, makes sense. Azure Dedicated Host is that private house: an entire physical server in a Microsoft data centre that belongs to you and nobody else, while Microsoft still keeps the building, the power and the plumbing running.
This guide assumes you know nothing about the topic. Every new word is explained when it first appears, with an everyday comparison. By the end you will understand how Dedicated Host differs from ordinary virtual machines, how to organise hosts into groups, how placement and capacity work, how licensing savings arise, how maintenance can be controlled, how to keep workloads available, and how to judge cost honestly.
1First Principles: Shared Hardware and Its Limits
To appreciate a dedicated server, we first need to understand what sharing means in the cloud.
How ordinary cloud machines work
When you create a regular Azure virtual machine, you are not given a physical computer. A virtual machine, often called a VM, is a software-defined computer that runs on a physical server called a host. A special program called a hypervisor divides the physical server into several isolated virtual computers. Azure normally places VMs belonging to many different customers on the same physical host, packing them together efficiently so that hardware never sits idle. This sharing is called multi-tenancy, because many tenants live in the same building.
Think of a large apartment building. Each flat is a virtual machine, the whole building is the physical host, and the residents are different customers. Strong walls and locked doors keep families apart, and the arrangement is cheap because the cost of the building is split many ways.
Is shared hardware safe?
Yes, for the overwhelming majority of workloads. The hypervisor enforces strict isolation, so one customer’s VM cannot read another’s memory or files, and Microsoft invests heavily in protecting against cross-tenant attacks. Most banks, hospitals and governments run on shared cloud infrastructure every day.
Why some customers still want more
A few situations push organisations toward owning the whole server:
Compliance and Policy
Some regulations, contracts or internal policies require that workloads do not share physical hardware with other organisations.
Software Licensing
Certain licences are priced per physical core or per server, so controlling the physical machine can reduce licence cost significantly.
Maintenance Control
Some businesses need to decide when the underlying hardware software is updated, to avoid disruption in critical periods.
Predictable Performance
Having no outside neighbours removes the small chance of another customer’s workload affecting yours.
Dedicated Host exists for specific needs: isolation, licensing and control. It is not a faster or better VM, and for ordinary workloads it is usually unnecessary and more expensive.
2What Azure Dedicated Host Is
A physical server in an Azure data centre, reserved for one customer.
The definition
Azure Dedicated Host is a service that provides physical servers able to host one or more Azure virtual machines, where the server is dedicated to your organisation and your subscription. Workloads on it are isolated at the hardware level, because no other customer’s virtual machines run on the same physical server. The host is the same type of hardware Azure uses everywhere, running in the same data centres, connected to the same network, and managed by Azure for its physical operation.
Who is responsible for what
The split of duties is easy to misunderstand. Microsoft still owns and operates the hardware, the data centre and the hypervisor layer. You choose the host type, decide which VMs run on it, and manage the operating systems and software inside those VMs exactly as you would with ordinary Azure VMs. You do not log in to the host itself, you cannot install your own hypervisor on it, and you do not touch its firmware.
| Layer | Regular Azure VM | Azure Dedicated Host |
|---|---|---|
| Physical server sharing | Shared with other customers | Dedicated to you alone |
| Physical hardware operation | Microsoft | Microsoft |
| Hypervisor and host software | Microsoft | Microsoft |
| Control over host maintenance timing | Limited | Greater control within allowed options |
| Operating system and applications | You | You |
| What you pay for | Each VM | The whole host, whether full or empty |
Renting a dedicated host is like renting a whole floor of a hotel rather than individual rooms. The hotel still provides cleaning, security and electricity. You decide who sleeps in which room and how they are arranged, and nobody outside your group is on the floor.
Dedicated Host is not the same as bare metal or running your own data centre. You still use Azure virtual machines on top, managed through the normal Azure tools. You are renting exclusivity, not unrestricted access to the physical machine.
3Dedicated Host Among Azure’s Isolation Options
Azure offers several ways to reduce sharing. Knowing the ladder prevents over-buying.
Isolation is not an on-off switch. Azure provides a ladder of choices with growing levels of separation, and each rung has a different price and purpose.
| Option | What Is Isolated | Typical Use |
|---|---|---|
| Ordinary VMs | Logical isolation through the hypervisor; hardware is shared | Almost all workloads |
| Confidential VMs | Data in use is encrypted in memory using hardware features, hiding it even from the cloud operator | Highly sensitive data and regulated analytics |
| Azure Dedicated Host | Whole physical server reserved for one customer | Hardware-level isolation, licensing benefit, maintenance control |
| Dedicated or sovereign environments | Entire separate cloud environments with extra governance for specific governments or sectors | Government and special national requirements |
Isolated VM sizes
Azure has also offered special large VM sizes that occupy an entire physical host, so no other customer shares that hardware. These are simpler to buy than a Dedicated Host because they come as a single VM, but they offer less control: you do not manage the host, you cannot place several VMs on it, and the availability of such sizes changes over time. Always check the current documentation before relying on them.
Dedicated Host versus Confidential VMs
These solve different problems and are sometimes confused. Dedicated Host answers the question “who else lives on my hardware?” Confidential VMs answer the question “who can see my data while it is being processed?” Some organisations need one, some need the other, and a few need both.
Dedicated Host is a private house with no neighbours. A confidential VM is a flat where everything inside is sealed in a locked safe, even from the building manager. The first controls who lives near you; the second controls who can peek inside your belongings.
Write down the exact requirement before choosing. “Our auditor needs proof of no co-tenancy” points toward Dedicated Host. “We must keep data encrypted even during processing” points toward confidential computing. The right answer follows the actual requirement, not general anxiety.
4Core Building Blocks: Host Groups and Hosts
Two resources define the whole service. Understanding their relationship is the heart of the topic.
Host
A host is a single physical server. When you create a host, you choose its type, which is a combination of the hardware family and the VM family it supports. A host is created inside a host group, and it provides a fixed pool of processor cores and memory that your VMs consume.
Host group
A host group is a collection of hosts that you manage together. It lives in one region and, optionally, in one availability zone. When you create a virtual machine, you place it on a host group, and sometimes on a specific host inside it. The host group is the unit that controls availability design, such as how many fault domains the hosts spread across.
Subscription
The billing and access boundary under which everything is created.
Host Group
A region-level container for hosts, with settings such as zone and fault domain count.
Dedicated Host
One physical server of a chosen type, providing a fixed amount of capacity.
Virtual Machines
Ordinary Azure VMs placed onto the host group or host, consuming its capacity.
Disks and Networking
Managed disks and virtual network resources attached to the VMs exactly as for any other VM.
flowchart TD
SUB[Subscription] --> HG[Host Group in a Region]
HG --> H1[Dedicated Host 1]
HG --> H2[Dedicated Host 2]
H1 --> V1[VM A]
H1 --> V2[VM B]
H2 --> V3[VM C]
H2 --> V4[VM D]
V1 --> D1[Managed Disks and NICs]
A host group is a hotel wing you have reserved. Each host is one floor in that wing. The virtual machines are the guests staying in rooms on those floors. You pay for the floors you reserved whether the rooms are full or not.
Virtual machines in a host group use the same disks, images and virtual networks as ordinary VMs. Only the placement and billing model changes, which keeps day-to-day management familiar.
5Host Types, VM Families and Capacity
A host is not a generic box. Its type determines which VMs it can run and how many fit.
Host types and VM series
Each Dedicated Host is created from a specific host type, sometimes called a SKU. The type is tied to a VM series, which is a family of VM sizes sharing the same hardware generation, such as a general-purpose series or a memory-optimised series. A host of a given type can run only VM sizes from that series, though it can run any mix of sizes from that series up to the capacity of the host. A host of one series cannot run VMs from a different series.
Capacity as a pool
Every host has a fixed number of physical cores, a fixed amount of memory and, for some hosts, specific licensing-relevant core counts. Each VM placed on the host uses part of that pool, according to the size you choose. When the pool is full, no more VMs can be placed there without adding another host. Capacity is therefore a bit like seats in a bus: you can mix adults and children, but the total cannot exceed the number of seats.
A host is a minibus with, say, sixty seats. A small VM takes one seat; a large VM takes eight. You may fill the bus with any combination that fits, but you cannot seat sixty-one people, and you cannot put a motorbike passenger on a bus designed only for adults.
Choosing the series
General Purpose
Balanced processor and memory for web, application and small database servers.
Memory Optimised
More memory per core for databases and in-memory workloads, important when licences are priced by core.
Compute Optimised
More processing per unit of memory, for processor-hungry tasks.
Specialised
Other families such as storage- or graphics-oriented series, where offered for dedicated hosts in a region.
Newer and older hardware
Azure releases new hardware generations over time and retires old ones. Host types for newer generations usually offer more performance per core, and older types may have a retirement date after which they cannot be renewed. Always confirm availability in your chosen region before designing, because not every host type exists everywhere.
Picking a host type before listing the VM sizes you actually need. If your workload needs sizes from two different series, you will need hosts of two types, which increases cost and fragmentation. Plan the VM sizes first, then choose the host types.
6Regions, Zones and Fault Domains
Location and spreading decisions are made at the host group level, so they deserve early attention.
Regions
A host group lives in one Azure region, such as Central India or West Europe. All its hosts, and the VMs placed on them, are in that region. Choose a region near your users and within any legal boundaries for your data. Not all host types are available in all regions, and some regions have limited capacity for the newest types.
Availability zones
Many regions are divided into availability zones. A zone is one or more data centres with independent power, cooling and networking. You can create a host group in a specific zone, and every host in it will then be in that zone. To protect against a zone failure, you create several host groups, one per zone, and spread your workload across them. A host group is tied to one zone; it does not span zones by itself.
Fault domains
A fault domain is a group of hardware sharing a common power source and network switch, like a single electrical circuit in a building. When creating a host group, you choose how many fault domains to spread its hosts across. Azure then places your hosts in separate fault domains, so a power or switch failure in one affects only some of your hosts rather than all of them. The number of fault domains available depends on the region and whether you use zones.
flowchart TD
R[Region] --> Z1[Zone 1]
R --> Z2[Zone 2]
R --> Z3[Zone 3]
Z1 --> HG1[Host Group Zone 1]
Z2 --> HG2[Host Group Zone 2]
Z3 --> HG3[Host Group Zone 3]
HG1 --> FD1[Fault Domain 0 Host]
HG1 --> FD2[Fault Domain 1 Host]
HG2 --> FD3[Fault Domain 0 Host]
HG2 --> FD4[Fault Domain 1 Host]
A region is a city, zones are neighbourhoods with their own power stations, and fault domains are separate electrical circuits within a building. Spreading your hosts across neighbourhoods and circuits means a single outage cannot switch off everything you own.
Creating one host and calling the design highly available. A single physical server is a single point of failure, no matter how good it is. Real resilience needs at least two hosts in different fault domains, preferably in different zones, with the application itself spread across them.
7Placing VMs: Automatic and Manual Placement
Once hosts exist, the question is which VM goes where.
Two placement styles
Manual placement
When creating a VM, you pick a specific host. You have full control over which VMs share which host, useful when you want tight control, such as keeping a licensed database on a specific host or separating roles on purpose.
Automatic placement
When creating a VM, you choose only the host group. Azure picks a host in the group that has enough free capacity and compatible type. This is simpler and keeps hosts reasonably full without manual bookkeeping, and works well when you have many VMs of varied sizes.
What happens at creation time
Request received
You ask for a VM of a particular size, specifying the host group or a specific host.
Compatibility check
Azure confirms the VM size belongs to the series supported by the host type, and that it matches the VM’s region and zone.
Capacity check
Azure checks that the target host, or at least one host in the group, still has enough free cores and memory.
Placement
The VM is created on the chosen or selected host and starts using its capacity pool.
Failure if full
If no host has room, creation fails with a capacity message. You respond by adding a host or choosing a different size.
Fragmentation
Capacity can become fragmented. Imagine two hosts each with a few free cores left, but a new VM needing more cores than either has free. The total free capacity is enough, but it is split across hosts so the VM cannot be placed. Planning VM sizes so they pack neatly into hosts reduces this waste.
Packing suitcases into car boots. Even if the total empty space across two cars is plenty, a large suitcase will not fit if neither boot has a big enough gap. Careful packing at the start avoids unusable leftover space.
Choose a small set of standard VM sizes that divide evenly into your host’s capacity. Standard sizes make packing predictable, simplify capacity planning and keep wasted cores low.
8Licensing and the Hybrid Benefit
For many customers, licensing is the single biggest reason to use Dedicated Host.
Why licensing is physical
Some enterprise software, notably certain editions of Windows Server and SQL Server, has licensing rules based on physical cores of the server where it runs, rather than on the virtual cores of each VM. If you own such licences, a dedicated physical server lets you count the physical cores once and then run many VMs on that server, with potentially much better value than licensing every VM separately.
Azure Hybrid Benefit
Azure Hybrid Benefit lets customers with eligible licences and active Software Assurance, or qualifying subscription licences, apply them in Azure to reduce costs. On Dedicated Host, the benefit can work at the level of the whole host rather than per VM. Depending on the licence type and agreement, organisations may be able to license all the physical cores of the host and then run an unlimited number of eligible VMs on it, subject to the licensing terms.
Licensing terms are legal contracts, and they change. Eligibility, edition rules, core-counting rules and mobility rights differ by agreement. Before building a business case, confirm the exact terms with Microsoft or your licensing partner. This guide describes the idea, not your entitlement.
A worked idea, without numbers
Suppose you run twenty small SQL Server VMs. Licensing each VM separately could mean paying for a minimum number of cores for every one of the twenty. If, instead, you place all twenty on one dedicated host and license the host’s physical cores once, the licence cost may be far lower, even after you add the cost of renting the host. The saving depends entirely on how densely you can pack VMs and on your agreement.
flowchart LR
A[Many VMs on shared hardware] --> B[Licence each VM separately]
B --> C[Cost grows with every VM]
D[Many VMs on a dedicated host] --> E[Licence physical host cores once]
E --> F[Cost stays flat as VMs are added up to host capacity]
A cinema can sell a ticket to every person individually, or it can pay a flat fee to hire the whole screen for the evening. If you are bringing a large group, the flat fee is cheaper. If you are bringing two friends, individual tickets win.
Software that does not benefit
Not all software is priced by physical core. Open source operating systems and many modern applications are priced by subscription or by VM, and gain nothing from physical host licensing. Check each product’s licensing model before assuming that a dedicated host will save money.
Include your licensing or procurement team in planning from day one. A host that is perfectly designed technically can still lose its business case if the licence terms do not match the way you intend to use it.
9Maintenance Control
Even private houses need repairs. Dedicated Host lets you have a say in the timing.
Why hosts need maintenance
Physical servers need regular updates to their firmware, hypervisor and related software, for security and reliability. On shared hardware, Azure schedules this work itself and tries to make it invisible using techniques such as memory-preserving updates, which pause a VM for a few seconds without restarting it, and live migration, which moves a running VM to another host. Occasionally a restart is required.
Control on a dedicated host
Because the host belongs to you alone, Azure can offer more control over when maintenance is applied. Using maintenance configurations, you can define a window in which platform updates may be applied, and the updates for your hosts can be held back until then, within limits set by Azure. Critical security updates may still be applied with limited notice, so control is not unlimited.
Default Platform Behaviour
Azure applies updates on its normal schedule using its least-disruptive techniques. Simplest, least control.
Maintenance Window
You define a recurring window, such as quiet hours on weekends, in which platform updates are applied to your hosts.
Deferral Within Limits
Updates can be held back for a limited period, for example to avoid a busy business season, before they must be applied.
Preparing for maintenance
Define the window
Agree with business owners on the quiet times that suit each group of hosts.
Stagger the hosts
Give different hosts different windows so that the whole estate is never updated at the same moment.
Design redundancy
Run applications across multiple hosts so one host being updated does not cause an outage.
Watch notifications
Subscribe to service health and maintenance notices so that planned events are never a surprise.
A hotel that rents you a whole floor can agree to schedule lift repairs and carpet cleaning on days when your guests are away. It cannot, however, postpone an urgent fire-safety repair indefinitely.
Maintenance control does not mean maintenance can be avoided. Delaying updates increases exposure to known problems, so the sensible goal is to choose a convenient time, not to postpone indefinitely.
10Availability and Failure Handling
A dedicated server can still break. Good design assumes it will.
What happens when a host fails
Physical servers occasionally suffer hardware failures. When a host becomes unhealthy, Azure’s platform works to recover the VMs running on it by restarting them on healthy hardware, a process often called service healing. With Dedicated Host, the recovery behaviour is tied to the host group’s capacity, so it is wise to understand current documentation for how replacement hosts are provided and billed. The key practical point is that a host failure causes an interruption, and the VMs on it will restart rather than continue seamlessly.
Spare capacity as insurance
Because you rent whole servers, your own spare capacity is what makes recovery fast. If every host is packed completely full, a failure leaves nowhere for displaced workloads to go until replacement capacity is arranged. Many designs keep deliberate headroom, sometimes called an N+1 design, meaning enough hosts to carry the full workload even if one is lost.
| Design | Hosts Used | Protection | Cost Impact |
|---|---|---|---|
| Single host | 1 | None against host failure | Lowest |
| Two hosts, different fault domains | 2 | Survives one host failure if each can carry the load | Roughly double |
| Hosts in several zones | 2 or more per zone, across zones | Survives a zone failure | Higher still |
| Hosts in two regions | Per region | Survives regional disaster | Highest |
flowchart TD
U[Users] --> LB[Load Balancer]
LB --> HA[Host A Fault Domain 0]
LB --> HB[Host B Fault Domain 1]
HA --> AV1[App VM 1]
HA --> DB1[Database VM primary]
HB --> AV2[App VM 2]
HB --> DB2[Database VM secondary]
DB1 |replication| DB2
Application-level redundancy
Hosts provide places to run VMs; they do not make your application resilient on their own. For real availability, run several instances of each tier on different hosts and replicate data between them. Use load balancers to route around failed instances. Without this, two hosts merely mean two single points of failure.
Owning two houses does not protect your family unless you can actually live in either one. Beds must be made, food stocked and the family able to move quickly between them. Spare capacity and readiness are what make a second house useful.
Test failure deliberately. Practise stopping a VM, removing a host from a load balancer and recovering the application. The first time you discover how your system behaves during failure should not be during a real incident.
11Pricing and Cost Model
The billing model is the most important difference from regular VMs. Understanding it avoids nasty surprises.
You pay for the host, not the VMs
With ordinary VMs, you pay for each virtual machine you run. With Dedicated Host, you pay for the whole physical host for every hour it exists in your subscription, regardless of how many VMs are on it, and even if there are none. The VMs that run on the host do not incur separate compute charges, because you have already paid for the host’s capacity. You still pay for other resources such as disks, networking and any software licences not covered by your own agreements.
Utilisation decides value
Because the host bill is fixed, how full you keep the host determines your effective cost per VM. A host that is eighty percent full gives much better value than one that is twenty percent full. Dedicated Host rewards workloads that are steady, predictable and densely packed, and punishes those that are small, sparse or uncertain.
Chartering a whole bus costs the same whether it carries ten passengers or sixty. If you can fill it, the price per person is tiny. If you carry only ten, individual taxi fares would have been cheaper.
Ways to reduce cost
Reservations
Commit to a host type in a region for one or three years in exchange for a significant discount over pay-as-you-go pricing. Best for hosts you are sure you will keep.
Hybrid Benefit
Apply eligible existing licences to cut software costs, subject to your agreements.
High Density
Pack VMs well and avoid leaving hosts mostly empty.
Remove Unused Hosts
Delete hosts you no longer need, since empty hosts still bill every hour.
Stopping or deallocating all the VMs on a host and assuming the cost stops. The host itself continues to bill until it is deleted. Only removing the host ends its charge.
Sketching a business case
A fair comparison asks three questions. What would the same VMs cost on shared hardware? What does the dedicated host cost, including reservations? What licensing difference arises from each approach? The answer varies enormously by workload, and Microsoft’s pricing calculator and your agreement terms should be used with real numbers. Exact prices change and differ by region, so this guide does not quote figures.
| Situation | Likely Better Fit | Reason |
|---|---|---|
| Compliance requires no shared hardware | Dedicated Host | Isolation is the requirement; cost is secondary |
| Many licensed VMs that pack densely | Dedicated Host | Physical-core licensing can reduce total cost |
| A handful of small VMs | Regular VMs | The host would be mostly empty and costly per VM |
| Highly unpredictable or short-lived workloads | Regular VMs | Fixed hourly host cost is wasteful when demand varies |
12Networking, Storage and Everything Else Stays Familiar
Apart from placement and billing, VMs on dedicated hosts behave like any other Azure VMs.
Networking
VMs on a dedicated host connect to virtual networks, subnets, network security groups, load balancers and gateways exactly as ordinary VMs do. They can be members of the same virtual network as non-dedicated VMs, and they can communicate privately with them. The host itself is not a networking object; only the VMs are.
Storage
Disks are managed disks, the same as for regular VMs, with the usual types from standard to premium and ultra options, subject to the VM series support. Disks are not stored on the physical host, so they remain independent of host health. This means that if a VM must restart elsewhere, its disks follow it.
Images, extensions and automation
VM images, extensions, backup, monitoring agents and automation tools all work as usual. This continuity is one of the attractions of Dedicated Host: teams use the skills and tools they already have, rather than learning a new platform.
What stays the same
Virtual networks, disks, images, backup, monitoring, role-based access control, policy, tags and deployment templates.
What changes
Where VMs are placed, how compute is billed, what maintenance options exist, and the extra capacity planning you must do.
What is restricted
Some VM features or sizes may not be supported on dedicated hosts, such as certain scale or resizing behaviours. Always check the current support list for your intended design.
Assuming every VM feature works the same on a dedicated host. Resizing across series, certain scale-out features and some specialised sizes have restrictions. Verify the specific features you rely on before committing.
Living in a private house instead of a flat does not change how you use the internet, the post or the road outside. What changes is who owns the walls and who pays for the empty rooms.
13Resizing, Moving and Changing Hosts
Hosts are fixed physical servers, which limits how freely things can be moved around.
Hosts cannot be resized
A host has a fixed capacity determined by its type. You cannot make it bigger or change its series. If you need more capacity, you add another host. If you need a different series, you create a host of that type. Planning capacity in whole-host steps is therefore a core part of the job.
Resizing VMs
A VM can often be resized within the same series as long as the host has room for the new size. If the host does not have enough free capacity, you must move the VM to another host in the host group, which usually requires deallocating it first. Changing to a size from a different series generally means moving to a host of a different type.
Moving VMs between hosts
Confirm the target has space
Check that the destination host is of the right type and has enough free cores and memory.
Plan downtime
Moving generally requires stopping and deallocating the VM, so schedule it in a suitable window.
Move and restart
Reassign the VM to the new host or host group and start it again.
Verify
Check the application, monitoring and licensing records to confirm everything is healthy.
Moves are easier when applications are designed to run in several instances. You can drain one instance, move it, bring it back and repeat, with no user-visible downtime.
Changing hosts is like moving furniture between houses. You cannot enlarge the house, so you either rearrange rooms inside it or carry the furniture to a different house. Both take planning and some effort.
14Security and Compliance
Hardware isolation is one layer of security, not the whole story.
What dedicated hardware does and does not give you
A dedicated host removes the possibility of another customer’s VM sharing your physical server. This can satisfy auditors and policies that require physical separation and may reduce the theoretical risk of attacks that exploit shared hardware. It does not protect you from weak passwords, unpatched software, open network ports, over-privileged accounts or leaked secrets inside your own VMs. The shared responsibility model still applies in full.
Hardware Isolation
Provided by Dedicated Host: no other customers on your physical server.
Identity and Access
Role-based access control, multi-factor sign-in, least privilege and managed identities.
Network
Private subnets, tight security group rules, no unnecessary public exposure.
Data
Disk encryption, customer-managed keys where required, and encryption in transit.
Operating System
Patching, hardening, endpoint protection and removal of unneeded services.
Monitoring
Central logging, threat detection and alerting so attacks are noticed quickly.
Compliance evidence
Auditors often ask for evidence. Azure resource properties show which host a VM runs on, and tags and policy can document the purpose of each host. Azure also publishes compliance documentation for its platform. Keep a record linking each regulated workload to its host group, so you can show an auditor exactly where it runs.
Governance
Azure Policy can restrict who may create hosts, in which regions and of which types, and can require tags such as cost centre and owner. Because hosts are expensive, it is common to limit the right to create them to a small trusted group, and to alert on any new host creation.
Problem
A team treats Dedicated Host as a complete security solution and relaxes other controls such as patching and network rules.
Why It’s Harmful
Most real breaches come from weak configuration, stolen credentials and unpatched software, none of which hardware isolation prevents. The false confidence leaves the real doors open.
Correct Approach
Treat hardware isolation as one layer among many. Maintain the same identity, network, patching and monitoring discipline as on any other platform.
15Monitoring and Capacity Management
Since you pay for the host whether used or not, watching utilisation is how you protect your budget.
What to watch
Allocated capacity
How many of the host’s cores and how much memory are assigned to VMs. This shows how full each host is and how much room remains for new VMs.
Actual utilisation
How busy the VMs really are. A host fully allocated but with idle VMs may mean oversized VMs; a host with spare allocation but busy VMs may mean you are close to real performance limits.
Host health and availability
Whether the host is healthy and whether any events, such as planned maintenance or failures, affect it. Resource health and service health notices provide this.
VM availability
Whether VMs are running, and how often they restart, which can reveal host issues early.
Tools
Azure Monitor collects metrics from the platform, and agents inside the VMs collect operating system and application data into Log Analytics. Dashboards can show host fill levels, and alerts can warn when capacity is nearly exhausted so you can order another host before a VM creation fails. Cost management views can attribute host charges to owners through tags.
A capacity routine
Record the baseline
Note allocated cores and memory per host, and the growth rate of new VMs.
Set thresholds
Alert at a level such as seventy or eighty percent allocated, leaving time to add a host.
Review monthly
Look for hosts that are barely used and workloads that could be consolidated.
Plan reservations
Once usage is stable, convert steady hosts to reservations to reduce cost.
Remember the lead time. New hosts depend on regional capacity, so ordering one when the last one is full may mean waiting. Reviewing capacity regularly avoids emergency purchases.
Measuring only allocation and never real usage. VMs sized generously “just in case” waste host capacity. Right-sizing VMs lets the same host carry more workloads and delays the need for additional hosts.
16Automation, Deployment and Governance
Because hosts are costly and long-lived, they should be created deliberately and described in files, not clicked into existence.
Ways to create resources
Host groups, hosts and the VMs on them can be created through the Azure portal, command-line tools, programming libraries and declarative templates such as Bicep and ARM, or through tools like Terraform. The principle is more important than the tool: describe the desired infrastructure in files that are reviewed, versioned and repeatable.
Advantages of Automating
- Every host and host group is documented in a reviewable file.
- Environments can be rebuilt identically after an incident or for testing.
- Policy checks can block unapproved hosts before they cost money.
- History shows who changed what and when.
- Consistent tags make cost attribution reliable.
Disadvantages / Trade-offs
- There is an upfront effort to design and test templates.
- A template mistake can create expensive hosts at scale.
- Manual emergency changes can drift from the stored definition.
Guardrails for cost
Restricted Creation
Allow only a small, trusted group to create hosts, using role-based access control.
Mandatory Tags
Require owner, project and cost centre tags so every host has a responsible person.
Budget Alerts
Set spending alerts so unexpected host charges are noticed within days, not at month end.
Resource Locks
Protect critical hosts from accidental deletion, since removing a host that still holds VMs would be disruptive.
flowchart LR
A[Capacity request] --> B[Review and approve]
B --> C[Template creates host group and hosts]
C --> D[Policy checks tags and region]
D --> E[VMs placed with standard sizes]
E --> F[Monitor utilisation]
F --> G{Under or over used?}
G -->|Over| H[Request more capacity]
G -->|Under| I[Consolidate and remove hosts]
H --> A
Treat each host like a significant purchase, because it is one. A short approval step before creating a host, with a stated purpose and expected utilisation, prevents most costly mistakes.
17Dedicated Host with Other Azure Services
Real systems combine several services. Knowing how Dedicated Host fits keeps designs coherent.
Virtual Machine Scale Sets
Scale sets can be used with dedicated host groups in some configurations, allowing groups of similar VMs to be managed together. Support depends on orchestration mode and features, so check current documentation before relying on it.
Backup and Site Recovery
VMs on dedicated hosts can be backed up and replicated like other VMs. For regional disaster recovery, a second host group in another region provides places to start the replicated VMs.
Azure Migrate
Migration tools can help assess on-premises servers and plan how many hosts of which type are needed, particularly useful when moving licence-heavy estates to Azure.
Load balancers and gateways
VMs on hosts sit behind the usual Azure load balancing and gateway services, so existing network designs carry over.
Monitoring and security services
Azure Monitor, Defender for Cloud and Update Manager work with VMs on dedicated hosts the same way as with other VMs.
What not to expect
Platform-as-a-service offerings, such as managed databases and web app platforms, run on their own infrastructure and are not placed on your dedicated hosts. Dedicated Host is for infrastructure-level virtual machines. If you want isolation for a managed service, look for isolation options specific to that service.
Your private house sits in the same city as everyone else. The roads, the postal service and the water supply are all the same city services. Only your front door and your name on the deeds are different.
Believing that all Azure services can be placed on dedicated hosts. Only virtual machines use Dedicated Host. Other services have their own models and sometimes their own isolation or dedicated-capacity options.
18Advantages, Limitations and Trade-offs
An honest view of both sides leads to better decisions.
Advantages
- Hardware-level isolation: no other customer shares your physical server.
- Potentially large licence savings for software priced by physical cores.
- Greater control over when host maintenance is applied.
- Visibility and control over which VMs share which physical server.
- Familiar tooling: VMs, disks and networks behave as in normal Azure.
- Helps meet regulatory or contractual requirements for non-shared hardware.
Disadvantages / Trade-offs
- You pay for the whole host, even when it is empty or lightly used.
- Capacity planning becomes your responsibility, including spare capacity for failures.
- Hosts have fixed size and series; they cannot be resized.
- Some VM features and sizes may be restricted on dedicated hosts.
- Availability needs deliberate design with multiple hosts across fault domains and zones.
- Business value depends on licences and density, which require careful analysis.
When it is the right tool
Dedicated Host fits best when a clear requirement exists: a regulation or contract demanding physical isolation, a licence estate whose cost falls with physical-core licensing, a need to schedule maintenance around critical business periods, or a combination of these. It also suits steady workloads large enough to fill hosts efficiently.
When it is not
Avoid it when workloads are small, short-lived or unpredictable, when no isolation or licensing requirement exists, or when the team cannot commit to the capacity planning it demands. In those cases, ordinary VMs, perhaps with confidential computing or isolated sizes where needed, give better value.
19Real-World Scenarios
Patterns become clear when you see them applied. These are typical industry uses, described generally.
Financial services with regulatory isolation
A financial firm’s regulator expects sensitive trading and customer systems to avoid shared physical servers. The firm creates host groups in two zones, spreads database and application VMs across fault domains, applies strict access controls and keeps evidence linking each system to its host group for auditors.
Licence-heavy enterprise migration
A company with many Windows Server and SQL Server VMs and existing eligible licences moves them to Azure. By packing them densely onto dedicated hosts and applying its licences to the physical cores, it lowers total cost compared with licensing each VM separately, after confirming terms with its licensing partner.
Healthcare with contractual requirements
A hospital group is bound by a contract that forbids co-tenancy for patient record systems. It uses dedicated hosts for those systems and ordinary VMs for everything else, keeping cost in check while meeting the clause.
Seasonal business needing maintenance control
A retailer cannot tolerate any platform maintenance during its peak shopping weeks. It sets maintenance windows well outside the peak and staggers host updates so only a fraction of capacity is touched at once.
Software vendor hosting for customers
A software company hosts a separate environment for each large customer and offers isolated hardware as a premium feature. Each customer’s workloads run on their own host group, with tags used to allocate cost.
When it did not pay off
A small team rented a host for a dozen small VMs because “dedicated sounded safer”, and used a quarter of its capacity. After analysis, they moved the workloads back to ordinary VMs and saved money, with no loss of security that mattered to them.
20A Reference Architecture Walkthrough
Let us combine the ideas into one sensible design for a regulated business application.
Imagine an application with a web tier, an application tier and a licensed database tier. The goals are hardware isolation, resilience to a data centre failure, controlled maintenance, safe administration and controlled cost.
flowchart TD
USER[Users] --> GW[Application Gateway with web firewall]
GW --> WEB1[Web VMs on Host Group Zone 1]
GW --> WEB2[Web VMs on Host Group Zone 2]
WEB1 --> APP1[App VMs Zone 1]
WEB2 --> APP2[App VMs Zone 2]
APP1 --> DB1[(Licensed Database VM primary Zone 1)]
APP2 --> DB2[(Licensed Database VM secondary Zone 2)]
DB1 |replication| DB2
ADMIN[Administrators] --> BAS[Azure Bastion]
BAS -.private access.-> WEB1
BAS -.private access.-> APP1
MON[Azure Monitor and Log Analytics] -.collects.-> DB1
MON -.collects.-> DB2
BKP[Backup vault] -.protects.-> DB1
Walking through the design
Two host groups, two zones
Each zone has its own host group, with hosts spread across fault domains. A zone failure leaves the other zone running.
Standard VM sizes
A small set of agreed sizes packs neatly into hosts, minimising fragmentation and leftover capacity.
Licensed tier on dedicated cores
The database VMs share hosts whose physical cores are covered by the organisation’s licences, subject to confirmed terms.
Staggered maintenance
Hosts in different zones have different maintenance windows, so only part of the capacity is touched at once.
Protected administration and monitoring
Engineers use Bastion with multi-factor sign-in; metrics and logs flow to central workspaces with alerts on capacity and health.
Why this works
Each requirement has a specific answer. Isolation comes from dedicated hardware, resilience from zones and fault domains, licence efficiency from dense physical-core licensing, maintenance control from staggered windows, and cost discipline from reservations on steady hosts, tags and utilisation reviews.
21Best Practices and Common Mistakes
Habits that separate efficient dedicated host estates from expensive, underused ones.
Start with the requirement
Name the isolation, licence or maintenance need before buying any host.
Standardise VM sizes
Use a few sizes that pack well into hosts to limit wasted capacity.
Design for failure
Use multiple hosts across fault domains and zones, with spare capacity and tested recovery.
Involve licensing early
Confirm entitlements before relying on licence savings in the business case.
Reserve steady capacity
Use reservations on hosts you are confident will stay in use.
Monitor utilisation
Track allocation and real usage, and consolidate when hosts are underused.
Automate and govern
Use templates, policy, tags, locks and budgets to control creation and cost.
Keep other security layers
Hardware isolation does not replace patching, identity controls and network rules.
Common mistakes at a glance
| Mistake | Consequence | Better Habit |
|---|---|---|
| Buying hosts without a clear requirement | Paying for exclusivity that nobody needs | Document the isolation or licensing need first |
| One host for production | Single point of failure | At least two hosts in different fault domains or zones |
| Leaving hosts mostly empty | High effective cost per VM | Pack densely and consolidate |
| Deallocating VMs to save money | Host still bills fully | Delete hosts that are not needed |
| Mixed odd VM sizes | Fragmented, unusable capacity | Standard sizes that divide evenly |
| Assuming licence savings | Business case collapses | Confirm terms with Microsoft or a licensing partner |
| No capacity alerts | Failed VM creation when hosts are full | Alert at a threshold and plan lead time |
Problem
An organisation puts every workload, including small development machines, on dedicated hosts because “dedicated is more secure”.
Why It’s Harmful
Most workloads have no requirement for physical isolation. The organisation pays heavily for empty capacity and adds complexity without meaningful risk reduction.
Correct Approach
Classify workloads by actual requirement. Use dedicated hosts only for those that need them, and run the rest on ordinary VMs or managed services.
Problem
Hosts are filled to the last core with no spare capacity, and no one monitors how full they are.
Why It’s Harmful
A host failure or a growth spike leaves nowhere to place VMs. Emergency purchases take time, and the application is down or degraded while waiting.
Correct Approach
Keep deliberate headroom, alert on allocation thresholds and review capacity regularly so new hosts are added before they are needed.
22Frequently Asked Questions
No. You still run ordinary Azure virtual machines on top of a Microsoft-managed hypervisor. You do not log in to the host or install your own virtualisation software. You gain exclusivity of the physical server, not unrestricted access to it.
You pay for the host, not for the VM compute separately. You still pay for disks, networking and any software licences not covered by your own agreements.
Yes. A host bills for every hour it exists, whether it contains VMs or not. Deleting the host is the only way to stop its charge.
A host is one physical server. A host group is a container for hosts, living in one region and optionally one zone, where you set availability choices such as fault domain count.
No. A host is tied to one VM series and can run only sizes from that series. A host group may contain hosts of different types to support different series.
No. Hosts have fixed capacity. You add more hosts for more capacity or create hosts of a different type for a different series.
Use multiple hosts across fault domains and, ideally, host groups in several zones. Run several instances of each application tier, replicate data and keep spare capacity so workloads can restart if a host fails.
You can configure maintenance windows and, within limits, defer platform updates for your hosts. Critical security updates may still be applied on short notice, so control is bounded.
It can, for software licensed by physical cores, when you have eligible licences and pack VMs densely. Eligibility and terms vary, so confirm with Microsoft or your licensing partner before depending on the saving.
It adds hardware-level isolation, which some policies require. It does not replace good patching, identity management, network controls or monitoring, and ordinary Azure VMs are also strongly isolated and widely used for sensitive workloads.
Dedicated Host controls who shares your physical server. Confidential VMs protect data while it is being processed by encrypting memory with hardware features. They address different risks.
The VMs on it are interrupted and are recovered on healthy hardware by the platform, so expect a restart rather than seamless continuity. Check current documentation for how replacement is provided, and design with redundancy and spare capacity.
No. Dedicated Host is for virtual machines. Managed platform services use their own infrastructure and have their own isolation options.
If a host will clearly stay in use for a year or more, a reservation can lower its cost significantly. Avoid committing until usage is stable, since reservations are a commitment.
Ask whether a regulation, contract or licensing rule requires or rewards exclusive physical servers, or whether you must control maintenance timing. If none applies, ordinary VMs are almost always the better value.
23Summary and Key Takeaways
Azure Dedicated Host lets an organisation rent an entire physical server in an Azure data centre, so that its virtual machines share hardware with nobody else. Microsoft still operates the hardware and hypervisor, while you organise hosts into host groups, place VMs on them and manage everything inside the VMs as usual. The service answers three needs: isolation that satisfies strict policies, licensing efficiency for software priced by physical cores, and greater control over maintenance timing. In exchange, you pay for the host whether it is full or empty, take on capacity planning and availability design, and accept fixed host sizes and some feature restrictions. Used where a real requirement exists, with dense packing, redundancy and good governance, it is a precise tool. Used simply because dedicated sounds safer, it is an expensive habit.
Key Takeaways
- It is a whole physical server for you alone — Microsoft runs the hardware and hypervisor; you run the VMs and everything inside them.
- Host groups organise hosts — a host group lives in a region and optionally a zone, and its fault domain setting spreads hosts across separate power and network failure points.
- Host type decides what runs — each host supports one VM series and has fixed capacity, so plan standard VM sizes that pack neatly.
- You pay for the host, not the VMs — an empty host still bills every hour, so utilisation determines your real cost per VM.
- Licensing can justify it — physical-core licensing may reduce costs for dense licensed workloads, but terms must be confirmed with Microsoft or your licensing partner.
- Design for failure yourself — use multiple hosts, several fault domains and zones, redundant application tiers and spare capacity.
- Isolation is one layer, not the whole — keep patching, identity, network and monitoring discipline, and use Dedicated Host only when a clear requirement demands it.