Project Report

LOAD BALANCING ALGORITHMS USED IN DATA-CENTER NETWORKING

Abstract - This project focuses on analyzing and comparing the performance of three load balancing algorithms—Round Robin (RR), Least Outstanding Requests (LOR), and Flow Hash (FH) in a real deployment on a cloud-based environment using Amazon Web Services (AWS). The implementation involved deploying EC2 instances, Application Load Balancers (ALB), and a Network Load Balancer (NLB). The use of JMeter as an HTTP traffic generator, along with tools such as CloudWatch, provided sufficient data for analysis. Three test scenarios were evaluated: normal traffic, stress testing, and fault tolerance. Metrics such as request count, latency, CPU usage, and error rate were analyzed. The results showed practical differences between the algorithms and demonstrated the educational value of implementing and testing real cloud services.

Introduction

PROBLEM STATEMENT AND JUSTIFICATION

Datacenter networks offer scalability, flexibility, and cost efficiency by allowing services to be deployed on instances without requiring physical infrastructure. These virtual machines can dynamically adjust their capacity based on real-time demand, significantly reducing deployment time and improving responsiveness. In this context, load balancing plays a critical role in ensuring that traffic is evenly distributed across available instances, optimizing performance, maintaining service availability, and preventing any single server from becoming a bottleneck.

While major cloud providers such as AWS (Amazon Web Services), Google Cloud Platform (GCP), and Microsoft Azure offer built-in load-balancing solutions, they generally rely on algorithms like Round Robin, Least Connections, or IP Hash. These algorithms are preferred in large-scale, multi-tenant environments due to their ease of implementation and predictable behavior.

Although these default algorithms are effective in many scenarios, they typically do not make traffic distribution decisions based on backend load. Instead, they rely on the surrounding infrastructure, such as health checks and auto-scaling mechanisms, to react to changes in availability. This opens the opportunity to explore how more adaptive algorithms, such as Least Outstanding Requests (LOR), behave under conditions that simulate realistic operational challenges.

This project was inspired by the need to better understand how different load-balancing algorithms behave under realistic data center conditions. By leveraging AWS infrastructure, we implemented a test environment to evaluate and compare the performance of three common algorithms: Round Robin, Least Outstanding Requests (LOR), and Flow Hash, using metrics collected from both the client side and, more importantly, from the cloud infrastructure side. Our work was also guided by the research paper “Load Balancing in Data Center Networks: A Survey” [1], which provides a broad overview of existing load balancing strategies and underscores the importance of further evaluation, especially in real-world and large-scale data center environments.

OBJECTIVES

The main objective of this project is to analyze and compare the performance of three widely used load balancing algorithms: Round Robin (RR), Least Outstanding Requests (LOR), and Flow Hashing (FH) within a cloud-based data center environment on Amazon Web Services (AWS) [2].

The specific objectives of this project are:

• To evaluate and compare the latency, load distribution, fault tolerance, failure recovery, and resource utilization of each algorithm.

• To observe how these algorithms behave under different traffic conditions, including normal load, stress testing, and failover scenarios.

• To identify the advantages and limitations of each algorithm when applied to typical cloud-based data center applications.

• To provide a practical and metrics-based perspective that can help understand how these algorithms perform beyond theoretical assumptions.

RELATED WORK

Nandal, Singh, Bura, and Kumar [3] analyzed several load-balancing algorithms such as Round Robin, Equally Spread Current Execution, and Throttled. Their study used a simulation tool called CloudAnalyst to evaluate the performance of these algorithms in terms of response time and cost. While this approach provides valuable insights in a controlled environment, the study does not explore the use or implementation of these algorithms on any real cloud provider, which limits the practical validation of the results.

Prity and Hossain [13] provide a clear explanation of the relevance of cloud computing and describe different types of algorithms used for load balancing, including a brief explanation of each one.

The article also analyzes key performance metrics such as response time, resource utilization, fault tolerance, and others.

In addition, the authors highlight commonly used simulation tools like CloudSim and CloudAnalyst, which are popular among researchers for testing load-balancing strategies.

Nevertheless, this work provides valuable guidance on the metrics and criteria that we considered when designing and evaluating our experiments.

METHODOLOGY

