Azure Arc in 2026 and Where It Stops

In this article

• Arc-Enabled Servers: The Strongest Use Case
• Arc-Enabled Private Clouds: Where Governance Becomes Lifecycle Management
• Arc-Enabled Kubernetes: Multi-Cluster Governance
• Arc-Enabled SQL Server: The Practical Database Case
• Arc-Enabled Data Services: Promise Meets Reality
• Arc as a Governance Layer
• Where Arc Stops
• Cost Model
• When Arc Makes Sense
• When Arc Is Overkill
• Getting Arc Right

In short: Azure Arc now operates at two depths. The Connected Machine agent projects an existing server into Azure for governance: one policy, patching, monitoring, and Defender surface across every location. Resource bridge integrations for VMware vSphere, System Center VMM, and Azure Local go further and manage VM lifecycles from Azure. Neither depth migrates the workload, and neither transfers responsibility for the underlying platform to Microsoft. This post covers how much control each Arc integration really provides, what stays local, what it costs, and when Arc is overkill.

We wrote about Azure Arc at its 2020 GA with cautious optimism. The pitch was clear: install an agent, project non-Azure resources into Azure Resource Manager, and manage everything from one control plane. Policy, monitoring, security, updates. One toolchain across on-prem, AWS, GCP, and edge.

Six years later, Arc has delivered on much of that promise. It has also revealed its limits, and it has quietly split into two different propositions that share one name. Across larger hybrid deployments the technology itself is rarely the difficult part; scope, network approval, policy design, and ownership of the services enabled on top decide whether the implementation succeeds or stalls.

Arc is a governance play rather than a migration play. It does not move workloads to Azure; it extends the Azure management plane to wherever workloads already run. But parts of the portfolio now reach past governance into infrastructure lifecycle management, and knowing which part you are buying is the difference between a successful Arc deployment and a disappointed one.

Arc-Enabled Servers: The Strongest Use Case

Arc-enabled servers remain the most mature and broadly useful Arc capability. You install the Connected Machine agent on a Windows or Linux server, and that server appears in Azure Resource Manager as a resource with a resource ID, resource group membership, tags, and location.

Once the server is in ARM, the Azure management stack works against it. Azure Policy audits and enforces configurations. Update Manager patches the server alongside Azure VMs. Defender for Cloud provides vulnerability assessment and threat detection. Azure Monitor collects performance and log data into the same workspace as your Azure resources.

Extensions are the delivery mechanism. The monitoring agent, Defender agent, Key Vault extension, and custom script extensions all deploy using the same extension model as Azure VMs. A single Azure Policy assignment can deploy the monitoring agent to every Arc-enabled server in a management group, regardless of where those servers physically run.

The real value is consolidation. Before Arc, managing on-prem servers alongside Azure VMs meant separate patching tools, separate monitoring dashboards, separate security tools, and separate compliance reporting. Arc puts the governance and visibility layer into one place.

Arc-Enabled Private Clouds: Where Governance Becomes Lifecycle Management

Here is where the single name starts covering two different products, and where conversations about “Arc” go wrong. The Connected Machine agent performs guest projection: it lives inside an existing machine and exposes inventory, policy, extensions, monitoring, patching, and security, with no control over the hypervisor underneath.

Arc-enabled VMware vSphere, Arc-enabled System Center VMM, and Azure Local VMs work differently. Through the Azure Arc resource bridge, they perform infrastructure projection: part of the virtualisation platform itself becomes visible in Azure, and Azure can act on it. You can create, resize, start, stop, and delete VMs, and modify disks, network interfaces, CPU, and memory, from the Azure portal or ARM templates, with Azure RBAC deciding who may do which of those things.

What infrastructure projection still does not supply is the platform’s own qualities: availability, storage resilience, and disaster recovery remain whatever vSphere, VMM, or Azure Local provide, operated by whoever operated them before. Arc lets Azure drive the platform’s levers; it does not become the platform. When someone says “we manage our VMware through Arc”, ask which depth they mean, because self-service VM provisioning from the Azure portal and an agent inside each guest are different capabilities with different prerequisites.

Arc-Enabled Kubernetes: Multi-Cluster Governance

Arc-enabled Kubernetes projects any CNCF-conformant Kubernetes cluster into Azure. EKS, GKE, Rancher, k3s, on-prem clusters running kubeadm. Once connected, the cluster appears in the Azure portal and becomes addressable through ARM.

The governance model follows the same pattern as servers. Azure Policy for Kubernetes (based on Gatekeeper) enforces admission policies across all connected clusters from a central definition. GitOps via Flux deploys configurations and applications from Git repositories, managed as Azure extensions, and Microsoft now ships an Argo CD extension in public preview for teams standardised on it. Container Insights provides monitoring through a consistent dashboard regardless of where the cluster runs.

For organisations running Kubernetes in multiple locations (AKS in Azure, EKS in AWS, on-prem clusters for edge or latency-sensitive workloads), Arc provides the governance layer that prevents each cluster from becoming its own management island. Policy enforcement, GitOps configuration, and monitoring pipelines are defined once and applied everywhere.

