> For the complete documentation index, see [llms.txt](https://docs.cloud.olakrutrim.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cloud.olakrutrim.com/basics/core-infrastructure/networking/load-balancers/create-application-load-balancer-alb.md).

# Create Application Load Balancer (ALB)

{% hint style="info" %}
Creating a Target Group is a prerequisite for creating a Load Balancer. [Learn how to create a target group](/basics/core-infrastructure/networking/load-balancers/create-target-group.md)
{% endhint %}

* Go to the "Networking > Load Balancers" tab.
* Click on "Create Load Balancer > Application Load Balancer".
* Fill in the following fields:
  * Load Balancer Name - a display name for your LB
  * Description
  * Region - select the region where you want to deploy your LB
  * VPC, Subnet - select the VPC and Subnet within which you want to place your LB
  * Security Group - Choose a security group for your LB. You can create a new security group with custom inbound/outbound rules for your LB, from the "Networking > Security Groups" tab. [Learn how to create a security group.](/basics/core-infrastructure/networking/security-groups.md)
* Select a performance tier. We provide the following performance tiers:
  * **Standard** - 4 vCPUs, 8 GB RAM
  * **Pro (coming soon)** - 8 vCPUs, 16 GB RAM 

{% hint style="success" %}
A **Standard** ALB can support upto 10,000 simultaneous connections and 40,000 requests per second (RPS).
{% endhint %}

* **High Availability** - Each load balancer is provisioned with High Availability (HA) by default. The load balancer is provisioned with 2 nodes (1 primary, 1 backup) for enhanced reliability and fault tolerance.
* **Add Listeners** - You can add multiple listeners, each of which maps to 1 target group.
  * Fill in a display name, the protocol, and port number on which it listens for traffic.
  * **Policies & Rules** - An ALB can route requests according to their content, hence we have the option of adding a policy for each listener, and rules within the policy. A policy defines the action to take when all associated rules evaluate to true. Rules define the specific conditions (e.g., URL path, headers) to match client requests.
  * Fill in a display name for your policy.
  * Select the action to take when all rules evaluate to true:
    1. **Redirect to URL** - Redirect all matching requests to a specified URL
    2. **Reject** - Reject all matching requests.
    3. **Redirect to Pool** - Forward all matching requests to the target group.
* **Add Rules** - You can add multiple rules inside a listener's policy, of the following types:

| Rule Type                             | Description                                                                                                                                                                |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Cookie**                            | Routes requests based on specific cookie values. Useful for session-based routing or user personalisation (e.g., send users with a certain cookie to a specific backend).  |
| **File Type**                         | Routes requests depending on the file extension in the URL (e.g., `.jpg`, `.css`, `.mp4`). Useful for separating static and dynamic content.                               |
| **Header**                            | Routes traffic based on HTTP header values. Ideal for routing based on user-agent, content-type, or custom headers set by the client.                                      |
| **Host Name**                         | Routes requests based on the domain name in the request (e.g., `api.example.com`, `app.example.com`). Perfect for hosting multiple domains on one load balancer.           |
| **Path**                              | Routes traffic according to the URL path (e.g., `/api/*`, `/images/*`). Commonly used to direct requests for different parts of an app to specific target groups.          |
| **SSL Connection (Has Certificate)**  | Checks whether the incoming SSL/TLS connection includes a valid certificate. Useful for enforcing secure client connections (mutual TLS).                                  |
| **SSL (Verify Result)**               | Routes based on the result of SSL certificate verification (valid/invalid). Allows you to handle unverified or expired certificates separately.                            |
| **SSL Distinguished Name (DN) Field** | Routes based on details within the SSL certificate’s Distinguished Name (e.g., Common Name or Organization). Useful in enterprise setups for identifying specific clients. |

* Select an appropriate comparator and fill in the value to compare against.
* **Pool Configuration** - 
  * Add a display name and protocol for your pool.
  * Select a load balancer algorithm appropriate for your needs.
  * Select a target group containing at least 1 active VM, for your pool.

| Algorithm             | Description                                                                                                                                 |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Round Robin**       | Distributes requests evenly across all healthy targets — simple and effective for most workloads.                                           |
| **Least Connections** | Sends new requests to the target with the fewest active connections — best for apps where requests vary in duration.                        |
| **Source IP**         | Routes traffic based on the client’s IP address — ensures requests from the same client always go to the same target (session consistency). |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.cloud.olakrutrim.com/basics/core-infrastructure/networking/load-balancers/create-application-load-balancer-alb.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.