Extending Azure management beyond Azure with Arc

Hey there! Let’s talk about a question I get a lot from customers who are only halfway into Azure: what do you do with the servers that are never moving? The VMware cluster in the factory, the SQL box in a colo that has three years left on its hardware lease, the odd Hyper-V host somebody’s still keeping alive. You’re exploring Azure Policy, you like what Defender for Cloud does, and then you hit that machine and none of it applies, because it’s not in Azure.

That’s the gap Arc closes. Not by moving the machine. By projecting it into Azure as a resource, so the same management plane you already use for your cloud VMs reaches machines that are staying exactly where they are.

How it actually connects

Arc’s core piece is the Connected Machine agent, a small service you install on the on-premises or other-cloud server. Once it’s talking to Azure, that server shows up in the portal as a proper Arc-enabled server resource, alongside your regular VMs. It gets a resource ID, a resource group, tags, RBAC, the works. It genuinely feels like just another VM in your subscription, except Azure never touches the underlying compute.

For anything beyond individual machines, there’s the Azure Arc resource bridge, a small appliance (it runs as a VM itself) that sits in your VMware, Hyper-V or SCVMM environment and projects the whole virtualization layer into Azure. That’s what lets you provision new VMs on VMware through Azure APIs, or manage AKS running on your own hardware the same way you’d manage AKS in the cloud. I really love how this bit works, once the bridge is up, that whole environment stops being a black box to your Azure tooling.

There’s also Arc-enabled SQL Server and Arc-enabled Kubernetes, but the pattern is the same everywhere: an agent or a bridge, a resource identity in Azure, and from that point on, the resource behaves like it’s part of your Azure estate for management purposes.

What Arc costs you, and what it doesn’t

Registering a server with Arc is free. That part surprises people every time I bring it up. What you pay for is what you attach to it once it’s connected: Defender for Cloud’s server plan, Azure Monitor ingestion if you’re sending logs, Update Manager if you’re patching through it, Automanage if you’re using the machine configuration baseline. Same billing model as if that workload were sitting natively in Azure.

A couple of months back, I added Arc across a customer’s colo estate purely to get Defender for Cloud coverage on servers Azure Security Center couldn’t see at all. The Arc registration itself didn’t move the invoice. The Defender plan did, but that’s the same cost they’d have paid for equivalent protection on an Azure VM, they just hadn’t had the option before.

The approach that actually works

Don’t try to onboard everything in one push. I go environment by environment: pick one site or one cluster, get the agents or the resource bridge deployed, confirm the resources land correctly in Azure with the right resource group and tags, then validate one policy and one Defender scan against it before touching the next site. Scripted at scale (Arc has a bulk onboarding script for exactly this) it’s fast once you trust the process, but the first environment is where you find the firewall rule nobody documented or the proxy that needs an exception for the agent’s outbound endpoints.

Managing it day to day

This is honestly the part that makes Arc worth the setup. Once machines are connected:

• Azure Policy applies to them the same way it applies to native Azure resources, including guest configuration policies that check settings inside the OS, not just the resource metadata.
• Update Manager gives you one patching view across cloud and on-premises instead of a separate WSUS or SCCM story for the servers that aren’t in Azure.
• Run Command and extensions let you push scripts or install the Log Analytics agent, antivirus, whatever, from the same portal blade you’d use on a cloud VM.
• Azure Monitor and VM insights collect the same performance and log data you’d get natively, so on-prem stops being the place your dashboards go quiet.

The other reason people actually reach for this: ESU

If you’ve got Windows Server 2012 or 2012 R2 still running somewhere, this is probably the part you care about most. Both went out of mainstream support a while back, and running an unpatched OS in production isn’t a real option, but ripping and replacing that box on a deadline usually isn’t either.

Extended Security Updates through Arc is how I handle that gap now. You enroll the Arc-enabled server for ESU directly in the Azure portal, and it’s billed per core, monthly, through your Azure subscription, no separate volume licensing agreement, no calling around for a special SKU. Patches then show up through Update Manager, same pane you’re already using for everything else connected via Arc.

The part that actually saves time: you’re not managing a second patching process for the machines that need ESU. They’re already Arc-enabled for policy and monitoring, so turning on ESU coverage is one more thing on a resource you’re already looking at, not a separate project with its own tooling. I’ve used this to buy a customer another year on a legacy SQL Server 2012 box while the actual migration got scoped properly, instead of them rushing a risky cutover just to stay patched.

Worth being upfront about the trade-off here too: ESU is a bridge, not a destination. It buys time, it doesn’t buy you out of eventually moving off an OS that’s aged out. But if the real migration is 2012 R2, and it’s twelve months out, Arc-based ESU is the difference between staying patched during that window or quietly hoping nothing gets exploited in the meantime.

Governance, and why it’s the actual point

Tags, RBAC and Azure Policy are what turn a pile of connected servers into something you can actually govern, not just observe. A policy that enforces a tag or requires Defender coverage applies across your whole estate, cloud and on-prem, in one assignment. That’s a single governance model instead of two, and honestly, two is where most of the drift I see in hybrid environments comes from, one ruleset for the cloud stuff everyone remembers to update, and whatever the on-prem servers happened to have configured three years ago.

Arc doesn’t fix your servers or your network. It doesn’t replace a real migration if migration is actually the goal. What it does is put every machine you own inside one consistent management surface, so “it’s not in Azure” stops being an excuse for a server going unpatched or unmonitored.

If you’ve got infrastructure that isn’t moving to Azure anytime soon, go register one server with Arc this week and see it show up in the portal next to your cloud VMs. It’s a genuinely satisfying moment the first time you see it. Happy coding!