APPROACH.

This project involved the deployment of cloud-based load balancers on Amazon Web Services (AWS) to assess the performance of three algorithms: Round Robin (RR), Least Outstanding Requests (LOR), and Flow Hashing. Traffic generation and performance testing were conducted using Apache JMeter, which simulated concurrent client requests across different scenarios, including normal load, high demand, and failover conditions.

The performance evaluation was based on key metrics collected from JMeter and AWS CloudWatch, specifically latency, throughput, error rate, resource utilization, and failure recovery. These metrics enabled a practical and comparative analysis of the selected algorithms under realistic operating conditions within a cloud-based data center environment.

ARCHITECTURE.

DESIGN THE TEST SCENARIO.

The design of the test scenario has been structured to ensure an evaluation of the existing load-balancing algorithms within a data-center networking environment and to consider the available credits or resources in the AWZ cloud.

Zone selection.

The initial step involved selecting the appropriate AWS region and availability zones. According to AWS documentation, the United States (N. Virginia) "us-east-1" region was chosen primarily for its cost-effectiveness, broader service availability, and better compatibility with AWS Free Tier benefits, making it the most suitable option for the project.​

Lower Free Tier and On-Demand Costs: AWS provides the most cost-effective pricing in us-east-1, making it ideal for deploying non-critical academic testing without unnecessary expenses [4].

Broader Service Availability: The US-east-1 region offers a complete range of AWS services, ensuring that testing load balancers and monitoring can deploy without potential setbacks due to a lack of functionalities or support [5]. ​

Zones including Canada (Central) and US West (Oregon), despite their geographical proximity, suffer from limited service availability and elevated resource pricing [6]

Testing Virtual Machines (VMs)

Amazon Elastic Compute Cloud (EC2) enables users to deploy virtual machines tailored to specific workload requirements within the AWS cloud. As part of the AWS Free Tier, 750 hours per month of free usage are available for eligible EC2 instances such as the “t2.micro” instance which has the following technical specifications [7]:

Name	vCPUs	RAM (GiB)
t2.micro	1	1

Figure. EC2 Instance Type (t2.micro) - Source: AWZ Cloud Manager (Free Tier Account)

EC2 VM deployment testing scenario.

The deployment testing scenario includes:

• One EC2 (t2.micro) instance is dedicated to traffic generation, which simulates user requests (HTTP) to evaluate the performance of the different types of Load balancers.

• Three EC2 (t2.micro) instances function as backend servers behind different types of AWS Load Balancers.

Both types of VMs will be running on Ubuntu Server 24.04 OS Image, which is also part of the free tier offered by AWZ.

Figure. Amazon Machine Image (Ubuntu Server) - Source: AWZ Cloud Manager (Free Tier Account)

In the AWS cloud model, each Availability Zone is treated as a separate physical data center, so these instances were distributed across two Availability Zones within a single AWS region to simulate a realistic scenario, where client requests originate from a different location than the backend servers, which are typically hosted in a data center.

• AWZ Load Balancer deployment testing scenario.

To evaluate the selected load-balancing algorithms in a real-world setting, each was implemented using native AWS Elastic Load Balancing (ELB) services. Round Robin and Least Outstanding

Requests (LOR) were deployed through the Application Load Balancer (ALB), while Flow Hashing was tested using the Network Load Balancer (NLB).

Load Balancer Type on AWZ	Load Balancing Algorithm	Layer - Traffic
Application Load Balancer (ALB)	Round Robin (RR)	Layer 7 - HTTP/HTTPS
Application Load Balancer (ALB)	Least Outstanding Requests (LOR)	Layer 7 - HTTP/HTTPS
Network Load Balancer (NLB)	Flow Hashing (FH)	Layer 4 - TCP/UDP

Table. ELB Load Balancer Types Implemented in AWS [8]

• Testing App Tools.

• Apache JMeter V 5.6.3.

  The traffic generator VM runs Apache JMeter to simulate concurrent requests and test the performance of the different load balancers in distributing traffic among backend instances.

To control the load of HTTP traffic [9], the following parameters were used:

• Number of Threads: Represents the number of simultaneous users.

• Ramp-Up Period: The time taken to start all threads gradually, preventing a sudden spike in traffic.

