The cloud is not always the right place for every workload, but people still want cloud-style management everywhere.

Reasons workloads stay close to home

Public cloud is excellent for many things, but some workloads must remain on site. A factory floor machine needs to respond in a few milliseconds, and a network round trip to a distant region is too slow. A hospital or bank may have rules that keep certain data inside its own building or country. A ship, mine or remote branch may have poor or intermittent internet. A company may own expensive hardware and applications that are not ready to be rebuilt for the cloud. A retailer with hundreds of stores wants identical computing in each one, managed from one place.

These cases are often called edge computing when the computers sit near where data is produced, and hybrid cloud when on-premises and cloud systems work together. Azure Stack HCI is Microsoft’s answer: a way to run virtual machines, containers and selected Azure services on hardware in your location, while managing and monitoring everything through Azure.

What “HCI” means

HCI stands for hyperconverged infrastructure. In older datacenters, computing, storage and networking were separate boxes: racks of servers, a big shared storage array, and networking switches, each bought, managed and upgraded separately. Hyperconverged infrastructure merges compute and storage into the same servers: each server contributes its own processors, memory and disks, and software combines them into a shared pool. To grow, you add another server and get more of everything.

Microsoft has several products with “Azure” and “Stack” or “Arc” in their names. Telling them apart prevents expensive confusion.

flowchart TD
  AZ["Azure public cloud: portal, policy, monitoring, identity"] --> ARC["Azure Arc: connection and projection of resources"]
  ARC --> HCI["Azure Stack HCI cluster on your hardware"]
  ARC --> WS["Windows and Linux servers elsewhere"]
  ARC --> K8S["Kubernetes clusters elsewhere"]
  HCI --> VM["Virtual machines"]
  HCI --> CON["Containers and Kubernetes"]
  HCI --> AVD["Virtual desktops and other Arc-enabled services"]
        

An Azure Stack HCI deployment is a cluster of servers acting as one system.

A cluster is a group of servers, called nodes, that work together so that if one fails, the others carry on. In Azure Stack HCI the nodes run a specialized operating system built for the purpose. That operating system includes a virtualization layer, a software-defined storage layer and optional software-defined networking, managed together. Above it run your workloads, and alongside it runs the Azure Arc connection that registers the cluster in Azure.

flowchart TD
  subgraph NODE1["Node 1"]
    C1["Compute: processors and memory"]
    D1["Local disks"]
  end
  subgraph NODE2["Node 2"]
    C2["Compute: processors and memory"]
    D2["Local disks"]
  end
  subgraph NODE3["Node 3"]
    C3["Compute: processors and memory"]
    D3["Local disks"]
  end
  D1 --> POOL["Shared storage pool built by software"]
  D2 --> POOL
  D3 --> POOL
  POOL --> VOL["Volumes presented to the cluster"]
  VOL --> WL["Virtual machines and containers"]
  NODE1 --- NET["High-speed network between nodes"]
  NODE2 --- NET
  NODE3 --- NET
        

Hardware choices

Understanding how many “computers” share one real computer is the foundation of everything else.

Virtual machines

A virtual machine, often shortened to VM, is a software imitation of a computer that runs on a real one. A special layer called a hypervisor divides the physical server’s processors, memory and disks among several virtual machines, each believing it has its own hardware. In Azure Stack HCI the hypervisor is Hyper-V, the same technology used widely in Windows Server and, in its own variant, in Azure itself.

Failover clustering

The nodes are joined by failover clustering. The cluster constantly checks which nodes are healthy. If a node fails, the virtual machines that were running there are automatically restarted on other nodes, usually within a minute or two. Because all nodes can reach the same storage pool, no data needs to be copied at that moment. Planned maintenance is even smoother: virtual machines can be live migrated, moved between nodes while running, so a node can be updated or repaired without users noticing.

sequenceDiagram
  participant N1 as Node 1
  participant N2 as Node 2
  participant CL as Cluster service
  participant VM as Virtual machine
  N1->>CL: Heartbeat: healthy
  N2->>CL: Heartbeat: healthy
  Note over N1: Node 1 fails
  CL->>CL: Missed heartbeats detected
  CL->>N2: Restart virtual machine from shared storage
  N2->>VM: VM running again on Node 2
        

Quorum and the witness

