Start with the one-sentence idea, then build up the picture slowly.

Azure Dedicated Host is a service from Microsoft that gives you an entire physical server in an Azure data centre. Nobody else is allowed to run their virtual machines on that server. The machine is yours alone, and you decide which of your own virtual machines will live on it. Microsoft still owns the building, the power, the cooling, the network cables, and the physical hardware. You simply get exclusive use of one or more servers.

Let us define a few words before going on. A physical server is a real computer, a heavy metal box with processors, memory, and disks, that sits in a rack inside a data centre. A virtual machine, or VM, is a pretend computer created by software. One physical server can run many VMs at the same time, and each VM behaves as if it were a separate computer with its own operating system. The software that creates and manages these pretend computers is called a hypervisor.

In ordinary Azure, when you create a VM, Azure quietly chooses a server for it. That server may also run VMs that belong to other customers. This is called multi-tenancy, which simply means many customers, called tenants, share the same hardware. Strong software walls keep the tenants apart, and this model is safe for the vast majority of workloads. Dedicated Host is for the smaller group of cases where “safe software walls” are not enough, and the customer wants the physical box to be theirs alone.

It is important to notice what Dedicated Host is not. It is not a way of buying a server and shipping it to your own office. It is not a different cloud. Your VMs are still normal Azure VMs, managed with the same portal, the same command-line tools, and the same networking. The only change is a single extra setting that says “put this VM on my host”. Everything else you already know about Azure still applies.

To understand why a dedicated server matters, first see why sharing is the default.

Cloud providers make money and save energy by packing many customers onto the same machines. A single modern server can have dozens of processor cores and hundreds of gigabytes of memory. Very few workloads use all of that power all of the time. If every customer got a whole server, most of the servers would sit nearly idle, and prices would be far higher. By slicing each server into many VMs and handing the slices to different customers, the provider keeps the hardware busy and passes the savings on to you.

The hypervisor is the referee in this arrangement. It gives each VM a fair share of processor time and memory, and it prevents one VM from peeking at another VM’s data. The hypervisor in Azure is built and hardened by Microsoft and is one of the most heavily tested pieces of software in the cloud. Millions of VMs run on it every day, and for most customers the isolation it provides is entirely sufficient.

The noisy neighbour problem

Even with a good referee, shared hardware has a side effect people call the noisy neighbour problem. If another tenant suddenly runs a very heavy job, it can use a lot of shared resources such as memory bandwidth or disk traffic, and your VM might slow down a little. Azure works hard to limit this, and in practice it is rare. Still, a team running a trading system or a real-time game server may feel uneasy about any shared resource at all.

Why not just buy servers?

Some organisations answer the sharing worry by buying their own servers and running them on premises, which means inside buildings they control. That gives full ownership, but it brings a long list of chores: buying hardware months in advance, installing it, replacing broken parts, paying for power and cooling, and planning for disasters. Azure Dedicated Host sits in the middle. You get the exclusive hardware of the on-premises world with the faster, pay-as-you-go style of the cloud world.

Every service exists because somebody had a painful problem. Here are the main ones.

Compliance and policy

A compliance rule is a requirement from a law, a regulator, or a customer contract. Banks, health organisations, and public agencies often work under such rules. Many of these rules do not actually forbid shared cloud hardware, but the organisation’s own security team may still want a physical boundary because it is easy to explain to auditors. An auditor is a person who checks whether a company follows its rules. Saying “this server runs only our workloads” is a very simple sentence to defend in an audit room.

Licensing

A software license is the legal permission to use a program. Some enterprise software, especially older database and operating system products, charges by counting processor cores on the physical machine. In a shared cloud you cannot point at one physical server and say “this is mine”, so counting becomes confusing. With a Dedicated Host, the physical server is clearly yours, so the counting is clear. Microsoft also offers special benefits that let eligible customers bring existing Windows Server and SQL Server licenses and use them more efficiently on a Dedicated Host. We will return to this in the cost chapter.

Control over maintenance

Azure servers need regular updates, just like your phone does. On shared servers Microsoft picks the timing and uses clever techniques to keep VMs running with only tiny pauses. On a Dedicated Host you get extra tools to schedule when these updates happen, within limits Microsoft defines. A retail company, for example, may want to avoid updates during a big sale weekend.

Five building blocks. Learn these and the rest of the service becomes easy to follow.

The dedicated host

