Azure Dedicated Host - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Opening. Why would you rent the whole server? Why would you rent an entire physical server in Azure when you could just create a virtual machine and pay for that? Here's a simple way to think about it. Imagine an office building. A normal Azure Virtual machine is like renting one office. You work behind a locked door, but other companies rent offices in the same building as your dedicated host is more like reserving a whole floor for your own company. That sounds comfortable, but it also costs more. By the end of this, you'll understand the isolation, the maintenance control, and the licensing reasons behind it, plus that expensive mistake people make when they reserve a host and leave most of it empty.

0:40 The problem dedicated host solves most Azure virtual machines run on shared physical hardware. Behind the scenes, your VM stays separate from another company's VM. Azure uses virtualization to keep each customer's operating system files memory and network traffic apart. For most workloads, that's exactly what you need. You create a VM pick it size, install your app, and Azure puts it onto available hardware in one of its data centers. You don't see the physical server. You usually don't need to. But some organizations need more than logical separation. They need to know that no other customer runs virtual machines on the same physical server as theirs. Why would that matter? Sometimes it comes down to a company rule, an industry regulation, or a customer contract, a bank, healthcare provider, government team or company handling sensitive information may need hardware isolation as part of its security review.

1:27 They need to show where a workload runs and prove that the host belongs only to their organization. Here's the thing. Other times, the issue is software licensing. Some Windows Server and SQL server licenses work differently when you license a physical host. If a company already owns eligible licenses, placing many VMs on one dedicated host can change the cost calculation. That doesn't mean it always saves money. The host itself still costs money, but it creates an option that shared VMs don't provide. Then there are workloads that care about placement. Imagine a company runs several busy application VMs on normal shared Azure hardware. Azure chooses the host beneath each VM that keeps Azure flexible, which is useful, but the company doesn't choose exactly which physical server carries those VMs. With a dedicated host, the organization can decide which of its VMs share a physical server that can help when an app needs steady access to the host's memory and storage resources, or when a team wants tighter control over where workloads sit.

2:16 Notice the difference? A normal Azure VM gives you a virtual computer. A dedicated host gives you control over the physical server beneath a group of virtual computers. Before cloud services companies bought servers, installed them in their own server rooms, replaced failed parts, planned power and cooling, and waited for new hardware when they ran out of room. That brought control, but it also brought a lot of work. Azure changes that arrangement. Azure still owns the data center. Azure handles the building power, cooling, hardware repairs, and the platform that runs the VMs. Your organization doesn't receive a server in the mail or start swapping disks at midnight. Instead, you reserve the capacity of a physical Azure server for your own workloads. That middle ground matters. You get more control than a regular shared VM While Azure continues to run the physical data center behind the scenes.

3:01 So what exactly do you receive when you create an Azure Dedicated host? What Azure Dedicated Host actually is? So here's the simplest definition. And as your dedicated host is a physical server inside an Azure data center that Azure sets aside for one subscription, just one. That's the plain English version. You still create normal Azure virtual machines, and they still run on a virtualization layer. You aren't logging directly into a bare metal server or installing an operating system onto the physical machine yourself. Instead, Azure gives you a subscription, a private pool of physical capacity, and no other customer can place their virtual machines on that host. Think of it less like owning the building and more like reserving a private floor in a fully managed office tower. Azure owns the tower. Azure runs the power cooling network security at the front entrance and repairs.

3:44 When hardware fails, your company reserves that floor, then decides which of its own teams use the rooms on it. That private floor is the dedicated host. The important word is host. A host is the physical machine that supplies processor cores, memory and other resources for virtual machines with a standard Azure VM, Azure chooses a suitable host. Behind the scenes with Azure Dedicated Host, you create the host as an Azure resource and place compatible VMs onto it, so you gain visibility into the physical layer without taking over the job of running a data center. One host can carry more than one VM. For example, you might place several application servers, a database server, and a test server on the same dedicated host. As long as the host has enough room. Those VMs can have different sizes, but they must come from the VM size family that the host supports.

4:25 That last part catches people out. You can't create one dedicated host and assume every Azure VM size will run on it. A host SKU, which is Azure's name for a host type, matches a particular VM family and hardware type. If your host supports one family, you choose VM sizes from that family. When filling it, picture a parking garage built for regular cars. You can park compact cars, sedans, and SUVs in the spaces if they fit the rules for that garage. But you can't drive a delivery truck into a garage that wasn't built for it. The same idea applies here as you attracts the capacity remaining on the host as you place VMs. If the host has room, another compatible VM can start there. If the host runs out of available processor or memory capacity, Azure can't fit another VM onto it, even if you'd like to add one.

