You should use Oracle Load Balancing when you require either a public or a private load balancer as an entry point to automatically distribute incoming traffic to multiple servers within your virtual cloud network (VCN).

You can create a load balancer in the networking section of the Oracle Cloud Infrastructure management console.

You can create a load balancer in the networking section of the Oracle Cloud Infrastructure management console. Click "Load Balancers" and then "Create Load Balancer." Alternatively, you can use the CreateLoadBalancer API.

• For an overview and to learn how to launch an instance inside Oracle Cloud Infrastructure, see the Getting Started Guide.
• To learn more about load balancers, see the Overview of the Load Balancing Service section of the Oracle Cloud Infrastructure documentation.

The load balancer checks for incoming traffic on its IP address and distributes that traffic to a list of backend servers, based on the load balancing and health check policies that you have defined in a logical entity called a backend set. The backend set determines how the load balancer directs traffic to the collection of backend servers.

You can define the policies that tell the load balancer how to distribute incoming traffic to the backend servers. Currently, we support the following load balancing policies:

• Round robin
• Least connections
• IP hash

For more information, see How Load Balancing Policies Work in the documentation.

Alternatively, you can determine the health of a load balancer instance in relation to its backend servers in a programmatic way via the load balancer health API.

The load balancer health API is a programmatic mechanism for determining the health of a load balancer instance in relation to its backend servers.

You should use the health API when you wish to build your own notification and monitoring system or integrate with a system you are currently using.

When you programmatically poll the load balancer health API, you can obtain a 3-state health status (okay, warning, and critical) indicating the health of each backend server or, as an aggregate of all backend servers in a backend set, the entire backend set.

The load balancer listener which is a logical entity that checks for incoming traffic on the load balancers IP address. You configure a listener's protocol and port number, and the optional SSL settings.

Currently supported protocols include:

• TCP
• HTTP/1.0
• HTTP/1.1
• HTTP/2

For more information, see Managing Load Balancer Listeners in the documentation.

Yes, the load balancer can handle TCP, HTTP and HTTPS traffic at the same time. To do so, you must configure multiple listeners.

You can load balance for any port between 1-65535.

No. Currently, you need to specify the individual TCP port you want to load balance.

No. The load balancer currently only supports IPv4 traffic.

Yes. You can provide preprovisioned load balancing capacity (bandwidth) by selecting a load balancer shape. A load balancer shape is a template that determines the load balancer's total preprovisioned maximum capacity (bandwidth) for ingress plus egress traffic. Currently available shapes include 100 Mbps, 400 Mbps, and 8000 Mbps.

NOTE: Preprovisioned maximum capacity applies to aggregated connections, not to a single client attempting to use the full bandwidth.

Currently, you cannot change the shape of your load balancer once you created the load balancer. To change the shape of your load balancer (e.g. to increase or decrease the preprovisioned bandwidth for ingress plus egress traffic), you can use the console or API to create another load balancer with the new shape and update the DNS A record associated with you load balancer’s IP address.

Yes. You can optionally terminate SSL at the load balancer. To use SSL with your load balancer, you must add one or more certificate bundles to your system. The certificate bundle you upload includes the public certificate, the corresponding private key, and any associated certificate authority certificates. To terminate SSL at the load balancer, you must create a listener at a default port such as 443, and then associate an uploaded certificate bundle with the listener.

Yes. You can optionally implement SSL tunneling for your TCP load balancer and tunnel incoming SSL connections to your application servers.

The load balancing service supports the TLS 1.2 protocol with a default setting of strong cipher strength. The default supported ciphers include:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-SHA256
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES128-SHA256

Yes. You can enable for your HTTP load balancer server-side, cookie-driven session persistence

Yes. You can you can add, alter, or remove HTTP headers with the listener rule sets feature. A rule set is a named set of rules associated with a load balancer and applied to one or more listeners on that load balancer. Rules are objects that represent actions applied to requests or responses at a load balancer listener. Examples of how rule sets can help you enhance site security include:

• Adding the strict-transport-security header—with a proper value—to responses. This header helps guarantee that access to your site is HTTPS only.
• Adding the x-xss-protection header with a proper value. This header helps you enforce the cross-site scripting (XSS) protection built into modern browsers.
• Adding the x-content-type header with a proper value. This header helps you prevent attacks based on content type shifting.
• Removing debug headers, such as server, sent by backend servers. This action helps you hide the implementation details of your backend.

Yes. You can limit access to the load balancing service via a policy written by an administrator.

Yes. Both the public and private load balancers can be deployed as regional services using the VCN regional subnet option. Regional subnets in a VCN span the entire region which can include multiple ADs. A regional subnet enables you to create a regional private or public load balancer that supports AD failover in the event of an AD outage in an Oracle Cloud Infrastructure multi-AD region. Since a regional load balancer requires only one regional VCN subnet, it reduces the configuration and management overhead required by multiple AD-local subnets.