Compliance

Protect Azure networks with DDoS and firewalls

One capability across the network edge: make sure every internet-facing virtual network can absorb a volumetric attack, that traffic crossing a trust boundary is inspected by a firewall, and that the same protection extends to host and VM networking on Azure Local.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-ddos-protection-standard-enabled azure-local-host-vm-networking-protected azure-vnet-azure-firewall-protected

Protecting the network edge: the basics

What does an under-protected Azure network actually look like?

A virtual network is the perimeter of everything you run in Azure, and exposure at the edge shows up in a handful of distinct shapes rather than one setting. An internet-facing virtual network can sit on the free DDoS Basic tier, which absorbs only the largest platform-wide attacks and leaves a targeted volumetric or protocol attack to overwhelm your own public IPs. Traffic can flow in and out of a virtual network with no firewall in the path, so nothing inspects it, logs it, or denies it by default. On Azure Local, the on-premises HCI platform managed through Azure, host and VM networking can run without the default-deny and microsegmentation rules that keep an attacker from moving laterally once inside. Each is its own Defender for Cloud recommendation, but the underlying risk is the same: a network boundary that more of the internet can reach, flood, or pivot through than you meant.

Microsoft Defender for Cloud turns each of these into its own recommendation, which is why one network-heavy subscription can fail several edge checks at once. 'Azure DDoS Protection Standard should be enabled', 'Virtual networks should be protected by Azure Firewall' and 'Host and VM networking should be protected on Azure Local systems' read as separate problems on the report, but they are one job: make the network edge able to absorb an attack, inspect what crosses it, and contain anything that gets in. The first targets virtual networks that hold public-facing resources such as an Application Gateway with a public IP. The second targets virtual networks with no firewall inspecting their traffic. The third extends the same defence-in-depth to the hybrid Azure Local estate.

Most of this gap is drift, not intent. A virtual network created before DDoS Network Protection was budgeted for, a spoke that peers straight to the internet because the hub firewall was never built, an Azure Local cluster deployed before the network security policies were switched on. The work is to find every internet-facing or trust-crossing network that is under-protected, decide where each control genuinely belongs, and close the gap with a plan the rest of the estate can share.

In this lesson you will learn how Azure expresses protection at the network edge, how to find every internet-facing or trust-crossing network that is under-protected, and how to close the gap without paying for protection you do not need. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The flood that set the record, then was beaten the next year

Azure's own DDoS protection teams have publicly reported mitigating some of the largest attacks ever recorded, including multi-terabit-per-second floods aimed at single customers. The striking part is the cadence: each record-setting attack tends to be eclipsed within months as attackers rent ever larger botnets, so a network that comfortably absorbs today's typical attack on the free tier can be flat on its back against next quarter's. That is the case for the Network Protection tier: it brings adaptive, traffic-profiled mitigation and cost protection that scale with the threat, rather than the fixed, platform-wide-only shielding of the free Basic tier.

Finding edge exposure across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows network findings spread across several virtual networks in two subscriptions: some hold public-facing resources with no DDoS plan, others carry traffic with no firewall in the path.

Rather than work the findings one by one, Sam starts by listing which virtual networks actually carry DDoS Network Protection today, so the genuinely internet-facing networks can be separated from internal ones before any spend is committed.

Start by listing each virtual network and whether DDoS Network Protection is enabled on it. The unprotected internet-facing ones are the priority.

$ az network vnet list --query "[].{name:name, ddos:enableDdosProtection}" -o table

Name Ddos

------------------ ------

vnet-payments-prod False

vnet-batch-internal False

# vnet-payments-prod fronts a public payment portal and has no DDoS plan. Protect it first.

An internet-facing virtual network with DDoS Network Protection off is the highest-value target. Protect the public-facing networks before the internal ones.

How Defender for Cloud decides a network is under-protecteddeep dive

The three recommendations resolve to different properties and have deliberately different scope. 'Azure DDoS Protection Standard should be enabled' looks at virtual networks that contain public-facing resources, specifically those with an Application Gateway and public IPs, and flags any where the virtual network is not associated with a DDoS protection plan ('enableDdosProtection' is false). DDoS Basic is the free, always-on platform default that absorbs only large platform-wide attacks; the Network Protection tier, formerly called Standard, adds per-resource adaptive tuning, attack telemetry, alerting and cost protection, and is what this control wants enabled.

