Frontend Configuration

In the context of load balancers, the term frontend refers to the components that a client can see and send requests to. The entry point of client requests is the outward-facing floating IP address of the load balancer. Incoming traffic is checked by listeners, which are configured for specific protocols and ports. Different types of rules can be defined to categorize incoming requests and route them accordingly to different sets of backend servers.

Load Balancer Types

The Load Balancing service allows you to create a public or private load balancer within a VCN. Load balancers are deployed in pairs: one active and one standby instance sharing a floating IP address. A public load balancer has a public IP address that is accessible from outside the Private Cloud Appliance network environment. A private load balancer has an IP address from the hosting subnet, which is visible only within the VCN.

You can configure multiple listeners for an IP address to load balance transport Layer 4 and Layer 7 (TCP and HTTP) traffic. Both public and private load balancers act as reverse proxies and can route data traffic to any backend server that is reachable from the VCN.

All load balancers have a backend set to route incoming traffic to compute instances. The backend set is a logical entity that includes:

a list of backend servers
a load balancing policy
a health check policy
(optional) SSL handling
(optional) session persistence configuration

The backend servers – compute instances – associated with a backend set can exist anywhere, as long as the associated network security groups (NSGs), security lists, and route tables allow the intended traffic flow.

Private Load Balancer

To isolate your load balancer from the network outside the appliance and simplify its security posture, you can create a private load balancer. The Load Balancing service assigns it a private IP address that serves as the entry point for incoming traffic.

When you create a private load balancer, the service requires only one subnet to host both the primary and standby load balancers. The load balancer is accessible only from within the VCN that contains the host subnet, or as further restricted by your security rules.

The assigned floating private IP address is local to the host subnet. The primary and standby load balancers each require an extra private IP address from the host subnet.

Public Load Balancer

To accept traffic from a network location outside of the appliance, you create a public load balancer. A public load balancer must be deployed in a public subnet of a VCN that has an internet gateway configured. The service assigns the load balancer a public IP address that serves as the entry point for incoming traffic. You can associate the public IP address with a friendly DNS name through any DNS provider.

A Private Cloud Appliance is a single Availability Domain by definition, which implies that the primary and standby load balancers cannot be deployed in separate Availability Domains as it is done in Oracle Cloud Infrastructure. Therefore, both the primary and standby load balancer are deployed in the same subnet, and they each are assigned a private IP address from that host subnet. In addition, a load balancer uses one floating public IP address that can be reassigned between standby and primary as required.

Load Balancing Policies

After you create a load balancer, you can apply policies to control traffic distribution to your backend servers. The primary policy types that the Load Balancing service supports, are: Round Robin, Least Connections, and IP Hash.

Round Robin

The Round Robin policy is the default load balancer policy. This policy distributes incoming traffic sequentially to each server in a backend set list. After each server has received a connection, the load balancer repeats the list in the same order.

Round Robin is a simple load balancing algorithm. It works best when all the backend servers have similar capacity and the processing load required by each request does not vary significantly.

Least Connections

The Least Connections policy routes incoming non-sticky request traffic to the backend server with the fewest active connections. This policy helps you maintain an equal distribution of active connections with backend servers. As with the round robin policy, you can assign a weight to each backend server and further control traffic distribution.

This policy works best with protocols using long sessions, such as LDAP and SQL. It is not recommended for short sessions as typically seen in HTTP use cases. If you select the Least Connections policy for HTTP connections, the load balancer might instead apply Round Robin internally, and even adjust server weighting dynamically.

Note:

In TCP use cases, a connection can be active but have no current traffic. Such connections do not serve as a good load metric.

IP Hash

The IP Hash policy uses an incoming request's source IP address as a hashing key to route non-sticky traffic to the same backend server. The load balancer routes requests from the same client to the same backend server as long as that server is available. This policy honors server weight settings when establishing the initial connection.

Note:

You cannot add a backend server marked as Backup to a backend set that uses the IP Hash policy.

Caution:

Multiple clients that connect to the load balancer through a proxy or NAT router appear to have the same IP address. If you apply the IP Hash policy to your backend set, the load balancer routes traffic based on the incoming IP address and sends these proxied client requests to the same backend server. If the proxied client pool is large, the requests could flood a backend server.

When processing load or capacity varies among backend servers, you can refine each of these policy types with backend server weighting. Weighting affects the proportion of requests directed to each server. For example, a server weighted '3' receives three times the number of connections as a server weighted '1.' You assign weights based on criteria of your choosing, such as each server's traffic-handling capacity. Weight values must be from 1 to 100.

