Azure Application Gateway - Simply Explained

0:00 Most load balancers never read the request they are delivering. Azure Application Gateway does. And that single habit changes where your traffic lands. It looks at the URL path and the website name before it decides anything. So a request for images can go to one server while a request for video goes to another. The same gateway can also hold the encryption padlock and screen requests for attacks on the way through. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. By the end, you'll be able to explain why that box sits in the middle of the diagram in plain English, what it actually is. Imagine a receptionist at the front of a busy building. That person decides where every visitor should go, and the decision depends on who walks through the door. Now swap the visitors for web requests and the building for your web application.

0:42 That's the rough idea behind Azure Application Gateway. It's a web traffic load balancer. The name sounds heavier than the job because all it really does is sit in front of your app and decide where each incoming request should land. The difference between this and an older load balancer comes down to two words. Layer seven. That phrase sounds like a certification exam question. It's really about how much of the request your load balancer can see a traditional load balancer works lower down the stack. It only sees an address and a port. Think of a mail room clerk who reads the envelope and never opens it, because everything arriving looks roughly the same to that clerk. Application gateway works at the application layer, which is layer seven of the networking model everyone keeps referencing. At that layer. The gateway reads the actual request. It can see the path in the URL and the website name being requested.

1:25 So it decides based on what the visitor is asking for rather than where they came from. Microsoft's own documentation uses a clean example. A request with images in the URL can go to servers tuned for images. A request with video can land on servers built for video. That's the whole trick, and it explains why the service exists at all. It's a real deployment inside your network, and it lives in its own dedicated subnet. That means it gets its own slice of your network address space, instead of sharing one with other resources. This matters even if you're just running a small site. The moment you have more than one server, someone has to decide which server gets which request. Doing that by hand stops working the day you have real traffic. The features it brings fall into a few easy groups. Traffic handling covers routing by URL path, hosting several sites on one gateway redirects, header rewrites, and a way to keep one visitor tied to the same server.

2:13 Security covers encryption, end to end encryption, and the firewall. Resilience covers autoscaling, zone redundancy, and a front end address that never changes. The current generation is called V2, and it arrives in two flavors. Standard V2 handles routing and security. WAF V2 adds the protection that blocks attacks. If you follow an older tutorial and it mentions a V1 gateway, that generation is retired, so treat it as history rather than something to build. Today, the way a request finds its home is the bit nobody draws in the diagram, so follow one request from the outside in. Listeners and routing rules. A listener is the front door, and it's simpler than the name suggests. It's a piece of configuration that checks for incoming connection requests. Those checks run against four things, which are the port, the protocol, the host, and the IP address.

2:57 When a request arrives, the listener is what notices it and hands it along. You can run several listeners at once, and the official docs show the pattern clearly. Picture two websites Acme. Com and Fabrikam dot com. Both served on port eighty. Each one gets its own listener. The gateway tells them apart because each listener watches for a different hostname. That's exactly the kind of decision a lower layer load balancer can't make. Once a listener catches a request, a routing rule decides what happens next. That rule ties the listener to the back end pool that should receive the request. It also ties in the back end settings, which describe how to talk to those servers when you create a gateway in the Azure portal. It builds one of these rules for you. You get a default listener and a default back end pool. So you have a working starting point before you customize anything.

3:38 Rules come in a couple of useful shapes. Path based routing splits traffic by what's in the URL, which is how add images and video end up in different places. Multi-Site routing splits traffic by the website name in the request, which is how one gateway quietly serves several sites without anyone noticing. A rule can also do a few other things. It can redirect traffic to another port or an entirely different site. It can rewrite request and response headers and URLs as they pass. So picture what happens when someone types your address into a browser. The browser first looks up the gateway's address through DNS, and Azure controls that entry because every gateway lives in the Azure. Com domain, the gateway accepts the request on a. Listener checks it against the firewall if one is turned on and then hands it to the matching routing rule, that rule picks a back end pool, and the gateway forwards the request to one of the healthy servers.

4:26 Using that round robin order, it opens a fresh connection to the back end using the settings you configured before the request leaves, the gateway attaches a few extra headers so your application can still see the real client and the original address. A badly wired rule is the quiet failure that nobody catches until customers complain, the gateway will happily send a real customer to the wrong place. That's why the wiring is worth understanding, even if you never touch it yourself. Once a rule has picked a pool, the gateway still has to answer one uncomfortable question, which is what happens when a server in that pool stops answering back end pools and health probes? The back end pool is the group of servers that actually run your application. It's the destination. The routing rule points at a pool can hold a specific virtual machine, a virtual machine scale set, an IP address or a full domain name or an app service.

