Deploy a Spring Boot App on AWS EC2 With a Load Balancer: Step-by-Step Guide

Published · Updated

To deploy a Spring Boot web application on EC2 behind a load balancer, run the packaged JAR as a managed service, register the instance in an Application Load Balancer target group, and allow the application port only from the load balancer’s security group. The ALB receives public HTTP or HTTPS traffic and forwards requests only to targets that pass the configured health check.

This is a learning deployment, not a complete production blueprint. It deliberately uses one EC2 target first so that every component is visible. For instance replacement and horizontal capacity, continue to the Spring Boot Auto Scaling guide.

Architecture and prerequisites

The request path is:

Browser → ALB listener → target group → EC2:8080 → Spring Boot

You need an AWS account with permission to create EC2, security group, target group, and ALB resources; a Spring Boot web application; and a supported Java version for that application. The commands below assume Maven and a runnable JAR. Gradle users can use the equivalent bootJar task.

AWS resources in this tutorial incur charges. Check the EC2 and Elastic Load Balancing pricing pages for your Region before starting, and follow the cleanup section.

1. Package and test the application

Build and run the tests locally:

./mvnw clean verify
java -jar target/your-app.jar

Confirm the application responds on port 8080. For a dedicated health endpoint, add the Spring Boot Actuator dependency and use /actuator/health. Spring Boot exposes the health endpoint over HTTP by default; its Actuator documentation warns that additional endpoints can contain sensitive data and should be secured.

Do not use a business endpoint that writes data as a health check. A health request should be fast, safe, and return a success status only when this instance can accept traffic.

2. Create separate security groups

Use two security groups rather than opening port 8080 to the internet.

ALB security group

  • Inbound TCP 80 from 0.0.0.0/0 and ::/0 for this HTTP lab.
  • For a real site, add HTTPS 443 with an AWS Certificate Manager certificate and redirect HTTP to HTTPS.
  • Outbound to the instance security group on TCP 8080.

EC2 application security group

  • Inbound TCP 8080 with the ALB security group as the source.
  • No public inbound rule for port 8080.
  • If you use SSH, restrict TCP 22 to your current trusted IP. Prefer a managed access route such as AWS Systems Manager Session Manager where it is configured.

AWS gives the same target-security-group pattern in its ALB target registration guidance: allow the load balancer security group to reach the instance listener and health-check ports.

3. Launch and prepare the EC2 instance

Launch an instance in the VPC where the ALB will run. Choose a current supported AMI and an instance size appropriate for the application’s memory needs; free-tier eligibility and instance availability vary by account and Region.

Install the same Java major version used to build the application. Copy the JAR to a dedicated application directory, for example /opt/techeazy-app/app.jar. Do not bake database passwords, API keys, or AWS access keys into the JAR, user data, AMI, or service file. Give the instance an IAM role with only the permissions it needs and retrieve configuration from an appropriate managed store.

Create a non-login service account and a systemd unit instead of relying on nohup:

[Unit]
Description=Spring Boot application
After=network-online.target
Wants=network-online.target

[Service]
User=techeazyapp
WorkingDirectory=/opt/techeazy-app
ExecStart=/usr/bin/java -jar /opt/techeazy-app/app.jar
Restart=on-failure
RestartSec=5
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

Save it as /etc/systemd/system/techeazy-app.service, then run:

sudo systemctl daemon-reload
sudo systemctl enable --now techeazy-app
sudo systemctl status techeazy-app
curl --fail http://127.0.0.1:8080/actuator/health

Adjust the JAR path, Linux user, and health path to match your application. Use journalctl -u techeazy-app for service logs.

4. Create the target group

In EC2, create a target group with these lab settings:

  • target type: Instances;
  • protocol and port: HTTP:8080;
  • VPC: the instance VPC;
  • health-check protocol: HTTP;
  • health-check path: /actuator/health, or your tested read-only health path;
  • success code: the actual success response from that endpoint, normally 200.

Register the EC2 instance. A target must be registered, referenced by a listener rule, located in an enabled Availability Zone, and pass health checks before it receives normal traffic. See AWS’s target-group health-check reference.

If the target stays unhealthy, check the application process, port, health path, response status, Availability Zone selection, and both security groups before changing thresholds.

5. Create the Application Load Balancer

Create an internet-facing Application Load Balancer in the same VPC. Select subnets in at least two Availability Zones and attach the ALB security group. Add an HTTP listener on port 80 whose default action forwards to the target group.

An ALB is the appropriate ELB family for this HTTP tutorial because it evaluates listener rules at the application layer. The ELB beginner guide explains when ALB, NLB, or GWLB fits.

Copy the ALB DNS name after it becomes active:

curl --fail http://your-alb-name.region.elb.amazonaws.com/your-endpoint

Then inspect Target groups → Targets and confirm the instance is Healthy. AWS documents listeners, rules, target groups, and health checks in its Application Load Balancer overview.

6. Close the production gaps

Before treating this architecture as production-ready:

  • terminate TLS on an HTTPS listener with a valid certificate and redirect HTTP;
  • use private subnets for application instances and avoid public IP addresses where the network design permits;
  • send application and platform logs to durable centralized storage;
  • keep secrets outside images and deployment scripts;
  • configure monitoring, alarms, backups, and tested recovery procedures;
  • make the application stateless or move session state outside individual instances; and
  • deploy multiple healthy targets across Availability Zones and automate replacement.

A load balancer does not make one backend highly available. It only has another healthy target to choose when you actually provide one.

7. Clean up the lab

Delete resources you no longer need. Start by deleting the ALB and target group, then terminate the EC2 instance and remove unused security groups. Also check for snapshots, AMIs, Elastic IP addresses, log storage, and other resources created during experimentation. Verify the billing console rather than assuming that stopping an instance removes every charge.

Next, learn the underlying Auto Scaling Group concepts or build the full ASG and ALB version of this Spring Boot deployment. The broader architecture skills connect to the Cloud/AI Solutions Architect program.