General information about load balancers

Last update: October 05 2026Open in Markdown

A cloud load balancer distributes incoming network traffic across cloud servers within a single pool. You can use a load balancer to increase service availability: it optimally distributes requests across servers and reduces the load. If one server fails, the load balancer redirects traffic to another suitable server.

The load balancer operates at L3-L4 (network load balancer) and L7 (application load balancer) layers. To balance HTTPS traffic, TLS (SSL) certificates from Secrets Manager are used; for details, see the Load Balancer TLS (SSL) Certificates guide.

You can work with a load balancer in the Control Panel, via the OpenStack CLI, or with Terraform.

Cloud load balancers support user types and roles.

Cloud load balancer operation records are saved in audit logs.

If you need a load balancer for a Managed Kubernetes cluster, use only kubectl to create and configure it. For details, see the Configure a load balancer guide in the Managed Kubernetes section.

To track load balancer metrics, you can configure monitoring using Prometheus; for more information on available metrics and monitoring setup, see the Cloud Load Balancer Monitoring guide. You can also collect load balancer logs.

Load balancer types

	Basic non-redundant	Basic redundant	Advanced redundant
Number of instances	One	Two	Two
Instance configuration	2 vCPU, 1 GB RAM	2 vCPU, 1 GB RAM	4 vCPU, 2 GB RAM
Fault tolerance and redundancy	Single mode only	Active-Standby failover to a standby instance in a single pool *	Active-Standby failover to a standby instance in a single pool *
Use case	For test environments or projects that do not require 24/7 service availability	For small and medium-sized projects where service availability is critical	For high-load projects requiring constant service availability
Throughput	Up to 3 Gbps. Can be increased to 5 Gbps — submit a ticket	Up to 3 Gbps. Can be increased to 5 Gbps — submit a ticket	Up to 3 Gbps. Can be increased to 5 Gbps — submit a ticket
Number of HTTP requests per second (RPS)	~19 500	~19 500	~34 000
Number of HTTPS requests terminated at the balancer per second (RPS)	~3 000 keep-alive connections (with 10 000 concurrent TCP connections)	~3 000 keep-alive connections (with 10 000 concurrent TCP connections)	~9 000 keep-alive connections (with 10 000 concurrent TCP connections)

* If a redundant load balancer is located in a multi-AZ pool, its instances are located in different availability zones. If one availability zone fails, the instance in the other zone will continue distributing the load across servers.

If these types do not suit your needs, you can order a custom load balancer type — submit a ticket.

List of load balancer flavors

Flavors correspond to load balancer types and determine the number of vCPUs, RAM, and the number of load balancer instances.

To create load balancers via OpenStack CLI and Terraform, flavor IDs or names are used. IDs differ across pools.

note

For example, ac18763b-1fc5-457d-9fa7-b0d339ffb336 is the ID, and AMPH1.ACT_STNDB.4-2048 is the flavor name corresponding to the Advanced with redundancy type in the ru-9 pool.

You can view the list of load balancer flavors in all pools in the table or view the list of load balancer flavors in a specific pool via the OpenStack CLI.

List of load balancer flavors in all pools

St. Petersburg

ru-3

ID	Name
d4490352-a58a-44b7-b226-717cd7607c0e	AMPH1.SNGL.2-1024
dbf2523f-39a5-4f34-be74-07eb3f111171	AMPH1.ACT_STNDB.2-1024
ea49b7dd-c126-4b22-8a2c-2eb65cbda662	AMPH1.ACT_STNDB.4-2048

ru-1

ID	Name
10a221ac-f483-41c7-b9a8-79893317f5c6	AMPH1.SNGL.2-1024
06731413-f866-4497-a804-2feba12455be	AMPH1.ACT_STNDB.2-1024
f6538882-a867-4156-9cfd-d2e629b005c4	AMPH1.ACT_STNDB.4-2048

ru-9

ID	Name
3265f75f-01eb-456d-9088-44b813d29a60	AMPH1.SNGL.2-1024
d3b8898c-af94-47f8-9996-65b9c6aa95e2	AMPH1.ACT_STNDB.2-1024
ac18763b-1fc5-457d-9fa7-b0d339ffb336	AMPH1.ACT_STNDB.4-2048

gis-2

