To load test a multi-region deployment, generate traffic from the regions your users are in, send it through the same global routing they use, and measure four things a single-region test never shows: per-region response times, replication lag, behaviour during a regional failure, and the capacity of every region on its own. A test that hits one region from one place tells you almost nothing about the others.
Key Takeaways
- Test from where your users are. Load from one location measures one network path. Split virtual users across the regions your traffic really comes from.
- Replication lag is a test result, not a footnote. Write in one region, read in another, and record how long the new value takes to appear.
- Failover needs its own test. Take a region out of service while load is running and time how long users see errors, and how much data is missing afterwards.
- DNS decides which region answers. Check that each load generator really lands on the region you expect, and that the failover record moves traffic when the primary is unhealthy.
- Size every region for failover. If one region fails, the others take its traffic. Test them at that load.
What changes when an app runs in several regions
In one region, a load test mostly measures your application and database. With several regions, a request also crosses DNS, a routing decision and sometimes a long network path, and data written in one place has to reach the others. The result is that the same endpoint can be fast in Frankfurt, slow in Sydney and wrong for a second after a write in Virginia, all in the same test run.
There is no single latency number to quote for “multi-region”. Round-trip time depends on which two regions talk, and the cloud providers publish their own measurements; measure your own pairs. For the network side of this, see how network latency distorts cloud load test results and network jitter in cloud load testing.
How do you generate load for a multi-region application?
Generate load from the regions where your real users are, in the same proportions as real traffic, and aim it at the public hostname users use, not at one region’s internal address. Then compare results per source region: response time percentiles, error rate and which region actually served the request.
Two traps are easy to hit:
- Load generators that resolve to the wrong region. DNS routing decides by the resolver or client network. Azure’s Traffic Manager documentation notes that it sees the address of the recursive DNS resolver, not the client, and that when only a few resolvers are involved, caching can skew weighted distribution significantly (learn.microsoft.com, read 2026-10-23). A load test run from a few machines can therefore all land in one region. Log the serving region in a response header and count it per generator.
- Testing against the origin. If you skip the global routing layer, you skip the part that changes between single and multi-region. Where a CDN sits in front, see edge locations versus load generator regions and edge computing and load testing.
LoadFocus runs tests from 25 AWS regions and lets you split a test’s load across regions by percentage, for example 50% US East, 30% EU West and 20% Asia Pacific (loadfocus.com/load-testing, read 2026-10-23). The list of locations is on the locations page.
How do you test replication lag and data consistency?
Write a record through one region, then poll for it through another, and record the time until the new value is visible. Repeat under load, because replication competes with your application for capacity. Report the lag as a distribution (median and 99th percentile), not a single figure.
What the database promises differs by product, so read the numbers for yours:
- Amazon Aurora Global Database has one primary Region for writes and up to 10 read-only secondary Regions. Aurora replicates to the secondaries with latency “typically under a second” (docs.aws.amazon.com, read 2026-10-23). Reads in a secondary Region can therefore lag a write; write forwarding lets secondaries send writes to the primary, which adds a cross-Region hop to those writes.
- DynamoDB global tables default to multi-Region eventual consistency: changes replicate asynchronously, “typically within a second or less”, and concurrent writes to the same item resolve by last writer wins. A strongly consistent read can return stale data if the item was last updated in another Region. The optional multi-Region strong consistency mode needs exactly three Regions, has an RPO of zero, and has higher write latency. Replication also consumes write capacity, so a provisioned table can throttle when application writes plus replication exceed what is provisioned. DynamoDB publishes a
ReplicationLatencyCloudWatch metric for the eventual-consistency mode (docs.aws.amazon.com, read 2026-10-23). - Azure Cosmos DB offers five consistency levels, from strong to eventual. With strong consistency across several regions, write latency is two round trips between the two farthest regions plus 10 ms at the 99th percentile, and strong consistency is blocked by default when regions are more than 5,000 miles (8,000 km) apart. Accounts with multiple write regions cannot use strong consistency (learn.microsoft.com, page dated September 2025, read 2026-10-23).
Design the test around what your application assumes. If a user updates a profile and the next page reads from another region, that read-your-write path needs its own scenario. If your code writes the same record from two regions, test that too: last-writer-wins silently drops one of the writes.
How do you test failover under load?
Start a steady load, remove a region, and keep the load running while you measure three numbers: how long users see errors, how long until traffic is fully served by the surviving regions, and how much recent data is missing after the switch. The first two are your real recovery time, the third your real recovery point.
Ways to cause the failure:
- Stop the application tier in one region, or block it at the load balancer.
- Pause replication to simulate a region that is cut off. AWS Fault Injection Service can simulate Region isolation for DynamoDB global tables by pausing replication to and from a replica (docs.aws.amazon.com, read 2026-10-23).
- For databases, rehearse the documented procedure. Aurora distinguishes a switchover (planned, no data loss) from a failover (recovery after an outage in the primary Region) (docs.aws.amazon.com, read 2026-10-23). They are different tests with different expected data loss.
Run the failover test against a staging copy first, and agree the blast radius before running anything similar in production. Do not trust a failover number measured with an idle system: the recovering region may receive a full region’s traffic at once.
How do you test DNS and global routing?
Check that the routing policy sends each user group to the region you intended, and that it moves them when the primary is unhealthy. Route 53 offers simple, failover, geolocation, geoproximity, latency, IP-based, multivalue and weighted policies (docs.aws.amazon.com, read 2026-10-23); Azure Traffic Manager offers Priority, Weighted, Performance, Geographic, Multivalue and Subnet methods, applies one method per profile, and includes health monitoring and automatic failover (learn.microsoft.com, read 2026-10-23).
What to test:
- Steady state: each generator region reaches the expected serving region.
- Health-check failover: mark the primary unhealthy and time how long clients keep reaching it. DNS answers are cached by resolvers and clients, so some users keep the old answer until it expires; your TTL and the health-check interval set that window.
- Weighted shifts: when you move 10% of traffic to a new region, confirm the split in the access logs, not in the DNS configuration.
- Failback: returning traffic to the recovered region is a second event, with its own cold caches and warm-up.
How do you test capacity in each region?
Test each region at the load it carries in a failure. If three regions each run at 40% and one fails, the other two take roughly 60% each, plus the retries and reconnects that a failure brings. Autoscaling that reacts in minutes may not cover a spike that arrives in seconds, so include a step-up test, and check that quotas and limits are the same in every region. Differences between regions (instance limits, database size, cache sizes, feature flags) are a common reason one region degrades first. A full multi-cloud variant of this setup is in end-to-end performance testing for multi-cloud, and if tenants are separated by region see load testing multi-tenant SaaS applications.
Frequently Asked Questions
How is load testing multi-region different from multi-AZ?
Availability zones in one region sit close together, so a single-region test from one location covers most of the picture. Across regions you add distance, routing and replication, so you need load from several locations and checks on data freshness and failover.
Do I need to load test every region?
Yes, each region on its own and the set together. Each region carries real users in normal operation and the others’ traffic during a failure, and differences in configuration only show under load.
How do I measure replication lag during a load test?
Write a record with a timestamp through one region and poll for it through another, recording the delay. Run it continuously during the test and report percentiles. Database metrics such as DynamoDB’s ReplicationLatency help, but an application-level probe measures what users see.
How long should a failover take?
It depends on your design, health-check settings, DNS caching and database. There is no universal figure; the useful number is the one you measure, compared with the recovery time and data-loss limits your business has set.
Can I run all of this from one load generator location?
No. One location gives one network path and, through DNS, usually one serving region. Use generators in several regions and confirm which region served each request.
Sources
- Amazon Aurora Global Database, docs.aws.amazon.com (AuroraUserGuide, aurora-global-database), read 2026-10-23.
- How DynamoDB global tables work, docs.aws.amazon.com (developerguide, V2globaltables_HowItWorks), read 2026-10-23.
- Choosing a routing policy, Amazon Route 53, docs.aws.amazon.com (DeveloperGuide, routing-policy), read 2026-10-23.
- Traffic Manager routing methods, learn.microsoft.com (azure/traffic-manager), page dated December 2025, read 2026-10-23.
- Consistency level choices, Azure Cosmos DB, learn.microsoft.com (azure/cosmos-db/consistency-levels), page dated September 2025, read 2026-10-23.
- LoadFocus load testing page, loadfocus.com/load-testing, read 2026-10-23.
