Cloud Load Generation

Serious scale needs serious injection capacity. We run distributed load generation fleets in AWS — elastic, geographically distributed, and torn down the moment the test ends.

Why cloud generation

Testing an internet-facing platform from inside its own datacentre measures a system that doesn't exist: no real network path, no TLS handshake cost at the edge, no geographic latency mix. Cloud generators place load where users are — Sydney, Singapore, US-East — and scale to hundreds of thousands of virtual users without a permanent fleet to own.

Architecture

Our standard rig: containerised k6/JMeter/Gatling workers on ECS Fargate or EC2 spot fleets, orchestrated per-run from infrastructure-as-code; a results pipeline streaming metrics to a central InfluxDB/Grafana stack; and a control node coordinating ramp synchronisation across regions. Everything is defined in Terraform/CloudFormation — a test rig is created for the engagement and destroyed after, so you pay for hours, not months.

Injection fleet — 100k VU example
  ap-southeast-2 : 40 × c6i.2xlarge   (60% of load)
  ap-southeast-1 : 20 × c6i.2xlarge   (25%)
  us-east-1      : 12 × c6i.2xlarge   (15%)
  results        : InfluxDB + Grafana, live
  cost           : compute billed only for run hours

Generator discipline

The most common distributed-testing error is a saturated generator reporting application latency. Every fleet we run monitors its own CPU, memory, GC, socket counts and bandwidth; generator headroom is verified at each load step, and fleets are sized with at least 40% margin over the target load.

Practical considerations

We coordinate with your hosting/CDN/WAF providers before large tests (most have load-testing notification policies), source IP ranges are published for allow-listing, and ramp profiles respect any rate limits you deliberately keep in place — testing through protections you'd disable for the test produces fiction.