A cluster must decide who is “in charge” and which part of the cluster is still valid if the network splits. It uses a voting system called quorum: a majority of votes must agree that the cluster can run. Each node has a vote, and in small clusters an extra vote comes from a witness, a lightweight third party that breaks ties. The witness may be a cloud witness, stored in an Azure storage account, which suits sites with internet access, or a file share or other option for isolated sites. A two-node cluster especially needs a witness; without one, losing a single node can stop the cluster.

Storage is the heart of hyperconverged design. If it is wrong, nothing else matters.

Storage Spaces Direct, usually shortened to S2D, is the software that turns the internal disks of all nodes into one shared storage pool. Instead of buying a separate storage array, you use ordinary drives inside each server, and the software keeps multiple copies of the data across nodes so that a drive or even a whole server can fail without data loss.

Drives and caching

Clusters often mix fast and slower drives. The fastest drives act as a cache, a quick landing zone that absorbs recent reads and writes, while larger and cheaper drives hold the bulk of the data. Many designs use all-flash storage, meaning solid-state drives of different speeds, for predictable performance. The software decides automatically which drives cache and which store, according to the mix present.

Resiliency types

flowchart LR
  W["Write from a virtual machine"] --> C["Cache tier: fast drives"]
  C --> M1["Copy on Node 1"]
  C --> M2["Copy on Node 2"]
  C --> M3["Copy on Node 3 for three-way mirror"]
  M1 --> CAP["Capacity drives hold the data"]
  M2 --> CAP
  M3 --> CAP
        

Capacity planning

Raw disk space is not usable space. After mirroring or parity, and after reserving space so the cluster can rebuild data after a drive failure, usable capacity is much smaller than the sum of disks. Leave unallocated reserve space for repairs, plan growth, and size cache so that the working set of active data fits. Miscalculating this is one of the most common causes of unpleasant surprises.

A hyperconverged cluster lives or dies by its network, because storage traffic runs across it.

Since data is copied between nodes over the network, network speed and reliability directly affect storage performance and safety. A cluster handles three broad kinds of traffic. Management traffic carries administration and Azure connectivity. Compute traffic carries the data of your virtual machines to the outside world. Storage traffic carries the replication and access between nodes. These can share physical network cards or be separated, depending on design.

Network ATC and intents

Configuring cluster networking by hand is intricate and error-prone. Network ATC lets you declare intents: statements such as “use these network cards for management and compute together, and these two for storage”. The system then configures virtual switches, settings and quality-of-service rules consistently across all nodes and keeps them from drifting. This sharply reduces configuration mistakes.

flowchart TD
  subgraph NODE["One node"]
    NIC1["Network cards 1 and 2"]
    NIC2["Network cards 3 and 4"]
  end
  NIC1 -->|Intent: management and compute| SW["Top-of-rack switches"]
  NIC2 -->|Intent: storage with RDMA| SW
  SW --> LAN["Corporate network"]
  SW --> OTHER["Other nodes"]
  LAN --> AZ["Outbound to Azure endpoints"]
        

Switchless storage networks

In small clusters, nodes can be connected directly to each other for storage traffic, with no storage switch in between. This reduces cost and complexity, especially for two or three nodes at remote sites, but limits growth and requires careful cabling. For larger or growing clusters, switches are the standard choice.

Software-defined networking

Software-defined networking, or SDN, adds virtual networks, software load balancing, distributed firewall rules and gateways managed in software, much like cloud networking. It can be managed through Azure Arc on newer versions or through other tools. It is optional, and brings its own planning and operational overhead, so adopt it only when you need network virtualization or micro-segmentation.

This is the part that makes the pantry in your kitchen answer to the supplier’s ordering system.

Azure Arc is Microsoft’s way of projecting resources that live outside Azure into the Azure management plane. When an Azure Stack HCI cluster is registered, each node is connected as an Arc-enabled server and the cluster appears in the Azure portal as a resource in your subscription. From there it can be governed with Azure Policy, secured with Azure security tools, monitored through Azure Monitor, and updated through Azure update services.

Arc resource bridge

A small, specialized virtual machine called the Arc resource bridge runs on the cluster. It is the translator between Azure’s control plane and the local infrastructure. When you click “create virtual machine” in the Azure portal, the request travels to the bridge, which asks the local cluster to create it. The bridge makes your on-premises cluster behave, from the portal’s point of view, like an Azure region with its own resource types.

