Deploying Spring Boot on AWS with an Application Load Balancer

A practical architecture guide for Java developers

Overview

An Application Load Balancer (ALB) distributes incoming HTTP/HTTPS requests across registered targets, such as Amazon EC2 instances running a Spring Boot application. It provides a stable entry point, health checks, and integration with AWS networking and security services.

This guide presents a common architecture using an internet-facing ALB and Spring Boot instances in private subnets across two Availability Zones. It is a reference design: validate service quotas, pricing, security requirements, and regional availability before using it in production.

What you will build

• Public HTTPS entry through an Application Load Balancer.
• A target group that routes requests to Spring Boot instances.
• EC2 instances in private subnets across two Availability Zones.
• Health checks that allow the ALB to determine whether a target can receive traffic.
• Security groups that restrict traffic to the intended paths.
• Optional Auto Scaling for replacing unhealthy instances and adjusting capacity.

Architecture diagram

The companion file aws_spring_boot_alb_architecture.svg contains an editable vector diagram of the design.

Request flow

1. A user opens https://api.example.com.
2. DNS resolves the hostname to the ALB endpoint (commonly through an Amazon Route 53 alias record).
3. The ALB terminates TLS using an ACM certificate and evaluates its listener rules.
4. The listener forwards matching requests to the target group.
5. The target group routes requests to healthy Spring Boot targets on the configured application port.
6. The Spring Boot application responds; the response travels back through the ALB to the client.

The ALB does not require the EC2 instances to have public IP addresses. In this design, instances are in private subnets and accept application traffic only from the ALB security group.

Main AWS components

Component	Responsibility
Amazon Route 53 (optional)	DNS record for the application hostname
Application Load Balancer	Public entry point, listener rules, TLS termination, traffic distribution
AWS Certificate Manager (ACM)	TLS certificate for the custom domain
Target group	Registered targets, target port, health-check settings
Amazon EC2	Runs the Java runtime and Spring Boot application
Auto Scaling group (optional)	Maintains desired capacity and can replace unhealthy instances
VPC and subnets	Network isolation across Availability Zones
Security groups	Restrict inbound and outbound traffic
Amazon CloudWatch	Metrics, logs (when configured), alarms, and dashboards

Network and security design

Use separate security groups to express the intended traffic path:

ALB security group

• Allow inbound TCP 443 from intended client networks; use 0.0.0.0/0 only if the application is intentionally public.
• If redirecting HTTP to HTTPS, allow TCP 80 as well.
• Allow outbound traffic to the application port on the target instances, subject to the security-group rules and your organization's policy.

EC2 application security group

• Allow inbound traffic on the Spring Boot application port (for example, TCP 8080) from the ALB security group only.
• Do not expose port 8080 directly to the public internet.
• Keep administrative access restricted. Prefer AWS Systems Manager Session Manager where suitable instead of opening SSH broadly.

Security groups are stateful. Keep the rules as narrow as practical and review them before deployment.

Spring Boot configuration

For example, the application may listen on port 8080:

server.port=8080

Create a health endpoint. With Spring Boot Actuator, a common liveness/readiness endpoint is:

/actuator/health

If you use Actuator, add the relevant dependency and configure exposure deliberately. Do not expose sensitive management endpoints publicly. Depending on the application, you may prefer a dedicated health-check endpoint that confirms the application can safely receive traffic.

Example target-group health-check settings (adjust to your app):

• Protocol: HTTP
• Port: traffic port (for example, 8080)
• Path: /actuator/health
• Success codes: 200
• Interval, timeout, and healthy/unhealthy thresholds: choose values appropriate to startup time and failure detection needs.

The health-check endpoint should return a successful response only when the instance is ready to serve requests. Test the endpoint from the target's network path before relying on it.

Setup checklist

