Azure Arc
Azure Arc projects resources that live outside Azure — on-premises servers, Kubernetes clusters on any cloud, certain databases — into Azure Resource Manager, so they can be governed, monitored, and managed with the same tools as native Azure resources. An Arc-enabled server in your own datacenter appears in the portal and obeys Azure Policy as if it were an Azure VM.
The value is one control plane across a hybrid and multicloud estate. Instead of separate tooling for on-premises, AWS, and Azure, Arc extends Azure's governance, monitoring, and policy outward. It manages and governs those resources; it does not move or run them in Azure — the workload stays where it is.
Arc-Enabled Servers
Installing the Arc agent on a physical or virtual machine anywhere registers it in ARM as an Arc-enabled server. It then supports Azure Policy, Monitor, Defender for Cloud, extensions, and Update Manager — the same governance and security applied to native VMs, reaching machines Azure does not host. This is how an on-premises fleet inherits cloud governance.
Arc-Enabled Kubernetes
Any CNCF-conformant Kubernetes cluster — on-premises, on another cloud, at the edge — can be connected through Arc and then managed centrally: policy enforcement, monitoring, GitOps-based configuration, and Azure services deployed onto it. It brings a fleet of heterogeneous clusters under one management and compliance umbrella.
Arc-Enabled Data Services
Arc lets Azure SQL Managed Instance run on your own infrastructure while staying managed through Azure, for workloads that must keep data on-premises for latency or sovereignty but still want the managed-service experience and Azure billing. (Arc-enabled PostgreSQL was retired in 2025; for PostgreSQL, the managed path is Azure Database for PostgreSQL Flexible Server.)
Governance Extension
Once a resource is Arc-enabled, the governance you already use in Azure extends to it: Policy audits and enforces its configuration, Defender for Cloud assesses its posture, and Monitor collects its telemetry — all from the same dashboards. Arc's payoff is that hybrid resources stop being a separate, blind-spot estate and join the one you already govern.
- Expecting Arc to run or migrate workloads into Azure — it manages and governs resources in place; it does not move them.
- Onboarding servers to Arc but never applying Policy, Monitor, or Defender, so the projection adds no governance.
- Running separate, parallel tooling for on-premises and other clouds when Arc would unify them under Azure's control plane.
- Forgetting that Arc-enabled resources incur Azure costs for the management features (like Defender plans) you enable on them.
- Treating Arc-enabled Kubernetes as identical to AKS — Arc manages external clusters; it does not provision the cluster itself.
- Leaving the Arc agent un-maintained, so connectivity and the governance that depends on it lapse.
- Use Arc to bring on-premises and multicloud resources under Azure's governance, monitoring, and policy.
- Apply Azure Policy, Monitor, and Defender for Cloud to Arc-enabled resources so they inherit real governance, not just visibility.
- Consolidate hybrid management on Arc rather than running parallel per-environment tooling.
- Use Arc-enabled data services where data must stay on-premises but a managed experience is wanted.
- Account for the Azure costs of management features enabled on Arc resources.
- Keep the Arc agent maintained so connectivity and governance stay intact.
Knowledge Check
What does Azure Arc do with on-premises and multicloud resources?
- Projects them into Azure Resource Manager for governance, monitoring, and policy — in place, without moving them
- Lifts them into an Azure region and re-hosts each one as a native Azure virtual machine on Microsoft's own hardware
- Continuously replicates their data into an Azure region for disaster recovery
- Converts them into serverless functions that scale to zero when they sit idle
An Arc-enabled server is registered but gains no governance benefit. Why?
- No Azure Policy, Monitor, or Defender has been applied to it — registration only provides visibility
- Arc-enabled servers cannot have Azure Policy or guest configuration definitions assigned to them at all
- The server must be migrated into an Azure region before any governance applies
- Arc only supports Kubernetes clusters and cannot onboard standalone servers
How does Arc-enabled Kubernetes differ from AKS?
- Arc connects and manages existing external clusters; it does not provision the cluster as AKS does
- Arc-enabled Kubernetes is simply Microsoft's newer marketing name for the very same AKS managed service
- Arc can only manage Kubernetes clusters that are already running inside Azure
- Arc provisions and scales the worker nodes itself while AKS leaves that to you
You got correct