How can I gracefully drain pods during scale-in on EKS?

Kubernetes does support this, but it is a coordinated shutdown rather than an instant container stop. When a pod begins terminating, it is marked for removal from the Service endpoints, which causes new traffic to stop being routed there. The pod then runs its termination lifecycle, including any preStop hook, receives SIGTERM, and is eventually force-killed when terminationGracePeriodSeconds expires.

In practice, configure the application to stop accepting new work after SIGTERM, give existing requests enough time to finish, and set an appropriate termination grace period. A short preStop delay is often used to give endpoint and load-balancer state time to propagate, but it should be treated as a safety margin rather than the main draining mechanism.

This is not unique to EKS. Older load balancers and other orchestrators have always needed a window between taking an instance out of rotation and stopping its process. Kubernetes generally follows the same pattern, but propagation is asynchronous, so a small race is possible.

Use a sufficiently long terminationGracePeriodSeconds, configure the load balancer's deregistration timeout, and test rolling updates and scale-in under real traffic. If occasional 5xx responses remain, check whether they come from the load balancer, the application closing connections, or the client timing out; those point to different fixes.

For EKS, the exact behavior also depends on how the load balancer integrates with Kubernetes. Readiness gates, endpoint removal, target registration mode, and the load balancer's deregistration delay all matter. Make sure the pod is not considered ready once shutdown starts, and verify that the load balancer waits for existing connections to drain.

Also make sure the application handles SIGTERM correctly. If it exits immediately, no amount of load-balancer configuration can protect requests that are already being processed.