5:11 Once a request reaches the pool, the gateway spreads it across the healthy servers. It uses a round robin approach, which simply means it works through the list in order instead of hammering one machine. The part that earns its keep is the health probe. The gateway checks the health of every server in the pool on its own without being asked. It quietly stops sending traffic to any server it believes is unhealthy. The probe doesn't give up either. It keeps checking the sick server and starts routing to it again the moment it responds properly. Every instance of the gateway runs those checks separately, so a pool gets watched from several places at once rather than by one lonely process. The default check is simple it sends a normal web request to the server on the port. Your back end settings specify, and it treats a clean answer as a sign of life. The default probe has settings worth knowing because they explain how quickly all of this happens.

5:55 It checks each server, every 30s, and waits up to 30s for a reply. It marks a server as down after three failures in a row. Anything that replies with a status code between two hundred and three hundred and ninety nine counts as healthy, which in plain terms means the server answered normally rather than throwing an error. The practical effect is that a dead server drops out of rotation and comes back by itself. Nobody has to sit there and babysit it at three in the morning. You can also build a custom probe that checks a specific path or accepts a particular response code. You can even have it look for a specific word in the response body, which helps when a server answers with a friendly error page instead of a real failure, it's worth knowing that a wrong probe path is the classic reason people see five hundred and two errors, and can't work out why.

6:36 The gateway is checking. Something else about every request to this next one has nothing to do with traffic at all, and it has to do with the little padlock in your browser where HTTPs gets handled. That padlock is TLS, the encryption that keeps strangers from reading what travels between a browser and a website. When your traffic reaches the gateway, the encrypted connection can end right there. The name for that is TLS termination. Your backend servers then receive a normal request from the gateway. They don't have to do all the encryption math themselves. Ending the encryption at the gateway solves two problems at once. Your servers stop spending effort on cryptography and get to focus on your application. You also manage certificates in one place instead of chasing them across every machine in the pool. That single place is also where your certificate renewals happen.

7:17 So one expiring certificate becomes one thing to fix rather than a dozen. If you'd rather keep everything encrypted the whole way. The gateway supports that too. It will open a fresh encrypted connection to the back end. One detail is worth knowing because it explains plenty of confusing behavior later. The gateway adds headers to every request before it forwards them, and those headers carry the real client address and the original host name. Your application can still tell who actually made the request, even though the connection now comes from the gateway. That's why a request arriving at your server looks like it came from the gateway, even when it started somewhere else entirely. The gateway can also be set up to add, remove, or update request and response headers. That's how teams fix things like a back end that insists on seeing a particular hostname.

7:57 The V2 generation is built for this work, and Microsoft reports that it handles TLS offload far faster than the older version it replaced for you. That mostly means encryption isn't the thing slowing your site down. Encryption keeps outsiders from reading the traffic. It does nothing about someone sending you malicious traffic on purpose. That's a different problem and it needs a different tool. What stops the attacks? That tool is the web application firewall, usually shortened to WAF. It's the reason the WAF v2 version of the gateway exists. Routing decides where a request should go, and the firewall decides whether it should be allowed through at all. It inspects the whole request, including the headers and the body. It blocks the attacks that have been working on unprotected sites for years. The two that get named first are SQL injection and cross-site scripting.

8:38 SQL injection is where an attacker tries to sneak database commands into a form field. Cross-Site scripting is where they try to plant their own code inside your page. The list continues from there and covers command injection, request smuggling, and a handful of other tricks attackers reuse because they keep paying off. The rules come from the Owasp core rule set. Owasp is a public project that keeps a shared list of common web attacks. Microsoft's firewall uses those rules and keeps them current. You inherit years of collective experience. Instead of writing your own detection rules from scratch, and you get the updates as new attack patterns show up rather than patching your own list. The firewall runs in one of two modes, and the difference matters more than the names suggest detection mode watches, logs, and blocks nothing, which is the training wheels setting.

9:21 Prevention mode blocks the attack, and the attacker gets a four hundred and three response and a closed connection. Microsoft recommends running a new firewall in detection mode for a short while in production. That way, you can spot false alarms and tune them out before you start blocking real traffic. Behind the scenes, the firewall scores each request by severity. A critical rule match adds five points. An error adds for a warning. Adds three and a notice. Adds two. Five points is enough to block the request in prevention mode. One serious match is enough by itself, while a single minor warning is not. Two extras are worth a line each. You can filter traffic by geography to allow or block whole countries. There's also a bot manager rule set that separates verified search engine crawlers from bots that lie about who they are.