A dedicated host is the Azure resource that represents one physical server. When you create it, you choose its SKU, a word that means “the exact product variety”. The SKU combines two things: the VM family the host supports, and the hardware generation of the server. For example, one SKU might support a general-purpose VM family on one processor generation, while another supports a memory-heavy family. You choose the SKU based on the VMs you plan to run.

The host group

A host group is a container that holds one or more dedicated hosts. You create the group first, and then you create hosts inside it. The group decides where the hosts live: in which Azure region, and optionally in which availability zone. It also decides how many fault domains the hosts are spread across and whether automatic placement is turned on.

Fault domains

A fault domain is a set of hardware that can fail together, such as servers sharing one rack, one power feed, or one network switch. If you place two hosts in different fault domains, a single rack problem will not take both down. The host group lets you choose how many fault domains you want, up to the number the region supports.

Availability zones

An availability zone is a separate data centre building, or group of buildings, inside one Azure region, with independent power, cooling, and networking. A host group can be pinned to one zone. To survive the loss of a whole zone, you create one host group per zone and spread your application across them.

Virtual machines on the host

The VMs you place on a host are standard Azure VMs. The key rule is that all VMs on a given host must come from the VM family that the host SKU supports. Within that family you can mix sizes, for example a small VM and a large VM, as long as the total fits inside the host’s capacity.

How the pieces fit together, from your subscription down to a single VM.

Look at the diagram below from top to bottom. At the top is your Azure subscription, which is your billing and access boundary. Inside it you create host groups. Each host group can be tied to a zone, and inside the group the hosts are spread over fault domains. Finally, VMs sit on the hosts. This is a strict tree: a VM sits on exactly one host, a host belongs to exactly one group, and a group lives in exactly one region.

flowchart TD
    SUB["Azure Subscription"] --> HG1["Host Group A - Zone 1"]
    SUB --> HG2["Host Group B - Zone 2"]
    HG1 --> FD0["Fault Domain 0"]
    HG1 --> FD1["Fault Domain 1"]
    FD0 --> H1["Dedicated Host 1"]
    FD1 --> H2["Dedicated Host 2"]
    H1 --> VM1["VM 1 - small"]
    H1 --> VM2["VM 2 - large"]
    H2 --> VM3["VM 3 - small"]
    HG2 --> FD2["Fault Domain 0"]
    FD2 --> H3["Dedicated Host 3"]
    H3 --> VM4["VM 4 - medium"]

What Microsoft manages and what you manage

This split is the heart of the service. Microsoft manages the physical building, the power, the cooling, the network, the server hardware, the host operating system, and the hypervisor. You manage the host resource itself, meaning when it is created and deleted, how many you have, and what size and family they are. You also manage everything inside your VMs, such as the guest operating system, applications, and data. This is a shared responsibility model, and Dedicated Host moves the line a little toward you compared with regular VMs, because you now also own capacity planning.

Networking and storage

Dedicated Host changes nothing about networking and storage design. Your VMs attach to normal virtual networks, use normal network security groups, and use normal Azure managed disks. The disks are not physically stored inside the host server. They live in Azure storage and are attached over the network, as they are for any VM. So the “dedicated” part applies to the compute hardware, meaning processors and memory, not to the storage service behind the disks.

What happens between “I want a VM on my host” and “the VM is running”.

Every host has a fixed amount of capacity, measured in virtual processors, usually called vCPUs. A vCPU is a slice of processor power that a VM can use. The host SKU tells you how many vCPUs of each supported VM size the server can hold. When you ask for a new VM on a host, Azure checks the host’s remaining capacity. If the new VM fits, it is created. If it does not fit, the request fails with a clear error instead of squeezing the VM in.

No overprovisioning

Overprovisioning means promising more resources than physically exist, hoping not everyone asks at the same time. Regular shared servers can do careful forms of this. A Dedicated Host does not. The vCPUs you place on it must fit within the real capacity. This is a feature, not a flaw: it is exactly why performance is predictable. It also means you can never “borrow” a little extra from the host when it is full.

Placement: manual or automatic

When you create a VM, you point it at either a specific host or at a host group. If you point at a host, the VM goes there or fails. If you point at a host group that has automatic placement turned on, Azure searches the hosts in the group and picks one with enough room. Automatic placement is convenient because you do not have to track free space yourself. Manual placement is useful when you want certain VMs to be together, for example because they share a license.

