Below is a step-by-step, “article-style” guide to configure an AWS Load Balancer for a new Spring Boot application. I’ll show a clean, production-friendly setup using Application Load Balancer (ALB) (best fit for HTTP/HTTPS, path-based routing, host-based routing, WebSockets, etc.). I’ll include both EC2 + Auto Scaling and ECS/Fargate notes where it matters.

---

Configure an AWS Application Load Balancer for a Spring Boot App (Step-by-Step)

What you’re building

A typical secure AWS setup looks like this:

Internet → ALB (HTTP/HTTPS) → Target Group → Spring Boot instances/containers

The load balancer:

• Terminates TLS (HTTPS)

• Health-checks your app

• Distributes traffic across instances

• Supports scaling and zero-downtime deployments (with the right strategy)

---

Prerequisites

Before creating the load balancer, decide these basics:

1. Where is Spring Boot running?

   • EC2 instances (common)

   • ECS/Fargate (common)

   • EKS (then you’ll likely use AWS Load Balancer Controller; similar concepts)

2. App port

   • Common: 8080 (Spring Boot default)

   • We’ll assume 8080

3. Health endpoint

   • Best practice: /actuator/health (Spring Boot Actuator)

   • Use the “liveness” style endpoint for ALB checks where possible

---

Step 1: Prepare the Spring Boot app for ALB health checks

Enable actuator (recommended)

In build.gradle / pom.xml, include actuator.

Then configure:

• Expose health endpoint

• Ensure it returns 200 OK

Example application.yml:

management:
  endpoints:
    web:
      exposure:
        include: health,info
  endpoint:
    health:
      probes:
        enabled: true

Recommended health paths:

• /actuator/health (simple)

• /actuator/health/liveness (even better for ALB checks)

Tip: ALB health checks must succeed quickly—avoid slow DB checks on the main health check path unless you specifically want that behavior.

---

Step 2: Network foundation (VPC + subnets)

For an internet-facing ALB, you want:

• VPC

• 2+ public subnets in different AZs (ALB requirement for HA)

• Route table for public subnets with route to an Internet Gateway

Also ensure your backend compute (EC2/ECS tasks) is in:

• private subnets (recommended), OR

• public subnets (simpler but less ideal)

---

Step 3: Create / confirm Security Groups

You’ll typically use two security groups:

A) ALB Security Group (inbound from the internet)

Inbound rules:

• HTTP 80 from 0.0.0.0/0 (optional; often used only to redirect to HTTPS)

• HTTPS 443 from 0.0.0.0/0 (recommended for production)

Outbound:

• Allow all (default is fine), or restrict to backend security group ports.

B) Application Security Group (inbound only from ALB)

Inbound rules:

• Custom TCP 8080 source = ALB security group

• SSH 22 only from your VPN/bastion/office IP (if EC2; avoid opening to world)

This is the key security pattern: instances accept app traffic only from the ALB.

---

Step 4: Create a Target Group

Go to EC2 → Target Groups → Create target group

Choose:

• Target type

  • Instance (if EC2)

  • IP (if ECS/Fargate, or if you want to register IPs)

  • Lambda (rare for Spring Boot directly)

Configuration:

• Protocol: HTTP

• Port: 8080

• VPC: your VPC

Health checks:

• Protocol: HTTP

• Path: /actuator/health (or /actuator/health/liveness)

• Healthy threshold: 2–3

• Unhealthy threshold: 2–3

• Timeout: 5s

• Interval: 15–30s

• Success codes: 200 (or 200-399 depending on your endpoint)

Pro tip: Start with /actuator/health and 200-399 if you have redirects or special behavior.

Register targets:

• If EC2: select instances and add them (or let Auto Scaling do it later)

• If ECS: ECS service will attach tasks automatically

---

Step 5: Create the Application Load Balancer (ALB)

Go to EC2 → Load Balancers → Create Load Balancer → Application Load Balancer

1. Name it (e.g., springboot-alb-prod)