• Test Duration: Specifies how long the test runs.

• Constant Timer: Introduces a short delay between requests to simulate realistic user behavior.

• HTTP Server – NGINX

  NGINX application running on Ubuntu EC2 VMs, serving as the backend web servers for handling incoming requests.

• Amazon CloudWatch for Performance Monitoring

  AWS CloudWatch was used to collect infrastructure-level metrics during the tests. CloudWatch provided real-time visibility into how the load balancers interacted with backend servers under varying traffic conditions, allowing for a comprehensive evaluation of algorithm behavior from the infrastructure perspective [10].

The deployed scenario on the AWZ cloud is shown in the following diagram:

Figure. Architecture Design Project Diagram

The traffic generator EC2 using Apache JMeter and running on Ubuntu OS was deployed on the Availability Zone (AZ) “us-east-1-a”, while the HTTP Backend servers were deployed on the AZ “us-east-1-c”.

The connectivity of EC2 and the load balancer was performed using two Security Groups, which are considered logic firewalls in AWZ cloud, allowing inbound traffic for SSH (remote management) and HTTP (testing traffic). Every EC2 instance has a public IP for management and a private IP for internal traffic, which will be used for the testing scenario.

3.3 LOAD TESTING IMPLEMENTATION

To evaluate the performance of each load balancing algorithm under different operating conditions, three distinct test scenarios were designed and executed: normal load, stress load, and failure tolerance. These scenarios aimed to reflect typical situations encountered in cloud-based data center environments.

• Normal Load Scenario

This scenario simulated typical traffic using a moderate and constant number of HTTP requests generated by Apache JMeter. All backend instances remained active, allowing us to measure how each algorithm distributes traffic under stable conditions.

Baseline Test (Single EC2 Instance - No Load Balancer):

An initial load of 400 concurrent users was selected as the baseline to simulate a realistic medium-scale traffic scenario. This value was determined through progressive load testing using a single EC2 instance without a load balancer.

JMeter was configured with 400 users during this baseline test, and the results showed a maximum throughput of approximately 742 requests per second and a minor error rate of 0.02%, mostly caused by timeouts.

JMeter CLI console (showing response times and throughput)

These results confirmed that a single instance became a performance bottleneck under increased concurrency. Therefore, 400 users were established as a reasonable starting point for evaluating how each load-balancing algorithm distributes traffic and mitigates performance degradation.

• Stress Load Scenario

The stress scenario involved generating a high volume of concurrent requests in a short period to simulate sudden spikes in traffic. This test evaluated the algorithms’ ability to maintain performance and stability under heavy load.

• Failure Tolerance Scenario

To simulate a backend failure, one of the EC2 instances was manually stopped during an active test. This allowed for the observation of how each algorithm responds to changes in instance availability and redistributes traffic.

The following table summarizes the JMeter configuration parameters used to simulate the

scenarios for the evaluated load-balancing algorithms.

Table. JMeter Load Test Parameters for Each Scenario

3.4 LOAD BALANCING TESTING IMPLEMENTATION

The previous phase for configuring load balancers in AWS is explained as follows:

• Target Group Configuration: The target group is a logical grouping of the backend servers to which the load balancer distributes traffic. At this stage, the network designer must register all instances that will receive the traffic. In the case of the Application Load Balancer (ALB), it is also possible to choose the routing algorithm Round Robin (default) or Least Outstanding Requests.

• Security Group Configuration: In this step, it is possible to define routing rules based on protocol and port number to control incoming and outgoing traffic to the instances in the virtual network.

Load Balancer Components:

• Load Balancer: Acts as the front-facing entry point that receives client requests and distributes them to the registered target servers.

• Listener: A component that listens for incoming requests on a specific protocol and port, and forwards them to the appropriate target group based on the defined rules.

• Target Group: A set of backend resources (such as EC2 instances) that receive the traffic routed by the load balancer.

The final stage of the AWS implementation involves the configuration of CloudWatch, which is AWS's monitoring tool used to visualize various metrics from virtual network components such as EC2 instances and Load Balancers.

In CloudWatch, it is possible to design custom dashboards or use the default ones provided by AWS. For this experiment, we created custom dashboards to visualize the most relevant metrics for our performance analysis.

