AWS Load Balancers Explained for Beginners: ALB vs NLB, Listeners, Target Groups, and Health Checks

A load balancer is a service that distributes incoming network traffic across multiple servers or application targets. Instead of every user connecting directly to one server, users connect to a shared endpoint, and the load balancer forwards their traffic to suitable backend resources.

In AWS, this functionality is provided by Elastic Load Balancing (ELB).

Two widely used types are:

• Application Load Balancer (ALB): Designed for application-layer HTTP and HTTPS traffic, with advanced routing based on details of the request.

• Network Load Balancer (NLB): Designed for transport-layer traffic, including TCP and UDP, with high-performance connection handling and static IP capabilities.

But why would an application need a load balancer? How does AWS decide which server receives a request? And what is the difference between a listener, target group, and health check?

Let's understand everything from the beginning using simple examples.

1. Why Do We Need a Load Balancer?

Imagine you build a website using Next.js and deploy it on one EC2 instance.

Your architecture looks like this:

Visitors → EC2 Web Server

Suppose the server handles requests from hundreds of users.

Initially, everything works well.

But as your application becomes more popular, more people start using it simultaneously.

The server must process more requests, use more memory, handle more database connections, and manage more network activity.

Eventually, you might face problems such as:

• Slow page loading.

• Higher CPU and memory utilization.

• Request timeouts.

• Reduced responsiveness.

• Application unavailability when the server fails.

One possible solution is to upgrade your EC2 instance.

For example, you might move from an instance with 2 vCPUs to one with 4 vCPUs.

This is called vertical scaling.

But there is another approach.

Instead of increasing the capacity of a single server, you can run multiple servers and distribute traffic between them.

This is called horizontal scaling.

Vertical scaling vs horizontal scaling

What happens when we add three servers?

Suppose we launch three EC2 instances running the same application.

All three servers are capable of handling website requests.

But now we have a new problem.

How does a visitor know which server to connect to?

We don't want visitors to manually choose an EC2 IP address.

We also don't want every visitor to be sent to the same server while the other servers remain idle.

This is where a load balancer becomes useful.

With a load balancer:

Visitors → Load Balancer → EC2 A / EC2 B / EC2 C

Visitors connect to one public endpoint.

The load balancer distributes their requests across the available application servers.

The user doesn't need to know which EC2 instance handles each request.

That decision is managed by the load balancer.

2. What Is Elastic Load Balancing (ELB) in AWS?

Elastic Load Balancing (ELB) is an AWS service that distributes incoming application or network traffic across registered targets.

Those targets may include EC2 instances, IP addresses, containers, and certain other resources, depending on the load balancer type.

ELB also monitors target health and can stop sending new traffic to unhealthy targets under normal operating conditions.

This makes it useful for improving:

• Availability.

• Fault tolerance.

• Traffic distribution.

• Horizontal scaling.

• Application traffic management.

Is ELB the same as ALB?

Not exactly.

ELB is the overall AWS load-balancing service.

ALB and NLB are different load balancer types provided by that service.

AWS supports several load balancer families:

Classic Load Balancer remains relevant to certain legacy environments, but modern applications generally start by evaluating ALB or NLB.

This article focuses on those two types.

3. What Is an Application Load Balancer (ALB)?

An Application Load Balancer operates at Layer 7, also called the Application Layer, of the OSI networking model.

That may sound technical, but the idea is straightforward.

An ALB understands application-level HTTP and HTTPS requests.

For example, it can examine:

• The requested hostname.

• The URL path.

• HTTP headers.

• HTTP request methods.

• Query-string conditions.

It can then use those details to decide where a request should go.

Example: A website with multiple services

Suppose your application has three backend services.

You want all three services to be available through one domain:

example.com

Without application-aware routing, you would need another component to determine which service should receive each HTTP request.

With an Application Load Balancer, you can define rules such as:

Now consider three incoming requests.

Request 1:

https://example.com/

The ALB sends the request to the website target group.

Request 2:

https://example.com/api/products

The ALB sends the request to the API target group.

Request 3:

https://example.com/admin/dashboard

The ALB sends the request to the admin target group.

The ALB makes these decisions using application-level information.

This is called path-based routing.