10:01 One gateway can put up to forty websites behind the firewall, which is why this protection stays affordable as you add sites. All of that protection is worthless if the gateway itself falls over the moment traffic spikes. That brings us to the part people rarely think about until it matters. Scaling without thinking. Auto scaling means the gateway adds capacity when traffic rises and gives it back when traffic falls. You never have to guess the right size in advance. You set a minimum instance. Count anywhere from zero to one hundred. You can set a maximum as well, and it defaults to ten. If you don't specify one, each instance is worth roughly ten units of capacity, so the count translates fairly directly into how much work the gateway can take. On Azure measures that work in capacity units, a single unit covers about two thousand five hundred connections, a little over two megabits per second of throughput, and one compute unit.

10:46 Whichever of those three you burn through first is the one that drives the cost, which is why a site with lots of tiny requests and a site streaming big files can end up paying differently for the same traffic volume. Even at zero minimum instances, the gateway stays highly available. The service is always deployed as more than one instance, and Azure quietly replaces an instance that stops working. Two honest details make this feel less magical. Bringing a new instance online can take around three to five minutes. When the gateway scales back down. It drains existing connections for five minutes before removing an instance so nobody gets cut off mid request. That's the difference between a capacity plan that looks good on paper and one that behaves well when it counts. Zone redundancy is the other half of staying up. The gateway spreads itself across at least two availability zones by default, and availability Zone is a physically separate group of data centers inside the same region.

11:34 If one of those zones fails, the gateway keeps serving from the others. That's the kind of resilience that used to require running two separate gateways and a traffic manager to juggle them. One caveat is worth stating plainly zones only exist in some regions, so how much resilience you get depends on where you deploy. A quieter benefit sits alongside all of this. The V2 gateway uses a static address that stays the same for the life of the deployment. Even after a restart, your DNS records never have to chase a moving target, so the gateway routes, protects and scales itself. Which raises the question that many people arrive with. That question is whether the other Azure load balancers do the same thing. The three Azure load balancers, three services, three names, and Microsoft's own documentation puts them all in the same family.

12:17 That's exactly why beginners mix them up. The cleanest way to keep them straight is to notice two things, which are how closely each one inspects the traffic, and how far away your users are. As your load balancer sits lowest and works at layer four, it only sees network traffic such as TCP and UDP, so it never reads a URL or a hostname. It simply spreads flows across virtual machines with almost no delay added. It's built for speed and can push millions of flows at once. If your application speaks a protocol other than plain web traffic, or you want the fastest possible path through, this is the one you reach for as your application gateway sits a layer higher and stays regional, it reads the request ends the encryption and can run a firewall. It lives inside your own network where you can see it when your users are mostly in one region and your app is a normal web application, this is usually the middle ground that fits as your front door sits higher still and goes global.

13:05 It's really a content delivery network wrapped around a load balancer, so it can cache your static files close to your users, as well as route their requests. It's built on Microsoft's Edge network with more than one hundred and eighteen edge locations spread across one hundred metro areas, Microsoft says it can improve latency by up to three times while running its own firewall out at the edge. If your users are scattered around the world and every millisecond of delay costs you something. This is the worldwide front door. There's a fourth option worth naming, so the picture is complete. Azure Traffic Manager does global routing using DNS alone, which is lighter than the other three. It doesn't read requests or end encryption, so it fits when all you need is a Smart address that points to the nearest healthy endpoint. What surprises people is that these services aren't rivals.

13:47 Microsoft's guidance says end to end scenarios often benefit from combining them. A common pattern puts front door out front for Global Entry, while an application gateway sits regionally behind it, doing the careful work close to your application. Cost deserves a short note so nobody gets caught out. Application gateway V2 has no upfront charge. You do pay a fixed hourly amount whether or not traffic arrives, plus a charge based on the capacity you actually consume. As an illustration, Microsoft's pricing page lists a fixed rate around a quarter of a dollar per hour for the standard version and a bit more for the firewall version. Those figures are examples that vary by region rather than prices to plan a budget against. So check the live pricing page before you commit. The whole picture fits in a few breaths. Application gateway is a layer seven load balancer, so it reads the request instead of just the address.

14:32 And that's why it can send images one way and video another. Listeners are the front door while routing rules via that door to the right back end pool. Health probes keep dead servers out of rotation without anyone watching. TLS termination takes the padlock. Work off your servers and the web application. Firewall screens requests for known attacks. Auto scaling with zone redundancy keeps the whole thing standing when traffic jumps or a data center goes quiet. Here's the question I'd like you to sit with. If a load balancer can read the request, the host name, and the URL path, where does the decision about what a request is actually allowed to do belong? Does it belong in the gateway at the front or in the application that understands the business rule? Sit with that one for a minute because it changes how you design everything behind the front door. If you want more episodes that make Azure and Microsoft three hundred sixty five feel less like a wall of jargon, subscribe to M365 FM and we'll keep making them.