Application Load Balancer Metrics [10]:

• Target Response Time: Measures the time between when the load balancer sends a request to a target and when the target server starts to respond.

• Request Count: Indicates the number of incoming requests received by the load balancer to be distributed across the registered target servers.

• HTTP_Code_Target_2XX_Count: Represents the number of successful HTTP responses (2XX codes) returned by the destination servers, helping validate that requests were completed correctly.

• HTTP_Code_Target_5XX_Count: Represents the number of unsuccessful HTTP responses (5XX codes) returned by the destination servers, helping validate that requests were completed with errors.

• Healthy Host Count: Helps assess fault tolerance by showing the number of healthy backend instances over time. This metric allows us to pinpoint the start and end times of a failure scenario.

Network Load Balancer Metrics [11]:

• NewFlowCount: Indicates the number of new flows received by the load balancer. In the context of Flow Hash, this is especially useful to evaluate how traffic is routed to backend servers.

• Healthy Host Count: Also used here to monitor the status of backend instances and evaluate how each algorithm reacts to failures during the fault tolerance test.

EC2 Instance Metrics:

• CPU Utilization, Network In, and Network Out: These metrics allow us to analyze how resources are distributed across the target instances.

They help evaluate how each algorithm balances the processing load and traffic among the available servers.

IV. PERFORMANCE ANALYSIS

The first stage of the performance analysis is to fully understand each load balancing algorithm used in AWS, including Round Robin, Least Outstanding Requests, and Flow Hash. A brief explanation of each is provided below:

• Round Robin (RR): The load balancer receives client requests and distributes them sequentially to each target server. This algorithm does not take into account the current load or performance of the destination servers. It simply cycles through the targets in order, restarting the sequence once all have received a request.

• Least Outstanding Requests (LOR): This algorithm routes new requests to the target server with the fewest active (in-progress) requests. It is particularly useful when destination servers have different processing capacities, as it helps distribute the load more evenly based on real-time usage.

• Flow Hash (FH): This algorithm routes each incoming flow based on a hash generated from the protocol, source and destination IP addresses, and source and destination ports. This results in consistent routing for each flow.

If the target stickiness feature is enabled, Flow Hash ensures that all connections from the same client are consistently routed to the same backend target. This behavior helps maintain session persistence and reduces the overhead associated with establishing new connections.

4.1. Scenario 1 – Normal Traffic:

The results of the metrics for this scenario are summarized as follows:

Client Perspective (JMeter Metrics):

Metrics – JMeter Instance	RR – 400 Users	LOR – 400 Users	FH – 400 Users
Total Requests	221.015	220.817	221.074
Average Throughput (req/s)	392	392-401	360-400
Peak Throughput (req/s)	400	404	400
Total Errors – Error Rate	0 – 0%	0 – 0%	0 – 0%

The following graphs illustrate the performance of the three load-balancing algorithms under normal load conditions. They show how JMeter-generated traffic was handled by the AWS load balancers (ALB for RR and LOR, NLB for Flow Hash) and distributed across the backend instances. These results help assess each algorithm’s ability to maintain stable throughput, balanced load distribution, and consistent response times when all instances are healthy and traffic is moderate.

Round Robin – Performance Under Normal Load Conditions (Client Perspective)

Average Response Time (ms)

Throughput (requests/second)

Least Outstanding Requests – Performance Under Normal Load Conditions (Client Perspective)

Average Response Time (ms)

Throughput (requests/second)

Flow Hash– Performance Under Normal Load Conditions (Client Perspective)

Average Response Time (ms)

Throughput (requests/second)

Load Balancer Perspective (AWZ Cloud Watch Metrics):

Metrics – AWZ Cloud Watch	RR – 400 Users	LOR – 400 Users	FH – 400 Users
Request Count (ALB) / Active Flow Count (NLB)	221.015	220.817	221.075
Max Target Response Time (ms)	170	6	-
HTTPCode_ELB_5XX_Count (ALB) – Error Rate	0 - 0%	0 - 0%	-
Max CPU Utilization - Load JMeter Instance	31,7%	29,3%	32.5%
Max CPU Utilization - NGINX Backend Servers	BE#1: 9.22% BE#2: 9.21% BE#3: 8.66%	BE#1: 9.57% BE#2: 9.04% BE#3: 9.00%	BE#1: 14.80% BE#2: 13.88% BE#3: 12.07%

