Multi-Site Hosting

Mastering Multi-Site Hosting with Application Gateway

Introduction: The Gateway to Efficient Resource Management

In modern cloud architecture, the ability to serve multiple distinct websites or applications from a single entry point is not just a convenience—it is a fundamental requirement for cost efficiency and operational simplicity. Application Gateway, as a Layer 7 load balancer, provides the capability to perform multi-site hosting. This means you can direct incoming web traffic to different backend server pools based on the hostname, the URL path, or other request headers, all while managing your SSL certificates and security policies in one place.

Why does this matter? Imagine managing ten separate web applications, each requiring its own public IP address, its own firewall configuration, and its own SSL certificate lifecycle management. The administrative overhead would be immense, and the security surface area would be significantly larger. By using multi-site hosting on an Application Gateway, you consolidate these requirements. You present a single, hardened interface to the public internet, and the gateway intelligently routes traffic to the appropriate backend infrastructure behind the scenes. This lesson will guide you through the architectural concepts, configuration steps, and best practices for implementing robust multi-site hosting solutions.

Architectural Foundations of Multi-Site Hosting

To understand multi-site hosting, we must first define the core components of an Application Gateway. An Application Gateway acts as a "traffic cop" for your web traffic. When a request arrives, the gateway inspects the request and makes a decision based on pre-configured rules. In a multi-site scenario, the primary decision factor is usually the "Host" header provided by the client's browser.

Core Components

• Frontend IP Configuration: The single entry point (usually a public IP) where all traffic for all your hosted sites arrives.
• Listeners: These define how the gateway listens for incoming traffic. In a multi-site setup, you will have multiple listeners, each configured to watch for a specific hostname (e.g., api.example.com vs. portal.example.com).
• Backend Pools: These are the groups of servers (virtual machines, scale sets, or App Services) that actually host the application code.
• Routing Rules: These are the logic gates that map a specific listener to a specific backend pool.

Callout: Layer 7 vs. Layer 4 Routing It is important to distinguish between the load balancing provided by an Application Gateway (Layer 7) and a standard Load Balancer (Layer 4). Layer 4 load balancing operates at the transport level, looking only at IP addresses and ports. Because it doesn't "read" the HTTP request, it cannot distinguish between site-a.com and site-b.com if they arrive on the same port. Layer 7 routing, used by Application Gateway, inspects the actual HTTP headers, allowing for host-based and path-based routing, which is the foundation of multi-site hosting.

The Mechanics of Host-Based Routing

Host-based routing is the most common form of multi-site hosting. When a user types www.store.com into their browser, the browser sends an HTTP request with a Host: www.store.com header. The Application Gateway receives this packet, checks its list of configured listeners, finds the one matching www.store.com, and triggers the associated routing rule.

Step-by-Step Configuration Flow

1. Define Backend Pools: Create separate pools for each site. For instance, create a Store-Pool for your e-commerce site and a Blog-Pool for your content site.
2. Configure Listeners: Create a listener for each domain. You must specify the frontend port (usually 443 for HTTPS) and the specific hostname.
3. Create Routing Rules: Link each listener to its respective backend pool. If you have a rule for store.com, it must point to the Store-Pool.
4. Health Probes: Configure individual health probes for each site. This ensures that if the Blog-Pool goes down, the Application Gateway stops sending traffic there, while the Store-Pool remains unaffected.

Note: When using multiple sites, ensure that your DNS provider is configured to point the CNAME or A records for all these domains to the single Public IP address of the Application Gateway. Without correct DNS propagation, the gateway will never receive the requests.

Practical Implementation: A Scenario-Based Approach

Let’s walk through a concrete example. Suppose you are a company operating two services: a internal employee dashboard (dashboard.internal.com) and a public-facing help site (help.company.com).

1. Setting up the Backend Pools

You create two separate backend pools. The DashboardPool consists of a Virtual Machine Scale Set, while the HelpPool consists of two standard Virtual Machines.

2. Configuring HTTPS Listeners

Since you are dealing with web traffic, you should use HTTPS. You will need to upload a certificate for each domain or use a wildcard certificate. You configure two listeners:

• Listener 1: Dashboard-Listener, Port 443, Hostname: dashboard.internal.com
• Listener 2: Help-Listener, Port 443, Hostname: help.company.com

3. Defining the Routing Rules

You create two basic routing rules:

• Rule 1: Dashboard-Rule. Matches Dashboard-Listener and forwards traffic to Dashboard-Pool.
• Rule 2: Help-Rule. Matches Help-Listener and forwards traffic to Help-Pool.

Code Snippet: Defining a Basic Rule (JSON Configuration)

