Azure Application Gateway: The Smart Front Door for Your Web Apps
A beginner-friendly guide to Azure Application Gateway, the service that receives web traffic, protects it, understands it and sends it to the right server, explained step by step with everyday analogies.
Imagine a large hospital with many departments. Visitors do not walk straight into the operating theatre or the pharmacy. They first meet a reception desk. The receptionist asks why they came, checks whether they are allowed in, and sends them to the correct floor. If one department is closed for cleaning, the receptionist quietly sends visitors to another one that is open. Azure Application Gateway is the reception desk of a web application.
In this guide we start from the beginning, with the question “what happens when you open a website?”, and build up to routing rules, encryption, firewalls, scaling and real company designs. No earlier knowledge is assumed. Each new word is explained the first time it appears, usually with a simple comparison from daily life.
1What Is Azure Application Gateway?
Application Gateway is a managed web traffic load balancer that works at the level of web requests.
When you type a website address into a browser, the browser sends a request over the internet. That request is written in a language called HTTP, or HTTPS when it is encrypted. A web server reads the request and sends back a page or some data. A small website can run on one server, but a popular website needs many servers, because one machine cannot answer millions of visitors.
A load balancer is a service that stands in front of the servers and shares the visitors among them, so no single server is overwhelmed. Application Gateway is a special kind of load balancer that understands web traffic. It can look inside each request and read details such as the website name and the page path. Because of that, it can make clever decisions, like sending image requests to one group of servers and payment requests to another.
It is a managed service, which means Microsoft runs and updates the machines that power it. You describe how traffic should be handled, and Azure takes care of the heavy lifting, including adding more capacity when traffic grows.
Think of a restaurant host at the entrance. A simple greeter just points guests at any free table. A smart host asks whether you want the family hall, the rooftop or the takeaway counter, checks your booking and your dress code, then leads you to the right place. Application Gateway is the smart host.
Words you will meet again and again
Listener
The part that waits for incoming requests on a chosen address, port and website name.
Routing Rule
Connects a listener to a backend pool and decides how requests are directed.
Backend Pool
The group of servers or services that finally handle the requests.
Health Probe
A regular check that tells the gateway whether each backend server is healthy.
TLS Termination
Decrypting secure traffic at the gateway instead of at every server.
Web Application Firewall
An optional shield that blocks common web attacks before they reach your servers.
The current generation is called v2, and it is the one you should use. The older v1 generation is being retired by Microsoft, so any article that recommends v1 is out of date.
2Why Does It Exist?
Simple load balancing is not enough for modern web applications.
A basic load balancer works at a lower level. It only sees the address and port of a connection and cannot read the web request. It is fast and simple, but it treats all traffic the same way. If a company wants to host a shop, a blog and an admin panel behind a single public address, a basic load balancer cannot tell them apart.
Modern applications also need security. Attackers send harmful requests, such as attempts to trick a database into giving up secrets. Encrypting traffic costs processing power on every server. And applications are often split into many small services, each one living at a different path of the same website. All of these needs call for a gateway that understands web traffic in depth.
Many websites behind one address
One gateway can serve dozens of website names, each routed to its own set of servers, saving public addresses and money.
Path-based splitting
Requests for pictures, videos or an API can be sent to dedicated servers tuned for those jobs.
Central encryption
Certificates are managed at one place, instead of being installed and renewed on every single server.
Built-in protection
A web application firewall can stop common attacks at the door, before they ever touch your code.
High availability
Unhealthy servers are removed from rotation automatically, so visitors do not meet error pages.
3The Building Blocks of a Gateway
A gateway is made of a handful of parts, and each one has a single clear job.
Frontend IP
The address that visitors use to reach the gateway. It can be a public address, a private address inside your network, or both.
Listeners
Each listener watches one port and, optionally, one website name, and accepts requests that match.
Routing rules
A rule links a listener to a backend, or tells the gateway to redirect, and may split by path.
Backend settings
Describe how the gateway talks to the backend: which port, whether to use encryption, how long to wait.
Backend pools
The list of servers, virtual machine scale sets, app services or addresses that receive the requests.
Health probes
Regular test requests that confirm each backend is alive and answering correctly.
flowchart LR
U["Visitor Browser"] --> F["Frontend IP"]
F --> L["Listener"]
L --> R["Routing Rule"]
R --> BS["Backend Settings"]
BS --> BP["Backend Pool"]
BP --> S1["Server 1"]
BP --> S2["Server 2"]
BP --> S3["Server 3"]
In a courier company, the front counter is the frontend, the clerk who reads the label is the listener, the sorting chart is the routing rule, the loading instructions are the backend settings, and the delivery vans are the backend pool.
4Inside the Machine: How a Request Travels
Following one request from the browser to the server shows how everything fits together.
The gateway is a reverse proxy. That means it sits in front of your servers and speaks to visitors on their behalf. Visitors never connect directly to your servers. Instead, they connect to the gateway, and the gateway opens a second, separate connection to a backend server. This is why the gateway can inspect, filter and change traffic along the way.
Name lookup
The browser asks DNS for the address of the website. DNS answers with the gateway’s address.
Secure connection
The browser connects to the gateway and sets up an encrypted session. The gateway shows its certificate to prove its identity.
Inspection
The gateway reads the request. If a firewall is enabled, the request is checked against attack rules.
Rule matching
The gateway finds the listener and the routing rule that match the website name and the path.
Server selection
From the chosen pool, the gateway picks a healthy server, using a round-robin approach that shares requests evenly.
Response return
The server replies to the gateway, which sends the answer back to the browser through the encrypted session.
sequenceDiagram
participant B as Browser
participant D as DNS
participant G as Application Gateway
participant S as Backend Server
B->>D: Where is shop.example.com?
D-->>B: Gateway address
B->>G: Secure request for /cart
G->>G: Firewall check and rule match
G->>S: Forward request to healthy server
S-->>G: Response
G-->>B: Response over secure session
A secretary takes your call, understands your request, and then makes a separate call to the right expert to get the answer. You never speak to the expert directly, which lets the secretary screen unwanted calls and take notes.
Because the gateway makes a new connection, the server sees the gateway’s address instead of the visitor’s. The gateway therefore adds a header named X-Forwarded-For that carries the original visitor address, and applications can read it for logging.
5Listeners: Who Is Knocking?
A listener is the ear of the gateway, waiting for requests on a particular door.
Every listener is tied to a frontend address and a port. Web traffic normally arrives on two well-known doors, one for plain HTTP and one for secure HTTPS. A listener can also hold a certificate when it serves secure traffic. There are two main types of listeners.
Basic Listener
Accepts all requests that arrive on a port, whatever website name they ask for. Good for one website per port.
Multi-Site Listener
Accepts only requests for specific website names, such as shop or blog. Lets one gateway host many websites on the same port.
A basic listener is a receptionist who answers every call the same way. A multi-site listener is a receptionist who greets callers differently depending on which company number they dialled.
A multi-site listener can use a wildcard host name, so one listener can handle many sub-sites of a domain. This is useful for platforms where each customer receives their own sub-site.
Putting a basic listener and a multi-site listener on the same port and expecting them to share nicely. Plan your website names early and use multi-site listeners whenever more than one site may ever share the gateway.
6Routing Rules: Deciding Where Requests Go
The routing rule is the brain of the gateway.
Each rule links one listener to a destination. The destination is either a backend pool or a redirect to somewhere else. There are two styles of rules, and understanding them is the key to using the gateway well.
Basic routing rule
Every request that arrives at the listener goes to the same backend pool. Simple and perfect when one group of servers handles the whole website.
Path-based routing rule
The rule looks at the path in the address, the part after the website name. A request for the images path goes to one pool, a request for the API path goes to another, and everything else goes to a default pool.
flowchart TD
L["Listener: shop.example.com"] --> R{"Path-based Rule"}
R -->|"/images/*"| P1["Image Servers Pool"]
R -->|"/api/*"| P2["API Servers Pool"]
R -->|"everything else"| P3["Web Servers Pool"]
In a big railway station, the signboards tell you whether to go to platform one for local trains or to platform five for express trains. The gateway is the signboard, and the paths are the train names.
Redirection
A rule can also redirect visitors. The most common example is sending everyone who arrives over insecure HTTP to the secure HTTPS version of the same page. This protects visitors without needing any change in your servers. Redirects can also move old website names to new ones.
Always include a default pool in a path-based rule, so that unexpected paths still reach a server that can show a friendly page instead of an error.
7Backend Pools and Backend Settings
The backend is where the real work happens, and the gateway needs clear instructions for talking to it.
A backend pool can hold many kinds of targets. Each target is one possible destination for a request, and the gateway shares requests among the healthy ones.
Virtual Machines
Ordinary servers, listed by their network cards or private addresses.
Scale Sets
Groups of identical machines that grow and shrink with demand. The gateway sees new machines automatically.
App Services
Managed web hosting on Azure, reached through its name.
Addresses and Names
Any reachable private or public address or domain name, including servers in an office connected to Azure.
Backend settings
Backend settings tell the gateway how to talk to the pool. They contain the port to use, whether the connection should be encrypted again, how long to wait before giving up on a slow server, and whether visitors should stick to the same server. They also decide what website name the gateway presents to the backend, which matters a lot for services like app services that expect a particular name.
Session affinity
When switched on, the gateway uses a small cookie to send the same visitor to the same server on every request. This helps applications that store a visitor’s shopping basket in the memory of one server. It is better to store such data in a shared place, so any server can handle any visitor.
Connection draining
When a server is being removed, the gateway lets the requests already in progress finish before stopping new ones. Visitors do not see broken pages during updates.
Request timeout
The maximum time the gateway waits for a server to answer. Too short and slow but valid answers are cut off. Too long and visitors wait while a broken server hangs.
Overriding the host name incorrectly for app services. If the backend receives the wrong name, it may redirect visitors back to its own address and bypass the gateway entirely. Test that links and redirects keep the gateway’s name.
8Health Probes: Is the Server Alive?
A good gateway never sends visitors to a server that is broken.
The gateway regularly sends small test requests to every backend server. This is called a health probe. If a server answers correctly, it is marked healthy. If it fails to answer, or answers with an error, a number of times in a row, the gateway marks it unhealthy and stops sending visitors to it. When the server recovers and passes the probe again, it is put back into rotation automatically.
flowchart LR
G["Application Gateway"] -->|"probe every few seconds"| A["Server A: healthy"]
G -->|"probe every few seconds"| B["Server B: failing"]
G -->|"probe every few seconds"| C["Server C: healthy"]
V["Visitors"] --> G
G -->|"traffic"| A
G -->|"traffic"| C
A taxi dispatcher regularly calls each driver. If one driver does not answer, the dispatcher stops sending passengers to that car until the driver calls back.
Default and custom probes
If you do nothing, the gateway uses a default probe that tests the main page of the server. A custom probe lets you choose a specific path, such as a special health page that checks the database and other dependencies, and set how often to test, how long to wait, and what counts as a good answer.
Create a dedicated health page in your application that returns a simple success answer only when the application can truly do its job. A probe that only checks that the web server is running will happily send visitors to an application whose database is down.
If every server in a pool is marked unhealthy, visitors receive a gateway error. Common causes are firewall rules that block the probe, a wrong probe path, or an application that requires a login on the health page. Check these first when everything suddenly looks unhealthy.
9Encryption: TLS Termination and End-to-End TLS
Encrypting traffic protects visitors, and the gateway gives you two ways of doing it.
HTTPS keeps traffic private using TLS, a system that scrambles data so that nobody between the browser and the server can read it. To use TLS, a server needs a certificate, which is a digital identity card issued by a trusted authority. Managing certificates on many servers is tiring and error-prone, so the gateway can take over this job.
TLS Termination
The gateway decrypts incoming traffic, inspects it and sends it to the backend as plain HTTP inside your private network. Servers do less work and certificates live in one place.
End-to-End TLS
The gateway decrypts traffic to inspect it, then encrypts it again before sending it to the backend. Data is protected on the whole journey.
| Question | TLS Termination | End-to-End TLS |
|---|---|---|
| Traffic inside your network | Plain, not encrypted | Encrypted again |
| Backend server effort | Low | Higher, needs certificates on servers |
| Best for | Simple apps in a trusted private network | Sensitive or regulated data, strict compliance |
| Firewall can inspect traffic | Yes | Yes |
Termination is a security guard who opens a sealed envelope at the building entrance, checks it, and hands the loose letter to the office. End-to-end TLS is the same guard who checks the letter and then seals it in a new envelope before it travels inside the building.
Certificates and Key Vault
Certificates expire, and an expired certificate makes browsers show scary warnings. The gateway can read certificates directly from Azure Key Vault, a safe storage place for secrets. When the certificate in Key Vault is renewed, the gateway picks up the new version automatically, so renewals do not require manual uploads.
Forgetting to renew a certificate that was uploaded by hand. The website then fails for every visitor on the expiry day. Use Key Vault with automatic renewal, and create an alert that warns weeks before any expiry.
10Web Application Firewall: The Security Guard
The Web Application Firewall, called WAF, protects your websites from common attacks.
Attackers often hide harmful instructions inside ordinary-looking web requests. One famous trick is to type database commands into a login box, hoping the website will run them. Another is to inject scripts into a page, to steal the data of other visitors. These are among the most common attacks on the internet, and they are listed in a famous security list known as the OWASP Top Ten.
The WAF version of Application Gateway compares every request with a large set of rules, called the core rule set. It is built on rules maintained by the OWASP community, and Microsoft updates the rule sets over time. Requests that look harmful are blocked or logged, depending on the mode you choose.
Detection Mode
Suspicious requests are only recorded in the logs, not blocked. Perfect for learning what normal traffic looks like.
Prevention Mode
Suspicious requests are blocked and the visitor sees an error. This is the mode for real protection.
Start in detection mode
Switch the WAF on and watch what it would block, without disturbing any real visitor.
Review the logs
Look for requests flagged by mistake, called false positives, such as a legitimate form that contains special characters.
Tune with exclusions
Add narrow exceptions for specific fields or paths where the rules wrongly block good traffic, instead of switching off whole rules.
Move to prevention mode
Once the false positives are under control, turn on blocking and keep monitoring.
Extra WAF abilities
Custom rules
Write your own rules, such as blocking visitors from certain countries, limiting how often one address may send requests, or allowing only your office addresses to reach an admin page.
Bot protection
Rules that recognise known harmful automated programs, such as scrapers and scanners, while allowing helpful ones such as search engine crawlers.
WAF policies
Settings live in a policy object that can be attached to the whole gateway, to a single listener or to a single path, so different websites can have different protection levels.
A WAF reduces risk but is not a magic cure. Applications must still be written securely, and the WAF is one layer among several. Never turn off a rule permanently just because it is inconvenient; adjust it with a precise exclusion instead.
11Rewrites and Redirects: Changing Traffic on the Fly
The gateway can modify requests and responses so that your applications do not have to.
Sometimes you want to adjust a message while it passes through. Rewrite rules let the gateway add, change or remove headers, which are small labelled notes that travel with every request and response. They can also change the address of a request before it reaches the backend.
Add Security Headers
Add headers that instruct browsers to behave safely, such as always using HTTPS, without touching application code.
Hide Server Details
Remove headers that reveal which software the backend uses, because such details help attackers.
Change the Path
Map a friendly public path to a different internal path, so the outside address stays clean while the application stays unchanged.
Pass Information
Add headers that tell the application useful facts, such as the original visitor address or the original host name.
A mailroom clerk can stamp extra notes on envelopes, cover up an internal department name, or re-address a parcel so it reaches the correct desk, all without the sender or the receiver having to do anything.
Rewrites are most valuable when you cannot easily change the application, such as software bought from a vendor. For your own code, fixing the application directly is usually cleaner.
12Scaling, Zones and Availability
A front door that breaks during a sale is worse than no front door at all.
The v2 generation of the gateway can scale automatically. Capacity is measured in capacity units, a blend of how many connections, how much data and how much computing the gateway handles. You set a minimum and a maximum, and the gateway adds or removes instances as traffic changes. Scaling up takes a short while, so keeping a sensible minimum helps with sudden spikes.
Availability zones
In regions that offer availability zones, the gateway can place its instances in different zones, which are separate buildings with independent power and cooling. If one zone has a problem, the gateway keeps working from the others. A zone-redundant gateway is the standard choice for important production systems.
flowchart TD
U["Visitors"] --> VIP["Static Public IP"]
VIP --> G1["Gateway Instance in Zone 1"]
VIP --> G2["Gateway Instance in Zone 2"]
VIP --> G3["Gateway Instance in Zone 3"]
G1 --> B["Backend Pool across zones"]
G2 --> B
G3 --> B
A large mall opens extra checkout counters when the queue grows, and closes them when it shrinks. Counters in three separate wings mean that a water leak in one wing does not stop the whole mall from billing customers.
You pay a fixed hourly charge for the gateway plus a charge based on the capacity units used. Autoscaling therefore helps control cost, but a high minimum means you always pay for it. Choose a minimum that covers normal traffic, not the biggest peak of the year.
Placing a zone-redundant gateway in front of a backend that lives in only one zone. The gateway survives a zone failure, but the application behind it does not. Spread both layers.
13Networking Needs: The Dedicated Subnet
The gateway lives inside your virtual network, in a subnet reserved for it.
Application Gateway runs as a group of instances, and each instance takes a private address from its subnet. For this reason it needs a subnet of its own, which holds only gateways and nothing else. A generously sized subnet is recommended for v2, so that autoscaling always finds free addresses. A smaller subnet may run out of addresses just when you need to scale up.
Dedicated Subnet
Do not place servers or other services in the gateway’s subnet.
Room to Scale
Plan for many more addresses than you need today, so autoscaling and upgrades never run out of space.
Reserved Ports
Azure uses a range of ports for gateway management. Security rules on the subnet must not block them, or the gateway will fail.
Careful Routes
Custom routes on the gateway subnet can break its management traffic, so test any change carefully.
Public, private or both
A gateway can have a public frontend for visitors from the internet, a private frontend for applications that only your internal network and connected offices may reach, or both. Internal gateways are very common for company portals and for services that sit between different parts of a private system.
A company’s reception area has its own entrance hall that is kept free of storage boxes and office desks, so visitors flow in smoothly. Putting other things in that hall would block the crowd on busy days.
Writing a network security rule that denies everything except web ports on the gateway subnet. This blocks the management ports and the load balancer’s health checks, and the gateway shows as unhealthy. Always keep the required infrastructure rules.
14Security: Layers Around the Gateway
The gateway is a strong front door, but it works best as part of several layers.
Edge protection
Enable DDoS protection on the public address, to absorb floods of fake traffic that aim to knock the website offline.
WAF in prevention mode
Block common attacks, use bot protection and add custom rules for rate limiting and country filtering where needed.
Modern TLS only
Require a recent version of TLS and strong ciphers, and redirect plain HTTP to HTTPS.
Private backends
Keep servers on private addresses and allow them to accept traffic only from the gateway’s subnet.
Secrets in Key Vault
Store certificates in Key Vault and give the gateway an identity with the minimum permission to read them.
Logging and alerts
Record firewall and access logs, and alert on spikes of blocked requests or errors.
A secure office has a gate guard, a bag scanner, a reception desk and locked doors inside. The gateway acts as the gate and scanner, and your network rules and application checks are the inner doors.
Protecting the gateway with a WAF while leaving the backend servers reachable directly from the internet. Attackers will simply go around the front door. Make sure the only way to reach the servers is through the gateway.
15Monitoring, Logging and Troubleshooting
When visitors see an error page, quick answers come from good logs and metrics.
Azure Monitor collects numbers about the gateway, such as how many requests it handles, how long backends take to answer, how many servers are healthy, and how many requests failed. You can draw charts, build dashboards and create alerts that send a message when numbers cross a limit.
Access Log
One entry for each request, showing who asked, which path, which server answered, how long it took and the response code.
Firewall Log
Records each request that the WAF blocked or flagged, and which rule was responsible.
Performance Log
Shows how the instances are performing and how traffic is distributed among them.
Backend Health
A live view of which servers are healthy and the reason why any are marked unhealthy.
Reading common error codes
| Code | Usual meaning | First thing to check |
|---|---|---|
| 502 | Bad gateway: the backend gave no valid answer | Probe status, backend port, certificate trust, firewall on servers |
| 503 | Service unavailable: no healthy backend | Are all servers marked unhealthy, and why |
| 504 | Gateway timeout: the backend was too slow | Request timeout setting and server performance |
| 403 | Forbidden: often blocked by the WAF | Firewall log for the matched rule |
Begin with backend health. Most problems turn out to be unhealthy servers, a wrong probe or a blocked network path. Then check certificates and timeouts, and finally the WAF logs.
16Application Gateway Compared with Its Neighbours
Azure has several traffic services, and picking the right one saves effort and money.
| Service | Works at | Scope | Best for |
|---|---|---|---|
| Application Gateway | Web requests (layer 7) | One region | Smart routing, WAF and TLS for web apps in a region |
| Azure Load Balancer | Connections (layer 4) | One region | Fast, simple balancing of any kind of traffic |
| Azure Front Door | Web requests (layer 7) | Global edge network | Worldwide web apps with caching, acceleration and global failover |
| Traffic Manager | DNS answers | Global | Directing users to different regions through DNS |
Traffic Manager is a signboard on the highway that points cities to different branches of a company. Front Door is a network of reception desks in every country. Application Gateway is the smart reception desk inside one building, and Load Balancer is a simple door that spreads people across corridors.
Use Application Gateway when
Your web application lives in one region, needs path or host-based routing, and you want a WAF and central TLS inside your own network.
Use Front Door when
Your users are all over the world and you want edge caching, faster delivery and failover between regions.
Combine them when
You want global reach and local control. Front Door receives traffic worldwide at the edge, and a private Application Gateway in each region provides detailed routing close to the servers.
Use Load Balancer when
The traffic is not web traffic at all, or when you only need simple, very fast distribution without reading requests.
17Design Patterns That Work Well
These layouts appear again and again in successful production systems.
Pattern: Shared Gateway for Many Sites
One gateway with multi-site listeners serves many website names, each with its own pool and certificate. This reduces the number of gateways to pay for and manage.
Pattern: Microservices by Path
An application split into small services uses path-based routing, so that the orders path, the users path and the payments path each reach their own service.
Pattern: WAF at the Edge, Private Servers Inside
The gateway holds the only public address, the WAF filters traffic, and all servers live on private addresses in separate subnets.
Pattern: Ingress for Kubernetes
The gateway can act as the entry point for a Kubernetes cluster. A controller inside the cluster keeps the gateway’s rules in step with the cluster’s services, so new applications are published automatically.
Pattern: Blue-Green Release
Two identical sets of servers, blue and green, sit behind the gateway. The new version is tested on the idle set, and traffic is switched across by changing the routing rule, with an instant way back if something fails.
flowchart TD
I["Internet"] --> FD["Global Edge Service"]
FD --> AG["Regional Application Gateway with WAF"]
AG --> W["Web Subnet"]
AG --> API["API Subnet"]
API --> DB["Data Subnet"]
18Real-World Examples
Gateways of this kind sit in front of many sites you may use every day.
Online retail during sales
A shop uses path-based routing so that product images are served by one pool and checkout by another. The WAF blocks automated scanners, and autoscaling handles the rush of a festival sale.
Banks and insurers
Customer portals sit behind a gateway with a strict WAF policy and end-to-end encryption. Internal staff portals use a private gateway reachable only from the corporate network.
Software-as-a-service platforms
Each customer gets a sub-site name. A wildcard listener and one shared gateway route each name to the correct application group.
Hospitals and public services
Citizen and patient portals use the WAF to meet security requirements, while health probes make sure that services remain available throughout the day.
Media and publishing
News sites route article requests and video requests to separate server groups, tuned for each kind of content, and survive breaking-news traffic spikes with autoscaling.
Company intranets
An internal-only gateway publishes several internal tools under one address, with certificates managed centrally in Key Vault.
Advantages
- Understands web requests for smart host and path routing
- Built-in WAF with attack protection
- Central TLS handling with Key Vault integration
- Autoscaling and zone redundancy in v2
- Health probes remove failing servers automatically
Disadvantages / Trade-offs
- Works within one region, so global reach needs another service
- Costs more than a simple load balancer, especially with the WAF
- Needs its own dedicated subnet and careful network rules
- Only handles web protocols, not every kind of traffic
- Misconfigured probes or host names can cause confusing errors
19Anti-Patterns to Avoid
These shortcuts regularly lead to outages, attacks and surprise bills.
Problem
The WAF is left in detection mode forever, because nobody had time to tune it.
Why It’s Harmful
Detection mode only records attacks. Everything harmful still reaches the application, giving a false sense of safety.
Correct Approach
Use detection mode as a short learning phase, tune with precise exclusions, then switch to prevention mode and keep reviewing the logs.
Problem
Backend servers keep public addresses, so people can reach them directly and skip the gateway.
Why It’s Harmful
Attackers bypass the WAF and the routing rules entirely. The gateway protects nothing if the side door is open.
Correct Approach
Keep servers private and allow incoming traffic only from the gateway’s subnet.
Problem
The default health probe is used, which only checks the front page, and the application has hidden failures behind it.
Why It’s Harmful
The gateway keeps sending visitors to servers that appear healthy but cannot reach their database. Visitors see errors while the gateway believes all is well.
Correct Approach
Create a custom probe that points to a meaningful health page, and tune the interval and thresholds.
Problem
Certificates are uploaded by hand and their expiry dates are tracked in somebody’s calendar.
Why It’s Harmful
A missed renewal brings the whole website down with browser warnings, usually at the worst possible time.
Correct Approach
Store certificates in Key Vault with automatic renewal and let the gateway read them from there. Add alerts for upcoming expiry.
Problem
Applications depend on session affinity because they keep visitor data in the memory of one server.
Why It’s Harmful
When that server restarts or fails, every visitor sticking to it loses their session. Load also becomes uneven across servers.
Correct Approach
Store session data in a shared cache or database so any server can serve any visitor, and use affinity only when you truly must.
20Best Practices and a Starter Checklist
Walk through these steps when setting up a new gateway.
Choose v2 with zones
Use the current generation, spread across availability zones, with autoscaling set to a sensible minimum and maximum.
Plan the subnet
Give the gateway a dedicated, generously sized subnet and keep required management traffic open.
Design listeners and rules clearly
Use multi-site listeners for several websites, path-based rules where needed, and always include a default pool.
Write meaningful probes
Point probes at a real health page and tune timing so failures are detected quickly without false alarms.
Secure the traffic
Redirect HTTP to HTTPS, use modern TLS, keep certificates in Key Vault and use end-to-end TLS for sensitive data.
Enable and tune the WAF
Start in detection mode, tune exclusions, then move to prevention and add custom rules and bot protection.
Lock down the backends
Keep servers private and accept traffic only from the gateway.
Monitor and automate
Send logs to Log Analytics, create alerts on unhealthy hosts, error rates and certificate expiry, and define the gateway in repeatable templates rather than manual clicks.
Choosing the retired v1 generation, using a tiny subnet, blocking management ports, leaving the WAF in detection mode, trusting the default probe, ignoring certificate renewals, and exposing backend servers directly to the internet.
21Frequently Asked Questions
A normal load balancer spreads connections without reading them. Application Gateway reads web requests, so it can route by website name and path, handle TLS, rewrite headers and apply a web application firewall.
If your website is open to the internet and handles any sensitive information, yes, it is strongly recommended. For purely internal tools in a trusted network, the standard version may be enough.
Yes. Multi-site listeners route requests by website name, and each listener can use its own certificate and backend pool. This is a common way to save money.
No. A gateway belongs to one region. For global distribution and failover, put Azure Front Door or Traffic Manager in front of gateways in several regions.
A 502 means the gateway could not get a valid answer from the backend. Check the health of the backend, the port and protocol in the backend settings, the backend certificate if you use end-to-end TLS, and any firewall on the servers.
Yes, as long as the network connection through VPN or ExpressRoute is in place and the gateway can route to those addresses. You list the office servers by address or name in the backend pool.
Yes, the v2 generation supports WebSockets and HTTP/2 for incoming connections, which matters for chat, live dashboards and modern browsers.
If the certificate is stored in Azure Key Vault and set to renew automatically, the gateway reads the new version without a manual step. Certificates uploaded by hand must be replaced by you before they expire.
The gateway is the Azure service. The ingress controller is a helper inside Kubernetes that configures the gateway automatically from the cluster’s own settings. Azure also offers a newer, container-focused gateway product for Kubernetes traffic, worth reviewing if you run clusters.
Share one gateway between several sites, set a realistic autoscale minimum, remove test gateways when finished, and use the WAF only where it is needed. Review the capacity unit graphs monthly and adjust.
22Summary and Key Takeaways
Azure Application Gateway is a smart, managed front door for web applications. It accepts visitors through listeners, applies rules to decide where each request should go, checks that servers are healthy, handles encryption, filters attacks with a web application firewall and scales on demand. Used inside a well-planned network, with private backends and good monitoring, it makes web applications safer, faster and easier to run, without placing the burden of these jobs on every single server.
Key Takeaways
- It is a layer 7 reverse proxy — it understands web requests, so it can route by website name and path, unlike a simple load balancer.
- Six parts make a gateway — frontend IP, listeners, routing rules, backend settings, backend pools and health probes.
- Health probes protect visitors — use a custom probe that tests real application health, not just the front page.
- TLS can be terminated or end-to-end — keep certificates in Key Vault, and use end-to-end encryption for sensitive data.
- The WAF is a key shield — start in detection mode, tune precisely, then move to prevention mode.
- Plan the network carefully — use v2 with zones, a dedicated and roomy subnet, and private backends that accept traffic only from the gateway.
- Choose the right neighbour — use Front Door for global reach, Load Balancer for simple traffic, and combine services when you need both global and local control.