# Exoscale Documentation — NLB > Network Load Balancer (NLB): a Layer 4 (TCP/UDP) load balancer that distributes incoming traffic to the Compute instances of an Instance Pool. --- url: https://community.exoscale.com/product/networking/nlb/ --- # NLB - [Quick Start - NLB](https://community.exoscale.com/product/networking/nlb/quick-start/index.md) - Create a Network Load Balancer, add a service, and route traffic to an Instance Pool through the CLI or Portal. - [Overview - NLB](https://community.exoscale.com/product/networking/nlb/overview/index.md) - Terminology and key features at a glance, learn the core concepts, capabilities, and options of this service before you dive deeper. - [How-To - NLB](https://community.exoscale.com/product/networking/nlb/how-to/index.md) - Step-by-step guides to configure the service and use specific features, with clear instructions for common tasks and problem solving. - [Service Boundaries - NLB](https://community.exoscale.com/product/networking/nlb/service-boundaries/index.md) - Service boundaries: quotas, limits, and the guaranteed service levels (SLA) for this product, including key constraints to plan and operate reliably. - [Reference - NLB](https://community.exoscale.com/product/networking/nlb/reference/index.md) - Reference documentation for API, CLI, and tools, browse comprehensive details, parameters, commands, and integration notes. --- url: https://community.exoscale.com/product/networking/nlb/quick-start/ --- # Quick Start - NLB Use this guide to create a Network Load Balancer (NLB), connect it to an Instance Pool, and verify its public endpoint. ## Prerequisites Before you begin: - Create an [Instance Pool](https://community.exoscale.com/product/compute/instances/how-to/instance-pools/index.md) containing the instances that will receive traffic. - Create the NLB and Instance Pool in the same Exoscale zone. - Make sure the application is running on the target instances and listening on the target port. - Configure the target instances' Security Groups to allow the required application and health-check traffic. - Install and configure the [Exoscale CLI](https://community.exoscale.com/tools/command-line-interface/index.md) if you want to follow the CLI workflow. > [!IMPORTANT] > An NLB service targets an Instance Pool. You cannot configure an arbitrary > list of instances as its backend. ## First Steps via CLI ### Create a Network Load Balancer {#creating-a-network-load-balancer-from-the-cli} Create an NLB in the same zone as the target Instance Pool: ```bash exo compute load-balancer create mynlb --zone ch-gva-2 --description "Exposing my application to the internet" ✔ Creating Network Load Balancer "mynlb"... 6s ┼───────────────────────┼─────────────────────────────────────────┼ │ NETWORK LOAD BALANCER │ │ ┼───────────────────────┼─────────────────────────────────────────┼ │ ID │ 988e7d8e-5841-451a-995a-8b5b48ac071c │ │ Name │ mynlb │ │ Zone │ ch-gva-2 │ │ IP Address │ 91.92.152.147 │ │ Description │ Exposing my application to the internet │ │ Creation Date │ 2025-05-19 08:26:43 +0000 UTC │ │ State │ running │ │ Services │ n/a │ │ Labels │ │ ┼───────────────────────┼─────────────────────────────────────────┼ ``` The command returns the NLB ID, state, and public IP address. You can retrieve the information again at any time: ```bash exo compute load-balancer show mynlb --zone ch-gva-2 ``` ### Add a Service Add a TCP service that listens on port 80 and forwards traffic to port 80 on the `web` Instance Pool: ```bash exo compute load-balancer service add mynlb web-http \ --zone ch-gva-2 \ --instance-pool web \ --protocol tcp \ --port 80 \ --target-port 80 \ --strategy round-robin \ --healthcheck-mode tcp \ --healthcheck-port 80 ``` Inspect the configured service: ```bash exo compute load-balancer service show mynlb web-http --zone ch-gva-2 ``` For all supported service and health-check options, see the [`exo compute load-balancer service add` reference](https://community.exoscale.com/reference/cli/exo/compute/load-balancer/service/add/index.md). ### Verify the Endpoint Wait until the NLB and its service report a running state. For an HTTP application listening on port 80, send a request to the NLB public IP: ```bash curl http:// ``` If the request fails, confirm that the target application is running, the health check is passing, and the target instances allow the required traffic. ## First Steps via Portal ### Create a Network Load Balancer {#creating-a-network-load-balancer-from-the-portal} In the [Exoscale Portal](https://portal.exoscale.com/), select **Compute**, then **Load Balancers**. Select **Add** to open the NLB creation form. Enter: - a unique name; - the zone containing the target Instance Pool; - an optional description. ![NLB creation form in the Exoscale Portal.](./nlb.png) Submit the form. After the NLB is created, the list displays its state and public IP address. ![Created NLB and its public IP address in the Portal.](./nlb-created.png) ### Open the NLB Details Open the contextual menu for the NLB and select **Details**. The details view shows the NLB configuration, public IP address, state, and configured services. ![NLB details view in the Exoscale Portal.](./nlb-details.png) ### Add a Service Select **Add Service**, then configure: - a service name; - the target Instance Pool; - TCP or UDP; - the public service port; - the target port used by the application; - the load-balancing strategy; - the health-check mode, port, interval, timeout, and retry settings. ![NLB service creation form in the Exoscale Portal.](./service.png) Submit the form and wait for the service to report a running state. Confirm that its health check succeeds before sending production traffic to the NLB. ### Verify the Endpoint Copy the NLB public IP address from its details page. For an HTTP application listening on port 80, open `http://` in a browser or run: ```bash curl http:// ``` ## Next Steps - Learn how NLB services, strategies, and health checks work in the [NLB Overview](https://community.exoscale.com/product/networking/nlb/overview/index.md). - Review [NLB limits and quotas](https://community.exoscale.com/product/networking/nlb/service-boundaries/limits-and-quotas/index.md). - Manage backend capacity with [Instance Pools](https://community.exoscale.com/product/compute/instances/how-to/instance-pools/index.md). - Browse the [NLB CLI reference](https://community.exoscale.com/reference/cli/exo/compute/load-balancer/index.md). --- url: https://community.exoscale.com/product/networking/nlb/overview/ --- # Overview - NLB ## Architecture A __Network Load Balancer (or NLB)__ is a Layer 4 (TCP/UDP) load balancer that distributes incoming traffic to Compute instances managed by an [Instance Pool](https://community.exoscale.com/product/compute/instances/how-to/instance-pools/index.md). ![](nlb.svg) ## Terminology Several types of load balancing strategies are available during service configuration: Round Robin : incoming traffic will be forwarded to each member of the Instance Pool in equal proportions and in circular order. Source-Hash : incoming traffic will be balanced on different members of the target Instance Pool depending on the source IP address. A given source IP address will always forward to the same Instance. Maglev-Hash : consistent hashing with minimal disruption. Each destination will receive an almost equal number of connections. There is no difference in terms of raw performance between the strategies. The choice depends on your specific application and needs. ## Features A NLB is composed of several services, each bound to an Instance Pool that resides in the same zone as the NLB. Services will efficiently forward connections reaching the NLB's IP address to the member instances of the Instance Pool. While the instances remain individually accessible through their public IP, the NLB will expose a single IP address for all services and distribute the incoming traffic across the members of the Instance Pool following the service's rules. NLB services will update automatically when the Instance Pool scales up or down, distributing traffic across all reachable member instances of the pool and excluding unreachable ones by using an integrated health check functionality. NLB acts only on incoming traffic, so all return traffic from the backend to the client that originated the request goes out directly from the pool member instance. Each NLB is composed of services, each with its own configuration. Each NLB service can target a different Instance Pool residing in the same zone as the NLB, and is independent from other services. Each NLB Service is composed of the following parts: - A target Instance Pool - A load balancing strategy - A triplet indicating the Protocol, Service Port and Target Port for the traffic to be balanced. - A Health Check probe > [!NOTE] > While it's possible to edit and modify most of the parameters of a service, it is not possible > to modify the targeted Instance Pool. Moreover, an Instance Pool cannot be deleted if it is > targeted by a service. Network Load Balancer supports [labels](https://community.exoscale.com/product/compute/instances/how-to/labels/index.md). For service limits, quotas, and zone availability, see [NLB Limits and Quotas](https://community.exoscale.com/product/networking/nlb/service-boundaries/limits-and-quotas/index.md). --- url: https://community.exoscale.com/product/networking/nlb/how-to/ --- # How-To - NLB Step-by-step guides to configure the service and use specific features, with clear instructions for common tasks and problem solving. - [Choose Load Balancer Strategies](https://community.exoscale.com/product/networking/nlb/how-to/loadbalancer-strategies/index.md) - Choose NLB strategies like Source-Hash or Maglev-Hash to balance traffic for stateful apps, stable routing, and dynamic backend changes. - [Configure NLB Health Checks](https://community.exoscale.com/product/networking/nlb/how-to/config-healthcheck/index.md) - Configure NLB health checks with TCP, HTTP, or HTTPS probes, thresholds, and timing to route traffic only to healthy instance pool members. - [Configure Protocols and Ports](https://community.exoscale.com/product/networking/nlb/how-to/protocols-and-ports/index.md) - Configure NLB protocols and service or target ports to route TCP or UDP traffic correctly to instance pool members behind the load balancer. --- url: https://community.exoscale.com/product/networking/nlb/how-to/loadbalancer-strategies/ --- # Choose Load Balancer Strategies ## Source-Hash Strategy Details Whereas Round Robin works for most use cases, Source-Hash is generally better for stateful applications. Source hashes ensure that the same client always goes to the same backend based on their IP address. This could be useful, for example, to create session stickyness. However, it is important to notice that the entire hash distribution is recalculated when the state of the backend nodes changes. This recalculation happens: - When an Instance Pool member instance is added (scaling up). - When an Instance Pool member instance is deleted (scaling down). > [!NOTE] > The source hash is NOT recalculated in case of a health check failure. ## Maglev-Hash Strategy Details Maglev-hash offers a sophisticated approach with minimal disruption during server changes and optimal load distribution, making it suitable for large-scale, dynamic environments. It minimizes changes in load distribution when servers are added or removed, ensuring high availability and reliability; provides near-optimal load distribution and quick recovery. --- url: https://community.exoscale.com/product/networking/nlb/how-to/config-healthcheck/ --- # Configure NLB Health Checks Each NLB Service comes with an integrated, non-optional health check mechanism. Each member of the target Instance Pool will be regularly contacted using the health check parameters you provide. When the health check probe is marked as failed, the NLB will no longer forward traffic to that node. The health check parameters are: Protocol : the protocol the health check has to use to contact the pool member, either `TCP`, `HTTP` or `HTTPS`. TLS-SNI : this parameter can be set when the protocol is `HTTPS`. It allows configuration of the server name indication of the health check. Port : the port on which the health check must be performed. This can be a different port than the target port used to forward the traffic, or the same one depending on your own setup. As for the target port, your target Instance Pool [Security Groups](https://community.exoscale.com/product/networking/security-group/index.md) must allow incoming traffic on the health check port. Path : the URI relative to the machine IP address to be used for `HTTP` health checks. The path starts with `/` that will be added to the target Instance IP. Interval : the time in seconds between health check calls. Timeout : the time in seconds until the request is dropped and the health check call is considered failed. Retries : the number of subsequent failed health check calls needed to consider the member is _down_. The health check probe will try to contact each member of the Instance Pool with the designated method and at the indicated interval: - HTTP health checks will seek a 2XX status code - TCP health checks will verify that it is possible to establish a connection on the specified port The health check status of the NLB member will change from `success` to `failure` after the indicated amount of failed retries. No traffic will be forwarded to an instance if its health check status is marked as `failure`. The health check probe will continue to try to reach the Instance, and as soon as the check succeeds, it will change the status back to `success` and resume traffic forwarding. > [!WARNING] > Your Instance Pool [Security Groups](https://community.exoscale.com/product/networking/security-group/index.md) > needs to have an open ingress rule on the designated health check port to work. --- url: https://community.exoscale.com/product/networking/nlb/how-to/protocols-and-ports/ --- # Configure Protocols and Ports For each service you will provide the protocol of the traffic to be balanced (either `TCP` or `UDP`) and a pair of ports: Service port : the port on which the NLB Service has to listen for the incoming traffic. Target port : the port on which the NLB Service has to forward the traffic. This is the port on which the members of the Instance Pool will actually receive the forwarded traffic. > [!WARNING] > Your Instance Pool [security groups](https://community.exoscale.com/product/networking/security-group/index.md) > need to have an open ingress rule on the designated target port to work. --- url: https://community.exoscale.com/product/networking/nlb/service-boundaries/ --- # Service Boundaries - NLB - [Limits and Quotas - NLB](https://community.exoscale.com/product/networking/nlb/service-boundaries/limits-and-quotas/index.md) - Review NLB hard limits, account quotas, backend restrictions, naming rules, and zone availability. - [SLA - NLB](https://community.exoscale.com/product/networking/nlb/service-boundaries/sla/index.md) - NLB Service Level Agreement - [Pricing ↗︎](https://www.exoscale.com/pricing/#nlb) --- url: https://community.exoscale.com/product/networking/nlb/service-boundaries/limits-and-quotas/ --- # Limits and Quotas - NLB ## Limits | Usage | Limit | | --- | ---: | | Maximum characters in an NLB name | 255 | | Maximum characters in an NLB description | 225 | | Maximum services per NLB | 200 | * Names of NLBs need to be unique in the context of an organization. * Names of NLB Services need to be unique in the context of the NLB itself. * NLB only forwards connections to Instance Pool members. It is not possible to terminate TCP or SSL/TLS connections with NLB. * Once a service is created, it is not possible to modify its target Instance Pool. * An IPv6 Network Load Balancer requires its target Instance Pool to have IPv6 enabled (dual-stack). Instances without an IPv6 address are not eligible backends and will not receive traffic. > [!IMPORTANT] > Network Load Balancers only work with > [Instance Pools](https://community.exoscale.com/product/compute/instances/how-to/instance-pools/index.md). > It is not possible to provide an arbitrary list of instances as a target. ## Quotas | Usage | Quota | | --- | ---: | | Network Load Balancers per account | 5 | Each NLB also counts toward the [Elastic IP](https://community.exoscale.com/product/networking/eip/index.md) quota. Contact Exoscale Support if you need to request a quota increase. ## Availability NLB is available in all Exoscale zones. --- url: https://community.exoscale.com/product/networking/nlb/service-boundaries/sla/ --- # SLA - NLB These product-specific SLAs define the Service Availability Target for Exoscale Network Load Balancer (NLB). It applies to each Client using the Service. Capitalized terms used herein but not defined herein shall have the meanings set forth in the Exoscale Terms and Conditions or EUSA, whichever applies. ## SLA Definitons | Metric | Target | Definition | | -------- | -------- | ------------ | | Service Availability for Network Load Balancer | >= 99.95% Monthly Uptime Percentage | The percentage of time in a calendar month during which the Exoscale Network Load Balancer is operational and accessible, actively distributing traffic to healthy backend targets. Unavailability means that the Client is unable to access its subscribed resources running on the Exoscale Service platform due to the failure of a critical component like the load balancer. | ## Product Specifications For detailed product features, technical specifications, and tutorials, please refer to the [Exoscale documentation](https://community.exoscale.com/product/networking/nlb/index.md). ## Client Responsibilities While Exoscale is responsible for operating and maintaining the Network Load Balancer service, Clients remain responsible for the following: - Backend server health and availability - Health check configuration and tuning - SSL/TLS certificate management for HTTPS listeners - Security group rules for load balancer traffic For a complete explanation of the shared responsibility framework between Exoscale and Clients, please see the [Exoscale Shared Responsibility Model documentation](https://community.exoscale.com/platform/compliance/shared-responsability-model/index.md). ## Exclusions For the complete list of SLA exclusions, please refer to the [General Exoscale Terms and Conditions](https://www.exoscale.com/terms/). ## Retribution The standard retribution and SLA credit schemes apply for this product as described under [General Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or [EUSA](https://www.exoscale.com/eusa/) whichever applies. In the event that the Monthly Uptime Percentage for Exoscale [SERVICE] falls below the committed Service Level Objective, the Client will be eligible for service credits as follows: | Monthly Uptime Percentage | Service Credit Percentage of Monthly Service Fees for Affected Resources | | -------- | -------- | | from 99.95% to 98.3% | 50% | | below 98.3% | 100% | ### Claim Service Credit To request a service credit, refer to the Service Unavailability Credit section of the [Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or the [EUSA](https://www.exoscale.com/eusa/), whichever applies. --- url: https://community.exoscale.com/product/networking/nlb/reference/ --- # Reference - NLB - [API Network Load Balancer](https://community.exoscale.com/reference/api/compute/network-load-balancer/index.md) - All operations on Network Load Balancer. (external) - [CLI Network Load Balancer](https://community.exoscale.com/reference/cli/exo/compute/load-balancer/index.md) - All commands on Network Load Balancer. (external)