5:07 A dedicated host also doesn't mean one VM automatically receives every resource in the server. You choose how to divide the host capacity between your VMs. One company may put a few large VMs on a host. Another may run a large number of smaller VMs. Both approaches use the same basic model one physical server divided into virtual machines for one organization. Before you create the physical hosts, you normally create something called a host group. A host group is a container for dedicated hosts. It tells Azure where those hosts belong, such as the Azure region you choose and where you use one, the availability zone. You can think of a host group as a label on a set of reserved floors inside one Azure location. It keeps related hosts together from a management point of view, while giving Azure the information it needs about where they should sit.

5:49 The host group doesn't run your app, the host does, and the VM runs your operating system and application. That sounds like a lot of layers, but it's easier when you see the order. First, you create a host group inside it, you create one or more dedicated hosts. Then you create compatible VMs and place them onto those hosts. You can choose a specific host for a VM or in some setups, let Azure choose an available host within the host group. That means dedicated host gives you placement control, but it doesn't remove Azure from the picture. Azure still runs the platform, monitors host health, and keeps the data center operating. You're choosing where your VMs land within capacity you have already reserved. Next, let's put the pieces together. Because host groups hosts VMs, zones, and fault domains each solve a different part of the problem how the building blocks fit together.

6:35 So how do you set this up in a way that can survive a problem with one piece of hardware? Start with the host group. When you create a host group, you choose an Azure region such as West Europe or East US that places the group in the wider Azure location where your VMs and supporting services will run. You may also choose an Availability Zone. An availability zone is a separate physical location inside one Azure region. Each zone uses its own power, cooling and network equipment. If a problem affects one zone, another zone can continue running. That means a host group belongs to one zone. When you choose zone placement, you can't put one host group across several zones. If your application needs to run across zone one and zone two, you create separate host groups. One group goes into zone one, another goes into zone two. Then you add hosts to each group and spread your VMs across them.

7:17 That sounds like extra setup because it is, but you're deciding where the physical boundaries sit before a failure forces the issue. After the host group exists, you create dedicated hosts inside it. Each host maps to a physical server in an Azure data center, and Azure reserves that capacity. When the host is created, you select the host type based on the VM family you plan to use. Then Azure gives you a server that can run compatible VMs. At this stage, plan ahead if your application uses one VM family today but needs another family later, that may require a different dedicated host type. A host doesn't turn into a different hardware type after you create it, So choosing the host type starts with the VM sizes your workloads actually need. Once hosts are ready, you place VMs onto them.

7:57 You can select a specific host if you want direct placement control. For example, you might decide that one application VM belongs on host A and another belongs on host B. Azure can also place VMs automatically inside a host group when automatic placement is enabled. In that case, you tell Azure which host group to use, and Azure picks an available host that has enough capacity. You still stay within your reserved hardware, but Azure handles the last placement choice. Both approaches work. Manual placement gives you a clear view of exactly where each VM runs. Automatic placement can reduce the work when you have several hosts and compatible VMs, but you still need enough spare space across those hosts. Azure checks capacity as each VM starts. A host may have available processor capacity, but the VM must also fit the hosts supported size family.

8:39 So placement is not just about finding empty space. The VM has to match the type of server you reserved. Now zones protect you from a wider side problem. Fault domains help with a smaller hardware problem. Think about the rows of server racks inside a data center. A fault domain separates hosts across different physical rack groups, so one rack level problem is less likely to affect every host in your design. When you create a host group, you choose the number of fault domains you need. Then, as you create hosts, you assign each host to a fault domain. Your VMs don't need their own fault domain setting. The host carries that placement decision one detail matters here. Two hosts assigned to different fault domains gain separation, but hosts with the same fault domain don't automatically sit beside each other.

9:20 A fault domain is about reducing shared failure risk, not about placing machines close together. Let's use a simple example. Imagine your company runs an internal ordering app. It has two application VMs that do the same job, and a load balancer sends users to whichever VM is available. You create two dedicated hosts. Host A goes into fault domain one host B goes into fault domain two. Then you place one application VM on each host. If Azure needs to repair hardware affecting host A, the VM on host A may become unavailable for a period, but the second VM continues on host B so employees can still place orders. That's the design goal. You don't buy two hosts because you enjoy paying for two hosts. You use separate hosts because a second copy of the application only helps when it doesn't depend on the same physical machine.