Where Arc-enabled Kubernetes gets less useful: operational management of the cluster itself. Arc does not manage node pools, upgrades, or infrastructure. Those remain the responsibility of whatever platform runs the cluster. If your EKS cluster needs a node group update, you do that through AWS. Arc gives you visibility and governance on top; operational control stays with the platform underneath.

Arc-Enabled SQL Server: The Practical Database Case

Before the Kubernetes-based data services, there is a much lighter database proposition that the Arc conversation often skips. SQL Server enabled by Azure Arc connects the SQL Server installations you already run, on any Arc-enabled server, without replacing them with anything. In return you get a central inventory of every instance and database, best-practice and migration assessments, Defender for SQL coverage, Microsoft Entra authentication on supported versions, Extended Security Updates delivered without a separate agreement, and the option of pay-as-you-go SQL Server licensing through your Azure bill.

For most enterprises this is the broadly useful Arc database case: it meets the databases where they are. The managed instance below is a different, heavier decision.

Arc-Enabled Data Services: Promise Meets Reality

Arc-enabled data services let you run Azure SQL Managed Instance on your own infrastructure, managed through Azure. It is the only Arc-enabled data service left on the list: the PostgreSQL variant was retired in 2025, which is itself a signal about how hard this category is. The idea remains compelling: bring Azure PaaS database capabilities to on-prem hardware or other clouds, with Azure billing, monitoring, and management.

One constraint changed quietly and matters for regulated environments: the original product supported both direct and indirect connectivity, but Microsoft retired indirectly connected mode in September 2025. New deployments require an ongoing outbound path to Azure. The database and its storage remain local, but the management, inventory, and billing relationship is no longer designed for environments that cannot communicate with Azure. If the requirement is that application data stays local, Arc data services can still fit; if the requirement is that the management plane must also operate without Azure connectivity, they cannot, and Azure Local’s disconnected operations tier is the product for that conversation.

In practice, the deployment and operational model is more complex than the pitch suggests. Arc data services run on Kubernetes (which means you need a cluster, and you need to maintain it). The data controller that manages the database instances is itself a Kubernetes workload with non-trivial resource requirements. Upgrades, backups, and high availability configurations need careful planning.

Arc data services fit specific scenarios: regulatory requirements that keep data in a jurisdiction, environments where latency to Azure is too high for PaaS databases, and teams that already run Kubernetes on-prem.

Proof of concepts get abandoned when the Kubernetes requirement, backup complexity, and operational overhead exceed expectations. Arc data services are not “SQL Managed Instance on a VM.” They are a distributed system that requires engineering investment to operate.

If your data can live in Azure, use PaaS databases in Azure. Arc data services exist for the cases where data cannot move, and those cases should be clearly identified before starting.

Arc as a Governance Layer

The mental model that works best: Arc extends the Azure Resource Manager API surface to non-Azure resources. Every benefit flows from that extension.

Azure Policy works because Arc resources have ARM resource IDs that policy can evaluate. Update Manager works because the agent accepts extension-based update orchestration through ARM. Defender works because the Defender agent installs as an extension and reports to the same Defender backend. Tagging, RBAC, resource groups, management groups, cost management for Arc data services. All of it works because the resource exists in ARM.

This is why Arc is a governance play. It gives you one control plane for policy, compliance, visibility, and security posture across a distributed environment. That control plane moves no data and migrates no workloads; an on-prem server remains an on-prem server.

For organisations building landing zone architectures that include hybrid components, Arc is how those hybrid components become addressable within the same governance structure. Azure VMs and hybrid machines sit beneath the same management-group and policy-assignment hierarchy, so the governance structure is shared. The definitions underneath still need to target the relevant resource types (Microsoft.Compute and Microsoft.HybridCompute are different things to a policy), and not every effect is available identically on both, which is why Microsoft maintains a dedicated catalogue of Arc-enabled server policy definitions.

Where Arc Stops

Arc is a control plane; the data plane stays where it always was. Understanding this boundary prevents the most common disappointments.

Networking does not change. Arc does not provide VNet integration, private endpoints, or Azure networking capabilities for non-Azure resources. The server’s network stack, firewall rules, and connectivity remain exactly as they were before the agent was installed. The agent needs outbound HTTPS to Azure endpoints, but that is a management channel rather than a data plane connection.

Network approval used to be one of Arc’s least attractive implementation details, because each enabled service brought another endpoint list. The Azure Arc gateway improves that: core Arc onboarding concentrates through seven approved FQDNs and an auditable proxy path, with one gateway resource handling roughly 2,000 Arc-enabled servers per region. It simplifies egress governance rather than eliminating it; Azure Monitor, Defender, Key Vault, and update services can still require their own destinations, so keep the network team in the design conversation.

Compute, storage, and availability are still yours. An agent-projected server runs on whatever hardware or hypervisor hosts it; if the host fails, Azure sees the resource go offline and does nothing about it. The resource bridge integrations can restart or recreate a VM on vSphere, VMM, or Azure Local because they drive the platform’s own controls, but the platform’s availability, storage resilience, and disaster recovery remain whatever that platform provides. Backup, DR, and capacity planning never transfer to Microsoft at either depth.

