Begin with the problem a single web server cannot solve, then see how this service answers it.

The problem

A small website can live on one server. Visitors type the address, the server answers, and life is simple. Then the site becomes popular. One server cannot handle all the visitors, so you add a second and a third. Now a new question appears: when a visitor arrives, which server gets the request? Someone has to decide, and that someone must also notice when a server breaks, so visitors are not sent to a dead machine.

What the service is

Azure Application Gateway is a managed web traffic load balancer and reverse proxy. “Managed” means Microsoft runs and patches the machines behind it. “Load balancer” means it spreads requests across several servers. “Reverse proxy” means that visitors talk to the gateway, not to your servers directly, and the gateway talks to your servers on their behalf. Because it understands the web language, called HTTP, it can make smart choices based on the address a visitor asked for, the website name, cookies and headers.

What it gives you

Where it lives

The gateway sits inside your own Azure virtual network, which is your private network in the cloud. It works for one region. If you need to spread users across several regions around the world, other services work above it, and a later chapter explains how to choose.

To understand why this service exists, you need a small tour of how network traffic is organized into layers.

The layer idea

Network engineers describe communication as a stack of layers, like floors of a building. Each layer has a job and only talks to the layers directly above and below. A simple version looks like this. The lower floors move raw signals and addresses. The middle floors, called layer 4, handle connections between two computers using addresses and ports. The top floor, called layer 7, understands the actual conversation of an application, such as a web request asking for a particular page.

Layer 4 versus layer 7

A layer 4 load balancer sees only envelopes. It knows the sender address, the receiver address and the port number. It cannot open the envelope. So it can split traffic evenly, but it cannot say “send requests about pictures to the picture servers.” A layer 7 load balancer opens the envelope and reads the letter. It sees the web address, the site name, the cookies and the headers, and can use all of these to choose a destination.

What a reverse proxy is

A normal proxy sits in front of users and speaks for them to the internet, as when an office routes all browsing through one gateway. A reverse proxy sits in front of servers and speaks for them to users. The visitor never learns which server answered. This hides your internal layout, lets you change servers freely, and gives you one place to apply security and rules.

Why this matters for design

Because the gateway ends one conversation with the visitor and starts a new conversation with your server, it can change things in between: add a header, rewrite an address, switch from one kind of encryption to another. This power is what makes the service useful, and it also explains many of the surprises people meet, such as the server seeing the gateway’s address instead of the visitor’s.

Every term below is explained with what it is, why it exists, a picture from daily life and a simple example.

How the words fit together

Read the chain from left to right: a visitor reaches the frontend IP, a listener catches the request, a routing rule matches it, backend settings define how to speak to the servers, and the request lands on a member of the backend pool that the health probe says is healthy. The firewall inspects the request near the start. Keeping this chain in mind makes the portal screens and the documentation much easier to read.

Here is the full picture of where the gateway sits and which pieces it touches.

flowchart LR
  U["Visitor browser"] --> DNS["DNS name"]
  DNS --> FIP["Frontend IP"]
  subgraph VNET["Your virtual network"]
    subgraph GSUB["Dedicated gateway subnet"]
      L["Listener"] --> W["WAF inspection"]
      W --> R["Routing rule"]
      R --> BS["Backend settings"]
    end
    subgraph APPSUB["Application subnets"]
      P1["Web server 1"]
      P2["Web server 2"]
      P3["API server"]
    end
  end
  FIP --> L
  BS --> P1
  BS --> P2
  BS --> P3
  KV["Key Vault certificates"] -.-> L
  MON["Azure Monitor logs"] -.-> GSUB

The gateway instances

Behind the single name “Application Gateway” there are several small virtual machines, called instances, that Microsoft runs for you. They share the work. In the newer version, the number of instances changes automatically with traffic. You never log in to these machines; you only configure the gateway through the portal, templates or command-line tools.

The dedicated subnet

A subnet is a slice of your virtual network. The gateway needs a slice to itself, containing no other kind of resource. Think of it as a private loading dock. This keeps the gateway’s own management traffic separate and lets it grow by taking more addresses from the slice. Plan the size generously, since running out of addresses blocks scaling.

Frontends

A gateway can have a public address, a private address or both in the newer version. A public frontend serves the internet. A private frontend serves only internal users, such as employees reaching an internal tool through a company network link.