10:01 The same idea applies across availability zones. If you place one application VM in a host group in zone one and another in a host group in zone two, you gain protection against problems that affect an entire zone. It requires more planning, and your application must support running in more than one place, but it creates a wider separation boundaries so the building blocks follow a simple order. Choose the region, create one or more host groups. Use zones when your app needs separation between physical Azure locations. Add dedicated hosts and place those hosts across fault domains when you need rack level separation, then spread your VMs so one host doesn't carry every copy of the application. A private host gives you more placement control, but hardware can still need repair, isolation, security, and maintenance control.

10:42 Let's talk about what physical isolation actually changes your VMs on a dedicated host. Don't share that physical server with any other Azure customers VMs. If your team has rules about single tenant hardware, that gives you a clear answer during a security review, those workloads run on capacity reserved just for your organization. It's a clean box you can point to when a contract, company, policy or regulator asks for host level separation. But here's the thing. Dedicated hardware isn't the same as complete control of everything below it. Azure still runs the data center and the physical platform. Microsoft handles power cooling, networking, failed components, and that virtualization layer that lets your VMs run. You get to choose the host for your workloads, but you don't become the data center operator.

11:22 That's an important difference. Your security responsibilities stay familiar to. You still need to protect the operating system. Inside each VM. You still manage identities, network rules, and updates. Inside the guest OS, you still control access to your apps and data. A dedicated host changes where the VM runs. It doesn't patch an unprotected VM for you. That part is still your job. Now some workloads really care about maintenance timing. Azure occasionally updates the platform below your VMs to improve reliability, performance, security or add support for new capabilities. Most maintenance causes little to no disruption, but some applications notice even a short pause. A trading system might notice. A factory system might notice a tightly timed business process. Might notice. Dedicated host gives you maintenance control for supported platform maintenance.

12:04 You can defer a regular update and apply it when your team chooses. Within a rolling thirty five day maintenance window that gives you room to prepare. Maybe you notify users first. Maybe you move traffic to another copy of the app. Maybe you schedule the work during a quieter period. The point isn't that maintenance disappears. The point is that you get to choose its timing within the window. Azure allows. Once that window ends, Azure applies the pending maintenance. So think of it as controlled scheduling, not a permanent skip button. There's another detail that shapes how you design the app, as your dedicated host doesn't support live migration on some shared Azure setups, Azure may move a running VM to different hardware with little or no visible interruption. Dedicated hosts work differently if the underlying host develops a failure, Azure can service heal it by moving the host and its VMs to healthy hardware, then restarting those VMs.

12:51 That process brings a short period of downtime. The host comes back with the same basic placement settings its region host group, fault domain, and host type. But your VMs must restart as part of the recovery. You can also choose when creating the host, whether Azure automatically replaces it after a failure. Teams with strict compliance needs may decide not to let Azure automatically replace the host, because they need a stronger connection between their host resource and the underlying machine. That choice also brings more responsibility. If the host cannot recover, you may need to create another host and move the VMs yourself. So don't plan around one dedicated host, never failing. Plan for the application to survive a host failure. Run copies of important workloads on separate hosts. Use load balancing where it fits. Test that an app can restart cleanly.

13:31 Keep backups and recovery plans ready because physical isolation doesn't remove the normal risks of running software. And once you reserve an entire physical server, the next question becomes very practical what are you paying for and how much of that server will you actually use? Pricing licenses and the capacity trap. With a normal Azure VM. You usually think in VM prices, you choose a size, run it for as long as you need it, and pay for that VMs compute use dedicated host flips that idea around. You pay for the physical host itself, whether it runs one VM, ten compatible VMs or no VMs at all. Azure builds the host while it remains allocated. Because Azure has reserved that physical capacity for your organization. That's the capacity trap. Imagine you reserve a large meeting room for a full day.

14:12 Then only two people show up. The room still costs the same. A dedicated host works much like that. Empty processor capacity and unused memory don't lower the host bill. The VMs you place on that host still appear in your Azure bill, but their compute charge shows as zero because you already paid for the host. Storage still costs money. Network use can still cost money. Software licenses can still cost money too. So don't read zero VM compute price as zero cost. It only means the compute charge moved from each VM to the host. Before you create a host list, the VMs you expect to run there. Look at their VM family, their processor needs and the total capacity they will use. Then compare that plan with the capacity of the host type available in your Azure region. This is not a purchase you guess at.

