海外服务器多可用区部署实测：跨 AZ 延迟只差 1.4–4.0 毫秒，流量费却和跨区一样贵

Meta Description: 2026 年 10 月实测：从圣何塞对 6 个 AWS 区域的 S3 端点连续解析，得到 224 个同区域 IP 并逐一发 10 包，同区 RTT 极差仅 1.4–4.0 ms；而跨 AZ 流量按 $0.01/GB 双向计费，复制 1 GB 账单 $0.02，与跨区同价。附三档架构账单算例、场景矩阵与 48 小时验收协议。

关键词：海外服务器多可用区、跨可用区、跨 AZ 流量费、可用区延迟、多可用区部署、AZ 与地区区别、数据同步成本、地区选择

一、先说结论：延迟上最便宜的冗余，账单上最贵的冗余

如果你已经选好了地区，下一个问题不再是「哪个机房快」，而是「同一个地区里要不要开第二个、第三个可用区」。2026 年 10 月 25 日，我们从美国加州圣何塞一个固定测点，对 6 个 AWS 区域的 S3 端点连续解析了 40 次，一共拿到 224 个同区域 IP，并逐一发了 10 包 ICMP：同一区域内部最快与最慢的 IP 只差 1.4–4.0 毫秒，比圣何塞到洛杉矶这一段（8.7 毫秒）还小。但同一件事在账单上的表现完全相反——跨 AZ 流量按 $0.01/GB 双向计费，复制 1 GB 的账单是 $0.02，与跨区复制一份的价格完全相同。

五条可复核的结论：

• 同区极差 1.4–4.0 ms，全部落在跨城差之下。香港 ap-east-1 的 9 个 IP 极差只有 1.42 ms，美西 us-west-2 的 48 个 IP 极差 2.33 ms，美东 us-east-1 的 40 个 IP 极差 3.97 ms。作为参照：圣何塞→洛杉矶 8.66 ms、→东京 104.50 ms。
• 这点差异连测量噪声都盖不住。同一批 IP 的 mdev（抖动）是 0.47–1.39 ms，与「最快和最慢之差」同量级。换句话说，你 ping 一次得出的「A 比 B 快 2 ms」，有一半概率是抖动。
• 跨 AZ 一份副本 = 跨区一份副本，价格一模一样。AWS 跨 AZ 是 $0.01/GB 且 In 与 Out 各收一次，合 $0.02/GB；美境内跨区也是 $0.02/GB。多可用区不是「便宜的跨区」，它和跨区同价。
• 费用占比反直觉：每月跨 AZ 写入 10 TB 时，双 AZ 方案的总成本 $224–248 里有 89% 是流量费，实例费只占 11%。
• 唯一免费的边界是「不出 AZ」。同 AZ 流量是 $0；一旦越界，无论跨一个机架区还是跨一个洲，都按 GB 起价。

需要先钉死视角：本文的「同区极差」是从区外一条跨洋路径观测到的上界，不是 AZ 之间的真实 RTT。公网无法证实某个 S3 IP 属于哪个 AZ（AWS 不公开这个映射），这一点第三节会讲清楚，别把 4 ms 当成「AZ 之间差 4 ms」引用。

二、先把三个层级分清：地区、可用区、机房

「多可用区」被讨论得很多，但大部分人把三个层级混成了一层，于是得出两个相反的结论：要么觉得「多 AZ 就是多活」，要么觉得「多 AZ 纯属浪费钱」。它们防的故障根本不是同一类。

三个层级的定义都有官方口径可查。微软在 Azure 架构文档里把可用区定义为「区域内的一个隔离位置，拥有独立的电源、网络和制冷」，并把同一区域内可用区之间的往返延迟描述为低于 2 毫秒；AWS 的说法是可用区之间「以低延迟网络互联，延迟为单数字毫秒」，同时强调每个 AZ 有独立的供电与制冷。这两句合起来给出一个量级锚点：AZ 级延迟是毫秒个位数，通常就是 1–2 毫秒。

所以「多可用区」这个词的准确含义是：用 1–2 毫秒的延迟代价，换掉「一个机房整体没了」这一类故障。它不换掉城市级灾害（那要跨区），也不换掉单机故障（那要副本或自动重启）。这句话是全文的基础，后面所有的钱都花在这个定义上。

一句话记住这一节： AZ 是故障域，不是延迟域；它防的是「一座变电站」，不是「一座城市」。

三、实测设计：224 个同区域 IP 是怎么来的

