Defender for Servers + Azure Arc: Hybrid + Multicloud Onboarding
Extend Microsoft Defender for Cloud protections to on-premises servers and other clouds via Azure Arc — Defender for Servers plans, vulnerability scanning, EDR via Defender for Endpoint, and agentless VM scanning.
One Defender control plane for every server, anywhere
Azure Arc lets a non-Azure server — an on-prem VM, an AWS EC2 instance, a GCP Compute Engine VM, a bare-metal box in a datacenter — show up in Azure as if it were an Azure resource. Once it’s Arc-enabled, you can apply Azure Policy to it, deploy Azure VM extensions to it, monitor it with Azure Monitor, and — most importantly for SC-500 — protect it with Microsoft Defender for Cloud.
Microsoft Defender for Servers is the workload protection plan that covers VMs. It has two tiers: Plan 1 (Defender for Endpoint integration only) and Plan 2 (everything — JIT, vulnerability scanning, agentless disk scanning, file integrity monitoring, regulatory compliance, threat detection). Both plans work for Azure VMs AND for Arc-enabled servers anywhere.
The exam pattern: when a question says “hybrid” or “multicloud” servers, the answer is almost always Azure Arc + Defender for Servers Plan 2.
Azure Arc — the bridge
Azure Arc onboards a non-Azure server by installing the Azure Connected Machine agent (azcmagent). Once installed and registered against a Resource Group / Region / Subscription, the server appears as an Arc-enabled server in Azure.
Onboarding paths
| Source | Onboarding method |
|---|---|
| On-prem Windows/Linux VMs | Run azcmagent connect script (interactive) or service principal authentication for at-scale (use a managed-by-Azure service principal) |
| AWS EC2 instances | Defender for Cloud AWS connector auto-deploys Arc agent to selected EC2 instances when AWS Defender for Servers is enabled |
| GCP Compute VMs | Defender for Cloud GCP connector behaves similarly to AWS |
| VMware vSphere / Azure Stack HCI | First-class integrations install Arc agent at scale across the cluster |
| Existing Azure VMs | Not Arc — already Azure-native. Defender for Servers applies directly without Arc |
What Arc-enabled servers get
- Azure Policy including Azure Machine Configuration (in-guest) policies — same DSC v3 packages as on Azure VMs
- Azure Monitor via Data Collection Rules — logs and metrics flow into Log Analytics
- Defender for Cloud / Defender for Servers — covered below in detail
- Azure VM extensions — Microsoft Defender for Endpoint, Microsoft Sentinel, Azure Monitor agent, others
- Azure Update Manager — patch lifecycle for Windows + Linux across Azure + Arc
Defender for Servers Plan 1 vs Plan 2
| Capability | Plan 1 | Plan 2 |
|---|---|---|
| Microsoft Defender for Endpoint integration | ✓ | ✓ |
| MDE licence included | ✓ | ✓ |
| Just-in-time VM access (JIT) | ✗ | ✓ |
| Vulnerability assessment (Defender Vulnerability Management) | ✗ | ✓ |
| Agentless disk scanning | ✗ | ✓ |
| File integrity monitoring (FIM) | ✗ | ✓ |
| Regulatory compliance for servers | ✗ | ✓ |
| Network map | ✗ | ✓ |
| Adaptive application controls | ✗ | ✓ |
| Baseline configuration assessment | ✗ | ✓ |
| Pricing model | Per-server / month | Per-server / month (higher) |
When to pick which
- Plan 1 — Cost-sensitive coverage focused on EDR. You want every server licensed for MDE under the Defender wrapping (a competitive bundle for many orgs) without paying for the broader feature set.
- Plan 2 — Production, regulated, or threat-aware estates where you need JIT, vulnerability assessment, agentless scanning, file integrity monitoring. The SC-500 default answer when the question mentions any of these capabilities.
Vulnerability assessment
Defender for Servers Plan 2 includes Microsoft Defender Vulnerability Management (MDVM) for in-band vulnerability scanning. Two assessment surfaces:
- MDE-based agent scanning — MDE on the server periodically inventories software and reports against the MDVM catalogue. Surfaces in Defender for Cloud as recommendations and in MDVM’s portal.
- Agentless disk scanning — covered in the next section; complements agent-based by catching software on VMs where MDE is missing or unhealthy.
A legacy option for organisations still using Qualys integration was deprecated in favour of MDVM; the SC-500 right answer for new deployments is MDVM.
Endpoint Detection and Response (EDR)
Microsoft Defender for Endpoint (MDE) is the EDR. Defender for Servers automatically onboards covered VMs (Azure + Arc) to MDE — Windows Server 2012R2 and later, Linux distributions per the published matrix.
Once onboarded, the server appears in Microsoft Defender XDR alongside the rest of the org’s endpoints. EDR features include:
- Real-time behavioural detection (process injection, suspicious LOLBin use, encoded PowerShell, etc.)
- Live response (shell to the device for investigation)
- Automated investigation and response (AIR)
- Threat hunting via advanced hunting queries (KQL) across the device estate
- Defender XDR incident correlation across endpoint + identity + Office + cloud apps + (via Defender for Cloud connector) cloud workloads
Agentless scanning
Agentless scanning is the scan-without-installing-anything-in-guest pattern. Defender for Servers (Plan 2) and Defender CSPM include agentless scanning capabilities:
How it works
- Defender takes a snapshot of the VM’s disk (via Azure Storage for Azure VMs, via the multicloud connector for AWS EBS / GCP PD).
- The snapshot is mounted in a Defender-controlled environment (a Microsoft-managed compute environment specifically for this scan).
- Defender scans for: OS / installed-software vulnerabilities, secrets in plaintext (CSPM secret scanning), malware (Defender CSPM malware scanning), end-of-life software.
- The snapshot is destroyed; findings flow into Defender for Cloud recommendations and Defender CSPM attack-path analysis.
Why it matters
- VMs without MDE installed still get scanned. The MDE-installed coverage gap closes.
- Stopped/offline VMs can be scanned from their disks at any time.
- Multicloud VMs (AWS EC2, GCP) get the same scan coverage as Azure VMs.
- No in-guest performance impact.
Agentless scanning is enabled at the subscription level under Defender for Servers Plan 2 settings (and Defender CSPM settings for the broader CSPM scanning).
When to pick agent vs agentless (or both)
These complement, not compete:
- Agent-based (MDE) gives real-time behavioural detection, live response, and the EDR surface. Required for in-incident response and detection of in-progress attacks.
- Agentless scanning gives coverage of stopped/offline VMs, VMs where MDE isn’t installed or healthy, and multicloud disks where in-guest agent deployment is operationally harder. Required for posture completeness.
The exam pattern: when a question asks about detecting attacks in progress, the answer involves MDE. When a question asks about posture coverage — including stopped VMs, multicloud, finding plaintext secrets on disk — the answer involves agentless scanning. When both are listed as goals, the answer is “both, configured together”.
Scenario: Asha brings AWS into the Defender pipeline
Aurora Health Service runs a clinical workload on AWS EC2 (legacy, due to migrate to Azure but currently constrained). Asha needs the same Defender visibility she has on her Azure-native VMs.
- Defender for Cloud AWS connector: configure the AWS connector in Defender for Cloud, point at the AWS Organisation, enable the Servers offering. Defender provisions Azure Arc onboarding for the selected EC2 instances (and the necessary AWS IAM for snapshot operations).
- Defender for Servers Plan 2 enabled on the subscription that hosts the Arc-enabled-server objects projected from AWS. EC2 instances now show in Defender for Cloud alongside Azure VMs.
- MDE auto-onboarding: enabled in Defender for Servers settings. MDE deploys to the supported EC2 instances via the Arc-enabled-server extension mechanism.
- Agentless scanning enabled — gives Asha coverage on the EC2 instances even when MDE is unhealthy and across stopped instances.
- Vulnerability assessment powered by MDVM is now on across both Azure VMs and the projected EC2 instances; findings unified in Defender for Cloud.
- JIT enabled where applicable on the EC2 instances; AWS security-group changes are made on-request via the same JIT flow.
The result: one Defender control plane spanning ~120 Azure VMs and 38 AWS EC2 instances, with unified vulnerability reporting, EDR, agentless coverage of stopped instances, and JIT access. Aurora’s SOC sees one pane of glass instead of two.
Key terms
Knowledge check
Asha at Aurora Health Service needs Microsoft Defender for Cloud protection on 38 AWS EC2 instances alongside her Azure VMs — unified vulnerability reporting, EDR, agentless scanning. Which sequence is correct?
Ravi at Maple Genomics has 6 Azure VMs that occasionally need rapid scaling — they're stopped most of the time and powered up for genomic workload bursts. He needs vulnerability coverage on these VMs even when stopped. Which capability is required?
Esme at Northwind Bank is reviewing the Defender for Servers tier required for her production VMs. She needs: MDE EDR, JIT VM access, vulnerability assessment, file integrity monitoring. Which plan covers all four?
What’s next
Next: Defender for Containers — protecting Azure Kubernetes Service (AKS), Azure Container Registry (ACR), Azure Container Instances (ACI), and Azure Container Apps. The container-side complement to what we just covered for VMs.