Session affinity changes how a load balancer distributes successive requests. Without affinity, each request can be assigned independently using the configured routing algorithm. With affinity, the load balancer identifies a returning client or session and attempts to reuse its previous backend assignment. This is useful when an application stores information such as a shopping cart, login workflow, or temporary processing context in a server's memory.
Consider a legacy web application running on three virtual machines. A user logs in through the first machine, which stores the user's session locally. If the next request reaches the second machine, the application might treat the user as unauthenticated. Cookie-based affinity can keep that browser's requests on the first machine. However, the routing cookie normally identifies an assignment; it does not copy the application's session data to other machines.
Common implementations use cookies or the client's source IP address. Cookie-based affinity works at the HTTP application layer and can distinguish browsers that share a public IP address. Source-IP affinity can support traffic where HTTP cookies are unavailable, but many users behind a corporate proxy or network address translation gateway may appear to be one client. Changing client IP addresses can also change the backend assignment. Choose the load-balancing layer and affinity mechanism based on the application's protocol and client behavior.
In AWS, an Application Load Balancer supports target-group stickiness using load-balancer-generated cookies or application-based cookies. A Network Load Balancer offers source-IP stickiness for supported configurations rather than HTTP-cookie stickiness. These are different mechanisms, not interchangeable settings. Maintaining one TCP connection on one target is also different from maintaining affinity across multiple connections. Similarly, an established WebSocket connection naturally remains with its selected target; reconnecting is a separate routing event.
Affinity introduces a trade-off between continuity and balanced resource utilization. A few busy sessions can overload particular targets while others have spare capacity. Adding servers does not immediately redistribute existing sticky sessions, so scaling out may provide less immediate relief than expected. Affinity duration should reflect the actual need, and engineers should monitor per-target request counts, latency, resource utilization, and errors rather than relying only on fleet-wide averages.
Affinity is not a high-availability mechanism. When a target fails or is removed, subsequent requests may be assigned elsewhere, and locally stored session state may be lost. Health checks, multi-zone deployment, graceful deregistration, and application recovery behavior remain necessary. Connection draining can help active requests finish during planned removal, but it does not transfer in-memory sessions.
For scalable, loosely coupled designs, prefer interchangeable application targets with session data in a shared, appropriately resilient store, or use securely designed client-held session state. For example, storing a cart in a database allows any healthy application instance to serve the next request. In architecture questions, choose affinity when requests explicitly need the same backend, but do not mistake it for session replication, durable storage, or automatic fault tolerance.
Amazon ElastiCache