Load balancer policy decisions apply differently to TCP load balancers, cookie-based session persistent HTTP requests – also known as sticky requests –, and non-sticky HTTP requests.

A TCP load balancer considers policy and weight criteria to direct an initial incoming request to a backend server. All subsequent packets on this connection go to the same endpoint.
An HTTP load balancer configured to handle cookie-based session persistence forwards requests to the backend server specified by the cookie's session information.
For non-sticky HTTP requests, the load balancer applies policy and weight criteria to every incoming request and determines an appropriate backend server. Multiple requests from the same client could be directed to different servers.

Listeners

The listener is a logical entity at the ingress side of the load balancer setup. It is the key component that detects incoming traffic on the load balancer IP address. It listens for requests from clients using a particular protocol and port. Requests are subsequently routed to the appropriate backend servers based on the rules defined in the load balancer configuration. To handle TCP, HTTP, and HTTPS traffic, you must configure at least one listener per traffic type.

When you create a listener, ensure that your VCN security rules allow the listener to accept traffic.

Note:

To accommodate high-volume traffic, Oracle strongly recommends that you use stateless security rules for your load balancer subnets. For more information, refer to the section Virtual Firewall in the chapter Virtual Networking Overview.

You can have one SSL certificate bundle per listener. You can configure two listeners, one each for ports 443 and 8443, and associate SSL certificate bundles with each listener. For more information about SSL certificates for load balancers, see Load Balancer SSL Certificates.

Cipher Suites

A cipher suite is a set of algorithms or ciphers that help secure network connections using Transport Layer Security (TLS). You configure cipher suites for a load balancer to determine the security, compatibility and speed of HTTPS traffic. All ciphers are associated with at least one version of TLS (1.0, 1.1, 1.2).

Any cipher suite you use or create must contain individual ciphers that match the TLS version supported in your environment. For example, if your environment supports TLS version 1.2, you can use a cipher suite containing ciphers that work with TLS 1.2. You can use predefined cipher suites or create your own. You add or change the cipher suite associated with a load balancer as part of the listener configuration.

Predefined Cipher Suites

The Load Balancing service supports these predefined cipher suites.

oci-default-ssl-cipher-suite-v1

This cipher suite contains a restricted set of ciphers that are only supported in TLS version 1.2 and meet stricter compliance requirements.

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

oci-modern-ssl-cipher-suite-v1

This cipher suite offers a wider set of ciphers, but still limited to TLS version 1.2 only.

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

oci-compatible-ssl-cipher-suite-v1

This cipher suite supports the broadest set of ciphers. It contains ciphers supported by TLS versions 1.1 and 1.2.

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA
AES256-GCM-SHA384
AES256-SHA256
AES256-SHA
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256

oci-wider-compatible-ssl-cipher-suite-v1

This cipher suite contains all supported ciphers.

TLS version 1.2:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
AES128-SHA256
AES256-GCM-SHA384
AES256-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DH-DSS-AES256-GCM-SHA384
DHE-DSS-AES256-GCM-SHA384
DH-RSA-AES256-GCM-SHA384
DHE-DSS-AES256-SHA256
DH-RSA-AES256-SHA256
DH-DSS-AES256-SHA256
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDH-RSA-AES256-SHA384
ECDH-ECDSA-AES256-SHA384
DH-DSS-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
DH-RSA-AES128-GCM-SHA256
DHE-DSS-AES128-SHA256
DH-RSA-AES128-SHA256
DH-DSS-AES128-SHA256
ECDH-RSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256
ECDH-RSA-AES128-SHA256
ECDH-ECDSA-AES128-SHA256

TLS version 1.1:

ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES128-SHA
AES256-SHA
DES-CBC3-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-RSA-CAMELLIA128-SHA
DHE-RSA-SEED-SHA
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
DH-RSA-AES256-SHA
DH-DSS-AES256-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-DSS-CAMELLIA256-SHA
DH-RSA-CAMELLIA256-SHA
DH-DSS-CAMELLIA256-SHA
ECDH-RSA-AES256-SHA
ECDH-ECDSA-AES256-SHA
CAMELLIA256-SHA
PSK-AES256-CBC-SHA
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
DH-RSA-AES128-SHA
DH-DSS-AES128-SHA
DHE-RSA-CAMELLIA128-SHA
DHE-DSS-CAMELLIA128-SHA
DH-RSA-CAMELLIA128-SHA
DH-DSS-CAMELLIA128-SHA
ECDH-RSA-AES128-SHA
ECDH-ECDSA-AES128-SHA
CAMELLIA128-SHA
PSK-AES128-CBC-SHA
API SPEC