1. Choose a VPC and Availability Zones. Create or select a VPC with public subnets for the ALB and private subnets for application instances. For a highly available design, use at least two Availability Zones.
2. Create security groups. Configure the ALB to accept the intended client traffic and the EC2 security group to accept the application port only from the ALB security group.
3. Provision the application instances. Launch EC2 instances or create an Auto Scaling group in the private subnets. Install a supported Java runtime and deploy the Spring Boot JAR or a container.
4. Create a target group. Select the target type (for example, instance), configure the application port and health-check path, then register the instances or attach the Auto Scaling group.
5. Create the ALB. Select an internet-facing scheme if public access is required, attach subnets in at least two Availability Zones, and associate the ALB security group.
6. Configure HTTPS. Create an HTTPS listener on port 443 and select an appropriate ACM certificate. Optionally configure an HTTP listener on port 80 to redirect to HTTPS.
7. Configure listener rules. Forward the intended host/path traffic to the target group. Keep default actions explicit.
8. Configure DNS. If using Route 53, create an alias record for the custom hostname pointing to the ALB.
9. Validate health and traffic. Confirm targets become healthy, then test the application through the ALB hostname or custom domain.
10. Add observability. Review ALB metrics, target response codes, access logs if enabled, application logs, and CloudWatch alarms.
11. Test failure handling. Stop one test instance or make it unhealthy in a non-production environment and verify that requests are served by other healthy targets.
12. Review cost and clean up. ALB, EC2, data transfer, NAT gateways, logs, and other resources can incur charges. Delete lab resources when finished.

Example deployment flow

Developer
   |
   v
Build Spring Boot JAR
   |
   v
Deploy to EC2 instances (or an Auto Scaling group)
   |
   v
Register instances in the target group
   |
   v
ALB HTTPS listener forwards requests
   |
   v
Healthy Spring Boot targets respond

This is a conceptual workflow, not an automated deployment script. A production pipeline could use Jenkins or AWS developer tools to build, test, scan, publish, and deploy the artifact.

Validation and troubleshooting

Symptom	What to check
Targets show unhealthy	Health-check path, success code matcher, app startup, port, security groups, and application logs
ALB returns 502	Target process/port, protocol mismatch, application closing connections, and target response
ALB returns 503	Whether healthy targets are registered and available; listener forwarding configuration
Requests time out	Route tables, network ACLs, security groups, application response time, and dependency latency
HTTPS certificate warning	Certificate domain coverage, listener certificate selection, and DNS hostname
Works on instance but not through ALB	Listener rules, target-group registration, health state, and ALB-to-instance security-group path

Troubleshoot from the outside inward: DNS, listener and certificate, target group health, network permissions, then application behavior. Use CloudWatch metrics and logs to narrow down the failing layer.

Availability and scaling considerations

• Deploy targets across at least two Availability Zones.
• Use an Auto Scaling group when automated capacity management and instance replacement are required.
• Set scaling policies based on workload-appropriate metrics; CPU alone may not reflect application saturation.
• Keep the application stateless where possible. Store shared durable data in managed services rather than local instance storage.
• Configure graceful shutdown and sensible connection, request, and timeout settings.
• Test deployments and instance replacement behavior in a non-production environment.

Cost considerations

Costs depend on region, load-balancer usage, EC2 instance type and runtime, data transfer, NAT gateways, logging, and related services. Review current AWS pricing for your selected region before deployment. For a short-lived learning environment, remove resources after testing and verify that no billable resources remain.

Production-readiness checklist

• HTTPS listener uses a valid ACM certificate.
• Public access is limited to the ALB; application instances are not directly exposed.
• EC2 security group permits the application port only from the ALB security group.
• Targets span multiple Availability Zones.
• Health checks represent application readiness.
• Logs, metrics, alarms, and access logging are configured as required.
• Secrets are not hardcoded in source code or AMIs.
• Deployment and rollback procedures are documented and tested.
• Capacity, timeouts, and scaling policies have been load-tested.
• Cost and resource cleanup have been reviewed.

Conclusion

An Application Load Balancer gives a Spring Boot application a managed HTTP/HTTPS entry point, health-based routing, and a foundation for multi-AZ deployment. The ALB alone does not make an application highly available: the targets, data tier, deployment process, network configuration, and operational practices must also be designed and tested for resilience.

Note: AWS console labels and service options can change. Verify current AWS documentation and regional pricing before implementing this architecture.