Azure Arc

About Azure Arc

Azure Arc extends Azure's management plane to infrastructure that runs outside Azure, including physical and virtual servers, Kubernetes clusters and selected data services in datacenters, edge locations and other public clouds. Instead of moving every workload into Azure, organizations can project supported external resources into Azure Resource Manager so they can be organized, governed and monitored with familiar Azure tools. Arc is most useful for teams that want a consistent control plane across hybrid and multicloud environments without treating every environment as an isolated management island.

What can Azure Arc manage?

Azure Arc supports several resource types. Arc-enabled servers let organizations connect Windows and Linux physical servers or virtual machines that run outside Azure. Arc-enabled Kubernetes lets teams connect CNCF-certified Kubernetes clusters running on premises, at the edge or in other public clouds. Microsoft also provides Arc-enabled data services and SQL Server enabled by Azure Arc for selected database and management scenarios.

Once connected, these resources can appear in Azure Resource Manager with Azure resource IDs. That allows teams to use familiar grouping, tagging, inventory and governance patterns across resources that are not physically hosted in Azure.

How does Azure Arc work with servers and Kubernetes?

Arc-enabled servers use the Azure Connected Machine agent. After onboarding, each machine becomes a hybrid Azure resource that can be organized with resource groups and tags and can integrate with supported Azure services such as Azure Policy, Azure Monitor and Microsoft Defender for Cloud. The underlying server still runs where the organization placed it, so Arc does not turn an on-premises machine into an Azure virtual machine or transfer responsibility for the hardware and operating environment to Microsoft.

Arc-enabled Kubernetes uses agents that establish an outbound connection to Azure. Connected clusters can be inventoried in Azure and can use capabilities such as GitOps configuration, Azure Policy, Azure Monitor and Microsoft Defender for Containers. Microsoft states that Arc-enabled Kubernetes supports CNCF-certified Kubernetes distributions, including clusters running in datacenters and other public clouds.

What does Azure Arc cost?

Pricing was checked on August 27, 2026. Microsoft states that basic Azure Arc management for Arc-enabled servers and Kubernetes is offered at no additional Azure Arc charge. Costs can appear when organizations enable additional Azure services such as security, monitoring, update management, policy guest configuration or other paid capabilities.

For Arc-enabled Kubernetes, some configuration and GitOps capabilities use vCPU-based pricing after the included allowance described by Microsoft, while related services such as Azure Monitor for containers and Microsoft Defender for Containers have their own meters. Buyers should therefore estimate Arc as a control-plane layer plus the cost of each additional Azure management service they plan to use.

How does Azure Arc fit with Azure Policy, Monitor and Defender?

Azure Arc is often most useful when it becomes the connection layer for Azure management services rather than an inventory tool by itself. Arc-enabled resources can participate in Azure Policy governance, Azure Monitor observability and Microsoft Defender for Cloud security scenarios where the relevant integration is supported.

This can simplify operating models for organizations with resources spread across datacenters, edge sites and multiple clouds. It can also increase platform dependence because operational teams begin relying on Azure APIs, agents, identity, policy and monitoring for assets that are not hosted in Azure. Teams should decide which Azure services provide enough value to justify that dependency.

What are the main deployment and security considerations?

Arc-enabled servers are agent based. Organizations remain responsible for securing the servers, keeping the Connected Machine agent and extensions updated, protecting credentials used for onboarding and administration, and deciding which extensions and management features are allowed. Microsoft also documents data residency and regional considerations for Arc-enabled resources.

For Kubernetes, the connected cluster maintains an outbound connection to Azure through Arc agents. Teams should review network requirements, identity and RBAC design, extension permissions, GitOps controls and how Azure policies interact with cluster-level governance. Arc can make management more consistent, but it does not remove the need to secure each underlying environment.

How is Azure Arc different from migrating workloads to Azure?

Azure Arc is a management and service-extension approach, not a migration service. A connected server can continue running in another cloud or in a private datacenter while appearing as an Azure resource for supported management operations. A connected Kubernetes cluster can remain on its existing infrastructure while Azure provides selected governance and management capabilities.

Organizations that want to retire datacenter infrastructure or move application execution into Azure still need a migration plan and destination services such as Azure Virtual Machines, Azure Kubernetes Service, Azure App Service or other Azure products. Arc is better suited to workloads that must remain distributed or that will move gradually.

What are the limitations and tradeoffs?

Azure Arc capabilities vary by resource type, region and connected service. Not every Azure feature available to a native Azure resource is available to an Arc-enabled equivalent. Add-on services can introduce separate charges, agents and extensions create operational dependencies, and policy or monitoring configurations can become complex across large heterogeneous fleets.

Arc also does not eliminate the operational responsibility of the environment owner. Hardware, local networking, operating systems, Kubernetes distributions, storage and the availability of the underlying infrastructure remain the customer's responsibility outside Azure. Organizations should test the exact management capabilities they need before assuming Arc provides feature parity with native Azure resources.

Who should choose something else?

Organizations that run almost everything natively in Azure may not need Azure Arc for those resources because Azure already provides native management. Small teams with only a few external servers may find simpler local tooling easier to operate if they do not need centralized Azure governance or security integration.

Teams whose primary goal is application migration should evaluate Azure Migrate and the destination Azure services rather than treating Arc as a migration substitute. Organizations that want cloud-neutral management with minimal dependency on one provider should also compare multicloud management platforms before standardizing on Azure Arc.