Merge pull request #269 from aws-solutions/release/v4.0.2

Changes for release/v4.0.2

Author: ianwow

CHANGELOG.md

@@ -5,6 +5,25 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [4.0.2] - 2025-12-09
+
+### Changed
+
+- `jetty-http` package has been reverted to a previous version to support [HTTP2](https://github.com/Blazemeter/jmeter-http2-plugin/blob/master/README.md) JMeter plugin.
+- Improvements to cron-base scheduling with clarification between UTC and local time zones.
+
+### Fixed
+
+- Resolved issues related to zipped files when migrating from v3 for v4. Load tests created in v3 should now correctly reference the existing zip test script and be downloadable from the test scenario page.
+- Fixed a bug where tags would not be saved when creating or updating a scheduled load test.
+- Fixed a bug where non-integer http status code responses would fail to render in the results dashboard.
+
+### Security
+
+- Update to address vulnerability in [CVE-2025-66418](https://nvd.nist.gov/vuln/detail/CVE-2025-66418)
+- Update to address vulnerability in [CVE-2025-66471](https://nvd.nist.gov/vuln/detail/CVE-2025-66471)
+- Upgrade to the latest Amazon Linux base image SHA256 hash
+
 ## [4.0.1] - 2025-11-21
 
 ### Security

README.md

@@ -1,6 +1,14 @@
 # Distributed Load Testing on AWS
 
-The Distributed Load Testing Solution leverages managed, highly available and highly scalable AWS services to effortlessly create and simulate thousands of connected users generating a selected amount of transactions per second, originating from up to 5 simultaneous AWS regions. As a result, developers can understand the behavior of their applications at scale and at load to identify any bottleneck problems before they deploy to Production. [Launch in the AWS Console](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?&templateURL=https://solutions-reference.s3.amazonaws.com/distributed-load-testing-on-aws/latest/distributed-load-testing-on-aws.template&redirectId=GitHub)
+Distributed Load Testing on AWS helps you automate performance testing of your software applications at scale to identify bottlenecks before you release your application. This solution simulates thousands of connected users generating HTTP requests at a sustained rate without the need to provision servers.
+
+* Deploy Amazon ECS on AWS Fargate containers that run independently to test the load capacity of your application.
+* Simulate tens of thousands of concurrent users across multiple AWS Regions generating requests at a continuous pace.
+* Customize your application tests using [JMeter](https://jmeter.apache.org/), [K6](https://k6.io/), [Locust](https://locust.io/) test scripts, or simple HTTP endpoint configuration.
+* Schedule load tests to run immediately, at a future date and time, or on a recurring schedule.
+* Run multiple load tests concurrently across different scenarios and regions.
+
+The intended audience for using this solution's features and capabilities in their environment includes IT infrastructure architects, administrators, and DevOps professionals who have practical experience architecting in the AWS Cloud. As a result, developers can understand the behavior of their applications at scale and at load to identify any bottleneck problems before they deploy to Production. [Launch in the AWS Console](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?&templateURL=https://solutions-reference.s3.amazonaws.com/distributed-load-testing-on-aws/latest/distributed-load-testing-on-aws.template&redirectId=GitHub)
 
 ## On this Page
 
@@ -15,35 +23,49 @@ The Distributed Load Testing Solution leverages managed, highly available and hi
 
 ![Architecture](architecture.png)
 
-The high-level process flow for the solution components deployed with the AWS CloudFormation template is as follows:  
+Deploying this solution with the default parameters deploys the following components in your AWS account.
+
+> **Note**: AWS CloudFormation resources are created from AWS Cloud Development Kit (AWS CDK) constructs.
 
-1. A distributed load tester API, which leverages [Amazon API Gateway](https://aws.amazon.com/api-gateway) to invoke the solution's microservices ([AWS Lambda](https://aws.amazon.com/lambda) functions).
+The high-level process flow for the solution components deployed with the AWS CloudFormation template is as follows:
+
+1. A distributed load tester API leverages [Amazon API Gateway](https://aws.amazon.com/api-gateway) to invoke the solution's microservices ([AWS Lambda](https://aws.amazon.com/lambda) functions).
 
 2. The microservices provide the business logic to manage test data and run the tests.
 
-3. These microservices interact with [Amazon Simple Storage Service](https://aws.amazon.com/s3) (Amazon S3), [Amazon DynamoDB](https://aws.amazon.com/dynamodb), and [AWS Step Functions](https://aws.amazon.com/step-functions) to provide storage for the test scenario details and results and run test scenarios.
+3. These microservices interact with [Amazon Simple Storage Service](https://aws.amazon.com/s3) (Amazon S3), [Amazon DynamoDB](https://aws.amazon.com/dynamodb), and [AWS Step Functions](https://aws.amazon.com/step-functions) to store test scenario details and results and to orchestrate test execution.
+
+4. An [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc) (Amazon VPC) network topology deploys containing the solution's [Amazon Elastic Container Service](https://aws.amazon.com/ecs) (Amazon ECS) containers running on [AWS Fargate](https://aws.amazon.com/fargate).
 
-4. An [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc) (Amazon VPC) network topology is deployed containing the solution\'s [Amazon Elastic Container Service](https://aws.amazon.com/ecs) (Amazon ECS) containers running on [AWS Fargate](https://aws.amazon.com/fargate).
+5. The containers use an [Amazon Linux 2023](https://aws.amazon.com/linux/amazon-linux-2023/) base image with the [Taurus](https://gettaurus.org/) load testing framework installed. Taurus is an open-source test automation framework that supports JMeter, K6, Locust, and other testing tools. The container image is [Open Container Initiative](https://opencontainers.org/) (OCI) compliant and hosted by AWS in an [Amazon Elastic Container Registry](https://aws.amazon.com/ecr) (Amazon ECR) public repository. For more information, refer to [Container image customization](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/container-image.html).
 
-5. The containers include the [Amazon Linux 2023](https://aws.amazon.com/linux/amazon-linux-2023/) based [Open Container Initiative](https://opencontainers.org/) (OCI) compliant container image with the Taurus open-source test automation framework installed, which orchestrates load generation using Apache JMeter (default), K6, or Locust. The container image is hosted by AWS in an [Amazon Elastic Container Registry](https://aws.amazon.com/ecr) (Amazon ECR) public repository. For more information about the ECR image repository, refer to [Container image customization](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/container-image.html).
+6. A web console powered by [AWS Amplify](https://aws.amazon.com/amplify) deploys into an S3 bucket configured for static web hosting.
 
-6. A web console powered by [AWS Amplify](https://aws.amazon.com/amplify) is deployed it into an Amazon S3 bucket configured for static web hosting.
+7. [Amazon CloudFront](https://aws.amazon.com/cloudfront) provides secure, public access to the solution's website bucket contents.
 
-7. [Amazon CloudFront](https://aws.amazon.com/cloudfront) provides secure, public access to the solution\'s website bucket contents.
+8. During initial configuration, the solution creates a default administrator role (IAM role) and sends an access invite to a customer-specified user email address.
 
-8. During initial configuration, this solution also creates a default solution administrator role (IAM role) and sends an access invite to a customer-specified user email address.
+9. An [Amazon Cognito](https://aws.amazon.com/cognito) user pool manages user access to the console, the distributed load tester API, and the MCP Server.
 
-9. An [Amazon Cognito](https://aws.amazon.com/cognito) user pool manages user access to the console and the distributed load tester API.
+10. After you deploy this solution, you can use the web console or APIs to create and run test scenarios that define a series of tasks.
 
-10. After you deploy this solution, you can use the web console to create a test scenario that defines a series of tasks.
+11. The microservices use this test scenario to run ECS tasks on Fargate in the specified Regions.
 
-11. The microservices use this test scenario to run Amazon ECS on AWS Fargate tasks in the Regions specified.
+12. When the test completes, the solution stores results in S3 and DynamoDB and logs output in [Amazon CloudWatch](https://aws.amazon.com/cloudwatch).
 
-12. In addition to storing the results in Amazon S3 and DynamoDB, once the test is complete the output is logged in [Amazon CloudWatch](https://aws.amazon.com/cloudwatch).
+13. If you enable the live data option, the solution sends CloudWatch logs from the Fargate tasks to a Lambda function during the test for each Region where the test runs.
 
-13. If you select the live data option, the solution sends the Amazon CloudWatch logs for the AWS Fargate tasks to a Lambda function during the test, for each Region in which the test was run.
+14. The Lambda function publishes the data to the corresponding topic in [AWS IoT Core](https://aws.amazon.com/iot-core) in the Region where the main stack was deployed. The web console subscribes to the topic and displays real-time data while the test runs.
 
-14. The Lambda function then publishes the data to the corresponding topic in [AWS IoT Core](https://aws.amazon.com/iot-core) in the Region where the main stack was deployed. The web console subscribes to the topic, and you can see the data while the test runs in the web console.
+### MCP Server Integration (Optional)
+
+> **Note**: The following steps describe the optional MCP Server integration for AI-assisted load testing analysis. This component is only deployed if you select the MCP Server option during solution deployment.
+
+15. An MCP client (AI development tool) connects to the [AWS AgentCore Gateway](https://aws.amazon.com/bedrock/agentcore/) endpoint to access the Distributed Load Testing solution's data through the Model Context Protocol. AgentCore Gateway validates the user's Cognito authentication token to ensure authorized access to the MCP server.
+
+16. Upon successful authentication, AgentCore Gateway forwards the MCP tool request to the DLT MCP Server Lambda function. The Lambda function returns the structured data to AgentCore Gateway, which sends it back to the MCP client for AI-assisted analysis and insights.
+
+17. The Lambda function processes the request and queries the appropriate AWS resources (DynamoDB tables, S3 buckets, or CloudWatch logs) to retrieve the requested load testing data.
 
 ## Deployment
 
@@ -96,6 +118,9 @@ A NodeJS Lambda function that checks if the Amazon ECS tasks are running or not.
 **source/webui**<br/>
 React-based single page application that provides the web console interface for the solution. Built with Cloudscape Design System, Redux for state management, and AWS Amplify for authentication. Authenticated through Amazon Cognito, this dashboard allows users to create tests and view results.
 
+**source/mcp-server**<br/>
+A TypeScript package that implements the Model Context Protocol (MCP) server for AI-assisted load testing analysis. Provides structured access to DLT data through AWS AgentCore Gateway.
+
 ## Local Development
 
 For developers working on the solution locally, this section provides step-by-step instructions for setting up and deploying DLT from source code.

VERSION.txt

@@ -1 +1 @@
-4.0.1
+4.0.2

architecture.png

@@ -1,4 +1,4 @@
-FROM public.ecr.aws/amazonlinux/amazonlinux:2023-minimal@sha256:c69a151043b0e0e7d0362ab283299267580f5a5a4cf08131eb61b9528eaec882
+FROM public.ecr.aws/amazonlinux/amazonlinux:2023-minimal@sha256:3f6c5a2858113e9bb6710dfccdace7dc698e83f7a012240a1d07b3a46d273999
 
 RUN dnf upgrade -y --refresh && \
     dnf install -y python3.11 python3.11-pip java-21-amazon-corretto bc procps jq findutils unzip && \
@@ -36,5 +36,10 @@ RUN rm -rf /tmp/jmeter-plugins-manager-1* && \
 # Add settings file to capture the output logs from bzt cli
 RUN mkdir -p /etc/bzt.d && echo '{"settings": {"artifacts-dir": "/tmp/artifacts"}}' > /etc/bzt.d/90-artifacts-dir.json
 
+# Temporary fix for CVE-2025-66418 and CVE-2025-66471 in urllib3 2.5.0
+# This must be upgraded after bzt setup to satisfy bzt requirements.txt
+# https://github.com/Blazemeter/taurus/blob/647dd34ab318b5d3060a8c6ce2e5b047a0efddd2/requirements.txt
+RUN $PIP_INSTALL 'urllib3>=2.6.0'
+
 WORKDIR /bzt-configs
 ENTRYPOINT ["./load-test.sh"]

deployment/ecr/distributed-load-testing-on-aws-load-tester/Dockerfile

@@ -68,7 +68,7 @@
     "dnsjava": "dnsjava/dnsjava/3.6.1/dnsjava-3.6.1.jar",
     "xstream": "com/thoughtworks/xstream/xstream/1.4.21/xstream-1.4.21.jar",
     "http2-hpack": "org/eclipse/jetty/http2/http2-hpack/11.0.26/http2-hpack-11.0.26.jar",
-    "jetty-http": "org/eclipse/jetty/jetty-http/12.0.25/jetty-http-12.0.25.jar",
+    "jetty-http": "org/eclipse/jetty/jetty-http/11.0.26/jetty-http-11.0.26.jar",
     "http2-common": "org/eclipse/jetty/http2/http2-common/11.0.26/http2-common-11.0.26.jar",
     "kotlin-stdlib": "org/jetbrains/kotlin/kotlin-stdlib/2.1.0/kotlin-stdlib-2.1.0.jar",
     "commons-lang3": "org/apache/commons/commons-lang3/3.18.0/commons-lang3-3.18.0.jar",

deployment/ecr/distributed-load-testing-on-aws-load-tester/jar_updater.py

@@ -106,7 +106,11 @@ if [ "$TEST_TYPE" != "simple" ]; then
       exit 1
     fi
 
-    sed -i -e "s|$TEST_ID.zip|$TEST_SCRIPT|g" test.json
+    # Update test.json to reference the test script extracted from the zip.
+    # Prior to v4.0, zipped test scripts were stored with their framework's expected extension (e.g. JMeter zip would be ABCDE12345.jmx instead of ABCDE12345.zip).
+    # test.json may reference $TEST_ID.$EXT (legacy to support .jmx) or $TEST_ID.zip (current).
+    # The two sed replacements ensure either file name is correctly updated to the actual test script value.
+    sed -i -e "s|$TEST_ID.$EXT|$TEST_SCRIPT|g" -e "s|$TEST_ID.zip|$TEST_SCRIPT|g" test.json
 
     # copy bundled plugin jars to jmeter extension folder to make them available to jmeter
     BUNDLED_PLUGIN_DIR=`find $PWD -type d -name "plugins" | head -n 1`

deployment/ecr/distributed-load-testing-on-aws-load-tester/load-test.sh

@@ -1,6 +1,6 @@
 id: SO0062 
 name: distributed-load-testing-on-aws
-version: v4.0.1
+version: v4.0.2
 cloudformation_templates:
   - template: distributed-load-testing-on-aws.template
     main_template: true 

solution-manifest.yaml

@@ -699,6 +699,9 @@ const scheduleTest = async (event, context) => { // NOSONAR
 
     //Update DynamoDB if table was not already updated by "create" schedule step
     if (config.scheduleStep || !recurrence) {
+      // Validate and normalize tags
+      const validatedTags = validateTags(config.tags);
+      
       const updateDBData = {
         testId,
         testName: config.testName,
@@ -714,6 +717,7 @@ const scheduleTest = async (event, context) => { // NOSONAR
         fileType: config.fileType,
         cronValue,
         cronExpiryDate,
+        tags: validatedTags,
       };
       let data = await updateTestDBEntry(updateDBData);
       console.log(`Schedule test complete: testId=${testId}, status=scheduled`);