Listeners, rules and pools

One gateway can host many websites. Each website gets a listener. Each listener is joined by a rule to a backend pool, and many rules can share a pool. This lets a single gateway serve a shop, a blog and an internal API, each with its own name, certificate and servers.

Supporting services

Application Gateway has been sold in more than one form. Choosing the right one early saves a painful rebuild later.

Two generations

The original generation, called v1, used fixed-size instances that you picked yourself. The newer generation, called v2, added automatic scaling, zone redundancy, a static public address, faster updates and better performance. Microsoft has announced retirement of v1 on a published schedule, so new designs should use v2. Check the current retirement dates on the official lifecycle page, since dates may move.

Standard and WAF tiers

Both generations come in a plain form and a form with the web application firewall included. In v2 the names are commonly written as Standard v2 and WAF v2. WAF v2 adds the attack-blocking engine and its logs for an extra charge. If the application faces the internet, the firewall form is the sensible default.

Choosing a size

In v2, you set a minimum number of instances to cover steady load and quick bursts, and a maximum to cap cost. A common starting point is a minimum of two for availability, then adjust after watching real traffic. Setting the minimum to zero saves money but leaves a delay when traffic returns, which many production sites cannot accept.

Other forms

Microsoft also offers a container-focused way to use the gateway, where it is controlled from inside a Kubernetes cluster, and newer related products for containers have appeared over time. Offerings and names evolve, so verify the current list in the documentation before you plan around a specific one.

Follow a single click from a visitor’s browser to the application and back, step by step.

sequenceDiagram
  participant V as Visitor
  participant G as Gateway
  participant F as Firewall engine
  participant S as Backend server
  V->>G: Open secure connection to shop.example.com
  G->>G: Present certificate, finish handshake
  V->>G: Send request for /cart
  G->>F: Inspect request against rules
  F-->>G: Allowed
  G->>G: Match listener and routing rule
  G->>G: Pick healthy server from pool
  G->>S: New connection, forward request
  S-->>G: Response
  G->>G: Apply response rewrites
  G-->>V: Send response

Step by step

Two connections, not one

The most important idea is that the visitor’s connection and the server’s connection are separate. The visitor never talks to your server directly, and the server never sees the visitor’s real address unless the gateway passes it along in a header. Applications that rely on the visitor address for logging or limits must read that header.

Connection reuse

Opening a new connection for every request is slow. The gateway keeps connections to servers open and reuses them for later requests, which saves time and server effort. This is also why a server that closes idle connections too quickly can cause strange occasional errors, a topic revisited in the troubleshooting chapter.

Routing is the gateway’s main talent. Three styles cover almost every real design.

Basic routing

In basic routing, one listener is joined to one pool. Everything that arrives goes to the same group of servers. This fits a single website with a single application tier. It is the simplest style and the easiest to troubleshoot.

Path-based routing

Here the gateway looks at the part of the address after the site name, called the path. Requests for /api can go to API servers, /images to media servers, and everything else to the main web servers. This allows one public name to hide several back-end applications, which is perfect for gradually splitting a large application into smaller parts.

Multi-site routing

Multi-site routing uses the site name the visitor typed. One gateway can host shop.example.com and blog.example.com, each with its own listener, certificate and pool. Because all sites share the gateway, you pay once for the front door while keeping the back ends independent. In the newer version, listeners can also match wildcard names, such as every subdomain of a company name.

Redirects

A redirect tells the browser to ask somewhere else. The most common example sends visitors who typed the insecure address to the secure address. Another example moves an old site name to the new one. The gateway can do this without involving any server, which keeps the logic in one place.

Rewrites

A rewrite changes a request or response while it passes through. You can add or remove headers, or change the path before it reaches the server. For example, a public path of /store/cart could be changed to /cart, so the application does not need to know about the public prefix. Rewrites are powerful but easy to overuse, so document each rule.

Rule order and priority

In the newer version, each rule has a priority number, and the lowest number is checked first. A catch-all rule should have the highest number so that specific rules win. Forgetting this is a common cause of traffic going to the wrong pool.

Encryption is where most first-time gateway projects get confused. Take it slowly and the choices become clear.

What a certificate is

A certificate is a digital identity card for a website. It says “this is really shop.example.com” and is signed by an organization that browsers trust. It also carries a public key used to set up encryption. Certificates expire, usually after a year or less, so someone must renew them before that date.

