Microsoft Defender for Cloud is the cloud security posture and workload protection platform for Azure and hybrid estates. The posture management baseline is free, but the protection that matters is a stack of paid plans, Defender for Servers, for Storage, for SQL, for Containers, for App Service, for Key Vault and more, each metered through Azure consumption on a per resource basis. That billing model is the trap. A plan switched on at the subscription level silently meters every qualifying resource inside it, the bill scales with the estate rather than with a seat count, and nobody owns the line because it arrives inside the Azure invoice rather than a license schedule. Defender for Cloud is where security spend hides in consumption, and where plan scoping is the difference between targeted protection and a runaway meter.
Defender for Cloud combines a free posture management baseline with a set of paid workload protection plans. Each plan protects a class of resource and meters through Azure consumption, which makes the billing behave like infrastructure spend rather than licensing.
The free tier delivers secure score and the basic posture recommendations across connected subscriptions. The value sits in the paid plans: Defender for Servers, Storage, SQL, Containers, App Service, Key Vault, and the others, plus the Defender CSPM plan that adds the advanced posture features. Each is enabled and billed independently, and the estate pays only for the plans switched on.
Defender for Servers comes in two plans. Plan 1 delivers the core endpoint protection for servers, built on Defender for Endpoint. Plan 2 adds vulnerability assessment, file integrity monitoring, just in time access, and the broader server security surface. Plan 2 is materially more expensive per server, and the gap between the plans across a large server estate is one of the largest levers on the line.
Defender for Cloud produces three recurring exposures. The first is the plan enabled estate wide that meters resources nobody decided to protect. The second is Servers Plan 2 where Plan 1 fits. The third is server protection paid twice through Cloud and through Endpoint.
A plan switched on at the subscription level meters every qualifying resource inside it, including the development, test, and low value workloads that never warranted the protection. The bill scales with the resource count and arrives buried in the Azure invoice. Because no seat is involved, the line escapes the license review entirely and grows with every new resource the teams deploy.
Defender for Servers gets enabled at Plan 2 across the whole server estate because it is the complete option. The vulnerability assessment, integrity monitoring, and just in time features that justify the premium go unused on the bulk of servers. Paying the Plan 2 rate per server hour for an operation that exercises only the core protection is a large and recurring overspend.
Defender for Servers Plan 2 already includes the Defender for Endpoint capability for servers. When a separate standalone Defender for Endpoint purchase also covers those servers, the same machines are protected and paid for through two lines. The overlap sits across the security and the Azure procurement tracks, and it survives until someone maps the server estate against both.
Defender for Cloud responds to three levers. The scoping confines the paid plans to the resources that warrant them. The plan review aligns Servers to the operation. The overlap map eliminates the double server coverage against Defender for Endpoint.
The paid plans are scoped to the production and sensitive resources that justify the protection, rather than enabled blanket across every subscription. Development, test, and low value workloads come off the meter, and the line collapses to the resources the security posture genuinely requires. Because the billing is per resource, the scoping translates directly and immediately into the Azure invoice.
The scoped position then feeds the broader Azure commitment negotiated at the EA renewal.
Defender for Servers is tested against the operation, and the servers that do not exercise the Plan 2 vulnerability and integrity features move to Plan 1 at the lower per server rate.
The server estate is mapped against any standalone Defender for Endpoint purchase, and the duplication is eliminated so each server is protected and paid for once, through the path that costs least across the combined security and Azure spend.
The Defender for Cloud spend negotiates inside the broader Azure commitment, where the consumption metered protection draws against the same commit and the security stack is priced as one position rather than a set of separate meters.
Because the Defender plans meter through Azure consumption, the spend draws down the same Azure commitment as the rest of the estate. A buyer who models the scoped protection inside the total Azure commit negotiates the consumption discount across the whole volume, and decides the commitment level knowing the security meter is part of it rather than discovering the protection spend after the commit is set.
Defender for Cloud, Defender for Endpoint, and Microsoft Sentinel describe one security operation across the cloud estate. A buyer who maps the overlaps, eliminates the double coverage, and negotiates the stack as a single position carries more leverage than pricing each meter alone. The Defender for Cloud line is set inside the full security and Azure commitment, where the scoping and the commit decide the cost together.
The engagement is a plan scoping and overlap diagnostic, a Servers plan model, and the integration of the scoped position into the broader Azure and security negotiation. The output is a Defender for Cloud meter confined to what warrants protection.
We map every enabled Defender plan against the resources it meters, surface the development and low value workloads carrying paid protection, test Defender for Servers against the operation, and reconcile the server estate against any standalone Defender for Endpoint coverage. The output is a defensible picture of what is protected, what is double covered, and what should come off the meter.
We scope the plans to the resources that warrant them, align Servers to the right plan, eliminate the double server coverage, and fold the scoped consumption into the broader Azure commit and security stack negotiation. We set the commitment knowing the protection meter is part of it. The output is a Defender for Cloud line confined to real need and defensible inside the Azure commitment.
The Defender for Cloud diagnostic maps every enabled plan against the resources it meters, scopes the protection to the workloads that warrant it, aligns the Servers plan, eliminates the double coverage with Defender for Endpoint, and folds the scoped consumption into the Azure commit. The result is a security meter confined to real need, not a runaway line inside the Azure invoice.