14:52 A host supports VMs from its matching VM family, and it has a fixed amount of capacity. You can mix different compatible VM sizes, but every VM you add takes a piece of the host. Once capacity runs out, another VM won't fit. There's a second planning issue. You can't resize a dedicated host after you create it. If you later need another host type or hardware generation, you create a new host and plan the move for your VMs. That means the host choice needs to match both your workload today and your likely needs in the near future. Dedicated host often suits workloads that run steadily. Maybe you have a group of Windows Server VMs that run all day, every day. Maybe you have SQL server workloads that already need a fixed amount of capacity. If those VMs can fill much of a host host level, pricing may work well.

15:33 But if your workload changes every week or only runs for short periods, a regular Azure VM may fit better. Regular VMs give you more freedom to grow and shrink without carrying the cost of unused physical space licensing can change the math. Azure Hybrid Benefit lets eligible customers use existing Windows Server and SQL server licenses in Azure for dedicated host. This can reduce the software part of the cost when your licenses qualify under the current terms, the word eligible matters. Licensing depends on the product edition, the license type, software assurance or equivalent subscription rights, and the rules that apply to your organization. Don't assume every old license can move to a dedicated host in the same way. For some organizations, Windows Server Data Center licenses or SQL Server enterprise licenses with the required rights can provide unlimited virtualization rights on a dedicated host after they licensed the available physical cores on that host.

16:21 Here's the plain English instead of licensing every Windows Server or SQL server VM one by one, they may license the hosts physical cores and run as many qualifying VMs as the host can physically hold. That can matter a lot when one host carries many Windows Server or SQL server VMs. Still, licensing doesn't create extra capacity. You can have unlimited virtualization rights under the right license terms, but the host only runs the VMs that fit within its. Actual processor and memory limits. The licensing rule changes the software cost model. It doesn't turn one server into an unlimited server. Azure also has reservations for dedicated hosts. A reservation is a longer commitment for a matching host type and location. It can lower the host cost for steady, long running needs, but it also means you're betting that you'll keep using that capacity.

17:04 That's sensible. When the workload is stable, it's risky when the workload may disappear. Change VM family or move to another region soon. Use the Azure Pricing Calculator for the region and host type you plan to use. Check the current dedicated host pricing page, then ask your Microsoft licensing, contact or licensing partner to confirm what your existing licenses allow. You need the full picture host price, storage network, use backup software licenses, reserved capacity, and the cost of capacity you pay for but don't use a dedicated host can lower costs in the right design. It can also turn a small group of VMs into a very expensive private server. So plan carefully and you'll know which side of that equation you're on when dedicated host fits and when it doesn't.

17:45 Today, let's talk about when Azure Dedicated host actually makes sense and when it doesn't. Think of it this way. Imagine your company has a rule that says your servers must be physically separate from anyone else's. Or maybe a customer contract requires it. Dedicated host gives you that separation. It's like renting a whole house instead of an apartment. You get full control over the building, but you pay for the entire space whether you use every room or not. Licensing can also steer you toward dedicated host. If you already own licenses for Windows Server or SQL server and you run a steady number of VMs, the host level pricing might save money. But here's the catch you need to run enough VMs to fill the server, otherwise, the math doesn't work. And here's the thing your application needs to handle maintenance gracefully.

18:27 Dedicated host lets you control when the host gets updated, but if uptime matters, your app should run across at least two hosts. One host goes down for updates, the other keeps running. On the other hand, dedicated host doesn't fit every scenario if you only have one or two small VMs that change often, it's probably overkill. Same for short term projects that come and go quickly. In those cases, regular Azure VMs are simpler and cheaper because you pay for the capacity you use, not the whole server. So here's a quick checklist. Ask yourself three questions. Do you truly need a physical server dedicated only to you? Can your VMs actually use enough of the host to justify the cost? Can your application survive if one host becomes unavailable? If the answer to the first question is no, start with regular VMs.

19:07 If the answer to the second is no, be careful. You might solve a technical requirement while creating a budget problem. Conclusion. Choose the right level of control. Here's your bottom line. As your dedicated host gives you a private physical server in the cloud, but you pay for that server whether you fill it or not. So match the tool to your workload, not the other way around. Thanks for listening to Microsoft Knowledge Nuggets. I'm Marco Peeters. If this helped, subscribe on M365 FM and in the next episode, we'll cover how to choose the Azure Compute option that actually fits your workload. So you're not paying for empty server space.