Load balancers

A load balancer is used to receive incoming traffic and transmit it to the backend endpoints. Requests are routed based on the settings of load balancer listeners. Settings for transmitting traffic to backends are configured in backend groups.

The load balancer stores a list of endpoints, which accept traffic, and disables TLS encryption before sending the traffic to backends. Load balancer supports modern TLS versions (TLSv1.2, TLSv1.3) and encryption methods. If the load balancer is going to serve multiple domains, you can configure individual certificates and HTTP routers for each domain by using the TLS SNI mechanism.

For convenience and security, you can use the load balancer in combination with Yandex Certificate Manager to store your TLS certificates. You can also use Yandex Monitoring services to monitor request processing.

Security groupsSecurity groups

When creating a load balancer, you need to specify security groups as they contain rules the load balancer uses to receive incoming traffic and send it to backend VMs. Each VM also has security groups assigned to it.

For the load balancer to work correctly:

• The load balancer security groups must allow:

  • Receiving external incoming traffic on the ports specified in the listener, e.g., for HTTP(S) traffic: TCP connections on ports 80 and 443 from any address (CIDR: 0.0.0.0/0).
  • Receiving incoming traffic to health check load balancer nodes in different availability zones: TCP connections on port 30080 with the Load balancer healthchecks source.
  • Sending traffic to backend VMs, i.e., VMs whose IP addresses are included in target groups. For example, any outgoing connections to internal VM addresses (any protocol, full port range, CIDR: <VM_internal_IP_address>/32).

  Note

  Security group rules must specify IP ranges in CIDR format. You cannot assign a group that uses a different security group.

• Backend VM security groups must allow incoming traffic from the load balancer on the ports specified in the backend groups, e.g., any incoming connections from subnets hosting the load balancer or from at least one of its security groups.

For information on how to configure security groups for the Ingress controller and Gateway API, see Configuring security groups for Managed Service for Kubernetes Application Load Balancer tools.

Load balancer location and its internal IP addressesLoad balancer location and its internal IP addresses

When creating a load balancer, specify a network and subnets in the availability zones. Those are the subnets where the load balancer's nodes will be hosted. Application backends will receive traffic from the load balancer nodes in these subnets.

See below to learn what subnet sizes are recommended for load balancers.

You can disable the load balancer in the selected availability zones. In this case, external traffic will no longer be sent to the load balancer nodes in these availability zones. However, the load balancer nodes in other availability zones will continue supplying traffic to backends in the availability zones the load balancer was disabled in, if allowed by the locality-aware routing settings.

Internal IP addressesInternal IP addresses

The load balancer reserves internal IP addresses in the specified networks and assigns addresses to its nodes. These addresses are used for communication between the load balancer nodes and backends. Node IP addresses are shown in the list of internal IP addresses.

To correctly distribute the load across backends, add a permission for incoming traffic from subnets where the load balancer nodes are located:

1. Get the CIDR of each network the load balancer nodes are using.
2. To enable nodes to freely communicate with backends, add these CIDRs to the list of allowed sources.

For example, the load balancer uses subnets with CIDRs 10.0.1.0/24 and 10.0.2.0/24, and backends receive traffic on port 8080. In which case you will need two rules to allow traffic from the load balancer nodes:

Traffic direction	Port range	Protocol	Source	CIDR blocks
Inbound	8080	TCP	CIDR	10.0.1.0/24
Inbound	8080	TCP	CIDR	10.0.2.0/24

Autoscaling and resource unitsAutoscaling and resource units

An internal group of VM instances called resource units is created in each availability zone of the load balancer.

One resource unit supports these peak performance thresholds:

• 1000 requests per second (RPS).
• 4000 concurrently active connections.
• 300 new connections per second.
• 22 MB (176 Mbit) of traffic per second.

The system automatically scales the resource unit group based on the load balancer node’s external workload. The system calculates the group size to ensure resource unit utilization remains below specified thresholds.

