Azure DDoS Protection: One Plan, Many Subscriptions — The Multi-Subscription Cost Mistake

The pattern shows up in almost every multi-subscription Azure tenant I review:

1. The platform team enables Azure DDoS Protection (Network Protection tier) in the connectivity subscription. Good.
2. A workload team in a different subscription spins up an internet-facing app, follows their security checklist, and creates their own DDoS Protection Plan in their subscription.
3. Another workload team does the same in a third subscription.
4. Twelve months later the tenant is paying for three, four, sometimes a dozen DDoS plans. At roughly US$2,944 per plan per month the bill compounds quickly.

Almost none of that spend is necessary. Microsoft is explicit on this point: a single DDoS Protection Plan can be shared across multiple subscriptions in the same Azure AD tenant. One plan, one bill, every spoke VNet protected. This article is the architect's case for that pattern — the cost math, the reference architecture (modelled on Microsoft's own hub-and-spoke guidance), the RBAC required, a Terraform baseline, and the healthcare addendum that makes it auditable.

1. The Multi-Subscription Mistake

These are the anti-patterns I find on every cost review of a mid-to-large Azure estate:

• One DDoS Protection Plan per subscription — each workload team creates their own, treating it like a per-subscription resource.
• Plan created in the workload subscription, owned by the app team, with no tenant-level governance.
• Network Protection tier used for a single public IP when IP Protection (per-IP pricing) would be 1/10th the cost.
• No Azure Policy to prevent or detect duplicate plans being created elsewhere in the tenant.
• Plan enabled, VNets never associated — paying the flat fee for protection that is not applied to any public IP.
• No DDoS simulation in the lifecycle — the plan is bought as compliance signage, never validated.
• No telemetry / no alerts — an actual attack arrives and nobody notices the mitigation log entries.

2. What Microsoft Actually Says

From the official Microsoft Learn documentation on managing DDoS Protection:

That single statement collapses the multi-plan pattern. The architectural rule becomes: one DDoS Protection Plan per tenant, deployed in the connectivity / hub subscription, referenced by every spoke VNet that needs Network Protection.

3. Reference Architecture — One Plan, Many Spokes

This is the hub-and-spoke pattern Microsoft recommends in the DDoS reference architectures and in the Cloud Adoption Framework landing zone. One plan in the connectivity subscription; every workload VNet across every other subscription associates with it.

4. The Cost Math — Why This Matters

Public list pricing for Azure DDoS Protection (Network Protection tier) is approximately US$2,944 per month, per plan, flat, covering up to 100 protected public IP resources, with a small per-resource overage above that. The flat fee is the cost trap — it does not scale down with use.

Pattern	Plans	Approx. annual cost	Outcome
One plan per subscription (5 subs)	5	≈ US$176,640 / yr	4 plans are redundant; protection identical
One plan per workload (12 apps)	12	≈ US$423,936 / yr	11 plans redundant; same protection
Shared plan, multi-subscription (recommended)	1	≈ US$35,328 / yr	Same protection, one bill, central governance

List prices for illustration only; check the Azure DDoS Protection pricing page for current per-region figures and EA/CSP discounts.

5. SKU Choice — IP Protection vs Network Protection

Since 2023 Microsoft has offered two SKUs. Choose deliberately, per the official SKU comparison:

Aspect	IP Protection	Network Protection
Scope	Per public IP	Per VNet (plan-scoped)
Pricing model	Per protected IP / month	Flat plan fee + included IPs
Rapid Response (DRR)	Not included	Included
WAF cost protection	No	Yes (cost reimbursement on attack)
Multi-subscription sharing	N/A (per IP)	Yes — single plan across tenant
Best for	Small estate, < ~15 public IPs	Enterprise / regulated / multi-sub

For a multi-subscription enterprise tenant — and always for healthcare or any regulated workload — Network Protection is the right choice because DRR and WAF cost protection materially change incident economics. The architectural mistake is not which SKU to pick; it is buying Network Protection more than once.

6. RBAC for Cross-Subscription Association

Sharing a plan across subscriptions is a permissions exercise, not a connectivity one. The user or service principal that creates / updates a spoke VNet must hold a role that includes the Microsoft.Network/ddosProtectionPlans/join/action on the plan in the hub subscription. Per Microsoft's permissions documentation:

• Network Contributor built-in role on the DDoS Protection Plan resource — typically granted to the spoke landing-zone managed identity.
• Or a custom role containing only Microsoft.Network/ddosProtectionPlans/join/action if you want least-privilege.
• Grant at the DDoS plan scope (not the hub subscription) to minimise blast radius.

Operate this through the same group-based RBAC model your landing zone already uses — do not hand-grant per spoke.

7. Terraform Baseline

This is the minimum viable pattern: the plan in the hub subscription, the spoke VNet in any other subscription referencing it by full resource ID across an aliased provider.

# providers.tf — one provider per subscription
provider "azurerm" {
  alias           = "hub"
  subscription_id = var.hub_subscription_id
  features {}
}
provider "azurerm" {
  alias           = "spoke"
  subscription_id = var.spoke_subscription_id
  features {}
}

