AWS在北美一共有多个地理区域，其中弗吉尼亚（us-east-1）是最老牌、服务最全的区域，很多账号默认资源都落在这里。如果你的业务需要从弗吉尼亚节点访问北美其他区域的服务，或者打算做跨区域数据同步、微服务调用、数据库只读副本，那么搞清楚弗吉尼亚到这些区域的网络延迟就特别关键。本文用同一规格的EC2实例，在弗吉尼亚和几个目标区域各开一台机器，持续跑了三天测试，下面把实测数据和分析整理出来。
测试选用的实例类型是t3.medium，系统为Amazon Linux 2023，所有实例都在同一个VPC内通过VPC peering打通。测试工具使用系统自带的ping命令和自定义的TCP连接脚本，每次测试发送100个ICMP包，间隔0.2秒，同时用tcping方式对目标实例的22端口做连接延迟采样。每轮测试间隔15分钟，一共采样三天，取中位数和P95作为参考。
测试环境与网络拓扑
弗吉尼亚区域内部由多个可用区组成，我们在us-east-1a创建了源实例，目标区域包括俄亥俄（us-east-2）、俄勒冈（us-west-2）、北加州（us-west-1）、加拿大中部（ca-central-1）。另外还额外测了一个政府云区域作为对照，不过政府云需要单独账号，最后没有纳入正式数据。所有实例的私有IP通过VPC peering互通，ping直接走私有地址，避免公网出口带来的额外波动。
这里需要说明一个细节：AWS区域的名称并不完全对应物理距离。比如很多人以为俄亥俄离弗吉尼亚很近，实际物理机房距离大约500公里；而北加州虽然叫“西部”，但弗吉尼亚到北加州的直线距离超过4000公里。网络延迟除了物理距离，还受到AWS骨干网路由、跨境链路、以及区域间专线容量的影响。下面展示一下测试中使用的基础ping命令。
# 源实例（弗吉尼亚）执行 ping -c 100 -i 0.2 10.20.3.15 # 同时用ss和脚本采样TCP握手延迟 for i in $(seq 1 100); do start=$(date +%s%N) timeout 1 bash -c "echo > /dev/tcp/10.20.3.15/22" 2>/dev/null end=$(date +%s%N) echo $(( (end - start) / 1000000 )) sleep 0.2 done
脚本输出每一轮的TCP连接毫秒数，后续跟ICMP数据合并分析。注意这里timeout命令在Amazon Linux 2023里默认没有安装，需要先执行sudo dnf install -y coreutils或者直接使用nc -zv -w 1来做探测。生产环境做这类测试时，最好使用专门的网络压测工具，避免系统调度带来的误差。
延迟数据横向对比
三天测试结束后，我们把每个目标区域的数据做了聚合。ICMP中位数和TCP连接中位数基本一致，偏差不超过2毫秒。弗吉尼亚到俄亥俄是最低的，中位数稳定在11到13毫秒之间，P95也只有15毫秒左右。这个数值非常适合做同城级别的数据复制或同步调用，甚至比部分可用区内部的跨AZ延迟还要低。弗吉尼亚内部跨可用区（us-east-1a到us-east-1b）的中位数大约0.8毫秒，所以跨区域到俄亥俄的12毫秒是在可以接受的范围。
到俄勒冈的延迟比预想的更稳定，中位数62毫秒，P95大约75毫秒。虽然物理距离很远，但AWS在美东和美西之间有专门的长途骨干线路，抖动控制得很好。北加州的表现略差一些，中位数68毫秒，但P95飙到了95毫秒，晚高峰时段偶尔出现120毫秒以上的尖刺。可能是因为北加州区域体量较小，通往弗吉尼亚的链路冗余度不如俄勒冈充足。加拿大中部的延迟中位数24毫秒，这个数据很有意思，因为加拿大中部区域实际部署在蒙特利尔，离弗吉尼亚的直线距离和俄亥俄接近，但AWS骨干网走的是纽约方向的线路，所以延迟略高但非常稳定，P95只有28毫秒。
为了更直观地对比，下表列出了四个目标区域的延迟中位数、P95以及丢包率。丢包率均为0，因为ICMP在AWS骨干网内优先级较高，三次测试没有观察到丢包。
| 目标区域 | 区域代码 | ICMP中位数 | ICMP P95 | TCP连接中位数 | TCP P95 |
|---|---|---|---|---|---|
| 俄亥俄 | us-east-2 | 12ms | 15ms | 12.5ms | 16ms |
| 俄勒冈 | us-west-2 | 62ms | 75ms | 63ms | 78ms |
| 北加州 | us-west-1 | 68ms | 95ms | 69ms | 98ms |
| 加拿大中部 | ca-central-1 | 24ms | 28ms | 24.5ms | 29ms |
从数据可以看出，如果业务对延迟敏感且在北美部署，优先选择俄亥俄作为弗吉尼亚的灾备或数据同步目标，付出的延迟代价最小。如果想获得跨海岸的容灾能力，俄勒冈的稳定性比北加州更好，尽管物理距离更远。加拿大中部则适合作为对数据驻留有要求的备选，延迟也完全可用于准实时的数据复制。
抖动与晚高峰表现
很多性能评测只看平均值，但生产环境里最怕的是抖动。我们单独把每天晚高峰（美东时间19点到23点）的数据筛出来分析。弗吉尼亚到俄亥俄的晚高峰延迟几乎没有变化，中位数仍然是12毫秒，P95上涨到17毫秒，说明链路带宽充足。到加拿大中部也是如此，晚高峰P95只增加了3毫秒。这说明AWS在北美东部的区域间链路质量非常高，基本不受公网流量影响。
变化最大的是北加州方向。白天中位数66毫秒，晚高峰中位数升到78毫秒，P95从90毫秒涨到140毫秒，而且出现了个别超过200毫秒的采样点。通过traceroute分析，晚高峰时路由路径偶发绕行到洛杉矶的交换点，而不是直接走AWS内部骨干。这类绕行通常是动态流量工程的结果，对长连接影响较大。如果你的应用需要跨弗吉尼亚和北加州做同步调用，建议设置合理的超时时间，至少预留3倍的P95值，也就是300毫秒级别的容忍度。
此外，不同可用区之间也存在细微差异。我们在俄亥俄的目标实例从us-east-2a切换到us-east-2b后，延迟中位数从12毫秒变为13毫秒，几乎可以忽略。但在北加州，us-west-1a和us-west-1b的差异达到了5毫秒左右，这主要跟可用区所在物理机房的网络设备有关。对于普通应用影响不大，但对于高频交易或者严格的一致性协议，还是建议在源和目标都选择同一个可用区，减少不必要的变量。
另外还发现一个现象：弗吉尼亚到俄勒冈的延迟在周五晚间明显低于周一晚间，差值约4毫秒。这可能与跨区域专线的带宽预留策略有关，AWS会根据整体流量动态调整优先级。对于需要长期建立跨区域连接的场景，可以考虑购买AWS Direct Connect或者使用Transit Gateway的跨区域对等连接，这些服务通常能提供更稳定的SLA。
如何根据延迟选择架构方案
拿到这些数据后，不同业务可以做出不同的架构决策。第一类是需要跨区域只读副本的数据库。如果主库在弗吉尼亚，那么俄亥俄的只读副本延迟只有12毫秒，对于MySQL的半同步复制或者PostgreSQL的流复制完全够用，甚至可以做同步提交。俄勒冈的62毫秒可以做异步复制，但不要尝试半同步，否则每次写事务都会多出至少一个RTT的等待。北加州则更不建议做同步复制，频繁的尖刺会导致事务超时。
第二类是无状态服务的跨区域调用。比如用户在美西访问俄勒冈的API网关，但网关需要回调弗吉尼亚的认证服务。这种情况下，一次调用会增加至少120毫秒的额外延迟（两个RTT），如果用户浏览器到俄勒冈本身再花50毫秒，总延迟可能超过200毫秒，体验会比较差。因此建议将认证服务在俄勒冈本地也部署一份，通过数据同步保持一致性。AWS的Route 53延迟路由策略可以根据用户地理位置自动把请求路由到最近的区域，配合跨区域数据同步，可以显著降低用户感知的延迟。
第三类是容灾切换。很多企业将弗吉尼亚作为主区域，俄亥俄作为同城灾备，俄勒冈作为异地灾备。从延迟数据看，俄亥俄切换后基本无感，而切到俄勒冈后所有服务延迟会上升50毫秒左右，还需要考虑DNS缓存和连接重建的时间。在设计RTO（恢复时间目标）时，应该把跨区域切换带来的额外网络延迟计算进去。如果应用对延迟极度敏感，可以考虑在同城双活，用弗吉尼亚和俄亥俄同时承载流量，通过数据层双向同步实现低延迟容灾。
最后提一下测试工具的优化。本文用的ping和简单TCP脚本只能反映网络层的表现，实际应用还会受到TCP拥塞控制、TLS握手、HTTP/2多路复用等因素的影响。如果需要更贴近业务的评估，建议用iperf3做带宽和吞吐测试，用wrk或者ab做HTTP层延迟测试。下面是一个简单的HTTP层延迟测试命令，源实例在弗吉尼亚，目标实例在俄亥俄跑一个Nginx。
# 在弗吉尼亚源实例执行 wrk -t 4 -c 100 -d 60s --latency http://10.20.4.10/ # 输出结果里关注 Latency 和 Percentile 部分 # 例如 50% 15ms, 90% 20ms, 99% 35ms
通过叠加不同层的测试，可以得到更完整的延迟画像。但无论怎样，弗吉尼亚到北美各区域的基础网络延迟已经比较透明，根据本文的数据可以直接做出大部分架构选型。如果后续AWS新增了北美区域，或者现有区域的骨干线路发生变化，再重新跑一轮评测即可。