Azure Arc is a bridge that extends Azure’s management, security and services to resources that live outside Azure.

The problem it solves

Few organizations keep everything in one place. They have servers in their own data centers, workloads in other public clouds, small computers in shops and factories, and applications spread across all of them. Each location tends to have its own tools for inventory, patching, security and monitoring. The result is a patchwork where nobody has a complete picture, rules are applied unevenly and the same job is done in five different ways.

Azure Arc solves this by letting those outside resources appear inside Azure as if they were native. A server in a data center gets an entry in the Azure portal, can be tagged, searched, secured, patched and monitored with Azure tools, and can be governed by the same policies as an Azure virtual machine. The resource does not move; only its management does.

What Arc is not

Azure Arc is not a migration tool, and it does not move your workloads into Azure. It is also not a separate cloud. It is a management layer. Your servers keep running where they are, on the hardware you own or rent, while Arc adds a connection that lets Azure see and manage them. Some Arc offerings also let you run selected Azure services, such as certain databases, on your own infrastructure.

Where the name comes from

The word Arc suggests a link spanning two places. Over time, Microsoft has expanded the family to include servers, Kubernetes, data services and virtual infrastructure, so Azure Arc is better thought of as an umbrella than as a single product.

Understanding why organizations end up spread across many places explains what Arc is trying to repair.

Why resources stay outside Azure

The cost of fragmentation

Spread-out estates cause real problems. Inventories are incomplete, so forgotten servers remain unpatched. Security rules are enforced in some places and not others. Staff must learn many consoles. Audits take weeks because evidence is scattered. Each of these problems is solvable alone, but solving them separately for every location multiplies the effort.

flowchart TD
    subgraph BEFORE["Without Arc: separate tools per location"]
        A1["On-premises tools"]
        A2["Other cloud tools"]
        A3["Edge site scripts"]
        A4["Azure tools"]
    end
    subgraph AFTER["With Arc: one control plane"]
        B0["Azure control plane: portal, policy, monitoring, security"] --> B1["On-premises servers and clusters"]
        B0 --> B2["Other cloud servers and clusters"]
        B0 --> B3["Edge sites"]
        B0 --> B4["Azure resources"]
    end
        

The central trick of Arc is to give every outside resource a representation inside Azure, connected by a small agent.

Azure Resource Manager projection

Everything in Azure is managed through Azure Resource Manager, the service that creates, updates and tracks resources and applies permissions and policy. Arc adds outside resources to this system. When a server is connected, a matching resource appears in Azure Resource Manager, carrying the server’s name, location, properties and tags. This is sometimes called projecting the resource into Azure. Because it is now a normal Azure resource, it can be organized into resource groups, governed by role-based access control, searched with resource queries and targeted by policy.

The agent and the outbound connection

A small piece of software, called an agent, runs on the outside resource. It connects outward to Azure over a secure channel, reports the resource’s state and receives instructions. The connection is initiated from your side, so you normally do not need to open any inbound ports to Azure. The agent also gives the resource an identity in Azure, which allows it to use Azure services securely without storing passwords.

flowchart LR
    subgraph OUT["Outside Azure: your data center, another cloud or the edge"]
        SRV["Server, cluster or database"]
        AG["Arc agent"]
        SRV --- AG
    end
    AG -->|Outbound secure connection| ARM["Azure Resource Manager"]
    ARM --> POR["Portal, queries and tags"]
    ARM --> POL["Policy and access control"]
    ARM --> SVC["Azure services: monitoring, security, updates"]
    SVC -.->|Instructions through the agent| AG
        

Extensions deliver capabilities

The agent itself is small. Most capabilities are delivered as extensions, which are add-on packages that Azure installs and updates on the resource through the agent. There is an extension for monitoring, one for security protection, one for running scripts, one for update management and many more. This keeps the base lightweight and lets you add only what you need.

Arc covers several kinds of resources, and each has its own version of the same idea.

How the pieces relate

Servers are where most organizations begin, and the idea is simple: install a small agent and the machine joins your Azure estate.

The Connected Machine agent

The agent supports Windows and Linux, on physical hardware and virtual machines, in your own data centers, in other clouds and at the edge. Once installed and registered, the server appears in Azure as an Arc-enabled server resource, placed in a subscription and resource group that you choose. It gets a managed identity of its own, and it begins reporting basic information such as its operating system, name and status.

What you gain immediately

Operating systems and prerequisites

The agent supports a wide range of modern Windows Server and Linux distributions, and the list of supported versions is documented and changes as new releases appear. Very old operating systems may not be supported. The machine needs outbound network access to Azure endpoints over the standard secure web port, and enough permissions on the machine to install the agent.

Connecting one server by hand is easy; connecting thousands needs a repeatable, safe process.

Ways to onboard

A repeatable rollout

The real value of connecting servers is the set of Azure services that can then manage them.

sequenceDiagram
    participant AM as Azure Update Manager
    participant ARC as Arc control plane
    participant AG as Arc agent on server
    participant SV as On-premises server
    AM->>ARC: Request update assessment for tagged servers
    ARC->>AG: Pass assessment instruction
    AG->>SV: Check for missing updates
    SV-->>AG: List of missing updates
    AG-->>AM: Report results to Azure
    AM->>ARC: Maintenance window starts
    ARC->>AG: Install approved updates
    AG-->>AM: Report success and any restart needed
        

Policy turns your standards into rules that are checked, and sometimes enforced, across every connected resource.

Azure Policy on Arc resources

Azure Policy evaluates resources against rules, such as requiring certain tags or approved locations, and reports which ones comply. Because Arc resources are Azure resources, the same rules apply. A policy can also deploy missing pieces automatically. For example, it can install the monitoring extension on every Arc-enabled server that does not have it, so new servers are covered without anyone remembering to configure them.

Settings inside the machine

Standard policy looks at the Azure resource itself. To check what is inside the operating system, such as which software is installed, whether a service is running or whether password rules are set, Azure uses Azure Machine Configuration, which was previously called guest configuration. It runs checks on the machine through an extension and reports back, and in some cases it can correct the setting. This is how consistent security baselines are applied to servers in all locations.

flowchart TD
    STD["Organization standard: servers must be monitored and meet a security baseline"] --> POL["Azure Policy assignment at management group"]
    POL --> E1["Deploy monitoring extension to servers missing it"]
    POL --> E2["Deploy Machine Configuration extension"]
    E2 --> CHK["Check settings inside the operating system"]
    CHK --> REP["Compliance report in Azure"]
    E1 --> REP
        

Policy design tips

Many organizations run Kubernetes clusters in several places, and Arc brings them under one management roof.

Connecting a cluster

Any Kubernetes cluster that follows the common community standards can be connected, whether it runs in your data center, in another cloud or on edge hardware. Connecting installs a small set of agents inside the cluster, in their own namespace. These agents reach out to Azure, so the cluster appears as an Arc-enabled Kubernetes resource and can receive configuration and extensions.

What it enables

Identity for workloads

Applications running in Arc-enabled clusters often need to call Azure services, such as a key vault or a storage account. Rather than storing secrets in the cluster, modern approaches let workloads use federated identities, in which the cluster issues a token that Azure trusts for a defined purpose. This reduces secrets and brings Azure-style access control to workloads running elsewhere. Check the current support for this feature in your cluster version.

GitOps makes a Git repository the single place that describes how clusters should look, and lets the clusters pull their own instructions.

The idea

In GitOps, the desired state of a cluster, including its applications and settings, is stored as files in a Git repository. An agent in each cluster watches the repository and continuously applies what it finds. If someone changes a setting directly on the cluster, the agent notices the difference and puts it back. Every change to the desired state is a change in Git, which means it is reviewed, versioned and reversible.

flowchart LR
    DEV["Engineer proposes a change in Git"] --> PR["Pull request and review"]
    PR --> REPO["Approved configuration in Git repository"]
    REPO -->|Cluster pulls changes| F1["Cluster A: data center"]
    REPO -->|Cluster pulls changes| F2["Cluster B: other cloud"]
    REPO -->|Cluster pulls changes| F3["Cluster C: edge site"]
    F1 --> DR["Agent detects and corrects drift"]
    F2 --> DR
    F3 --> DR
        

Why the pull model suits Arc

Clusters in remote or restricted networks often cannot accept inbound connections. In a pull model, each cluster reaches out to the repository, so no inbound ports are needed. It also scales naturally: adding a new cluster simply means pointing it at the repository. Azure Arc provides this using the widely adopted Flux tooling, with configuration objects managed from Azure.

Layers of configuration

Databases are among the most valuable and most regulated assets, and Arc offers ways to manage them in place and to run Azure data services anywhere.

SQL Server enabled by Azure Arc

When the Arc agent is installed on a machine that hosts SQL Server, a SQL Server extension can discover each instance and database and register them as Azure resources. This gives a central inventory of SQL Server across the estate, with version, edition and configuration details. Further capabilities build on that foundation.

Arc-enabled data services