Custom Cipher Suites

Instead of selecting from the predefined cipher suites, you can create a cipher suite of your own to match the specific requirements of your environment. You build a custom cipher suite by adding individual ciphers associated with the TLS version(s) used in your configuration. A custom cipher suite must contain at least one cipher. Include only ciphers for the TLS version(s) that your environment effectively supports.

Note:

Ensure compatibility between specified SSL protocols and configured ciphers in the cipher suite, otherwise the SSL handshake will fail.
Ensure compatibility between configured ciphers in the cipher suite and configured certificates. For example: RSA-based ciphers require an RSA certificate, whereas ECDSA-based ciphers require ECDSA certificates.

Supported Ciphers

The Load Balancing service supports these ciphers.

TLS Version 1.2 Ciphers

Certificate	Cipher Suite	Key Exchange	Encryption	Bits	Cipher Suite Name (IANA)
ECDHE-ECDSA-AES128-GCM-SHA256	[0xc02b]	ECDH	AESGCM	128	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
ECDHE-RSA-AES128-GCM-SHA256	[0xc02f]	ECDH	AESGCM	128	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE-ECDSA-AES128-SHA256	[0xc023]	ECDH	AES	128	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
ECDHE-RSA-AES128-SHA256	[0xc027]	ECDH	AES	128	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
ECDHE-ECDSA-AES256-GCM-SHA384	[0xc02c]	ECDH	AESGCM	256	TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
ECDHE-RSA-AES256-GCM-SHA384	[0xc030]	ECDH	AESGCM	256	TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
ECDHE-ECDSA-AES256-SHA384	[0xc024]	ECDH	AES	256	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
ECDHE-RSA-AES256-SHA384	[0xc028]	ECDH	AES	256	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
AES128-GCM-SHA256	[0x9c]	RSA	AESGCM	128	TLS_RSA_WITH_AES_128_GCM_SHA256
AES128-SHA256	[0x3c]	RSA	AES	128	TLS_RSA_WITH_AES_128_CBC_SHA256
AES256-GCM-SHA384	[0x9d]	RSA	AESGCM	256	TLS_RSA_WITH_AES_256_GCM_SHA384
AES256-SHA256	[0x3d]	RSA	AES	256	TLS_RSA_WITH_AES_256_CBC_SHA256
DHE-RSA-AES256-GCM-SHA384	[0x9f]	DH	AESGCM	256	TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
DHE-RSA-AES256-SHA256	[0x6b]	DH	AES	256	TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
DHE-RSA-AES128-GCM-SHA256	[0x9e]	DH	AESGCM	128	TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
DHE-RSA-AES128-SHA256	[0x67]	DH	AES	128	TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
DH-DSS-AES256-GCM-SHA384	[0xa5]	DH/DSS	AESGCM	256	TLS_DH_DSS_WITH_AES_256_GCM_SHA384
DHE-DSS-AES256-GCM-SHA384	[0xa3]	DH	AESGCM	256	TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
DH-RSA-AES256-GCM-SHA384	[0xa1]	DH/RSA	AESGCM	256	TLS_DH_RSA_WITH_AES_256_GCM_SHA384
DHE-DSS-AES256-SHA256	[0x6a]	DH	AES	256	TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
DH-RSA-AES256-SHA256	[0x69]	DH/RSA	AES	256	TLS_DH_RSA_WITH_AES_256_CBC_SHA256
DH-DSS-AES256-SHA256	[0x68]	DH/DSS	AES	256	TLS_DH_DSS_WITH_AES_256_CBC_SHA256
ECDH-RSA-AES256-GCM-SHA384	[0xc032]	ECDH/RSA	AESGCM	256	TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
ECDH-ECDSA-AES256-GCM-SHA384	[0xc02e]	ECDH/ECDSA	AESGCM	256	TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
ECDH-RSA-AES256-SHA384	[0xc02a]	ECDH/RSA	AES	256	TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
ECDH-ECDSA-AES256-SHA384	[0xc026]	ECDH/ECDSA	AES	256	TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
DH-DSS-AES128-GCM-SHA256	[0xa4]	DH/DSS	AESGCM	128	TLS_DH_DSS_WITH_AES_128_GCM_SHA256
DHE-DSS-AES128-GCM-SHA256	[0xa2]	DH	AESGCM	128	TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
DH-RSA-AES128-GCM-SHA256	[0xa0]	DH/RSA	AESGCM	128	TLS_DH_RSA_WITH_AES_128_GCM_SHA256
DHE-DSS-AES128-SHA256	[0x40]	DH	AES	128	TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
DH-RSA-AES128-SHA256	[0x3f]	DH/RSA	AES	128	TLS_DH_RSA_WITH_AES_128_CBC_SHA256
DH-DSS-AES128-SHA256	[0x3e]	DH/DSS	AES	128	TLS_DH_DSS_WITH_AES_128_CBC_SHA256
ECDH-RSA-AES128-GCM-SHA256	[0xc031]	ECDH/RSA	AESGCM	128	TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
ECDH-ECDSA-AES128-GCM-SHA256	[0xc02d]	ECDH/ECDSA	AESGCM	128	TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
ECDH-RSA-AES128-SHA256	[0xc029]	ECDH/RSA	AES	128	TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
ECDH-ECDSA-AES128-SHA256	[0xc025]	ECDH/ECDSA	AES	128	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

