- Newest
- Most votes
- Most comments
The behavior you're experiencing on r8i/r8i-flex/m8i instances appears to be related to connection tracking and TCP idle timeout settings.
In AWS, TCP connections are tracked and will be closed if they remain idle (no data transmitted) for a specific period. For EC2 instances, the default TCP established idle timeout is 432,000 seconds (5 days), but this can vary based on instance types and configurations.
The consistent ~5 minute (approximately 300 seconds) disconnection you're seeing suggests that a TCP idle timeout is being enforced somewhere in your connection path. This could be due to differences in the underlying network infrastructure or default connection tracking configurations between the r7i and r8i/m8i instance families.
To address this issue, you have several options:
-
Implement WebSocket ping/pong frames or application-level heartbeats to keep the connection active by sending data periodically (before the 5-minute mark).
-
Adjust the TCP established timeout for your instances. You can modify the
tcpEstablishedTimeoutparameter in the ConnectionTrackingConfiguration for your Elastic network interfaces. This value can be set between 60 seconds and 432,000 seconds (5 days). -
Check if there are any differences in the network configuration between your instance generations that might be affecting connection tracking.
For WebSocket applications, it's generally a good practice to implement heartbeat mechanisms regardless of infrastructure, as various components in a network path might have different idle timeout policies.
Sources
ConnectionTrackingConfiguration - Amazon Elastic Compute Cloud
ConnectionTrackingSpecification - Amazon Elastic Compute Cloud
Introducing NLB TCP configurable idle timeout | Networking & Content Delivery
Relevant content
- asked a year ago
- AWS OFFICIALUpdated a year ago
I am experiencing this issue as well when I migrated from m6i servers to m8i servers. Were you able to determine what the cause was?
We haven't found the root cause. Our migration is on hold for now. Any information others can provide about this behavior is appreciated.
After returning to this issue, it turns out Nitro v6 instance types use a different security-group connection tracking idle timeout. The default used to be 432000 seconds (5 days); on Nitro v6 it is now 350 seconds (about 5.8 minutes). AWS docs: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html.
The timeout can be set during instance creation: https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html, but I haven’t tested it yet.