Create a test scenario

Creating a test scenario involves four main steps: configuring general settings, defining the scenario, shaping traffic patterns, and reviewing your configuration.

Step 1: General settings

Configure the basic parameters for your load test including test name, description, and general configuration options.

Test identification

Scheduling options

Configure when the test should run:

Scheduling workflow

When you schedule a test, the following workflow occurs:

Live data

Select the Include live data checkbox to view real-time metrics while your test is running. When enabled, you can monitor:

The live data feature provides real-time charting with data aggregated at one-second intervals. For more information, refer to Monitoring with live data.

Step 2: Scenario configuration

Define the specific testing scenario and select your preferred testing framework.

Test type selection

Choose the type of load test you want to perform:

Traffic shape mode

Choose which side controls the load the test generates. The mode you select changes the fields the console shows in Step 3: Traffic shape.

Native requires an uploaded script, so you can’t select it when you choose the Simple HTTP Endpoint test type. For the full definitions and guidance on which mode to choose, refer to Traffic shape modes.

HTTP endpoint configuration

When "Simple HTTP Endpoint" is selected, the solution generates a JMeter test plan from your configuration and executes it with the bundled Apache JMeter binary. Configure these settings:

Test framework scripts

When using JMeter, k6, or Locust, upload your test script file or a .zip archive containing your test script and supporting files.

For JMeter, you can include custom plugins in a /plugins folder within your .zip archive.

For Locust, a test script inside a .zip archive must be named locustfile.py. To install third-party Python packages into the container at run time, include a requirements.txt file in the archive, and optionally a packages subdirectory of wheel files to install them without internet access. For more information, refer to Locust tests.

Safety duration (Native mode)

When you select Native mode, the console shows a Safety duration field alongside the script upload. The default is 4 hours and the maximum is 24 hours.

In Native mode, the safety duration ends a test that runs longer than you intended, because your script decides when the run finishes. It is a guard, not a schedule. If the test is still running when the duration elapses, the solution stops the testing framework. It keeps the results for the portion that ran and records the run as complete rather than failed. Set it above the longest run you expect the script to need.

Step 3: Traffic shape

Configure how traffic will be distributed during your test, including multi-Region support.

Traffic shape modes

The solution offers two traffic shape modes, Standard and Native. They differ in which side controls the load: the solution, or the script you upload. You select the mode in Step 2: Scenario configuration, and it determines which of the fields below apply.

Standard

Standard mode puts the solution in control of the load. You set the number of Fargate tasks per Region, the concurrent virtual users per task, a ramp-up period, and a hold duration. The solution runs your test through the Taurus automation framework, which translates those values into the underlying framework’s own load controls. Taurus takes precedence over whatever load your script declares, so a k6 options block, a Locust LoadTestShape, or a JMeter thread group is rewritten or ignored. A Region’s virtual users are the task count multiplied by the concurrency for each task, and the shape is the same whichever framework you chose. This is how every test ran before version 4.3.0, so scenarios created earlier keep behaving exactly as they did and need no changes.

Choose Standard when the load shape belongs outside the script, set from the console, the CLI, or an agent. Standard is the only mode that lets you set an exact virtual-user count and change the ramp-up and hold shape without touching the script. Only Standard supports the Simple HTTP Endpoint type, where the solution generates the test plan for you. Typical uses: a capacity check stepping 500 to 5,000 virtual users, a nightly regression holding 1,000 users for ten minutes, or any comparison needing an identical ramp. Its limit is expressiveness. Anything Taurus cannot represent is unavailable here, including multiple weighted scenarios, per-stage thresholds, and arrival-rate executors.

Native

Native mode puts your script in control of the load. The solution runs the file you uploaded under the framework’s own command line: jmeter -n -t, k6 run, or locust --headless. It passes no load flags, so your script is the sole authority on the traffic it generates and the solution never rewrites it. Two controls remain: how many Fargate tasks to launch per Region, and a required safety duration of up to 24 hours. The safety duration is a guard against a script that never exits, not a schedule. If a test is still running when the duration elapses, the solution stops the framework, collects the results for the portion that ran, and records the run as complete rather than failed. Each task runs as an independent framework process with no coordination between tasks, so a Region generates one full copy of your script’s declared load for each task. For example, a k6 script that holds 200 virtual users, run on five tasks, puts 1,000 virtual users on the target. Task count is therefore the only load control Native gives you, and it moves in whole multiples of whatever the script declares. Changing the ramp, the hold time, or the virtual-user count itself means editing the script.

Choose Native when you want to run a script exactly as it was written. A script that already runs locally or in CI runs unchanged on the solution, which is the main reason to reach for Native. Native preserves everything the framework can express: k6 scenarios, stages, and thresholds; Locust LoadTestShape classes and weighted task sets; JMeter timers and thread groups. Pick it when the load shape is part of what the test means, and reproducing it faithfully matters more than steering it from outside. Typical uses: reusing a k6 script from a pipeline without rewriting it, a spike-then-recover profile, or weighted scenarios that a single concurrency number cannot express. Two constraints follow from running the framework as authored. Native requires an uploaded script, so Simple HTTP Endpoint is unavailable. Locust scripts must not set processes, because the solution counts requests only when Locust runs as a single process.

Choosing a mode

Multi-Region traffic configuration

Select one or more AWS Regions to distribute your load test geographically. For each selected Region, configure:

Determine the number of users

The number of users a container can support for a test can be determined by gradually increasing the number of users and monitoring performance in Amazon CloudWatch. Once you observe that CPU and memory performance are approaching their limits, you’ve reached the maximum number of users a container can support for that test in its default configuration (2 vCPU and 4 GB of memory).

This calibration sets the Concurrency value, so it applies to Standard mode. The container limits it establishes apply to Native mode as well. There you raise or lower the load your script declares, instead of setting the Concurrency field.

Calibration process

You can begin determining the concurrent user limits for your test by using the following example:

Repeat steps 1-3 if the test did not exceed the resource limits. Optionally, you can increase the container resources to allow for a higher number of concurrent users. However, this results in a higher cost. For details, refer to the Developer Guide.

For more information on calibrating users per engine, refer to Calibrating a Taurus Test in the BlazeMeter documentation.

Table of available tasks

The Table of Available Tasks displays resource availability for each selected Region:

To increase the number of available tasks or vCPUs per task, refer to the Developer Guide.

Test duration

Define how long your load test will run. The console shows this section in Standard mode only. In Native mode your script determines how long the test runs, bounded by the safety duration you set in Step 2: Scenario configuration.

Step 4: Review and create

Review all your configurations before creating the test scenario. Verify:

After reviewing, choose Create to save your test scenario.

Managing test scenarios

After creating a test scenario, you can: