Apache JMeter 5.6.3

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick Apache JMeter 5.6.3 on Ubuntu 24.04 as the software version and select your Region, then choose Launch through EC2. Choose an instance type, your key pair, your subnet and the security group described above.

m5.large (2 vCPUs, 8 GiB) runs a few hundred light HTTP threads. JMeter is CPU and memory bound, so for heavier tests pick a larger compute-optimised type (for example c6i.2xlarge) and raise the Java heap (Step 7). Launch the load generator in the same Region as the system under test, ideally in the same VPC, so that you measure the system and not the internet in between.

The image has two volumes: a 12 GiB root volume and a 30 GiB data volume (/dev/sdf) for /var/lib/jmeter. If you keep long result files, make the data volume bigger at launch.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --block-device-mappings '[{"DeviceName":"/dev/sdf","Ebs":{"VolumeSize":100,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=jmeter}]'

Connect over SSH with your key pair. The login user depends on the version you launched:

• Apache JMeter 5.6.3 on Ubuntu 24.04: log in as ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

The login message shows how to run a plan and where your keystore details are.

First boot takes a few seconds. It generates the RMI keystore and its password, creates your folders on the data volume, copies the sample plans, and only then starts jmeter-server. Check that everything is running:

systemctl is-active apache-jmeter-firstboot jmeter-egress-guard jmeter-server \
  && sudo test -f /var/lib/sac/data/apache-jmeter-firstboot.done && echo FIRSTBOOT_DONE

active active active FIRSTBOOT_DONE

Only SSH listens on the network. jmeter-server (a java process) listens on the loopback address only:

sudo ss -Hlntp | awk '$4 !~ /^127\.0\.0\.5[34]/ {print $4, $6}' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort -u | tee /dev/stderr \
  | awk '$1 !~ /^(127\.|\[::ffff:127\.)/ {sub(/.*:/, "", $1); print $1}' | sort -un | xargs | grep -qx '22' && echo "network listeners: 22"

0.0.0.0:22 users:(("sshd"),("systemd")) [::]:22 users:(("sshd"),("systemd")) [::ffff:127.0.0.1]:1099 users:(("java")) [::ffff:127.0.0.1]:1100 users:(("java")) network listeners: 22

Your folders are on the data volume:

findmnt -no FSTYPE,TARGET /var/lib/jmeter | tee /dev/stderr | grep -q '^ext4 ' && sudo ls /var/lib/jmeter/test-plans | tee /dev/stderr | grep -qx sample.jmx

ext4 /var/lib/jmeter http-sample.jmx sample.jmx

• /var/lib/jmeter/test-plans: your .jmx plans (two samples to start from)
• /var/lib/jmeter/results: results files (.jtl)
• /var/lib/jmeter/reports: HTML dashboard reports
• /var/lib/jmeter/logs: jmeter.log files of your runs and jmeter-server.log

/var/lib/sac/data/apache-jmeter-endpoints.notes (root only) holds the details of this instance's distributed-mode engine, all generated on first boot. Read it with:

sudo sed -n 's/^\(JMETER_[A-Z0-9_]*\)=.*/\1/p' /var/lib/sac/data/apache-jmeter-endpoints.notes | tee /dev/stderr \
  | grep -qx JMETER_RMI_KEYSTORE_PASSWORD && echo "notes present"

JMETER_HOME JMETER_DATA JMETER_RMI_REGISTRY JMETER_RMI_SERVER_PORT JMETER_RMI_CLIENT_CALLBACK_PORTS JMETER_RMI_KEYSTORE JMETER_RMI_PROPERTIES JMETER_RMI_KEYSTORE_PASSWORD JMETER_RMI_CERT_SHA256 JMETER_REMOTE_RUN notes present

You rarely need the password itself. JMeter reads it from /etc/jmeter/rmi/rmi-password.properties (readable only by root and the jmeter account) when you pass -q /etc/jmeter/rmi/rmi-password.properties.

The keystore holds a self-signed certificate for 127.0.0.1. That certificate is both this instance's identity and the only certificate it trusts. Check that jmeter-server presents this instance's certificate:

FP="$(sudo sed -n 's/^JMETER_RMI_CERT_SHA256=//p' /var/lib/sac/data/apache-jmeter-endpoints.notes)" openssl s_client -connect 127.0.0.1:1099 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -ext subjectAltName | tee /dev/stderr \
  | grep -qix "sha256 Fingerprint=$FP" && echo "jmeter-server presents this instance's certificate"