Three ways to handle traffic

Certificates in Key Vault

Instead of uploading certificate files directly, you can store them in Azure Key Vault and let the gateway fetch them using a managed identity. This has two big benefits. First, nobody has to handle the secret file by email or chat. Second, if the vault certificate is renewed, the gateway can pick up the new version automatically, avoiding the outage that follows an expired certificate. Verify the exact refresh behavior in the current documentation, since it has changed across versions.

Trusting the backend

With end-to-end encryption, the gateway must decide whether to trust the server’s certificate. Public certificates from well-known authorities work easily. Private or self-signed certificates require you to give the gateway the issuing certificate to trust. Turning off these checks to make an error go away removes the protection you wanted.

Host name matters

The gateway can send the visitor’s original host name to the server or use a different one, such as the server’s own name. Many platform services, like app services, expect their own name and fail if given another. Whenever you see strange redirects or login loops after adding a gateway, check the host name setting first.

Protocol versions

Older encryption versions are weak. Choose a policy that sets a modern minimum version and good cipher choices, and review it as standards change. Clients that cannot meet the policy will fail to connect, so look at your visitor mix before tightening.

Mutual authentication

In some designs the client must also show a certificate, so the gateway knows exactly who is calling. This is called mutual TLS. It suits business-to-business links and device fleets. It adds management work, because you must issue, rotate and revoke client certificates.

A load balancer is only as good as its knowledge of which servers are alive. Probes provide that knowledge.

How a probe works

Every few seconds, each gateway instance sends a small request to each pool member, usually to a special page such as /health. If the answer is within the expected range of status codes and arrives within the timeout, the server is healthy. After a number of failures in a row, the server is marked unhealthy and receives no new traffic. When it passes again, it comes back automatically.

stateDiagram-v2
  [*] --> Healthy
  Healthy --> Suspect: probe fails
  Suspect --> Healthy: probe passes
  Suspect --> Unhealthy: failures reach threshold
  Unhealthy --> Recovering: probe passes
  Recovering --> Healthy: passes continue
  Recovering --> Unhealthy: probe fails again

Default and custom probes

If you do nothing, the gateway uses a default probe that asks the root page of the server. That is often too shallow or wrongly shaped. A custom probe lets you choose the path, host name, interval, timeout and the status codes that count as success. Good health pages check what matters, such as database reachability, but not so deeply that one slow dependency makes every server look dead at once.

The danger of all-unhealthy

If every member is marked unhealthy, the gateway returns an error to visitors. In some versions, if all members are bad, the gateway may still try them, hoping one works. Do not rely on this. Design the health page so it reports only the condition of that server and its must-have parts.

Backend pool members

Members can be network interface addresses, scale sets, fully qualified names, public addresses and app services. Choose names when addresses change often. Keep pool members in the same region and virtual network, or in a network that is reachable by peering or a private link.

Connection draining

When you take a server out of the pool for maintenance, you do not want to cut visitors off in the middle of a purchase. Connection draining tells the gateway to stop sending new requests to that server but let existing ones finish within a time limit. Without it, deployments can cause small bursts of errors.

Session affinity

Some applications store a visitor’s state in the memory of one server. For these, cookie-based affinity keeps sending that visitor to the same server. It works, but it makes load uneven, complicates scaling and loses state if the server fails. A better long-term design stores state in a shared place, such as a cache or database, so any server can answer.

The gateway is a network citizen. It needs space, open paths and sensible rules.

Sizing the subnet

The newer version can use many instances and needs addresses for each, plus some reserved by Azure. A subnet that is too small will block growth. Teams commonly choose a roomier subnet than the minimum, because changing it later means disruption. Check the current sizing recommendation in the documentation and add comfortable margin.

Required rules

The gateway needs certain inbound traffic from Azure’s own management system so it can be controlled and health-checked. Blocking that traffic with an overly strict rule will put the gateway into a failed state. Add your own allow rules for visitors on the listener ports, and use deny rules carefully, ordered by priority.

flowchart TD
  I["Internet visitors"] -->|"443"| G["Gateway subnet"]
  M["Azure management"] -->|"required control ports"| G
  G -->|"app port"| A["App subnet"]
  A -->|"database port"| D["Data subnet"]
  I -. "blocked directly" .-> A
  I -. "blocked directly" .-> D

