Free guides, interview Q&As, and job responsibility breakdowns — curated by industry veterans to help you crack MNC interviews
Azure Load Balancing is a core networking service that helps distribute incoming network traffic across multiple backend resources, such as Virtual Machines, so that no single resource is overwhelmed with too many requests. It plays an important role in building highly available and scalable applications on Azure, and it is one of the most commonly used networking services in real-world Azure deployments.
What is Azure Load Balancing?
Definition
Azure Load Balancer is a Layer 4 (TCP, UDP) load-balancing service that distributes incoming network traffic across a pool of backend resources, such as Virtual Machines, based on configured load balancing rules and health probe status.
(Azure Load Balancer एक networking service है जो आने वाले network traffic को कई backend VMs के बीच distribute करती है, ताकि traffic संतुलित तरीके से handle हो सके और किसी एक VM पर अधिक load न पड़े।)
Explanation
When client requests arrive at the load balancer's frontend IP address, the load balancer examines the configured load balancing rules and forwards each request to one of the healthy VMs in the backend pool. This distribution happens automatically and transparently to the client, who only interacts with a single IP address regardless of how many backend VMs are actually serving the traffic. Azure Load Balancer works at the transport layer, meaning it makes forwarding decisions based on IP address and port information rather than inspecting application-level content.
Example
ABC Technologies hosts three web servers running an internal e-commerce application. Instead of sharing three different IP addresses with customers, the company configures an Azure Load Balancer in front of the VMs. Customers now access the application using a single Load Balancer IP address, while the Load Balancer silently distributes each incoming request across the three web servers.
How Azure Load Balancing Works
Definition
Azure Load Balancer works by receiving incoming connections on a frontend IP address and forwarding them to backend resources according to load balancing rules, while continuously checking backend health using health probes.
(Azure Load Balancer, frontend IP पर आने वाले connections को backend VMs तक load balancing rules के अनुसार forward करता है, और health probe के द्वारा backend VMs की health को भी लगातार check करता रहता है।)
Explanation
The working of Azure Load Balancer can be understood in four steps: first, a client sends a request to the Load Balancer's frontend IP; second, the Load Balancer checks the health probe status of the backend VMs to identify which ones are currently healthy; third, based on the configured load balancing rule, the Load Balancer selects a healthy backend VM using a hashing algorithm; and fourth, the request is forwarded to that VM's private IP address and port. This process repeats independently for every new incoming connection, allowing traffic to be spread fairly across all available backend resources.
Example
Suppose an organization's Load Balancer is configured with three backend VMs, but the health probe marks VM2 as unhealthy. In this situation, the Load Balancer automatically stops sending new traffic to VM2 and continues distributing requests only between VM1 and VM3 until VM2 becomes healthy again.
Why Azure Load Balancing is Used
Azure Load Balancing is used whenever an application needs to remain available and responsive even if individual backend VMs fail or become overloaded. Instead of relying on a single server that can become a single point of failure, organizations deploy multiple VMs behind a Load Balancer so that traffic can continue flowing even if one VM goes down. This approach also allows organizations to scale their applications by simply adding more VMs to the backend pool as demand grows. Common reasons for using Azure Load Balancing include:
(Azure Load Balancing का उपयोग तब किया जाता है जब application को high availability चाहिए और traffic को कई VMs में समान रूप से बांटना हो। इससे किसी एक VM के fail होने पर भी application काम करता रहता है।)
Example
An organization running a payment processing application cannot afford downtime. By placing three VMs behind an Azure Load Balancer, the organization ensures that even if one VM restarts for maintenance, the other two VMs continue serving customer requests without interruption.
The purpose of Azure Load Balancing goes beyond simply forwarding traffic — it is designed to keep applications reliable, responsive, and resilient under varying levels of demand. The following points describe the core purposes that Azure Load Balancer serves in a typical Azure network architecture.
Ensure High Availability
High availability means that an application remains accessible to users even when individual components fail. Azure Load Balancer contributes to high availability by distributing traffic across multiple backend VMs deployed either in an Availability Set or across Availability Zones, so that the failure of one VM does not bring down the entire application. Combined with health probes, the Load Balancer can automatically detect a failed VM and redirect traffic to the remaining healthy VMs within seconds. This makes Load Balancer a foundational building block for any production-grade, mission-critical Azure workload.
(High Availability का मतलब है कि किसी एक VM के fail होने पर भी application users के लिए accessible बना रहे। Load Balancer traffic को कई VMs में बांटकर यह सुनिश्चित करता है कि application हमेशा चालू रहे।)
Example
A banking application is deployed across three VMs using a zone-redundant configuration behind a Standard Load Balancer. If one Availability Zone experiences an outage, the Load Balancer continues sending traffic to VMs running in the remaining zones, keeping the application available to customers.
Prevent Server Overloading
Without load balancing, all client requests would be directed to a single server, which can quickly become overwhelmed as the number of users increases, resulting in slow response times or complete failure. Azure Load Balancer prevents this by spreading incoming requests evenly across all healthy backend VMs, ensuring that no single VM handles a disproportionate share of the traffic. This even distribution keeps CPU, memory, and network utilization balanced across the backend pool, which in turn keeps response times consistent for end users. As traffic grows, additional VMs can be added to the backend pool to further reduce the load on each individual server.
(Load Balancer traffic को सभी healthy VMs में बराबर मात्रा में बांटता है, जिससे किसी एक VM पर ज्यादा load नहीं पड़ता और server overload होने से बचा जा सकता है।)
Example
During a festive sale, an e-commerce website receives ten times its usual traffic. Because the application is deployed across five VMs behind a Load Balancer, the additional load is spread across all five servers instead of overwhelming a single machine.
Distribute Incoming Traffic
Traffic distribution is the fundamental function performed by a Load Balancer — it takes all incoming client connections and spreads them across the available backend VMs using a defined distribution mode, most commonly a five-tuple hash based on source IP, source port, destination IP, destination port, and protocol type. This ensures that traffic from the same client session is generally routed to the same backend VM for the duration of that session. Because the distribution happens automatically at the network layer, application developers do not need to build custom logic to decide which server should handle each request. This makes it easy to scale an application horizontally simply by adding more VMs to the backend pool.
(Load Balancer traffic को एक defined algorithm के आधार पर backend VMs में automatically distribute करता है, जिससे developers को traffic distribution के लिए अलग से कोई logic नहीं लिखना पड़ता।)
Example
A company's web application receives requests from thousands of different users simultaneously. The Load Balancer automatically distributes these requests across four backend VMs using its hashing algorithm, without requiring any manual intervention.
Improve Application Reliability
Application reliability refers to how consistently an application performs its intended function without unexpected failures or degraded performance. Azure Load Balancer improves reliability by working together with health probes to continuously monitor the state of backend VMs and automatically excluding any VM that stops responding correctly. This means that transient issues on a single VM, such as a temporary crash or restart, do not affect the overall availability of the application, because traffic is simply redirected to the remaining healthy VMs. Over time, this self-healing behavior significantly reduces the impact of individual server failures on the end-user experience.
(Health Probe की मदद से Load Balancer यह पहचानता है कि कौन-सी VM सही तरीके से काम कर रही है, और सिर्फ healthy VMs को ही traffic भेजता है, जिससे application की reliability बढ़ती है।)
Example
If a backend VM crashes unexpectedly due to a software update, the health probe detects the failure within seconds and the Load Balancer stops sending traffic to that VM, allowing the remaining VMs to continue serving users without any visible disruption.
Azure provides two main types of Load Balancer based on the scope of traffic they handle — Public Load Balancer and Internal Load Balancer. Choosing the right type depends on whether the traffic originates from the internet or from within a private Azure network.
Public Load Balancer
Definition
A Public Load Balancer is a Load Balancer that has a public IP address as its frontend, allowing it to receive and distribute traffic coming from the internet to backend VMs within an Azure Virtual Network.
(Public Load Balancer का frontend एक public IP address होता है, जिसकी मदद से internet से आने वाला traffic backend VMs तक पहुंचाया जाता है।)
Explanation
A Public Load Balancer is typically used for internet-facing applications, such as public websites or APIs, where external users need to reach the application. Because the frontend IP is publicly accessible, the individual backend VMs do not need their own public IP addresses — all inbound traffic passes through the Load Balancer's public IP first. Public Load Balancers can also provide outbound internet connectivity for backend VMs through a process known as outbound SNAT (Source Network Address Translation).
Example
A company hosts its public-facing e-commerce website on three VMs. A Public Load Balancer with a single public IP address is placed in front of these VMs, allowing customers anywhere on the internet to access the website through that one IP address.
Internal Load Balancer
Definition
An Internal Load Balancer, also called a Private Load Balancer, is a Load Balancer that uses a private IP address as its frontend, making it accessible only from within the same Virtual Network or from connected networks.
(Internal Load Balancer का frontend एक private IP address होता है, इसलिए इसे केवल उसी Virtual Network या connected networks के अंदर से access किया जा सकता है, internet से नहीं।)
Explanation
Internal Load Balancers are commonly used for multi-tier applications where the frontend tier needs to communicate with a backend tier, such as an application tier calling a database tier, without exposing that internal traffic to the public internet. Because the frontend IP is private, resources outside the Virtual Network — including the general internet — cannot directly reach the Internal Load Balancer, providing an additional layer of network isolation. This makes Internal Load Balancers well suited for internal APIs, database clusters, and other backend services that should never be exposed publicly.
Example
ABC Technologies has an application tier that needs to distribute requests across three database VMs. Since these database VMs should never be exposed to the internet, the company configures an Internal Load Balancer with a private frontend IP, allowing only resources inside the VNet to reach the database tier.
Public Load Balancer vs Internal Load Balancer
| Public Load Balancer | Internal Load Balancer |
|---|---|
| Frontend IP is a public IP address | Frontend IP is a private IP address |
| Accessible from the internet | Accessible only within the VNet or connected networks |
| Used for internet-facing applications | Used for internal, multi-tier communication |
| Can provide outbound internet connectivity | Does not provide internet-facing connectivity |
(Public Load Balancer का उपयोग internet-facing applications के लिए किया जाता है, जबकि Internal Load Balancer का उपयोग केवल internal/private communication के लिए किया जाता है।)
When to Use Public Load Balancer
A Public Load Balancer should be used whenever an application or service needs to be accessed by users or systems located outside the Azure Virtual Network, such as customers browsing a website from anywhere in the world. It is also appropriate when backend VMs need outbound internet access without being individually assigned public IP addresses, since the Public Load Balancer can provide this connectivity centrally. Typical scenarios include public websites, publicly accessible REST APIs, and internet-facing services that sit in front of a web tier.
(Public Load Balancer तब उपयोग किया जाता है जब application को internet से access किया जाना है, जैसे कोई public website या API।)
When to Use Internal Load Balancer
An Internal Load Balancer should be used when traffic needs to be distributed between resources that exist entirely within a private network boundary, such as between an application tier and a database tier, or between microservices that should not be reachable from the public internet. It is also useful in hybrid scenarios where on-premises systems, connected through a VPN or ExpressRoute connection, need to reach internal Azure services privately. Using an Internal Load Balancer in these cases reduces the attack surface of the application by keeping sensitive backend services completely hidden from the internet.
(Internal Load Balancer तब उपयोग किया जाता है जब traffic केवल internal resources के बीच ही distribute करना हो, जैसे application tier से database tier तक।)
Every Azure Load Balancer is built using four core components that work together to receive, evaluate, and forward traffic to backend resources. Understanding each component individually makes it much easier to design and troubleshoot a Load Balancer configuration. The four components — Frontend IP Configuration, Backend Pool, Health Probe, and Load Balancing Rule — are introduced briefly here and explained in full detail in the sections that follow.
Frontend IP Configuration
The Frontend IP Configuration is the IP address, either public or private, that clients use to connect to the Load Balancer. It acts as the single entry point through which all incoming traffic reaches the Load Balancer before being forwarded to the backend pool. A Load Balancer can have one or more frontend IP configurations depending on how many independent entry points the application requires.
(Frontend IP Configuration वह IP address होती है जिसका उपयोग clients Load Balancer से connect होने के लिए करते हैं।)
Backend Pool
The Backend Pool is the group of Virtual Machines or virtual machine scale set instances that actually process the incoming requests forwarded by the Load Balancer. Adding or removing VMs from the backend pool directly controls which resources are eligible to receive traffic. A well-configured backend pool typically contains two or more VMs to ensure redundancy.
(Backend Pool उन VMs का समूह होता है जो Load Balancer द्वारा भेजे गए traffic को actually process करते हैं।)
Health Probe
A Health Probe is a background mechanism that periodically checks whether each VM in the backend pool is responding correctly, and reports the health status back to the Load Balancer. Only VMs that pass the health probe check continue to receive new traffic, while unhealthy VMs are automatically excluded until they recover. This makes the health probe a critical component for achieving automatic failover.
(Health Probe backend VMs की health को लगातार check करता है और unhealthy VMs को traffic भेजना बंद कर देता है।)
Load Balancing Rule
A Load Balancing Rule defines exactly how traffic arriving on a specific frontend IP and port should be forwarded to a specific backend pool and port, using a chosen protocol such as TCP or UDP. Each rule ties together the frontend IP configuration, the backend pool, and a health probe, forming the complete path that a request follows through the Load Balancer. Multiple rules can be configured on a single Load Balancer to support different applications or ports.
(Load Balancing Rule यह define करता है कि traffic frontend से किस backend pool और port तक कैसे forward किया जाएगा।)
This section explains Frontend IP Configuration in more detail, including how public and private frontend IPs differ and the role this component plays in the overall load balancing process.
What is Frontend IP Configuration?
Definition
Frontend IP Configuration refers to the IP address assigned to the Load Balancer that clients use as the destination address when sending traffic to the application.
(Frontend IP Configuration Load Balancer को दी गई वह IP address है जिसे clients application तक पहुंचने के लिए उपयोग करते हैं।)
Explanation
When a Load Balancer is created, at least one frontend IP configuration must be defined, and this IP address becomes the single point of contact for all client traffic destined for that Load Balancer. A Load Balancer can support multiple frontend IP configurations, which allows a single Load Balancer to serve multiple applications or services, each identified by its own IP address. The frontend IP configuration is always linked to a specific load balancing rule, which determines what happens to traffic that arrives on that IP address.
Example
ABC Technologies configures a single frontend IP, 20.50.10.5, on their Public Load Balancer. All customer traffic destined for their website is sent to this IP address, which the Load Balancer then forwards to the appropriate backend VM.
Public Frontend IP
A Public Frontend IP is a publicly routable IP address assigned to the Load Balancer's frontend, allowing the Load Balancer to receive traffic directly from the internet. This type of frontend IP is used exclusively with Public Load Balancers and enables external users anywhere in the world to reach the application. Because it is exposed to the internet, the public frontend IP should be protected using appropriate Network Security Group rules and, where required, additional security services such as Azure DDoS Protection.
(Public Frontend IP एक internet-accessible IP address होती है जिसका उपयोग external users द्वारा application access करने के लिए किया जाता है।)
Private Frontend IP
A Private Frontend IP is an IP address drawn from the address space of the Virtual Network, making the Load Balancer reachable only from within that VNet or from networks connected to it. This type of frontend IP is used with Internal Load Balancers to keep traffic completely private and inaccessible from the public internet. Private frontend IPs are especially useful for backend services, such as databases and internal APIs, that should never be directly reachable from outside the organization's network.
(Private Frontend IP केवल Virtual Network के अंदर से accessible होती है और यह internet से पूरी तरह hidden रहती है।)
Role of Frontend IP in Load Balancing
The frontend IP plays a central role in load balancing because it is the first point of contact for every incoming connection — without a frontend IP, the Load Balancer would have no address on which to receive traffic. Once traffic arrives on the frontend IP, the Load Balancer consults the associated load balancing rule to determine which backend pool and port the traffic should be forwarded to. In this way, the frontend IP acts as the anchor that ties together the client-facing side of the Load Balancer with its backend distribution logic.
(Frontend IP वह starting point है जहाँ से Load Balancer traffic receive करता है और फिर उसे load balancing rule के अनुसार backend तक forward करता है।)
The Backend Pool determines which Virtual Machines are eligible to receive traffic from the Load Balancer. This section explains what a backend pool is, why it is important, and how VMs are added to it.
What is a Backend Pool?
Definition
A Backend Pool is a logical grouping of Virtual Machines or virtual machine scale set instances that are registered with a Load Balancer to receive distributed traffic.
(Backend Pool VMs का एक group होता है जिसे Load Balancer traffic भेजने के लिए उपयोग करता है।)
Explanation
VMs are added to a backend pool either individually through their network interfaces, or collectively as part of a Virtual Machine Scale Set, allowing the Load Balancer to treat scaled-out sets of identical VMs as a single backend target. Once a VM is part of the backend pool and its associated health probe reports it as healthy, it becomes eligible to receive traffic according to the configured load balancing rules. Removing a VM from the backend pool immediately stops the Load Balancer from sending it any further traffic, which is useful during planned maintenance windows.
Example
ABC Technologies adds three web server VMs — WebVM1, WebVM2, and WebVM3 — to the backend pool of their Load Balancer. From this point onward, any client traffic matching the Load Balancer's rules is distributed among these three VMs.
Purpose of Backend Pool
The primary purpose of a backend pool is to provide the Load Balancer with a defined set of resources that can share the responsibility of handling application traffic, rather than relying on a single VM. By grouping multiple VMs into a backend pool, an organization gains both redundancy — since traffic can continue flowing even if one VM fails — and scalability, since new VMs can be added to the pool as demand increases. The backend pool essentially defines the answer to the question, 'Which servers are available to handle this traffic right now?'
(Backend Pool का उद्देश्य traffic को handle करने के लिए कई VMs को एक साथ group करना है, जिससे redundancy और scalability दोनों मिलती हैं।)
Backend Pool Members
Backend pool members are the individual resources — typically Virtual Machines or VMSS instances — that have been added to the backend pool and are therefore eligible to receive traffic. Each member must have a network interface connected to the same Virtual Network as the Load Balancer, and members are generally expected to run identical or compatible application workloads so that traffic can be routed to any of them interchangeably. The Load Balancer treats all healthy members equally when distributing traffic, unless specific configuration settings dictate otherwise.
(Backend Pool Members वे VMs होती हैं जो backend pool में add की गई हैं और traffic receive करने के लिए eligible हैं।)
How to Configure a Backend Pool
Configuring a backend pool begins by opening the Load Balancer resource in the Azure Portal and navigating to the Backend pools section, where a new backend pool can be created with a descriptive name. The administrator then selects the Virtual Network associated with the Load Balancer and chooses whether to add backend pool members using NIC-based configuration for individual VMs or IP-based configuration for more flexible scenarios. After the backend pool is created, the required VMs or VMSS instances are added as members, completing the configuration.
(Backend Pool बनाने के लिए Azure Portal में Load Balancer खोलकर Backend pools section में जाना होता है और वहां required VMs को add किया जाता है।)
Add Virtual Machines to Backend Pool
Adding Virtual Machines to a backend pool associates their network interfaces with the Load Balancer, making them eligible to receive forwarded traffic once the health probe confirms they are healthy. This is typically done by selecting the backend pool in the Azure Portal, choosing Add, and then selecting the specific VMs or associated availability set/scale set to include. It is good practice to add at least two VMs to a backend pool so that the application can continue running even if one VM becomes temporarily unavailable.
(VMs को Backend Pool में add करने से वे Load Balancer से traffic receive करने के योग्य बन जाती हैं।)
Example
After creating a backend pool named 'web-backend-pool', ABC Technologies adds WebVM1 and WebVM2 as members. Both VMs are now capable of receiving traffic forwarded by the Load Balancer.
1.7 Health Probe
Health Probes allow the Load Balancer to continuously verify that backend VMs are functioning correctly, ensuring that traffic is only sent to resources that can actually process it.
What is a Health Probe?
Definition
A Health Probe is a monitoring mechanism configured on an Azure Load Balancer that periodically sends requests to backend VMs to determine whether each VM is healthy and able to receive traffic.
(Health Probe एक monitoring mechanism है जो backend VMs की health को periodically check करता है।)
Explanation
The health probe works by sending repeated checks — such as a TCP connection attempt or an HTTP request — to a specified port on each backend VM, at a configurable interval. If a VM responds successfully within the expected criteria, it is marked healthy and remains eligible for traffic; if it fails to respond correctly for a defined number of consecutive attempts, it is marked unhealthy and temporarily removed from active traffic distribution. This continuous monitoring allows the Load Balancer to react automatically to VM failures without any manual intervention.
Example
A Load Balancer is configured with an HTTP health probe on port 80 that checks each backend VM every 15 seconds. When WebVM2 stops responding due to an application crash, the health probe detects this within a few probe cycles and the Load Balancer stops sending it new traffic.
Why Health Probe is Used
Health probes are used to prevent the Load Balancer from sending traffic to VMs that are unable to properly process requests, which would otherwise result in failed connections or degraded performance for end users. By continuously validating VM health, the Load Balancer can automatically route around problematic VMs, effectively providing self-healing behavior for the application without requiring an administrator to manually intervene. This is especially important during events such as application crashes, VM reboots, or planned maintenance, where a VM may be temporarily unavailable.
(Health Probe का उपयोग यह सुनिश्चित करने के लिए किया जाता है कि traffic केवल उन्हीं VMs को भेजा जाए जो सही तरीके से काम कर रही हैं।)
Health Probe Configuration
Configuring a health probe involves specifying several key settings: the protocol to use for checking (TCP, HTTP, or HTTPS), the port on which the check should be performed, the interval between consecutive probe attempts, and the number of consecutive failures required before a VM is marked unhealthy. For HTTP or HTTPS probes, a specific URL path can also be specified, allowing the probe to check the health of a particular application endpoint rather than just basic connectivity. These settings can be tuned based on how quickly the organization needs the Load Balancer to detect and react to VM failures.
(Health Probe configure करते समय protocol, port, interval और failure threshold जैसी settings define की जाती हैं।)
Protocol and Port
Azure Load Balancer supports three health probe protocols — TCP, HTTP, and HTTPS — each suited to different scenarios depending on how detailed the health check needs to be. A TCP probe simply checks whether a connection can be established on the specified port, making it a lightweight option, while HTTP and HTTPS probes send an actual web request and check for a successful response code, allowing them to validate that the application itself — not just the network layer — is functioning correctly. The port specified in the probe configuration should generally match the port on which the application is actually listening on the backend VM.
(TCP probe केवल connection check करता है, जबकि HTTP/HTTPS probe application level पर response verify करता है।)
Health Probe and Backend VM Health
The health status reported by the probe directly determines whether a given backend VM participates in traffic distribution at any given moment. When all configured probe checks succeed, the VM is considered healthy and continues to receive its share of traffic according to the load balancing rule. However, if the VM fails the required number of consecutive probe checks, it is immediately marked unhealthy, and the Load Balancer redirects its share of traffic to the remaining healthy VMs in the backend pool until the failing VM recovers.
(Health Probe की status के आधार पर ही यह तय होता है कि किसी VM को traffic मिलेगा या नहीं।)
A Load Balancing Rule ties together the frontend IP, backend pool, and health probe to define exactly how traffic should be handled. This section explains each element of a load balancing rule and how they work together.
What is a Load Balancing Rule?
Definition
A Load Balancing Rule is a configuration on an Azure Load Balancer that specifies how traffic arriving on a particular frontend IP and port should be distributed to a particular backend pool and port.
(Load Balancing Rule यह define करता है कि frontend पर आने वाला traffic किस backend pool और port तक कैसे भेजा जाएगा।)
Explanation
Every load balancing rule brings together several components: a frontend IP configuration that defines where traffic enters, a backend pool that defines where traffic should be sent, a health probe that determines which backend VMs are currently eligible, and a protocol and port pair on both the frontend and backend sides. Without a load balancing rule, a Load Balancer would have a frontend IP and a backend pool defined, but no instructions on how to actually connect the two, meaning no traffic would be forwarded at all.
Example
A Load Balancing Rule named 'http-rule' is configured to accept TCP traffic on frontend port 80 and forward it to backend port 80 on VMs in the 'web-backend-pool', using the health probe named 'http-probe' to determine which VMs are eligible.
Frontend IP Configuration (within the rule)
Within a load balancing rule, the frontend IP configuration specifies exactly which of the Load Balancer's IP addresses this particular rule applies to, which matters when a Load Balancer has multiple frontend IPs serving different applications. Selecting the correct frontend IP ensures that traffic destined for one application is not accidentally forwarded according to the rules meant for a different application.
(Rule में frontend IP यह बताता है कि यह rule किस IP address पर लागू होगा।)
Backend Pool (within the rule)
Within a load balancing rule, the backend pool selection determines which group of VMs will actually receive the traffic matched by this rule. A single Load Balancer can have multiple backend pools, and different rules can point to different pools, allowing one Load Balancer to serve multiple independent applications.
(Rule में backend pool यह बताता है कि traffic किन VMs तक forward होगा।)
Health Probe (within the rule)
Each load balancing rule must be associated with a health probe, which the Load Balancer uses to determine which VMs in the selected backend pool are currently healthy enough to receive traffic under this rule. Without an associated health probe, the Load Balancer would have no way of knowing whether a backend VM is actually capable of handling requests.
(Rule में health probe यह तय करता है कि backend pool की कौन-सी VMs traffic पाने के योग्य हैं।)
Protocol
The protocol setting in a load balancing rule specifies whether the rule applies to TCP or UDP traffic, and it must match the type of traffic the application actually uses — for example, most web applications use TCP, while some real-time or streaming applications may use UDP. Selecting the correct protocol is essential, because the Load Balancer will only forward traffic that matches the protocol configured in the rule.
(Protocol setting यह define करता है कि rule TCP traffic के लिए है या UDP traffic के लिए।)
Frontend Port
The frontend port is the port number on the frontend IP address that clients use when connecting to the application, such as port 80 for standard HTTP traffic or port 443 for HTTPS traffic. This is the port that external clients need to know and use in order to successfully reach the application through the Load Balancer.
(Frontend Port वह port है जिस पर clients Load Balancer से connect होते हैं, जैसे HTTP के लिए port 80।)
Backend Port
The backend port is the port number on the backend VMs where the actual application is listening for incoming connections, and it does not necessarily have to match the frontend port. This flexibility allows scenarios such as forwarding public-facing traffic on port 80 to an application that is actually running on a non-standard port, like 8080, on the backend VMs.
(Backend Port वह port है जिस पर backend VM पर application actually traffic receive करता है, यह frontend port से अलग भी हो सकता है।)
How Load Balancing Rules Work
When a client sends a request to the frontend IP and port defined in a load balancing rule, the Load Balancer first checks the health probe status of the VMs in the associated backend pool to identify which ones are currently healthy. It then selects one of the healthy VMs, typically using a hash-based algorithm that considers the source and destination IP addresses and ports, and forwards the request to that VM's private IP address on the configured backend port. The response from the backend VM is then routed back to the client, completing the request cycle, and this entire process repeats independently for every new connection that arrives.
(Load Balancing Rule के अनुसार, आने वाला traffic health probe से healthy पाई गई VM को frontend से backend port तक forward किया जाता है।)
The following practical lab provides hands-on experience with Azure Load Balancing. It walks through creating a complete Load Balancer setup, from the frontend IP all the way to verifying traffic distribution across backend VMs.
Objective
To create a fully functional Azure Load Balancer end-to-end — including frontend IP, backend pool, health probe, and a load balancing rule — and to verify that traffic is being successfully distributed across backend Virtual Machines.
Steps
1. Create an Azure Load Balancer
2. Configure Frontend IP
3. Create a Backend Pool
4. Add Virtual Machines to Backend Pool
5. Configure Health Probe
6. Create Load Balancing Rule
7. Test Load Balancer Connectivity
Learning Outcome
After completing this lab, you should be able to independently create an Azure Load Balancer with all four core components configured correctly, and verify that traffic is being distributed across multiple backend Virtual Machines as expected.
(इस Practical को पूरा करने के बाद आप Azure Load Balancer को स्वयं create और configure कर पाएंगे तथा traffic distribution को verify कर सकेंगे।)
Following recommended best practices helps ensure that an Azure Load Balancer deployment remains reliable, secure, and easy to maintain over time. The following points summarize the key best practices to keep in mind while designing and operating a Load Balancer.
Use Appropriate Load Balancer Type
Choosing between a Public and Internal Load Balancer should be based on whether the traffic genuinely needs to come from the internet or should remain entirely within the private network. Using a Public Load Balancer for traffic that should stay internal unnecessarily increases the application's exposure to the internet, so administrators should default to Internal Load Balancers wherever public access is not explicitly required.
(Application की जरूरत के अनुसार सही Load Balancer type — Public या Internal — चुनना जरूरी है।)
Configure Health Probes Properly
Health probes should be configured with realistic intervals and thresholds that balance quick failure detection against the risk of falsely marking a temporarily busy VM as unhealthy. Wherever possible, HTTP or HTTPS probes should be used instead of simple TCP probes, since they validate that the application itself is responding correctly and not just that the network port is open.
(Health Probe को सही interval और threshold के साथ configure करना चाहिए ताकि false failures से बचा जा सके।)
Maintain Multiple Backend Instances
A backend pool should always contain at least two VMs, and ideally more for critical workloads, so that the Load Balancer can continue distributing traffic even if one VM becomes unavailable. Spreading these VMs across different Availability Zones, where possible, further improves resilience against datacenter-level failures.
(Backend Pool में हमेशा कम से कम दो या उससे अधिक VMs रखनी चाहिए ताकि redundancy बनी रहे।)
Monitor Backend Health
Administrators should regularly monitor backend VM health and Load Balancer metrics using Azure Monitor, setting up alerts for scenarios such as a VM being marked unhealthy or the number of healthy backend instances dropping below a safe threshold. Proactive monitoring allows issues to be identified and resolved before they significantly impact end users.
(Azure Monitor के द्वारा backend VMs की health को regularly monitor करना चाहिए।)
Secure Load Balancer Traffic
Traffic reaching the Load Balancer, particularly on a Public Load Balancer, should be restricted using Network Security Group rules that allow only the required ports and protocols, reducing the attack surface of the application. For internet-facing Load Balancers handling sensitive or high-traffic applications, enabling Azure DDoS Protection adds an additional layer of defense against volumetric attacks.
(Load Balancer traffic को NSG rules और आवश्यकता होने पर DDoS Protection के द्वारा secure करना चाहिए।)
Test Load Balancing Configuration
Before relying on a Load Balancer configuration in production, administrators should thoroughly test it by simulating VM failures, verifying that health probes correctly detect the failure, and confirming that traffic is properly redirected to the remaining healthy VMs. Regular testing, especially after making configuration changes, helps catch misconfigurations before they cause an outage.
(Production में उपयोग करने से पहले Load Balancer configuration को failure scenarios के साथ अच्छी तरह test करना चाहिए।)