TLS Version 1.0/1.1 Ciphers Supported in TLS Version 1.2

Certificate	Cipher Suite	Key Exchange	Encryption	Bits	Cipher Suite Name (IANA)
ECDHE-ECDSA-AES128-SHA	[0xc009]	ECDH	AES	128	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
ECDHE-RSA-AES128-SHA	[0xc013]	ECDH	AES	128	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
ECDHE-RSA-AES256-SHA	[0xc014]	ECDH	AES	256	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
ECDHE-ECDSA-AES256-SHA	[0xc00a]	ECDH	AES	256	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
AES128-SHA	[0x2f]	RSA	AES	128	TLS_RSA_WITH_AES_128_CBC_SHA
AES256-SHA	[0x35]	RSA	AES	256	TLS_RSA_WITH_AES_256_CBC_SHA
DHE-RSA-AES128-SHA	[0x33]	DH	AES	128	TLS_DHE_RSA_WITH_AES_128_CBC_SHA
DHE-RSA-CAMELLIA256-SHA	[0x88]	DH	Camellia	256	TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
DHE-RSA-CAMELLIA128-SHA	[0x45]	DH	Camellia	128	TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
DHE-DSS-CAMELLIA256-SHA	[0x87]	DH	Camellia	256	TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
DHE-DSS-CAMELLIA128-SHA	[0x44]	DH	Camellia	128	TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
DHE-RSA-SEED-SHA	[0x9a]	DH	SEED	128	TLS_DHE_RSA_WITH_SEED_CBC_SHA
DHE-DSS-SEED-SHA	[0x99]	DH	SEED	128	TLS_DHE_DSS_WITH_SEED_CBC_SHA
DH-RSA-SEED-SHA	[0x98]	DH/RSA	SEED	128	TLS_DH_RSA_WITH_SEED_CBC_SHA
DH-DSS-SEED-SHA	[0x97]	DH/DSS	SEED	128	TLS_DH_DSS_WITH_SEED_CBC_SHA
DHE-RSA-AES256-SHA	[0x39]	DH	AES	256	TLS_DHE_RSA_WITH_AES_256_CBC_SHA
DHE-DSS-AES256-SHA	[0x38]	DH	AES	256	TLS_DHE_DSS_WITH_AES_256_CBC_SHA
DH-RSA-AES256-SHA	n/a	n/a	n/a	n/a	n/a
DH-DSS-AES256-SHA	[0x36]	DH/DSS	AES	256	TLS_DH_DSS_WITH_AES_256_CBC_SHA
DH-RSA-CAMELLIA256-SHA	[0x86]	DH/RSA	Camellia	256	TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
DH-DSS-CAMELLIA256-SHA	[0x85]	DH/DSS	Camellia	256	TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
ECDH-RSA-AES256-SHA	[0xc00f]	ECDH/RSA	AES	256	TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
ECDH-ECDSA-AES256-SHA	[0xc005]	ECDH/ECDSA	AES	256	TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
CAMELLIA256-SHA	[0x84]	RSA	Camellia	256	TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
PSK-AES256-CBC-SHA	[0x8d]	PSK	AES	256	TLS_PSK_WITH_AES_256_CBC_SHA
DHE-DSS-AES128-SHA	[0x32]	DH	AES	128	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
DH-RSA-AES128-SHA	[0x31]	DH/RSA	AES	128	TLS_DH_RSA_WITH_AES_128_CBC_SHA
DH-DSS-AES128-SHA	[0x30]	DH/DSS	AES	128	TLS_DH_DSS_WITH_AES_128_CBC_SHA
DH-RSA-CAMELLIA128-SHA	[0x43]	DH/RSA	Camellia	128	TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
DH-DSS-CAMELLIA128-SHA	[0xbb]	DH/DSS	Camellia	128	TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256
ECDH-RSA-AES128-SHA	[0xc00e]	ECDH/RSA	AES	128	TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
ECDH-ECDSA-AES128-SHA	[0xc004]	ECDH/ECDSA	AES	128	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
SEED-SHA	[0x96]	RSA	SEED	128	TLS_RSA_WITH_SEED_CBC_SHA
CAMELLIA128-SHA	n/a	n/a	n/a	n/a	n/a
PSK-AES128-CBC-SHA	[0x8c]	PSK	AES	128	TLS_PSK_WITH_AES_128_CBC_SHA
DES-CBC3-SHA	[0x0701c0]	RSA	3DES	168	SSL_CK_DES_192_EDE3_CBC_WITH_SHA
IDEA-CBC-SHA	[0x07]	RSA	IDEA	128	TLS_RSA_WITH_IDEA_CBC_SHA
ECDHE-RSA-DES-CBC3-SHA	[0xc012]	ECDH	3DES	168	TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
ECDHE-ECDSA-DES-CBC3-SHA	[0xc008]	ECDH	3DES	168	TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
DHE-RSA-DES-CBC3-SHA	n/a	n/a	n/a	n/a	n/a
DHE-DSS-DES-CBC3-SHA	n/a	n/a	n/a	n/a	n/a
DH-RSA-DES-CBC3-SHA	[0x10]	DH/RSA	3DES	168	TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
DH-DSS-DES-CBC3-SHA	[0x0d]	DH/DSS	3DES	168	TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
ECDH-RSA-DES-CBC3-SHA	[0xc00d]	ECDH/RSA	3DES	168	TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
ECDH-ECDSA-DES-CBC3-SHA	[0xc003]	ECDH/ECDSA	3DES	168	TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
PSK-3DES-EDE-CBC-SHA	[0x8b]	PSK	3DES	168	TLS_PSK_WITH_3DES_EDE_CBC_SHA
KRB5-IDEA-CBC-SHA	[0x21]	KRB5	IDEA	128	TLS_KRB5_WITH_IDEA_CBC_SHA
KRB5-DES-CBC3-SHA	[0x1f]	KRB5	3DES	168	TLS_KRB5_WITH_3DES_EDE_CBC_SHA
KRB5-IDEA-CBC-MD5	[0x25]	KRB5	IDEA	128	TLS_KRB5_WITH_IDEA_CBC_MD5
KRB5-DES-CBC3-MD5	[0x23]	KRB5	3DES	168	TLS_KRB5_WITH_3DES_EDE_CBC_MD5
ECDHE-RSA-RC4-SHA	[0xc011]	ECDH	RC4	128	TLS_ECDHE_RSA_WITH_RC4_128_SHA
ECDHE-ECDSA-RC4-SHA	[0xc007]	ECDH	RC4	128	TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
ECDH-RSA-RC4-SHA	[0xc00c]	ECDH/RSA	RC4	128	TLS_ECDH_RSA_WITH_RC4_128_SHA
ECDH-ECDSA-RC4-SHA	[0xc002]	ECDH/ECDSA	RC4	128	TLS_ECDH_ECDSA_WITH_RC4_128_SHA
RC4-SHA	[0x05]	RSA	RC4	128	TLS_RSA_WITH_RC4_128_SHA
RC4-MD5	[0x04]	RSA	RC4	128	TLS_RSA_WITH_RC4_128_MD5
PSK-RC4-SHA	[0x8a]	PSK	RC4	128	TLS_PSK_WITH_RC4_128_SHA
KRB5-RC4-SHA	[0x20]	KRB5	RC4	128	TLS_KRB5_WITH_RC4_128_SHA
KRB5-RC4-MD5	[0x24]	KRB5	RC4	128	TLS_KRB5_WITH_RC4_128_MD5