数据要能复核，所以方法写全。

测点。 美国加州圣何塞，38.55.134.58 / AS402169（Uscloud）。采集时间 2026-10-25 06:02–06:20 UTC，与本文的九地区基线同一时段、同一条出口。

取样对象。 6 个 AWS 区域的 S3 区域端点：s3.us-west-2.amazonaws.com、s3.us-east-1.amazonaws.com、s3.ap-northeast-1.amazonaws.com、s3.ap-southeast-1.amazonaws.com、s3.eu-central-1.amazonaws.com、s3.ap-east-1.amazonaws.com。

选 S3 端点的理由有三个：它是同区域内由托管服务做多 AZ 部署的端点，DNS 会返回同一区域内不同落地位置的多个 IP；它不需要任何账号或权限，任何人都能复现；它长期稳定，不像测速文件那样随时下线。

取样方法。 对每个端点连续调用 getaddrinfo 40 次（每轮会返回一组 IP），去重后得到该区域的 IP 集合；再对每个 IP 执行 ping -c 10 -i 0.2 -W 2，取 avg 与 mdev。最终 224 个 IP 全部 10/10 收到回包，端到端丢包 0%。

三条必须写明的局限。

1. 无法证实 IP 属于哪个 AZ。 AWS 不公开「公网 IP → 可用区」的映射，第三方 GeoIP 也只到城市级。所以本文的 224 个 IP 只能保证「属于同一个区域」，不能保证「分属不同 AZ」。
2. 极差里混着路径差异。 同一个区域的不同 IP 可能从不同骨干出口进来，极差 = AZ 位移 + 路径差异，两者无法拆分。因此下文一律把它称作「AZ 级差异的外部观测上界」，而不是「AZ 间 RTT」。
3. 真正的 AZ 间延迟只能在区内测。 想拿准确数字，得在同一个区域开两台不同 AZ 的实例互 ping。本文没有账号，做不到，这是本文最大的数据缺口，如实标注。

一句话记住这一节： 这是一次「从区外看同区多 IP 的离散度」实验，它能回答「AZ 差异在大尺度上可不可见」，不能回答「AZ 之间具体几毫秒」。

四、实测一：九地区基线（同一测点、同一时段）

先给坐标系。以下为 2026-10-25 06:03–06:12 UTC、ping -c 20 -i 0.3 的结果，用来给后文的「毫秒」一个尺寸感。

这张表里最该看的是最后一行的 mdev：新加坡这一轮的抖动是 10.297 ms，最大值 206.299 ms。这个数字后面还会用到——它比本文全部「同区极差」都大 3–7 倍。

五、实测二：224 个同区域 IP，极差只有 1.4–4.0 毫秒

三行读法，从重要到次要：

第一，绝对极差全部小于 4 毫秒，且全部小于「换一座城市」的代价。 最快与最慢之间差 1.4–4.0 ms，而圣何塞→洛杉矶（同州、不同城市）就是 8.66 ms。也就是说：在同一地区内选错落地位置，损失的延迟还不够你换一个城市。

第二，相对极差反而是短路径最大。 us-west-2 的极差/均值是 7.48%，ap-east-1 只有 0.94%。原因很直白：基数小的时候，同样的 2 ms 占比更大。所以「相对差异」这个指标在这里没有决策价值——1.42 ms 和 3.97 ms 在体验上是同一件事。

第三，抖动比极差还大。 us-east-1 的极差 3.97 ms、样本标准差 1.39 ms；us-west-2 的极差 2.33 ms、标准差 0.64 ms。当你要比较的两个值之差和它们自身的抖动一样大时，单次测量不构成结论。 这与我们 10 月 22 日那篇「同城机房离散度」里发现的两轮反转是同一回事：AWS 端点每轮解析到不同 IP，单轮 10 ms 级的「谁更快」不成立。

这张表里最值得看的是第三、四列：6 个区域里有 4 个，「单个 IP 的最大抖动」比「整个区域最快与最慢之差」还大。ap-northeast-1 有一个 IP 的抖动是 5.35 ms，而该区域 46 个 IP 的极差只有 3.26 ms——这意味着任何单次测量都可能把「最慢的 IP」测成「最快的 IP」。

一句话记住这一节： 同区之差 1.4–4.0 毫秒，这个量级小于你自己的抖动，所以它不是可决策的信号。

六、为什么你 ping 不出一个可用区

把「AZ 之间 1–2 毫秒」和「实测极差 1.4–4.0 毫秒」放在一起，会得到一个反直觉的推论：实测极差比物理上限还大，说明极差的主要成分不是 AZ 位移。

