Azure Arc is usually sold as a way to see your servers in the Azure portal, and that framing undersells it badly. What Arc actually does is extend Azure’s management plane onto machines that Azure does not host, wherever those machines sit: in your own rack, in a branch office, in another cloud, domain-joined or not. That makes it the first credible answer to a question most environments have been avoiding, which is how you govern a server consistently when the network and the directory no longer reach all of them. The control plane for that is free. The management that rides on top of it is metered. And which of the two you are paying for turns out to be decided less by what you switch on than by what your Windows Server licensing already entitles you to.
What Arc actually is
Strip away the marketing and Arc is two things working together. There is an agent you install on a server, and there is a projection of that server into Azure Resource Manager as a resource of its own. Once both exist, the machine is addressable by the same control plane that governs a native Azure virtual machine: it has a resource ID, it lives in a resource group and a subscription, it answers to Azure role-based access control, it can be targeted by Azure Policy, tagged, and queried at scale through Resource Graph, and it can receive extensions. The server itself has not moved and nothing about its workload has changed. What has changed is that it now has a management surface in Azure that did not exist before, and that surface is the whole point.
This is why Arc reads as a replacement for the domain rather than an addition to it. For thirty years the answer to “how do I configure, patch, and reach this server” was Active Directory and the machinery around it: Group Policy for settings, WSUS for updates, a jump box and domain credentials for access. Arc offers a different answer to each of those, delivered from the cloud and indifferent to whether the machine is domain-joined, workgroup, on-premises, or running in someone else’s cloud. It is not a lift of your servers into Azure. It is a lift of Azure’s management model down onto your servers wherever they already sit.
One correction to make early, because the framing trips people up. Arc is not only for servers that have left the domain. A fully domain-joined server is a first-class Arc candidate and often the most valuable one, because Arc manages its patching, configuration, and remote access from the cloud while it goes on being a domain member doing exactly what it always did. Nothing about onboarding asks the machine to give up its domain membership, and nothing about Arc requires you to plan an exit from Active Directory. Leaving the domain is one outcome Arc makes possible for some servers later; it has never been the entry requirement. Read the whole series with that separation in mind, because conflating the management plane with the identity plane is the single most common error in this space, and the capstone article ends by pulling the two apart deliberately.
Not the same thing as hybrid join
One clarification belongs up front, because the two ideas collide in almost every first conversation. Arc is not hybrid Entra join. Hybrid join is about a client device’s identity, teaching a Windows workstation to hold both an on-premises and a cloud identity so a user can sign in and satisfy Conditional Access. Arc is about a server’s management plane, giving a machine a resource identity in Azure so that policy, patching, and access can be driven from the cloud. They solve different problems for different audiences, they use different agents and different trust models, and a server that is Arc-connected is not thereby joined to anything. When someone asks whether Arc “joins the server to Entra,” the honest answer is that it does something adjacent but distinct, and conflating the two is the fastest way to design the wrong thing. The client story lives in the Intune Deployment Guide; this series is entirely about servers.
Who owns the machine now
Installing the Arc agent is a bigger decision than it looks, and it is worth being blunt about why. The agent carries an extension manager that runs as SYSTEM on Windows and root on Linux, which means anyone who can write an extension to the machine’s Azure resource can run arbitrary code on the server as its most privileged account. Arc onboarding is, in plain terms, a grant of remote code execution mediated by Azure role-based access control. The practical consequence is that the resource group your Arc machines live in becomes an important RBAC and operational scope rather than a filing convenience. The people with write access to it are effectively local administrators of every server inside it. Assigned narrowly, that scope limits administrative blast radius, though permissions granted at the subscription or management group still inherit into it, so it bounds administration rather than isolating it.
The cloud decides who may manage the server. The server itself decides what management is even possible. Both halves are real, and neither can be inferred from the other.
What keeps that from being reckless is that the authority is split. The cloud side governs who may manage the machine, through role assignments and policy scope. The machine side retains a local veto that Azure cannot override: an agent configuration that can restrict which extensions are allowed, disable the extension manager entirely, or run in a mode that permits only Microsoft-managed tooling. That local control is genuinely local. Nobody with Owner or even Global Administrator rights in the tenant can override it from Azure, and equally, nobody can read or attest it from Azure either. It is a real control and a real blind spot at the same time, which means if you care about it you have to enforce it the same way you would any other host setting, with configuration management, or it drifts quietly. Hold onto that authority split. It is the theme that runs under every article that follows.
The control plane is free. The management is not.
Here is the part that reorganizes how you should think about cost, because it inverts the usual assumption. The Arc control plane is free. Onboarding the agent, projecting the resource, organizing it into resource groups and subscriptions, applying tags, querying with Resource Graph, driving role-based access control, and running any Azure Policy that does not reach inside the guest all cost nothing. Even remote access through Arc, whether that is SSH, Run Command, or the Custom Script extension, is included at no charge. You can stand up an inventory of a thousand servers, governed and searchable, and pay Azure nothing for the privilege.
The money starts the moment you ask the plane to do something inside the operating system. Machine configuration, the service that audits and enforces settings in the guest, together with change tracking and inventory, meters at roughly six dollars per server per month. Azure Update Manager, the patching service, adds about five. Defender for Servers, Azure Monitor ingestion, and Extended Security Updates each carry their own line. A plainly managed server, patched and configured and nothing more, lands near eleven dollars a month before you have monitored a thing. None of this is hidden, but it is easy to miss that the free part is the projection and the paid part is the actual management, which is the reverse of how most people expect a platform to price.
What makes this an architectural question rather than a billing one is that your Windows Server licensing can waive most of it. If your servers carry active Software Assurance or subscription licenses and you attest to that, the management stack, patching, machine configuration, change tracking, and more, comes at no extra cost. Enabling Defender for Servers Plan 2 on the subscription folds patching and machine configuration in for free as well. Enrolling a legacy machine in Extended Security Updates through Arc does the same. The pattern is deliberate: Microsoft prices Arc so that the servers you are already paying to license are cheap to manage, and the ones you are not are the ones that meter. Your licensing posture, not your feature choices, sets the bill. That is the single most important thing to understand before you plan a deployment, and it is why the licensing article in this series is not an appendix but a load-bearing chapter.
The GPO replacement, and where it stops
It is fair to call Arc a path off Group Policy for servers, as long as you are honest about the seams. Azure Policy with machine configuration is the settings engine, capable of both auditing and enforcing state in the guest, and it is the closest thing to a GPO the cloud has produced. Update Manager is the patching engine, and it arrives just as Microsoft has declared WSUS deprecated, which is not a coincidence. SSH through Arc and Entra sign-in on the newest servers begin to retire the jump box. Taken together they cover a great deal of what the domain did for a server day to day.
They do not cover all of it, and pretending otherwise sets up a disappointment. Machine configuration governs machine-scope settings and has no user-side story. It enforces state on a cadence that reports compliance more slowly than a Group Policy refresh, and one of its modes will silently correct drift in a way that erases the evidence an auditor now expects to see. The domain still owns identity, Kerberos, and the file and print services that a server may exist to provide. Arc is a management plane, not a domain, and the useful question is not whether it replaces Active Directory but how much of your server management you can move onto it while the directory shrinks to the things only it can do. That is a decision, and this series ends on it deliberately.
Where we start
The series works outward from the agent, because the agent is the trust decision everything else depends on. The next article takes onboarding seriously as an architecture problem rather than an install step: what the agent is, what it grants, how you connect at scale without scattering secrets, and how the network path is changing underneath you. From there we build the management plane itself, policy and machine configuration, then patching, then the operations surface of extensions, monitoring, and remote access. After that comes the licensing reality in full, Extended Security Updates and pay-as-you-go and the waiver matrix, because the timing matters and the dates are close. Then the security attach, Defender for Servers delivered through Arc, and finally the decision this all builds toward: what you move onto Arc, what stays on the domain, and how you tell the difference.
Azure Arc
Next: [ARC 2] Onboarding: The Agent Is a Trust Decision ›