sha256 Fingerprint=0C:2C:0C:78:10:2F:2A:CF:B6:F4:53:60:BF:D4:32:79:66:FF:E5:D4:A5:7E:A6:1C:78:46:42:18:71:6F:63:44 X509v3 Subject Alternative Name: IP Address:127.0.0.1, DNS:localhost jmeter-server presents this instance's certificate

Run JMeter as the jmeter account, from /var/lib/jmeter, so that its log and results land in folders it owns:

sudo -u jmeter bash -c 'cd /var/lib/jmeter && jmeter --version -j logs/version.log' 2>/dev/null | tee /dev/stderr \
  | grep -q '5\.6\.3' && echo "Apache JMeter 5.6.3"

_ ____ _ ____ _ _ _____ _ __ __ _____ _____ _____ ____ / \
  | _ \
  / \
  / ___| | | | ____| | | \/ | ____|_ _| ____| _ \
  / _ \
  | |_) / _ \| | | |_| | _| _ | | |\/| | _| | | | _| | |_) | / ___ \| __/ ___ \
  |___| _ | |___ | |_| | | | | |___ | | | |___| _ < /_/ \_\_| /_/ \_\____|_| |_|_____| \___/|_| |_|_____| |_| |_____|_| \_\ 5.6.3 Copyright (c) 1999-2024 The Apache Software Foundation Apache JMeter 5.6.3

Always run your tests as jmeter. The metadata fence (Step 8) applies to that account, and besides root it is the only account that can read the keystore. Your own ubuntu shell is not fenced.

sample.jmx is a self-contained plan (5 threads, 20 loops each, no network traffic) that shows the whole flow. Run it in non-GUI mode, write the results to a .jtl file, and generate the HTML dashboard at the end of the run (-e -o). Then count the samples and errors in the results file:

R="first-run-$(date +%H%M%S)"
sudo -u jmeter bash -c "cd /var/lib/jmeter && jmeter -n -t test-plans/sample.jmx -l results/$R.jtl -j logs/$R.log -e -o reports/$R" | grep 'summary =' \
  && sudo awk -F, 'NR>1 {n++; if ($8 != "true") e++} END {printf "%d samples, %d errors\n", n, e}' "/var/lib/jmeter/results/$R.jtl" | tee /dev/stderr | grep -qx '100 samples, 0 errors' \
  && sudo test -s "/var/lib/jmeter/reports/$R/index.html" && echo "HTML report: /var/lib/jmeter/reports/$R/index.html"

summary = 100 in 00:00:04 = 22.3/s Avg: 150 Min: 12 Max: 251 Err: 0 (0.00%) 100 samples, 0 errors HTML report: /var/lib/jmeter/reports/first-run-063121/index.html

The report folder must not exist yet, because JMeter refuses to overwrite one. That is why each run above gets its own name. To read the report, copy it to your machine and open index.html in your browser:

ssh -i <your-key.pem> ubuntu@<public-ip> "sudo tar -C /var/lib/jmeter/reports -czf - first-run-063121" | tar -xzf - open first-run-063121/index.html
# macOS; use xdg-open on Linux or start on Windows

You can also turn any existing results file into a report later: sudo -u jmeter bash -c 'cd /var/lib/jmeter && jmeter -g results/<run>.jtl -o reports/<run>-report'.

http-sample.jmx sends 2 threads of 5 HTTPS GET / requests to the host you name with -Jtarget_host and checks that each one answers 200:

R="http-$(date +%H%M%S)"
sudo -u jmeter bash -c "cd /var/lib/jmeter && jmeter -n -t test-plans/http-sample.jmx -Jtarget_host=example.com -l results/$R.jtl -j logs/$R.log" | grep 'summary =' \
  && sudo awk -F, 'NR>1 {n++; if ($8 != "true") e++} END {printf "%d samples, %d errors\n", n, e}' "/var/lib/jmeter/results/$R.jtl" | tee /dev/stderr | grep -qx '10 samples, 0 errors'

summary = 10 in 00:00:01 = 13.2/s Avg: 69 Min: 9 Max: 489 Err: 0 (0.00%) 10 samples, 0 errors

Build your own plans with the JMeter GUI on your workstation. Download the same version, 5.6.3, from jmeter.apache.org. Then copy the plans to the instance and run them headless there:

scp -i <your-key.pem> my-plan.jmx ubuntu@<public-ip>:/tmp/ ssh -i <your-key.pem> ubuntu@<public-ip> "sudo install -o jmeter -g jmeter -m 0640 /tmp/my-plan.jmx /var/lib/jmeter/test-plans/ && rm /tmp/my-plan.jmx"

Keep these points in mind for real tests:

• Run load tests only against systems you own or have permission to test.
• Java heap. JMeter starts with a 1 GiB heap. For large tests give it more, for example half the instance's memory: sudo -u jmeter bash -c 'cd /var/lib/jmeter && HEAP="-Xms4g -Xmx4g" jmeter -n ...'.
• Plugins and drivers. Put extra jars (JDBC drivers, plugins) in /opt/jmeter/lib or /opt/jmeter/lib/ext with sudo. They are then available to every run.
• Several load generators. To spread a test over more instances, run the same plan on each instance, copy the .jtl files to one of them, join them (keep one header line) and build one report with jmeter -g. This needs no network connection between the instances. JMeter's own controller-and-servers mode needs its RMI ports open between hosts, which this image deliberately does not do (see Step 9).

Test plans can reach the internet and your private networks, but not the EC2 instance metadata service or a few reserved address ranges. Check the metadata block first. The metadata service gets no answer (000) for the jmeter account and still answers for ubuntu (your SSH account). Every JMeter service on the image carries the metadata block:

{
sudo -u jmeter curl -s -m 5 -o /dev/null -w 'jmeter -> metadata: %{http_code}\n' -X PUT http://169.254.169.254/latest/api/token -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' curl -s -m 5 -o /dev/null -w 'ubuntu -> metadata: %{http_code}\n' -X PUT http://169.254.169.254/latest/api/token -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' for u in apache-jmeter-firstboot jmeter-egress-guard jmeter-server; do systemctl show -p IPAddressDeny --value "$u" | grep -q '169\.254\.0\.0/16' && echo "$u: metadata denied"; done } | tee /dev/stderr | xargs | grep -qx 'jmeter -> metadata: 000 ubuntu -> metadata: 200 apache-jmeter-firstboot: metadata denied jmeter-egress-guard: metadata denied jmeter-server: metadata denied' && echo "metadata blocked for JMeter"

jmeter -> metadata: 000 ubuntu -> metadata: 200 apache-jmeter-firstboot: metadata denied jmeter-egress-guard: metadata denied jmeter-server: metadata denied metadata blocked for JMeter

Two controls enforce this. Each JMeter service has its own network filter (systemd IPAddressDeny). In addition, an nftables rule rejects the metadata addresses (IPv4 and IPv6, all of 169.254.0.0/16 including the container credential endpoint, fe80::/10) for the jmeter account anywhere on the instance, so a test plan, a JSR223 script or a plugin cannot read the instance's IAM role credentials. If a plan needs AWS credentials (for example to sign requests), give it its own, with only the permissions it needs.

The same nftables table also refuses a few reserved IPv4 ranges for the jmeter account, none of which is a real load-test target: 192.0.0.0/24 (IETF protocol assignments), 198.18.0.0/15 (reserved for benchmarking network devices in isolated labs), 240.0.0.0/4 (reserved) and 224.0.0.0/4 (multicast, dropped rather than rejected). To check it, run the commands below. Each reserved address is refused at once (000, in well under a second), and the rule counters show the hits:

for a in 198.18.0.1 192.0.0.9 240.0.0.1; do
sudo -u jmeter curl -s -m 5 -o /dev/null -w "jmeter -> $a: %{http_code} in %{time_total}s\n" "http://$a/" || true; done | tee /dev/stderr \
  | awk '$4 == "000" && $6 + 0 < 3 {n++} END {exit n != 3}' \
  && sudo nft list chain inet sac_jmeter_egress output | awk '/"sac-backstop"/ {for (i = 1; i < NF; i++) if ($i == "packets") p = $(i + 1)} END {exit !(p > 0)}' \
  && echo "reserved ranges refused for JMeter"

jmeter -> 198.18.0.1: 000 in 0.000412s jmeter -> 192.0.0.9: 000 in 0.000201s jmeter -> 240.0.0.1: 000 in 0.000187s reserved ranges refused for JMeter

IPv6 is left open apart from the metadata address and link-local addresses. JMeter needs no IPv6 egress of its own beyond the targets your plans name, and a blanket IPv6 block would break load tests against IPv6 services.

Why private networks are not fenced. JMeter's job is to send traffic to the systems you choose, and most systems people load test (internal APIs, databases, services behind a load balancer) live on private addresses in their VPC. Blocking private ranges would stop the product doing its main job, so the image fences only the metadata service, link-local addresses and the reserved ranges above, which are never a load-test target.

For the same reason, the image does not look up your VPC's address range and block it, as some SecureAnyCloud images do for services that should never call into your network. Reaching your VPC is what a load generator is for, so 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 all stay open to the jmeter account.

The flip side is that a plan runs with the instance's network position, so it can reach whatever the instance's subnet, route tables and the targets' security groups allow. Run only plans you trust. If a load generator must not reach some targets, use security groups or network ACLs on those targets, or add nftables rules for the jmeter account.

jmeter-server is JMeter's remote engine: a controller sends it a plan over Java RMI and it runs the plan and streams the samples back. On this image the engine and the controller both run on the instance, as jmeter, over mutual TLS on loopback. The built-in self-test runs a full test through the engine:

sudo jmeter-selftest | tail -n 1 | tee /dev/stderr | grep -q '^JMETER_SELFTEST_OK '

JMETER_SELFTEST_OK distributed run through jmeter-server (RMI over mutual TLS, 127.0.0.1:1099/1100) as jmeter: 100/100 samples

To run your own plan through the engine, add -r (use the remote engine) and -q /etc/jmeter/rmi/rmi-password.properties (this instance's keystore password):

R="remote-$(date +%H%M%S)"
sudo -u jmeter bash -c "cd /var/lib/jmeter && jmeter -n -t test-plans/sample.jmx -r -q /etc/jmeter/rmi/rmi-password.properties -l results/$R.jtl -j logs/$R.log" \
  | grep -E 'Remote engines have been started|summary =' | tee /dev/stderr | grep -q 'started:\[127.0.0.1\]' \
  && sudo awk -F, 'NR>1 {n++; if ($8 != "true") e++} END {printf "%d samples, %d errors\n", n, e}' "/var/lib/jmeter/results/$R.jtl" | tee /dev/stderr | grep -qx '100 samples, 0 errors' && echo "distributed run OK"

Remote engines have been started:[127.0.0.1] summary = 100 in 00:00:04 = 23.7/s Avg: 135 Min: 13 Max: 261 Err: 0 (0.00%) 100 samples, 0 errors distributed run OK

What the engine refuses. A client that turns RMI TLS off, and a client that has the keystore file but not its password, cannot configure the engine:

for X in '-Jserver.rmi.ssl.disable=true' ''; do OUT="$(sudo -u jmeter bash -c "cd /var/lib/jmeter && jmeter -n -t test-plans/sample.jmx -r $X -l results/refused.jtl -j logs/refused.log" 2>&1)" if grep -q 'could not be configured:\[127.0.0.1\]' <<< "$OUT" && ! grep -q 'engines have been started' <<< "$OUT"; then echo "refused: ${X:-no keystore password}"; else echo "ACCEPTED: ${X:-no keystore password}"; fi done | tee /dev/stderr | grep -c '^refused: ' | grep -qx 2 && echo "RMI without this instance's keystore and password is refused"

refused: -Jserver.rmi.ssl.disable=true refused: no keystore password RMI without this instance's keystore and password is refused

And the engine is not on the instance's network address at all:

IP="$(hostname -I | awk '{print $1}')" for p in 1099 1100; do if timeout 5 bash -c "exec 3<>/dev/tcp/$IP/$p" 2>/dev/null; then echo "$p open"; else echo "$p refused"; fi; done \
  | xargs | tee /dev/stderr | grep -qx '1099 refused 1100 refused' && echo "RMI is not on the network address"

1099 refused 1100 refused RMI is not on the network address

On top of that, an nftables rule drops packets from the network to ports 1099 to 1103 and to JMeter's UDP shutdown ports (4445 to 4455), and the security group opens only SSH.

Why there is no remote controller. In JMeter's distributed mode the engine connects back to the controller to deliver results, so a controller on your workstation would need its own ports reachable from the instance, and the RMI ports would have to be opened between hosts. That is the setup behind JMeter's history of RMI attacks, so this image keeps the engine and the controller on the instance and you drive both over SSH. The controller's callback ports are chosen by the system on 127.0.0.1 (client.rmi.localport=0): JMeter 5.6.3 cannot use a fixed callback port with RMI over TLS (the run fails with NotSerializableException: org.apache.jmeter.JMeter$ListenToTest), so leave that setting as it is.

To replace the keystore, its certificate and its password with new ones (the old ones stop working at once, and jmeter-server restarts on the new keystore):

sudo jmeter-rmi-keystore --rotate sudo jmeter-selftest

The new password is written only to /etc/jmeter/rmi/rmi-password.properties and the notes file; it never appears on a command line. Read the new certificate fingerprint with sudo grep ^JMETER_RMI_CERT_SHA256= /var/lib/sac/data/apache-jmeter-endpoints.notes.

Everything you create is on the data volume, /var/lib/jmeter. Take an EBS snapshot of that volume, or copy your plans and results off the instance:

ssh -i <your-key.pem> ubuntu@<public-ip> "sudo tar -C /var/lib/jmeter -czf - test-plans results reports" > jmeter-$(date +%F).tar.gz

To restore into a new instance of this image, unpack the archive into /var/lib/jmeter as jmeter: sudo -u jmeter tar -C /var/lib/jmeter -xzf - < jmeter-<date>.tar.gz. To grow the data volume, modify it in the EC2 console and then run sudo resize2fs "$(findmnt -no SOURCE /var/lib/jmeter)".

jmeter-server runs as jmeter, which has no login shell and no sudo. The service has no capabilities and NoNewPrivileges, sees the rest of the system read-only (ProtectSystem=strict, writable only under /var/lib/jmeter), and has private /tmp and /dev. Some sandbox settings are deliberately relaxed because a Java load generator needs them: JIT compilation (no MemoryDenyWriteExecute), any system call, netlink sockets and up to 8192 threads. The keystore files are readable only by root and jmeter:

getent passwd jmeter | cut -d: -f1,6,7 | tee /dev/stderr | grep -qx 'jmeter:/var/lib/jmeter:/usr/sbin/nologin' \
  && sudo -l -U jmeter 2>&1 | grep -q 'not allowed to run sudo' && echo "jmeter: no login shell, no sudo" \
  && sudo stat -c '%n %U:%G %a' /etc/jmeter/rmi/rmi-keystore.p12 /etc/jmeter/rmi/rmi-password.properties /var/lib/sac/data/apache-jmeter-endpoints.notes \
  | tee /dev/stderr | grep -c ' root:jmeter 640$' | grep -qx 2 && echo "keystore: root and jmeter only"

jmeter:/var/lib/jmeter:/usr/sbin/nologin jmeter: no login shell, no
sudo /etc/jmeter/rmi/rmi-keystore.p12 root:jmeter 640 /etc/jmeter/rmi/rmi-password.properties root:jmeter 640 /var/lib/sac/data/apache-jmeter-endpoints.notes root:root 600 keystore: root and jmeter only

The build record shows where JMeter came from and how its libraries were checked:

sed -n '1,8p' /usr/share/doc/sac-jmeter/BUILD-INFO.txt | tee /dev/stderr | grep -q '^jmeter *Apache JMeter 5\.6\.3 '

jmeter Apache JMeter 5.6.3 (jmeter.apache.org, 2024-01-07), Apache-2.0; /opt/jmeter apache-jmeter-5.6.3.tgz sha512 5978a1a35edb5a7d428e270564ff49d2b1b257a65e17a759d259a9283fc17093e522fe46f474a043864aea6910683486340706d745fcdf3db1505fd71e689083 docs/ and printable_docs/ not shipped (Oracle-licensed javadoc assets, docs/api/legal/LICENSE; the manual is online) jars 159 jars = the CVE-gated set (listing sha256 565449bb9d8a8ca658cba8060c094b88fd6b4b074247953196bfb3d07419d3da; jars-sha256.txt) json-smart + accessors-smart raised 2.5.0 -> 2.5.2 (CVE-2024-57699), Maven Central, sha256 pinned tika 1.28.5 as released; CVE-2025-54988 / -66516 (PDF parser XXE) unreachable: no PDFBox ships, so Tika cannot load its PDF parser java openjdk version "17.0.20.1" 2026-08-18 (Ubuntu openjdk-17 JRE, noble, security-patched; no JDK ships) distributed mode jmeter-server as the nologin account jmeter: registry 127.0.0.1:1099, engine 127.0.0.1:1100, controller

About the libraries JMeter 5.6.3 bundles:

• json-smart and accessors-smart are raised from 2.5.0 to 2.5.2 (CVE-2024-57699): a deeply nested JSON response now fails the assertion or extractor cleanly instead of crashing the test.
• Apache Tika 1.28.5 (used when an assertion or extractor reads a response "as document") has advisories in its PDF parser (CVE-2025-54988, CVE-2025-66516). That parser needs Apache PDFBox, which JMeter does not ship, so Tika cannot load it: a PDF response yields no text and nothing it references is fetched. Do not add PDFBox jars to /opt/jmeter/lib.
• httpcore5 5.2.4 and dnsjava 2.1.9 have advisories with no fix in the versions JMeter 5.6.3 supports. They can only be triggered by the systems you test (a denial of service of your own test run) or by a DNS resolver you configure yourself in a DNS Cache Manager.

Ubuntu security updates, including the OpenJDK runtime, install automatically. To apply everything now:

sudo apt-get update && sudo apt-get upgrade -y

JMeter itself is installed from the Apache release, not from an apt repository, so apt-get upgrade does not change it. New JMeter releases arrive as new versions of the AWS Marketplace listing: launch the new version and copy your plans across (Step 11).