用光速算一遍。光纤中的传播速度约 200 km/ms（即 5 微秒/公里），一个往返要除以 2 再乘 2，简化为 RTT ≈ 距离/100，单位分别是毫秒和公里。同一城市内的两个可用区，物理距离通常在个位数到数十公里级（Azure 的官方描述是「区域内一个隔离位置」，AWS 强调独立的供电与制冷，都不承诺具体公里数）。取一个宽松的上界 100 公里：

• 100 km → RTT ≤ 1.0 ms
• 50 km → RTT ≤ 0.5 ms
• 20 km → RTT ≤ 0.2 ms

也就是说，AZ 位移能贡献的延迟上限大约是 0.2–1.0 ms，而实测极差是 1.4–4.0 ms。多出来的 1–3 ms，来自于「不同 IP 走不同骨干出口、落在不同边缘节点、甚至不同城市的前置接入点」——这些跟 AZ 无关。

这解释了一个常见困惑：为什么有人 ping 同一地区的两个 IP 差了 4 ms，就断定「这个 AZ 比那个慢」。他测到的其实是他到两条不同路径的差，而这两条路径随时会变：我们 10 月 15 日那篇 IP 归属分析里，hk.tencentcloudapi.com 解析出的「香港节点」实测只有 2.0 ms（本地接入点，不是香港机房）；10 月 22 日那篇里，AWS 端点两轮解析甚至给出互相矛盾的排名。

一句话记住这一节： 从区外看，AZ 之间的延迟差被路径噪声淹没；要判断 AZ 快慢，必须在区内测，而这件事对选型几乎没有意义——因为差的这 1 毫秒改变不了任何决策。

七、结论一：AZ 是个故障域决策，不是延迟决策

把第五、六节合起来，可以下一个很硬的判断：

在延迟维度上，多可用区是「几乎免费」的。 你为跨 AZ 付的延迟代价是 1–2 毫秒，相当于：

• 一次 TCP 握手的一个 RTT（约 1 ms 量级，见 10 月 5 日《建连往返预算》篇）
• 新加坡那条线路一次抖动（10.3 ms）的 1/5
• 换一个城市代价（8.7 ms 起）的 1/5

所以「多 AZ 会不会变慢」这个问题的答案是：不会，慢到你测不出来。

但反过来，如果多 AZ 的理由是「延迟更低」，那这个理由是假的。同一个地区内不同 AZ 的延迟差，小于你链路正常的日内波动，也小于同一台机器在不同时段的差异（10 月 23 日那篇基线漂移实测里，同一条链路 21 天内的均值漂移就达到数毫秒量级）。

于是决策标准就只剩一条：这个 AZ 防的故障，你赔不赔得起。 这直接引出下一节——既然延迟不是成本，那成本就只有一样：流量费。

八、费用：同 AZ 免费，跨 AZ 每方向 $0.01/GB

先给官方原文，再给推算，避免口径混淆。

AWS。 VPC 定价页对等连接（peering）的原文是：「Data sent over VPC peering connections that crosses an Availability Zone within the same AWS Region is charged at $0.01/GB in both "In" and "Out" direction.」AWS 架构博客的原文是：「Data transfer within the same Availability Zone is free.」两句合起来就是全部规则：同 AZ 免费；跨 AZ 每个方向 $0.01/GB，收发各算一次。

GCP。 官方 VPC 网络定价表：同一 zone 内用内网地址「No charge」；不同 zone、同一 region 用内网地址「$0.01」/GiB。GCP 只向发送方计费。

Azure。 官方带宽定价页把「Data transfer within same Availability Zone」（同可用区内）单列为 Free；跨可用区与跨区域各自成表、分别计价，其中跨区域（北美/欧洲）$0.02/GB、亚洲/大洋洲/中东/非洲区内 $0.08/GB、南美区内 $0.16/GB、跨洲从亚洲 $0.08/GB。

把三条规则换算成「搬运 1 GB 实际要付多少」：

第三行是关键，务必盯住：跨 AZ 复制 1 GB 的账单是 $0.02，跨区复制 1 GB 的账单也是 $0.02。 这意味着「多可用区比多地区便宜」在流量费上是不成立的——它只在实例费、运维复杂度、合规上便宜。

