Speed Testing from Inside Major Cloud Provider Networks

Differences Between In-Cloud and Regular Speed Tests

Traditional speed test nodes are mostly deployed in IDC data centers or home broadband environments, reflecting the link from public internet users to your server. However, when your architecture spans multiple clouds, service-to-service calls traverse the peering connections between cloud providers, and the quality of this link cannot be measured by regular speed tests.

Speedtest.cn has deployed speed test probes in twelve regions across five providers: Alibaba Cloud, Tencent Cloud, Huawei Cloud, AWS, and Google Cloud. This allows direct measurement of latency, packet loss, and routing paths from a specific cloud region to your target address.

Typical Use Cases

Before cross-cloud disaster recovery drills, use in-cloud nodes to verify whether the actual latency between two clouds meets the requirements for database master-slave synchronization. When selecting CDN origin-pull routes, compare the time taken to fetch from each cloud data center back to your origin server. When troubleshooting user complaints in a specific cloud region, quickly determine whether the issue lies in the in-cloud link or the public internet.

All in-cloud nodes are marked with cloud provider icons in the node selection panel, and you can mix them with regular nodes to run comparative tests.

How to Interpret In-Cloud Speed Test Results

Latency for in-cloud nodes is typically significantly lower than for public nodes. If latency on a particular in-cloud link spikes abnormally, it is likely due to a routing change in the cloud provider's backbone network. We recommend using the traceroute feature to inspect specific hops and keep screenshots as evidence when submitting a ticket to the cloud provider.