Figure. CPU Utilization for the Round Robin Algorithm under the Normal Scenario [12]

Figure. CPU Utilization for the Least Outstanding Request Algorithm under the Normal Scenario [12]

Figure. CPU Utilization for the Flow Hash Algorithm under the Normal Scenario [12]

Comparative Analysis:

In this scenario, the three algorithms show similar results in key metrics such as a 0% error rate and balanced CPU utilization across the destination HTTP servers. Flow Hash shows a slight increase in CPU usage compared to the others.

4.2. Scenario 2 – Stress Scenario:

The results of the metrics for this scenario are summarized as follows:

Client Perspective (JMeter Metrics):

Metrics – JMeter Instance	RR – 1000 Users	LOR – 1000 Users	FH – 1000 Users
Total Requests	1.398.938	1.511.783	1.611.000
Average Throughput (req/s)	1150-1500	1200-1300	1800-1900
Peak Throughput (req/s)	1716	1500	1711
Total Errors – Error Rate	0 – 0%	640 – 0.04%	143 – 0.01%

The following graphs show how the three algorithms performed under high traffic conditions. JMeter was used to generate a sudden spike in concurrent requests. They show how each load balancer handled the load and help compare throughput, latency, and overall stability under stress.

Round Robin – Performance Under Stress Conditions (Client Perspective)

Average Response Time (ms)

Throughput (requests/second)

Least Outstanding Requests – Performance Under Stress Load Conditions (Client Perspective)

Average Response Time (ms)

Throughput (requests/second)

Flow Hash– Performance Under Stress Conditions (Client Perspective)

Average Response Time (ms)

Throughput (requests/second)

Load Balancer Perspective (AWZ Cloud Watch Metrics):

Metrics – AWZ Cloud Watch	RR – 1000 Users	LOR – 1000 Users	FH – 1000 Users
Request Count (ALB) / Active Flow Count (NLB)	1.398.938	1.511.783	1.610.867
Max Target Response Time (ms)	244	36	-
HTTPCode_ELB_5XX_Count (ALB) – Error Rate	0 – 0%	640 – 0.04%	-
Max CPU Utilization - Load JMeter Instance	72,31%	75,76%	77.59%
Max CPU Utilization - NGINX Backend Servers	BE#1: 17,48% BE#2: 16,75% BE#3: 16,34%	BE#1: 89,49% BE#2: 51,86% BE#3: 18,85%	BE#1: 32,99% BE#2: 32,01% BE#3: 31,68%

Figure. CPU Utilization for the Round Robin Algorithm under the Stress Scenario [12]

Figure. CPU Utilization for the Least Outstanding Request Algorithm under the Stress Scenario [12]

Figure. CPU Utilization for the Flow Hash Algorithm under the Stress Scenario [12]

Comparative Analysis:

This scenario reveals the following findings:

• Flow Hash continues to be the algorithm that handles the highest number of requests and maintains relatively balanced CPU usage across its backend servers (around 32% each).

• Least Outstanding Requests showed the highest error rate (0.04%) and a clear overload on one backend server with a peak CPU utilization of 89%. All backend servers had the same capacity, so this behavior might mean that when the system is under high load, LOR does not share the traffic evenly. It may send too many requests to one server.

• Round Robin maintained a consistent and balanced CPU usage across its backend servers, all staying below 18%. It also had no errors, indicating good stability. However, it exhibited the highest peak target response time (244 ms), suggesting that despite its simplicity, this algorithm may not optimize for latency under heavy load.

• Overall, each algorithm presents trade-offs: Flow Hash maximizes throughput, LOR struggles with backend imbalance, and Round Robin favors stability at the cost of response time. These insights are key when selecting a load-balancing strategy aligned with specific application needs.

4.3. Scenario 3 – Fault Tolerance Scenario

The results of the metrics for this scenario are summarized as follows:

Client Perspective (JMeter Metrics):

