AWS Elastic Load Balancer (ELB): A Beginner's Guide

Published · Updated

Elastic Load Balancing (ELB) is the AWS service that accepts traffic and distributes it across registered targets. A load balancer listens on a protocol and port, applies routing behavior, and sends requests or connections to targets that meet its health criteria. ELB can improve availability and make horizontal scaling practical, but it cannot make a single backend or a broken application highly available on its own.

Follow one request through ELB

For a typical HTTP service behind an Application Load Balancer, the path is:

Client → listener → listener rule → target group → healthy target

  • A listener accepts connections on a configured protocol and port, such as HTTPS 443.
  • A listener rule evaluates conditions and chooses an action, such as forwarding /api/* to an API target group.
  • A target group defines the target type, backend protocol and port, and health-check settings.
  • A target is a registered destination such as an EC2 instance, IP address, or—in supported ALB configurations—a Lambda function.

AWS’s Application Load Balancer overview explains that listener rules select target groups and health checks operate per target group.

Choose the load balancer family

AWS currently documents Application, Network, Gateway, and Classic Load Balancers. The first three are the modern families used for distinct traffic patterns; Classic Load Balancer is previous-generation and should mainly be encountered in legacy environments.

Application Load Balancer (ALB)

Use an ALB for HTTP and HTTPS applications that need application-layer routing. It can route using hosts, paths, headers, methods, query strings, and source IP conditions. This is the natural choice for the Spring Boot EC2 tutorial, where an HTTP listener forwards to a target group on port 8080.

Network Load Balancer (NLB)

Use an NLB for transport-layer TCP, TLS, UDP, and TCP_UDP traffic when the workload needs connection-level handling and NLB-specific network capabilities. Do not select it merely because a page claims every NLB workload is “faster”; choose based on protocol, addressing, connection behavior, and architecture requirements.

Gateway Load Balancer (GWLB)

Use a GWLB to deploy and scale compatible virtual network appliances, such as inspection or firewall systems, through a transparent network gateway pattern. It is not a substitute for an ALB in front of an ordinary Spring Boot HTTP service.

Classic Load Balancer (CLB)

CLB is the previous generation. Existing systems may still use it, but new designs should evaluate ALB or NLB based on the application protocol and required features. AWS lists all four families in the Elastic Load Balancing documentation.

Health checks control routing

An ALB periodically checks each registered target using the target group’s configured protocol, port, and path. After a target passes its initial health check, it can receive normal traffic. Repeated failed checks take it out of service until it becomes healthy again.

Choose a path that answers quickly and does not mutate state. It should reflect whether this instance can serve traffic, without depending on so many external systems that one shared dependency marks every target unhealthy at once. For Spring Boot, /actuator/health is a common starting point when Actuator is configured appropriately.

Health checks are not a complete disaster-recovery strategy. AWS documents that an ALB can fail open if every registered target in every enabled Availability Zone is unhealthy, routing to all targets despite their health status. Design monitoring and failure handling with that behavior in mind. See ALB target-group health checks.

Secure the traffic path

For an internet-facing ALB architecture:

  1. Allow public inbound traffic only on the intended ALB listener ports, normally HTTPS 443 and optionally HTTP 80 for redirection.
  2. Use a certificate and current TLS policy appropriate to the application.
  3. Give backend instances a separate security group.
  4. Allow the application and health-check ports on the instance security group from the ALB security group, not from the whole internet.
  5. Keep administrative ports restricted and use managed access where possible.

AWS explicitly recommends using the load balancer security group as the source for target listener and health-check ports in its target registration documentation.

TLS termination at the load balancer protects the client-to-ALB leg. Decide separately whether compliance or threat models require encryption from the load balancer to targets. Also consider AWS WAF, authentication, rate limiting, and application-layer authorization where the system requires them; a load balancer is not an authorization boundary by itself.

Availability requires healthy capacity

Select subnets in multiple Availability Zones for an internet-facing ALB, and run healthy targets in more than one zone when availability matters. A load balancer in front of one EC2 instance still has one application failure point. Likewise, three targets that all depend on one failing database are not three independent application stacks.

ALB target groups can use round robin by default or other supported routing algorithms configured as target-group attributes. Avoid describing routing as always selecting the “least busy server”; the actual behavior depends on load balancer family and configuration.

For automatic instance registration and replacement, attach the target group to an Auto Scaling group. The ASG beginner guide explains capacity and health replacement, while the Spring Boot scaling tutorial combines both services.

Observe before tuning

Monitor target health, response codes, latency, connection behavior, and capacity. Access logs and CloudWatch metrics can help answer whether failures begin at the load balancer, target, or application. Tune timeouts, deregistration delay, health thresholds, routing algorithms, and stickiness only from measured application behavior.

Sticky sessions can help a legacy stateful application, but they also concentrate a user’s traffic on one target and do not preserve state after target replacement. Externalizing session state is usually a stronger scaling design.

Costs and cleanup

Elastic Load Balancing is billable even when the backend is only a lab. Charges depend on the load balancer family, running time, and processed capacity dimensions; data transfer and associated AWS services can add cost. Consult the current ELB pricing page for the selected Region and usage.

When a lab ends, delete the load balancer and unused target groups, then remove instances, Auto Scaling groups, security groups, certificates, logs, and other resources only after checking their dependencies. Stopping an EC2 instance does not delete the load balancer.

For a complete first build, continue to deploying Spring Boot on EC2 with an ALB. These cloud architecture fundamentals also support the Cloud/AI Solutions Architect program.