# Load Balancers ### Introduction Krutrim Load Balancers are fully managed, high-availability services that automatically distribute incoming traffic across your backend servers or applications. They ensure your services stay reliable, responsive, and scalable — even during sudden traffic spikes. Load balancers act as smart traffic managers, routing requests to healthy targets and preventing any single server or region from becoming a point of failure. Whether you’re running web apps, APIs, or large-scale workloads, Krutrim’s Load Balancers help maintain consistent performance and uptime. You can choose between: * **Application Load Balancers (ALB)** — operate at Layer 7 for content-based routing (HTTP/HTTPS). * **Network Load Balancers (NLB)** — operate at Layer 4 for ultra-low-latency traffic (TCP/UDP). Krutrim manages scaling, health checks, SSL termination, and high availability automatically — so you can focus on your applications, not the infrastructure behind them. #### Target Groups A **Target Group** is a logical collection of backend servers (VMs) that receive traffic from a Load Balancer. Each target group defines how the health of its targets is checked and which ports or protocols are used for communication. * Targets are registered VMs or services that handle actual user requests. * Health checks ensure only healthy targets receive traffic. * You can attach one or more target groups to a load balancer, depending on your routing needs. #### Listeners A **Listener** is a process that checks for incoming connection requests using a specific protocol and port. It defines *how* and *where* incoming traffic is routed. * Each listener is mapped to only *one* target group. * You can add multiple listeners (e.g., HTTP on port 80, HTTPS on port 443) to the same load balancer. * You can add multiple listeners using the same protocol (eg. HTTP, HTTPS, TCP), but on different ports. Each of these would map to a separate target group. #### Choosing the Right Load Balancer Krutrim offers two types of load balancers to suit different application needs. The choice depends on the kind of traffic your application handles and how you want to route it. Choose **Application Load Balancer (ALB)** if you need to route web traffic intelligently — for example, directing requests based on URLs, headers, or cookies. It’s ideal for websites, APIs, and micro-services that use HTTP or HTTPS. Choose **Network Load Balancer (NLB)** if you need ultra-fast performance and can handle raw network traffic without content-based routing. It’s best for real-time applications, gaming, streaming, or IoT workloads that rely on TCP or UDP connections. | | ALB | NLB | | -------------------- | ---------------------------------------------- | -------------------------------------- | | **Best For** | Web applications, APIs, microservices | Real-time apps, gaming, streaming, IoT | | **Traffic Type** | HTTP / HTTPS | TCP / UDP | | **Routing Type** | Content-based (based on URL, headers, cookies) | Network-based (based on IP and port) | | **SSL Termination** | Yes – SSL handled at the load balancer | No – traffic passed as-is | | **Policies & Rules** | Supports advanced routing rules | Not applicable | ### Creating a Target Group Creating a target group is a pre-requisite for creating a load balancer. [Learn how to create a Target Group.](/basics/core-infrastructure/networking/load-balancers/create-target-group.md) ### Creating a Load Balancer [Learn how to create a Network Load Balancer.](/basics/core-infrastructure/networking/load-balancers/create-network-load-balancer-nlb.md) [Learn how to create an Application Load Balancer.](/basics/core-infrastructure/networking/load-balancers/create-application-load-balancer-alb.md) ### Manage Load Balancer * You can view or edit a Load Balancer from the **Load Balancers** listing page by clicking **“View”** or **“Edit”** next to the desired Load Balancer. * **Region**, **VPC**, and **Subnet** cannot be modified after deployment. * **Security Groups** can be updated or changed anytime. * In **Listener** settings, the **Protocol** and **Port number** cannot be modified once deployed. However, all **Policies** and **Rules** under a listener can be edited as needed. * In **Pool Configuration**, you can modify the **Pool Name**, **Load Balancing Algorithm**, and **Target Group** attached. The **Pool Protocol**, however, cannot be changed. * For major changes like switching protocol or region, it’s recommended to create a new Load Balancer. ### Delete Load Balancer * You can delete a Load Balancer from the **Load Balancers** listing page by selecting the **“Delete”** option from the **Actions** menu of the respective Load Balancer. * Deleting a Load Balancer will **not delete the associated Target Groups** — they will only be **detached** and remain available for future use. * Once deleted, the Load Balancer and its listeners, pools, and policies are permanently removed. * Always verify that no active applications depend on the Load Balancer before deleting it. ### Billing * The **base charge** for both Standard ALB and Standard NLB is **₹8.00 per hour**. * **Data processing charges** apply as follows: **₹0.44/GB** for the first 100 GB, and **₹0.22/GB** for usage above 100 GB. * A **Standard ALB** supports up to **10,000 simultaneous connections** and **40,000 requests per second (RPS)**. * A **Standard NLB** supports up to **90,000 simultaneous connections** and **350,000 requests per second (RPS)**. * Data transfer is billed for both **inbound and outbound** traffic through the load balancer. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.cloud.olakrutrim.com/basics/core-infrastructure/networking/load-balancers.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.