sequenceDiagram
  participant USER as Administrator
  participant PORTAL as Azure portal and Resource Manager
  participant BRIDGE as Arc resource bridge on cluster
  participant CLUSTER as Local cluster
  USER->>PORTAL: Create virtual machine
  PORTAL->>BRIDGE: Request over outbound secure connection
  BRIDGE->>CLUSTER: Create VM using local resources
  CLUSTER-->>BRIDGE: Result
  BRIDGE-->>PORTAL: Status
  PORTAL-->>USER: VM appears as an Azure resource
        

Custom locations

A custom location is a label in Azure that points to your cluster, so that when you deploy something you can choose it like a region. It lets you deploy Arc-enabled services such as virtual machines, Kubernetes clusters and some data and application services onto your own hardware using the same templates and tools as in the cloud.

Connection requirements

The cluster needs outbound connectivity to Azure endpoints to register, receive updates, report health, and bill. It initiates all connections, so no inbound holes in your firewall are needed for core management. A cluster must reconnect to Azure within a defined period to remain in good standing; extended disconnection can limit functionality. Some newer options aim to allow longer or fully disconnected operations for special cases.

Getting from delivered hardware to a registered, validated cluster follows a clear sequence.

From a single small site to many nodes, shape matters.

flowchart LR
  subgraph SITE["Site design choices"]
    A["Single node: smallest, least resilient"]
    B["Two nodes with witness: common branch design"]
    C["Three or more nodes: stronger resilience"]
    D["Rack-aware or stretched: survive a rack or site loss"]
  end
  A --> B --> C --> D
        

What actually runs on the cluster?

Creating and managing virtual machines

Because the cluster appears as a custom location in Azure, you can create a virtual machine from the portal, command line or a deployment template, choosing an image, size, network and storage path. The virtual machine appears as an Azure resource with tags, access control and extensions. Guest agents allow policy, monitoring and updates inside the machine as well, just as for Azure virtual machines.

Modern applications often run as containers, and the cluster can host them too.

A container packages an application with everything it needs, so it runs the same everywhere. Kubernetes is the system that starts, stops, scales and heals containers across a group of machines. On Azure Stack HCI, Microsoft provides a way to create Kubernetes clusters whose nodes are virtual machines running on your HCI cluster, managed and updated through Azure Arc. This gives developers the same orchestration they use in the cloud, near the data.

flowchart TD
  HCI["Azure Stack HCI cluster"] --> VMA["Control plane virtual machines"]
  HCI --> VMB["Worker node virtual machines"]
  VMA --> K8S["Kubernetes cluster"]
  VMB --> K8S
  K8S --> APP["Containerized applications"]
  AZ["Azure Arc: lifecycle, policy, monitoring, GitOps"] --> K8S
        

Keeping a cluster current without downtime is one of the product’s biggest selling points.

Updating a cluster involves many layers: the operating system, the cluster software, the agents, the firmware of servers and drives, and the drivers of network cards. In the past each had its own tool and schedule. Lifecycle management in Azure Stack HCI brings these together into solution updates, tested bundles that update the layers in a controlled order. Updates are rolled through the nodes one at a time: a node is drained by live-migrating its workloads to others, updated, rebooted, checked, and then the next node is processed.

flowchart TD
  A["Update available in Azure"] --> B["Pre-checks: health, capacity, connectivity"]
  B --> C["Pick node 1: drain workloads"]
  C --> D["Apply updates and restart"]
  D --> E["Health check and resync storage"]
  E --> F{"More nodes?"}
  F -->|Yes| G["Next node"]
  G --> C
  F -->|No| H["Cluster fully updated"]
        

Servers in remote locations may be physically less protected than a datacenter, so security is built into the platform.

flowchart TD
  P["Physical: locked rack, tamper protection"] --> H["Hardware: secured-core, TPM, secure boot"]
  H --> O["Operating system: hardened baseline, application control"]
  O --> D["Data: BitLocker, encrypted traffic"]
  D --> I["Identity and access: Entra ID, role-based access, least privilege"]
  I --> M["Monitoring: Defender, logs, alerts"]
        

Identity and access

Azure role-based access control governs who can manage the cluster and its resources through Azure. Give people only the roles they need. Avoid shared local administrator accounts; where local accounts are needed, protect and rotate their passwords. If you integrate with an on-premises directory, plan its availability carefully, since directory outages can affect cluster operation.

A remote cluster that nobody watches will fail quietly.