'Virtual networks should be protected by Azure Firewall' looks for virtual networks whose traffic is not routed through an Azure Firewall, and its related policy is 'All Internet traffic should be routed via your deployed Azure Firewall'. In practice the firewall sits in a hub virtual network, the spokes peer to the hub, and a user-defined route sends 0.0.0.0/0 to the firewall's private IP so all internet-bound and cross-boundary traffic is inspected, logged and denied by default rather than flowing direct. 'Host and VM networking should be protected on Azure Local systems' is the hybrid extension: it checks that the network security policies, the default-deny inbound rules and microsegmentation implemented as five-tuple stateful firewall rules at each VM's virtual switch port, are switched on for the Azure Local cluster.

Defender for Cloud evaluates these against the Microsoft Cloud Security Benchmark on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly. The control-plane change itself, associating a DDoS plan or attaching a route table, is immediate, but the posture catches up on the next assessment. The strongest position pairs each enabled control with an Azure Policy backstop: a policy that audits or modifies virtual networks to require DDoS protection means no new internet-facing network slips out from under the plan, turning a point-in-time fix into a standing guarantee.

What is the impact of leaving the edge under-protected?

The direct impact splits by control. Without DDoS Network Protection, a targeted volumetric or protocol attack against an internet-facing public IP can saturate it and take the service offline, and on the free Basic tier you have neither the adaptive mitigation tuned to your traffic nor the cost protection that absorbs the scale-out charges an attack can trigger. Without a firewall in the path, traffic crossing a trust boundary flows uninspected: there is nothing to deny it by default, nothing to apply application-level rules, and nothing logging it for the investigation you will need later. On Azure Local without host and VM network protection, an attacker who reaches one VM can move laterally to the next because the default-deny and microsegmentation rules that would have fenced each workload are not in force.

The second-order impact is blast radius and time-to-detect. An inspected, default-deny edge shrinks the attack surface to the routes you actually operate and gives you the logs to see an intrusion early; an open edge leaves you defending everything and discovering problems late. A flood that takes a public service down is not only lost revenue for the hours it lasts, it is the reputational hit of a visible outage.

On the compliance side, every modern framework, ISO 27001, SOC 2, PCI DSS and the UK and EU regimes, expects evidence that internet-facing services are protected against denial-of-service and that traffic crossing trust boundaries is filtered and logged. A passing set of these edge recommendations across every subscription, including the Azure Local systems, is a clear and defensible artefact to hand an auditor.

How do you protect the edge safely and efficiently?

Work the capability as one loop rather than chasing individual findings. The order matters: decide where each control genuinely belongs before you commit spend, so you protect the internet-facing networks and real trust boundaries without paying for protection on networks that do not face the internet.

1. Inventory every network by exposure

List the virtual networks that hold public-facing resources and lack a DDoS plan, the networks whose traffic is not routed through a firewall, and the Azure Local clusters without host and VM network protection. Treat this inventory as the source of truth, not the Defender finding count, because one network can trigger several recommendations at once.

2. Separate internet-facing from internal

DDoS Network Protection belongs on networks that face the internet, not on purely internal ones. Decide which networks genuinely carry public IPs and customer traffic. Those justify the plan today; internal-only networks generally do not, and protecting them uniformly is wasted spend.

3. Protect with shared resources, highest impact first

Create one DDoS protection plan and bring every internet-facing network under it, since a single plan can be shared across every subscription in the tenant, its fixed monthly charge covering up to a hundred public IP addresses. Stand up one Azure Firewall in a hub, peer the spokes to it, and route 0.0.0.0/0 through it so traffic crossing a boundary is inspected and denied by default. Switch on the network security policies for each Azure Local cluster. Prioritise the customer-facing and revenue networks first.

4. Ratchet it shut with Azure Policy

Assign the built-in policy that audits or modifies virtual networks to require DDoS protection, and the policy that requires internet traffic to route via Azure Firewall, so no new internet-facing network is created outside the plan or outside the inspected path. Back this with the Azure Local network protection policy, so the safe configuration is enforced rather than merely encouraged.

# Create one shared DDoS protection plan, then bring the internet-facing
# virtual networks under it. A single plan can be shared across every
# subscription in the tenant; its fixed monthly charge covers up to 100
# public IP addresses.
RG=net-hub-rg
LOC=uksouth
az network ddos-protection create \
  --resource-group "$RG" \
  --name ddos-plan-shared \
  --location "$LOC"

for vnet in vnet-payments-prod vnet-web-prod; do
  az network vnet update \
    --resource-group "$RG" \
    --name "$vnet" \
    --ddos-protection true \
    --ddos-protection-plan ddos-plan-shared
  echo "$vnet: associated with shared DDoS Network Protection plan"