# hub.tf — one DDoS Protection Plan for the whole tenant
resource "azurerm_network_ddos_protection_plan" "tenant" {
  provider            = azurerm.hub
  name                = "ddos-plan-tenant"
  resource_group_name = var.hub_rg
  location            = var.location
  tags = {
    owner       = "platform-network"
    cost-center = "shared-services"
    purpose     = "tenant-wide-ddos-network-protection"
  }
}

# spoke.tf — spoke VNet in a different subscription, same tenant
resource "azurerm_virtual_network" "spoke" {
  provider            = azurerm.spoke
  name                = "vnet-spoke-app1"
  resource_group_name = var.spoke_rg
  location            = var.location
  address_space       = ["10.20.0.0/16"]

  ddos_protection_plan {
    id     = azurerm_network_ddos_protection_plan.tenant.id   # cross-sub reference
    enable = true
  }
}

Pair this with an Azure Policy at the tenant root management group:

• Deny creation of any new Microsoft.Network/ddosProtectionPlans outside the connectivity subscription.
• Audit VNets in spoke subscriptions whose ddos_protection_plan.id is null and that have one or more public IPs attached — flag for the FinOps / security review.

8. Monitoring, Simulation & Rapid Response

A DDoS plan you have never tested is the same as one you never bought. Build the lifecycle into the platform:

Microsoft documents the full simulation programme and the rapid-response process — these are not bolt-ons, they are part of the product.

9. Healthcare Addendum — HIPAA & HITRUST

For healthcare SaaS the DDoS conversation is not a cost conversation, it is an availability and integrity conversation. HIPAA's Security Rule does not name DDoS, but it does require both. Volumetric attacks that knock a payer portal or a FHIR API offline are a §164.308(a)(7) contingency-plan event the moment they happen, and a HITRUST audit finding the moment they recur.

Control	How a shared DDoS plan satisfies it
HIPAA §164.308(a)(7) Contingency Plan	Always-on mitigation + DRR engagement is part of the documented response runbook; tested via simulation.
HIPAA §164.312(b) Audit Controls	DDoS notification & mitigation logs streamed to Log Analytics with 6-year retention.
HIPAA §164.312(e)(1) Transmission Security	Mitigation preserves availability of the encrypted transport — paired with the WAF in front of the same public IPs.
HITRUST 09.m Network Controls	Network-layer DDoS protection enabled on all internet-facing VNets carrying ePHI; evidence is the VNet → plan association.
HITRUST 12.c Information System Continuity	Continuity plan references DDoS mitigation + DRR contact path; tested via simulation cadence.

10. Architect's Checklist

• Exactly one DDoS Protection Plan per Azure AD tenant (Network Protection tier).
• Plan deployed in the connectivity / hub subscription owned by the platform team.
• Azure Policy at tenant root: deny new plans outside the connectivity subscription.
• Spoke VNets reference the shared plan by full resource ID (Terraform / Bicep, not portal).
• RBAC: spoke landing-zone identities have Microsoft.Network/ddosProtectionPlans/join/action on the plan only.
• Diagnostic logs to Log Analytics + Sentinel; 6-year retention for healthcare.
• Alerts on IfUnderDDoSAttack metric per protected public IP.
• Quarterly DDoS attack simulation; results filed against the contingency-plan evidence.
• Microsoft DRR contact path documented in the SOC runbook.
• Quarterly FinOps query for orphan plans + public-IP VNets with no plan association.
• Healthcare: HIPAA §164.308(a)(7) and HITRUST 09.m / 12.c evidence owner named.

11. Further Reading — Official Documentation

Every claim in this article maps to current Microsoft Learn guidance. These are the authoritative references:

Azure DDoS Protection — core

• Azure DDoS Protection overview
• DDoS Protection SKU comparison — IP Protection vs Network Protection
• Manage Azure DDoS Protection (cross-subscription plan sharing)
• DDoS Protection features
• DDoS Protection permissions & RBAC

Architecture & landing zone

• DDoS reference architectures (hub-spoke, single-VNet, perimeter)
• Cloud Adoption Framework — landing zones
• CAF — IP addressing & connectivity

Operations & testing

• Test through simulations (authorised partner programme)
• DDoS Rapid Response (DRR)
• DDoS disaster recovery guidance

Pricing & compliance

• Azure DDoS Protection pricing
• Azure HIPAA / HITECH offering
• Azure HITRUST CSF offering

Infrastructure-as-Code

• Terraform azurerm_network_ddos_protection_plan
• Terraform azurerm_virtual_network (ddos_protection_plan block)

Key Takeaway

Azure DDoS Protection Plan is a tenant resource pretending to be a subscription resource. Treat it as tenant-wide, deploy exactly one, share it across every spoke VNet through cross-subscription RBAC, enforce that uniqueness with Azure Policy at the root management group, and validate with annual simulations. For healthcare, that single plan becomes a HIPAA contingency-plan and HITRUST continuity control — and removes tens of thousands of dollars of unnecessary spend in the same move. Right architecture, right cost, right compliance posture.