2. Scheme: Internet-facing (or internal if private)

3. IP address type: IPv4 (or dualstack if needed)

4. Network mapping:

   • Select your VPC

   • Select at least two public subnets across AZs

5. Security group: attach the ALB SG you created

---

Step 6: Configure ALB Listeners and Rules

Option A (common): HTTP redirects to HTTPS + HTTPS forwards to target group

Listener 80 (HTTP):

• Action: Redirect to HTTPS 443

Listener 443 (HTTPS):

• Attach an ACM certificate

• Forward to your target group

Add TLS Certificate (ACM)

Go to AWS Certificate Manager (ACM):

• Request a public certificate for app.yourdomain.com

• Validate via DNS (recommended)

• Once “Issued”, select it in the ALB 443 listener

---

Step 7: Connect ALB to your Spring Boot compute

If using EC2 + Auto Scaling (recommended for reliability)

1. Put your EC2 instances into an Auto Scaling Group

2. In the ASG, attach the Target Group

3. Ensure instances use Application SG and are in correct subnets

4. Confirm your app runs on 8080 and is reachable from ALB SG

If using ECS/Fargate

1. Create/update ECS Service

2. Enable Load balancing

3. Choose the ALB, listener, and target group

4. Ensure task security group allows 8080 inbound from ALB SG

5. Confirm container port mapping exposes 8080

---

Step 8: Configure DNS (Route 53)

If you own the domain in Route 53:

Route 53 → Hosted zone → Create record:

• Record name: app (for app.yourdomain.com)

• Type: A (Alias)

• Alias to: your ALB DNS name

Now your public URL points to the ALB.

---

Step 9: Validate end-to-end

1. Open the ALB DNS name:

   • http://<alb-dns> (should redirect to HTTPS)

   • https://<alb-dns> (should show your app)

2. Check target group health:

   • Targets should be healthy

3. Check logs if unhealthy:

   • Security group rules (most common issue)

   • Health check path/port wrong

   • App not listening on 0.0.0.0 / port mismatch

---

Step 10: Production-grade hardening (highly recommended)

Enable access logs

ALB → Attributes → Access logs → store in S3
Great for debugging and audit.

Enable deletion protection (prod)

Prevents accidental deletion.

Stickiness (only if needed)

If your app uses in-memory sessions (not ideal), enable stickiness. Better: use stateless JWT or external session store.

Timeouts

Tune:

• Idle timeout (default 60s)
  Useful for long requests or SSE/WebSockets patterns.

Use WAF (for internet-facing apps)

Attach AWS WAF to ALB:

• Managed rule groups

• Rate limiting

• IP reputation filters

Use HTTPS-only

Disable HTTP listener or always redirect HTTP → HTTPS.

---

Common Spring Boot + ALB gotchas (and fixes)

1. Health check failing

   • Fix path (/actuator/health)

   • Confirm actuator exposure

   • Confirm security group allows ALB → app port

2. Wrong port

   • ALB forwards to 8080, but app actually runs on 80 or 5000

   • Align target group port + runtime port

3. App binds to localhost

   • Ensure server binds to 0.0.0.0 (typical in containers)

   • Spring Boot default is usually fine on EC2

4. TLS at ALB + app thinks it’s HTTP

   • Add forwarded headers support:

     • For modern Spring Boot, set:

       server.forward-headers-strategy=framework
       

   • Helps with redirects, scheme detection, secure cookies.

---

Quick reference: minimal checklist

• ALB in 2 public subnets

• ALB SG allows 443 from internet

• App SG allows 8080 from ALB SG

• Target group port 8080, correct health path

• Listener 443 forwards to target group

• ACM cert attached + Route 53 alias record

• Targets show healthy

---

If you tell me EC2 vs ECS/Fargate, your domain setup (Route53 or external), and whether you want blue/green deployments, I can tailor this into an even more “copy/paste runnable” runbook (including exact security group rules, recommended health endpoints, and deployment strategy).