Automated API Load Testing on AWS: Grafana k6 and AI-Powered Reporting with Amazon Bedrock A developer built an automated load-testing pipeline that exposes an Amazon Bedrock and S3 Vectors duplicate-product service through Amazon API Gateway, drives traffic with Grafana k6 on AWS, and uses generative AI on Amazon Bedrock to interpret the collected metrics. The approach grounds test criteria in SRE conceptsβ€”SLIs, SLOs, and SLAsβ€”so results are judged against defined response-time and error-rate objectives rather than simple pass/fail checks. When developing an application or service, one of the common questions we face is how many concurrent requests it can handle and how the services it depends on will respond. Even if we verify that all functionalities work correctly, this does not guarantee that the system will maintain its performance as demand increases. This is why software testing goes beyond verifying functional requirements . It also allows us to evaluate aspects such as performance, stability, and responsiveness. In particular, load testing is not simply about pushing a system until it fails, but rather about understanding how it behaves under different conditions and identifying when it stops meeting the expected requirements. In the previous article, we built a service to identify duplicate products using Amazon Bedrock, S3 Vectors, and DynamoDB, including an AWS Lambda function to perform real-time searches. During our initial tests, the service responded within a few seconds, but one question remained unanswered: how would it behave if many users accessed it simultaneously? To answer this question, in this second part, we will expose the service through Amazon API Gateway and evaluate its behavior under load. Before running the tests, however, we need to define what we want to measure and which criteria we will use to evaluate the results. To do this, we will introduce some fundamental concepts of Site Reliability Engineering SRE . We will then automate load testing with Grafana k6 on AWS and, finally, generate a report in which generative AI will help us interpret the collected metrics. Before evaluating how our API behaves under load, we need to establish what acceptable performance and reliability actually mean. A service may continue responding to requests, but that does not necessarily mean it is meeting the expected performance requirements. This is where Site Reliability Engineering SRE comes into play. Originally developed at Google, SRE is a discipline that applies software engineering principles to operating and maintaining reliable systems. It focuses on defining measurable objectives, selecting indicators that reflect service behavior, and using automation to reduce repetitive operational tasks. For our use case, these concepts provide a foundation for moving beyond simply checking whether the API responds. Instead, we can evaluate specific indicators such as response times, error rates, and performance under different load conditions. SRE is built on a set of principles that guide how reliable services are designed, operated, and maintained. These range from defining reliability objectives and managing risk to automation, monitoring, and keeping systems as simple as possible. The following infographic summarizes seven of these principles, based on Google's Site Reliability Engineering book. Illustration by the author. Based on Google's Site Reliability Engineering book. Service reliability depends not only on availability but also on the ability to handle demand while maintaining acceptable performance. In this context, SRE includes several practices aimed at anticipating problems, optimizing resources, and reducing the impact of changes in production. Among these practices, we can highlight: Evaluating a service's capacity and performance requires more than simply running tests and collecting metrics. We also need to define what we want to measure and which service levels we consider acceptable. In this context, SRE introduces three related concepts: SLI Service Level Indicator , SLO Service Level Objective , and SLA Service Level Agreement . Together, they connect technical measurements with service objectives and commitments. The following infographic summarizes what each concept represents, the question it helps answer, and a practical example of how it can be applied. Illustration by the author. Based on Google's SRE framework. Grafana k6 is an open-source tool developed in Go and maintained by Grafana Labs, designed to perform load and performance testing on applications, APIs, and microservices. Test scenarios are defined using JavaScript, making it easier to automate tests and integrate them into development workflows. Although we often associate these tools with stress testing, k6 allows us to evaluate how a system behaves under different load conditions, without necessarily pushing it to the point of failure. Illustration by the author. Based on Grafana k6 documentation. Depending on what we want to evaluate, we can define different test scenarios: To execute these tests, k6 provides several components that allow us to configure load, validate responses, collect metrics, and integrate results with other tools. We can group them into four main components: To run load tests on AWS, we start with the game-catalog-resolve-product Lambda function developed in the previous article, which uses Amazon Bedrock, S3 Vectors, and DynamoDB to identify duplicate products. In this second part, we expose the function through Amazon API Gateway HTTP API with IAM authorization, requiring k6 requests to be signed using AWS credentials. To automate the testing process, we use AWS Step Functions to orchestrate the execution of k6 on Amazon ECS Fargate and the subsequent report generation through an AWS Lambda function. Test scripts and results are stored in Amazon S3, while Amazon ECR stores the container images. The entire infrastructure is defined using Terraform, and the code is available on GitHub, allowing the solution to be reproduced. Architecture diagram by the author. In this use case, we will run different load testing scenarios against our API. To do this, we use Grafana k6 running inside a Docker container to send requests and collect performance metrics. Once the tests are complete, a Python-based process calculates the results and generates a PDF report that includes an interpretation provided by Amazon Bedrock. The project is available on GitHub: game-catalog-k6 https://github.com/RominaElenaMendezEscobar/game-catalog-k6 . Serverless pipeline that runs Grafana k6 load tests against an API on Amazon ECS Fargate orchestrated by AWS Step Functions , and generates a PDF report where Amazon Bedrock interprets the metrics. All the infrastructure is defined with Terraform . πŸ“ Article: πŸ”— Part 1 the API under test : Identical or Similar? AI-Powered Product Matching with Amazon Bedrock and S3 Vectors https://dev.to/aws-builders/identical-or-similar-ai-powered-product-matching-with-amazon-bedrock-and-s3-vectors-3pm Β· repository https://github.com/RominaElenaMendezEscobar/aws-games-products The thresholds… game-catalog-k6/ β”œβ”€β”€ Dockerfile, entrypoint.sh β”œβ”€β”€ search.js, sigv4.js β”œβ”€β”€ scenarios/ β”œβ”€β”€ queries.json β”œβ”€β”€ report/ β”‚ └── config/ β”œβ”€β”€ terraform/ └── build-and-push.sh The goal is to make this solution reusable for testing other APIs without modifying the underlying infrastructure or the report generation process. To do this, we only need to configure three elements: api id In our case, we use Amazon API Gateway HTTP API with IAM authorization. The service URL follows this structure: https://