Everything in this series assumes resources live in Azure, but every real estate has the other machines: the datacenter VMs that will never migrate, the VMware farm mid transition, the EC2 instances from an acquisition. Azure Arc’s proposition is simple: project those machines into Azure Resource Manager so the governance machinery this series has built, policy, RBAC, monitoring, Defender, applies to them identically.

What Connecting Actually Means

The connected machine agent installs on Windows or Linux, authenticates outbound over 443 (through your proxy or private endpoints via Private Link scopes, no inbound holes), and the machine appears as an ARM resource with an ID, a location in a resource group, tags, and a managed identity. That last item is quietly the biggest deal: an on premises server with a managed identity can fetch secrets from Key Vault and authenticate to Azure services with no stored credentials, extending the no secrets doctrine of this series to machines that will never run in Azure. From there the extension framework carries the platform tooling: Azure Monitor agent with data collection rules, custom script, dependency agent, and update management, deployed and versioned through ARM like any cloud VM.

az connectedmachine extension create \
  --machine-name dc1-app-07 \
  --resource-group rg-arc-servers \
  --name AzureMonitorLinuxAgent \
  --publisher Microsoft.Azure.Monitor \
  --type AzureMonitorLinuxAgent \
  --enable-auto-upgrade true

Governance Without Asterisks

Because Arc machines are ARM resources, the earlier posts apply verbatim. Azure Policy audits and enforces on them, including guest configuration policies that assert in OS settings, password policy, TLS versions, installed agents, across the hybrid fleet from one assignment at the management group. Defender for Servers covers them with the same plans and the same secure score. RBAC scopes who can manage which machines through the same Entra groups and PIM. Update Manager patches Windows and Linux on schedules with maintenance windows, cloud and Arc machines in one view, which for most organizations replaces a WSUS deployment and a spreadsheet. And inventory stops being a quarterly discovery project: Resource Graph queries return the entire fleet, cloud and datacenter and other clouds, with tags and compliance state, in milliseconds. The honest boundary: Arc governs and observes; it does not migrate, and it does not make a 2012 server less legacy. It makes the legacy visible and accountable, which is the prerequisite for every improvement.

Beyond Servers, and the Money Angle

Two siblings deserve a mention now and fuller posts later. Arc enabled Kubernetes projects any conformant cluster into Azure for policy, GitOps configuration, and monitoring, the multicloud cluster governance story. Arc enabled data services run SQL Managed Instance and PostgreSQL as containers on your infrastructure with cloud style management. Meanwhile SQL Server enabled by Arc gives existing SQL estates best practice assessment, Defender coverage, and, notably, pay as you go licensing as an alternative to the EA true up dance. The licensing angles matter for funding the project: Extended Security Updates for aging Windows Server delivered free through Arc enrollment have justified entire Arc rollouts on their own, and Azure Hybrid Benefit threads through the pricing. My deployment advice is unglamorous: onboard at scale with a service principal and your configuration management, tag honestly (owner, environment, datacenter), start with monitoring plus inventory plus Defender in audit, and let the first month of visibility findings set the roadmap. The fleet you can see is the fleet you can defend.

Cheers
Osama