Load balancer
Overview
A load balancer is a managed network resource that distributes incoming traffic across multiple servers (VMs). It spreads requests arriving at a public IP across servers according to rules, preventing any single server from being overloaded and keeping the service available even when some servers fail.
The load balancer operates at L4 (transport layer) and handles TCP and UDP traffic. It is a managed resource operated by Elice, so it does not appear in the VM list and can be created and managed only from the portal.
Client
└── Public IP (attached to the load balancer)
└── Load balancer (rules + health checks)
├── Server #1 (network interface)
└── Server #2 (network interface)
Prerequisites
Before creating a load balancer, have the following ready.
- Virtual network: the virtual network the load balancer and target servers belong to
- Target servers: the VMs that receive traffic and their network interfaces. Only network interfaces in the same virtual network as the load balancer can be registered as servers.
- Public IP: a public IP to attach to the load balancer. If you have not prepared one, you can create it inline from the creation form via Create public IP.
- Quota: load balancers are subject to a per-organization count quota. The remaining count is shown on the creation form and the Usage & Quota page.
Creating a load balancer
-
In Network > Load Balancer, click Create load balancer.
-
Fill in the basic info.
Field Description Name A recognizable name Zone Availability zone for the load balancer (pick the same zone as the target servers) Virtual network The virtual network the load balancer and target servers belong to Public IP The public IP to attach. IPs already attached to another resource cannot be selected Pricing type Pricing plan (on-demand or reserved). The load balancer is billed hourly from activation until deletion -
Add one or more load balancing rules. A rule defines the listener (which traffic to accept), the servers (where to send it), and the distribution method.
Field Description Protocol Transport protocol for client traffic (TCP / UDP) Port Listener port clients connect to. Traffic arriving at this port of the public IP is forwarded to the servers (1–65535). The same port cannot be used across rules, even with different protocols Distribution algorithm How requests are spread across servers (see the table below) -
Add one or more servers to each rule and select a network interface for every server.
Field Description Network interface The network interface of the target server (VM). Only interfaces in this load balancer's virtual network are selectable Server port The port the target server receives traffic on (1–65535) -
Configure the health check (see the table below).
-
Click Create.
A load balancer starts in the Requested state right after creation and switches to Activated once provisioning finishes. Send traffic only after the status becomes Activated.
Distribution algorithms
Choose how each rule spreads traffic across its servers.
| Algorithm | Behavior | Best for |
|---|---|---|
| Round Robin | Assigns servers in rotation | Servers with similar capacity and uniform request times (default) |
| Least Connection | Prefers the server with the fewest active connections | Varying request durations or long-lived connections |
| Random | Picks a server at random | Simple approximate balancing |
Health check
The health check probes each server periodically, removes unhealthy servers from distribution, and re-adds them once they recover. It is configured per rule.
| Field | Description | Default |
|---|---|---|
| Protocol | Protocol used to probe servers. Fixed to TCP | TCP |
| Port | Port to probe. Can differ from the service port (1–65535) | 80 |
| Interval (s) | How often servers are probed | 10 |
| Timeout (s) | Max time to wait for a response per probe. Exceeding it counts as a failure | 5 |
| Healthy threshold | Consecutive successes required to return an unhealthy server to rotation | 2 |
| Unhealthy threshold | Consecutive failures required to remove a healthy server from rotation | 3 |
Even when the listener protocol is UDP, the health check always verifies TCP connectivity on the health check port. That is why the health check protocol is fixed to TCP.
The health check port defaults to 80. If you set the server port to 8080 or similar, change the health check port to match. Otherwise the probe hits the unresponsive port 80, every server is marked unhealthy, and no traffic is forwarded.
Editing a load balancer
Only load balancers in the Activated state can be edited. The editable fields are the name and the rules (including servers, distribution algorithm, and health check); the zone, virtual network, public IP, and pricing type cannot be changed after creation.
- In Network > Load Balancer, select the target load balancer.
- Click Edit and change the name, rules, servers, distribution algorithm, or health check.
- Click Save. Changes apply without recreating the load balancer.
To add or remove servers during operation, edit the rule's server list. A removed server stops receiving traffic, and a newly added server joins distribution as soon as it passes the health check.
Deleting a target VM leaves its server entry in the rule. The dead server is excluded from distribution by the health check, but you should also remove it from the rule's server list. Network interfaces registered in rules cannot be deleted, so they are excluded when deleting the VM together with its resources.
The public IP attached to a load balancer cannot be detached or replaced. To use a different public IP, delete the load balancer and create a new one.
Deleting a load balancer
Only load balancers in the Activated state can be deleted. In Network > Load Balancer, select the target and click Delete.
Deletion is asynchronous, like creation. After you request deletion the status becomes Deleting, and the load balancer is removed from the list when it completes. The attached public IP is detached when deletion completes, after which it can be attached to another resource or deleted.
Billing
A load balancer is billed hourly from the moment it becomes Activated until it is deleted. It is not billed while provisioning (the Requested state), and there are no extra charges based on traffic volume or request count.
- The pricing type (on-demand or reserved) is chosen at creation and cannot be changed afterwards.
- The attached public IP is billed separately from the load balancer.
- Billing continues while the load balancer is activated even with no traffic, so delete load balancers you are not using.
Next steps
- Public IP: allocate a public IP to attach to the load balancer
- Network interface: check the target servers' network interfaces
- Firewall: allow inbound traffic to the listener port