Chicago Local Zone Latency

The increased latency you're experiencing with your EC2 instance in the Chicago Local Zone could be due to several factors. Local Zones are designed to provide single-digit millisecond latency to end users in specific geographic areas, so a jump from ~1.0 ms to 25+ ms is indeed significant and unusual.

Here are a few points to consider and potential steps to address the issue:

1. Network Configuration: Ensure that your EC2 instance and the associated network components are properly configured. Check your VPC settings, security groups, and network ACLs to make sure they're not introducing any unnecessary delays.

2. Instance Type and Configuration: Verify that you're using an instance type that supports enhanced networking. Also, make sure your instance's network settings are optimized for low latency. This may include enabling busy poll mode and configuring CPU power states in the Linux kernel.

3. ENA Driver Settings: If your instance uses the Elastic Network Adapter (ENA), review the ENA driver settings. You might need to adjust interrupt moderation settings using the 'ethtool' command to minimize latency, although this could increase CPU usage.

4. MTU Settings: Check the Maximum Transmission Unit (MTU) settings. For most Local Zones, the MTU between an EC2 instance in a Local Zone and an EC2 instance in the Region is 1300 bytes, but for some specific Local Zones, it can be higher (8801 bytes for Chicago).

5. ISP and Route Issues: While Local Zones have their own internet connections, there could be issues with the route between your Local Zone and Interactive Brokers' servers. You might want to perform a traceroute to identify if there are any problematic hops causing the increased latency.

6. AWS Support: If you've verified your configuration and the issue persists, it may be worth contacting AWS support. There could be underlying infrastructure issues or changes that are affecting the Local Zone's performance.

7. Alternative Solutions: If the latency issues continue, you might consider using a cluster placement group within the Local Zone or even a Dedicated Host to potentially reduce network hops and improve latency.

Remember, while Local Zones are designed for low latency, actual performance can vary based on network conditions and specific configurations. Continuous monitoring and optimization may be necessary to maintain the desired low-latency performance.

Sources
AWS Local Zones Features - AWS
Improve network latency for Linux based EC2 instances - Amazon Elastic Compute Cloud
How AWS Local Zones work - AWS Local Zones

It doesn't sounds likely that the local zone is where the latency is being introduced here. I would suggest you perform a traceroute from the local zone to the resource you are accessing to get an idea where the latency is being introduced. Based on the traceroute you should have a better idea of if you should work with AWS support or support for your target service.

Update: I fired up my original EC2 Chicago instance in the us-east-1-chi-1a Availability Zone and the roundtrip time to IBKR servers are around 2ms, where the roundtrip time to IBKR Chicago serves (cdc1.ibllc.com) from the us-east-1-chi-2a Availability Zone remains around 25ms. I still have to dig deeper, but it's a head scratcher for sure.

For now, I'll stick with chi-1a, until I figure out what gives.