CH07-03: Network and Edge Protection Services

Goal

Identity and secret controls decide who can act and how sensitive material is protected. The next question is how traffic reaches the workload and which paths need filtering, inspection, private access, or denial-of-service mitigation.

This section connects security service selection back to the networking mental model from Chapter 3. Network security is not one control. Public edge traffic, HTTP application traffic, virtual network routing, outbound access, and private service access each create different design questions.

The durable idea for this section is:

Network and edge protection services reduce exposure and inspect traffic at different layers.

The Short Version

Azure Firewall, Web Application Firewall, DDoS Protection, and private endpoints all relate to traffic protection, but they do different jobs.

The service choice should follow the traffic risk. Do not start with "put a firewall in front of it" as the whole answer. First ask where the traffic enters, what protocol it uses, what must stay private, what must be inspected, and who owns the route and alert.

A Layered Traffic Model

A public API might have several traffic control points:

flowchart TB
    A["Internet user or client"]
    B["Public edge<br/><small>WAF and DDoS protection</small>"]
    C["Application entry point<br/><small>API, web app, gateway, or load balancer</small>"]
    D["Virtual network path<br/><small>Routing and inspection through firewall when required</small>"]
    E["Private service access<br/><small>Private endpoint and private DNS</small>"]
    F["Logs and alerts<br/><small>Security and operations visibility</small>"]

    A --> B --> C --> D --> E
    B --> F
    D --> F
    E --> F

This is a simplified model, not a required design for every workload. A low-risk internal tool may not need every layer. A regulated internet-facing workload may need most of them, plus identity, application security, monitoring, and response processes.

Azure Firewall

Azure Firewall is a managed network firewall service. In architecture terms, it is often used when a team needs centralized network traffic filtering, logging, and policy control.

Common reasons to consider Azure Firewall include:

• Controlling outbound traffic from workloads to the internet.

• Inspecting or filtering traffic between spokes in a hub-spoke network.

• Applying central network and application rules through firewall policies.

• Logging allowed and denied traffic for operations and investigation.

• Routing selected traffic through a controlled network path.

Azure Firewall is useful when the network path is part of the control objective. It is not a replacement for application authentication, authorization, input validation, secret management, or secure configuration.

A common pattern is to place Azure Firewall in a hub network and route selected workload traffic through it. That can make central inspection easier, but it also creates operational responsibilities: route table management, resilience design, rule ownership, change review, troubleshooting, and cost management.

Web Application Firewall

Web Application Firewall, usually shortened to WAF, protects web applications from common HTTP-layer attacks when deployed with supported services such as Azure Front Door or Application Gateway.

This is a different job from a network firewall. A network firewall may filter by IP address, port, protocol, or network/application rules. A WAF understands web request patterns and can help protect against common attacks such as SQL injection or cross-site scripting.

Use WAF thinking when the control objective is application-layer protection for public or private HTTP entry points. The design question is not only "Do we have a WAF?" It is also:

• Where is the web entry point?

• Which paths are internet-facing?

• Which rules run in detection mode or prevention mode?

• Who tunes false positives?

• How are WAF logs reviewed during incidents?

• How does WAF fit with application security fixes?

WAF can reduce risk at the edge, but it does not make vulnerable application code safe by itself. It buys protection and visibility while the application team still owns secure design, validation, patching, and testing.

DDoS Protection

Distributed denial-of-service attacks try to make an application unavailable by overwhelming public endpoints or the surrounding infrastructure with attack traffic.

Azure provides platform-level DDoS protection by default, but enhanced Azure DDoS Protection is used when public resources need stronger, workload-aware mitigation and telemetry. This matters most for workloads where internet availability is critical, public IP resources are exposed, or an outage would create major business, safety, or regulatory impact.

DDoS Protection is about availability under attack. It does not replace WAF because WAF protects at the web application layer. It does not replace Azure Firewall because a firewall controls network traffic paths and rules. These controls may be combined for public web workloads:

Private Endpoints and Private Access

Private endpoints give supported Azure services a private IP address in a virtual network. They are commonly used for services such as storage accounts, databases, Key Vault, and messaging services when the design should avoid public data-plane access.

Private endpoints reduce exposure, but they do not replace authorization. A private path answers, "Can this network reach the service privately?" It does not answer, "Is this identity allowed to read the data?" You still need identity, RBAC or service-level permissions, secret management, and logging.

Private endpoint design also depends on DNS. If the application still resolves a service name to the public endpoint, traffic may not follow the path you intended. Private DNS zones and name resolution planning are part of the security design, not an afterthought.

Example: Public Customer API

Imagine a public customer API that stores sensitive records and calls internal services.

A layered traffic design could use:

This design is useful because each control has a reason. The WAF protects web request paths. DDoS Protection protects availability of public resources. Azure Firewall controls selected network paths. Private endpoints reduce public exposure for dependencies. Logs make the controls observable.

Common Mistakes

• Treating a firewall as the whole security architecture.

• Using private endpoints while leaving weak identity or authorization controls in place.

• Confusing WAF rules with network firewall rules.

• Enabling DDoS Protection without understanding which public resources are protected.

• Routing everything through inspection without designing resilience, ownership, troubleshooting, and cost.

• Forgetting DNS when designing private endpoints.

If Someone Asks You

How do Azure Firewall, WAF, and DDoS Protection differ?

A good answer is:

Azure Firewall is for centralized network traffic filtering, routing, and logging. Web Application Firewall is for HTTP-layer protection of web applications and APIs at supported edge or gateway services. DDoS Protection helps mitigate volumetric attacks against protected public resources. Private endpoints reduce public exposure for supported Azure services by giving workloads a private network path. They complement each other, but none of them replaces identity, authorization, secure application code, or response operations.

What You Should Remember

Protect traffic according to where the risk appears: edge, application layer, network path, or private service access.

Questions to Check Your Understanding

1. Why is WAF different from a network firewall?

2. What does private access reduce, and what does it not replace?

3. Why should central inspection be designed with resilience?