- Newest
- Most votes
- Most comments
This behavior occurs because NLB's idle timeout only tracks data transfer - it doesn't consider a TCP connection "idle" if it's just sitting there with no data flowing. The idle timeout counter only starts when data stops flowing through an active connection.
Here's the key detail: TCP keepalives that maintain the TCP connection state operate at a lower network layer than where NLB's idle timeout mechanism works. So you can have a persistent TCP connection that stays open indefinitely even with a configured idle timeout, as long as no application data is ever sent.
To actually force closure of truly idle connections, you'll need to:
- Either implement application-level keepalive messages to trigger the idle timeout
- Or handle connection cleanup at the target instance level using OS-level TCP timeout settings
This is a somewhat counterintuitive aspect of NLB's idle timeout implementation that catches many users by surprise. The documentation could be clearer about this behavior.
see this documentation and blog post for more info. https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-configurable-idle-timeout-for-connection-tracking/
Right, you can close idle connections or use connection pool mechanism instead. you can set TCP keepalive settings in /etc/sysct.conf file. Here is a sample for linux. net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_intvl = 10 net.ipv4.tcp_keepalive_probes = 6
Also you can programmatically enable TCP keepalives for your connections. For example python sample below. import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
The "issue" that we are seeing is probably not a problem in practice, but interesting nonetheless. We created 12 persistent, idle connections through the NLB (meaning they don't close at the source and don't ever send any data). What we see (at the source) is that the last 2 connections go away when the target application times-out and closes the connection, but the first 10 connections (at the source) do not ever close even though the target has timed-out the connections and has no remaining open connections. FWIW, the target handles all incoming connections in series. Thank you for your feedback on this.
Relevant content
- asked 4 years ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 3 years ago
OK, this makes sense; however, I'm not sure I fully understand your 2nd alternative (Or handle connection cleanup at the target instance level using OS-level TCP timeout settings), since the target has long since closed all of its connections. Are you suggesting that merely closing the idle connection at the socket level on the target is not sufficient?