Connection draining makes backend removal a coordinated transition rather than an immediate disconnection. A load balancer or proxy stops selecting a retiring backend for new work, while eligible in-flight requests or established connections continue for a bounded period. Once that work completes, or the configured deadline expires, the backend can be removed and its compute resources terminated. The precise unit being drained depends on the protocol and implementation: an HTTP request, a TCP connection, and a long-lived streaming session have different completion boundaries.
In an automatically scaled application, draining is especially important during scale-in. Adding capacity usually introduces new healthy targets; removing capacity risks interrupting users already being served. A safe removal sequence withdraws the selected target from new traffic, keeps its application and network path available while outstanding work finishes, and then terminates it. Maintain enough healthy capacity on the remaining targets to absorb the redistributed traffic. During rolling deployments, register and validate replacement capacity before withdrawing old targets when availability requirements demand it.
For example, consider an API whose normal requests finish within two seconds but whose report downloads sometimes take ninety seconds. Immediately terminating an instance selected for scale-in can break those downloads. A draining window longer than the expected download duration can let them finish, provided application shutdown and other infrastructure timeouts do not end the connection first. Set the window using observed request durations and operational requirements rather than assuming that a default value fits every workload.
AWS implements this concept through connection draining on Classic Load Balancers and target-group deregistration delays on Application Load Balancers and Network Load Balancers. With an attached load balancer, Amazon EC2 Auto Scaling deregisters a terminating instance and waits for the applicable deregistration process before terminating it. Lifecycle hooks can provide additional coordination for application cleanup or other shutdown work, but they do not replace load-balancer draining. Applications must remain capable of serving outstanding work throughout the relevant interval.
Draining is bounded protection, not a guarantee that every session will finish. WebSocket connections, streaming RPCs, and other persistent sessions may outlive any practical draining window. Such applications need reconnect behavior, resumable operations, or application-level notifications that encourage clients to move. Whether connections are forcibly terminated when a timer expires is implementation-specific; Network Load Balancer connection-termination settings, for example, affect this behavior.
A longer window reduces the chance of interrupting slow work but can delay scale-in, resource release, and deployments. A shorter window improves replacement speed but increases the risk of resets, partial responses, and retries. Draining is not the same as an idle timeout, session stickiness, or a health check. It does not migrate a live connection to another backend, and an unexpected crash cannot be drained gracefully. Validate the complete shutdown sequence under load, monitor errors and active connections, and make retries safe through idempotent operations where appropriate.
Amazon EC2 Auto Scaling