Keeping servers private

A key benefit is that servers can stay private. Give them no public address, and allow traffic to them only from the gateway subnet. Then the gateway becomes the only door, and every request must pass through its inspection and logging.

Private frontends and internal use

For internal applications, give the gateway a private frontend address. Employees reach it through a company link or VPN, and nothing is exposed to the public internet. A mixed design can have both a public and a private frontend with different listeners.

Reaching other networks

Pool members in other virtual networks can be reached through peering. On-premises servers can be reached through a VPN or dedicated circuit. Check name resolution too: the gateway must be able to turn server names into addresses, which may require a private DNS zone linked to its network.

Outbound traffic

The gateway itself also needs to reach certain Azure services, for example Key Vault when using stored certificates. Restricting outbound rules too tightly can break these calls. Review outbound needs before applying a deny-all rule.

The firewall feature turns the gateway from a traffic director into a guard. Understand what it can and cannot do.

What it blocks

The firewall engine uses rule sets maintained by the security community, most famously the OWASP core rule set. These rules recognize patterns of common web attacks: attempts to inject database commands, scripts planted into pages, attempts to read files outside allowed folders, scanner tools and protocol abuse. It looks at the address, headers, cookies and, up to a size limit, the request body.

Detection and prevention modes

Tuning false positives

Real applications sometimes send data that looks like an attack: a text editor that submits HTML, or an API that sends long encoded values. The usual path is to run in detection mode, read the logs, identify which rules fire on legitimate requests, and then add exclusions for specific fields or turn off a single rule for a specific path. Disabling large groups of rules to make an alarm stop is a bad habit that opens real holes.

Custom rules

You can write your own rules before the managed rules run. Examples include allowing only certain countries, blocking a list of bad addresses, limiting the rate of requests from one address, or allowing special partners through. Rules run in priority order, and each has an action: allow, block, log or in some cases a challenge.

Policies and scope

A firewall policy is a reusable object. You can attach one policy to the whole gateway, a single listener or even a single path. This lets a stricter policy protect the admin area and a looser one serve public pages.

Limits to remember

The firewall does not fix vulnerable code, protect against stolen passwords, or stop attacks that never travel through the gateway. It is one layer, not a replacement for secure coding, patching and strong authentication. Large request bodies may be inspected only up to a documented size, so know that limit.

Bot and rate controls

Newer rule sets can recognize known good bots, such as search engines, and known bad ones. Rate limits slow down password-guessing and scraping. Treat these as helpful filters, not guarantees, and verify current feature availability for your tier.

The gateway sits at a perfect place for security, but real safety comes from many layers working together.

Identity and permissions

Use Azure role-based access control to decide who may change the gateway. Reading metrics is a smaller power than editing rules. Give each person the smallest role that does the job, and record who changed what with the activity log. A single mistaken rule can take down a whole site, so editing rights deserve care.

Secrets and identities

Use a managed identity so the gateway can read certificates from Key Vault without any stored password. Limit that identity to reading only the needed secrets. Never put certificate passwords in templates or scripts that are saved in shared folders.

Headers that help browsers protect users

Through rewrite rules, the gateway can add response headers that tell browsers to enforce secure behavior: always use secure connections for this site, do not guess file types, and limit which pages may embed yours. These headers cost almost nothing and close entire classes of problems. Test them carefully, since a strict policy can break pages that load resources from other places.

Hiding internal details

Error pages and headers can leak server names and software versions. Custom error pages and header removal reduce what attackers learn. The gateway can serve a friendly custom page for common errors such as maintenance and forbidden requests.

Protecting against floods

Large floods of traffic aimed at making a site unavailable are called denial-of-service attacks. Azure provides a network-level protection service for virtual networks that can cover the gateway’s public address. The firewall rate rules add application-level control. Plan which protection you need based on business impact, and confirm current options and pricing.

Private access to platform services

If back ends are platform services such as app services, restrict them so they only accept traffic from the gateway. Otherwise someone who learns the direct address can bypass all of your gateway protections. Use network restrictions or private endpoints, and check that direct access fails.

Logging for security

Send firewall and access logs to a central workspace. Create alerts for sudden spikes in blocked requests, many failures from one source, and rule changes. Keep logs long enough to meet your legal and audit needs.