Request Routing

The Load Balancing service allows you to route incoming requests to different backend servers based on certain properties of the request. The goal is to optimize the utilization of backend resources.

When multiple applications are hosted on the backend, several virtual host names can be associated with the load balancer listeners, so that incoming HTTP requests matching a particular host name are routed to the right backend servers.

When backend applications use multiple endpoints or content types, represented by a distinct URI or path, HTTP requests for each of those endpoints can be routed to different backend servers based on path route rules. These path route rules contain a string that is matched against the URI of an incoming request to determine the appropriate backend destination.

Virtual host names and path route rule sets are frequently combined in request routing. Note that virtual host names take precedence over URI matching.

Virtual Host Names

Virtual host names are assigned to any listener you create as part of your load balancer configuration. They work in conjunction with records you add to your DNS system. Host names associated with a listener correspond to the backend sets of that listener. In the backend, traffic is routed to the servers that host particular applications.

Virtual host names only work with HTTP(S) listeners; they are not supported with TCP listeners. If a listener has no associated virtual host name, that listener is the default for the assigned port. If all listeners on a port have virtual host names, the first virtual host name configured for that port serves as the default listener.

Advantages of using virtual host names include:

IP address consolidation. Multiple host names, backed by DNS entries in your name servers, can point to the same load balancer IP address.
Single load balancer. Instead of deploying a load balancer per application, you can use one load balancer for multiple applications.
Single load balancer shape. Running multiple applications behind a single load balancer helps you manage aggregate bandwidth demands and optimize utilization.
Simpler backend management. Managing a set of backend servers under a single resource simplifies network configuration and administration.