ID	Name
aa7a9b6a-0e4b-49d6-be0a-91ca7fe4b034	AMPH1.ACT_STNDB.4-2048
acc0dd16-7a1f-4f44-8b24-595dc9c5c074	AMPH1.ACT_STNDB.2-1024
eb343d9a-7744-4afa-941d-3a2e5f3103c4	AMPH1.SNGL.2-1024

Moscow

ru-2

ID	Name
e1613cc2-62b9-4cc8-b0fb-a30cf0cca3f3	AMPH1.SNGL.2-1024
ac29a80a-c694-4861-a061-3a78cae0ccf9	AMPH1.ACT_STNDB.2-1024
1d25f453-41e8-48bb-9fc6-ffa235f03444	AMPH1.ACT_STNDB.4-2048

ru-6

ID	Name
189a1bc0-d49a-4dd2-8b1f-6d1f4273fc78	AMPH1.SNGL.2-1024
a11c76d9-7a2e-4054-91d8-deaa09a4eb56	AMPH1.ACT_STNDB.2-1024
38ea8aa2-84db-4a41-981b-d7f4e10d50ef	AMPH1.ACT_STNDB.4-2048

ru-7

ID	Name
78dbe17b-0358-47db-a933-7f06e58307e4	AMPH1.SNGL.2-1024
b93feeb9-6522-4dfa-9e08-38d03ac2448f	AMPH1.ACT_STNDB.2-1024
226d5473-2aa6-42da-b74e-529c6da7a12f	AMPH1.ACT_STNDB.4-2048

gis-1

ID	Name
07ef9ddf-aac9-4d9a-9c9d-42a6997568a7	AMPH1.SNGL.2-1024
fe77536d-9266-49fd-a207-ef50ab716c64	AMPH1.ACT_STNDB.2-1024
01342570-05e9-46fa-9456-666c360ff166	AMPH1.ACT_STNDB.4-2048

Novosibirsk

ru-8

ID	Name
15be309a-62c8-4b1c-8896-345d5eb21b00	AMPH1.SNGL.2-1024
c979a0d1-5558-4820-aed1-9990b66648f9	AMPH1.ACT_STNDB.2-1024
eed81b82-707b-488c-8142-47a9c1fb71e8	AMPH1.ACT_STNDB.4-2048

Tashkent

uz-1

ID	Name
7d56905c-92ce-49e8-986e-f656f7b44cda	AMPH1.SNGL.2-1024
ca85e2b6-456e-4118-a2db-0f4aa4f51528	AMPH1.ACT_STNDB.2-1024
5f8741d4-d6c6-438d-bf11-2ab0fbd926c5	AMPH1.ACT_STNDB.4-2048

uz-2

ID	Name
74cb3ac7-5984-4612-b0f6-e43ee95bb495	AMPH1.SNGL.2-1024
c20efedb-3ae0-4bd7-a80d-6d36f5120efd	AMPH1.ACT_STNDB.2-1024
64dcea94-32e7-4248-aa43-7ac56952c5ba	AMPH1.ACT_STNDB.4-2048

Almaty

kz-1

ID	Name
a082beed-caca-4722-b4cf-c261781224cf	AMPH1.SNGL.2-1024
abe8a65d-371b-4157-8402-aa39611ebf9a	AMPH1.ACT_STNDB.2-1024
ad73fce9-8d22-40bc-8708-d5ddd7bf4067	AMPH1.ACT_STNDB.4-2048

Nairobi

ke-1

ID	Name
c48873e3-06ef-4aa8-9537-b3050578cfdb	AMPH1.SNGL.2-1024
458d379b-d6c3-4667-baf5-53fe05b33156	AMPH1.ACT_STNDB.2-1024
d95b0f5e-f727-45a0-9dd0-bbd014f64fbe	AMPH1.ACT_STNDB.4-2048

Where:

• ID — load balancer flavor ID;
• Name — flavor name that corresponds to the load balancer type:
  • AMPH1.SNGL.2-1024 — Basic without redundancy type;
  • AMPH1.ACT_STNDB.2-1024 — Basic with redundancy type;
  • AMPH1.ACT_STNDB.4-2048 — Advanced with redundancy type.

View a list of load balancer flavors in a specific pool

1. Open the OpenStack CLI.