一个容易被忽略的补充：阿里云、腾讯云的计费文档把「同地域内网流量」列为不计费项（跨地域才计费），所以在国内两家云上，跨可用区通信不进账单。同一套三 AZ 架构从阿里云搬到 AWS，每月会凭空多出一笔四位数的流量费——这是「同样的架构、不同的账单」里最容易被低估的一条（以厂商当期计费文档为准）。

一句话记住这一节： 唯一免费的边界是「不出 AZ」；跨出去一步，无论是一个机架区还是一个洲，都按 GB 起价，而且跨 AZ 与跨区同价。

九、三档价格台阶：$0 / $0.02 / $0.02 / $0.09

把上面的规则排成台阶，一眼就能看出「哪一档值得省」：

这张表能纠正两派人的错误：

• 「多 AZ 省钱派」 以为跨 AZ 只是「内部流量」，几乎不花钱。实际是从 0 直接跳到 $0.02/GB，跨度是无穷大。
• 「跨区一定更贵派」 以为跨区是跨 AZ 的两倍。实际两者单价完全相同，因为跨 AZ 的双向计费已经把单价翻了一倍。

真正该记住的是：你要省的不是「跨区改跨 AZ」，而是「把跨 AZ 通信做成一次性、批量化、或者干脆不出 AZ」。 具体做法在第十三节。

十、算例：三种架构的月度账单

设定一个典型业务：一个写入型服务，每月产生 10 TB 新数据（约 333 GB/天），需要 1 份冗余。所有价格按 2026 年 10 月 AWS 公开标价折算，不含税、不含实例费以外的其他服务。

再加上实例费，多 AZ 的真实代价就露出来了。按 2 核 4 GB、$12–24/月/台折算：

读法：在 10 TB/月 这个量级上，多可用区的成本里 89%–92% 是流量费，不是服务器费。 这跟大多数人的直觉相反——大家习惯性认为「多开一台机器就是多一份钱」，实际上多开的那台机器是便宜的，机器之间的那条线才是贵的。

再补一个更狠的算例：读写放大。 假设应用在 AZ-B、数据库主库在 AZ-A，每个查询跨 AZ 拉 50 KB 结果集，QPS 1000：

• 吞吐 = 1000 × 50 KB = 48.8 MB/s ≈ 0.048 GB/s
• 月流量 = 0.048 × 86,400 × 30 ≈ 123,596 GB（约 120 TB）
• AWS 账单 = 123,596 × $0.02 ≈ $2,472/月
• GCP 账单 = 123,596 × $0.01 ≈ $1,236/月

一个「把应用和数据库分在两个 AZ 以图高可用」的常规操作，在 QPS 1000、结果集 50 KB 的负载下，每月多付两千多美元。而它换来的「高可用」，在同 AZ 内做读写分离 + 每日快照的前提下，可以省掉 90%——因为同 AZ 内读写是免费的。

十一、例外：为什么托管多可用区数据库不收流量费

这里有个必须讲清的反例，否则上面的账会算错。

AWS 架构博客的原话是：RDS 启用多可用区配置后，在另一个可用区部署备用实例，「Replication between the primary and standby instances does not incur additional data transfer charges」。也就是说，托管数据库的主备复制是存储层同步，不计流量费；但同一句话的后半段是「data transfer charges will apply from any consumers outside the current primary instance Availability Zone」——应用如果不在主库那个 AZ，读写照样按 $0.01/GB 每方向收费。

这条规则推导出一个很实用的结论：

所以「要不要用托管多可用区」在成本上是有明确答案的：写入量大（>3 TB/月）时，托管多可用区比自建主从便宜，因为复制走存储层不收费；但读副本一旦跨 AZ，又回到按 GB 计费。 这也解释了为什么云厂商的「多可用区」卖得动——它卖的不是架构，是把变动成本换成了固定成本。

顺带一个容易踩的小坑：区域级 NAT 网关按 AZ 计小时费。官方定价页写明：「if your regional NAT is running across three Availability Zones for one hour, you'll be billed for three 'NAT Gateway-hours'」。开了三 AZ 的 NAT，小时费直接 ×3，且跨 AZ 的 NAT 流量还要再叠处理费。

十二、什么时候必须跨 AZ，什么时候纯属浪费

把「故障域」和「$0.02/GB」两件事放在一起，决策就变成一张表：

四条判断原则，比表格更好记：