What is host-based routing?

An ALB can also make routing decisions using the requested hostname.

Suppose you have:

• example.com

• api.example.com

• admin.example.com

You can create listener rules such as:

All three hostnames can point to the same ALB, which forwards requests to the appropriate target groups.

This is called host-based routing.

It is especially useful for applications built using multiple services.

Does ALB always distribute traffic equally?

No.

An ALB supports different target-selection algorithms and routing configurations.

For a conventional target group, the default algorithm is round robin.

This means requests are distributed among eligible targets in rotation, rather than guaranteeing that every server receives exactly the same number of requests over every time period.

Other supported algorithms include least outstanding requests and weighted random, subject to applicable configuration requirements.

Health status, sticky sessions, request duration, and routing rules can also influence actual distribution.

The goal is to route requests appropriately, not guarantee perfectly identical utilization across all servers.

4. What Is a Network Load Balancer (NLB)?

A Network Load Balancer primarily operates at Layer 4, the Transport Layer, of the OSI networking model.

Instead of routing based on HTTP paths or headers, it distributes network connections or flows using transport-layer information.

That includes information such as:

• Source and destination IP addresses.

• Source and destination ports.

• Transport protocol.

• Connection or flow characteristics.

An NLB is designed for high-performance networking and workloads that need protocols beyond ordinary HTTP routing.

Its supported listener protocols include TCP, TLS, UDP, TCP_UDP, and, in current AWS documentation, QUIC and TCP_QUIC with specific configuration requirements.

For beginners, the most important protocols to understand are TCP, UDP, and TLS.

Example: A TCP application

Suppose you have a custom backend service listening on TCP port 9000.

You run this service on three EC2 instances.

Clients connect to the NLB endpoint using TCP port 9000.

The NLB selects an eligible backend target for each connection or flow according to its routing behavior.

Client → NLB:9000 → One of the TCP servers

The NLB doesn't need to understand the application's URL paths because this service may not use HTTP at all.

Example: A UDP application

Some real-time applications use UDP rather than TCP.

Examples may include certain gaming, telemetry, voice, or other custom network services.

An NLB supports UDP traffic, making it suitable for workloads that an Application Load Balancer cannot handle directly.

Does NLB support HTTPS applications?

Yes, depending on how it is configured.

HTTP and HTTPS applications ultimately use underlying transport protocols, and an NLB can forward suitable TCP or TLS traffic.

