CH08-02: Public Entry Points, Routing, and Edge Protection

Goal

The previous section started with the request path. This section zooms in on the first architecture decision in that path: how traffic reaches the application.

The public entry point is easy to underestimate because it can look like a small DNS or HTTPS detail. In production, it is where user traffic first becomes a managed responsibility. It influences routing, TLS certificates, WAF policy, health checks, failover, logging, and who responds when users cannot reach the application.

The durable idea is:

The public entry point is where user traffic first becomes an architecture responsibility.

The Short Version

An entry point is the controlled front door for application traffic.

It usually answers questions like:

Which public name do users call?
Where is HTTPS terminated?
Which requests are allowed, challenged, blocked, or routed?
Which backend should receive each path or host name?
How does the system notice an unhealthy backend?
Where are web attack patterns inspected?
Is the application regional, global, public, private, or some mix?

In Azure web architectures, two names appear often: Azure Front Door and Azure Application Gateway.

Azure Front Door is a global edge service. It sits close to users on Microsoft's global edge network and can provide global HTTP routing, TLS termination, acceleration, health-based routing, and web application firewall protection.

Azure Application Gateway is a regional application delivery controller. It provides layer 7 load balancing, TLS termination, path-based routing, health probes, and web application firewall integration inside a region and virtual network-oriented design.

Those descriptions are useful, but they are not the decision by themselves. The better question is:

Where should application traffic be inspected, routed, and failed over?

Entry-Point Responsibilities

A practical entry layer often carries several jobs at once:

flowchart LR
    U["Users"]
    D["DNS & custom domain"]
    T["TLS / HTTPS"]
    W["WAF policy"]
    R["Routing & health probes"]
    B["Backend web/API runtime"]

    U --> D --> T --> W --> R --> B

This is a logical view. In a real Azure design, one service may carry several of these responsibilities. Front Door can handle custom domains, TLS, WAF, and global routing. Application Gateway can handle TLS, WAF, routing, and health probes for regional application traffic. Some designs use both: Front Door for global edge entry and Application Gateway for regional private application delivery.

Do not add both services automatically. Add the layer because the requirement exists.

Front Door and Application Gateway by Job

The decision is easier when you compare architectural jobs instead of product popularity.

Question	Front Door Often Fits When...	Application Gateway Often Fits When...
Where are users?	Users are spread across regions or countries.	Traffic is mainly regional or enters a specific Azure network.
What routing matters?	The team needs global HTTP routing, acceleration, or health-based routing across backends.	The team needs regional path, host, or backend pool routing inside a virtual network design.
Where should WAF sit?	WAF should inspect traffic at the global edge before it reaches regional backends.	WAF should inspect traffic at a regional gateway close to private application tiers.
What backend placement matters?	Backends may be App Service, Container Apps, APIs, or multiple regional origins.	Backends commonly sit behind regional network controls, private IPs, or internal tiers.
What is the operating concern?	Global routing policy, edge security, certificate ownership, and backend health.	Regional gateway configuration, subnet placement, backend pools, WAF tuning, and network operations.

This table is a starting point, not a fixed rule. A simple public web app may use Front Door directly in front of App Service. A regional enterprise app may use Application Gateway with WAF in front of private backends. A highly available global app may use Front Door in front of regional gateways or regional app backends.

WAF Is Application-Layer Protection

A web application firewall, usually called WAF, is not the same as a network security group or a firewall rule that allows or denies ports.

WAF looks at HTTP and HTTPS traffic for common web attack patterns such as injection attempts, cross-site scripting patterns, suspicious protocol behavior, and malformed requests. It helps protect the application layer, where a normal-looking HTTPS request can still be hostile.

WAF does not remove the need for secure application code, authentication, authorization, input validation, dependency updates, logging, or incident response. It is a protective layer, not a magic shield.

Plan WAF ownership before production:

Who reviews blocked requests?
Who tunes rules when legitimate traffic is affected?
Who decides whether a rule runs in detection or prevention mode?
Who investigates repeated attack patterns?
How are WAF logs connected to application and security monitoring?

Enabling WAF without ownership can create either false confidence or noisy operations.

Example: Retail Web App Entry

Imagine a retail web application with a public website and an API. The team needs HTTPS, a custom domain, WAF protection, health-based routing, and separate routing for /api traffic.

A first-pass entry design might look like this:

Users
  -> DNS: www.example.com
  -> Front Door with TLS and WAF
  -> /      routes to web frontend
  -> /api   routes to account/order API
  -> Health probes remove unhealthy backend from routing

This design is useful when the team wants a global edge entry and can expose approved backend origins safely. If the API backend must be reachable only through a private regional gateway, the design might change:

Users
  -> Front Door with TLS and WAF
  -> Regional Application Gateway
  -> Private web/API backend

That second design adds complexity. It may be justified by private backend placement, enterprise network inspection requirements, or regional gateway standards. If those requirements do not exist, the simpler design may be better.

Common Mistakes

Treating the entry point as only a DNS record.
Choosing Front Door because the word "front" sounds generally correct, without checking global routing needs.
Choosing Application Gateway because the team wants a gateway, without checking whether a global edge entry would better match user traffic.
Enabling WAF without rule tuning, log review, and operational ownership.
Forgetting that TLS certificates, custom domains, health probes, and backend access all need lifecycle management.
Designing a public entry point before deciding which backends should remain private.

If Someone Asks You

How do you choose the public entry point for an Azure web application?

A good answer is:

I start by asking where users are, where the backends live, and where traffic should be protected and routed. Front Door is often a strong fit for global edge entry, HTTP routing, TLS, WAF, and health-based routing across origins. Application Gateway is often a strong fit for regional application delivery, path routing, TLS, WAF, and private network-oriented backends. The right answer depends on reach, routing, backend placement, security ownership, and operations.

What You Should Remember

Entry-point design controls how traffic arrives, how it is protected, and how failures are routed.

Questions to Check Your Understanding

What responsibilities belong at the public entry point?
How is WAF different from general network filtering?
Why does regional versus global traffic matter?
When might a design use both Front Door and Application Gateway?