Load balance HTTP(S) traffic in Azure Flashcards
Azure Application Gateway
Application Gateway provides features such as load balancing HTTP traffic and web application firewall. It provides support for TLS/SSL encryption of traffic between users and an application gateway and between application servers and an application gateway.
- You can configure session stickiness if you need to ensure that all requests for a client in the same session are routed to the same server in a back-end pool.
- Support for the HTTP, HTTPS, HTTP/2, and WebSocket protocols
- A web application firewall to protect against web application vulnerabilities
- End-to-end request encryption
- Autoscaling to dynamically adjust capacity as your web traffic load change
- Connection draining allowing graceful removal of back-end pool members during planned service updates
Application Gateway - Components
Front-end IP address - Client requests are received through a front-end IP address. You can configure Application Gateway to have a public IP address, a private IP address, or both. Application Gateway can’t have more than one public IP address and one private IP address.
Listeners - Application Gateway uses one or more listeners to receive incoming requests. A listener accepts traffic arriving on a specified combination of protocol, port, host, and IP address. Order of processing listeners
For the v1 SKU, requests are matched according to the order of the rules and the type of listener. For the v2 SKU, multi-site listeners are processed before basic listeners.
Each listener routes requests to a back-end pool of servers following routing rules that you specify. A listener can be Basic or Multi-site.
- A Basic listener only routes a request based on the path in the URL.
- A Multi-site listener can also route requests using the hostname element of the URL.
Routing rules - A routing rule binds a listener to the back-end pools. A rule specifies how to interpret the hostname and path elements in the URL of a request and direct the request to the appropriate back-end pool. A routing rule also has an associated set of HTTP settings. These HTTP settings indicate whether (and how) traffic is encrypted between Application Gateway and the back-end servers.
Application Gateway - Web Application Firewall
The web application firewall (WAF) is an optional component that handles incoming requests before they reach a listener. The web application firewall checks each request for many common threats based on the Open Web Application Security Project (OWASP).
Back-end pools
A back-end pool is a collection of web servers that can be made up of: a fixed set of virtual machines, a virtual machine scale-set, an app hosted by Azure App Services, or a collection of on-premises servers.
Application Gateway uses a rule to specify how to direct the messages that it receives on its incoming port to the servers in the back-end pool. If the servers are using TLS/SSL, you must configure the rule to indicate:
- That your servers expect traffic through the HTTPS protocol.
- Which certificate to use to encrypt traffic and authenticate the connection to a server.
Application Gateway - Routing
When the gateway routes a client request to a web server in the back-end pool, it uses a set of rules configured for the gateway to determine where the request should go.
There are two primary methods of routing this client request traffic:
1. Path-based routing - Sends requests with different URL paths to different pools of back-end servers. For example, you could direct requests with the path /video/* to a back-end pool containing servers that are optimized to handle video streaming
2. Multiple-site routing - Configures more than one web application on the same Application Gateway instance. In a multi-site configuration, you register multiple DNS names (CNAMEs) for the IP address of the application gateway, specifying the name of each site.
Application Gateway routing also includes these features:
- Redirection. Redirection can be used to another site, or from HTTP to HTTPS.
- Rewrite HTTP headers. HTTP headers allow the client and server to pass parameter information with the request or the response.
- Custom error pages. Application Gateway allows you to create custom error pages instead of displaying default error pages.
TLS/SSL Termination
What is TLS/SSL Termination?
- When a user sends an HTTPS request, it’s encrypted using TLS/SSL.
- Instead of decrypting this request on your backend servers (which can be CPU-intensive), Azure Application Gateway handles decryption.
How does it work?
* The Application Gateway receives incoming encrypted traffic.
* It has a TLS/SSL certificate to decrypt the traffic.
It can either:
* Forward it as plain HTTP to backend servers (not recommended for sensitive data).
* Re-encrypt it using another TLS/SSL certificate before sending it to the backend (for end-to-end encryption).
Why is this useful?
* Reduces load on backend servers (as they don’t have to handle TLS/SSL).
* Simplifies certificate management (certificates are handled at the gateway, not on every server).
* Enhances security by ensuring backend servers are not directly exposed to the internet.
Health Probes
Health probes determine which servers are available for load-balancing in a back-end pool. The Application Gateway uses a health probe to send a request to a server. When the server returns an HTTP response with a status code between 200 and 399, the server is considered healthy.
- When using custom probes, you can configure a custom hostname, URL path, probe interval, and how many failed responses to accept before marking the back-end pool instance as unhealthy, etc.
- An application gateway automatically configures a default health probe when you don’t set up any custom probe configurations.
The source IP address that the Application Gateway uses for health probes depends on the backend pool:
- If the server address in the backend pool is a public endpoint, then the source address is the application gateway’s frontend public IP address.
- If the server address in the backend pool is a private endpoint, then the source IP address is from the application gateway subnet’s private IP address space.
Autoscaling
Application Gateway supports autoscaling, and can scale up or down based on changing traffic load patterns. Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning.
Listeners
A listener is a logical entity that checks for incoming connection requests by using the port, protocol, host, and IP address. When you configure a listener, you must enter values that match the corresponding values in the incoming request on the gateway.
Redirection
You can use application gateway to redirect traffic. The gateway has a generic redirection mechanism which allows for redirecting traffic received at one listener to another listener or to an external site.
These redirection types are supported:
* 301 Permanent Redirect
* 302 Found
* 303 See Other
* 307 Temporary Redirect
Global redirection: Redirects from one listener to another listener on the gateway. This enables HTTP to HTTPS redirection on a site.
Path-based redirection: Enables HTTP to HTTPS redirection only on a specific site area, for example a shopping cart area denoted by /cart/*.
Redirect to external site: Requires a new redirect configuration object, which specifies the target listener or external site to which redirection is desired.
Azure Front Door
Azure Front Door is Microsoft’s modern cloud Content Delivery Network (CDN) that provides fast, reliable, and secure access between your users and your applications. Azure Front Door delivers your content using the Microsoft’s global edge network with hundreds of global and local POPs distributed around the world close to both your enterprise and consumer end users.
Azure Content Delivery Network - Delivers high-bandwidth content to your users by caching their content at strategically placed physical nodes around the world.
Azure Front Door - Tier Comparison
Azure Front Door is offered in two different tiers, Azure Front Door Standard and Azure Front Door Premium. Azure Front Door Standard and Premium tier combine capabilities of Azure Front Door (classic), Azure CDN Standard from Microsoft (classic), and Azure WAF into a single secure cloud CDN platform with intelligent threat protection.
Azure Front Door - Routing Architecture
- Select and connect to Azure Front Door edge location
- Match to Azure Front Door profile, establish TLS connection
- Evaluate WAF rules
- Match Azure Front Door route, select origin group
- Evaluate rules engine rules
- Return cached content
- Select origin from origin group
- Forward request to origin
Azure Front Door - Route Rules Configuration
1. Incoming Match: Determines if a request matches a routing rule based on:
* HTTP Protocols (HTTP/HTTPS)
* Hosts (e.g., www.foo.com, *.bar.com)
* Paths (e.g., /users/, /file.gif)
2. Route Data:
* If caching is enabled, Front Door serves the cached response.
* If no cached response is found, the request is forwarded to the backend pool.
3. Route Matching: Matches the most specific rule first, based on:
* Frontend Host Matching: Exact match required, otherwise returns 400 Bad Request.
* Path Matching:
-Looks for an exact match first.
-If no exact match, checks for wildcard (/*) paths.
-If no match is found, returns 400 Bad Request.
4. Catch-All Rule: If there are no routing rules for an exact-match host with a catch-all (/*) route, the request will fail.
Azure Front Door processes requests in a structured way, ensuring specific matches before forwarding traffic. It allows path-based redirection, which is useful for microservices.
Redirection Types & Protocols
301 | Moved permanently - Indicates that the target resource was assigned a new permanent URI.
302 | Found - Indicates that the target resource is temporarily under a different URI.
307 | Temporary redirect - Indicates that the target resource is temporarily under a different URI.
308 | Permanent redirect - Indicates that the target resource was assigned a new permanent URI.
You can set the protocol used for redirection. The most common use case of the redirect feature is to set HTTP to HTTPS redirection.
- HTTPS only: Set the protocol to HTTPS only, if you’re looking to redirect the traffic from HTTP to HTTPS.
- HTTP only: Redirects the incoming request to HTTP
- Match request: This option keeps the protocol used by the incoming request.
Destination Host / Path / Fragment & Query String Parameters
Destination host - As part of configuring a redirect routing, you can also change the hostname or domain for the redirect request. So, using this field you can redirect all requests sent on https://www.contoso.com/* to https://www.fabrikam.com/*.
Destination path - For cases where you want to replace the path segment of a URL as part of redirection, you can set this field with the new path value. So, using this field, you can redirect all requests sent to https://www.contoso.com/* to https://www.contoso.com/redirected-site.
Destination fragment - The destination fragment is the portion of URL after the number sign (#). You can set this field to add a fragment to the redirect URL.
Query string parameters - You can also replace the query string parameters in the redirected URL. Using this field, you can redirect all traffic sent to https://www.contoso.com/foo/bar to https://www.contoso.com/foo/bar?&utm_referrer=https%3A%2F%2Fwww.bing.com%2F
Configure Rewrite Policies
Azure Front Door supports URL rewrite by configuring an optional Custom Forwarding Path to use when constructing the request to forward to the backend.
Configure Health Probes
Azure Front Door uses health probes to determine backend health and proximity by periodically sending HTTP/HTTPS requests. These probes help route traffic to the best available backend.
Key Points:
* Probe frequency varies from 25 to 1200 requests per minute, depending on configuration.
* Default probe frequency: 30 seconds (~200 requests/minute per backend).
Supported HTTP Methods:
* GET: Retrieves entity information.
* HEAD (default): Similar to GET but returns no message body, reducing backend load.
Health Probe Responses:
1. Determining Health:
* A 200 OK means the backend is healthy.
* Any failure (e.g., network failure, no response) marks the probe as failed.
2. Measuring Latency:
* Measures the time from probe request initiation to response completion.
* Uses a new TCP connection each time to avoid bias.
Health Evaluation Process:
1. Exclude disabled backends.
2. Exclude backends with multiple probe failures, based on configurable thresholds (SampleSize & SuccessfulSamplesRequired).
3. Measure and maintain latency for healthy backends.
If a backend pool has only one active backend, health probes can be disabled to reduce load.
Secure Front Door with TLS/SSL
Using the HTTPS protocol ensures sensitive data is delivered securely. When your web browser is connected to a web site via HTTPS, it validates the web site’s security certificate and verifies that it is from a legitimate certificate authority.
Some of the key attributes of the custom HTTPS feature are:
No extra cost: There are no costs for certificate acquisition or renewal and no extra cost for HTTPS traffic.
Simple enablement: Simplified provisioning is available from the Azure portal. You can also use REST API or other developer tools to enable the feature.
Complete certificate management: All certificate procurement and management is handled for you. Certificates are automatically provisioned and renewed before expiration, which removes the risks of service interruption because of a certificate expiring.
