Key Takeaways
- “Multi-cloud performance testing” means one of two things: running load generators from several clouds against one application, or testing an application whose parts run in several clouds. Decide which you need before you pick tools.
- Most multi-cloud problems sit at the seams: DNS-based routing, calls that cross providers, and the slowest region in a chain. Test those seams with user journeys, not one cloud at a time.
- Provider documentation tells you how each routing service picks a target. Your load test tells you what it costs in latency. Do not trust either alone.
- LoadFocus runs tests from 25 AWS regions, so its generators are all on AWS. Generators on Azure or Google Cloud need your own JMeter or k6 machines.
Provider facts below come from AWS, Microsoft and Google documentation read on 2026-10-23. Check the linked pages before relying on a detail.
What is multi-cloud performance testing?
Multi-cloud performance testing is load testing an application that spans more than one cloud, or load testing from more than one cloud, and measuring how latency and errors change along the path. In practice it means sending realistic user journeys at the public entry point, watching percentile latency per region and per dependency, and finding which cloud, region or cross-cloud call limits the whole journey.
The two meanings need different setups:
| Question | Where generators run | Where the app runs | Typical finding |
|---|---|---|---|
| How do users in different places experience one app? | Several regions or clouds | One cloud or several | Latency differs by region, routing sends some users to a distant endpoint |
| Does an app split across clouds hold up under load? | Anywhere that reaches the entry point | Services in two or more clouds | A cross-cloud call becomes the slowest hop, or one provider’s limits are reached first |
Most teams need the second question answered and assume the first answers it. It does not: generators in three clouds hitting a single-cloud app tell you about network paths to that app, not about the app’s own cross-cloud calls.
How do you set up a multi-cloud load test?
Work in this order. Each step is small, and skipping the first two is the usual reason results cannot be compared.
- Map the journeys and the hops. For each business-critical flow (login, search, checkout), list which service answers at each step and in which cloud and region. A flow that crosses a provider boundary on every request is the first test target.
- Fix the measurement. Use the same script, think times and percentile reporting everywhere. Report p50, p95 and p99 per region; an average across clouds hides the bad one. See why percentiles are more useful than averages.
- Baseline each deployment on its own. Run the same moderate load against each cloud’s endpoint directly (bypassing global routing) so you know what each stack does by itself.
- Test through the real entry point. Run the journeys through the DNS or global load balancer users actually hit, and check which backend answers whom.
- Ramp and spike. Raise load past the expected peak and add a sudden jump, using the shapes in the spike testing guide.
- Compare per region and per hop, then repeat after each change, in CI where you can.
How does DNS and global load balancing affect the test?
It changes which backend a simulated user reaches, and a load test can hide that if all generators share one resolver or one location. What each provider documents:
- AWS Route 53 offers eight routing policies: simple, failover, geolocation, geoproximity, latency, IP-based, multivalue answer and weighted. Latency routing is for resources in multiple AWS Regions, to send traffic to the Region with the best latency (docs.aws.amazon.com, read 2026-10-23).
- Azure Traffic Manager has six methods: Priority, Weighted, Performance, Geographic, Multivalue and Subnet. Performance routing picks an endpoint by measured network latency using an Internet Latency Table, and decides from the IP of the user’s recursive DNS service, not the client. Microsoft also warns that DNS caching can skew weighted distribution when there are few clients or resolvers, and that this is common to all DNS-based routing (learn.microsoft.com, page dated 2025-12-29, read 2026-10-23).
- Google Cloud global external Application Load Balancers use a single anycast IP address as the frontend for backends in regions around the world, and a global load balancer supports backends in multiple regions (docs.cloud.google.com, read 2026-10-23).
Two consequences for the test. First, a small set of generators behind one resolver can all land on the same endpoint, so a weighted or performance policy looks wrong when it is working. Spread generators across locations and resolvers, or test each endpoint directly as well. Second, routing is decided before your request leaves DNS, so a test only exercises failover if you actually take an endpoint down or mark it unhealthy during the run.
Which tools can generate load from several clouds?
Any tool that runs on a machine you control can run in any cloud. Apache JMeter and k6 are open source and run on a VM in AWS, Azure or Google Cloud; the cost is that you manage the machines, the clock sync and the result collection (see running a JMeter distributed test in the cloud).
A managed service removes that work but limits where generators live. LoadFocus states on its load testing page that it runs tests from 25 AWS regions worldwide (read 2026-10-23), and its main site describes 25+ cloud regions. So every LoadFocus generator runs on AWS. That is a good fit to measure how users in many places reach your app, wherever the app is hosted. It is not a way to start load from inside Azure or Google Cloud, for example to measure a call that never leaves that cloud’s network. For that, run your own k6 or JMeter there and report results beside the managed run.
Learn how LoadFocus works with JMeter scripts and k6 scripts on its product pages.
What should you watch out for in multi-cloud tests?
- Provider testing policies. AWS’s page on testing says network stress tests send legitimate high-volume traffic to a target expected to handle it, and that volumetric DDoS simulations are prohibited on EC2; it also says AWS may apply traffic shaping when surges exceed 25 Gbps (aws.amazon.com/ec2/testing, read 2026-10-23). Microsoft says DoS testing of any kind is prohibited for Azure resources, including tests that simulate DoS, and that network-intensive automated testing generating excessive traffic is not permitted (learn.microsoft.com, penetration testing page, updated 2026-07-24, read 2026-10-23). A load test is not a DoS test, but read the current rules for every provider you test against and keep the load to what you intend to serve.
- Cross-region and cross-cloud data transfer costs. Providers bill data leaving a cloud or region, with rates that change. Look up the current price pages before a large test, and keep test payloads realistic but not oversized. This article does not print prices.
- Network noise. Generator-to-app latency is part of every measurement. The network latency and load test accuracy post explains how to separate it from server time, and the multi-region deployment post covers apps that run in several regions.
- One-off runs. Latency across the internet varies with time of day. Repeat a test at different hours before drawing a conclusion about a provider.
Frequently Asked Questions
What is multi-cloud performance testing?
It is load testing an application that runs across more than one cloud, or load testing from generators placed in more than one cloud, and comparing latency and errors per region and per hop. The first needs journeys that cross providers; the second needs generators in different locations.
Can LoadFocus test from Azure or Google Cloud?
Its pages state that it runs tests from 25 AWS regions, so its generators are on AWS. It can test an app hosted on any cloud, as long as the app is reachable. To generate load from inside Azure or Google Cloud, run JMeter or k6 on your own machines there.
How do I test a Route 53, Traffic Manager or global load balancer setup?
Run the journeys through the real hostname from several locations, and also hit each endpoint directly for a baseline. DNS caching and a shared resolver can send many generators to one endpoint, so use generators in different places and take one endpoint out of service during a run to check failover.
Do I need approval from AWS, Azure or Google to load test?
Rules differ and change. AWS’s testing page covers network stress tests and prohibits volumetric DDoS simulation; Microsoft prohibits DoS testing of Azure resources. Read each provider’s current policy before a large run, and keep the load at the level you actually plan to serve.
How do I keep multi-cloud test costs under control?
Test the hot journeys instead of everything, keep runs short except for planned soak tests, and check each provider’s current data transfer prices before large runs. Measured usage after a pilot run gives you a better estimate than any rule of thumb.
Sources
- AWS: Choosing a routing policy, Route 53 Developer Guide, docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html (read 2026-10-23)
- Microsoft Learn: Traffic Manager routing methods (ms.date 2025-12-29), learn.microsoft.com/azure/traffic-manager/traffic-manager-routing-methods (read 2026-10-23)
- Microsoft Learn: Penetration testing (updated 2026-07-24), learn.microsoft.com/azure/security/fundamentals/pen-testing (read 2026-10-23)
- Google Cloud: Cloud Load Balancing overview, docs.cloud.google.com/load-balancing/docs/load-balancing-overview (read 2026-10-23)
- AWS: Amazon EC2 testing policy, aws.amazon.com/ec2/testing (read 2026-10-23)
- LoadFocus load testing page and index, loadfocus.com/load-testing, loadfocus.com/index.md (read 2026-10-23)
Published with PostNext