Azure Monitor collects health and performance data from the cluster and shows it in the Azure portal. A dedicated insights view summarizes cluster health, node status, storage capacity and performance, network health, virtual machine counts and resource use. Logs and metrics flow to a Log Analytics workspace, where you can query them, build workbooks and create alerts.

flowchart LR
  CL["HCI cluster and nodes"] --> AG["Monitoring agents"]
  AG --> LA["Log Analytics workspace"]
  LA --> INS["Insights views and workbooks"]
  LA --> AL["Alert rules"]
  AL --> ACT["Action group"]
  ACT --> TEAM["Team channel, email or incident tool"]
        

Resilience inside a cluster is not the same as a backup, and neither is the same as disaster recovery.

flowchart LR
  VM["Virtual machines on HCI"] -->|Backup| AB["Azure Backup vault"]
  VM -->|Replication| ASR["Azure Site Recovery to Azure region"]
  VM -->|Optional replica| SITE2["Second HCI site"]
  AB --> RESTORE["Restore after deletion or ransomware"]
  ASR --> FAIL["Fail over to Azure in a site disaster"]
        

The main benefit of managing through Azure is consistency across hundreds of sites.

Because clusters, nodes, virtual machines and Kubernetes clusters appear as Azure resources, the whole Azure governance toolkit applies. Azure Policy can require encryption, enforce tagging, restrict regions, and audit configuration. Management groups and subscriptions organize resources. Role-based access control sets who can do what. Tags record owner, site, cost center and environment. Azure Resource Graph lets you query thousands of resources across sites in seconds.

Costs come from several places, and the pricing model is different from public cloud usage billing.

The right choice depends on where workloads must run and how much you want to manage yourself.

Cloud capacity is elastic; your pantry’s capacity is physical. Plan with care.

A checklist of typical issues and where to look first.

Habits that make hybrid infrastructure dependable, and habits that make it painful.

Patterns worth adopting

More anti-patterns to avoid

A review list to use before going live and at regular intervals afterward.

How organizations put Azure Stack HCI to work.

Short answers to common beginner questions.

It is Microsoft’s hyperconverged infrastructure that runs on validated servers in your own location and is managed through Azure, now branded Azure Local.

Compute and storage are combined in the same servers, and software pools their disks into shared storage, so you grow by adding servers.

No. Hub runs a subset of Azure cloud services as a private regional cloud, while HCI provides virtualization, storage, containers and Azure Arc management on your hardware.

Workloads run locally without it, but the cluster must reconnect to Azure within a defined period for management, updates and billing. Check the current allowed disconnection time and any disconnected options.

Only if they appear in the validated hardware catalog and meet requirements. Otherwise support and stability can be a problem.

One for small tolerant sites, two for a common small-site design with a witness, and three or more for stronger resilience and flexibility. Larger designs have extra requirements.

Software that pools the local disks of all nodes into shared, resilient storage by keeping multiple copies or coded protection across servers.

Through lifecycle management from Azure, rolling through nodes one at a time while workloads move to other nodes. Guest machines need their own patching.

No. It protects against drive and node failure, not deletion, corruption, ransomware or loss of the site. Keep independent backups and plan for disaster recovery.

Yes. Kubernetes clusters can run on virtual machines of the cluster and be managed through Azure Arc. Check the current version and feature support.

Typically a recurring host fee per physical core through Azure, plus guest operating system licensing options, hardware costs and any Azure services you use. Check the current pricing page.

When workloads have no latency, residency or connectivity reason to stay on site, public Azure usually offers more elasticity and less to operate yourself.

The concepts are stable, but names, versions, hardware lists, scale limits, disconnected options and prices change. Confirm details in the current official documentation before finalizing a design.

Azure Stack HCI, now branded Azure Local, brings cloud-style management to infrastructure you own and place where you need it. Validated servers form a cluster that pools compute and storage, tolerates failures through mirroring and failover, and carries storage traffic over a carefully designed network. Azure Arc and the resource bridge project the cluster into Azure, so you create virtual machines and Kubernetes clusters, apply policy, watch health, back up and update from one place. Security is built in from secured-core hardware to encryption and monitoring, but physical care of sites still matters. Careful sizing for failure and updates, independent backups and tested recovery keep operations dependable, and licensing combines hardware, a host service fee, guest licensing and Azure services. Because names, features and prices keep changing, hold on to the lasting ideas in this guide and verify the details in current documentation. Used for the right workloads, it gives you the supplier’s standards with the pantry inside your own kitchen.