Azure Application Gateway v2 The Ultimate Guide to Multi-Protocol (L4/L7) Load Balancing

In modern cloud networking, the traditional separation between web traffic and raw data streams is vanishing. Architects now require a single, resilient entry point that can handle a corporate website (HTTPS), a database cluster (SQL on TCP), and an IoT broker (Secure MQTT on TLS) simultaneously.

With the Azure Application Gateway v2 SKU, Microsoft has transitioned this service from a simple web load balancer into a sophisticated Application Delivery Controller (ADC). This article explores how to architect, enable, and monitor a multi-protocol gateway.

1. Architectural Foundation: The Terminating Proxy

Unlike a standard Network Load Balancer (NLB) which operates via "flow-through" packet forwarding, the Application Gateway is a Terminating Proxy.

How it Works:

1. 1. Client Connection: The client connects to the Gateway’s Frontend IP. The Gateway terminates this connection at the listener level.
   2. Gateway Processing: For Layer 7 (HTTP/S), it can inspect headers, paths, and WAF rules. For Layer 4 (TCP/TLS), it acts as a transparent proxy, simply acknowledging the handshake.
   3. Backend Connection: The Gateway initiates a new connection from its internal subnet IP to the backend server.

Key Benefit: This architecture enables TLS Offloading. You can secure your TCP services with high-grade certificates at the Gateway, while your backend servers receive unencrypted traffic, saving significant CPU cycles on the backend.

     2. Protocol Breakdown: HTTP, HTTPS, TCP, and TLS

Note: While UDP support is available for specific scenarios like DNS, TCP and TLS remain the primary focus for connection-oriented enterprise apps.

     3. The "Gatekeepers" Listeners and Rules

 The Listener is the logical endpoint that waits for traffic. To support a unified stack, you must configure different listener types on the same Gateway.

1. 1. Layer 7 Listeners: Require a host header (e.g., api.testlab.com) and can use Path-based rules to send /images to one pool and /videos to another.
   2. Layer 4 Listeners: Do not understand URLs or host headers. They route traffic based purely on the Frontend Port. If traffic hits Port 1433, it follows the TCP rule to the SQL pool.

     4. Health Probes The Pulse of Your Backend

A gateway is only as reliable as its monitoring. Because TCP/TLS doesn't have "Status Codes" (like 200 OK), the probing logic is different.

1. 1. HTTP/S Probes: The Gateway sends a GET request to a specific path (e.g., /health) and expects a response between 200–399.

   2. TCP Probes: The Gateway performs a TCP Three-Way Handshake. If the backend server responds with a SYN-ACK, it is considered healthy.
   3. TLS Probes: These perform the TCP handshake followed by a TLS Greeting. This ensures the backend's encryption service is actually responsive.

     5. Implementation Guide the Configuration Path 

To enable these features, follow this specific configuration path in the Azure Portal or via CLI.

Step 1: Enable the Feature 

Ensure you are using the Standard_v2 or WAF_v2 SKU. Navigate to your Application Gateway resource.

Step 2: The Portal Path

1. 1. Listeners: Go to Settings > Listeners > + Add Listener. Choose Protocol: TCP or TLS. Set your port (e.g., 1433 for SQL).
   2. Backend Settings: Go to Settings > Backend settings > + Add.
      1. 1. Crucial: Select Protocol: TCP (not HTTP). This removes the requirement for host headers and cookie affinity.
   3. Rules: Go to Settings > Configuration > + Add Routing Rule. Link your TCP Listener to your  Backend Setting and Backend Pool.

Step 2: CLI Path (Automation)

To add a TCP listener for a SQL server via Azure CLI: