AWS Load Balancer Guide: ALB, NLB and When Your Backend Needs One

An AWS load balancer is the public front door for most production backends on AWS: clients connect to it, and it forwards requests to healthy containers or instances behind it. Elastic Load Balancing offers several types, and for HTTP APIs the usual choice is an Application Load Balancer (ALB).

Building one by hand means listeners, target groups, security groups, certificates and health checks before the first service is reachable. This guide covers ALB vs NLB vs Classic, the pieces that matter for backends, and how Encore (infrastructure from code) provisions an ALB when you deploy to your own AWS account.

AWS load balancers at a glance

The Application Load Balancer guide and the Network Load Balancer guide are the source of truth for each type.

ALB vs NLB vs Classic

An ALB evaluates listener rules and can send /api/users/* to one target group and /api/orders/* to another, terminate TLS with a certificate from ACM, redirect HTTP to HTTPS, and register IP targets such as Fargate tasks. ALB is the usual fit for browser and mobile APIs that need path routing and HTTPS termination.

An NLB preserves the connection model: it selects a target with a flow hash and keeps that connection on one target for its lifetime. It scales to very high connection rates, can use a static IP or Elastic IP per subnet, and suits TCP services, gRPC over HTTP/2 when you terminate elsewhere, or cases where clients must pin an IP. It does not offer ALB-style path conditions.

Classic Load Balancers predate ALB and NLB. New backends should pick ALB for HTTP and NLB for raw TCP or UDP rather than Classic.

Listeners, target groups and path routing

A listener is a port and protocol on the load balancer, usually 80 and 443. Each listener has a default action and optional rules. On an ALB, rules match host, path, HTTP method, headers, query string or source IP, and forward to a target group, redirect or return a fixed response, as described in the listener documentation.

A target group is the set of destinations for a rule: instance IDs, IP addresses (including Fargate tasks in awsvpc mode) or, on ALB, Lambda functions. Health checks are defined per target group, so one unhealthy service does not take others offline. ECS and EKS register and deregister tasks as they start and stop, which is how rolling deploys stay available.

Path-based routing lets several services share one ALB and one certificate. Host-based routing does the same for several domains. Both avoid one load balancer per microservice.

TLS and health checks

TLS usually terminates on the ALB with a certificate from AWS Certificate Manager. The listener on 443 presents the certificate; traffic from the ALB to targets can stay HTTP inside the VPC or use HTTPS if you want encryption to the container. Redirecting 80 to 443 is a listener rule.

Health checks probe a path and port on each target. Failed checks remove the target from rotation until it recovers. Grace periods matter on cold starts: a check that fires before the process is ready marks a healthy deploy as unhealthy. Access logs and CloudWatch metrics on the target group show request counts, latency and unhealthy hosts.

How Encore provisions the load balancer

Encore combines an open source infrastructure SDK for TypeScript and Go with a platform that provisions and deploys into your own AWS or GCP account. On AWS, each environment gets an Application Load Balancer in the public subnet as the entry point for inbound traffic. Compute runs in private subnets and accepts inbound traffic only from that ALB, as documented in the AWS infrastructure docs.

With Fargate, each service is attached to ALB target groups with health checks and a health-check grace period so new tasks can start before traffic arrives. Deploys use a rolling update: new tasks are introduced gradually while old ones are removed, and the load balancer routes only to healthy targets. With EKS, Encore installs the AWS Load Balancer Controller, manages ALB ingress and target groups, and provisions TLS certificates through ACM for external traffic.

Public APIs are the endpoints you mark as exposed. Everything else stays private to the service mesh inside the environment. For a branded URL, add a CNAME to custom-domain.encr.app and register the domain in the dashboard; Encore issues certificates and serves HTTPS on that name, as described in custom domains. The default encr.app subdomain keeps working during the cutover.

Set up the app

A public endpoint is ordinary TypeScript. The ALB, target group and TLS sit outside the source:

// checkout/encore.service.ts
import { Service } from "encore.dev/service";
export default new Service("checkout");

// checkout/cart.ts
import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("checkout", { migrations: "./migrations" });

// expose: true makes this reachable through the environment's ALB / HTTPS URL.
export const getCart = api(
  { expose: true, method: "GET", path: "/cart/:id" },
  async ({ id }: { id: string }): Promise<{ id: string; items: number }> => {
    const row = await db.queryRow<{ items: number }>`
      SELECT items FROM carts WHERE id = ${id}`;
    return { id, items: row?.items ?? 0 };
  },
);

-- checkout/migrations/1_create_carts.up.sql
CREATE TABLE carts (
  id TEXT PRIMARY KEY,
  items INTEGER NOT NULL DEFAULT 0
);

encore run starts the API and a local Postgres. On deploy to AWS, Encore creates the VPC, ALB, target groups and RDS instance, and injects credentials at runtime. Connect the account once with the own-cloud guide. Resource settings are edited per environment under infrastructure configuration.

An AI coding agent adding a second public route updates the same service file, and the load balancer that already fronts the environment serves the new path.

Best fit: Teams who want HTTPS and routing for backends in their own AWS account, defined by the endpoints they expose.

Good to know

• Prefer ALB for HTTP APIs; reach for NLB when you need static IPs, extreme connection rates or non-HTTP protocols.
• Put health checks on a cheap path that does not hit the database on every probe.
• Plan connection counts: each healthy target holds its own pool to RDS or Redis.

Related guides

• What is an AWS VPC
• ECS vs EC2
• What is Amazon ECS
• How to deploy to AWS in 2026
• Deploy a TypeScript backend to AWS