Create an Application Load Balancer
Use this guide to create an Application Load Balancer (ALB) from the MyAccount portal. An ALB works at Layer 7 and routes HTTP and HTTPS traffic to backend groups, with support for content-based routing rules, HTTP health checks, and auto scaling group backends.
If you are still deciding between an ALB and a Network Load Balancer, see Choose a Load Balancer. For TCP workloads, see Create a Network Load Balancer.
You can also create and manage Load Balancers through the MyAccount API. See API & Automation.
Before You Begin
Make sure you can sign in to MyAccount and that your account has enough billing access or infra credits to launch the selected plan. Decide your scheme (internal or external), front-end protocol, and which backend nodes or auto scaling group will receive traffic. If you plan to serve HTTPS, import the SSL certificate first — see SSL Certificates.
Load Balancers are billable resources. Review the Summary before you deploy.
Step 1: Open the Create Flow and Select a Plan
- Log in to MyAccount.
- In the left navigation, go to Compute > Load Balancer.
- Access the Create Load Balancer page.
- The plans are listed by vCPU, RAM, storage, maximum concurrent connections, and price.
Plan capacity and price can change. Use the live plan list in the portal as the source of truth. See Choose a Load Balancer.
Step 2: Choose the Type
After selecting a plan, choose Application Load Balancer (ALB). The ALB operates at Layer 7, supports HTTP and HTTPS, and enables application-level routing based on request attributes such as headers and paths.
Step 3: Enter Details
| Field | What to enter |
|---|---|
| Name | A default name is provided from the selected plan; you can change it. Use letters, digits, hyphen, or underscore. |
| Scheme | External (with public IP) for internet-facing traffic, or Internal (without public IP) for private VPC traffic. |
| Frontend Protocol | HTTP, HTTPS, or Both (HTTP and HTTPS) — the protocol clients use to reach the load balancer. |
Frontend Protocol
The front-end protocol checks for connection requests using the protocol and port you set for client-to-load-balancer connections:
- HTTP — plain HTTP. Supports
X-Forwardedheaders. - HTTPS — secure HTTP using SSL/TLS. Requires an SSL certificate on the load balancer and supports
X-Forwardedheaders. - Both — accepts HTTP and HTTPS.
When you choose HTTPS or Both, select an imported SSL certificate from the dropdown. If your certificate is not listed, import it first from the Certificate Manager — see SSL Certificates.
HTTP Redirect
When the front-end protocol is HTTPS or Both, you can enable Redirect HTTP to HTTPS. Enable this for web user safety, accessibility, or PCI compliance so that plain HTTP requests are upgraded to HTTPS.
Step 4: Configure Target Mapping
Target Mapping defines the backend groups that receive traffic. Add one or more backend groups with Add More Backend.
Backend Group — a logical set of backend servers that receive traffic from the load balancer. It defines the destination pool for requests and applies health checks and the routing policy. Give each group a unique name.
Backend Protocol — how the load balancer talks to the backends: HTTP or HTTPS. For HTTPS backends, the certificate can be self-signed or issued by an internal CA, enabling TLS termination or end-to-end encryption.
Health Check — enable Add HTTP Health Checks to monitor backend health. The load balancer sends requests to a URL path and marks a node UP on a 2xx or 3xx response, otherwise DOWN.
The default health-check path is
/. Change it to any URI your application uses to report health.
Routing Policy — choose how requests are distributed:
- Round Robin — even distribution across backends.
- Source IP Hash — keeps a client on the same backend (the ALB default).
- Least Connection — sends traffic to the backend with the fewest active connections.
Backend Type — choose Node or Auto Scale Group.
Node Backends
Registering an E2E node adds it to the load balancer, which then routes requests only to healthy registered nodes.
- Select Node as the backend type.
- Click Add Server and enter each server's name, IP (preferably the private IP if the node is on E2E Cloud), and port.
- After adding servers, open the dropdown to review the backend server list.
You can also set a WebSocket Timeout (1–100 seconds) for the backend group.
Auto Scale Group Backends
Registering an auto scaling group lets the load balancer distribute traffic across nodes that scale up or down automatically based on your policy.
- Select Auto Scale Group as the backend type.
- Select an application scaling group from the dropdown to register behind the load balancer.
- Enter the Scaler Port used to send and receive traffic through the load balancer.
- To create a new group, select Add New to open the Auto Scaling flow.
Step 5: Peak Performance Features
VPC — enable this to attach a VPC so the load balancer can reach backends over private networking. There are two VPC types: a Default VPC with a pre-defined CIDR provided by E2E, and a Custom VPC you create (where you can optionally select an associated subnet). A VPC is required for the internal scheme.
Reserved IP — enable this to use a reserved IP as the default public IP for the load balancer. A reserved IP lets you re-point traffic to different backend resources without downtime.
Step 6: BitNinja
BitNinja is a server security tool that defends against cyberattacks. Each protected load balancer learns from every attack and applies that knowledge across all BitNinja-enabled servers and load balancers.
Enable BitNinja to protect the load balancer. It is easy to install, needs minimal maintenance, and provides immediate protection.
Step 7: Timeouts
Configure timeout values to suit your traffic: connection timeout, client timeout, server timeout, and HTTP keep-alive timeout. Each accepts a value in milliseconds within the range the portal allows.
Step 8: Encryption
Enabling encryption protects the load balancer's data at rest, including SSL/TLS certificates and configuration. Encryption can only be enabled during creation — select Enable Encryption and, optionally, set a passphrase.
For how encryption works and the passphrase rules, see Load Balancer Encryption.
Encryption cannot be enabled or disabled after the load balancer is created. Decide before you deploy.
Step 9: Security Group
A security group acts as a virtual firewall for the load balancer, controlling inbound and outbound traffic. A default security group is selected automatically, but you can create a new one or select an existing one during creation.
- Inbound rules decide what traffic can reach the load balancer (for example, HTTP/HTTPS from specific networks or the public internet).
- Outbound rules control what traffic the load balancer can send out.
To create a security group during the flow:
- Select the + icon to create a new security group.
- Enter a name (description optional). Optionally set it as the default for future load balancers.
- Define the inbound and outbound rules you need, then select Create.
The new group appears in the security group dropdown for selection. See Security Groups for full rule details.
Avoid allow-all rules. Restrict inbound access to the ports and source ranges your application needs.
Step 10: Review the Summary and Deploy
In the Summary, verify the plan, type, details, target mapping, and peak performance features. When everything is correct, select Submit.
Setup takes a few minutes. The load balancer first appears as Creating (about 5–6 minutes), may pass through Deploying (about 2–3 minutes), and reaches Running once provisioning completes. You are redirected to the Load Balancers page.
After the load balancer is running, manage it from the Load Balancer details tabs — see Manage Load Balancers.
Related Resources
| Resource | Use it for |
|---|---|
| Choose a Load Balancer | Compare ALB and NLB and plan settings. |
| Create a Network Load Balancer | Launch a Layer 4 TCP NLB instead. |
| Manage Load Balancers | Edit backends, ACLs, network, monitoring, and actions. |
| SSL Certificates | Import and attach an SSL certificate for HTTPS. |
| Load Balancer Encryption | Encrypt the load balancer at rest. |
| VPC | Private networking. |
| Reserved IP | Stable public IP. |
| Auto Scaling | Dynamic scale group backends. |
| BitNinja | Load balancer protection. |