1. 能不能重建？ 能重建的（构建机、无状态 worker）不需要跨 AZ，重跑比冗余便宜。
2. 数据能不能丢？ 能丢的（缓存、会话）双 AZ 就够，丢一半也比不冗余强。
3. 故障域是不是同一个？ 同一个变电站、同一段城域光纤才算同一个 AZ 风险；如果你的两个「AZ」其实是同一栋楼的两层，那 $0.02/GB 白花了。
4. 跨 AZ 解决不了的问题，别用跨 AZ 解决。 城市级灾害、法域风险、供应商锁定，这三件事只有跨区能解。

十三、把跨 AZ 账单压下去的五种做法

按「省下的钱 / 改动量」排序，从最划算开始：

第一，同 AZ 亲和（省 100%，改动最小）。 把应用和它最常访问的数据放在同一个 AZ。同一 AZ 内流量 $0，这一条能直接把第十节那个 $2,472/月的读放大账单归零。实现方式：子网按 AZ 划分，部署时显式指定 AZ，不要用「自动选」；K8s 用 topologyKey: topology.kubernetes.io/zone 做 pod 亲和。

第二，把跨 AZ 通信批量化（省 50%–90%）。 跨 AZ 的成本按 GB 计，不按次计。所以「每请求一次跨 AZ 往返」和「每 100 请求批量一次」的账单差 100 倍。做法：批量写、批量拉、结果集分页而不是全量拉、压缩后再跨（gzip 通常 3–5 倍）。

第三，用区域级快照代替跨 AZ 复制（省 100% 的复制流量）。 EBS 快照存放在区域级的对象存储里，从快照恢复卷不产生跨 AZ 数据传输费。备份需求用「快照 + 跨区复制」组合，而不是「实时同步到另一个 AZ」。

第四，写入量大时用托管多可用区（把变动成本换成固定成本）。 见第十一节：复制走存储层不收费，实例费翻倍是固定的。10 TB/月 以上，托管通常更便宜。

第五，注意 NAT 与中转的隐藏收费。 区域级 NAT 按 AZ 计小时费（三 AZ = 3 倍小时费），跨 AZ 的 NAT 处理还要叠加；对等连接跨 AZ 同样是每方向 $0.01/GB。用 VPC 端点（Gateway Endpoint）直连 S3/DynamoDB 可以完全绕开 NAT，这一条对静态资源多的站点往往一次省几百美元。

十四、验收协议：48 小时内核对你的跨 AZ 项

账单上的跨 AZ 是被拆散在多行里的，不做一次专项核对，你永远不知道自己在为哪条线付钱。五步，两小时内能做完：

第一步：定位账单行。 在 Cost Explorer 或 CUR 里按 Usage Type 过滤，AWS 的跨 AZ 传输通常出现在含 DataTransfer-Regional-Bytes 的行上；按「Region + Usage Type」分组，看哪一行在涨。GCP 对应的是 Network Inter Zone Egress（按 SKU 名过滤）。

第二步：核对实例与数据的 AZ 分布。 逐台实例看 AZ；重点看「应用实例所在 AZ」与「数据库/缓存所在 AZ」是否一致。不一致就是第十节那个 $2,472/月 的账单来源。

第三步：用连接表确认对端。 在应用机上执行 ss -tnp，把对端 IP 与子网表对照，确认有多少活跃连接是跨 AZ 的；或者直接看 VPC Flow Logs 里 src/dst 的 AZ 字段。

第四步：算「每万次请求的跨 AZ GB」。 用一个真实业务指标（每万次请求产生的跨 AZ 字节数）做分母，再乘上你的月请求量，得到预测账单。这个指标比「总流量」更能定位放大点。

第五步：做一次 A/B。 把应用切到与数据库同一个 AZ，跑 24 小时，对比账单差与 P95 延迟变化。预期结果是：账单明显下降，P95 变化在噪声范围内——如果你看到 P95 明显变差，说明你原来跨 AZ 的那条路径另有问题（比如 AZ 内的实例本来就慢），值得单独查。

十五、五个常见误区

误区一：多可用区就是多活。 多 AZ 只防「单机房/单变电站级」故障。城市级灾害（地震、洪水、大范围断电）两个 AZ 一起挂，同城的多活等于没有。真正的多活需要跨区。

误区二：跨 AZ 比跨区便宜。 单价上它们完全一样（$0.02/GB，AWS）。跨 AZ 只省实例费、运维和合规成本，不省流量费。

误区三：AZ 之间有延迟差，所以要挑快的。 实测 224 个同区 IP 的极差是 1.4–4.0 ms，而 AZ 位移的物理上限只有 0.2–1.0 ms，其余是路径噪声。从区外 ping 不出 AZ 快慢，也不该用 ping 选 AZ。