done

# Stand up a Premium Azure Firewall policy in the hub with IDPS and
# threat intelligence both in Deny mode (deploy the firewall + route
# 0.0.0.0/0 to its private IP from each spoke to complete the path).
az network firewall policy create \
  --resource-group "$RG" \
  --name hub-fw-policy \
  --location "$LOC" \
  --sku Premium \
  --threat-intel-mode Deny \
  --idps-mode Deny

# Ratchet it shut: assign the built-in policy that requires DDoS protection
# on virtual networks. Look the definition up by its exact display name so
# no GUID is hardcoded.
pid=$(az policy definition list \
  --query "[?displayName=='Virtual networks should be protected by Azure DDoS Protection'].name" -o tsv)
az policy assignment create \
  --name require-vnet-ddos \
  --policy "$pid" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Quick quiz

Question 1 of 5

Defender for Cloud shows findings across DDoS protection, Azure Firewall and Azure Local host networking on several networks. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure protects the network edge across the controls in this capability.

You can now treat the Azure network edge as one capability rather than a scatter of findings: inventory which networks face the internet or cross a trust boundary under-protected, separate internet-facing from internal, protect with a shared DDoS plan and a hub firewall highest-impact first, extend the same posture to Azure Local, and ratchet the estate shut with Azure Policy. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Protecting the network edge: the cost and risk view

The one network capability where the controls carry a real, forecastable Azure charge, so the framing has to be sharp

Unlike most security hygiene, edge protection is not free. Azure DDoS Network Protection is a fixed monthly charge for the protection plan that covers a set of public IP resources, and Azure Firewall carries an hourly deployment charge plus a per-gigabyte data-processing charge. That makes this the rare capability where finance is genuinely in the loop on the spend, not just the risk. The job is to right-size it: a single DDoS plan can be shared across every subscription in the same tenant, with the fixed monthly charge covering up to a hundred public IP addresses, so the per-network cost falls sharply when one plan is shared rather than duplicated, and one Azure Firewall in a hub protects every spoke that routes through it.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A virtual network fronting a customer-facing payment portal carries a far higher expected loss from a successful DDoS or an uninspected intrusion than an internal batch-processing network, yet both can surface as a single red finding. Map the failures to the workloads behind them and prioritise by exposure, so the fixed monthly spend lands first where the downside is largest.

The arithmetic still favours action, it is just not one-sided the way disabling a free setting is. The DDoS plan and the firewall are bounded, forecastable monthly costs that you can model up front. The downside of leaving the edge open is the cost of the event you did not absorb: hours of customer-facing downtime during a volumetric attack, or an intrusion that moved laterally because nothing inspected the traffic, with the breach response that follows.

This lesson is for the finance partner who sees DDoS and firewall findings on the security report and needs to know what the right response is and, unusually for security hygiene, what it actually costs. It covers why these controls carry real monthly spend, how a shared DDoS plan and a hub firewall keep the per-network cost down, and how to turn a list of red findings into a risk-ordered plan with a forecastable budget.

Fun fact

The flood that set the record, then was beaten the next year

How a finance partner frames the edge decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with a cluster of network findings across two older subscriptions. The instinct is not to wave through a blanket protection budget; it is to ask what is actually behind each red finding, because unlike most security hygiene these controls cost real money. Enabling DDoS Network Protection adds a fixed monthly plan charge, and standing up Azure Firewall adds an hourly charge plus per-gigabyte data processing. So the spend question is real and forecastable: how many internet-facing networks genuinely need the DDoS plan, and how many trust boundaries genuinely need a firewall in the path.

Sam asks the team to map each failing network to the workload behind it. One virtual network fronts a customer payment portal, another carries only internal batch traffic between two private subnets, and a third is a spoke that should route through a hub firewall that was never built. The list is reframed on the risk register and against a shared-resource plan: the payment-portal network is a high expected-loss item that justifies the DDoS plan today, and because a single DDoS plan can be shared across every subscription in the tenant, with its fixed monthly charge covering up to a hundred public IP addresses, the marginal cost of bringing the other internet-facing networks under the same plan is small. The hub firewall is one deployment that protects every spoke that routes through it, so the data-processing charge, not a per-network licence, is the variable to watch. The finance pack reads: 'One DDoS plan, shared across the tenant, covers our internet-facing networks for a fixed monthly cost; one hub firewall protects the spokes; the spend is bounded and forecastable, and it lands first where a flood or an intrusion would cost us the most.'