flowchart TD
    R["VM create request that targets a host group"] --> Q{"Automatic placement on?"}
    Q -->|"Yes"| S["Azure picks a host with free capacity"]
    Q -->|"No"| T["You must name the exact host"]
    S --> U{"Is there room for this VM size?"}
    T --> U
    U -->|"Yes"| V["VM is created and starts on the host"]
    U -->|"No"| W["Request fails - add a host or choose another"]

Moving VMs

A VM is tied to its host while it runs. To move a VM to a different host, you generally stop and deallocate it, change its host setting, and start it again. Deallocate means the VM is stopped and Azure releases its compute resources, so it stops using the host’s capacity. Because the move needs a stop, plan such changes for quiet periods.

Host resizing

You cannot stretch a host into a bigger or different one. If you outgrow a host, you create a new host with the SKU you want, move your VMs across, and delete the old one. This is why careful sizing at the start saves a lot of effort later, which we cover in Chapter 9.

The life of a dedicated host, from planning to retirement.

A dedicated host has a lifecycle, which is simply the series of stages it goes through from birth to end. Knowing these stages helps you avoid surprises, especially with billing. The most important thing to remember is that the host starts costing money the moment it is created and keeps costing money until you delete it, whether or not any VM is running on it.

flowchart LR
    A["Plan capacity"] --> B["Create host group"]
    B --> C["Create dedicated host"]
    C --> D["Deploy VMs onto host"]
    D --> E["Operate and monitor"]
    E --> F{"Capacity needs changed?"}
    F -->|"Need more"| C
    F -->|"Need less"| G["Move or delete VMs"]
    G --> H["Delete empty host"]

The data path of a request

When a user visits your website running on a VM on a Dedicated Host, the path of the data is the same as for any Azure VM. The request arrives at a public address or a load balancer, flows through your virtual network and its security rules, and reaches the VM. The VM reads its disk over Azure’s internal storage network and sends the reply back. The host is invisible in this path. Its only job is to supply processor and memory to the VM, which is why moving to a Dedicated Host usually requires no application changes.

A single server will eventually fail. Good design expects that and plans for it.

Availability means the share of time your application is up and usable. Reliability means it keeps doing the right thing even when parts break. With regular VMs, Azure gives you tools such as availability sets and scale sets to spread VMs across different hardware. With a Dedicated Host, you are the one who must make sure your VMs are not all sitting on one physical server, because there is only one server per host. If that server fails and all your VMs are on it, your whole application goes down together.

Spread across hosts and fault domains

The first rule is to use more than one host. The second rule is to place those hosts in different fault domains, so one rack problem cannot hit them all. Put your VM replicas on different hosts. For example, a pair of web servers should sit on two different hosts, not on the same one.

Spread across zones

For stronger protection, build one host group in each availability zone and run copies of your application in each. A load balancer in front sends traffic to whichever zone is healthy. If one whole zone has a problem, the other keeps serving users.

flowchart TD
    U["Users"] --> LB["Zone-redundant load balancer"]
    LB --> W1["Web VMs on Host Group in Zone 1"]
    LB --> W2["Web VMs on Host Group in Zone 2"]
    W1 --> D1["Database primary in Zone 1"]
    W2 --> D2["Database replica in Zone 2"]
    D1 --> D2

What happens when a host fails?

Physical servers can break. Azure monitors host health, and when a problem is detected it can take steps to recover affected VMs, which in practice may mean restarting them on healthy hardware. For a Dedicated Host, the recovery behaviour depends on the settings and capabilities available at the time, and you should read Microsoft’s current documentation to confirm exactly how automatic recovery treats your hosts. Whatever the details, you should design so that losing one host is an event your application survives, not a disaster. A good test is to ask: “If this one host disappeared right now, what would my users notice?”

Choosing the right host is the single most important decision. Here is a simple method.

Capacity planning means working out how much computing power you need before you buy it. Because a Dedicated Host is billed as a whole server, an almost empty host wastes money, and a host that is too small forces you to buy a second one early. The goal is to fill each host to a comfortable level without squeezing it so tightly that you have no room to grow.

One family per host

A VM family is a group of VM sizes built for a similar purpose, such as general use, memory-heavy work, or fast local storage. A host supports one family at a time. If your estate mixes general-purpose and memory-heavy VMs, you need separate hosts for each. This can make a small estate expensive, because each family may leave a host partly empty.

Mixed sizes inside a family