2. View the list of flavors:

   openstack loadbalancer flavor list -c id -c name

   Example response for the ru-9 pool:

   +--------------------------------------+------------------------+
   | id                                   | name                   |
   +--------------------------------------+------------------------+
   | 3265f75f-01eb-456d-9088-44b813d29a60 | AMPH1.SNGL.2-1024      |
   | d3b8898c-af94-47f8-9996-65b9c6aa95e2 | AMPH1.ACT_STNDB.2-1024 |
   | ac18763b-1fc5-457d-9fa7-b0d339ffb336 | AMPH1.ACT_STNDB.4-2048 |
   +--------------------------------------+------------------------+

   Where:

   • id — load balancer flavor ID;
   • name — flavor name that corresponds to the load balancer type:
     • AMPH1.SNGL.2-1024 — Basic without redundancy type;
     • AMPH1.ACT_STNDB.2-1024 — Basic with redundancy type;
     • AMPH1.ACT_STNDB.4-2048 — Advanced with redundancy type.

How a load balancer works

The load balancer uses the OpenStack Octavia model, which includes:

• instance (amphora) — performs load balancing. It runs on a cloud server and uses HAProxy (High-Availability Proxy), a software for proxying traffic. In redundant load balancers (types Basic with redundancy and Advanced with redundancy), two instances are created; in non-redundant load balancers, one instance is created;
• target group (pool) — a group of servers to which a rule redirects requests via the protocol specified for the group;
• servers (members) — servers that handle traffic in the pool. They are available via the IP address and port specified for the server within the target group;
• health checks (health monitor) — the process of checking the health of all servers in the target group;
• rule (listener) — listens for incoming traffic to the load balancer using the protocols and ports specified in the rule. Then routes traffic to the required group of servers;
• HTTP policy (L7 Policy) — additional conditions in the rule for routing HTTP traffic with specific parameters.

Target groups

A target group is a group of servers to which traffic from the load balancer is distributed. A server can be part of several target groups of the same balancer if different ports are specified for the server in these groups.

For a target group, you can configure:

• protocols and ports for receiving traffic from the load balancer;
• algorithms used to distribute requests;
• health checks to monitor server status.

Availability checks

You can enable availability checks for a target group. The balancer will monitor the state of the servers—if any server is down, the balancer will redirect connectivity to another.

Inspection parameters:

• inspection type. Depending on the target group protocol, the following types are available:

  • TCP group — TCP, PING;
  • PROXY group — TLS-HELLO, HTTP, TCP, PING;
  • UDP group — UDP-CONNECT, PING;
  • HTTP group — HTTP, TCP, PING;

• for the HTTP inspection protocol, you can configure URL invocation and expected response codes;

• inspection interval — the interval in seconds at which the balancer sends inspection requests to servers;

• connection timeout — the response waiting time;

• success threshold — the number of consecutive successful attempts after which the server is set to operational status;

• failure threshold — the number of consecutive unsuccessful attempts after which server operations are suspended.

Rules

A rule is a set of load balancer settings that handle a traffic stream with a specific port and protocol and distribute this traffic to the required group of servers.

In a rule, you can configure:

• protocols and ports of incoming traffic for the load balancer;
• HTTP policies for additional HTTP traffic routing;
• connections passing through the load balancer;
• select a target group of servers.

There is no limit to the number of rules in a balancer.

HTTP policies

An HTTP policy is an addition to a rule that allows you to route specific HTTP and HTTPS traffic separately from other traffic:

• forward to another target group (REDIRECT_TO_POOL);
• redirect to a URL — completely replace the request URL, including the protocol, domain name, path, and request parameters (REDIRECT_TO_URL);
• redirect to a URL prefix — replace the protocol and domain name in the request URL (REDIRECT_PREFIX);
• reject (REJECT).

A request is redirected according to the first matching policy. The order in which policies are applied depends on the policy action: REJECT policies are applied first, followed by REDIRECT_TO_URL and REDIRECT_PREFIX, and then REDIRECT_TO_POOL. If a rule has multiple policies with the same action, they are applied according to the policy's position in the rule. You can change the policy application order.

An HTTP policy consists of a set of conditions; there is no limit to the number of conditions in a policy. For a request to match a policy, it must meet all policy conditions. A condition specifies:

• request parameter to check: HOST_NAME or PATH. When configuring a policy via the OpenStack CLI, you can also create a condition based on the parameters COOKIE, FILE_TYPE, and HEADER;
• comparison value for inspection — an exact value or a regular expression;
• match type with the control value: EQUAL TO, STARTS WITH, ENDS WITH, CONTAINS, REGEX.

There is no limit to the number of HTTP policies in a rule.

