OCI Load Balancing Options

Once traffic reaches your OCI network it usually needs to be spread across multiple instances, and how you do that determines both your performance and your availability. OCI gives you two distinct load balancers, an application layer load balancer that understands HTTP and can route based on content, and a network layer load balancer that operates at the transport layer for raw throughput and low latency. Choosing between them is not about which is better, it is about what your application needs, and getting it right also means using the load balancer as the tool that makes a single instance failure invisible. This guide covers the two options, when to use each, and how load balancing underpins availability.

Load balancing sits in the middle of the network picture, between the connectivity covered in our complete networking guide and the application itself. It is also where high availability is won or lost, which is why the choice deserves real thought rather than a default.

The application load balancer

The flexible application load balancer operates at the HTTP layer, which means it understands requests and can make decisions based on their content. It can route different paths to different backend sets, terminate encryption, insert headers, and apply rules based on the request. This intelligence is what you want for web applications and APIs where routing logic, encryption handling, and content based decisions matter. Its flexible shape means bandwidth scales with demand rather than being fixed, so you pay for what you use and the balancer grows with traffic.

The network load balancer

The network load balancer operates at the transport layer, working with the raw connection rather than understanding the application protocol. Because it does less, it does it faster, offering very low latency and very high throughput, and it preserves the source address of the client, which some applications require. This is the right choice for non HTTP traffic, for workloads where latency is critical, and for cases where you need the backend to see the real client address. It is simpler and faster precisely because it does not interpret the traffic.

The two load balancers compared

Load balancing and availability

Beyond distributing load, a load balancer is one of the main tools for availability. By spreading backends across fault domains and availability domains and health checking them continuously, the load balancer routes around a failed instance automatically, so a single failure becomes invisible to users rather than an outage. This is why the load balancer is central to any resilient design, and it connects directly to the subnet and availability thinking in our subnet design guide. A load balancer with all its backends in one fault domain gives you distribution without resilience, which misses half the value.

Choosing and configuring

The right load balancer is the one that matches what your application actually does, and the right configuration is the one that uses it for availability and not just distribution. Get both right and the load balancer becomes the layer that keeps the service up through individual failures without anyone noticing. The wider context is in our complete networking guide, and we design load balanced, highly available architectures for clients as part of our OCI networking solution.

Health checks and failure handling

The quiet workhorse of any load balancer is its health checking. The balancer continuously probes each backend, and when one fails a check it is removed from rotation, so traffic stops flowing to it before users notice a problem. When it recovers, it is added back. This is what makes a load balancer a resilience tool and not just a distribution tool, and configuring the health checks well, with appropriate intervals and thresholds, is what determines how quickly the balancer reacts to a failure. Health checks that are too lax leave traffic flowing to a sick instance, while checks that are too aggressive can remove a healthy instance over a transient blip. Getting them right is part of the design, not a default to accept blindly.

Encryption handling

Where you terminate encryption is a design decision the load balancer mediates. The application load balancer can terminate encryption at the balancer, decrypting incoming traffic and forwarding it to backends, which simplifies certificate management and lets the balancer inspect and route on content. Alternatively it can pass encrypted traffic through to the backends, which keeps the data encrypted all the way to the application at the cost of the balancer's content awareness. The right choice depends on your security requirements and on whether you need content based routing, and it connects to the certificate management practices that keep encryption working without expiry surprises.

Designing for availability

The full value of a load balancer is realised only when the backends behind it are spread for resilience. A balancer with all its backends in a single fault domain distributes load but does not survive the loss of that fault domain. Spreading backends across fault domains, and where appropriate across availability domains, means the balancer can route around the loss of any one of them, keeping the service available through failures that would otherwise be outages. This is the pattern that ties load balancing to the resilience thinking in our subnet design guide, and it is the difference between a load balancer that improves performance and one that also improves availability.