误区四：开三个 AZ 就是三副本，成本 ×3。 三 AZ 的复制份数是 2（写 1 份、同步 2 份），但账单不是 ×3：实例费 ×3、流量费按 2 份计、NAT 小时费 ×3。真正的倍数要按第十节的表逐项算。

误区五：多可用区可以替代备份。 不能。AZ 内的逻辑删除、误操作、勒索加密会以毫秒级同步到另一个 AZ——这正是 10 月 19 日那篇「不可变备份」要解决的问题。多 AZ 防硬件故障，备份防人为与逻辑故障，两者不可互替。

总结与推荐

这篇实测想纠正的是一个默认假设：「多可用区是延迟和成本之间的折中」。数据给出的答案比折中更极端：

1. 延迟上几乎免费。 224 个同区域 IP 的 RTT 极差只有 1.4–4.0 毫秒，AZ 位移的物理上限是 0.2–1.0 毫秒，剩余的差是路径噪声。多 AZ 不会让你变慢，慢到你测不出来。
2. 账单上非常贵。 同 AZ 免费，跨 AZ 每方向 $0.01/GB，复制 1 GB 账单 $0.02，与跨区同价。10 TB/月 的写入量下，多 AZ 总成本里 89%–92% 是流量费。
3. 最贵的不是多开一台机器，是机器之间那条线。 双 AZ 相对单 AZ 的 10–18 倍价格差里，服务器只占 11%。
4. 放大效应来自「每请求一次跨 AZ」而不是「总量」。 1000 QPS × 50 KB 结果集就是 120 TB/月、$2,472/月，而同样的负载在 AZ 内是 $0。
5. 托管多可用区是唯一「复制免费」的路径。 RDS 主备复制走存储层不计流量费，但跨 AZ 的读消费者照样收费——这条边界决定了架构该怎么切。

落到行动上：先用第十二节的表判断「这个业务赔不赔得起这个故障域」，赔不起就跨 AZ；决定跨之后，用第十三节的第一条（同 AZ 亲和）把绝大部分流量留在 AZ 内，只在真正需要冗余的数据上付 $0.02/GB。 多可用区不是一个「开或不开」的开关，它是一个「哪条线跨、哪条线不跨」的切分问题。

本文测试数据采集于 2026 年 10 月 25 日 06:02–06:20 UTC（测点：美国加州圣何塞 38.55.134.58 / AS402169 Uscloud；DNS 取样为对 6 个 AWS S3 区域端点各连续 getaddrinfo 40 次去重；ICMP 为 ping -c 10 -i 0.2 -W 2，224 个 IP 全部 10/10 回包、端到端丢包 0%；九地区基线为 ping -c 20 -i 0.3）。价格与规则来源：AWS VPC 定价页（跨 AZ「$0.01/GB in both In and Out direction」）、AWS 架构博客《Overview of data transfer costs for common architectures》（「Data transfer within the same Availability Zone is free」、RDS 多可用区复制不计流量费）、AWS EC2 按需定价页（出网 $0.09/GB 首 10 TB）、Google Cloud VPC 网络定价页（同 zone 免费、跨 zone $0.01/GiB）、Azure 带宽定价页（同 AZ 免费、跨区域北美/欧洲 $0.02/GB、亚洲区内 $0.08/GB）。跨区美境内 $0.02/GB 沿用本站 2026-10-07 篇已核实锚点。公网无法证实 IP 与可用区的对应关系，本文极差应读作 AZ 级差异的外部观测上界；真实 AZ 间 RTT 需在区内双实例互测。延迟与资费可能因网络环境、测试时间与区域不同而有所差异，建议购买前用你自己的业务形态进行 48 小时免费测试。

🚀 需要海外服务器？ 通过 6.chengzicloud.cloud 购买，覆盖香港/新加坡/日本/美国等全球区域，多可用区可选，测试后满意再付款，30 天无理由退款保障。

相关阅读

• 海外服务器线路对比的最后一公里：21 个运营商节点实测
• 海外服务器同城机房延迟离散度实测
• 延迟基线会漂：海外服务器地区选择的时间维度实测
• 海外服务器备份存哪个地区：快照、对象存储与恢复速度
• 海外服务器备份加密、密钥托管与不可变备份
• 海外服务器出网流量费：源站与镜像地区的选择
• 海外服务器跨地区迁移成本量化

本文由 6.chengzicloud.cloud 提供，点击访问首页了解更多