Public Entry, Routing, and Edge Protection

Goal

The previous section started with the request path. This section zooms in on the first boundary in that path: where traffic enters the system and becomes the application's responsibility.

Public entry is easy to underestimate. It can look like DNS, TLS, or a load-balancing detail. In production, it shapes routing, protection, failover, logging, certificate ownership, security review, and user-visible availability.

The durable idea is:

Public entry is the controlled doorway between users and application capability.

The Short Version

The public entry layer usually answers these questions:

• What name do users call?

• Where is TLS terminated or passed through?

• Which requests are routed to which backend?

• Which requests should be cached, redirected, blocked, challenged, or inspected?

• How is an unhealthy backend removed from traffic?

• Which logs show traffic, routing, denied requests, and suspicious patterns?

• Who owns certificates, WAF policy, routing rules, and incident response?

Different provider services can implement these responsibilities. The pattern is the controlled doorway, not the product name.

Entry Responsibilities

Use this logical model before naming provider products:

User
  -> DNS and public entry
  -> TLS and edge policy
  -> Routing decision
  -> Application runtime

In a simple system, one service may carry most of these responsibilities. In a more complex system, global edge entry, regional gateway routing, application load balancing, WAF policy, and API gateway behavior may be split across layers.

Do not add layers because they look complete in a reference diagram. Add a layer because it carries a clear responsibility.

Routing and Protection

Routing answers where the request should go. Protection answers which requests should be allowed to continue.

Routing can use host names, paths, headers, health probes, geography, deployment version, or backend availability. A storefront might route static assets differently from dynamic pages, API calls differently from page views, and admin traffic differently from public traffic.

Protection can include TLS policy, WAF rules, bot and abuse controls, rate limits, request size limits, header checks, and basic protocol validation. The goal is not to make the entry layer responsible for all security. The goal is to reduce unsafe or unwanted traffic before it reaches application code.

A web application firewall, often called WAF, inspects HTTP and HTTPS traffic for common web attack patterns. It is different from a basic network rule that only allows or denies ports. WAF does not replace secure code, authentication, authorization, input validation, dependency updates, or incident response. It is one protective layer in a broader design.

Edge Versus Runtime

Some decisions belong near the edge, before the application runtime handles the request. Others belong inside the application.

The edge should not become a place where hidden business logic accumulates. It should protect and route the request so the application can focus on application behavior.

Example: Storefront Entry

Consider a commerce storefront with global users. The site serves public product pages, static images, authenticated cart actions, checkout calls, and account APIs.

A first entry model might look like this:

www.example.com
  -> Public entry with TLS and WAF
  -> /assets/* routes to static content
  -> /products/* routes to web runtime
  -> /api/cart/* routes to cart API
  -> /api/checkout/* routes to checkout API

Not every path needs the same treatment. Static assets may benefit from caching. Checkout should avoid unsafe caching and needs stronger identity and monitoring. Admin routes may need different access rules or might not be publicly exposed at all.

Health matters too. If one backend is unhealthy, the entry layer should know whether to stop sending traffic there, route to another origin, show a controlled error, or degrade part of the experience. That decision belongs in the architecture, not only in runtime configuration.

Operating the Entry Layer

Public entry creates ongoing ownership:

• certificate renewal and custom domain validation;

• routing rule changes;

• WAF rule tuning and false-positive review;

• traffic logs and security logs;

• health probe behavior;

• incident response when users cannot reach the application;

• cost review for traffic, routing, caching, logs, and data transfer.

If nobody owns these, public entry becomes an invisible risk. A misconfigured certificate, noisy WAF rule, broken route, or unhealthy backend probe can become a production incident even when the application code is fine.

Common Mistakes

• Treating public entry as only a load balancer.

• Adding edge protection without clear ownership of rules and false positives.

• Letting routing logic become invisible across several products.

• Ignoring how public-entry costs grow with traffic, rules, logs, and data transfer.

• Putting business workflow logic at the edge because it is convenient.

If Someone Asks You

What should a public entry layer do for a web application?

A good answer is:

It should provide a controlled doorway for traffic. That means naming where users connect, handling TLS and routing, applying appropriate edge protection, sending requests to healthy backends, emitting useful logs and metrics, and giving owners a clear place to manage certificates, rules, failover, and incident response.

What to Remember

Public entry should protect and route the request before the application has to handle it.

Questions to Check Your Understanding

1. Which responsibilities can belong at the public entry layer?

2. Why should routing and protection be discussed before provider service names?

3. How can public-entry choices affect operations and cost?

4. What should stay in the application instead of being pushed into the entry layer?