Data plane operations are local. If you run SQL on an Arc-enabled server, queries execute locally, storage I/O is local. Arc provides the management overlay of monitoring, policy, and Defender; the runtime stays wherever the workload lives.

Teams that expect Arc to make on-prem infrastructure behave like Azure will be disappointed. Arc makes on-prem infrastructure visible and governable from Azure. Those are different things.

Cost Model

The cost model is one of Arc’s selling points, but it has nuance.

Arc-enabled servers and Kubernetes clusters are free to onboard. The agent costs nothing, and the ARM representation, tagging, and RBAC come with it. But a useful Arc deployment rarely stops at inventory, and each capability on top has its own meter or inclusion rule. As of August 2026: Azure Update Manager bills the equivalent of $5 per Arc-enabled server per month and Azure Policy machine configuration $6, both waived when Defender for Servers Plan 2 covers the machine, since Plan 2 includes them. Azure Monitor ingestion bills per GB. Kubernetes GitOps configuration is free for the first six vCPUs per subscription and per-vCPU after that, with Container Insights and Defender for Containers metered separately. Arc-enabled data services bill through Azure on the vCore configuration.

The practical implication: model the capabilities you will actually enable, per machine and per cluster, rather than assigning one generic cost to “an Arc-enabled server”. The plan choice on Defender in particular swings the total, because it absorbs two of the other meters.

When Arc Makes Sense

Hybrid environments that will stay hybrid. If the five-year plan includes on-prem servers, co-location, or other cloud providers alongside Azure, Arc provides the governance consolidation that makes a multi-location footprint manageable. Without Arc, you run parallel toolchains and parallel dashboards, and compliance reporting becomes a manual aggregation exercise.

Multi-cloud governance. Organisations with workloads in AWS and GCP alongside Azure can project EC2 instances and GKE clusters into Azure and govern them with Azure Policy. Whether this is the right approach depends on where the governance team lives. If the team is Azure-native, Arc brings everything into their existing toolchain. If the team is deliberately multi-cloud with Terraform and independent monitoring, Arc adds value only for specific Azure-native capabilities like Defender.

Edge sites with unreliable links. The Connected Machine agent heartbeats to Azure every five minutes and tolerates interruptions gracefully: a machine that drops offline is simply marked disconnected and picks up where it left off when the link returns. The boundary is measured in weeks rather than hours; a machine disconnected for 45 days can expire and needs re-onboarding. For retail locations, factory floors, and sites with flaky connectivity, that tolerance is enough. For genuinely disconnected environments that must operate with no path to Azure at all, Arc is the wrong tool and Azure Local’s disconnected operations tier is the product Microsoft built for the job, with Arc as its control plane inside the boundary.

When Arc Is Overkill

Fully Azure environments gain nothing from Arc. If every server is an Azure VM, you already have ARM integration, Policy, Defender, Monitor, and Update Manager.

Environments already governed by a credible alternative. When an existing management stack supplies the required inventory, patching, security coverage, and compliance evidence, adding Azure as a second control plane creates duplication instead of consolidation. The deciding factor is the missing capability rather than the raw server count: three regulated, internet-facing servers can justify Arc immediately, while hundreds of machines under an authoritative existing toolchain may not need it at all.

Short-term environments, usually. Servers heading for decommissioning rarely repay the onboarding effort, unless they need Defender coverage or patch evidence for exactly that remaining lifetime, in which case the compliance requirement decides, and the machine’s age does not.

Organisations without Azure investment. Arc extends Azure governance. If the organisation does not use Azure and does not plan to, projecting servers into ARM creates a dependency without an ecosystem to justify it.

Getting Arc Right

Start with servers. The agent deployment is straightforward, the value is immediate, and the overhead is minimal. Deploy at scale using a service principal and your existing configuration management tool, assign to a resource group in the connectivity or management subscription, and apply your standard policy set.

Add Kubernetes clusters when you have multi-cluster governance needs. If you run one AKS cluster, Arc adds nothing. If you run AKS, EKS, and an on-prem cluster, the unified policy and GitOps model justifies the setup.

Approach data services with clear requirements. Plan the Kubernetes infrastructure, the backup strategy, and the operational model before deploying. If the data can move to Azure, move it.

Treat Arc as infrastructure rather than a project, inside a deliberately defined eligibility scope. Make the agent the default for every machine in that scope, exclude unsupported appliances, tightly isolated zones, and systems already governed through an authoritative alternative platform, and write the exclusion list down. The value compounds when Arc is the default with documented exceptions instead of a special deployment for selected servers.

Technical details verified against Microsoft’s Azure Arc documentation on 2 August 2026.

Related: Azure Local in 2026 and Which Tier Fits Which Workload the platform Arc governs inside your boundary · Azure Landing Zones in 2026 and What Actually Matters Now where Arc resources land in the hierarchy · Defender for Cloud in 2026 and What to Enable, Tune, and Skip the biggest line on the Arc bill · Cloud Sovereignty in 2026 and Why It Is a Workload Classification Problem when data cannot move