Why edge exposure belongs on the risk register, with a real budget line

The cost model here is genuinely two-sided, which makes the framing matter more than usual. Protection is not free: the DDoS plan is a fixed monthly charge and the firewall is an hourly plus per-gigabyte charge, so each enabled control is a forecastable line on the budget. Leaving the edge open, by contrast, is an unbounded tail risk: a successful volumetric attack costs you the downtime, and an uninspected intrusion costs you the breach response, and neither is capped.

The documented cost of an outage or breach includes lost revenue for every hour a public service is down, the scale-out charges a flood can trigger without DDoS cost protection, forensics and legal fees after an intrusion, and customer churn. Against that, the remediation is a bounded monthly spend that a shared DDoS plan and a hub firewall keep efficient. The finance role is to right-size the protection, attach expected loss to each failing network, and make sure the fixed spend lands first where the downside is largest, rather than buying protection uniformly for networks that do not face the internet.

What finance can do about the edge gap

Finance cannot stand up a firewall, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with a forecastable monthly budget and no protection bought where it is not needed. Three levers.

1. Right-size with shared resources

Make explicit that these controls are bought once and shared, not per network. A single DDoS protection plan can be shared across every subscription in the tenant for one fixed monthly charge that covers up to a hundred public IP addresses, so the marginal cost of bringing each additional internet-facing network under it is small. One Azure Firewall in a hub protects every spoke that routes through it, so the variable to watch is data processing, not a per-network licence. Budget the plan and the firewall as shared infrastructure lines, and the per-network cost falls sharply.

2. Order the work by expected loss, not by finding count

A virtual network fronting a customer payment portal and an internal batch network both show up as a single red finding, but their expected loss from a flood or an intrusion differs by orders of magnitude. Ask the team to map each failing network to the workload behind it and protect the customer-facing, revenue-generating networks first. The metric that belongs on the cost-and-security review is the count of findings weighted by the exposure and revenue at stake, not the raw total.

3. Do not buy DDoS protection for internal-only networks

The cheapest spend is the spend you do not make. DDoS Network Protection is for networks that face the internet; a purely internal network between private subnets does not need a DDoS plan, and protecting it uniformly is wasted budget. Require that the team distinguishes internet-facing networks, which justify the plan, from internal ones, which generally do not, so the fixed monthly cost is concentrated where the threat actually is.

Quick quiz

Question 1 of 5

A security report shows DDoS and firewall findings across several networks. As the finance partner, what is the right starting assumption about the Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure protects the network edge across the controls in this capability.

You have finished the finance view of edge protection. You know this is the rare security capability with a real, forecastable cost: a fixed monthly DDoS plan and an hourly-plus-data firewall charge, kept efficient by sharing one plan across the tenant and one firewall across the spokes, and concentrated on internet-facing networks rather than bought uniformly. Next time DDoS and firewall findings land, you will right-size the protection, order it by exposure and revenue at stake, and present a bounded budget line rather than treating it as either free or unforecastable.

Back to the library

Protecting the network edge: the headline

Whether an internet-facing service can be knocked offline by a flood, or breached by traffic nobody inspected

The network edge is where two of the most public failure modes live: a service taken offline by a distributed denial-of-service flood, and an intrusion that crossed a boundary nobody was inspecting. An internet-facing virtual network on the free DDoS tier and a network with no firewall in the path are each one bad day away from a headline, and the report shows this as a scatter of separate findings across the estate.

The leadership question is not 'are we compliant today?' It is 'if our public service is flooded tomorrow, or if traffic carries an intrusion, does the platform absorb and inspect it, or does it land on the workload?' The defensible end state is that every internet-facing virtual network sits behind a DDoS protection plan, traffic crossing a trust boundary is inspected by Azure Firewall, and the same posture extends to the Azure Local estate.

This one is a cost decision as well as a governance one, and that is the honest framing. DDoS protection and a firewall carry real, forecastable monthly charges. The trade is a bounded, predictable spend against the unbounded cost of downtime and breach, which is exactly the kind of insurance leadership is paid to weigh.

A short read for the leader who needs to know what an under-protected network edge exposes, why DDoS and firewall protection is genuinely a cost decision as well as a governance one, and what a defensible end state looks like across the estate, including the hybrid Azure Local systems.

Fun fact

The flood that set the record, then was beaten the next year

What it looks like when the edge is protected by design, not by luck

