Choose a Load Balancer
Use this page to decide how to configure a Load Balancer before you create one in the MyAccount portal. It explains what a Load Balancer does, the difference between the two types (ALB and NLB), the scheme and routing choices you make during creation, and how plans are sized.
A Load Balancer is a managed appliance that acts as a single point of contact for your application and distributes incoming traffic across a group of backend nodes. It checks connection requests on the protocol and port you configure for the front end (client to load balancer) and forwards them to healthy backend nodes on the protocol and port you configure for the back end (load balancer to nodes). If a node goes down, traffic is routed to the remaining healthy nodes; when you add a node, it starts receiving traffic.
You need an E2E MyAccount before you begin. If you do not have one, sign in or create an account from the E2E MyAccount portal.
Why Use a Load Balancer
- High availability — traffic is spread across multiple backend nodes, so the failure of one server does not take the application down.
- Scalability — add or remove backend nodes, or attach an auto scaling group, to handle changing demand without interrupting requests.
- Fault tolerance — health checks remove unhealthy nodes from rotation automatically and return them when they recover.
- Flexible traffic control — choose the front-end and back-end protocols and ports, the routing policy, and the timeout behavior that fit your workload.
- Proactive monitoring — real-time metrics, health stats, and email alerts surface problems early. See Monitoring and Alerts.
Application Load Balancer vs Network Load Balancer
After you select a plan, you choose the Load Balancer type. The two types differ in the network layer they operate at and the features they expose.
| Aspect | Application Load Balancer (ALB) | Network Load Balancer (NLB) |
|---|---|---|
| Layer | Layer 7 (application) | Layer 4 (transport) |
| Traffic | HTTP and HTTPS | TCP |
| Front-end protocol | HTTP, HTTPS, or Both | TCP (set by a listening port) |
| Routing rules (ACL) | Yes — host, path, query, method, and source IP | No |
| Backend protocol choice | HTTP or HTTPS | Not applicable (TCP) |
| HTTP health checks | Yes | Not applicable |
| Auto scaling group backends | Yes | No (node backends only) |
| Listening port | Set by protocol | Required: 80, 443, or 1024–65535 |
| Best for | Web applications that route on request content | High-throughput TCP services and non-HTTP protocols |
Choose an ALB when you need application-aware routing — for example, sending /api to one backend group and /static to another, routing by hostname, or terminating HTTPS at the load balancer. See Create an Application Load Balancer.
Choose an NLB when you need to forward raw TCP connections with low overhead and do not need content-based routing. See Create a Network Load Balancer.
Scheme: Internal or External
When you create a Load Balancer, you choose its scheme:
- External (with public IP) — distributes traffic that arrives from the internet to your backend nodes. Use this for public-facing applications.
- Internal (without public IP) — distributes traffic within your private VPC networks, with no public exposure. An internal Load Balancer must be attached to at least one VPC.
An internal Load Balancer requires a VPC. If you choose the internal scheme, select or create a VPC during creation. An external Load Balancer can optionally use a reserved IP as its public IP.
Routing Policy
The routing policy (balancing algorithm) decides how the Load Balancer spreads requests across the backends in a group:
- Round Robin — distributes requests evenly across backend servers in turn.
- Source IP Hash — routes based on a hash of the client's source IP so a given client keeps reaching the same backend (useful for session affinity).
- Least Connection — sends each request to the backend with the fewest active connections. This works well for long-lived connections and is the default for NLB.
You set the routing policy per backend group during creation and can change it later from the Backend Mapping tab.
Health Checks
For an ALB, the Load Balancer checks the health of each backend node against a URL path you define. If the node responds with a 2xx or 3xx HTTP status code, it is marked UP; otherwise it is marked DOWN and removed from rotation until it recovers.
- Enable Add HTTP Health Checks on the backend group to turn on HTTP monitoring.
- The default health-check path is
/. Change it to any URI your application uses to report health.
Plans
Load Balancer plans are listed by vCPU, RAM, storage, maximum concurrent connections, and price. Larger plans support more concurrent connections and higher throughput; the entry plan suits light workloads, while the larger plans suit high-traffic production services.
Plan names, capacity, and pricing can change. Use the live plan list in the portal during creation, or the Plans & Pricing API, as the source of truth for currently available plans and current prices. Do not rely on static documentation for prices.
You can launch a Load Balancer on an hourly plan and convert it to a discounted committed plan later. See Committed Load Balancer.
Before You Create
Decide the following before you launch, so the create flow goes smoothly:
| Decision | Where it is used |
|---|---|
| ALB or NLB | Type selection, immediately after the plan |
| Internal or external scheme | Details step |
| Front-end protocol (ALB) or listening port (NLB) | Details / Target Mapping |
| Backend nodes (name, private IP, port) or auto scaling group | Target Mapping |
| Routing policy and health-check path | Target Mapping |
| HTTPS — imported SSL certificate | SSL Certificates |
| Encryption at rest (creation-time only) | Load Balancer Encryption |
| VPC and reserved IP | Peak Performance Features |
| Security group rules | Security Group step |
Related Resources
| Resource | Use it for |
|---|---|
| Create an Application Load Balancer | Launch a Layer 7 ALB. |
| Create a Network Load Balancer | Launch a Layer 4 TCP NLB. |
| Manage Load Balancers | Operate, edit, monitor, and delete an existing Load Balancer. |
| SSL Certificates | Serve HTTPS from the Load Balancer. |
| Load Balancer Encryption | Encrypt the Load Balancer at rest. |
| VPC | Private networking for internal Load Balancers. |
| Reserved IP | Use a stable public IP. |
| Auto Scaling | Attach a dynamic scale group as a backend. |
| Load Balancer API | Automate creation and management. |