AWS Elastic Load Balancer (ELB) Beginner's Guide: ALB vs NLB vs GWLB, With FAQ
Published · Updated
Elastic Load Balancing (ELB) is the AWS service that accepts incoming traffic and spreads it across several registered targets, such as EC2 instances, containers or IP addresses, in one or more Availability Zones. It checks the health of those targets and sends traffic only to the healthy ones. In AWS’s own words, a load balancer “monitors the health of its registered targets and ensures that it routes traffic only to healthy targets” (How Elastic Load Balancing works).
ELB makes horizontal scaling and higher availability practical. It cannot make a single backend, or a broken application, highly available on its own.
What is an example of elastic load balancing?
A typical example: an online shop runs its web application on three EC2 instances, spread over two Availability Zones. Customers do not connect to any instance directly. They connect to one load balancer address, and the load balancer forwards each request to one of the three instances.
Now one instance stops answering its health check, perhaps because the application crashed. The load balancer marks it unhealthy and stops sending it requests. Customers keep being served by the other two. When the instance recovers, or an Auto Scaling group replaces it, the load balancer starts sending it traffic again.
That is the core process ELB performs: distributing incoming traffic across multiple targets so that no single server carries the whole load, and routing around targets that fail their health checks. Adding a fourth instance to the target group, or removing one for maintenance, works the same way, without changing the address customers use.
Follow one request through ELB
For an 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 on port 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, the backend protocol and port, and the health-check settings.
- A target is a registered destination: an EC2 instance, an IP address or, for an ALB, a Lambda function.
AWS’s Application Load Balancer overview explains that listener rules select target groups and that health checks are configured per target group.
Before any of that, the client resolves the load balancer’s DNS name. AWS returns the IP addresses of the load balancer’s nodes, and the node that receives the request picks a healthy target and forwards the request to it using the target’s private IP address.
ALB vs NLB vs GWLB vs Classic: which load balancer should you use?
AWS documents four load balancer types. Three are current; Classic Load Balancer is the previous generation. This summary follows AWS’s product comparison:
| Application (ALB) | Network (NLB) | Gateway (GWLB) | Classic (CLB) | |
|---|---|---|---|---|
| Works at | Layer 7 (application) | Layer 4 (transport) | Layer 3 gateway with layer 4 load balancing | Layer 4 and 7 |
| Traffic | HTTP, HTTPS, gRPC | TCP, UDP, TLS | IP packets | TCP, SSL/TLS, HTTP, HTTPS |
| Target types | Instance, IP, Lambda | Instance, IP, ALB | Instance, IP | Instances |
| Static IP addresses | No; use its DNS name | Yes, with optional Elastic IPs | No | No |
| Typical use | Web apps and APIs needing path- or host-based routing | Non-HTTP protocols, fixed IP addresses, connection-level handling | Firewalls and inspection appliances | Older systems not yet migrated |
Application Load Balancer (ALB)
Choose an ALB for HTTP and HTTPS applications that need application-layer routing. It can route on host, path, headers, method, query string and source IP. This is the right choice for an ordinary web application or REST API, such as the Spring Boot EC2 tutorial, where an HTTP listener forwards to a target group on port 8080.
Network Load Balancer (NLB)
Choose an NLB for transport-layer traffic, which its documentation lists as TCP, UDP, TCP_UDP, TLS and QUIC target groups, or when clients need fixed IP addresses. Each enabled Availability Zone gets a static IP address, and an internet-facing NLB can use one Elastic IP address per subnet. Do not pick it simply because it is described as “faster”. Choose on protocol, addressing and connection behaviour.
Gateway Load Balancer (GWLB)
Choose a GWLB to deploy and scale third-party virtual network appliances, such as firewalls or intrusion-detection systems, transparently in the traffic path. It exchanges traffic with those appliances using the GENEVE protocol on port 6081. It is not a replacement for an ALB in front of a web application.
Classic Load Balancer (CLB)
CLB is the previous generation. You may meet it in older environments, but new designs should start with an ALB or NLB. AWS lists all four types in the Elastic Load Balancing documentation.
How does ELB decide which target gets a request?
It depends on the load balancer type (routing algorithms):
- ALB evaluates listener rules in priority order, then picks a target from the chosen target group. The default algorithm is round robin. A target group can switch to least outstanding requests, which favours targets with fewer requests in progress, or weighted random (ALB target group attributes).
- NLB uses a flow hash of the protocol, source and destination addresses and ports, and the TCP sequence number. Each TCP connection stays on one target for its lifetime.
- GWLB uses a flow hash too, so all packets of one flow reach the same appliance.
- CLB uses round robin for TCP listeners and least outstanding requests for HTTP and HTTPS listeners.
So “ELB always sends traffic to the least busy server” is not accurate. The behaviour depends on the type and on how the target group is configured.
Cross-zone load balancing
Each Availability Zone you enable gets a load balancer node. With cross-zone load balancing on, each node spreads traffic across targets in every enabled zone. With it off, each node uses only targets in its own zone, so a zone with fewer targets puts more load on each of them. For an ALB it is always on at the load balancer level and can be turned off per target group. For NLB and GWLB it is off by default and can be turned on.
Health checks control routing
The load balancer periodically checks each registered target using the target group’s protocol, port and path. A target receives normal traffic once it passes its health check. Repeated failures take it out of service until it is healthy again.
Choose a health-check path that responds quickly and does not change any data. It should report whether this instance can serve traffic, without depending on so many shared systems that one failing 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 disaster-recovery plan. AWS documents that an ALB fails open: if it does not have enough healthy targets, it sends traffic to all registered targets regardless of health. Plan your monitoring with that in mind. See ALB target-group health checks.
Internet-facing or internal?
When you create a load balancer you choose its scheme. An internet-facing load balancer has nodes with public IP addresses and accepts traffic from the internet. An internal load balancer has only private IP addresses and accepts traffic only from clients that can reach its VPC.
Both route to targets using private IP addresses, so your targets do not need public IP addresses. A common pattern for a multi-tier application uses an internet-facing load balancer in front of the web tier and an internal load balancer in front of the application tier.
Secure the traffic path
For an internet-facing ALB:
- Allow public inbound traffic only on the listener ports you intend to use, normally HTTPS 443, plus HTTP 80 if you redirect it.
- Use a certificate and a current TLS security policy.
- Give backend instances their own security group.
- Allow the application and health-check ports on that group only from the load balancer’s security group, not from the whole internet.
- Keep administrative ports closed to the internet and use managed access where possible.
AWS recommends using the load balancer’s security group as the source for target ports in its target registration documentation.
Terminating TLS at the load balancer protects the client-to-load-balancer leg. Decide separately whether you also need encryption from the load balancer to targets. Consider AWS WAF, authentication and rate limiting where the system needs them. A load balancer is not an authorisation boundary on its own.
Availability needs healthy capacity
Select subnets in at least two Availability Zones (an ALB requires this), and run healthy targets in more than one zone when availability matters. A load balancer in front of one EC2 instance still has one point of failure. Three targets that all depend on one failing database are not three independent stacks.
For automatic registration and replacement of instances, attach the target group to an Auto Scaling group. The ASG beginner guide covers capacity and health replacement, and the Spring Boot scaling tutorial combines the two services.
Observe before tuning
Watch target health, response codes, latency and connection behaviour. Access logs and CloudWatch metrics show whether failures start at the load balancer, the target or the application. Tune timeouts, deregistration delay, health thresholds, routing algorithm and stickiness only from measured behaviour.
Sticky sessions can help a legacy stateful application, but they concentrate a user’s traffic on one target and do not survive target replacement. Moving session state out of the instance is usually the stronger design.
Costs and cleanup
Load balancers are billed while they run, even for a lab. ALB, NLB and GWLB charge per hour plus capacity units (LCUs, NLCUs and GLCUs); Classic charges per hour plus data processed. Data transfer and related services add to that. New accounts may have free-tier coverage. Check the current ELB pricing page for your Region.
When a lab ends, delete the load balancer and unused target groups, then remove instances, Auto Scaling groups, security groups, certificates and logs after checking what depends on them. Stopping an EC2 instance does not delete the load balancer, and the load balancer keeps billing.
Elastic Load Balancer FAQ
What is AWS Elastic Load Balancing in simple terms?
It is a managed service that gives your application one entry point and spreads incoming traffic across several servers or containers behind it, skipping any that fail their health checks.
Is ELB a single service or several?
One service with four load balancer types: Application, Network, Gateway and Classic. “ELB” usually refers to the service as a whole, and “ALB” or “NLB” to a specific type.
What is the difference between ALB and NLB?
An ALB understands HTTP and routes on request details such as path and host. An NLB works at the connection level for TCP, UDP and TLS, and can have static IP addresses. Use an ALB for web apps and APIs. Use an NLB for non-HTTP protocols or when clients need fixed IPs.
Does an Application Load Balancer have a static IP address?
No. Clients reach an ALB through its DNS name, whose IP addresses can change as it scales; AWS sets a 60-second TTL on that record. If you need fixed IP addresses, use an NLB, which supports static and Elastic IP addresses.
Does ELB scale automatically?
Yes. AWS scales the load balancer itself as traffic changes and updates its DNS entry. It does not add servers behind it. That is the job of an Auto Scaling group.
What is the difference between ELB and Auto Scaling?
ELB distributes traffic across the targets that exist. Auto Scaling changes how many targets exist. They are usually used together: the Auto Scaling group registers new instances with the target group and replaces unhealthy ones.
Can one load balancer serve several applications?
An ALB can. Listener rules can send different hostnames or paths to different target groups, so one ALB can front several services.
Is Classic Load Balancer deprecated?
AWS calls it the previous generation. Existing ones keep working, but new workloads should use an ALB or NLB.
Is Elastic Load Balancing free?
No. It is billed per hour plus usage, as described in the costs section above. Some new accounts receive limited free-tier usage. Always confirm on the pricing page and delete lab load balancers when you finish.
Next step
For a complete first build, continue to deploying Spring Boot on EC2 with an ALB. These cloud architecture fundamentals are part of the Cloud/AI Solutions Architect program.