Inside one family you can mix sizes. A host might run a few large VMs, or many small ones, or a blend. Think of it like packing a suitcase: one large item takes the room of several small ones. When you mix sizes, check the total vCPU count and that the combination is one that the host can actually hold.

Right-sizing and waste

Right-sizing means choosing resources that match real usage. Many teams discover that their VMs are bigger than they need. Before you move to Dedicated Host, measure how busy your VMs really are. Shrinking them first often means you need fewer hosts, and that can cut the bill significantly.

Where the money goes, and where you can save.

How billing works

With regular VMs you pay for each VM while it runs. With Dedicated Host you pay for the host itself, and the VMs placed on it do not carry their own compute charge. The meter runs for the host as long as it exists. This means the price per VM depends on how full you keep the host. A fully used host can be cost-effective, and a mostly empty host is very expensive per VM.

Software licenses

The host price covers the hardware, not necessarily the software on your VMs. Operating system and database licenses may be charged separately, depending on your agreements. This is where Dedicated Host can become attractive. Microsoft offers Azure Hybrid Benefit, a program that lets eligible customers use licenses they already own, with active Software Assurance or qualifying subscriptions, instead of paying for new ones in Azure. For Windows Server and SQL Server on a Dedicated Host, the benefit can be applied across the whole host, which may allow many VMs to be covered by the licenses you hold for the physical cores. The exact rules, such as eligibility and how cores are counted, are set by Microsoft’s licensing terms, so confirm them with your licensing contact before you rely on the savings.

Reservations

A reservation is a deal where you promise to use a resource for one or three years, and in return Azure gives you a lower price. Dedicated Hosts support reserved pricing. If your workload is steady and will run for a long time, a reservation can lower the cost noticeably. If your needs may change soon, pay-as-you-go keeps you flexible.

Servers need care. Dedicated Host lets you have a say in when it happens.

Every physical server needs updates for its firmware, its host operating system, and its hypervisor. Updates fix bugs and security holes, so skipping them is not an option. Azure uses several techniques to apply updates while VMs keep running, and many updates cause only a very short pause, sometimes so brief that applications do not notice. Some updates, however, may need a reboot of the host, which restarts the VMs on it.

Maintenance control

For Dedicated Hosts, Azure provides maintenance control features. You can create a maintenance configuration that describes a window of time in which you are willing to accept platform updates for your hosts. Within the rules Microsoft sets, such as a limit on how long updates can be deferred for security reasons, you can steer the work toward a quiet period. This is valuable for businesses with sensitive seasons, such as a tax-filing week or a holiday sale.

Do not confuse host updates and guest updates

The host operating system belongs to Microsoft. The guest operating system, which is the operating system inside your VM, belongs to you. Maintenance control affects the first kind. You are still responsible for patching the guest, installing security fixes in your applications, and keeping your software current. Dedicated Host does not patch your VMs for you.

What the dedicated hardware protects, and what it does not.

The main security gain of Dedicated Host is physical isolation. No VM from another customer shares the server’s processors, caches, or memory with yours. This removes a whole class of worries about attacks that rely on sharing hardware with a victim, often called side-channel attacks. A side-channel attack is a sneaky technique that learns secrets by watching tiny differences, such as timing, in a shared component. If nobody else is on the server, nobody else can watch.

What stays the same

Dedicated hardware does not make your VM secure by itself. A VM with a weak password, an outdated application, or an open network port is just as exposed on a Dedicated Host as on a shared one. Think of a house with its own plot of land: it is private, but it is not safe if you leave the front door open.

Security checklist

• Access control: Use Azure role-based access control, known as RBAC, which means giving each person only the permissions they need. Limit who can create, change, and delete hosts, because deleting a host is a serious action.
• Network protection: Use network security groups and private connectivity so VMs are reachable only from places that should reach them.
• Disk encryption: Encrypt managed disks and keep keys in a managed key vault.
• Guest hardening: Keep operating systems patched, remove unused software, and turn off unneeded services.
• Policy: Use Azure Policy, a feature that enforces rules automatically, to require tags and to restrict which regions and SKUs can be used.
• Threat detection: Turn on Microsoft Defender for Cloud so unusual behaviour in your VMs raises an alert.

You cannot manage what you cannot see. Here is what to watch.

Monitoring means continuously checking the health and behaviour of your system. Metrics are numbers measured over time, such as processor use. Logs are written records of events, such as “VM created” or “host deleted”. For Dedicated Host you care about two separate layers: the host layer, which answers “how full is my server?”, and the VM layer, which answers “how are my applications doing?”.

