Round-robin scheduling gives each eligible resource a turn, then repeats the sequence. With three backend servers, a simple request-level scheduler sends successive requests to A, B, C, A, B, and C. This approach requires little scheduling information and works well when servers have comparable capacity and requests require similar amounts of work. In operating systems, round-robin scheduling commonly means rotating runnable tasks through fixed CPU time slices; in cloud load balancing, it usually means rotating assignments among backend targets rather than preempting their execution.
The unit being scheduled is critical. A request-level load balancer can distribute individual HTTP requests, whereas a connection-level balancer assigns new connections. A long-lived connection can carry substantial traffic while remaining assigned to one backend. Consequently, equal connection counts do not imply equal request counts, bytes transferred, or CPU consumption. Before selecting an algorithm, determine whether the implementation schedules requests, connections, flows, or another unit.
For example, three identical application servers handling short, stateless API requests are reasonable candidates for round-robin distribution. If one request generates a large report while another returns a cached value, equal request counts can still leave one server overloaded. A least-outstanding-requests algorithm can respond to differences in concurrent work, although it does not directly measure CPU utilization. Weighted round robin is a related variation that assigns different shares to resources with different capacities; ordinary round robin gives each eligible resource an equal turn.
In AWS, Application Load Balancer uses round robin as the default target-group routing algorithm. Listener rules first identify the destination target group, and the routing algorithm then selects a target within that group. Classic Load Balancer uses round robin for HTTP and HTTPS listeners, but uses least outstanding connections for TCP listeners. Network Load Balancer uses flow hashing rather than configurable round-robin target selection. Do not infer an algorithm solely from the fact that a product is called a load balancer.
Cross-zone load balancing and round-robin scheduling answer different questions. Cross-zone configuration determines whether a load balancer node can distribute traffic to targets in other enabled Availability Zones; the routing algorithm determines how it selects among eligible targets. Suppose one zone contains two targets and another contains eight. Without cross-zone distribution, an approximately equal traffic split between zones can place much more load on each target in the smaller zone. Round robin within each zone does not correct that imbalance.
Session affinity also changes the effective distribution. A sticky session can keep subsequent requests from one client on the same target instead of repeatedly applying normal target selection. This can support applications with target-local session state, but a few busy clients may create uneven load. Externalizing session state often makes nonsticky distribution easier to operate. Multiple load balancer nodes, changing target membership, and concurrent traffic also mean that production observations need not show one globally strict A-B-C sequence.
High availability requires health checks, sufficient remaining capacity, and targets distributed across failure domains; round robin alone provides none of these. Health checks normally remove unhealthy targets from selection, but service-specific fail-open behavior can change this when all targets are unhealthy. During scale-in or deployments, deregistration draining helps existing work finish. Monitor target response time, errors, active connections, and resource utilization rather than judging balance only by request counts.
Routing algorithms are separate from security and client-address propagation. TLS, security groups, and application-layer protections control exposure and protection, while Proxy Protocol carries connection metadata where supported. Application Load Balancer conveys client information through HTTP headers such as X-Forwarded-For rather than Proxy Protocol. Classic Load Balancer supports Proxy Protocol version 1 for applicable TCP configurations, while Network Load Balancer supports version 2. Configure trusted proxy boundaries correctly; neither round robin nor client-address metadata authenticates a caller.