Mastering Azure Application Gateway: Rewrites, Multi-Site, Custom Ports, and More

When I first started working with Azure Application Gateway, I thought of it as “just another load balancer.” But the deeper I went, the more I realised how powerful and flexible it really is; especially when used as the front door for APIs, websites, and microservices.

In this post, I’m sharing top things I actually implemented — starting from a simple use case and going all the way to real world patterns. If you’re working with Azure networking, API Management, or microservice deployments, these will level up how you design traffic flow in your environment.

🛠️ My Setup: Simple, but Real

I wired up an Application Gateway in front of an Azure API Management (APIM) instance.

• The APIM in my case was deployed in internal mode (but these steps work for external mode too — you’ll just not need VNet connectivity).
• I had two subdomains:
  • api.example.com → API traffic through APIM
  • api2.example.com → frontend website hosted separately

This combination was enough to explore some deep scenarios — here’s what I learned 👇

1. Adding a Custom Port to a Custom Domain (and Preventing Redirects)

Let’s start simple — but not too simple.

I wanted https://api.example.com:7242 to hit my backend without redirecting to the App Service default URL (*.azurewebsites.net). Most guides will tell you to use custom host headers with rewrite, but there is a simpler way entirely from the basic listener configuration.

Why this matters:

• Some APIs or backend services run on non-standard ports, and exposing them behind a clean custom domain makes them easier to consume.
• Redirect loops or domain mismatches are common pitfalls — configuring the listener and backend pool properly avoids this.

just ensure that the overriding hostname settings are similar to this, to actually avoid the redirects.

2. Multi-Site Hosting: One Gateway, Multiple Domains

One of the best things about App Gateway is how one instance can serve many domains.
I mapped:

• api.example.com → backend A (API Management)
• api2.example.com → backend B (frontend website)

This works through a multi-site listener, which inspects the Host header and routes requests to the correct backend.

Basically multi-site listener allows multiple listeners on the same port, so I essentially created 2 listeners for different domains.

Each domain needs its own SSL certificate (SNI-based), so make sure you provision certificates for all the subdomains you intend to serve. I generated mine with Certbot and converted them into .pfx for Azure.

You can read more about certbot here.

3. Host, Path, and Query Rewrites (When URLs Don’t Match)

In many real-world setups, the URL your clients call is not the same as what your backend expects.

For example:

• Incoming: https://api.example.com/public/123
• Backend expects: /api/v1/123

Instead of changing the backend or forcing clients to update URLs, I solved this with a rewrite rule. Using variables like {var_uri_path_1}, I transformed incoming paths before forwarding them to the backend.

This pattern becomes essential when you:

• Version APIs without breaking clients
• Expose a friendly public URL but keep internal routes structured
• Consolidate multiple services behind one gateway

You can read more about routing using variables here.

4. Path-Based Routing for Multi-Version or Blue-Green Deployments

Routing based on path segments is another hidden superpower.
I configured rules like:

• /v1/* → Backend Pool: v1 API
• /v2/* → Backend Pool: v2 API

This setup is in the rules and its incredibly useful when you want:

• Canary rollouts (/canary/* → test backend)
• Multi-version deployments without changing DNS
• Smooth blue-green switches (just update the routing rule)

One surprise I ran into: some frontend assets didn’t load correctly when served from a nested path (e.g. /v0/). That’s because relative asset paths can break when extra segments are introduced. If that happens, you may need frontend rewrites or proxy path adjustments.

5. Redirect Rules and Custom Error Pages

You can define redirect rules for:

• http → https
• www → non-www
• /old → /new

The redirection rules can be defined in the path based routing rules. And for the error pages the static pages can be hosted on the storage account as the website.

I observed that when your backend such as APIM returns the 502, the gateway will fwd the same thing, the custom error pages only kicks in, when the probes become unhealthy.

🔒 Bonus: End-to-End TLS (Re-encryption)

Most of my services were already HTTPS-only, so re-encryption wasn’t optional. But if you terminate TLS at the gateway and your backend requires HTTPS too, you can enable end-to-end TLS easily.

Why it matters:

• Some services reject plain HTTP entirely.
• It’s a must for zero-trust architectures or compliance-heavy environments.

Automating certificate rotation (via Azure Key Vault) is the next step if you’re planning production use.

What This Experiment Taught Me

This small experiment turned into a deep dive into what Application Gateway is truly capable of. From path rewrites to blue-green routing and multi-domain hosting, it’s far more than “just” a reverse proxy.

What I’ve learned:

• Many features look simple on paper but get tricky in real-world implementations.
• A single Application Gateway can front multiple APIs, frontends, and even microservices, if you know how to use rewrites and routing rules well.
• And finally, understanding why something works (or doesn’t) is what takes you from “just deploying” to actually designing infrastructure.

Thanks for reading, Keep learning keep growing.

Reach out me contact information