Metrics – JMeter Instance	RR – 1000 Users (Failure)	LOR – 1000 Users (Failure)	FH – 1000 Users (Failure)
Total Requests	1.485.555	1.548.454	1.761.631
Average Throughput (req/s)	1.200-1.600	1.200-1.300	600-1.900
Peak Throughput (req/s)	1.711	1.686	1.988
Total Errors – Error Rate	7.425 – 0.50%	1.950 – 0.13%	331 – 0.02%

The following graphs show how the three algorithms responded to a backend instance failure. During the test, one EC2 instance was manually stopped to simulate failure. They show the algorithm’s ability to detect failure, redistribute traffic, and maintain performance.

Round Robin – Performance Under Fault Conditions (Client Perspective)

Throughput (requests/second)

Least Outstanding Requests – Performance Under Fault Conditions (Client Perspective)

Average Response Time (ms)

Throughput (requests/second)

Flow Hash– Performance Under Fault Conditions (Client Perspective)

Average Response Time (ms)

Throughput (requests/second)

Load Balancer Perspective (AWZ Cloud Watch Metrics):

Metrics – AWZ Cloud Watch	RR – 1000 Users (Failure)	LOR – 1000 Users (Failure)	FH – 1000 Users (Failure)
Request Count (ALB) / Active Flow Count (NLB)	1.485.590	1.548.474	1.761.324
Max Target Response Time (ms)	17	222	-
HTTPCode_ELB_5XX_Count (ALB) – Error Rate	7.413 – 0.50%	1.950 – 0.13%	-
Max CPU Utilization - Load JMeter Instance	76,33%	76,49%	81.63%
Max CPU Utilization - NGINX Backend Servers	BE#1: 17,77% BE#2: 21,00% BE#3: 19,91%	BE#1: 19,45% BE#2: 21,09% BE#3: 21,85%	BE#1: 35,93% BE#2: 38,43% BE#3: 39,13%

Figure. CPU Utilization for the Round Robin Algorithm under the Fault Tolerance Scenario [12]

Figure. CPU Utilization for the Least Outstanding Request Algorithm under the Fault Tolerance Scenario [12]

Figure. CPU Utilization for the Flow Hash Algorithm under the Fault Tolerance Scenario [12]

Comparative Analysis:

This scenario shows the following results:

• Flow Hash again processed the highest number of requests. It also handled the failure event with the lowest error rate of only 0.02%, which shows good fault tolerance.

• Least Outstanding Requests had a much higher target response time (222 ms), but still managed the failure quite well, with a low error rate of 0.13%.

• Round Robin had a noticeable increase in errors, reaching the highest error rate in this scenario (0.50%). However, its strength was the target response time, which stayed low at 17 ms, even during the fault.

V. LIMITATIONS AND FUTURE WORKS

Due to the goal of collecting real metrics from a real implementation of load balancing on a commercial cloud provider such as AWS, while also aim to minimize the costs associated with the use of virtual resources like VMs, Load Balancers, and CloudWatch the Free Tier option was selected as a practical solution for this project.

Unfortunately, this option only allows the use of specific types of virtual machines, which limits the flexibility and scalability of the experimental setup.

Future improvements to this project include:

• Including scenarios with heterogeneous backends, rather than only homogeneous ones.

• Adding the auto-scaling feature to evaluate how it affects system performance under varying workloads.

• Incorporating tools such as CloudAnalyst to compare the results from AWS CloudWatch with those generated by simulation, providing an additional layer of analysis through modelling and report generation.

VI. CONCLUSION

This project evaluated the performance of three load balancing algorithms: Round Robin (RR), Least Outstanding Requests (LOR), and Flow Hashing (FH), deployed on AWS cloud infrastructure under realistic traffic scenarios. The analysis was based on key performance metrics such as latency, throughput, error rate, and fault tolerance, collected using Apache JMeter and AWS CloudWatch.

• Under normal traffic, the three algorithms performed similarly in overall throughput. However, LOR consistently showed the lowest latency, while Flow Hash had slightly higher backend CPU usage, and Round Robin remained stable with no errors.

• In the stress scenario, LOR demonstrated the most balanced performance by maintaining low response times and recovering quickly from traffic spikes. While Flow Hash handled a larger number of requests, it did so with significantly higher latency. Round Robin showed no errors but had the slowest response times, confirming its limitations under heavy load.