A gateway that cannot keep up becomes the slowest part of your whole application. Knowing how it scales prevents surprises.

Autoscaling in v2

The gateway watches its own load and adds instances when traffic rises, then removes them when it falls. You set a minimum and a maximum. Scaling is not instant: new instances take some minutes to join. A sudden, huge spike, like a ticket sale opening at an exact minute, can outrun scaling. For predictable events, raise the minimum ahead of time.

What counts as load

Three kinds of work use up capacity: how many new connections arrive each second, how much data flows, and how much processing each request needs, especially encryption and firewall inspection. Larger certificates, more complex rules and body inspection all raise the processing cost. This is why a gateway with the firewall on needs more capacity than the same gateway without it for the same traffic.

A worked sizing example

The numbers below are illustrative and not official limits. Suppose your shop averages 300 requests per second and peaks at 900 during a sale. If one capacity unit comfortably handles about 50 requests per second with encryption and firewall checks, the average needs 300 divided by 50, which is 6 units, and the peak needs 900 divided by 50, which is 18 units. If each unit-hour costs an illustrative 0.01 dollars on top of a fixed hourly fee, then 6 units for an hour is 0.06 and 18 units is 0.18. The point is that cost follows load, so the minimum should cover normal traffic and the maximum should allow the peak.

Latency

The gateway adds a small delay: the extra hop, the decryption, the inspection. Usually it is a few milliseconds and invisible. Larger delays are normally caused by slow back ends, long distances between the gateway and servers, or connections that must be built repeatedly. Compare the gateway’s own measured time with the back-end time to see who is slow.

Keeping connections efficient

Reusing connections and enabling modern web protocols between the visitor and gateway improves speed. Compression and caching are better handled by the application or by a content delivery service in front, not by the gateway alone.

Request and body limits

The gateway has maximum sizes for headers, URLs and uploads, and a time limit for waiting on a server. Large file uploads and long-running calls can hit these limits. Check current values in the documentation and set the request timeout above the longest legitimate operation, while keeping it low enough to free stuck connections.

Websockets and long-lived connections

Some applications keep a connection open for chat or live updates. The newer gateway supports these, but long idle times may be cut off by timeouts. Test the real behavior with your application and adjust keep-alive settings.

A front door that fails takes the whole building with it. Resilience planning keeps the door open when parts break.

Inside one region

The v2 gateway can spread its instances across availability zones, which are separate buildings with their own power and cooling within one region. If one zone fails, instances in the others keep serving. To benefit, spread the back-end servers across zones too, since a gateway that survives while all servers sit in the failed zone helps nobody.

Across regions

A single gateway belongs to one region. For protection against loss of a whole region, deploy a gateway and back ends in a second region, then put a global traffic service in front that sends visitors to the healthy region. The data tier also needs a cross-region plan, since stateless web servers are easy to duplicate but databases are not.

flowchart TD
  U["Visitors worldwide"] --> GT["Global traffic service"]
  GT -->|"healthy"| R1["Region A gateway"]
  GT -->|"standby or active"| R2["Region B gateway"]
  R1 --> B1["Region A servers"]
  R2 --> B2["Region B servers"]
  B1 --> DB1["Primary database"]
  B2 --> DB2["Replica database"]
  DB1 -. "replication" .-> DB2

Active-active and active-passive

In active-active, both regions serve visitors at the same time, which uses resources well and shortens distances to users but needs careful data design. In active-passive, one region waits on standby. It is simpler but wastes capacity and requires tested switching. Either way, practice the failure; an untested plan is only a hope.

Planned maintenance

Microsoft updates the gateway’s underlying machines. With at least two instances, updates roll through without downtime. Your own changes, such as new rules, can be applied with little or no interruption in v2, but always test the change in a copy first.

Failure modes to expect

You cannot fix what you cannot see. Three streams of information tell you what the gateway is doing.

Metrics

Metrics are numbers sampled over time. The most useful ones are the count of requests, the number of failed requests, healthy and unhealthy host counts, response status counts grouped by code, the time the gateway waited for the back end, total time per request, current connections, throughput and capacity units used. Plot them on a dashboard and learn what normal looks like.

Access logs

The access log records each request: time, client address, host, path, status code, bytes, time taken, which server answered and which rule matched. It answers questions like “who got errors at ten past three?” and “which pool handled this request?”.

