WPLoadTester 7 runs load engines inside your own AWS account. Our license is flat. EC2 bills at AWS's rate, straight to your account. No per-VU-hour. No compute premium. Savings grow with scale.
SaaS load-test platforms charge per virtual-user-hour. Your costs scale with their margin. WPLoadTester's Cloud license is a flat fee — your only variable cost is raw EC2 in your own account.
We size cloud runs on m5.large instances (2 vCPU, 8 GiB RAM, on-demand ~$0.096/hr in us-east-1), each generating about 500 concurrent HTTP virtual users on typical API/web test cases. WPLoadTester's controller provisions and terminates the fleet automatically.
Worked example, against the typical per-VU-hour SaaS rate of ~$0.15/VU-hour — the published rate at LoadRunner Cloud, Grafana Cloud k6 Pro, and Azure Load Testing's first 10,000 VU-hour tier:
| Test size | m5.large fleet | Per-VU-hour SaaS (~$0.15) | WPLoadTester Cloud: license + EC2 |
|---|---|---|---|
| 1,000 VU × 1 hr | 2 instances | ~$150 | license + <$1 EC2 |
| 5,000 VU × 1 hr | 10 instances | ~$750 | license + $1 EC2 |
| 10,000 VU × 1 hr | 20 instances | ~$1,500 | license + $2 EC2 |
| 50,000 VU × 2 hr | 100 instances × 2 hr | ~$15,000 | license + $20 EC2 |
| 100,000 VU × 4 hr | 200 instances × 4 hr | ~$60,000 | license + $77 EC2 |
| 500,000 VU × 8 hr | 1,000 instances × 8 hr | ~$600,000 | license + $770 EC2 |
EC2 rates from AWS on-demand pricing in us-east-1 (April 2026), cross-referenced in our published cloud pricing table. 500 concurrent VU per m5.large is a conservative default — actual per-instance capacity depends on payload size, think-time, and response size, and heavy workloads may want m5.xlarge. Reserved-instance and Spot pricing drop these numbers further. The shape of the curve is what matters: per-VU-hour SaaS cost scales linearly with test size; WPLoadTester's doesn't.
Load should come from where your customers come from. For any public-facing application — e-commerce, SaaS, APIs — that means running load engines in AWS regions outside your target's, so test traffic takes the same internet path a real user's request would: public DNS, TLS handshake, CDN edge, cross-region latency.
Home and corporate broadband have closed a lot of the historical gap vs on-net load generation, but cross-region traffic still surfaces CDN cache behavior, TLS overhead, and queuing effects that an engine sitting next to your application simply won't see. The engines themselves still run in your AWS account at raw EC2 rates — they're just in the regions where your users actually are.
Private internal applications are the secondary case. If the target isn't internet-reachable — admin tools, back-office services, staging environments behind a firewall — the load engines co-locate in the target's VPC and traffic never leaves. Same license, same tool, different topology.
Engines deploy to the AWS regions you pick — us-east-1, eu-west-1, ap-southeast-1, wherever your users actually are. Latency, DNS, TLS, and CDN behavior reflect what a real request goes through.
Every EC2 instance bills straight through your existing AWS invoice at on-demand, reserved, or Spot pricing. No SaaS margin sitting between you and raw compute.
Internal-only target? Engines co-locate in the target's VPC, traffic never crosses the AWS boundary, and credentials stay inside your network. Compliance scope unchanged.
You've already approved AWS. You've already got an enterprise agreement. You've already got reserved capacity, volume discounts, credits, and tagging. WPLoadTester 7 Cloud just slots into that — your load-test compute shows up on your existing AWS invoice alongside everything else, with the same tags, in the same cost center.
Compare that to onboarding a new SaaS vendor: security review, data-processing agreement, procurement cycle, a separate invoice in a different currency, and — when test volume spikes — a bill that's on their margin, not AWS's margin.