Host layer

The most important host question is remaining capacity. The host’s detailed status shows how many VMs of each size can still be allocated. Watch this number, because when it reaches zero, new VM requests fail. Use the Azure Activity Log to see who created, changed, or deleted hosts and VMs, and use Azure Resource Health and service health notifications to learn about platform problems or planned maintenance that may affect your hosts.

VM layer

Inside the VMs, use Azure Monitor to collect processor, memory, disk, and network metrics, and collect application and operating system logs into a central workspace. This tells you whether a VM is oversized, undersized, or struggling. If VMs are mostly idle, you may be able to pack more on each host or use fewer hosts.

Dedicated Host is one of several ways to get more isolation. Compare before you choose.

Azure offers a ladder of isolation. At the bottom are regular shared VMs, which suit most workloads. Above them are isolated VM sizes, special large VM sizes that use a whole hardware generation so that effectively only one customer’s VM runs on that server, without you managing a host. At the top is Dedicated Host, where you hold the server itself and control placement. There are also confidential computing options, which protect data while it is being processed using special processor features, and those solve a different kind of problem.

How to choose

Ask three questions. First, do you need exclusive hardware, or just stronger protection of data in use? If exclusive hardware, continue. Second, will you run just a few very large VMs, or many mixed VMs? A few very large VMs might fit an isolated size nicely. Many VMs, or a need for license counting and maintenance control, points to Dedicated Host. Third, are you ready to manage capacity? If not, the simpler options are safer.

Every design choice gives something and takes something. Be honest about both sides.

The central trade-off

The big trade-off is control versus convenience. Regular VMs give you convenience: Azure handles placement, packing, and capacity. Dedicated Host gives you control: you decide where VMs live and you hold the hardware. Control brings responsibility and cost. A good architect chooses control only where the business reason is strong enough to justify the extra work.

Cost versus isolation

Isolation costs money, because you cannot share the price of the server with strangers. The cost is worth it when a rule demands isolation, when license savings are large, or when a failure caused by a noisy neighbour would cost more than the premium. It is not worth it merely because it sounds more secure. Security comes from many layers, and physical isolation is only one of them.

Flexibility versus commitment

Reservations lower the price but commit you to a term. Pay-as-you-go keeps you flexible but costs more per hour. If your estate is stable, commit. If it is changing fast, stay flexible until things settle.

Proven shapes to copy, and common shapes to avoid.

Patterns that work

Anti-patterns

An anti-pattern is a common solution that looks sensible but causes trouble. Here are the usual ones.

A practical list you can print and keep next to your desk.

Best practices

• Start with the need. Write down the exact reason for the dedicated hardware before you create anything.
• Measure first. Right-size your VMs using real usage numbers so you do not buy more host than you need.
• Use at least two hosts. Place them in different fault domains or different zones.
• Keep headroom. Do not fill hosts completely; leave room for failures, growth, and maintenance.
• Turn on automatic placement when you do not need to control exactly where each VM goes.
• Schedule maintenance into a quiet window, and keep replicas on different hosts.
• Automate creation. Describe hosts and groups in an infrastructure-as-code tool, which means keeping your setup in text files so it can be repeated and reviewed.
• Tag and review. Add owner, project, and cost-centre tags, and review hosts monthly.
• Use reservations only for steady, long-lived hosts.
• Test failure. Practise losing a host, in a test environment, so your team knows what happens.

Common mistakes

Four typical situations, described as illustrative examples, showing when the service fits.

The stories below are illustrative composites of the kinds of situations where teams commonly consider Dedicated Host. They are not claims about any particular company, but they reflect the reasoning real architects use.

Short answers to the questions beginners ask most often.

Everything important, in one place.

Azure Dedicated Host gives you a whole physical server inside an Azure data centre, so none of your neighbours share your hardware. You organise hosts into host groups, spread them across fault domains and zones, and place regular Azure VMs onto them. You pay for the host as a whole, which rewards good filling and punishes waste. In return you gain a simple isolation story for auditors, better use of eligible licenses, and some control over maintenance timing.

Remember the comparison we began with: an apartment versus a house. A house gives privacy and control, but you must keep it clean, locked, and filled with useful things. Use the service where the privacy is truly needed, keep your hosts well used, never put all your eggs on one host, and keep doing the usual security and patching work inside your VMs.