Performance and firewall logs

The performance log records per-instance numbers in some versions. The firewall log records which rule matched, its action and the details. Send all logs to a Log Analytics workspace, a storage account for long-term keeping, or an event stream for external tools. Be aware that detailed logs on a busy gateway can be large and add cost.

Alerts worth having

Reading error codes

Connection trouble checklist

The bill for a gateway has a few parts. Knowing them helps you predict and reduce it. Prices change, so use the official calculator for real numbers.

A worked monthly example

These numbers are made up to show the method. Imagine a fixed charge of 0.25 dollars per hour. A month of 730 hours costs 0.25 times 730, which is 182.50 dollars. Suppose the average use is 8 capacity units at 0.008 dollars per unit-hour: 8 times 0.008 is 0.064 dollars per hour, and 0.064 times 730 is 46.72 dollars. The total is about 229.22 dollars before data transfer and logs. If you add a second gateway for a test environment that runs all month, you roughly double the fixed part, which is why test gateways should be deleted or shared when possible.

Ways to reduce cost

Share one gateway among many sites using multi-site routing. Set the autoscale minimum to match real need rather than a fear-based high number. Delete idle test gateways. Keep log retention in line with real requirements and send only the categories you will use. Consider cheaper options for simple needs, such as using the app platform’s built-in features for a small single site.

Where money is wasted

Typical waste includes many small gateways where one would do, a high minimum copied from a template, large inspection of traffic that does not need it, and verbose logging left on forever. A monthly review of the bill against traffic statistics catches these.

Azure offers several services that sound alike. Each answers a different question, and they are often used together.

flowchart TD
  S["What do you need?"] --> Q1{"Web traffic?"}
  Q1 -->|"No, other protocols"| LB["Load Balancer"]
  Q1 -->|"Yes"| Q2{"Users worldwide?"}
  Q2 -->|"Yes"| FD["Front Door in front, gateway behind if needed"]
  Q2 -->|"No, one region"| Q3{"Need path routing or firewall?"}
  Q3 -->|"Yes"| AG["Application Gateway"]
  Q3 -->|"No"| LB2["Load Balancer or app platform features"]

Using them together

A common pattern places a global service at the edge to find the nearest healthy region and absorb attacks, with a regional gateway behind it to route to the right application inside the network, and a layer 4 balancer deeper in for non-web traffic. Each layer does what it is best at.

Gateway or app platform features

Platforms such as app services have their own simple balancing and custom domains. For a single small site that needs nothing else, those may be enough. Reach for the gateway when you need private back ends, firewall protection, path rules, many sites on one entry, or tighter control over encryption.

Kubernetes cases

For container platforms, the gateway can act as the entry point controlled by the cluster, so developers define routes with cluster objects and the gateway follows. This is worth considering if your teams already work in that way, but newer options appear regularly, so compare current choices.

Every tool trades one thing for another. Here is an honest look at the balance.

Key trade-offs

The sharing decision

Putting everything behind a single gateway is cheaper but makes it a shared fate point. A middle path groups sites by importance and team: critical public sites on one gateway, internal tools on another, and development on a third small one. Review limits such as the number of listeners and rules allowed per gateway before sharing widely.

Good teams reuse designs that have worked many times, and avoid ones that fail in familiar ways.

Patterns that work

Anti-patterns to avoid

A short checklist to apply before any gateway goes live.

Best practices

Common mistakes

Walk through the failures in advance, and recovery becomes routine.

Scenario one: sudden wave of 502 errors after a deployment

A new version of the application rolls out and visitors see Bad Gateway. Likely causes: the new version changed its health page, its certificate changed, or its start-up time grew so probes fail while it boots. Recovery: check the unhealthy host metric, run the probe path by hand, and roll back the deployment or fix the health page. Prevention: use connection draining, deploy to a few servers at a time and gate each step on probe success.

Scenario two: certificate expired

Browsers warn visitors and mobile apps refuse to connect. Recovery: renew the certificate in Key Vault, confirm the gateway picked up the new version, and clear any pinned older copies. Prevention: alerts at thirty and seven days, plus automatic renewal with the issuing authority.

Scenario three: legitimate users blocked by the firewall

