Test from inside major cloud provider networks with Globalping
Whether you're running cloud latency tests before a launch or comparing cloud provider performance during a migration, you need test results that show what’s actually happening inside those networks and not just what things look like from the outside.
Globalping runs probes across leading network providers such as Amazon.com, Google Cloud, DigitalOcean, Vultr, UpCloud, and Hetzner, as well as hundreds of others. As a user, you can run tests directly from these networks to get accurate, relevant results.
In this post, we’ll look at when testing from specific provider networks is useful and how you can target them in your tests.
Testing to a cloud vs testing from it
When measuring latency, the network you test from is just as important as the destination you are testing to.
When you test to a cloud provider, for example, pinging an AWS server from your laptop, you only learn how well you can reach it. That can be useful information, but it only reflects your own network path.
Testing from a cloud provider is different; when you run a ping from a Globalping probe inside AWS in Frankfurt, you see what traffic from that network looks like. That’s what you want to measure when your users, services, or dependencies (like a database) are hosted there.
Globalping hosts probes inside popular infrastructure networks. You can jump directly to their dedicated network pages below to run tests:
When to test from cloud providers
Let’s explore some practical use cases where running tests from a cloud provider comes in handy.
Compare cloud provider performance
Say you’re about to launch a new application and need to pick a hosting provider. In addition to comparing providers by features, specifications, and pricing, you can run tests from each provider network to your database, upstream APIs, or target user regions to see which provider delivers the lowest latency.
For example, if you need to decide between AWS eu-west-1 (Ireland) and Hetzner in Falkenstein, and want to see which offers lower latency to one of your upstream APIs in Amsterdam, you can run a ping from each provider and compare the results.
With the Globalping CLI, it looks like this:
> globalping ping your-amsterdam-api.com from aws+ireland
# or "globalping ping your-amsterdam-api.com from eu-west-1"
# if you know the cloud region's name
> globalping ping your-amsterdam-api.com from hetzner+falkenstein
This gives you real data to help you make better-informed decisions, rather than relying solely on the provider's benchmarks.
Debugging cloud-specific routing issues
Sometimes, performance problems may only show up for users on a specific network. Imagine a customer reports that requests to your API are slow, but only from their infrastructure running on Google Cloud. Before you start troubleshooting, check whether the issue lies on your end or theirs.
To test this, you can run traceroutes to your API from Google Cloud probes in the customer's specific region. Make sure to define a geographical location for your network. If Globaping picks a probe on the wrong continent, the test results won’t reflect the customer’s issue.
# targets a specific cloud region in the US
> globalping traceroute your-api.example.com from gcp-us-west1
# targets any Google Cloud probe in the US
> globalping traceroute your-api.example.com from us+google
If the traceroute’s latency and network path look okay, it’s a good sign that the issue isn’t with the network in that region. Next, you could run other network tests to help narrow down the problem.
Backing performance claims with real data
If you run a hosting company, CDN, or managed service, offering low latency is an important selling point. However, just quoting some numbers from your monitoring isn’t verifiable for prospects. Providing a way for them to replicate your data makes your performance claims checkable.
There are two straightforward ways to handle this with Globalping:
- The lightweight option is to link directly to the relevant looking glass page (for example, globalping.io/networks/amazoncom). Users can use that page to run tests from inside that cloud network to your service’s infrastructure or nearest CDN edge node.
- For a more robust solution, you can use the Globalping API to run measurements on a schedule and display the results as a graph on your website.
How to target cloud providers with Globalping
Now that we’ve looked at some examples, when testing from cloud providers comes in handy, let’s have a closer look at how you can do that in practice.
Looking glass pages
We host a dedicated looking glass page for every provider whose network we host probes in. For example, globalping.io/networks/upcloud lists all available UpCloud probes by region. You can pick a specific location and run a test directly from that probe without installing anything.
These pages also include a map showing where we have probes available, which can help you define and fine-tune test locations to get the best test results for your use case.
Globalping CLI
If you need to run tests repeatedly or automate them with a script, the Globalping CLI gives you the most flexibility. You can target a provider by name, combine it with a location, and use the results in your other tools.
Here are a few examples:
# Ping from any available UpCloud probe; results are returned as JSON
globalping ping example.com from upcloud --json
# Ping from AWS in a specific AWS cloud region
globalping ping example.com from us-east-1
# HTTP test from Google Cloud in Europe
globalping http example.com from google+europe
# Traceroute from DigitalOcean
globalping traceroute example.com from digitalocean
# Ping from multiple Hetzner probes simultaneously
globalping ping example.com from hetzner --limit 5
Other Globalping integrations
We’ve developed a range of official integrations that let you use Globalping with your favorite tools. For example, we have a web tool that lets you configure and run tests from your browser. If you work in a team, the Slack or Discord apps let you run tests and share results directly in the chat. If you’re looking to integrate Globalping with your AI assistant, the MCP server lets you run measurements using natural language.
That was just a sneak peek of the available integrations; you can find the full list at globalping.io/integrations.
Conclusion
Running network tests from specific cloud providers lets you see what traffic originating from those networks looks like. Instead of guessing how your infrastructure interacts with the rest of the web, you get real data from the networks your services use.
Head over to globalping.io/network-providers to start testing from hundreds of providers for free.