Distributed Load Testing on AWS: a CloudFormation-deployed load generator with a JMeter, k6 and Locust container
Distributed Load Testing on AWS automates performance testing at scale, demonstrating how systems behave under different load conditions and helping identify potential performance issues throughout their lifecycle.
At a glance
- What is it?
- AWS ships a CDK-built solution that runs Taurus-based load tests on Fargate across Regions, driven by an API Gateway and a Cognito-protected console. It is a good fit when the target already lives in AWS; it is a poor fit when you want a load generator that does not depend on the system under test.
- Who is it for?
- Adopt it if your application already runs in AWS and you want load generators that scale by adding Fargate tasks rather than by renting machines, and if a Cognito-gated console plus an API is an acceptable control plane. Do not adopt it if you need the generator to sit outside the provider that hosts the target, or if your test scripts depend on Taurus options the solution's container image does not expose.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem: load generators that cannot keep up with the thing they are testing
A single machine generating HTTP requests tops out well before a modern application does. The usual workaround is to rent more machines, install JMeter on each, keep their clocks and versions aligned, and collect results by hand. Distributed Load Testing on AWS exists to remove that coordination work. The README describes the goal plainly: simulate thousands of connected users generating HTTP requests at a sustained rate "without the need to provision servers."
The audience named in the README is IT infrastructure architects, administrators and DevOps professionals with practical AWS experience. That is honest about the cost of entry. This is not a hosted service you sign into; it is a CloudFormation deployment into your own account, and the bill for the Fargate tasks, DynamoDB tables, S3 buckets and CloudWatch logs lands on you. If your team has no one comfortable reading a CloudFormation stack, the setup will be the hard part, not the testing.
How the pieces fit: API Gateway, Step Functions, Fargate containers and an IoT Core live feed
The control plane is an API. According to the architecture overview, a distributed load tester API uses Amazon API Gateway to invoke Lambda microservices, which hold the business logic for managing test data and running tests. Those functions read and write Amazon S3 and Amazon DynamoDB, and use AWS Step Functions to orchestrate execution. The repository layout matches this: the npm workspaces list includes start-command, task-runner, task-status-checker, task-canceler, task-failure-handler, orphan-cleanup, regional-sync, sfn-failure-handler, test-cleanup, test-metadata-updater and real-time-data-publisher. Each of those is a separate Lambda concern, which tells you the failure handling was designed as a first-class problem rather than bolted on.
The data plane is Fargate. A VPC is deployed containing ECS containers running on AWS Fargate, built from an Amazon Linux 2023 base image with the Taurus load testing framework installed. Taurus is what lets one container image accept JMeter, K6 and Locust scripts. The image is OCI compliant and hosted by AWS in an Amazon ECR public repository, and the documentation points to a container image customization page if you need to change it.
Results follow two paths. When a test finishes, the solution stores results in S3 and DynamoDB and writes logs to CloudWatch. If the live data option is enabled, CloudWatch logs from the Fargate tasks are sent during the run to a Lambda function, which publishes them to AWS IoT Core in the region of the main stack, and the web console subscribes to that topic. That is a deliberate design: the console does not poll a database, it subscribes to a message topic, so the live view reflects the test as it runs rather than after it ends.
The console itself is an AWS Amplify application deployed into an S3 bucket configured for static web hosting, with CloudFront providing public access. Access is managed by an Amazon Cognito user pool covering the console, the API, and the MCP Server. During initial configuration the solution creates a default administrator IAM role and sends an access invite to an email address you specify.
Installing it and running a first test scenario
The README's fastest path is a CloudFormation launch in the AWS Console, using a template URL hosted in the solutions-reference S3 bucket. That path needs no local toolchain. The repository's local development path is different, and it is the one the Makefile and .env.example describe.
The Makefile refuses to run without a .env file, so the first step is copying the example. Note the guard rails: the Makefile rejects any value containing a single quote or a dollar sign, and it derives the list of variables to check from .env itself rather than from a hardcoded list.
cp .env.example .envThen edit the values. The example file names the region, the stack names, and the admin identity. MAIN_STACK_NAME has three commented alternatives, and the comment on each line tells you which deployment mode it selects.
TARGET_REGION=us-west-2
MAIN_STACK_NAME=distributed-load-testing-on-aws
REGIONAL_STACK_NAME=distributed-load-testing-on-aws-regional
ADMIN_NAME=username_no_spaces
[email protected]ADMIN_NAME is documented as needing no spaces, and ADMIN_EMAIL is the address that receives the Cognito access invite. If you pick the ALB + ECS stack instead, the example file marks CONSOLE_DOMAIN_NAME and ACM_CERTIFICATE_ARN as required for that mode.
For multi-region runs, REGIONAL_STACKS takes a space-separated list of regions, and the comment says make regional-deploy deploys to them sequentially. A single-region override is available on the same target.
REGIONAL_STACKS=us-west-2 eu-west-1 ap-southeast-2After deployment, the workflow is: open the console, create a test scenario, choose the script type, and run it immediately, at a future date and time, or on a recurring schedule. The README states that multiple load tests can run concurrently across different scenarios and regions. The package.json engines field requires Node.js 24 or newer for local work, and the root scripts are lint, fmt, typecheck and test, each delegating to workspaces.
Where it stops being the right tool
The most consequential limitation is not in the code, it is in the topology. The load generators run inside the same cloud that usually hosts the target. Traffic from a Fargate task in us-west-2 to an application in us-west-2 does not cross the public internet the way a real user's request does. Latency numbers from that run describe your internal network, not your customers' experience. If the thing you are trying to measure is edge latency or CDN behavior, this solution measures the wrong path.
The second constraint is the container image. Tests run through Taurus on an Amazon Linux 2023 base image hosted in an AWS public ECR repository. The README points to a container image customization page, which is an acknowledgement that the stock image will not cover every script. Any JMeter plugin, k6 extension or Python dependency your existing scripts rely on has to be added through that path, and the README does not document rollback if a customized image breaks a scheduled recurring test.
Third, the control plane is opinionated. Cognito manages access to the console, the API and the MCP Server, and the solution creates a default administrator role during initial configuration. That is convenient, and it also means you inherit an identity model rather than bringing your own. The README does not describe how to substitute an existing identity provider.
Finally, the deployment itself is a commitment. The architecture spans API Gateway, Lambda, S3, DynamoDB, Step Functions, a VPC, ECS on Fargate, CloudFront, Cognito, IoT Core and CloudWatch. Each of those is a component with its own cost and its own operational surface. A team that wants to run a k6 script for ten minutes on a laptop will find this a heavy way to do it.
The optional MCP Server and what it changes about analysis
The repository ships a source/mcp-server workspace, and the README describes the integration as optional and deployed only if you select the MCP Server option. The flow is specific: an MCP client, described as an AI development tool, connects to an AWS AgentCore Gateway endpoint. The gateway validates the user's Cognito token, then forwards the MCP tool request to the DLT MCP Server Lambda function. That function queries DynamoDB tables, S3 buckets or CloudWatch logs and returns structured data through the gateway to the client.
The design choice worth noting is that the gateway, not the Lambda, performs authentication. That keeps the Lambda free of token validation logic and means access control is centralized at the Cognito boundary. It also means the AI tool never talks to your data stores directly; it talks to a gateway that talks to a function that talks to them. For teams wary of handing a model broad access to production telemetry, that layering is the point. The README does not describe what happens when the Cognito token expires mid-session.
Alternatives and how they differ in approach
Azure Load Testing is the closest structural alternative, and the difference is architectural rather than cosmetic. It is a managed service on Azure, so the generators live in Microsoft's cloud and you do not deploy a stack into your own account. If your application runs on Azure, that removes the entire CloudFormation and Cognito setup described here. If your application runs on AWS, it introduces the cross-cloud traffic path that the AWS solution avoids. The two tools are mirror images, and the deciding question is which cloud hosts the target.
For teams that want the generator outside the target's network entirely, a self-managed k6 or Locust install on independent machines remains the honest comparison. You lose the scheduled execution, the multi-region fan-out, the console and the live IoT feed, and you gain control over exactly where the traffic originates. The README's own framing supports this reading: the value proposition is automation and scale without provisioning servers, not measurement fidelity relative to a real user's network.
Licence, maintenance and the cost of keeping up
The repository's LICENSE.txt is what the GitHub metadata reports as NOASSERTION, but package.json states "license": "Apache-2.0" and the author is Amazon Web Services. Apache-2.0 is permissive and includes an explicit patent grant, which matters for a solution you deploy into your own account. Read LICENSE.txt and NOTICE yourself rather than relying on either field; the two disagree, and only the file is authoritative. Nothing here is legal advice.
On maintenance, the last push to the default branch was on 2026-09-09, and the most recent release, v4.2.5, is dated the same day. The two releases before it, v4.2.4 and v4.2.3, landed on 2026-09-02 and 2026-08-19. That is a steady cadence of small version bumps rather than large ones, which is consistent with a solution that is being kept current rather than redesigned.
The upgrade cost is the part worth planning for. This is a CloudFormation deployment built from CDK constructs, and the README notes that CloudFormation resources are created from AWS CDK constructs. Upgrading means re-deploying the stack, and a customized container image is a separate artifact you maintain. The repository includes a stabilization-checker workspace and a regional-compatibility.json file, which suggests regional differences are tracked explicitly, but the README does not document an upgrade procedure or a rollback path. Verify both against the deployment documentation before you put a recurring schedule on a production target.
Editorial conclusion
Adopt it if your application already runs in AWS and you want load generators that scale by adding Fargate tasks rather than by renting machines, and if a Cognito-gated console plus an API is an acceptable control plane. Do not adopt it if you need the generator to sit outside the provider that hosts the target, or if your test scripts depend on Taurus options the solution's container image does not expose. Before committing, verify the two things the README leaves open: which deployment template matches your region (the ALB + ECS template exists precisely because some regions lack CloudFront), and whether the container image customization path covers the plugins your existing JMeter or k6 scripts already use.
Frequently asked questions
Can you give me an example of load testing with Distributed Load Testing on AWS?
The README describes creating a test scenario in the web console and running it immediately, at a future date and time, or on a recurring schedule. The scenario can use a JMeter, K6 or Locust script, or a simple HTTP endpoint configuration, and the solution then runs ECS tasks on Fargate in the specified Regions.
How do I install Distributed Load Testing on AWS?
The README's primary path is a Launch in the AWS Console button that creates a CloudFormation stack from a template hosted in the solutions-reference S3 bucket. The repository also supports a local path: copy .env.example to .env, fill in TARGET_REGION, the stack names and the admin email, then deploy through the Makefile. The Makefile will not run without a .env file.
Which test script formats does Distributed Load Testing on AWS support?
The README lists JMeter, K6 and Locust scripts, plus a simple HTTP endpoint configuration. All three run through the Taurus framework installed in the Amazon Linux 2023 container image, which is hosted by AWS in an Amazon ECR public repository.
Does Distributed Load Testing on AWS work without CloudFront?
The README describes three deployment templates. The default serves the web console via CloudFront and S3 and is described as suitable for most regions, while the ALB + ECS template hosts the console behind an Application Load Balancer with ECS Fargate for regions without CloudFront or with secure network requirements. The ALB + ECS mode requires CONSOLE_DOMAIN_NAME and ACM_CERTIFICATE_ARN in .env.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/aws-solutions-distributed-load-testing-on-aws)