After a peer company's public service was knocked offline for most of a day by a volumetric attack, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on the size of the attack, because the customer-facing networks were running on the free DDoS Basic tier, which only shields against the very largest platform-wide events, and a targeted flood would have landed on the workload.

The team's response was to stop treating edge protection as a per-network afterthought and start treating it as architecture. They created a single DDoS protection plan and brought every internet-facing virtual network under it, stood up one Azure Firewall in a hub and routed the spokes through it so traffic crossing a trust boundary is inspected and denied by default, and extended the same network security policies to the Azure Local clusters. The next time the CEO asked the question, the answer had changed from 'it depends how big the attack is' to 'the platform absorbs the flood and inspects the traffic by design, and the monthly cost of doing so is a known, budgeted line.' That shift, from hoping an attack stays small to engineering the edge to absorb it, is the confidence signal this capability delivers, and unlike most security work it comes with a price tag you can put in the plan.

Why this is a board-level risk

The two failure modes at the network edge, a public service flooded offline and an intrusion that crossed an uninspected boundary, are among the most visible and most costly an organisation can suffer, and both have well-documented precedents. Protecting the edge is the capability that makes these structurally harder, and an Azure Policy backstop keeps new networks from slipping out from under it.

Unlike most security controls, this one costs real money, and that is the point of bringing it to leadership: it is a deliberate trade of a bounded, forecastable monthly spend against the unbounded cost of downtime and breach. That is precisely the kind of insurance decision the board exists to weigh, and for any internet-facing revenue service the trade is straightforward to approve.

The leadership move on edge protection

The executive handle is not to approve each network individually; it is to require that the internet-facing edge is protected by shared, backstopped infrastructure, and to accept the bounded cost of doing so as deliberate insurance.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, every internet-facing virtual network sits under a shared DDoS plan, trust boundaries are inspected by a hub Azure Firewall, the Azure Local clusters have host and VM network protection on, and Azure Policy requires DDoS protection and firewall routing on new networks. A backstop that no new network can bypass is the difference between protecting what exists today and guaranteeing the edge stays protected tomorrow.

2. Treat the spend as deliberate insurance

This capability carries a real, forecastable monthly cost, and that is the right framing to bring to the board: a bounded, predictable spend against the unbounded cost of an outage or a breach. For any internet-facing revenue service the trade is straightforward, but it should be a conscious decision with a budget line, not a surprise on the bill or a control quietly left off to save money.

3. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we are protected.' It is a passing set of DDoS, firewall and Azure Local recommendations across every subscription plus evidence that the backstop policies are assigned. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

Quick quiz

Question 1 of 5

At a board review you ask whether a flood like a competitor's outage could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure protects the network edge across the controls in this capability.

Two takeaways. Edge protection is the rare control where the spend is real, so it is a deliberate insurance trade: a bounded monthly cost against the unbounded cost of an outage or breach, easy to approve for any internet-facing revenue service. And the defensible end state is not 'we checked and the networks looked fine'; it is a shared DDoS plan over every internet-facing network, a hub firewall inspecting trust boundaries, host and VM protection on Azure Local, and Azure Policy keeping new networks inside that envelope.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Azure Local

Host and VM networking should be protected on Azure Local systems Low Unprotected Azure Local host and VM networking exposes east-west traffic to interception and lateral movement.

Azure Virtual Network

Part of the learning path Close Azure network exposure

Protect Azure networks with DDoS and firewalls

Protecting the network edge: the basics

The flood that set the record, then was beaten the next year

Finding edge exposure across a subscription

How Defender for Cloud decides a network is under-protecteddeep dive

What is the impact of leaving the edge under-protected?

How do you protect the edge safely and efficiently?

1. Inventory every network by exposure

2. Separate internet-facing from internal

3. Protect with shared resources, highest impact first

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Protecting the network edge: the cost and risk view

The flood that set the record, then was beaten the next year

How a finance partner frames the edge decision

Why edge exposure belongs on the risk register, with a real budget line

What finance can do about the edge gap

1. Right-size with shared resources

2. Order the work by expected loss, not by finding count

3. Do not buy DDoS protection for internal-only networks

Quick quiz

Keep learning

Protecting the network edge: the headline

The flood that set the record, then was beaten the next year

What it looks like when the edge is protected by design, not by luck

Why this is a board-level risk

The leadership move on edge protection

1. Set a deadline to reach a backstopped end state

2. Treat the spend as deliberate insurance

3. Ask for proof, not assurance

Quick quiz

Keep learning

Controls this lesson covers

Azure Local

Azure Virtual Network

Related compliance lessons