Article 12 – Flexible Load Balancer (Layer 7): HTTP, HTTPS, and SSL Offloading

1. Introduction to Layer 7 Load Balancing

Modern web applications demand intelligent traffic management, high availability across Availability Domains, SSL/TLS security offloading, and dynamic auto-scaling.

Oracle Cloud Infrastructure (OCI) delivers Layer 7 application load balancing via the Flexible Load Balancer (L7).

The OCI Flexible Load Balancer operates at Layer 7 (Application Layer) of the OSI model. It inspects HTTP/HTTPS header details, request paths, hostnames, and cookies to route traffic intelligently across backend compute pools, container clusters, or bare metal web servers.

2. Core Architectural Features of OCI L7 Load Balancer

1. Flexible Bandwidth Scaling

Unlike legacy load balancers that required static shape selection (e.g., 100 Mbps fixed shape), the OCI L7 Load Balancer uses Flexible Bandwidth:
* Minimum Bandwidth: Baseline guaranteed throughput (e.g., 10 Mbps).
* Maximum Bandwidth: Upper limit ceiling (up to 8,000 Mbps / 8 Gbps).
* The OCI control plane scales underlying load balancer compute nodes dynamically between minimum and maximum limits without connection drops or manual intervention.

2. High Availability Pair Deployment

When you provision a Public Load Balancer, OCI automatically deploys an Active-Active pair of load balancer instances placed in separate Availability Domains (or separate Fault Domains in single-AD regions).

• Single Virtual IP (VIP): Both active nodes share the same Public Reserved IP address. If an AD experiences an outage, traffic shifts seamlessly to the surviving node.

3. Layer 7 Routing Mechanics

The L7 Load Balancer processes traffic using 4 core building blocks:

Incoming HTTPS Request ➔ [Listener] ➔ [Host/Path Request Route Set] ➔ [Backend Set] ➔ [Backend Server]

1. Listeners: Defines incoming protocol (HTTP, HTTPS, TCP), port (e.g., 80, 443), and assigned SSL/TLS certificates.
2. Request Route Sets: Rules evaluating HTTP request attributes:
3. Host-Based Routing: Route api.company.com to API Backend Set; route app.company.com to Main Web Backend Set.
4. Path-Based Routing: Route /images/* or /downloads/* to specialized storage servers.
5. Backend Sets: Logical grouping of application servers with shared health check configurations, load balancing policies, and SSL settings.
6. Health Check Policies: Probes backend servers (HTTP GET, TCP ping) to isolate unhealthy instances automatically.

3. SSL/TLS Termination & Re-Encryption Patterns

The OCI Load Balancer supports 3 distinct SSL encryption workflows:
1. SSL Termination (Offloading – Most Common): SSL handshake is decrypted at the load balancer. Traffic sent from load balancer to backend servers flows over unencrypted HTTP (Port 80) inside the private VCN. Offloads CPU-intensive RSA/ECC cryptographic processing from web VMs.
2. End-to-End SSL (Re-Encryption): Load balancer decrypts incoming HTTPS traffic for Layer 7 inspection/routing, then re-encrypts packets before sending them over HTTPS to backends. Required for strict PCI-DSS / HIPAA compliance.
3. SSL Pass-Through: Handled at Layer 4 (Network Load Balancer). Encrypted packets bypass load balancer inspection entirely and terminate directly on backend servers.

4. OCI Web Console (GUI) Step-by-Step Walkthrough

Follow these operational steps to provision a Public Flexible Load Balancer with HTTPS SSL Termination.

Step 1: Navigating to Load Balancers in the Console

1. Open Navigation Menu (≡) ➔ Networking ➔ Load Balancers.
2. Select your compartment (Network-Compartment).
3. Click Create Load Balancer.

Console Path: [≡ Main Menu] ➔ [Networking] ➔ [Load Balancers]

Step 2: Provisioning the Flexible Load Balancer

1. Select Load Balancer (HTTP/HTTPS) ➔ Click Create Load Balancer.
2. Configure Basic Details:
3. Name: LB-Public-Production
4. Visibility: Select Public.
5. Assign Public IP: Select Reserved Public IP (VIP-Production).
6. Flexible Bandwidth: Min: 10 Mbps | Max: 1000 Mbps.
7. Choose Network:
8. VCN: VCN-Production-Ashburn
9. Subnet: Select Subnet-Public-Regional.
10. Click Next.

Step 3: Configuring Backend Set and Health Check

1. Backend Set Name: BES-App-Tier
2. Load Balancing Policy: Select Weighted Round Robin (or Least Connections / IP Hash).
3. Health Check Policy:
4. Protocol: HTTP
5. Port: 80
6. URL Path: /healthz
7. Interval: 10 seconds
8. Click Add Backends ➔ Select compute instances (VM-App-01 and VM-App-02) ➔ Port 80.
9. Click Next.

Step 4: Configuring Listener with SSL Certificate

1. Listener Name: Listener-HTTPS-443
2. Protocol: HTTPS | Port: 443
3. Under Certificate Management:
4. Select OCI Certificate Service (or upload custom SSL certificate, private key, and CA bundle).
5. Choose certificate: cert-production-example-com.
6. Select Backend Set: BES-App-Tier.
7. Click Submit. OCI provisions the dual-node load balancer cluster in under 2 minutes.

5. Common Architectural Misconceptions & Pitfalls

Misconception 1: “Load Balancer Health Checks Ignore Security Lists”

• Reality: OCI Load Balancer health checks execute via private IP addresses from the load balancer’s subnet. If your backend compute instance Security List or NSG drops incoming TCP/HTTP health check probes from the load balancer subnet CIDR, the load balancer will mark backends as Unhealthy and drop incoming web traffic.

Misconception 2: “Cookie-Based Session Persistence Works When App Servers Modify Cookies”

• Reality: OCI L7 Load Balancer supports Server-Consistent Cookie and Load Balancer-Inserted Cookie persistence. If using Load Balancer-Inserted Cookies, the load balancer injects its own HTTP cookie header. Applications must not overwrite or strip this cookie header.

6. OCI L7 Load Balancer vs. Other Cloud Platforms