Skip to main content

Edge Locations vs Load Generator Regions in Cloud Testing

Edge Locations vs Load Generator Regions in Cloud Testing

Key Takeaways

  • An edge location (a CDN point of presence) is where your users are served from. A load generator location is where your test traffic starts. They are different things, and a load test cannot place generators inside a CDN’s edge locations.
  • Generator location changes what you measure: the network path, which CDN edge location answers, and which cache you hit. A test from one region describes users in that region only.
  • Choose generator regions from where your real users are, then split the virtual users between them in the same proportions. LoadFocus offers 25 AWS regions on every plan and a per-region percentage split on Pro and Enterprise (loadfocus.com/jmeter-load-testing, October 2026).

What is an edge location?

An edge location is a point of presence (POP) in a CDN: a site close to viewers that caches content and answers requests. AWS describes it as the place DNS routes a viewer to, “typically the nearest CloudFront POP in terms of latency”. On a cache miss the POP typically asks a regional edge cache, which has a larger cache, and only then your origin (docs.aws.amazon.com, How CloudFront delivers content, October 2026).

Edge locations belong to the CDN, not to you. You do not run tests from inside them. What you control in a load test is where the traffic starts, and the edge location that answers is decided by the CDN’s routing from that starting point. For what the CDN cache does to your results, read edge computing and load testing rather than repeating it here.

Why does generator location change load test results?

Three things change when you move the generators:

  1. The network path. More distance and more hops mean more latency before your server does any work. Network latency and load testing accuracy covers the distance and connection-setup arithmetic.
  2. Which edge location answers. Traffic from Frankfurt reaches a European POP, traffic from Sydney reaches an Asia Pacific one. Each POP has its own cache, so a warm cache in one place says nothing about another.
  3. Routing decisions that depend on source. DNS geo-routing, geo-blocking, WAF rules and per-IP rate limits all look at where the request comes from. A test from one data-centre region can pass all of them in a way real users in other countries do not.

A single-region test therefore answers “how does this behave for users near that region”. It does not answer it for everyone else.

Which regions should you test from?

Start from your users, not from the list of available regions.

  1. Take your analytics (country or city share of sessions, or of API calls) and keep the locations that cover most of your traffic, plus any market the business cares about.
  2. Match each to the nearest generator region.
  3. Weight the virtual users in the same proportions.
  4. Add one run from the same region as your origin. It shows server time with almost no network, and the gap to the other runs is your network cost.

LoadFocus lists 25 cloud locations (read October 2026): US East (N. Virginia and Ohio), US West (N. California), Canada (Central), eight in Europe (Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm, Zurich), Africa (Cape Town), nine in Asia Pacific (Hong Kong, Hyderabad, Jakarta, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo), Middle East (UAE), Israel (Tel Aviv) and South America (Sao Paulo). The load testing page calls them 25 AWS regions.

A worked split, using invented numbers: if analytics say 55 percent of sessions come from Western Europe, 30 percent from the US East coast and 15 percent from India, a 1,000-user test sends 550 from Frankfurt or Paris, 300 from N. Virginia and 150 from Mumbai.

How do you split virtual users per region?

On Pro and Enterprise you choose what share of the virtual users each region sends. LoadFocus’s JMeter page gives 60 percent Europe and 40 percent US East as its example, and the load testing page gives 50, 30 and 20 percent across three regions (loadfocus.com, October 2026). The pages do not state a separate per-region cap, so the plan’s concurrent virtual user limit is what applies, spread across the regions you pick.

A tester’s rule of thumb: if you want to compare regions, run each one alone first at the same load. Run the combined mix afterwards for the capacity result. Mixed-only tests hide which region is slow, because the overall percentile averages them together. Network jitter and load testing has a section on separating network from server with multi-location runs, and multi-region deployment and load testing covers the case where the application itself runs in several regions.

What can generator locations not tell you?

  • They are data-centre addresses, not users. A generator in an AWS region has a fast, stable connection. Real users arrive over mobile networks, home Wi-Fi and congested ISPs. Generator tests show a clean lower bound on latency, not the user experience.
  • A region is not a POP. A CDN may have far more edge locations than a test platform has regions, so one generator region stands in for many nearby cities.
  • Coverage has gaps. The list above has no mainland China location and no region in much of Central Asia. If those markets matter, test with a different tool or from your own machines there and say so.
  • Few source addresses can trigger protection. Many virtual users from one region share a small set of IPs, which can trip per-IP rate limits or a WAF. LoadFocus has an IP allow-list page (loadfocus.com/whitelist-ips) for that, and the CDN’s own testing rules apply too.
  • Real user monitoring answers a different question. For what actual visitors experience, use field data. Load tests measure capacity under controlled traffic.

A short checklist

  1. List your user locations from analytics.
  2. Pick the nearest generator regions and set the user split to match.
  3. Run each region alone, then the mix.
  4. Record the CDN’s cache status per request, and warm the cache or note that it is cold.
  5. Add a same-region-as-origin run as the baseline.
  6. Check that your WAF and rate limits allow the generator addresses.
  7. Compare percentiles per region, not one overall number.

Frequently Asked Questions

What is the difference between an edge location and a load generator region?

An edge location is a CDN point of presence that serves your users. A generator region is a cloud region where the test software runs and from which traffic starts. You choose generator regions; the CDN decides which edge location answers them.

Can I run a load test from CDN edge locations?

No. You run tests from the regions your tool offers, and the CDN routes that traffic to one of its edge locations. Testing a CDN you do not own may also need the provider’s approval.

How many regions does LoadFocus offer?

25 AWS regions, available on every plan including Free, listed on loadfocus.com/locations as of October 2026. Splitting the virtual users per region by percentage is a Pro and Enterprise feature.

Should I test from the region closest to my servers?

Do it once as a baseline, because it shows server time with little network in the way. Then test from where your users are, since that is where the latency and CDN behaviour you care about appear.

How many regions are enough?

Enough to cover the markets that make up most of your traffic, usually two to four. More regions add detail but also more runs to compare and more variables to explain.

Sources

Bogdan

Founder at LoadFocus

Bogdan builds and runs the tools this blog is about. He writes from what the products actually do in production, including the parts that break.

Weekly tips right in your inbox.

Don’t miss out on the latest testing tips and tricks, tools and news related to software testing.

Already +20,000 members in the list.

The Load Testing Platform with AI That Explains Your Results

Load test websites and APIs from 25 cloud regions, monitor page speed and uptime, and get AI analysis that explains your results in plain English.

Cloud load testing, website speed and API monitoring in one place.

Hi there! Can I share a cool thing I'm working on with you?

A software testing newsletter that sparks joy.

Our goal is to create helpful content for software developers and testers.

If you're not into it, you can unsubscribe instantly.