{"id":11732,"date":"2026-10-07T00:30:02","date_gmt":"2026-10-07T00:30:02","guid":{"rendered":"https:\/\/www.prepaway.com\/certification\/microsoft-az-104-front-door-or-application-gateway\/"},"modified":"2026-10-07T00:30:02","modified_gmt":"2026-10-07T00:30:02","slug":"microsoft-az-104-front-door-or-application-gateway","status":"publish","type":"post","link":"https:\/\/www.prepaway.com\/certification\/microsoft-az-104-front-door-or-application-gateway\/","title":{"rendered":"Microsoft AZ-104: Front Door or Application Gateway?"},"content":{"rendered":"

Azure Front Door and Azure Application Gateway are both Layer 7 services for HTTP and HTTPS, but their scope is fundamentally different. Front Door is a global edge service that accepts traffic at Microsoft’s distributed points of presence, can route across regions, provide CDN acceleration, perform global health-based failover, and apply WAF at the edge. Application Gateway is a regional service deployed with virtual-network integration for regional HTTP routing, TLS termination, backend pools, private addresses, and optional WAF.<\/p>\n

Microsoft’s current internet-ingress guidance recommends Front Door for most multi-region HTTP\/S applications and Application Gateway for regional web applications that need Layer 7 routing or WAF inside a region. The services can also be combined: Front Door handles global edge routing while regional Application Gateways manage VNet-local routing and app-specific policies. Front Door Premium can reach selected origins through Private Link.<\/p>\n

The decision belongs inside Azure Architecture in Practice<\/a>.<\/p>\n

Choose by geographic scope first<\/h3>\n

Front Door is global; Application Gateway is regional.<\/p>\n

Global load balancing<\/a> should be selected when users or origins span regions and the architecture needs edge routing, acceleration, and automatic regional failover.<\/p>\n

A single-region application usually does not need a global edge service unless CDN, edge WAF, or another Front Door feature provides specific value.<\/p>\n

Use Front Door for global HTTP delivery<\/h3>\n

Front Door terminates HTTP\/S close to users on Microsoft’s global edge network and routes requests to healthy origins.<\/p>\n

It can accelerate dynamic web traffic and cache content according to configuration.<\/p>\n

Multi-region applications benefit because failover and latency-based routing happen at the global service instead of through DNS-only behavior.<\/p>\n

Use Application Gateway for regional VNet routing<\/h3>\n

Application Gateway lives in a region and integrates closely with virtual-network backends.<\/p>\n

It supports host and path routing, TLS termination, cookie affinity, custom probes, and private IP destinations.<\/p>\n

Application Gateway design<\/a> is appropriate when the routing decision is regional and the gateway needs direct VNet-level control over backend pools.<\/p>\n

Choose the WAF inspection point<\/h3>\n

Both services offer WAF capabilities, but Front Door WAF evaluates traffic at the global edge while Application Gateway WAF evaluates traffic in the regional gateway.<\/p>\n

Edge WAF can block malicious requests before they reach a region; regional WAF can apply app-specific policy close to the backend.<\/p>\n

Some architectures use both when global and regional policies serve different purposes.<\/p>\n

Use Private Link where supported<\/h3>\n

Front Door Premium can connect to selected origins through Private Link, reducing public exposure of the origin.<\/p>\n

Application Gateway already runs in the virtual-network context and can reach private IP backends directly.<\/p>\n

Private origin access should still use authentication and network policy; hiding the origin from the public internet does not authorize every Front Door or VNet caller.<\/p>\n

Keep TLS ownership clear<\/h3>\n

Front Door and Application Gateway can both terminate TLS, but certificates, custom domains, backend encryption, and trust boundaries differ by service.<\/p>\n

Decide whether TLS terminates at edge, regional gateway, backend, or multiple layers.<\/p>\n

Certificate rotation and backend validation should be automated and monitored at every termination point.<\/p>\n

Combine services when responsibilities differ<\/h3>\n

A common multi-region pattern uses Front Door for global routing and edge WAF, then regional Application Gateway for detailed path routing and private backend integration.<\/p>\n

Current Microsoft guidance supports this layered pattern where each service provides a distinct function.<\/p>\n

Do not stack services automatically; each extra hop adds cost, latency, configuration, and another failure surface.<\/p>\n

Compare health and failover behavior<\/h3>\n

Front Door evaluates origin health globally and can redirect users across regions.<\/p>\n

Application Gateway health probes determine which backends receive traffic inside its region.<\/p>\n

Failure-domain design<\/a> should test both levels so a healthy global route does not point to a regional gateway whose backend dependencies are unavailable.<\/p>\n

Choose from the user flow<\/h3>\n

For AZ-305<\/a>, the durable decision is global or regional \u2192 HTTP routing needs \u2192 WAF inspection point \u2192 private-origin requirements \u2192 CDN\/acceleration \u2192 resilience.<\/p>\n

Front Door is not \u201cApplication Gateway at global scale,\u201d and Application Gateway is not \u201cFront Door inside a VNet.\u201d Their responsibilities overlap at Layer 7 but their network position and operational scope differ.<\/p>\n

Cost models also differ. Front Door includes edge\/request and data-transfer economics, while Application Gateway has regional gateway capacity and runtime cost. Compare them with expected request volume, regions, CDN behavior, WAF, and architecture complexity rather than one headline price.<\/p>\n

Observability should preserve client IP, edge\/gateway health, routing decision, WAF action, backend latency, TLS status, and origin response. When both services are chained, correlation IDs and forwarded headers help operators follow one request through the edge and regional layers.<\/p>\n

Front Door Classic and legacy gateway versions should not drive new architecture. Use current Standard\/Premium Front Door and Application Gateway v2 families according to Microsoft’s present lifecycle guidance.<\/p>\n

The best ingress design is the fewest layers needed to meet global reach, private integration, application routing, WAF, performance, and recovery requirements.<\/p>

Origin placement is one of the biggest architectural differences. Front Door origins can be in multiple Azure regions or even outside Azure, while Application Gateway typically fronts backends reachable from its regional network context. This makes Front Door a natural global entry point and Application Gateway a natural regional application-routing layer.<\/p>\n

Front Door’s anycast edge presence can reduce latency for globally distributed users by terminating connections close to the client and using Microsoft’s backbone toward the origin. Application Gateway does not provide that global edge acceleration because it is deployed in an Azure region.<\/p>\n

CDN functionality also differentiates the services. Front Door can cache appropriate content at edge locations, reducing origin load and latency. Application Gateway focuses on regional routing and does not function as a global CDN.<\/p>\n

Private-origin architecture should be planned carefully. Front Door Premium supports Private Link to selected Azure origins, which can remove public origin exposure while keeping a global edge frontend. Application Gateway can reach private IP addresses directly inside the VNet or connected networks. These are different private-connectivity models with different DNS, approval, and operational flows.<\/p>\n

WAF policy scope should match organizational responsibility. Edge WAF can provide a common global baseline, while regional Application Gateway WAF can add application-specific rules or exclusions. If both are used, document which layer owns each rule so duplicated blocking or conflicting exceptions do not become difficult to troubleshoot.<\/p>\n

Rate limiting and bot protection options differ by Front Door tier and WAF platform capabilities. Verify current tier-specific features before choosing a service solely from a feature checklist, especially for Standard versus Premium Front Door.<\/p>\n

Multi-region failover should be tested with origin health probes and realistic application dependencies. Front Door can route away from an unhealthy origin, but if both regions depend on the same database, identity provider, or private WAN, global routing does not create true regional independence.<\/p>\n

Application Gateway is often the better place for deeply regional behavior such as complex path maps, private backend pools, or application-specific certificate handling close to the workload. Front Door can remain the global distribution layer when those regional requirements exist in multiple regions.<\/p>\n

The services can be combined with Azure Firewall or other network controls, but every extra hop should have a defined purpose. A chain of Front Door \u2192 Firewall \u2192 Application Gateway \u2192 backend can be justified in some regulated architectures, while in others it creates redundant inspection and troubleshooting complexity.<\/p>\n

Client-IP preservation and forwarded headers should be understood when multiple proxies are chained. Applications, WAF logs, and fraud systems may need the original client address. Test the actual headers produced through the selected topology and configure trusted-proxy behavior explicitly.<\/p>\n

Health probes should be tied to service readiness. A regional gateway can report healthy while a database dependency is down, or Front Door can see an Application Gateway listener as healthy while the business transaction fails. Use probe endpoints that represent enough application depth to route users safely without creating expensive synthetic load.<\/p>\n

Deployment and configuration lifecycle also differ. Front Door is a global resource with edge propagation, while Application Gateway changes affect a regional gateway. Change windows, rollback, and test environments should reflect the service’s propagation and blast radius.<\/p>\n

For architecture reviews, draw the full request flow from user DNS to edge, optional WAF, regional gateway, backend, private services, and response. The correct service choice becomes obvious when each layer’s scope and responsibility are explicit.<\/p>\n

Use Front Door when the problem is global web delivery; use Application Gateway when the problem is regional application delivery; use both only when both problems genuinely exist.<\/p>\n

Application-delivery security also includes DDoS and origin protection. Front Door absorbs traffic at the edge and can reduce direct origin exposure, while Application Gateway public IPs sit in a regional design that can use Azure DDoS Protection according to the broader network architecture. WAF and DDoS solve different threat classes and should be planned separately.<\/p>\n

Front Door Standard and Premium have different WAF and Private Link capabilities. Verify the current tier requirement for managed rule sets, bot protection, and private origins before committing to the service. A design that depends on Premium-only features should include that cost and lifecycle explicitly.<\/p>\n

Regional data-sovereignty requirements can influence the decision. Some workloads intentionally keep processing and inspection inside a region, making Application Gateway plus regional routing more appropriate than a global edge service. Compliance constraints should be written before performance optimization.<\/p>\n

Keep ingress architecture under lifecycle review. New regions, private-origin options, WAF capabilities, and application changes can make a previously justified two-layer design unnecessary\u2014or make a simple regional gateway insufficient for a now-global service.<\/p>","protected":false},"excerpt":{"rendered":"

Azure Front Door and Azure Application Gateway are both Layer 7 services for HTTP and HTTPS, but their scope is fundamentally different. Front Door is a global edge service that accepts traffic at Microsoft’s distributed points of presence, can route across regions, provide CDN acceleration, perform global health-based failover, and apply WAF at the edge. Application Gateway is a regional service deployed with virtual-network integration for regional HTTP routing, TLS termination, backend pools, private addresses, and optional WAF. Microsoft’s current internet-ingress guidance recommends Front Door for most multi-region HTTP\/S applications…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-11732","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t