Introduction

On AWS, enabling HTTPS on a load balancer usually means attaching a TLS certificate to an HTTPS or TLS listener and deciding where TLS should terminate. In modern AWS setups, the most common choices are an Application Load Balancer for HTTP and HTTPS traffic or a Network Load Balancer for lower-level TCP or TLS traffic. Classic Load Balancer still exists in older environments, but it is legacy context rather than the normal starting point.

Start with AWS Certificate Manager

The easiest certificate path on AWS is usually AWS Certificate Manager, or ACM. It can issue and manage public certificates for supported AWS services.

A typical flow is:

1. request or import a certificate in ACM
2. create an HTTPS listener on the load balancer
3. attach the certificate to that listener
4. optionally redirect HTTP to HTTPS

Using ACM removes the need to manage certificate files manually on your instances in many common architectures.

TLS termination on an Application Load Balancer

For most web applications, an ALB is the normal answer. It can terminate HTTPS at the load balancer and then forward traffic to targets over HTTP or HTTPS depending on your architecture.

The common pattern is:

• client connects with HTTPS to the ALB
• ALB presents the ACM certificate
• ALB decrypts the traffic
• ALB forwards traffic to the target group

That gives you centralized certificate management and simple HTTP routing features such as host-based and path-based routing.

Redirect HTTP to HTTPS

A common best practice is to keep port 80 only for redirects and force real traffic onto HTTPS.

In AWS terms, that usually means:

• listener on port 80 for HTTP
• listener on port 443 for HTTPS
• redirect rule on port 80 that sends clients to HTTPS

This ensures users who type a plain HTTP URL are moved to the secure endpoint automatically.

When a Network Load Balancer makes sense

A Network Load Balancer operates at a lower level and is useful when you need TCP or TLS handling with different performance and architecture characteristics. It can be appropriate when you need to preserve source IPs, handle non-HTTP protocols, or work at Layer 4.

The choice between ALB and NLB is not mainly about whether you want SSL. It is about protocol behavior and routing needs.

A rough rule:

• choose ALB for normal web applications and HTTP-aware routing
• choose NLB for low-level TCP or TLS use cases

Decide where encryption ends

You also need to choose whether TLS ends at the load balancer or continues to the target.

Common options are:

• terminate TLS at the load balancer and send HTTP to the application
• terminate TLS at the load balancer and re-encrypt HTTPS to the target
• pass through lower-level traffic depending on the load balancer type and architecture

The right choice depends on your security requirements, internal network trust model, and application behavior.

Common Pitfalls

The biggest pitfall is using old ELB terminology loosely and not distinguishing ALB, NLB, and Classic Load Balancer. They do not all behave the same way.

Another issue is forgetting the certificate's region and service compatibility. ACM certificates must be available in the right AWS context for the load balancer you are configuring.

It is also easy to enable HTTPS on port 443 but forget to redirect port 80, leaving part of the user traffic on plain HTTP.

Finally, do not treat TLS termination as the only security step. Security groups, target-group health checks, backend encryption choices, and certificate renewal practices still matter.

Summary

• On AWS, HTTPS on a load balancer usually means attaching an ACM certificate to an HTTPS or TLS listener.
• ALB is the common choice for HTTP and HTTPS web applications.
• NLB is more appropriate for lower-level TCP or TLS scenarios.
• Decide explicitly where TLS terminates and whether traffic is re-encrypted to the backend.
• Redirect HTTP to HTTPS so users consistently reach the secure endpoint.