Microsoft Defender for Cloud, in depth: plans, data collection, posture, alerts and rollout as code

Plans: what you are actually turning on

Defender for Cloud is one service with a free tier and a set of paid plans, each switched on per subscription (or per AWS account or GCP project through a connector). The plan names below are as Microsoft documents them at the time of writing; pricing changes often, so check the pricing page rather than any number you read in an article.

Two structural points follow. Posture is mostly agentless, so the free tier gives value on day one. Threat detection is per plan and per resource type, so coverage is exactly what you enabled, and an unprotected subscription created last week is invisible to it until you close that gap. Microsoft is also bringing Defender for Cloud into the unified Microsoft Defender portal; at the time of writing that move is partial, so some features live in both portals and some in only one.

How data gets in

Data arrives through four channels. Configuration reads: in Azure, the security policy is an Azure Policy initiative, and each policy evaluation becomes an assessment; in AWS and GCP, the connector deploys a CloudFormation stack or a set of service accounts that grant Defender read access, and Defender evaluates the same benchmark against cloud APIs. Agentless scanning: for VMs and EC2 or GCE instances, Defender snapshots disks and scans them out of band for software inventory, vulnerabilities, secrets and malware, without touching the running machine. Sensors: Defender for Endpoint on servers, and a Defender sensor deployed into Kubernetes clusters, provide process-level runtime signals. Service logs: management-plane activity, storage and database data-plane telemetry, DNS queries and AI service traffic feed the per-service detections.

Posture findings land as assessments (shown as recommendations) with a status of Healthy, Unhealthy or NotApplicable per resource. Defender CSPM also loads resources, identities, network exposure, vulnerabilities and sensitive-data findings into a cloud security graph, which is what powers attack paths: chains such as internet-exposed VM, with a critical vulnerability, with a managed identity that can read a storage account holding sensitive data. Runtime detections land as alerts with severity, MITRE ATT&CK tactics and affected entities, and related alerts are correlated into incidents.

Posture: benchmark, score, owners and exemptions

The default standard is the Microsoft cloud security benchmark (MCSB), which maps controls to Azure, AWS and GCP checks. You can add regulatory standards (with Defender CSPM) and write custom recommendations, in Azure Policy for Azure resources or in KQL against the graph for multicloud ones.

The secure score summarises posture: recommendations are grouped into controls, each worth a maximum number of points, and you earn points as the share of healthy resources in the control rises. Microsoft has been introducing a risk-based score in the Defender portal, so check which model your tenant shows before you set targets. Either way, treat score as a trend, not a goal: a team can raise it by exempting things.

Governance rules assign owners and due dates to recommendations automatically, based on resource tags or scope, and track overdue items. Exemptions mark a recommendation as mitigated by other means or as an accepted risk, for a scope and an expiry. Use both: without owners, recommendations sit in a queue nobody owns; without exemptions that expire, the queue fills with false positives and people stop reading it.

Worked example: rolling out across a landing zone

Take a typical landing zone: a management group with forty subscriptions, a handful of AWS accounts, a SOC on a SIEM. The rollout below is in code so new subscriptions inherit it.

1. Enable plans. For one subscription, the Azure CLI sets plan tier and sub-plan; the names are the resource types the API uses, such as VirtualMachines for Defender for Servers and CloudPosture for Defender CSPM.

az account set --subscription "$SUB"
az security pricing create -n CloudPosture --tier standard \
    --extensions name=AgentlessVmScanning isEnabled=True \
    --extensions name=SensitiveDataDiscovery isEnabled=True
az security pricing create -n VirtualMachines --tier standard --subplan P2
az security pricing list -o table          # verify what is actually on

At management-group scope, assign the built-in Azure Policy definitions that configure Defender plans with DeployIfNotExists, so every new subscription is enrolled automatically, and alert on policy non-compliance. Infrastructure-as-code tools expose the same setting, for example the azurerm provider's subscription pricing resource with a resource type and sub-plan.

2. Connect AWS. Create an AWS connector at the organisation's management account, choose the plans to apply, and deploy the CloudFormation template it generates, which creates the IAM roles Defender assumes. Prefer organisation-level onboarding so new accounts are discovered.

3. Query posture across everything. Assessments, scores and alerts are exposed in Azure Resource Graph's securityresources table, so one query spans every subscription you can read. Unhealthy high-severity recommendations by name:

securityresources
| where type == 'microsoft.security/assessments'
| extend recommendation = tostring(properties.displayName),
         state = tostring(properties.status.code),
         severity = tostring(properties.metadata.severity),
         source = tostring(properties.resourceDetails.Source)