As an example, let's take a look at the following load:

• 6000 RPS.
• 29000 concurrently active connections.
• 750 new connections per second.
• 20 MB of traffic per second.

This is equal to eight resource units:

• 6000 / 1000 = 6 resource units per 6000 RPS.
• 29000 / 4000 = 7.25 ≈ 8 resource units per 30000 active connections.
• 750 / 300 = 2.5 ≈ 3 resource units per 750 new connections.
• 20 / 22 = 0.9090... ≈ 1 resource unit per 20 MB/sec of traffic.

By default, the minimum number of resource units per availability zone is 2. You can increase it in the autoscaling settings. For more information, see below.

The number of resource units affects the cost of using the load balancer. For more information, see Yandex Application Load Balancer pricing policy.

Autoscaling settingsAutoscaling settings

In the load balancer settings, you can specify the following:

The minimum number of resource units per availability zone

If you expect higher loads on the load balancer, you can increase the minimum number of resource units per zone in advance to avoid waiting for it to increase following the load.

The default minimum is 2. You cannot set a minimum value below 2.

Maximum total number of resource units

The cost of using the load balancer depends on the number of its resource units (see the relevant pricing policy). By default, this number is unlimited. You can set a limit to control your expenses.

If the specified minimum is too low for the actual load on the load balancer, it may run incorrectly.

Make sure the value is more or equal to the number of load balancer availability zones multiplied by the minimum number of resource units per zone.

You can set autoscaling for a group of resource units of your load balancer when creating or updating it.

Recommended subnet sizesRecommended subnet sizes

For Application Load Balancer to provide load balancer availability as specified in the service level agreement, load balancer subnets must have a sufficient number of internal IP addresses available. We recommend sizing the subnets to have at least two free IPs per each resource unit at peak load.

For example, if a load balancer uses eight resource units in each availability zone, as shown in this example, each subnet should have at least 8 × 2 = 16 free addresses. For the load balancer, we recommend specifying subnets at least /27 in size.

ListenerListener

The listener determines the ports, addresses, and protocols the load balancer will accept traffic on.

Some incoming ports, such as port 22, are reserved for service purposes and you cannot use them.

Request routing to backend groups depends on the listener type:

• HTTP: Load balancer accepts HTTP or HTTPS requests and distributes them across backend groups based on the rules set in HTTP routers, or redirects HTTP requests to HTTPS. Backend groups receiving traffic must have the HTTP or gRPC type.
• Stream: Load balancer accepts incoming traffic via unencrypted or encrypted TCP connections and routes it to Stream backend groups.

If encrypted traffic is accepted, the main listener and optional SNI listeners are set up for the load balancer. In each SNI listener, the domain name specified as Server Name Indication (SNI) when establishing a TLS connection is mapped to a TLS certificate and HTTP router (if the listener type is HTTP) or a backend group (if the listener type is Stream). The main listener is responsible for TLS connections with domain names that do not match any SNI listener.

One load balancer can serve both regular and encrypted traffic on different ports and have public and internal IP addresses on different listeners.

ExampleExample

The listener can accept HTTP traffic on port 80 and redirect traffic to HTTPS port 443. The listener gets an HTTP request from a client and returns a response with HTTP code 302. Further requests will be accepted at port 443 via HTTPS.

If an HTTPS listener is used, specify a certificate from Certificate Manager that will be used to terminate TLS connections.

StatisticsStatistics

Load balancer statistics are automatically logged in the Yandex Monitoring metrics. The following dashboards and measures are available:

• HTTP statistics:

  • RPS: Number of load balancer requests per second.
  • 4XX, 5XX: Number of load balancer responses containing HTTP codes 4XX and 5XX and the corresponding gRPC codes per second.
  • Request size: Total volume of load balancer requests per second.
  • Response size: Total volume of load balancer responses per second.
  • Latency: Response delay (the time between the balancer receiving the first byte of a request to sending the last byte of the response), 50th to 99th percentiles.

• Capacity statistics:

  • Active connections: Number of active connections.
  • Connections per second: Number of connections per second.
  • Requests per second: Number of requests per second.
  • Bytes per second: Amount of data handled per second.

For a full list of metrics delivered to Yandex Monitoring, see the reference.

Application Load Balancer has aggregate load balancer statistics available. In Monitoring, you can view statistics itemized by the resources associated with the load balancer (HTTP routers, virtual hosts, routes, and the like) as well as create alerts.

For instructions on viewing statistics, see Viewing L7 load balancer statistics.

LoggingLogging

You can configure the delivery of load balancer logs to a Yandex Cloud Logging log group.

For more information on how to view logs, see Viewing L7 load balancer logs.

A full list of logged parameters is provided in the log reference.

You can also send load balancer logs to a PostgreSQL DB.

Rules for discarding logsRules for discarding logs

Writing and storing logs in Cloud Logging is charged based on the service pricing rules. To log less data, add rules for discarding logs.

Possible rules:

Rule	Value
HTTP codes	100: Continue 101: Switching Protocol 102: Processing 200: OK 201: Created 202: Accepted 203: Non Authoritative Information 204: No Content 205: Reset Content 206: Partial Content 207: Multi-Status 300: Multiple Choices 301: Moved Permanently 302: Found 303: See Other 304: Not Modified 305: Use Proxy 307: Temporary Redirect 308: Permanent Redirect 400: Bad Request 401: Unauthorized 402: Payment Required 403: Forbidden 404: Not Found 405: Method Not Allowed 406: Not Acceptable 407: Proxy Authentication Required 408: Request Timeout 409: Conflict 410: Gone 411: Length Required 412: Precondition Failed 413: Request Entity Too Large 414: Request-URI Too Long 415: Unsupported Media Type 416: Requested Range Not Satisfiable 417: Expectation Failed 418: I'm a teapot 419: Insufficient Space on Resource 420: Method Failure 422: Unprocessable Entity 423: Locked 424: Failed Dependency 428: Precondition Required 429: Too Many Requests 431: Request Header Fields Too Large 451: Unavailable For Legal Reasons 500: Internal Server Error 501: Not Implemented 502: Bad Gateway 503: Service Unavailable 504: Gateway Timeout 505: HTTP Version Not Supported 507: Insufficient Storage 511: Network Authentication Required
HTTP code classes	1XX 2XX 3XX 4XX 5XX ALL
gRPC codes	GRPC_OK GRPC_CANCELLED GRPC_UNKNOWN GRPC_INVALID_ARGUMENT GRPC_DEADLINE_EXCEEDED GRPC_NOT_FOUND GRPC_ALREADY_EXISTS GRPC_PERMISSION_DENIED GRPC_UNAUTHENTICATED GRPC_RESOURCE_EXHAUSTED GRPC_FAILED_PRECONDITION GRPC_ABORTED GRPC_OUT_OF_RANGE GRPC_UNIMPLEMENTED GRPC_INTERNAL GRPC_UNAVAILABLE

Use casesUse cases

• Setting up virtual hosting
• Creating a load balancer with DDoS protection
• Creating an L7 load balancer in Application Load Balancer with a Yandex Smart Web Security profile
• Migrating services from an NLB load balancer to an L7 ALB load balancer for DDoS protection using Yandex Smart Web Security
• Configuring an Yandex Application Load Balancer L7 load balancer using an Ingress controller
• Fault-tolerant website with load balancing via Yandex Application Load Balancer using the management console
• Health checking your apps in a Yandex Managed Service for Kubernetes cluster using a Yandex Application Load Balancer L7 load balancer
• Writing load balancer logs to PostgreSQL
• Configuring logging for an Yandex Application Load Balancer L7 load balancer using an Ingress controller