A different offering lets you run certain Azure data services, such as a managed SQL instance, on your own Kubernetes infrastructure. A data controller runs in the cluster and coordinates provisioning, monitoring and updates, while Azure provides the management experience. This suits organizations that want cloud-style database operations, such as fast provisioning and automatic updates, in places where the data must remain. The set of available services and their maturity have changed over time, so verify what is currently supported.

Arc can manage not only individual servers but also the platforms that host them, so virtual machines can be handled from Azure.

The Arc resource bridge

For virtualization platforms such as VMware vSphere and System Center Virtual Machine Manager, Arc uses a lightweight appliance called the resource bridge. It runs inside your environment and connects the platform to Azure. Once the platform is connected, its virtual machines can be discovered and shown in Azure, and teams can perform actions such as starting, stopping and creating machines through the Azure portal and tools.

flowchart LR
    AZ["Azure portal, templates and policy"] --> ARM["Azure Resource Manager"]
    ARM --> CL["Custom location"]
    CL --> RB["Arc resource bridge appliance"]
    RB --> VC["vCenter or System Center VMM"]
    VC --> V1["Virtual machine 1"]
    VC --> V2["Virtual machine 2"]
    VC --> V3["Virtual machine 3"]
        

Custom locations

A custom location is a named place in Azure that represents a target in your own environment, such as a cluster or a virtualization platform. It lets people deploy resources there using the same Azure tools and permissions as for regular regions. In effect, your data center becomes a location option in the Azure portal.

Azure Local

Azure Local, formerly called Azure Stack HCI, is a hybrid infrastructure solution that runs on validated hardware in your own location and is managed through Azure Arc. It brings virtualization, storage and networking together, with Azure as the management layer, and is used for edge sites, branch offices and data centers that need local compute with cloud-style management. Details of editions, hardware and connectivity options evolve, so consult the current documentation and hardware catalogue.

Beyond management, Arc can host selected Azure services on infrastructure you control.

The Kubernetes foundation

The usual approach is to connect a Kubernetes cluster to Arc, install a cluster extension that carries the service, and create a custom location that points to that cluster. After that, you can deploy the Azure service to the custom location using the same portal and templates you would use for a normal Azure region. The service runs on your hardware, while its lifecycle and management come from Azure.

Why choose this

Arc depends on the connection back to Azure, so the network design deserves early attention.

Outbound only

The agent opens outbound connections to Azure over the standard secure web port. You do not need to open inbound ports from the internet for Arc to manage a machine, which is a major security advantage. You do need to allow the required Azure endpoints through your firewalls, and endpoint lists are published and updated, so keep them in your network change process.

Connectivity options

flowchart LR
    S1["Server in data center"] --> FW["Firewall or proxy: outbound only"]
    S2["Server in another cloud"] --> FW2["Cloud network egress"]
    S3["Edge site device"] --> FW3["Site internet link"]
    FW --> AZ["Azure Arc service endpoints"]
    FW2 --> AZ
    FW3 --> AZ
    PL["Private link over VPN or ExpressRoute"] -.-> AZ
    S1 -.-> PL
        

Handling disconnections

Machines at the edge may lose connectivity for days or weeks. Connected machines keep running normally, but they cannot receive management actions or report health. If an agent stays disconnected for too long, its identity credential can expire, and the machine shows an expired status that requires reconnecting. Plan for how long your sites might be offline, and confirm the current limits.

Because Arc can act on servers and clusters everywhere, its own security must be taken very seriously.

What an attacker would want

Anyone who can control the Arc management plane can potentially run commands on every connected machine. Extensions can execute scripts and install software with high privileges. So the permissions to manage Arc resources and extensions are effectively permissions to run code on those servers. Treating them as highly sensitive is the single most important security idea for Arc.

Separation of duties

Split roles so that one person cannot both create a dangerous extension and approve its use. Server owners may retain the ability to restrict what the agent may do, and central teams manage the standard set. For highly sensitive systems, require approval for any new extension or script that targets them.

Once resources are in Azure, the usual organizing tools make a large, scattered estate understandable.

Structure and naming

Plan how Arc resources will be placed. Common approaches group them by environment, by application, by business unit or by site. Resource groups are the basic container and a scope for permissions and policy. Management groups sit above subscriptions and allow rules to apply across many of them. Consistent naming and a required set of tags, such as owner, environment, site and cost centre, make everything easier to search and to charge back.

Asking questions with Resource Graph

Azure Resource Graph lets you query resource properties across subscriptions very quickly. With Arc resources in the same system, you can ask questions that span everything: which servers run an outdated operating system, which machines in which sites have not reported in a week, which SQL Server instances are of a certain edition, or which clusters run an unsupported Kubernetes version. These queries turn inventory into insight.