Virtual host names can be defined as exact names, such as "app.example.com", or as wildcard names. Wildcard names include an asterisk (*) at the beginning or end of the host name. Only the asterisk wildcard is supported; regular expressions are not supported. When searching for a virtual host name, the service chooses the first matching variant in the following order of priority:

Exact name match without wildcard. For example: app.example.com.
Longest wildcard name that begins with an asterisk. For example: *.example.com.

Note:

Prefix wildcard names might require a wildcard certificate for HTTPS sites.
Longest wildcard name that ends with an asterisk. For example: app.example.*.

Note:

Suffix wildcard names might require a multi-domain Subject Alternative Name (SAN) certificate for HTTPS sites.

To apply virtual host names to a listener, you first create one or more virtual host names associated with the load balancer. Virtual host name selection priority is not related to the listener configuration order. There is a maximum of 16 virtual host names associated with a load balancer and applied to a single listener.

Path Route Sets

A path route is a string that the load balancer matches against an incoming URI to determine the appropriate destination backend set. Some applications have multiple endpoints or content types, each identified by a unique URI path. For example: /admin/, /data/, /video/, or /cgi/. Path route rules allow traffic to be routed to the correct backend set without requiring multiple listeners or load balancers.

A path route set includes all path route rules that define the request routing for a particular listener. Only one path route set can be specified for each listener; a path route set contains a maximum of 20 path route rules.

A path route rule consists of a path route string and a pattern match type. Strings must not contain asterisks or regular expressions; string matching is case-insensitive. The pattern match types are:

EXACT_MATCH

Looks for a path string that exactly matches the incoming URI path.

Applies case-insensitive regex: ^<path_string>$

FORCE_LONGEST_PREFIX_MATCH

Looks for the path string with the best, longest match of the beginning portion of the incoming URI path.

Applies case-insensitive regex: <path_string>.*

PREFIX_MATCH

Looks for a path string that matches the beginning portion of the incoming URI path.

Applies case-insensitive regex: ^<path_string>.*

SUFFIX_MATCH

Looks for a path string that matches the ending portion of the incoming URI path.

Applies case-insensitive regex: .*<path_string>$

Rule Priority

Within a path route set, the match type determines the priority of path route rules. For sets containing multiple path route rules with different match types, the following order of priority is applied:

EXACT_MATCH
FORCE_LONGEST_PREFIX_MATCH
PREFIX_MATCH or SUFFIX_MATCH

The order of rules within a path route set is irrelevant for EXACT_MATCH and FORCE_LONGEST_PREFIX_MATCH. However, if matching cascades down to PREFIX_MATCH or SUFFIX_MATCH, the system selects the first prefix or suffix rule that matches the incoming URI path.

To apply path route rules to a listener, you first create a path route set that contains the rules. The path route set is part of the load balancer configuration. When you create or update a listener for the load balancer, you specify the path route set to use.