Load Balancer
Keep your application online on launch day and through every maintenance window
Requests are shared across several servers, and a server that stops responding drops out before users notice. Your HTTPS certificate and web application firewall (WAF) are managed in one place, from the portal.
Why now
- Launch morning, 10:00: traffic multiplies and the single web server stops responding. Adding a second server is easy — what's missing is the layer that splits traffic between them and shows users one address.
- At 3 a.m. one of the application servers hangs, and nobody knows until the complaint emails arrive in the morning. A health check on the load balancer takes that server out within seconds and sends requests to the ones still standing.
- Every patch night drops open sessions, and customer service fields calls about emptied shopping carts. You need a way to take a server out of the pool that waits for open connections to finish.
- A security scan found SQL injection and cross-site scripting (XSS) holes in your public application form. Until the code is fixed, you need a filter that stops attack signatures before they reach the app.
- Someone forgot to renew the HTTPS certificate on one of four servers, and browsers started warning visitors that the connection wasn't secure. You want the certificate in one place, with the servers none the wiser.
What changes
| Today | With Nesnet |
|---|---|
| One server hangs, the site goes down, and your users are the ones who report it. | A health check pulls the unresponsive server from the pool; requests go to healthy servers, and the portal shows which check took it down. |
| Patching happens at midnight, and open sessions get cut. | The server drains gracefully: no new requests, open connections finish, and maintenance moves into working hours. |
| Every server carries its own certificate and its own renewal date. | The certificate sits once in your organisation's certificate library and is attached to the virtual service; the servers never touch it. |
| Attack attempts land straight on the application server. | The WAF recognises common attack signatures up front — logging only at first, blocking once it's tuned. |
| You install, patch and keep redundant your own load-balancing software. | Nesnet runs and updates the platform; you manage pools, rules and certificates from the portal. |
From today to live: how it works
- 1
Discovery call
Walk Nesnet's team through which applications run on how many servers and over which protocols. You leave the call knowing your HTTPS, WAF and persistence needs and what drives the price.
- 2
Gateway preparation
Nesnet enables the load balancer on your gateway and allocates its capacity. From then on, every load-balancing setting in the portal is in your team's hands.
- 3
Pool and health checks
Add your servers to the pool by IP or as a security group. Choose the algorithm, the persistence type and the health-check thresholds here.
- 4
Virtual service and WAF
Allocate an address from the IP pool, pick the port and profile, and attach the certificate. The WAF starts in detection mode; collect a few days of logs and write the exemptions you need.
- 5
Go-live
The firewall rule goes in, your domain points to the new address, and the old path stays open for a while as a way back. Once the logs look clean, the WAF moves to blocking mode.
What you get
Send traffic only to healthy servers
By default each new request goes to the server with the fewest open connections at that moment. Pick one of nine algorithms per pool — round robin, consistent hash, fastest response and least load among them — and weight a stronger server so it takes a bigger share.
Spot failures before your users do
Servers are probed regularly over HTTP, HTTPS, TCP, UDP or PING, and you set the interval, the timeout and how many failed attempts mark a server down. Passive monitoring is on as well, so a server returning errors to real traffic is flagged without waiting for the next probe.
Do maintenance during working hours
Give a server a drain period in minutes before maintenance; during that time it takes no new requests while open connections finish on their own. Immediate removal or an open-ended wait are options too, so patch day never empties a customer's cart.
New servers join the pool on their own
Instead of listing pool members by IP address, point the pool at a security group. Every web server added to the group joins the pool too, so launching servers for a busy week scales traffic without touching the load balancer.
Web traffic and other protocols in one place
HTTP and HTTPS services are balanced at the application level (L7); TCP, UDP and TLS services at the connection level (L4). One virtual service can publish several ports together, and several services can share an address on different ports.
Manage certificates in one place
HTTPS terminates on the load balancer, with the certificate picked from your organisation's certificate library. On renewal day, upload the new certificate and attach it to the service — not one certificate file on the servers behind it needs touching.
Stay encrypted all the way to the back end
If your security policy requires encryption inside the network too, the load balancer re-encrypts traffic to the servers. Server certificates are validated against a root certificate authority and the name (CN/SAN) is checked, so an impostor server is turned away.
Stop attacks before they reach the app
The web application firewall (WAF) sits in front of HTTP and HTTPS services with an open-source signature set that recognises common attacks such as SQL injection and cross-site scripting (XSS). While a hole in your code is being fixed, attack signatures never reach the application server.
Switch the WAF on by watching first
In detection mode the WAF lets requests through and only logs them, so a few days of logs show which signatures trip over real users. Disable signatures one by one, add allow rules by path, IP, method or host name, then move to blocking mode.
See false positives with their reasons
WAF recommendations show why a request was caught and which setting to change so the same entry stops recurring. Your security team doesn't loosen rules by guesswork; it reads the recommendation and exempts only the signature or path that needs it.
Route requests by what they contain
On application-level services, write rules on client IP, port, method, path, query string, header or cookie. Send different paths under one address to different server groups, add or rewrite headers, and redirect old links to their new home.
Put a ceiling on abuse
HTTP security rules let you deny specific requests, close a suspicious connection at the TCP level or rate-limit requests. A script hammering a login page hundreds of times a second is stopped before it wears your application down, and plain HTTP requests are redirected to HTTPS.
Keep users on the same server
For applications that hold session state on the server, persistence can follow client IP, an HTTP cookie, a custom HTTP header, an application cookie (such as JSESSIONID) or the TLS session. A full shopping cart or a half-filled form isn't lost because a user landed on another server.
See your users' real addresses
With client IP preservation on, the source address of each request is kept, so servers in the pool see the user's address rather than the load balancer's. Application logs, access restrictions and security reviews all work from the real source; the option needs a group-based pool and an IPv4 service address.
Publish over IPv4 and IPv6
A virtual service can be published on IPv4, IPv6 or both. Because Nesnet networks hand out IPv6 from Nesnet's own address block, you reach users on mobile carrier networks and meet tenders that ask for IPv6 without opening a separate project.
Balance your internal tiers too
The service address can be a public IP on the internet or an address visible only inside your network. Use the same load balancer to spread traffic from application servers to database read replicas or internal API servers, so no single internal server takes the whole load.
Kubernetes services go live on their own
Open a LoadBalancer-type service in a Kubernetes cluster on the Nesnet cloud and a virtual service is created on the load balancer automatically. Choose with one annotation whether TLS terminates inside the cluster or on the load balancer; the cluster's API address is published from the same platform.
See what happened in the logs
Request logs for each virtual service are listed in the portal for the time range you pick, filtered by client IP, URI, request type and response, and exported as CSV. 'Who got an error at 14:00 yesterday, and why?' gets answered without logging in to every server.
Long-lived connections stay up
Sessions that stay open for hours — IMAP, ActiveSync or device links — are balanced at the connection level with a long idle timeout. Phones that kept reconnecting behind a short-timeout balancer hold on to their sessions with this setting.
Why Nesnet
Nesnet publishes its own portal on this platform
Nesnet's cloud portal and mail service sit behind the same load-balancing platform offered to customers, with the portal's WAF in blocking mode. Nesnet runs the same software for its own production traffic.
The full feature set
Nesnet's automation enables the load balancer on your gateway with the broadest feature set. WAF, multiple ports per service and detailed request logs come with it.
Built to the vendor guide, verified by measurement
When Nesnet moved its own services behind the load balancer, it applied the software's official settings table and confirmed the result with live measurement. Idle timeouts for mail protocols were set the same way, measured on Nesnet's own mail platform.
Address, rules and balancing on one gateway
The service address is allocated from Nesnet's IP pool in the portal and released when you're done. Traffic to it passes through the firewall on your own gateway — no extra appliance, no extra console.
Your traffic is handled in Türkiye
The load balancer and the servers behind it run in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara data centres. Requests and logs never take a detour through a region abroad.
Example scenarios
An online shop getting ready for sale week
Situation
An e-commerce company runs two web servers and one database. Every new server means DNS and server changes, and during the last sale one server hung and half the site returned errors.
Outcome
The web servers join the pool as a security group; two more servers are added to the group before the sale and enter the pool on their own. A server that hangs is taken out by its health check, and users keep being served by the others.
An application form protected after a security scan
Situation
A security scan finds a SQL injection hole in an organisation's public application form. The development team needs a few weeks to fix it.
Outcome
The form goes behind the load balancer and the WAF runs in detection mode for a week. Logs and WAF recommendations show two signatures to exempt for real users, then blocking mode goes on; until the fix ships, attack attempts never reach the application.
An application moving to Kubernetes
Situation
A development team is moving its services to a Kubernetes cluster on the Nesnet cloud. Asking the network team to expose every new service is slowing down its release schedule.
Outcome
Opening a LoadBalancer-type service creates the virtual service automatically. The team chooses where TLS terminates with an annotation, and the network team only reviews the firewall rule.
A mail system whose phones kept dropping
Situation
An organisation runs a mail system with IMAP and ActiveSync on several servers. Because its old balancer had a short idle timeout, staff phones reconnect many times a day.
Outcome
These protocols are now balanced at the connection level with a long idle timeout. Nesnet uses the same setting on its own mail platform, so the starting values come from measurement rather than guesswork.
Patch day moved into working hours
Situation
A software company's operations team patches at midnight every month, because shutting a server down cuts open sessions.
Outcome
Servers now drain from the pool one at a time, get updated and go back in. Patch day moves to the afternoon, and users never notice the servers taking turns.
Who does what
| Nesnet | You |
|---|---|
| Builds, updates and keeps running the load-balancing platform and the gateways, with platform patches applied on a regular cycle. | Define, change or delete pools, health checks and virtual services in the portal. |
| Enables the load balancer on your gateway with the full feature set and allocates its capacity. | Upload your certificate to the library and attach a new one before the old one expires. |
| Operates the IP pool for service addresses, the IPv6 address block and internet connectivity. | Write the allow rule for service ports on your gateway firewall. |
| Tune WAF mode, signatures and allow rules to how your application behaves. |
Who it is for
Teams running several web servers
Teams that run an online shop, a corporate portal or an API on more than one server and want users to see a single address. Also the right call if you would rather keep certificates in one place than renew them on every server.
Organisations with internet-facing applications
Organisations that need to shield a customer portal, a partner screen or an application form from common web attacks. The WAF stops attack signatures before they reach the application server.
Development teams on Kubernetes
Teams running a Kubernetes cluster on the Nesnet cloud. Open a LoadBalancer-type service and its counterpart appears on the load balancer automatically, with no ticket to the network team.
Services with long-lived connections
Mail, messaging or device services whose sessions stay open for hours. That traffic is balanced at the connection level (L4) with a long idle timeout, so phones stop reconnecting all day.
Operations teams tired of midnight patching
Teams that want to patch during working hours. Servers are drained from the pool one at a time, updated and put back, without dropping a single user session.
May not be the right fit
For a single-server, low-traffic site that can live with a short maintenance outage, a load balancer is an extra layer you don't need. One virtual server and a port-forwarding rule on the Firewall will do.
If your application depends on scripts specific to one load-balancing product, run that product on your own virtual server instead; its upkeep and redundancy then stay with your team.
Under the hood
The load balancing layer is built into the cloud portal and attached to the edge gateway of your virtual data centre. Once Nesnet switches load balancing on for your edge, pools, virtual services, health monitors and WAF settings become yours to manage in the portal. The edge gateway runs active/standby, so if one side fails the other takes over. Nesnet adds its own automation on top: the load balancer is enabled with the widest feature set, virtual service addresses come from Nesnet's IP pool, and logs are wired into the portal. For Kubernetes, the cloud provider component turns LoadBalancer services into virtual services, which is also how Nesnet's own Kubernetes platform exposes its workloads.
Building blocks
- Load balancing and WAF layer
- balancing, health monitoring, TLS termination, WAF and logs
- WAF signature set
- open-source signatures for common web attacks
- Cloud portal and API
- pools, virtual services and IP address management
- Dedicated edge gateway
- active/standby operation, firewall and NAT
- Kubernetes cloud provider component
- maps LoadBalancer services to the load balancer
How it compares
| Option | When it is the right choice |
|---|---|
| A single virtual server with a port publishing rule | If one server can carry the load and a short outage during maintenance is acceptable, this is enough. The Firewall opens the DNAT and allow rule together in one step. |
| Your own software load balancer on a virtual server | If your application depends on modules or scripts specific to one load-balancing product, running that product on your own server is the honest choice. Upgrades, redundancy and certificate housekeeping then stay with your team. |
| The LoadBalancer service of Managed Kubernetes | If your applications already live in a Kubernetes cluster on Nesnet, you do not define a load balancer separately. Creating the service builds the virtual service on the same platform, and an annotation decides where TLS ends. |
Technical specifications
| Application profiles | HTTP, HTTPS (L7), L4 TCP/UDP, L4 TLS |
|---|---|
| Algorithms | 9; least connections by default |
| Server weight | Per-server ratio |
| Multiple ports per service | Yes |
| Virtual service address | Public IP or internal IP |
| L7 policy matching | Client IP, port, method, path, query, header, cookie |
| Address family | IPv4, IPv6 or both; one IP on different ports |
| HTTP security rules | Allow/deny, close connection, redirect to HTTPS, rate limit |
| Client IP preservation | Yes; group-based pool, IPv4 service address |
| Active health monitors | HTTP, HTTPS, TCP, UDP, PING |
|---|---|
| Monitor settings | Interval (s), timeout (s), consecutive successes/failures |
| Passive monitoring | On |
| Persistence | Client IP, HTTP cookie, custom header, application cookie, TLS |
| Graceful drain | In minutes; immediate or indefinite also available |
| Pool members | Individual IPs or a firewall group |
| TLS termination | HTTPS and L4 TLS services; certificate from the library |
|---|---|
| Back-end TLS | Root CA validation, CN/SAN check |
| WAF | Signature-based; detection and enforcement; signature groups; exceptions |
| WAF scope | HTTP/HTTPS services only |
| WAF management | Detection/enforcement, allowlist, signature editing in the portal |
| Edge gateway | Active/standby operation |
|---|---|
| Logs | HTTP request logs, L4 logs, analytics metrics |
| Feature set | Full set, enabled by Nesnet automation |
| Logs in the portal | Filtering, CSV export, WAF recommendations |
| Data centres | Equinix Istanbul (Dudullu) and Türk Telekom Ankara |
If something breaks
A pool member stops responding
The health monitor removes it and new requests go to the remaining members. The member status shows which monitor took it down, so troubleshooting starts in the right place.
The active side of the edge fails
The edge the load balancer sits on runs active/standby; if the active side fails, the standby side takes over and your virtual services stay published on the same edge.
A physical host fails
If the physical host under your pool members goes down, the platform restarts those virtual machines on other hosts automatically. Until they are back, the load balancer keeps them out of rotation through its health checks.
Frequently asked questions
Pricing and first steps
Pricing
The load balancer is billed monthly, and invoices are issued as e-Invoice or e-Archive documents. The price is set by the resources you use and the items you choose, and Nesnet’s team prepares your quote.
What the price depends on
- Number and size of the virtual servers in your pools
- Storage used by those servers (GB)
- Outbound internet traffic (GB)
How to get started
- 1.Tell us about your servers and traffic using the form, or call 0800 606 1071.
- 2.Your needs are worked out in one call, with a load-balancing layout and a price.
- 3.Your gateway is prepared and you open your first virtual service in the portal.
Stop depending on a single server
Tell Nesnet's team how many servers you run, which addresses are live and what you need to protect; you'll hear back within the same business day. Requests go to healthy servers, and certificates and the WAF live in one place.