Arc brings its own components to run and maintain, and keeping them healthy is part of the job.

Agent states

stateDiagram-v2
    [*] --> Connecting
    Connecting --> Connected: Registration succeeds
    Connecting --> Failed: Network or permission problem
    Connected --> Disconnected: Agent stops reporting
    Disconnected --> Connected: Connection restored in time
    Disconnected --> Expired: Offline too long
    Expired --> Connected: Agent reconnected and re-registered
    Connected --> Deleted: Resource removed
    Failed --> Connecting: Problem fixed and retry
        

A healthy machine shows as connected and reports regular heartbeats. If the agent stops reporting, the machine is shown as disconnected. If it stays offline for longer than the allowed period, the machine’s identity expires, and it must be reconnected. Watching for machines that change state, and finding out why, is a core operational task.

Upgrades

Troubleshooting approach

The basic connection is inexpensive, but the services you add on top determine most of the bill.

What is free and what is not

Many control plane features of Arc, such as the resource inventory, tagging, role-based access control, queries and basic policy assignment, are generally offered without a separate charge for the connection itself. Charges arise from the Azure services you use through Arc, for example security plans, monitoring data ingestion, update management, extended security updates and certain data services, and from optional subscription offers for Windows Server management benefits. Prices and inclusions change, so confirm current details in the pricing pages.

Controlling spending

A staged path keeps risk and effort manageable and shows value early.

Teams that succeed with Arc share a few habits, and teams that struggle share a few traps.

Patterns worth adopting

Traps to avoid

A short checklist, followed by examples of the ideas working together.

Real-world scenarios

flowchart TD
    CEN["Central platform team in Azure"] --> LZ["Landing zone: management groups, policies, tags, roles"]
    LZ --> S1["Data center servers: inventory, patching, security"]
    LZ --> S2["Other cloud servers: inventory, patching, security"]
    LZ --> K1["Store clusters: GitOps and policy"]
    LZ --> DB["SQL Server instances: assessment and protection"]
    S1 --> DASH["Unified dashboards, alerts and compliance reports"]
    S2 --> DASH
    K1 --> DASH
    DB --> DASH
        

It is a way to manage resources outside Azure, such as servers, Kubernetes clusters and databases in your data centers or other clouds, using Azure tools, security and governance, without moving them into Azure.

No. Workloads and data stay where they are. Azure holds management information about the resources, and your data only reaches Azure if you choose services such as log collection that send it there.

Normally no. The agent makes outbound connections to Azure over the standard secure web port. You must allow the required Azure endpoints, or use a proxy or private connectivity.

It keeps running normally, but Azure cannot manage it or receive its health reports. If it stays disconnected beyond the allowed period, its identity expires and it must be reconnected, so plan for expected offline durations.

No. Arc is the management layer that can connect many kinds of resources. Azure Local is a hybrid infrastructure solution on validated hardware that is itself managed through Arc.

No. It manages resources in place. It can help with migration by providing inventory and assessments, but moving workloads to Azure uses migration tools.

Core connection and inventory features are generally free, while the Azure services you enable on top, such as security, monitoring, update management and extended updates, have their own prices. Check current pricing and model your estate before rollout.

Use a narrowly scoped onboarding identity with scripts, or existing tools such as group policy, configuration management or infrastructure-as-code. Pilot first and onboard in waves, applying tags and resource groups during the process.

It means cluster configuration is stored in a Git repository and agents in each cluster continuously pull and apply it, correcting any drift. Changes are made through reviewed commits instead of direct edits.

Excessive permissions over the management plane and extensions, since controlling them can mean running code on every connected machine. Use least privilege, local agent restrictions, protected onboarding credentials and audit logging.

Design a simple landing zone with naming and tags, connect a small pilot group of servers, enable inventory and monitoring, then add patching and security for the most important machines before expanding.

Azure Arc extends Azure’s control plane to servers, Kubernetes clusters, databases and virtual infrastructure that live in data centers, other clouds and the edge. A small agent connects each resource outward to Azure, where it appears as a normal resource that can be tagged, governed, monitored, patched and secured with the same tools used for native Azure resources. Policy, extensions and GitOps turn standards into automatic, consistent practice, while selected Azure services can even run on your own hardware. Success depends on preparation and ownership: a clear landing zone, narrowly scoped permissions, staged enforcement, healthy agents and an honest view of cost. Arc offerings and their maturity change often, so confirm current features and prices before you design.