Load balancer ports

The load balancer occupies several ports in the subnet; the exact number depends on the load balancer type: three ports for a load balancer without redundancy, five ports for redundant load balancers (Basic with redundancy and Advanced with redundancy types).

The subnet must always have available IP addresses for recreating the load balancer: in case of failures, it automatically creates a new instance and only then deletes the old one. To recreate a load balancer without redundancy, one available address is needed; for a redundant load balancer, two. If no free IP address is available, the load balancer will enter the ERROR status.

If you plan to place the load balancer and servers in the same subnet, choose a subnet size of /28 or larger. We recommend choosing a /24 private subnet with a public IP address (the address is needed for Internet access); in this case, available IP addresses will always be present for recreating an instance. Traffic balancing will be performed inside the private network.

The following ports are created for each balancer:

• uplink port—a virtual port where the VIP (virtual IP address) is placed. A rule listens for incoming traffic on this port. It is allocated when a load balancer is created and is located in its subnet. For redundant balancers, the VIP is reserved via the VRRP protocol;
• service VRRP ports—when a basic load balancer is created, one service port is allocated in its subnet. When a redundant balancer is created, two service ports are allocated for the primary and standby instances, and VRRP is configured between them;
• downlink service ports. If servers are not located in the balancer subnet, ports are allocated for instances in the subnets with the servers when the balancer is created: one port for a basic balancer, and two ports (primary and standby) for redundant balancers.

Protocols

The following protocol combinations are available:

• TCP–TCP — classic L4-balancing;
• TCP–PROXY — client information is not lost and is transmitted in a separate connection header;
• UDP–UDP — the UDP protocol is faster than TCP but less reliable;
• HTTP–HTTP — L7-balancing;
• HTTPS–HTTP — L7-balancing with encryption and SSL certificate termination at the balancer.

Request distribution algorithms

A rule distributes requests according to the selected algorithm. Two algorithms are available:

• Round Robin — a circular service algorithm. The first request is transmitted to one server, the next request to another, and so on until the last server is reached. Then the loop starts over. Requests are distributed to servers in accordance with the specified weight.
• Least connections — the algorithm accounts for the number of connections to servers. A new request is transmitted to the server with the fewest active connections; the server weight is not considered.

Sticky Sessions

Additionally, you can enable Sticky Sessions. This method is necessary when the end application maintains a long connection with each client and saves internal data state, which is not synchronized between servers in a rule.

New requests will be distributed according to the selected algorithm, and then the session will be pinned to the server that started processing the requests. All subsequent requests of this session will be distributed to that server, ignoring the selected algorithm. If the server is unavailable, the request will be redirected to another.

Session definition parameters can be configured—you can balance sessions or balance a single client to a single server. You can identify a session:

• by APP-cookie — an already existing cookie specified in the application code;
• by HTTP-cookie — a cookie created and attached to the session by the balancer;
• by Source IP — the client IP address is hashed and divided by the weight of each server in the target group—this determines the server that will process the requests.

Connection settings

You can specify the settings for connections passing through the balancer—between incoming requests and the balancer, and between the balancer and servers.

Connection settings:

• connection timeout — the response waiting time;
• maximum connections — the maximum number of active connections;
• inactivity timeout — the time during which a connection is considered active, even if no data is transmitted;
• TCP packets waiting timeout — the time during which the balancer waits for data transmission for inspection over an already established connection.

HTTP request headers

In normal operation mode, the balancer transmits only the original HTTP request body to the server, replacing the client IP address with its own.

Include the necessary types of additional headers in the request so that servers receive this information for correct operation or analysis:

• X-Forwarded-For — IP address from which the request originated;
• X-Forwarded-Port — load balancer port that received the request;
• X-Forwarded-Proto — original connection protocol;
• X-SSL-Client-Verify — whether the client used a secure connection;
• X-SSL-Client-Has-Cert — presence of a client certificate;
• X-SSL-Client-DN — owner identification information;
• X-SSL-Client-CN — host name for which the certificate was issued;
• X-SSL-Issuer — certificate authority that issued the certificate;
• X-SSL-Client-SHA1 — SHA1 fingerprint of the client certificate;
• X-SSL-Client-Not-Before — certificate start validity date;
• X-SSL-Client-Not-After — certificate expiration date.

Cost

Load balancers are billed according to the Cloud Platform payment model.

Load balancer pricing is available on selectel.ru.