AWS

How to Deploy a Spring Boot Application on AWS EC2

By Utility Zone ยท 2026-10-03T09:31:03.504541

Category: AWS, Java, Spring Boot, Cloud Deployment
Level: Beginner to Intermediate
Estimated reading time: 10--12 minutes

Spring Boot on AWS EC2 architecture

Figure 1. Simplified learning architecture. This is an illustrative diagram, not a production network design.

Introduction

Amazon Elastic Compute Cloud (EC2) provides virtual servers on which you can run Java applications. In this tutorial, you will build a Spring Boot executable JAR, launch an EC2 instance, install a compatible Java runtime, copy the JAR to the server, start the application, and review basic security and troubleshooting practices.

Important: This is a learning-oriented single-instance deployment, not a complete production architecture. The console and package options can change; verify current AWS documentation and pricing before deploying.

Prerequisites

  • An AWS account with permission to create EC2 resources.
  • A Spring Boot project that builds successfully.
  • A Java version supported by your Spring Boot version.
  • Basic familiarity with Linux, SSH, and Maven or Gradle.

Cost note: EC2 compute, storage, public IPv4 addresses, data transfer, and related resources may incur charges. Review current AWS pricing and remove resources you no longer need.

Step 1: Build the application

For Maven projects, run from the project root:

./mvnw clean package

On Windows, use mvnw.cmd clean package. If you use installed Maven, run mvn clean package.

For Gradle, the usual command is:

./gradlew clean bootJar

The executable JAR is commonly created under target/ for Maven or build/libs/ for Gradle. Confirm the build succeeded, then test locally:

java -jar target/your-application.jar

Replace the example filename with your actual JAR name. Stop the local process with Ctrl+C.

Step 2: Launch an EC2 instance

Illustrative EC2 launch checklist

Figure 2. Illustrative launch checklist, not an actual AWS console screenshot. Use the labels and options currently shown in your AWS account.

  1. Sign in to the AWS Management Console and open EC2.
  2. Choose Launch instance and provide a name such as spring-boot-demo.
  3. Select a supported Linux AMI, such as a suitable Amazon Linux image.
  4. Choose an instance type based on your test workload and budget.
  5. Create or select an SSH key pair if you need SSH access. Keep the private key secure.
  6. Review networking and storage settings, then launch the instance.
  7. Wait until the instance is running and its status checks pass.

Step 3: Configure the security group

Illustrative security group checklist

Figure 3. Illustrative security guidance, not a live security-group screenshot.

A security group is a virtual firewall for your instance.

Purpose Port Recommended source

SSH administration TCP 22 Your current public IP, not 0.0.0.0/0

Temporary application TCP 8080 Your IP only, if testing direct access is required

Do not expose SSH to the whole internet without a specific reason and compensating controls. For production, prefer controlled administration through options such as AWS Systems Manager Session Manager, a VPN, or a bastion host.

For a public production application, typically expose HTTPS on port 443 through an Application Load Balancer or a properly configured reverse proxy. Keep port 8080 private when possible.

Step 4: Connect to the instance and copy the JAR

Illustrative connect and deploy terminal checklist

Figure 4. Illustrative terminal workflow. Replace example filenames and host values with your own.

From Linux or macOS, restrict access to your private key and connect using the public DNS name shown in the EC2 console:

chmod 400 my-key.pem
ssh -i my-key.pem ec2-user@YOUR_EC2_PUBLIC_DNS

The login username depends on the selected AMI; ec2-user is common for Amazon Linux, while other images use different usernames.

Copy the JAR from your local machine (adjust paths, key, username, and host):

scp -i my-key.pem target/your-application.jar ec2-user@YOUR_EC2_PUBLIC_DNS:/home/ec2-user/

For Gradle, use the JAR under build/libs/. On the instance, verify the file:

ls -lh /home/ec2-user/

Step 5: Install Java

Check your Spring Boot version and project configuration to determine the supported Java version. Package names vary by Linux image and release. On an Amazon Linux image using dnf, search for available packages:

sudo dnf search java

Install a compatible runtime package available for your AMI. For example, a package may be named java-17-amazon-corretto-headless, depending on the image and repositories:

sudo dnf install java-17-amazon-corretto-headless

Use the version required by your application and verify the package name for your operating system. Older images may use yum instead of dnf.

Confirm the installation:

java -version

Step 6: Start the application

java -jar /home/ec2-user/your-application.jar

If the application listens on port 8080 and the security group temporarily allows your IP to reach it, test:

http://YOUR_EC2_PUBLIC_DNS:8080

Replace the host and path with your actual endpoint. If your application has no route at /, a 404 at the root path may be expected; test a valid endpoint.

You can set the port at startup with:

java -jar /home/ec2-user/your-application.jar --server.port=8080

Step 7: Run the application with systemd

Create a service file:

sudo vi /etc/systemd/system/springboot-app.service

Example configuration:

[Unit]
Description=Spring Boot Application
After=network.target

[Service]
User=ec2-user
WorkingDirectory=/home/ec2-user
ExecStart=/usr/bin/java -jar /home/ec2-user/your-application.jar
Restart=on-failure
RestartSec=5
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

This example is for illustration. Confirm Java's actual path with which java, and adjust ExecStart if needed. For production, use a dedicated service account rather than a general SSH account, and store the application in a dedicated directory with restricted permissions.

Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable springboot-app
sudo systemctl start springboot-app

Step 8: Verify the service and inspect logs

Illustrative service status and logs checklist

Figure 5. Illustrative verification workflow, not a captured terminal screenshot.

sudo systemctl status springboot-app
sudo journalctl -u springboot-app -n 100 --no-pager

To follow logs live:

sudo journalctl -u springboot-app -f

If you change the service file, reload systemd and restart the service.

Step 9: Manage configuration and secrets safely

Spring Boot supports external configuration through command-line arguments, environment variables, and configuration files. Keep environment-specific values outside the application artifact.

For example, a service unit can set a non-secret profile variable:

Environment="SPRING_PROFILES_ACTIVE=prod"

Do not put passwords, API keys, or database credentials in source control, public repositories, or a baked-in JAR. For production, consider AWS Secrets Manager or Systems Manager Parameter Store, with narrowly scoped IAM permissions. Avoid logging secret values.

If the application connects to Amazon RDS or another private service, configure networking and credentials according to that service's security model. Do not make a database public merely to simplify connectivity.

Step 10: Production readiness

  • HTTPS: Use a trusted TLS certificate, commonly with an Application Load Balancer and AWS Certificate Manager, or a correctly configured reverse proxy.
  • Least privilege: Limit security-group rules and IAM permissions to what is needed.
  • Monitoring: Collect logs and metrics, and configure useful alarms.
  • Backups and recovery: Define backup, restore, and data-retention procedures.
  • Patching: Keep the operating system and runtime updated.
  • Deployment: Use CI/CD and a rollback plan rather than manually replacing production files.
  • Availability: Consider multiple instances across Availability Zones and a load balancer if required.
  • Capacity and cost: Size resources based on observed CPU, memory, traffic, and budget.

A single EC2 instance is useful for learning, but it is a single point of failure unless additional resilience is designed.

Troubleshooting

The application cannot be reached

Confirm the instance is running, the application is listening on the expected port, the endpoint exists, and the security group permits traffic from the intended source. Check subnet routing and network ACLs as well.

sudo ss -lntp

The JAR exits immediately

sudo systemctl status springboot-app
sudo journalctl -u springboot-app -n 200 --no-pager

Common causes include an incompatible Java version, missing environment variables, invalid configuration, port conflicts, or unavailable dependencies.

java: command not found

which java
java -version

Check whether Java is installed and available on the service's PATH. If it is installed in a custom location, use its full path in the service file.

It works locally but not on EC2

Review active Spring profiles, environment variables, database connectivity, file paths, firewall rules, and assumptions about local files. Do not fix connectivity problems by opening all ports to the internet.

Deployment checklist

  • The application builds and runs locally.
  • The JAR uses a supported Java version.
  • EC2 access and the private key are configured securely.
  • SSH is restricted to an approved access path.
  • The JAR is copied to the intended directory.
  • A valid application endpoint responds.
  • Service status and logs are available.
  • Secrets are not embedded in the JAR or source code.
  • HTTPS and restricted public access are configured before production.
  • Costs and unused resources are reviewed.

What to learn next

  1. Connect Spring Boot to Amazon RDS for PostgreSQL using private networking.
  2. Configure an Application Load Balancer and HTTPS.
  3. Automate deployments with Jenkins or another CI/CD tool.
  4. Monitor Spring Boot with Amazon CloudWatch.
  5. Containerize the application with Docker and compare EC2 deployment with Amazon ECS.

Conclusion

Deploying a Spring Boot JAR to EC2 introduces the basics of cloud deployment: packaging, server setup, Java installation, network configuration, process management, and log inspection. Treat this as a learning environment rather than a complete production blueprint. Production applications also need secure secrets management, HTTPS, monitoring, controlled releases, recovery planning, and an appropriate availability design.

Publishing note: The visuals in this Markdown package are illustrative diagrams/mockups, not real captures of the AWS Management Console. Before presenting the article as a verified hands-on tutorial, run the steps in your AWS environment and replace the mockups with genuine, redacted screenshots of the screens you actually used. Do not claim the deployment was tested unless you completed it.