| where state == 'Unhealthy' and severity == 'High'
| summarize resources = count() by recommendation, source
| order by resources desc

Score by control, to see where points are lost:

securityresources
| where type == 'microsoft.security/securescores/securescorecontrols'
| extend control = tostring(properties.displayName),
         current = todouble(properties.score.current),
         max = todouble(properties.definition.properties.maxScore),
         unhealthy = toint(properties.unhealthyResourceCount)
| summarize lost = sum(max - current), unhealthy = sum(unhealthy) by control
| order by lost desc

Run these with az graph query -q (resource-graph extension) in a scheduled job and push the result to your dashboard, so posture is reviewed weekly rather than when someone opens the portal.

4. Route alerts. Turn on continuous export of alerts and recommendations to a Log Analytics workspace or Event Hubs, or use the Defender XDR integration if your SOC lives there. Map severities to on-call policy; high-severity alerts on production should page. The SIEM-side design is covered in SIEM in practice.

5. Automate the boring fixes. Workflow automation triggers a Logic App on a recommendation or alert, for example to open a ticket with the resource owner's tag, or to quarantine a storage blob flagged by malware scanning.

6. Prove detection end to end. A pipeline that has never carried an alert is untested. The security alerts page can generate sample alerts per plan; use them to confirm that export, SIEM rules, paging and automation all fire, and that the alert lands with the right subscription and owner attached. On a test server, a harmless EICAR test file exercises the Defender for Endpoint path the same way. Repeat the drill after any change to export settings, workspaces or on-call routing, and record the time from alert creation to page; that number is the one your incident response depends on, and it is invisible until you measure it.

Operating it without drowning

A few rules separate useful deployments from noisy ones.

• Triage by attack path, not by count. Fix the recommendations that sit on attack paths to sensitive data first. A thousand unhealthy low-severity findings on isolated dev resources matter less than one exposed VM with a reachable identity.
• Fix at the source. Recommendations recur when the IaC module that created the resource is wrong. Use the DevOps connectors to surface IaC misconfigurations in pull requests, and fix templates, not instances.
• Tune alerts with suppression rules, and review them. Suppress known-benign patterns (a vulnerability scanner that trips port-scan alerts) with a scoped rule and an owner, and expire rules quarterly.
• Watch identity. Many attack paths run through over-privileged managed identities and cross-cloud roles; pair Defender findings with the least-privilege practices in cloud IAM.
• Control cost deliberately. Plans bill per protected resource, so enable heavy plans where the data or exposure justifies them, and check the plan settings on new subscriptions rather than assuming defaults.

Failure modes

• Coverage gaps. A new subscription or AWS account is created outside the policy scope and has only the free tier. Detect by comparing subscription list to az security pricing list output per subscription.
• Connector drift. Someone deletes or edits the AWS IAM role and multicloud findings silently go stale. Alert on connector health and on assessments whose timestamps stop advancing.
• Sensor not running. Containers runtime detection depends on the cluster sensor; servers depend on Defender for Endpoint onboarding. Track sensor coverage as its own recommendation.
• Exemptions that never expire. The score rises while risk does not fall. Require an expiry and a justification.
• Alerts nobody reads. Alerts stay in the portal because export was never configured, or land in a workspace no rule queries.
• Assuming agentless means complete. Snapshot scanning sees disks, not memory or live network behaviour; it complements runtime sensors rather than replacing them.

Trade-offs

Defender for Cloud is strongest where Azure is your primary cloud and Microsoft security tools already run your SOC: native policy integration, Defender for Endpoint and XDR correlation, and no extra agents for posture. On AWS-first or GCP-first estates, native services such as AWS Security Hub and GuardDuty or Security Command Center have deeper service coverage on their own platform, and a third-party CNAPP may give a more uniform multicloud view. Many organisations run Defender CSPM across clouds for one posture view while keeping each cloud's native detection; the choice is set out in multicloud strategy. For Kubernetes, runtime detection is one layer; image signing, admission control and network policy, covered in container security, still have to be built.

What to do next

1. Inventory every Azure subscription, AWS account and GCP project, and record which Defender plans each has today.
2. Enable Foundational CSPM everywhere and connect AWS and GCP at organisation level.
3. Decide which paid plans each environment needs, and enforce them with management-group policy so new subscriptions inherit them.
4. Schedule the two Resource Graph queries above and review results weekly with owners.
5. Configure governance rules from ownership tags, and require expiries on every exemption.
6. Turn on continuous export or XDR integration and confirm a test alert reaches on-call.
7. Work attack paths to sensitive data first, and fix the IaC templates behind recurring recommendations.
8. Monitor connector, sensor and plan coverage as health signals, not as one-off setup.