• During backend failure, both LOR and FH demonstrated better adaptability and recovery behavior. LOR quickly redirected traffic and maintained stable performance. FH also adapted well but temporarily routed traffic to the failed instance, causing brief timeouts. Round Robin was the slowest to recover, with increased latency and error rate during the failure window.

Finally, combining client-side and infrastructure-side metrics offered a more complete and accurate view of how each algorithm truly behaves in a production-like setting. The results reinforce the importance of selecting the right load-balancing strategy based on real application needs rather than relying on default configurations.

In summary, while all three algorithms are effective in certain scenarios, LOR offers the most balanced and adaptive performance, especially under changing network conditions.

VII. REFERENCES.

[1] Zhang, J., Yu, F. R., Wang, S., Huang, T., Liu, Z., & Liu, Y. (2018). Load Balancing in Data Center Networks: A Survey. IEEE Communications Surveys and Tutorials, 20(3), 2324–2352. https://doi.org/10.1109/COMST.2018.2816042.

[2] Amazon Web Services, “What is Load Balancing?,” AWS Documentation, 2024. [Online]. Available: https://aws.amazon.com/what-is/load-balancing.

[3] Nandal, P., Singh, M., Bura, D., & Kumar, S. (2021). Analysis of Different Load Balancing Algorithms in Cloud Computing. International Journal of Cloud Applications and Computing, 11(4), 100–112. https://doi.org/10.4018/IJCAC.2021100106

[4] Amazon Web Services. "COST07-BP02 Choose Regions Based on Cost." AWS Well-Architected Framework,2025.https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_pricing_model_region_cost.html

[5] Amazon Web Services, "AWS Services by Region", 2025. https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/.

[6] E. Márquez, "Choose-your-aws-region-wisely" Concurrency Labs, 2024. https:// www. Concurrency labs.com/blog/ choose-your-aws-region-wisely

[7] Amazon Web Services, "T2 Instances," AWS Documentation, 2025. https://aws.amazon.com/ec2/instance-types/t2/.

[8] Amazon Web Services, Elastic Load Balancing – Network Load Balancer, Mar. 2025. [Online]. Available: https://aws.amazon.com/elasticloadbalancing/network-load-balancer/

[9] Apache Software Foundation, Apache JMeter User Manual, Mar. 2025. [Online]. Available: https://jmeter.apache.org/usermanual/component_reference.html

[10] Amazon Web Services, Application Load Balancer CloudWatch Metrics, Mar. 2025. [Online]. Available: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html

[11] Amazon Web Services, Network Load Balancer CloudWatch Metrics, Mar. 2025. [Online]. Available: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html

[12] AWS Free Tier Account Console:

https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#dashboards/dashboard/Final_ALB?start=2025-04-01T03%3A00%3A00Z&end=2025-04-01T03%3A30%3A00Z

[13] Prity, F. S., & Hossain, Md. M. (2024). A comprehensive examination of load balancing algorithms in cloud environments: a systematic literature review, comparative analysis, taxonomy, open challenges, and future trends. Iran Journal of Computer Science (Online), 7(3), 663–698. https://doi.org/10.1007/s42044-024-00183-y

VIII. APPENDIX

8.1 Project Deliverables

Project deliverables include regular updates on a public website and a final report. The final report will provide details regarding the implemented architecture, testing implementation, comparative analysis, and metric performance.

8.2 Member Contributions

The authors' main contributions are outlined as follows:

• The Abstract, Section II, Section IV (Load Balancer Perspective), and Section V were mainly written by Nelson Gomez Bohorquez.

• Section I, Section III, and Section IV (Client Perspective (JMeter)) were primarily written by Gabriel Naranjo Orozco.

• Both members contributed equally to Section IV (Performance Analysis). Gabriel focused on the Client Perspective through JMeter metrics across all three scenarios (Normal Load, Stress Load, and Failure Tolerance), while Nelson focused on the Infrastructure Perspective using CloudWatch metrics.

• The conclusions were drafted collaboratively, incorporating both perspectives to align with the project objectives.

• Additionally, both members contributed evenly to the Project Proposal, Bi-Weekly Updates, Project Implementation, and the final organization of the report.