The AWS outage and the role of load balancing
How load balancing distributes requests, what health checks verify, and why several servers can still share a single point of failure.
in this article
An application can have several servers and remain vulnerable to a single failure. If they all depend on the same service to resolve addresses, create capacity, or receive traffic, that dependency limits recovery.
The outage
In October 2025, DynamoDB DNS failed in us-east-1. EC2 recovery accumulated networking delays. NLB health checks subsequently removed healthy capacity from service. AWS's incident report describes that sequence.
The distinction matters. The initial version of this article attributed the start of the outage to load balancer monitoring. The subsequent report lets us correct that explanation.
To understand load balancing's role in that chain, start with what it does in an ordinary application.
What is load balancing?
Imagine a restaurant with one cashier. If 50 people arrive together, a queue forms. Opening more registers allows the work to be shared, provided someone organizes the distribution.
Load balancing distributes traffic across servers. In a web application, the balancer receives requests and selects a destination from those available. Distribution reduces the concentration of work on one machine, but does not create unlimited capacity.
How it works
A request can take this path:
[User] → [Load balancer] → [Server 1]
→ [Server 2]
→ [Server 3]
→ [Server 4]
The application needs to support that distribution. If a user's session exists only in one server's memory, the next request sent elsewhere may not find it. Choosing where to store state is part of the architecture.
Distribution strategies
Round robin alternates destinations in sequence. Least connections favors the server with fewer active connections. The choice depends on the traffic. A long connection does not represent the same amount of work as a short response.
Weights allow different proportions of traffic to reach servers with different capacities. Some strategies use the client's IP address to maintain affinity with a destination. Geographic routing makes another decision, choosing the region that receives traffic. Available options depend on the balancer.
Health checks
Health checks periodically test destinations against defined criteria. AWS Application Load Balancer uses intervals and success or failure thresholds to determine state changes. Removal is not immediate. See its health check documentation.
What the check asks matters, too. An endpoint that always reports success can miss a process unable to handle orders. At the other extreme, requiring every external service to work before passing a check can remove servers still capable of useful work.
Why use a balancer?
It lets you add servers and distribute new requests among them. It also helps with maintenance. You can stop sending new requests to a destination and let existing work finish before shutting it down.
When one server fails, the others can receive new requests. They need spare capacity to do that. If four machines already operate at their limit, losing one increases pressure on the rest.
Distribution does not automatically transfer an operation that was already running. The application needs to define what the user sees and whether a retry can happen without duplicating effects.
The domino effect
The four servers in the diagram might hide one database, one queue, or shared configuration. Repeating the servers does not duplicate those dependencies.
Our operational takeaway is to test recovery while a dependency is unavailable. Creating more instances during a failure only helps if the creation path still works. Sending everything to the remaining destinations likewise requires knowing how much work they can handle.
What to test in your application
Remove a server from service in a controlled environment and observe requests already running. Then check whether the remaining destinations handle the load and how long monitoring takes to detect the change.
Test a slow dependency as well. Record when the application stops waiting, how many retries it makes, and how it prevents those retries from growing the queue indefinitely.
The balancer handles traffic distribution. Application availability also depends on these decisions. Talk to Tucupy if you need to review how your system responds to failures.
Revised September 12, 2026, to correct the incident explanation.