While most users use the portal, understanding the JSON structure is vital for automation via Infrastructure as Code (IaC) tools like Terraform or Bicep.

{
  "name": "Dashboard-Rule",
  "properties": {
    "ruleType": "Basic",
    "httpListener": {
      "id": "/subscriptions/.../httpListeners/Dashboard-Listener"
    },
    "backendAddressPool": {
      "id": "/subscriptions/.../backendAddressPools/Dashboard-Pool"
    },
    "backendHttpSettings": {
      "id": "/subscriptions/.../backendHttpSettings/Default-Settings"
    }
  }
}

Explanation: This snippet defines the mapping. The httpListener tells the gateway which incoming request to look for, and the backendAddressPool tells the gateway where to send that traffic once the match is confirmed.

Advanced Routing: Path-Based Rules

Sometimes, multi-site hosting isn't enough. You might have company.com and want to serve the main site from one pool, but serve /images or /api from a completely different set of servers. This is called Path-Based Routing.

Implementing Path-Based Rules

Path-based rules allow you to add a second layer of intelligence. After the gateway identifies the host (e.g., company.com), it then looks at the URL path (e.g., /api/v1/users).

1. Create a Path-Based Rule: Instead of a "Basic" rule, select "Path-based".
2. Define Paths: Map /api/* to the API-Server-Pool and / (the root) to the Web-Server-Pool.
3. Priority: You must define the order of evaluation if paths overlap.

Warning: Be very careful with path ordering. If you define a rule for / before a rule for /api, the gateway might catch all traffic in the / rule and never reach the /api rule. Always place more specific paths (like /api/v1/auth) before general paths (like /).

Best Practices for Multi-Site Hosting

Adopting multi-site hosting requires a disciplined approach to configuration and management. Following these industry standards will prevent downtime and security vulnerabilities.

1. SSL/TLS Certificate Management

Never use self-signed certificates in production. With multiple sites, managing individual certificates can become a nightmare. Consider using a wildcard certificate (e.g., *.company.com) if all your sites share a root domain. If they are completely different domains (e.g., site-a.com and site-b.com), you will need to manage multiple certificates, which makes automation via tools like Key Vault essential.

2. Standardizing Health Probes

Each backend pool should have a custom health probe. Do not rely on default probes that just check if the server is alive. Configure your probes to check a specific "heartbeat" page (e.g., /health-check) that verifies the application's ability to connect to databases and other dependencies. If the database is down, the probe should fail, and the gateway should remove that server from the rotation.

3. Implementing Redirection

Often, you want to force all traffic to HTTPS. In a multi-site setup, you should create a listener on Port 80 for each site that simply redirects traffic to the corresponding HTTPS listener on Port 443. This ensures that no user accidentally browses your site over an unencrypted connection.

4. Logging and Monitoring

Because all traffic flows through one gateway, you must enable diagnostic logging. Without logs, troubleshooting a routing issue for one specific site becomes an exercise in guessing. Enable logs for ApplicationGatewayAccessLog and ApplicationGatewayPerformanceLog and stream them to a centralized workspace for analysis.

Comparison: Basic vs. Multi-Site Routing

Avoiding Common Pitfalls

Even experienced engineers run into issues when consolidating services. Here are the most frequent mistakes and how to avoid them.

Pitfall 1: DNS Mismatch

The most common issue is a mismatch between the DNS record and the listener hostname. If your listener is configured for site.com but the user requests site.net, the Application Gateway will return a 404 or a default site response.

• The Fix: Always verify your DNS CNAME records. If you are using a custom domain, ensure the Host header is preserved as it passes through the gateway.

Pitfall 2: Overlapping Rules

As mentioned earlier, path-based rules require careful ordering. A common error is placing a catch-all rule (like /) at the top of the priority list, which effectively "steals" traffic intended for more specific paths.

• The Fix: Use the priority number feature in your gateway settings to explicitly order rules from most specific to least specific.

Pitfall 3: Backend HTTP Settings Mismatch

If you have two sites, one requiring HTTPS on the backend and one requiring plain HTTP, you need two different "Backend HTTP Settings" objects. A common mistake is trying to share one setting object for both, leading to SSL handshake failures.

• The Fix: Create distinct Backend HTTP Settings for each backend pool that requires different protocol or port configurations.

Pitfall 4: Neglecting WAF Policies

When you move multiple sites behind one gateway, you might be tempted to apply one Web Application Firewall (WAF) policy to the whole gateway. However, one site might be a legacy application that needs "Detection Only" mode, while another is a modern app that requires "Prevention" mode.

• The Fix: Use per-site WAF policies if your gateway version supports it, or ensure your global policy is set to the most restrictive level required by your most sensitive application.

Deep Dive: Security and Isolation

When hosting multiple sites on a single gateway, you are essentially creating a shared resource. If one site is compromised, you do not want that to lead to the compromise of the others.

Network Security Groups (NSGs)

The Application Gateway should sit in its own dedicated subnet. The NSG for this subnet should allow inbound traffic on 80/443, but you should also restrict outbound traffic from the gateway to the backend subnets. By using service tags, you can ensure that the Application Gateway is the only entity allowed to communicate with your backend servers on the application ports.

The Role of Key Vault

Managing SSL certificates for multiple sites manually is a recipe for expired certificates and site outages. Integrate your Application Gateway with Key Vault. By storing your certificates in Key Vault and granting the Application Gateway's Managed Identity access to them, you can enable automatic certificate rotation. When you update the certificate in Key Vault, the gateway will automatically pick up the new version without requiring a manual update.

Performance Considerations

While consolidating services saves money, it also concentrates load. If one site experiences a massive traffic spike, it could potentially starve the resources of the other sites sharing the same gateway.

• Capacity Monitoring: Keep a close eye on the "Compute Units" or "Capacity Units" metrics. If you see high utilization, you may need to increase the minimum instance count of your Application Gateway.
• Autoscaling: Always enable autoscaling on your gateway so it can handle spikes in traffic across all hosted sites simultaneously.

Step-by-Step: Configuring a New Site

If you are tasked with adding a new site to an existing Application Gateway, follow this structured workflow to ensure no downtime.

1. Prepare the Backend: Deploy your new application and ensure it responds correctly on a local port. Verify connectivity from the Application Gateway subnet using a test tool or PowerShell Test-NetConnection.
2. Create the Pool: Add the new backend resources to a new Backend Address Pool.
3. Provision the Certificate: Upload the necessary SSL certificate to the Key Vault or the gateway directly.
4. Create the Listener: Define the new listener with the specific hostname.
5. Create the Rule: Create a new rule linking the listener to the backend pool.
6. Verify Routing: Use curl or a browser developer tool to inspect the request headers. Ensure the Host header matches what you configured.
7. DNS Update: Point the new domain's DNS record to the Application Gateway's Public IP.

Tip: Always perform these steps in a staging environment first. Use a temporary domain (like test.company.com) to verify that the listener and routing rules are working as expected before pointing your production traffic to the new configuration.

Common Questions (FAQ)

Can I host HTTP and HTTPS sites on the same gateway?

Yes. You can have multiple listeners on the same gateway. Some can be configured for port 80 (HTTP) and others for 443 (HTTPS). You can even use the HTTP listeners to redirect users to the HTTPS versions automatically.

Is there a limit to how many sites I can host?

Yes, there are limits on the number of listeners and rules per Application Gateway. While these limits are quite high, you should check the current Azure documentation for your specific tier (Standard vs. WAF) to ensure you aren't approaching the ceiling.

Do all sites need to be in the same resource group?

No. The Application Gateway can route traffic to backend servers located in different resource groups, different virtual networks, and even different subscriptions, provided there is network connectivity (e.g., VNet peering).

What happens if the Application Gateway fails?

The Application Gateway is a regional service. If the gateway fails, all sites hosted on it will go down. For high-availability requirements, you should consider using Azure Front Door, which provides global, multi-region load balancing and failover capabilities.

Key Takeaways

1. Consolidation Efficiency: Multi-site hosting reduces costs and administrative burden by allowing you to manage multiple applications through a single, unified entry point.
2. Layer 7 Intelligence: The power of the Application Gateway lies in its ability to inspect HTTP headers, enabling sophisticated routing based on hostnames and URL paths.
3. Strict Configuration Ordering: Always prioritize your routing rules from most specific to most general to avoid traffic being intercepted by unintended rules.
4. Automation is Essential: Use Infrastructure as Code and integrate with Key Vault for certificate management to ensure your configuration is repeatable, version-controlled, and secure.
5. Proactive Health Monitoring: Custom health probes are the heart of a reliable gateway; ensure each site has a dedicated probe that monitors the actual health of the application, not just the network availability of the server.
6. Security Isolation: While sharing a gateway, maintain security boundaries through proper NSG configuration and, where possible, per-site WAF policies to protect each application according to its unique risk profile.
7. Planning for Scale: Monitor the compute utilization of your gateway closely. Since it serves as a central hub, it is a single point of resource contention; enable autoscaling to accommodate traffic volatility.

By mastering these concepts, you transition from simply "hosting" applications to building a professional-grade traffic management layer that is scalable, secure, and easy to maintain. Whether you are managing two sites or twenty, the principles of clear listener definition, precise rule mapping, and automated certificate management remain the pillars of a successful implementation.