WAF, Firewall, DDoS or Network Security Perimeter? Choose by Threat Boundary

Thu, 05 Nov 2026 00:00:00 +1100

“Should we use WAF, Firewall, DDoS Protection or Network Security Perimeter?”

Before choosing, I would ask what we need to stop. An unwanted web request, an outbound connection, public access to a PaaS resource and an availability attack are not the same failure. Treating them as one purchasing decision is how a team ends up with the right product for the wrong problem.

A WAF rule can reject a web request while an unintended data operation remains available. DDoS protection can improve resilience against network-layer attacks without narrowing a workload’s data permissions. A perimeter association can be present while its enforcement mode is not the mode the design assumes.

Choose the boundary first. The threat-to-control matrix below makes the choice concrete: what the control should change, what it cannot replace, and how to check the difference without generating an attack.

The Mental Model

Controls are comparable only when they address the same failure condition.

Different layers can be complementary without being alternatives.

The continuing illustrative scenario has a public application ingress, an application workload, approved private Storage access, and a controlled unintended destination. Identity, networking and service behavior determine what can be done after a request reaches the application.

Split the review into four questions. Which HTTP requests should reach application logic? Which connections should the workload establish? Which public relationships should a supported PaaS resource accept? What protects the public endpoint’s availability under a network-layer attack?

Now the controls have a job to do. They are no longer competing on a feature list.

flowchart LR E[Public client] --> W[Application request boundary] W --> A[Application workload] A --> F[Selected network enforcement path] F --> D[Destination operation] I[Identity and service authorization] --> D P[Supported PaaS public-access boundary] --> D V[Availability resilience] -. supports .-> W

This is a boundary map, not a promise that every packet crosses every product. Private traffic may follow a different route from public traffic, and service-side operations may have another boundary entirely.

How It Really Works

Use a threat-to-control matrix

The draft toolkit’s threat-to-control module records threat, source, operation, candidate control, enforcement placement, unsupported cases, evidence and operational burden. A useful starting point is:

Failure condition	Candidate boundary	What it does not establish
Unwanted HTTP request reaches application logic	WAF policy on the chosen supported application front end	Correct application authorization or workload egress restriction
Unwanted connection leaves a source along an inspected route	Azure Firewall rules for traversing traffic	Enforcement on alternate routes or correct destination permissions
Unwanted public access to an onboarded PaaS resource	Network Security Perimeter association and applicable access rules	Blocking every Private Endpoint operation
Network-layer flood threatens an eligible public endpoint	Appropriate Azure DDoS offering	Prevention of authorized data misuse or all application-layer overload

Microsoft’s current documentation distinguishes WAF application protection from DDoS layer 3/4 protection. Firewall rule processing separately distinguishes DNAT, network and application rules. NSP documentation describes supported PaaS associations, transition/enforced modes and public-access rules.

Use those distinctions to decide what belongs in the design. Combining the products does not remove the need to check each one’s actual scope.

Verify placement, mode and bypass

For WAF, identify the hosting product and SKU, attached policy, effective mode and protected route to the origin. Detection-mode evidence is not prevention evidence. Confirm the exact host-specific capability before choosing a managed rule set or custom rule.

For Firewall, establish that the relevant route traverses the appliance and inspect effective policy, including parents and broader rules. A narrow application rule cannot rescue a matching permissive network rule that already terminates evaluation.

For NSP, inspect the resource association and supported service. Microsoft’s documentation allows Private Endpoint traffic without explicit NSP access rules; do not treat an enforced perimeter as a universal private-data boundary. Resource authentication and authorization still need their own assessment.

For DDoS, identify the eligible public IP/resource, selected offering and evidence of enabled coverage. Public-cloud feature availability does not imply every PaaS integration has identical support. Check service-specific support and cloud/region constraints.

Exercise a composition safely

Use a harmless marker header or path to match a deliberately configured WAF test rule on an author-owned application. Compare the front-end request with an authorized direct-origin check. The expected result is a documented policy response, not proof that all malicious requests are blocked.

Separately test a non-HTTP connection along the declared Firewall path and a synthetic authenticated operation against the controlled destination. Record which boundary rejects each case. A blocked HTTP marker alongside a successful unintended Blob operation is a useful counterexample: WAF works at its boundary while the consequence remains elsewhere.

DDoS validation here is configuration and coverage review only. Do not generate attack traffic or label a benign load test a mitigation result. Provider-authorized simulation would be a separately scoped exercise.

Real-World Impact

The matrix changes procurement and engineering reviews because each control must justify its role in a particular path. More layers are not automatically more assurance.

Prefer the composition that preserves necessary work

An application might need WAF protection for public HTTP input and tightly scoped data roles for Storage operations. An egress restriction may then constrain additional destinations. DDoS coverage addresses a distinct availability pressure where the endpoint is eligible.

Before adding another layer, ask which remaining operation it will constrain. TLS inspection can bring certificate management, troubleshooting and cost without correcting the broad data role that authorizes the unwanted write. It may still be justified, but that role is not a reason to deploy it.

Make ownership part of selection

WAF exclusions, Firewall policy inheritance, NSP profiles and service roles may have different owners. A control without an owner for changes and failure response becomes another exception backlog.

I would choose a smaller composition the team can test and operate over a wider one nobody can explain during an outage. An exclusion waiting for approval, a certificate renewal and an ambiguous support handoff all consume attention. That cost belongs beside the Azure bill.

Gotchas and Edge Cases

The awkward cases are worth keeping in the review. They show how a control can work correctly while the finding remains unresolved.

Origin access can bypass the web boundary

A front-end WAF result says nothing about an independently reachable origin. Inspect origin restrictions and allowed legitimate management paths before asserting that application input is constrained.

A network allowance is not a business allowance

Permitting HTTPS to a destination does not establish that the destination account, tenant or operation is approved. A successfully authenticated write can remain an unintended relationship even when every packet follows the designed route.

Transition evidence is not enforced rejection

NSP transition mode helps understand existing access patterns. Its presence is not proof of enforced denial. Record effective association mode and test resource-specific behavior rather than rely on the word “perimeter.”

Availability controls have their own exclusions

DDoS offering eligibility and value-added features differ. Do not transfer a coverage claim from one public IP resource to every public endpoint in the architecture. A dependency outage or valid application overload can also remain outside the tested protection.

Best Practices

Give each failure condition its own matrix row, with a non-goal and a counterexample. If two products answer different questions, do not force them into a winner-and-loser comparison.

An application owner should be able to read the result as a decision: “We need this boundary because of this operation, and we accept this remaining limitation.” That is more useful than a diagram carrying four security logos.

Assumptions and evidence boundary

These are documented control distinctions and proposed exercises, not observations from a combined tenant deployment. Before testing, record hosting/SKU and mode for WAF; Firewall tier, rule types and route; NSP onboarded resource, association API/schema and mode; DDoS offering and eligible endpoint; actual region/cloud support and diagnostic categories. Deployment APIs remain unpinned until a supported template and authorized lab are selected.

Separate permissions for reading policy/configuration, changing it and performing service data operations. Testing with an administrator can conceal the authority boundary the workload actually has.

For this finding, I would require every added control to constrain a named unwanted operation or support a named availability/recovery requirement. If it does neither, leave it out of this remediation decision. Any retained exception needs an owner, expiry and a compensating boundary we can actually test.

🍺

Brewed Insight: Choose controls by the question they answer. A control that works exactly as documented can still be the wrong response when the consequence sits at a different boundary.

Network Security Perimeter on Brewed in the Cloud by Chris Hailes