Last weekend, I was setting up JMeter for load testing. Instead of stressing my local machine 💻, I decided to spin up an Ubuntu-based EC2 instance on AWS. But before installing JMeter, I needed Java on the instance.
If you’re setting up Java on an AWS EC2 instance, this guide is for you. Let’s get started!
🚀 Step 1: Launch an EC2 Instance
- Login to your AWS Console and navigate to the EC2 Dashboard.
- Click Launch Instance and configure the instance as per your requirements.
- Make sure to download the .pem key file during the final steps—this is needed for SSH access.
- For this guide, we’re using an Ubuntu-based EC2 instance.
🛠 Step 2: Connect to Your EC2 Instance
Once your instance is up and running, connect via SSH from your local terminal.
-
Move to the directory where your .pem file is stored and update its permissions:
chmod 400 mypemfile.pem -
Connect to the EC2 instance:
ssh -i "mypemfile.pem" ubuntu@ec2-x-xxx-xx-0.ap-south-1.compute.amazonaws.com
✅ Pro Tip: Ensure you’re in the same directory as your .pem file before running the SSH command.
📌 Step 3: Install Java on EC2
-
Switch to a superuser:
sudo -i -
Update the package list to ensure everything is up to date:
sudo apt update && sudo apt upgrade -y -
Verify if Java is already installed (most likely, it’s not):
java -version
📂 Step 4: Create a Directory for Java
-
Navigate to the /usr/lib/ directory:
cd /usr/lib/ -
Create a new jvm directory:
mkdir jvm -
Grant proper permissions:
chmod u=rwx,g=rwx,o=rwx jvm
🔄 Step 5: Upload Java JDK to Your EC2 Instance
-
Exit from your EC2 session (
exit) and upload the JDK file from your local machine:scp -i "mypemfile.pem" ~/Downloads/jdk-11.0.25_linux-x64_bin.tar.gz ubuntu@ec2-x-xxx-xx-0.ap-south-1.compute.amazonaws.com:/usr/lib/jvm -
Once the upload is complete, reconnect to your EC2 instance and navigate to the
jvmdirectory:cd /usr/lib/jvm -
Extract the JDK archive:
tar zxvf jdk-11.0.25_linux-x64_bin.tar.gz
🌎 Step 6: Set Up Java Environment Variables
-
Open the environment file for editing:
nano /etc/environment -
Add the following lines to the file:
PATH="/usr/lib/jvm/jdk-11.0.25/bin:$PATH" JAVA_HOME="/usr/lib/jvm/jdk-11.0.25" -
Save and exit (
CTRL + X, thenY, thenEnter).
🛠 Step 7: Configure Java Alternatives
Run the following commands to let the system recognize Java and javac:
update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk-11.0.25/bin/java" 0
update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk-11.0.25/bin/javac" 0
✅ Step 8: Verify Java Installation
Run:
java -version

🎉 Boom! Java is now installed on your AWS EC2 instance! 🚀🔥
🪄 The One-Line Version
Steps 4 through 7 exist because I was installing a specific Oracle JDK build from a downloaded tarball. If you don’t need a particular vendor — and for JMeter you almost certainly don’t — Ubuntu’s package manager does all of it in one command:
sudo apt update && sudo apt install -y openjdk-17-jdk
That handles the directory, the extraction, JAVA_HOME, and the update-alternatives wiring for you. Verify the same way:
java -version
Use openjdk-17-jre instead if you only need to run Java and not compile it — it’s a noticeably smaller download, which matters on a small instance.
So when is the manual route worth it? When you need a JDK version the distribution doesn’t package, when licensing requires the Oracle build specifically, or when you’re pinning an exact build for reproducibility. Otherwise, take the one-liner.
🔀 Switching Between Installed JDKs
If you end up with more than one — the distribution’s OpenJDK plus a manually installed Oracle JDK, say — update-alternatives lets you pick interactively rather than editing paths:
sudo update-alternatives --config java
It prints the installed options with their paths and lets you select one by number. The same works for javac.
✅ Making JAVA_HOME Stick
/etc/environment is read at login, not by every process. Two consequences worth knowing:
- The variable won’t exist in your current session until you log out and back in, or run
source /etc/environmentby hand. - It is not picked up by systemd services. If you’re running something as a service, set
Environment=JAVA_HOME=...in its unit file instead.
Check it landed:
echo $JAVA_HOME
$JAVA_HOME/bin/java -version
If the second command works but plain java -version doesn’t, your PATH entry didn’t apply — the JAVA_HOME line took effect but the PATH line didn’t.
🧪 Now Actually Run JMeter
The whole point of this was load testing, and there’s one thing to get right: run JMeter in non-GUI mode on the server. The GUI is for building test plans locally; using it to run a test eats the memory you wanted for load generation.
jmeter -n -t testplan.jmx -l results.jtl -e -o ./report
-n is non-GUI, -t is the plan, -l is the raw results log, and -e -o generates the HTML dashboard afterwards. Pull the report back down with scp and open it locally.
🧯 Common Snags
Permission denied (publickey)on SSH — usually the.pemfile permissions (chmod 400) or the wrong default user. Ubuntu AMIs useubuntu; Amazon Linux usesec2-user.- SSH hangs with no error — that’s the security group, not the key. Port 22 needs to allow your IP inbound.
java: command not foundafter a reboot — thePATHchange in/etc/environmentdidn’t apply. See above.- The instance runs out of memory mid-test — a
t4g.nanois fine for installing Java and wrong for generating load. Size the instance to the test, and remember to shut it down afterwards. - Wrong architecture JDK — a Graviton (
t4g,m7g) instance needs theaarch64build, notx64. The tarball name tells you which you downloaded.