However, an NLB does not provide ALB-style HTTP content routing based on paths such as /api/* or request hostnames.

So if your requirement is advanced HTTP routing, ALB is usually the more natural choice.

If you require fixed public IP addresses, transport-level behavior, or protocols such as UDP, NLB may be more suitable.

5. Understanding Layer 4 vs Layer 7

The difference between Layer 4 and Layer 7 is the foundation of ALB vs NLB.

Let's use a simple example.

Imagine a large office building receiving deliveries.

At the entrance, a security desk sees the destination building and delivery information.

A basic transport-level dispatcher may use connection details to decide which receiving point should handle the delivery.

An application-aware dispatcher can inspect the delivery's destination department and send it to the correct team.

This is similar to the difference between Layer 4 and Layer 7.

Layer 4: Transport Layer

Layer 4 deals with how applications exchange data over transport protocols such as TCP and UDP.

A Layer 4 load balancer can use connection or flow information to select a backend.

For example:

Client:54000 → Service:9000 (TCP)

The NLB uses its flow-based routing process to select a target.

It does not need to inspect an HTTP path.

Layer 7: Application Layer

Layer 7 understands higher-level application protocols.

For example:

GET /api/products HTTP/1.1

An ALB can evaluate the HTTP request and route it according to path, host, or other supported conditions.

Simple comparison

Easy way to remember: ALB understands HTTP requests. NLB primarily handles transport-level connections and flows.

6. How Does a Load Balancer Actually Work?

Both ALB and NLB use a few important components.

The most important are:

1. Load Balancer

2. Listener

3. Target Group

4. Registered Target

5. Health Check

Let's understand each one separately.

Load Balancer

The load balancer is the common entry point for clients.

Instead of connecting to individual EC2 instances, clients connect to the load balancer's endpoint.

For example:

https://example.com

The domain may resolve to an AWS load balancer endpoint.

The load balancer then forwards traffic to the appropriate backend targets.

Listener

A listener is a configuration that checks for incoming connections using a particular protocol and port.

For example:

• HTTPS listener on TCP port 443.

• HTTP listener on TCP port 80.

• TCP listener on port 9000.

• UDP listener on port 5000.

Think of a listener as a receiving desk that accepts a particular type of delivery.

Target Group

A target group is a logical collection of backend targets.

It contains information such as:

• Which targets belong to the group.

• Which protocol and port are used to reach them.

• How target health is evaluated.

• Relevant traffic-routing settings.

For example:

Target Group: website-targets

The load balancer forwards traffic to registered targets in the group according to its routing configuration.

Registered Target

A registered target is a backend resource that has been added to a target group.

Depending on the load balancer type, a target may be:

• An EC2 instance.

• An IP address.

• A Lambda function, for ALB.

• An Application Load Balancer, as a supported target of NLB.

A target must meet the relevant requirements before the load balancer can route traffic to it.

Health Check

A health check determines whether a registered target is considered ready to receive traffic.

For example, an ALB can periodically send an HTTP request to:

/health

If the application returns an accepted success response, the target can be considered healthy after the configured threshold is met.

If health checks repeatedly fail, the load balancer normally stops selecting that unhealthy target for new traffic when healthy alternatives remain.

We'll explore health checks in more detail shortly.

7. Understanding Listeners with a Practical Example

Let's imagine you run a Next.js application on two EC2 instances.

Both applications listen on port 3000.

But your website visitors should use HTTPS on port 443.

Your configuration could be:

Visitor → ALB Listener 443 → Target Group → EC2 Port 3000

How does this work?

Step 1: Visitor opens the website

The visitor opens:

https://example.com

The browser establishes an HTTPS connection to the ALB endpoint.

Step 2: HTTPS listener receives the request

The ALB has an HTTPS listener configured on port 443.

It handles the client-side TLS connection using an appropriate certificate.

Step 3: Listener rules determine the target group

Suppose the listener's default action is to forward requests to:

nextjs-targets

The ALB selects this target group.

Step 4: Target group selects an eligible server

The target group contains two healthy EC2 instances:

• 10.0.1.10:3000

• 10.0.2.10:3000

The ALB chooses a target according to its algorithm and configuration.

Step 5: The selected server processes the request

The Next.js application generates a response.

The response returns through the ALB to the client.

This is the basic request flow.

Does EC2 need to expose port 3000 publicly?

No.

The EC2 instances can remain private.

For example, their Security Groups may allow inbound TCP 3000 only from the ALB's Security Group.

Users connect to the ALB on HTTPS port 443.

The ALB connects to the targets on their configured backend port.

This separates public connectivity from private application communication.

8. How Target Groups Work

Let's go deeper into target groups.

Suppose your application has:

• Two website servers.

• Two API servers.

You could create two target groups.

Website target group

Name: website-targets

API target group

Name: api-targets

Now configure the ALB to handle two request types:

When a user requests a page, the ALB selects a website server.

When an HTTP request matches /api/*, the ALB selects an API server.

The target group organizes backend resources for a particular routing purpose.

Is a target group the same as a subnet?

No.

A subnet defines an IP address range and its network boundary.

A target group defines which backend resources a load balancer may send traffic to.

An EC2 instance belongs to a subnet, while also potentially being registered in one or more compatible target groups.

These are different relationships.

Can one ALB use multiple target groups?

Yes.

This is one of the most useful capabilities of ALB.

A single ALB can serve multiple application components using listener rules.

You don't necessarily need a separate load balancer for every HTTP microservice.

However, separate load balancers may still be appropriate when applications require different network isolation, security, ownership, or operational boundaries.

9. What Are Load Balancer Health Checks?

Suppose your application is running on three EC2 instances.

What happens if the load balancer sends a request to EC2 B?

The request might fail because the application is no longer available.

To reduce this problem, AWS load balancers periodically monitor their registered targets using health checks.

How an ALB health check works

Suppose the application exposes a lightweight HTTP endpoint:

GET /health

A healthy application returns an expected response, such as:

HTTP/1.1 200 OK
Content-Type: application/json

{"status":"ok"}

This is an illustrative response format, not a claim about any particular deployed application.

The ALB periodically requests the health-check endpoint.

If the target returns a configured acceptable response within the allowed time, the health check succeeds.

If checks repeatedly fail, the target becomes unhealthy.

Example

During normal operation, the ALB selects healthy targets.

It would ordinarily distribute new requests between EC2 A and EC2 C rather than EC2 B.

Why are health-check thresholds important?

A single failed request doesn't always mean a server is permanently unhealthy.

There may be a brief network interruption, temporary application load, or a short restart.

AWS health checks use configurable thresholds.

For example, a configuration might require:

• Two consecutive failed checks to mark a target unhealthy.

• Five consecutive successful checks to restore healthy status.

The exact values depend on the load balancer and target group configuration.

What is the difference between TCP and HTTP health checks?

A TCP health check tests whether a TCP connection can be established.

An HTTP health check makes an HTTP request and examines the response.

These verify different things.

For example, a TCP connection might succeed while the application returns HTTP 500 errors.

Therefore, a successful TCP check doesn't necessarily prove the application is functioning correctly.

For HTTP applications, an appropriate HTTP or HTTPS health check often provides a better indication of application readiness.

ALB supports HTTP and HTTPS health checks. NLB supports TCP, HTTP, and HTTPS health checks for its target groups.

Should /health test the database too?

That depends on what your health check is meant to measure.

A simple liveness check might confirm that the application process is running.

A deeper readiness check might confirm that the server can handle useful requests, including required dependencies.

If every server reports unhealthy because one shared dependency temporarily fails, the load balancer may have no healthy targets.

For beginners, the important lesson is to design health checks around the target's ability to serve traffic, rather than returning success unconditionally.

Does a load balancer completely stop traffic when all servers are unhealthy?

Not always.

This is an important AWS-specific detail.

Both ALB and NLB have documented fail-open behaviors in certain all-targets-unhealthy situations.

For example, when every registered target in an applicable ALB target group becomes unhealthy, ALB may still route requests to those unhealthy targets.

NLB also has fail-open behavior under documented failure conditions.

This means health checks improve traffic selection and resilience, but do not guarantee that an application stays available when every backend fails.

10. How Does ALB Distribute Requests?

Let's look at a basic example.

You have three healthy Next.js servers:

• EC2 A

• EC2 B

• EC2 C

Suppose six HTTP requests arrive.

With a simple round-robin distribution, the requests might be assigned as follows:

This table illustrates the round-robin idea.

It is not a guarantee of the exact sequence for a real AWS application, which may involve multiple load balancer nodes, health changes, connection behavior, and other routing settings.

Does equal request count mean equal server load?

No.

One request might return a simple JSON response.

Another request might generate a complex report or perform an expensive database query.

Both count as individual requests, but they require different amounts of processing.

That is why distribution policies and application performance monitoring still matter.

11. How Does NLB Distribute Connections?

A Network Load Balancer uses flow-based selection rather than ALB-style application request routing.

For example, imagine a client initiates a TCP connection to a custom service.

The NLB evaluates connection or flow information and selects a target using its flow hashing behavior.

Packets belonging to that flow are directed consistently to the selected target under the relevant routing conditions.

Suppose:

• Client A connects on TCP port 9000.

• Client B connects on TCP port 9000.

• Client C connects on TCP port 9000.

Each connection may be assigned to a different eligible backend.

But it is also possible for multiple connections to be assigned to the same target.

NLB does not promise one connection per server in a perfect rotation.

This distinction matters when comparing it with ALB.

ALB commonly makes routing decisions at the HTTP request level.

NLB primarily makes decisions at the network connection or flow level.

12. Internet-Facing vs Internal Load Balancers

Both ALB and NLB can be configured as internet-facing or internal load balancers.

Internet-facing load balancer

An internet-facing load balancer provides a publicly reachable endpoint when its network and security configuration permits access.

Common uses include:

• Public websites.

• Public APIs.

• Internet-facing TCP services.

For example:

Internet Users → Public ALB → Private EC2 Instances

The application instances don't need individual public IPv4 addresses simply to receive traffic forwarded by the ALB.

Internal load balancer

An internal load balancer is designed for connectivity from private networks that have an appropriate route.

It is not intended to be directly accessible from arbitrary public internet clients.

For example:

Frontend Application → Internal ALB → Private Backend APIs

An internal load balancer can provide one endpoint for several backend services while keeping the service entry point private.

Does the ALB need to be in the same subnet as EC2?

No.

An ALB can be placed in separate subnets from its target instances.

A common design is:

• Internet-facing ALB in public subnets.

• EC2 application servers in private subnets.

• Database resources in private or isolated subnets.

The load balancer communicates with targets over appropriate VPC network paths, subject to the required security permissions.

13. Understanding Availability Zones and High Availability

A load balancer is especially useful when application servers run across multiple AWS Availability Zones.

An Availability Zone is an isolated location within an AWS Region.

Suppose you deploy an application across two Availability Zones.

Availability Zone A

• Private subnet: 10.0.1.0/24

• EC2 A: 10.0.1.10

Availability Zone B

• Private subnet: 10.0.2.0/24

• EC2 B: 10.0.2.10

An internet-facing ALB has nodes in its enabled Availability Zones and can route traffic to healthy registered targets.

If EC2 A fails, the ALB can normally continue routing traffic to EC2 B, provided the configuration and remaining capacity support it.

This improves fault tolerance compared with relying entirely on one EC2 instance.

What is cross-zone load balancing?

Cross-zone load balancing allows a load balancer node in one enabled Availability Zone to distribute traffic to registered targets in other enabled zones.

ALB has cross-zone load balancing enabled at the load balancer level.

NLB normally starts with cross-zone load balancing disabled, although it can be enabled.

For example:

• With cross-zone routing enabled, a load balancer node in AZ-A can forward traffic to healthy targets in AZ-B.

• Without cross-zone routing, an NLB node ordinarily sends traffic only to targets in its own enabled zone.

There are additional target group and billing considerations for cross-zone behavior.

The most important beginner lesson is that load balancing across Availability Zones helps provide redundancy, but the application also needs enough healthy capacity to handle failures.

Does a load balancer guarantee zero downtime?

No.

A load balancer improves availability, but it cannot compensate for every failure.

For example, if all backend servers are down, the application may still be unavailable.

Similarly, failures involving a shared database, incorrect deployment, invalid certificates, or broken application dependencies can affect every server.

High availability requires a complete architecture, not just a load balancer.

14. ALB vs NLB: Why Static IP Addresses Matter

One important reason for choosing NLB is its support for static IP addresses.

Application Load Balancer addressing

ALB provides an AWS-managed DNS name.

AWS can change the underlying IP addresses associated with that endpoint as the load balancer scales and operates.

You normally point your application domain to the ALB using an appropriate DNS record or Route 53 alias.

You should not treat ALB's currently resolved public IP addresses as permanently fixed.

Network Load Balancer addressing

NLB provides a static IP address for each enabled Availability Zone.

For an internet-facing NLB, you can associate suitable Elastic IP addresses with its zonal interfaces.

This can be useful when customers or partner systems require a stable list of public IPv4 addresses for firewall allowlisting.

Example: A partner integration

Suppose an external business partner only permits connections to specific public IP addresses.

Your service needs a stable public endpoint.

An internet-facing NLB with appropriately configured static IP addresses may be suitable.

But if you also need HTTP path-based routing, an ALB is better suited for that application-layer requirement.

AWS also supports using an ALB as a target behind an NLB, allowing some architectures to combine NLB static IP capabilities with ALB application routing.

That is a more advanced design and adds operational complexity and cost.

For most beginner web applications, start by understanding ALB's managed DNS endpoint before considering these additional requirements.

15. Understanding HTTPS and TLS Termination

When users open a secure website, they typically connect using HTTPS.

HTTPS uses TLS to encrypt communication.

A load balancer can help manage this encryption.

HTTPS with an Application Load Balancer

Suppose the user opens:

https://example.com

The connection reaches an ALB HTTPS listener on port 443.

The ALB uses a configured TLS certificate to establish the secure client connection.

After that, it forwards the request to a backend target group.

For example:

Browser → HTTPS 443 → ALB → HTTP 3000 → Next.js

This is called TLS termination at the load balancer.

The ALB handles the client-side TLS connection.

Does traffic between ALB and EC2 stay encrypted automatically?

Not necessarily.

In the example above, the ALB connects to EC2 using HTTP.

If you need encryption between the ALB and its targets, you can configure a suitable HTTPS backend target group.

That creates an additional encrypted connection from the ALB to the targets.

The appropriate configuration depends on your security requirements.

What about TLS with NLB?

NLB can use a TLS listener to terminate TLS connections.

It can also use a TCP listener to pass encrypted TLS traffic through to the backend, allowing the application server to handle decryption.

This is useful for services that need application-managed TLS or transport-level behavior.

However, the exact protocol combinations must comply with AWS's supported listener and target group configurations.

16. Security Groups and Load Balancers

Load balancers are part of your network, so Security Groups and other network controls remain important.

Consider this simplified architecture:

Internet → ALB → Private EC2 Instances

You might have two Security Groups.

ALB Security Group

Inbound:

This permits public IPv4 HTTPS connections, assuming the endpoint and routes are configured appropriately.

Its outbound rules must allow required communication with backend targets, including health checks.

EC2 Security Group

Inbound:

The application instances accept TCP connections on port 3000 from the ALB's Security Group.

They don't need to allow TCP 3000 from the entire internet.

This is a useful approach for reducing direct application exposure.

Does NLB support Security Groups?

Yes.

Current AWS Network Load Balancers support Security Groups, subject to relevant configuration restrictions.

This is worth emphasizing because older tutorials sometimes say NLB does not support Security Groups.

Certain features, including specific QUIC listener configurations, have their own restrictions.

Security design should also account for backend Security Groups, Network ACLs, and applicable client IP preservation settings.

For a deeper explanation of AWS network security, see AWS Security Groups vs Network ACLs Explained.

17. What Is Session Stickiness?

Let's imagine a user signs into a website.

The user's first request is sent to EC2 A.

The next request is sent to EC2 B.

If the application stores important login session information only in EC2 A's memory, EC2 B may not have that information.

This can cause problems such as users unexpectedly losing their sessions.

One possible solution is session stickiness, also called session affinity.

With ALB, sticky sessions can be configured to prefer the same target for subsequent requests from a client during a defined period.

For ordinary HTTP applications, ALB commonly uses cookies to implement this behavior.

Does every application need sticky sessions?

No.

For many modern applications, it is preferable to avoid storing essential session state only in one server's memory.

Instead, applications can use:

• A shared database.

• A shared session store such as Redis.

• Other suitable centralized or distributed session mechanisms.

This allows multiple servers to process requests without requiring every request from one user to reach the same instance.

Stickiness may still be useful for specific workloads, but it introduces trade-offs, including potentially uneven traffic distribution and stronger dependence on an individual target.

For scalable applications, shared state and stateless application design are often preferable to relying entirely on sticky sessions.

18. How Do Load Balancers Work with Auto Scaling?

A load balancer distributes traffic.

Auto Scaling adjusts the number of EC2 instances according to configured scaling policies and capacity requirements.

These features work together, but they solve different problems.

Load balancer

Decides where incoming traffic should be sent among eligible targets.

Auto Scaling

Can launch or terminate EC2 instances based on configured capacity settings, metrics, and scaling policies.

Example

Suppose your application initially runs on two EC2 instances.

Your traffic increases.

An EC2 Auto Scaling group may launch additional instances if its scaling policy determines that more capacity is needed.

Those instances can be registered with the load balancer's target group.

After they become healthy, the load balancer can include them in traffic distribution.

Later, when traffic decreases, Auto Scaling may reduce capacity.

The load balancer then stops routing new traffic to targets being deregistered as part of the capacity reduction process, subject to connection draining behavior.

Load balancing and Auto Scaling complement each other, but creating a load balancer does not automatically configure Auto Scaling.

19. ALB vs NLB: Complete Comparison

Now let's compare the two load balancers in one table.

Which should you choose?

Choose ALB when:

• Your application uses HTTP or HTTPS.

• You need routing based on URL paths or hostnames.

• You have multiple web or API services.

• You want application-aware traffic handling.

• You want to integrate HTTP-oriented features such as AWS WAF or supported authentication actions.

Choose NLB when:

• Your workload uses TCP, UDP, or another supported transport protocol.

• You need stable public IP addresses per enabled Availability Zone.

• Your application requires transport-level connection handling.

• You need specific network characteristics that ALB doesn't provide.

• You don't require ALB-style HTTP content routing.

NLB isn't automatically better for every high-traffic website. And ALB isn't automatically better for every TCP-based system.

The best choice depends on the application's actual requirements.

20. How Much Do AWS Load Balancers Cost?

AWS charges for load balancer usage, and pricing varies by type, Region, and usage.

For ALB, pricing commonly includes:

• Load balancer running time.

• Load Balancer Capacity Unit (LCU) usage or applicable capacity reservations.

• Other billable services and data transfer where relevant.

For NLB, pricing commonly includes:

• Load balancer running time.

• Network Load Balancer Capacity Unit (NLCU) usage or applicable capacity reservations.

• Additional applicable networking charges.

Other possible costs include public IPv4 addresses, data transfer, EC2 instances, and related infrastructure.

Does a load balancer cost money when there is no traffic?

Yes, a provisioned load balancer can incur time-based charges even if it receives little or no traffic.

This is why creating an ALB or NLB solely for a short experiment may still result in a bill.

A small application running on one EC2 instance does not always need a managed load balancer immediately.

For example, a personal website with limited traffic may operate acceptably using a single EC2 instance and Nginx, depending on its uptime and scaling requirements.

A load balancer becomes more valuable when you need multiple targets, advanced routing, improved fault tolerance, or other managed networking features.

Always review current pricing before choosing an architecture.

See the official AWS Elastic Load Balancing pricing.

21. Common AWS Load Balancer Problems

Let's look at several situations that beginners often encounter.

Problem 1: ALB returns HTTP 503

A 503 response can occur when the ALB has no usable registered targets for the selected routing action, among other causes.

Check whether the target group has registered targets and whether they are available and properly configured.

Problem 2: ALB returns HTTP 502

A 502 response indicates that the ALB encountered a problem communicating with or processing a response from the target, depending on the specific failure.

Possible causes include malformed backend responses, certain connection failures, or TLS-related problems.

Do not assume every 502 means that the backend process has stopped.

Problem 3: Targets always appear unhealthy

Possible reasons include:

• Incorrect health-check path.

• Wrong backend port.

• Application not running.

• Unexpected HTTP status code.

• Application listening only on localhost.

• Security Group or Network ACL restrictions.

• Health check timeout.

For example, if the ALB checks /health but your application returns HTTP 404, the health check may fail because the returned status doesn't match the configured success criteria.

Problem 4: The domain works sometimes but not consistently

One possibility is that some backend instances are healthy at the network level but behave differently from others.

Examples include inconsistent application versions, missing environment variables, or session information stored locally.

Load balancing cannot automatically make inconsistent application instances behave identically.

Problem 5: Requests don't appear evenly distributed

This may be expected.

Reasons include:

• Different routing algorithms.

• Sticky sessions.

• Uneven connection duration.

• NLB flow-based target selection.

• Different numbers of healthy targets.

• Cross-zone configuration.

• Varying traffic patterns.

Perfectly equal request counts are not always the goal.

Problem 6: HTTPS works at the ALB but fails between ALB and EC2

A possible reason is a mismatch between the target group protocol and what the backend application actually supports.

For example, configuring HTTPS to a backend that only serves plain HTTP on that port can cause a failure.

Client-to-ALB encryption and ALB-to-target encryption are separate connections when TLS is terminated at the ALB.

A useful troubleshooting checklist

When a load-balanced application doesn't work, examine the connection in this order:

1. DNS: Does the domain resolve to the intended load balancer?

2. Listener: Is the correct protocol and port configured?

3. Routing rule: Does the request match the intended listener rule?

4. Target group: Does the group contain the correct registered targets?

5. Health: Are the targets healthy, and what do the health-check reason codes show?

6. Network security: Do Security Groups and Network ACLs permit the required traffic?

7. Application: Is the service running and listening on the expected port?

8. Observability: Do CloudWatch metrics, access logs, and target application logs reveal the cause?

This structured approach is more effective than randomly changing firewall permissions.

22. Frequently Asked Questions

What is the difference between ELB and ALB?

ELB is the broader AWS service that provides load balancing.

ALB is one specific load balancer type designed for HTTP and HTTPS application traffic.

Is ALB better than NLB?

Neither is universally better.

ALB is usually the more appropriate starting point for websites and HTTP APIs requiring application-level routing.

NLB is useful for supported transport-layer workloads, static IP requirements, and certain high-performance networking scenarios.

Can ALB forward traffic to private EC2 instances?

Yes.

This is a common architecture.

An internet-facing ALB can accept public traffic while forwarding requests to targets in private subnets, provided connectivity and security rules are configured correctly.

Can ALB serve multiple applications?

Yes.

ALB can use host-based and path-based listener rules to direct requests to different target groups.

For example, one ALB can route website requests to Next.js servers and API requests to Node.js servers.

Does ALB require multiple Availability Zones?

For a standard regional Application Load Balancer using Availability Zone subnets, AWS requires at least two subnets in different Availability Zones. Some specialized deployment types have different requirements.

Can NLB have a static IP?

Yes.

NLB supports static IP addresses per enabled Availability Zone.

Internet-facing NLBs can use Elastic IP addresses, subject to the supported addressing configuration.

Do load balancers automatically create more EC2 instances?

No.

A load balancer distributes traffic to registered targets.

Amazon EC2 Auto Scaling is a separate service that can adjust instance capacity and integrate with load balancer target groups.

Can I use ALB without Auto Scaling?

Yes.

You can register existing EC2 instances in target groups without configuring Auto Scaling.

Can I use one EC2 instance behind an ALB?

Yes.

However, having a load balancer in front of one EC2 instance doesn't create backend redundancy.

If that one instance fails, there may be no healthy alternative.

Does a health check guarantee the application is fully working?

No.

A health check verifies only the conditions it is configured to test.

An application might successfully respond to /health while another feature, such as payment processing or database access, is failing.

Can ALB replace Nginx?

For some architectures, ALB can replace parts of what an Nginx reverse proxy does, particularly TLS termination and HTTP request forwarding.

However, Nginx also supports web-server features and application-specific proxy configuration that may not have direct ALB equivalents.

The decision depends on the application's requirements.

Does a load balancer prevent all downtime?

No.

It can improve fault tolerance and reduce the impact of certain failures, but application availability also depends on healthy backend capacity, databases, dependencies, networking, and correct configuration.

Conclusion

AWS load balancers help applications handle incoming traffic through a common endpoint while distributing requests or connections across backend resources.

The key beginner concepts are:

Elastic Load Balancing (ELB) is the AWS service that provides managed load balancing.

Application Load Balancer (ALB) is designed for HTTP and HTTPS workloads and supports request-aware routing based on paths, hostnames, and other HTTP properties.

Network Load Balancer (NLB) is designed for transport-layer connectivity, including TCP and UDP workloads, and provides useful capabilities such as static IP addresses.

Listeners receive connections using configured protocols and ports.

Target Groups organize the backend resources that may receive traffic.

Health Checks help AWS identify targets that can handle new traffic.

Availability Zones allow an application to distribute infrastructure across separate failure domains.

Auto Scaling can adjust backend capacity, while the load balancer distributes traffic among eligible targets.

The most important lesson is that a load balancer does not simply send traffic randomly to servers. It follows configured listeners, routing rules, target groups, target-selection behavior, and health information.

Once those pieces make sense, it becomes easier to understand how modern AWS applications achieve horizontal scaling and improved availability.

References

• Elastic Load Balancing - AWS Documentation

• What Is an Application Load Balancer? - AWS

• Application Load Balancer Concepts and Configuration - AWS

• What Is a Network Load Balancer? - AWS

• How Elastic Load Balancing Works - AWS

• Application Load Balancer Health Checks - AWS

• Network Load Balancer Health Checks - AWS

• Network Load Balancer Listeners - AWS

• Elastic Load Balancing Pricing - AWS