After enabling prevention mode, a form stops working. Recovery: read the firewall log for the rule identifier, add a narrow exclusion for that field, and retest. Prevention: a full period in detection mode with realistic traffic and tests of every important form and API.

Scenario four: gateway cannot scale during a promotion

A marketing email drives ten times the usual traffic within a minute and response times rise. Recovery: raise the minimum instance count immediately and, if needed, add capacity upstream. Prevention: coordinate with marketing, pre-scale before known events and load test.

Scenario five: network change breaks everything

A well-meaning engineer adds a deny rule to the gateway subnet and the gateway reports an unhealthy state. Recovery: remove the rule or add the required management allow rule. Prevention: review rule changes, apply policy through code and test in a copy.

Scenario six: a zone outage

One zone loses power. If both gateway and servers are zone-spread, visitors may notice a short blip. If servers live only in the failed zone, the site is down. Recovery: add servers in other zones, and confirm health. Prevention: spread servers evenly and test.

flowchart TD
  A["Visitors report errors"] --> B{"Which status code?"}
  B -->|"502"| C["Check probe and back-end certificates"]
  B -->|"503"| D["Check healthy host count and capacity"]
  B -->|"504"| E["Check back-end speed and timeouts"]
  B -->|"403"| F["Check firewall log and rules"]
  C --> G["Fix, then confirm in metrics"]
  D --> G
  E --> G
  F --> G

These are typical, invented scenarios that show the ideas at work. They are not reports about any named company.

What they share

Each example keeps servers private, uses health checks that reflect real readiness, treats certificates and rule changes as controlled operations, and watches a short list of metrics every day.

The gateway is shared infrastructure, so every change deserves the care you would give to changing the front door of a busy shop during opening hours.

Infrastructure as code

Describe the gateway in text files that a tool can read: its subnet, listeners, rules, pools, probes, certificates and firewall policy. Store those files in version control. Now every change has an author, a date, a reason and a reviewer. If something breaks, you can see exactly what changed and return to the previous version. Building production by clicking through the portal leaves no such record and invites small differences between test and production that cause surprises later.

Environments that match

Keep a development, a test and a production gateway built from the same files with different settings, such as names, sizes and certificates. When a rule works in test, the same rule works in production because nothing else differs. The test gateway can be smaller and can be deleted overnight to save money.

Safe change steps

Smoke tests

A smoke test is a short list of requests that must always work: the home page, the login page, one important API call and a redirect from the insecure to the secure address. Run it automatically after every change. It takes seconds and catches most mistakes before visitors do.

Protecting against accidents

Resource locks can stop someone from deleting a gateway by accident. Policies can forbid risky settings, such as a public address on a back-end server or a firewall in detection mode in production. Alerts on activity log events tell you whenever a rule or listener changes, so surprises become visible quickly.

Two situations come up often in real projects: an old gateway that needs replacing, and a container platform that needs a web entry point.

Planning a move from v1 to v2

You cannot simply flip a switch on a v1 gateway and turn it into v2. The usual path is to build a new v2 gateway next to the old one, copy its configuration, test it with a private address or a test name, and then move the public name to the new gateway. Microsoft has provided helper scripts and guidance for copying settings; check the current migration page, because these tools and the retirement dates are updated over time.

Things that change between versions

The public address behaves differently, since v2 uses a static one. Some settings are named differently. Firewall rule sets and policies are managed in a new way. Probes and header handling have small differences. Treat the move as a project with tests, not as a copy and paste.

Containers and the gateway

A container platform runs many small programs that start, stop and move around. Their addresses change constantly. To send web traffic to them, the platform needs an entry component that follows the changes. One approach lets the cluster control the gateway: developers describe a route in the cluster’s own language, and a small helper program inside the cluster updates the gateway so it points straight at the running containers. This saves an extra hop and keeps the rules close to the application code.

When to choose this approach

It suits teams already running a cluster who want the benefits of the firewall and managed scaling without running their own proxy inside the cluster. It is less suitable if you need very advanced routing that only an in-cluster proxy offers, or if updates to the gateway are too slow for very frequent route changes. Because products in this area evolve quickly, compare the present options before deciding.

Short answers to the questions people ask most. Where a detail may have changed, confirm in the current Microsoft documentation.

Application Gateway is the smart receptionist for web traffic in one Azure region. It reads requests, applies rules, protects against common attacks and sends visitors only to healthy servers.