Alibaba Cloud account registration Alibaba Cloud SLB load balancer configuration

Alibaba Cloud / 2026-04-30 12:34:30

Configuring an Alibaba Cloud SLB load balancer is one of those tasks that sounds intimidating until you actually do it. Then it becomes a series of decisions that feel weirdly like assembling a desk: you don’t need to be an engineer, but you do need to follow the instructions and not throw screws into the carpet. This article is your friendly guide to setting up Alibaba Cloud Server Load Balancer (SLB) with clear steps, sensible defaults, and troubleshooting advice for the most common “why is nothing working?” moments.

What SLB Does (And What It Doesn’t)

SLB’s job is to sit in front of your servers and distribute incoming traffic across them. Think of it as a polite receptionist who can’t do your work for you but can route visitors to the right desk. When traffic comes in, SLB forwards it to one of your backend servers based on listener rules, health checks, and load balancing algorithms.

However, SLB doesn’t magically fix broken application logic. If your backend application is returning errors, SLB will still happily send traffic to it—if it thinks that backend is “healthy.” That’s why health checks are so important. They’re like the tiny bouncer at the door who checks whether a server is truly ready to party.

Also, SLB isn’t a database, a cache, or a full traffic analytics platform by default. It handles connectivity, routing, and balancing. If you want fancy observability, you’ll probably pair it with other services (monitoring, logs, metrics, APM, etc.).

Before You Touch the Console: Planning Your Setup

Before configuration, gather answers to these questions. It will save you time and prevent the classic “I set everything but it still doesn’t work” situation.

1) What protocol are you exposing?

Common choices: HTTP, HTTPS, TCP, UDP (depending on SLB capabilities). For web apps, HTTP/HTTPS is typical. For custom protocols, TCP might fit. HTTPS adds certificate considerations, which we’ll cover later.

2) What port(s) do you need?

Most people expose port 80 (HTTP) and 443 (HTTPS). But modern systems love variety: port 8080 for internal services, port 8443 for alternate TLS, port 9000 for admin endpoints, and so on. SLB listeners map incoming ports to backend ports.

Alibaba Cloud account registration 3) How many backend servers will you use?

You can configure SLB with multiple backend instances across one or more zones. The more instances you have, the more fault tolerance you get. But remember: SLB doesn’t automatically scale your fleet. It can balance traffic, but it won’t magically spawn new servers unless you integrate with auto scaling or update your instance pool manually.

4) How do you want sessions handled?

Some applications need sticky sessions (session affinity). Others are stateless and can be perfectly happy without affinity. SLB offers options depending on your protocol and configuration. If you’re unsure, start with stateless setups and only enable stickiness if you have a real reason (like server-side sessions).

5) What does “healthy” mean for your service?

Set health checks to something meaningful. A basic TCP check might only verify that a port is open. An HTTP health check can validate that the application is responding with the right status code at a health endpoint (like /health or /status). A proper health check is the difference between “we’re up” and “we’re pretending to be up.”

Core SLB Concepts You’ll See in the Console

If the Alibaba Cloud console feels like it’s speaking in abbreviations (it does), these concepts are the translation layer.

Load Balancer Instance

This is the SLB “box” that receives traffic. You create one SLB instance, then configure listeners and backend servers under it.

Listeners

A listener defines what traffic SLB accepts (protocol and port) and how it should forward it. For example: “Incoming HTTP on port 80 should be forwarded to backend port 8080.” For HTTPS, it also involves certificates.

Backend Servers

These are your instance IPs (or instance identifiers) that receive the forwarded traffic. You can group instances into backend server sets, and SLB uses them for load balancing decisions.

Health Checks

Health checks periodically test each backend. Unhealthy backends are removed from rotation. Health check configuration often includes protocol (TCP/HTTP), interval, timeout, and success criteria (like expected HTTP status code).

Load Balancing Algorithm

SLB uses algorithms such as round-robin or least connections (depending on SLB features and protocol). Choose based on your app’s behavior. For many web apps, round-robin is perfectly fine. For services with uneven request durations, least connections can help.

Session Persistence (If Needed)

If your application relies on session affinity, you can enable persistence so that a client consistently hits the same backend. This is often implemented via cookies for HTTP-based apps.

Step-by-Step: Configuring an HTTP SLB

Let’s walk through a common case: you have several application servers running HTTP, but they listen on port 8080 internally. You want users on the internet to access your site via port 80.

Step 1: Create the SLB instance

In the Alibaba Cloud console, navigate to the SLB service and create a new load balancer. You’ll be asked for details like network type and region. Choose the same region as your backend instances. Then select whether the SLB is public-facing or internal (based on your use case). For internet users, you’ll typically choose a public SLB.

Choose the SLB specification that matches expected traffic and needs. Don’t overthink this at first; you can scale later if the platform supports it for your plan.

Step 2: Select a VSwitch and networking configuration

You’ll set a VSwitch (subnet) for the SLB. Make sure it aligns with your architecture. If your backend instances are deployed in certain zones, you’ll typically want the SLB to be configured accordingly so it can reach them.

At this stage, double-check routing and security rules. SLB can’t forward traffic to instances that don’t allow it. Networking issues are the cloud’s way of saying “I told you to check.”

Step 3: Add backend servers

Under the SLB instance, add backend server instances. You might choose by instance IDs and ports. Add all instances that should receive traffic. If you have more than one application or port, you might only add those serving the relevant listener.

Now check whether your instances listen on the backend port (say 8080). You’d be surprised how often someone configures SLB to forward to 8080 while the application is actually listening on 8000 or 3000. This is where your log files and a quick curl or netstat check can save the day.

Step 4: Configure the listener for HTTP

Create a listener with:

Front-end port: 80 (or whichever port clients use)
Protocol: HTTP
Backend port: 8080

Optionally configure rules if you use multiple routing behaviors (like path-based routing). Basic SLB setups just forward everything to the backend port.

Step 5: Configure health checks

This step is vital. Decide between TCP health checks and HTTP health checks.

If your app has a health endpoint (recommended), use HTTP health checks. Example settings:

Protocol: HTTP
Health check port: 8080
Alibaba Cloud account registration Health check path: /health
Healthy status code: 200 (or range you prefer)
Interval: 5 seconds (common)
Timeout: 2 seconds
Unhealthy threshold: e.g., 3 consecutive failures

Make sure your /health endpoint is lightweight and doesn’t do something expensive like calling external dependencies. Otherwise, you’ll turn your health check into a tiny denial-of-service against your own service.

If you don’t have a health endpoint yet, TCP checks can confirm that the port is open. But they can’t tell you whether the application is actually functional. A server might accept TCP connections but return 500 errors for real requests. HTTP health checks can prevent SLB from routing clients to such broken states.

Step 6: Confirm security groups and firewall rules

Now the part where the cloud sometimes plays hide-and-seek. Your backend instances must allow inbound traffic from the SLB (on the backend port). In many environments, this involves security groups (or firewall rules) attached to instances.

Check that:

Security group on backend instances allows inbound traffic on backend port (e.g., 8080) from the SLB’s IP range or from the SLB security group (if supported).
Network ACLs (if used) don’t block traffic.
Your instances have a listening service bound to the correct interface (e.g., 0.0.0.0) not just localhost.

Also ensure that the application is reachable within the VPC and that no proxies or routing rules interfere.

Step 7: Verify the backend status in SLB

After configuration, SLB will start health checking. Wait a few cycles. You should see backend servers transition to healthy state if everything is correct. If they remain unhealthy, don’t panic—this is where troubleshooting begins.

HTTPS Configuration: Certificates and the Usual Drama

Turning on HTTPS is where things go from “it might be misconfigured” to “it is absolutely misconfigured but in a different way.” The good news: once you understand the certificate flow, it becomes routine.

Step 1: Obtain and upload your certificate

You’ll need an SSL certificate. Alibaba Cloud typically supports uploading certificates (or using managed certificates) depending on your setup. Ensure:

The certificate is valid (not expired).
The domain name matches the certificate (CN/SAN).
You also have the private key and full chain if required by the platform.

Step 2: Add an HTTPS listener

Create a listener with:

Front-end protocol: HTTPS
Front-end port: 443
Backend protocol: HTTP (commonly) or HTTPS (if your backend supports it)
Backend port: usually 8080 or 8443

Attach the certificate to the HTTPS listener.

Step 3: Consider HTTP-to-HTTPS redirect

Many deployments also add an HTTP listener on port 80 that redirects to HTTPS. Some SLB configurations support redirect actions. Decide based on how your application expects requests.

If you don’t redirect and clients hit port 80, you’ll serve plain HTTP or maybe get a 404 depending on your app. Redirecting is usually nicer for user experience and security posture.

Step 4: Validate with a browser and curl

Test using:

A browser (to check for certificate warnings)
curl (to check headers, redirects, and response codes)
Optionally, openssl s_client (to confirm TLS handshake)

If you see certificate mismatch errors, it’s almost always the domain and certificate pairing. If it says handshake fails, check that the listener is correctly configured with the certificate, and that your certificate chain is complete.

TCP Load Balancing: When You’re Not Just Serving Webpages

Not everything is HTTP. If your service speaks TCP (for example, a custom protocol or database-like service, though SLB for databases is a topic for another article), SLB can still load balance based on a TCP listener.

In TCP mode, you typically configure:

Front-end protocol: TCP
Front-end port: e.g., 9000
Backend port: same or different port on backend servers
Health check: often TCP or sometimes application-layer (depending on features)

Because TCP health checks are “is the port open,” you should still consider whether your application has a way to validate readiness beyond mere connectivity. If your health check can’t verify deeper functionality, plan for application-level monitoring.

Alibaba Cloud account registration Also note that TCP connections can be long-lived. Load balancing algorithms and timeouts matter. Make sure your SLB idle timeout and your application timeouts are aligned, otherwise you’ll get mysterious disconnects that feel like the network is rolling its eyes.

Backend Selection, Routing, and Rules

Many SLB configurations go beyond “one listener forwards to one backend port.” You may want different routing behavior based on host headers, URL paths, or other attributes.

Basic forwarding rules

Alibaba Cloud account registration At its simplest, a listener forwards all traffic to a backend set. This is the easiest path and often enough.

Path-based or host-based routing

If SLB supports advanced routing rules in your product edition and configuration, you can define rules such as:

If path starts with /api, forward to backend group A
If path starts with /admin, forward to backend group B
Alibaba Cloud account registration If Host header is app.example.com, forward to app backend

This can help separate workloads and deploy different versions side by side. Just be careful: routing mistakes can look like “why is my endpoint returning the wrong service’s response?” which is very confusing and, frankly, rude to your debugging schedule.

Algorithm considerations

Load distribution algorithms should match your request characteristics. If all requests are similar and fast, round-robin works. If some requests are heavier and keep connections open, least connections can improve overall latency.

In some scenarios, session persistence changes the effective distribution. Even if the algorithm is fair, sticky sessions can pin clients to specific backends. That’s not inherently bad; it’s just something to keep in mind when you’re interpreting metrics.

Session Persistence: Sticky Sessions Without the Drama

Session persistence is helpful when your application stores session state in memory on each backend server. If a client’s requests must hit the same server, enabling session affinity avoids session loss.

Typical sticky session approaches include:

Cookie-based affinity for HTTP
Source IP-based affinity for some TCP/connection-based scenarios

Use it if you must. Prefer stateless designs when possible, because sticky sessions can reduce load balancing flexibility. If one backend becomes overloaded, stickiness might keep funneling traffic to it until health checks kick in.

Still, for legacy apps or stateful session designs, sticky sessions can be the difference between “works most of the time” and “works every time, like a dependable toaster.”

Health Checks: Tuning for Real Life

Health checks aren’t just a checkbox; they’re a tuning knob. Here are practical tips.

Alibaba Cloud account registration Choose a meaningful health endpoint

Use a /health endpoint that verifies the service is ready to handle real requests. Ideally it checks internal dependencies enough to signal readiness, but not so much that it becomes slow or failure-prone. There’s a balance: you want signal, not chaos.

Match timeouts to your app latency

If your app sometimes takes 3 seconds to respond under load, but your health check timeout is 1 second, SLB will mark backends unhealthy. That creates a feedback loop: SLB removes servers that are actually fine, which overloads remaining servers, which worsens latency. Congratulations, you invented a self-inflicted outage.

Don’t set intervals too aggressively

Health checks that run too frequently can add overhead. Most setups use 5 seconds for HTTP health checks, sometimes longer for heavier checks.

Be consistent with expected status codes

If your health endpoint returns 204 No Content but you expect 200 OK, it may be considered unhealthy. Align status codes with SLB configuration.

Troubleshooting: The “Why Is It Unhealthy?” Checklist

Let’s cover the classic troubleshooting path. Imagine your SLB dashboard shows backends in “unhealthy” state. Instead of spiraling, run through this list.

1) Verify your application is listening on the expected port

On a backend instance, confirm the application is listening on the port you configured (e.g., 8080). Use checks like netstat, ss, or a simple local curl.

If the app is listening on 127.0.0.1 only, SLB won’t reach it. Make sure it binds to 0.0.0.0 or the relevant network interface.

2) Confirm health check endpoint works from the instance itself

Hit the health check path (like /health) locally on the backend server. If it returns 404 or 500, SLB will never consider the server healthy. Fix the endpoint or adjust the health check path.

3) Check security groups and firewall rules

Make sure inbound rules allow the SLB to reach backend ports. If your backend is locked down to only certain sources, include the SLB’s source. Also check network ACL rules if you use them.

4) Validate that listener ports match backend ports

One of the most common misconfigurations: listener forwards to backend port X, but your service listens on port Y. Double-check the “front-end port” and “backend port” settings.

5) Confirm SLB is in the same region and compatible network

If you accidentally pick mismatched networking settings, SLB might not be able to reach the backend. Ensure region alignment and correct VSwitch configuration. In VPC-based setups, network connectivity matters.

6) Look at logs and metrics

Check backend logs for health check requests. Many times you’ll see the requests hitting and errors being logged. If you don’t see any health check requests, it’s likely a networking or security issue rather than an application issue.

7) For HTTPS: check certificate issues

If your HTTPS listener has certificate problems, clients may get errors and health checks may fail if they rely on HTTPS. Validate certificate validity and matching domains. Also verify backend protocol expectations: if SLB expects HTTPS to backend but your backend only speaks HTTP, health checks fail.

Multi-AZ and High Availability Tips

When SLB is configured with backends across multiple zones (AZs), you improve resilience. If one zone has issues, traffic can continue to be served from other zones as long as health checks report healthy status.

Ensure you actually distribute your instances across zones and add them all to the SLB backend. It’s possible to create a multi-zone architecture but accidentally add only instances from one zone. That turns “high availability” into “hope,” and hope is not a strategy.

Operational Best Practices

Once configured, treat SLB like a vital organ: keep it monitored, tested, and maintained.

Monitor SLB health and request metrics

Track metrics like backend health count, request count, latency, and error rates. If errors start increasing, it could be application regression, scaling needs, or misconfigured routing.

Use staged deployments when changing routing rules

If you update listener rules or backend sets, consider doing it gradually. You want to avoid routing real traffic to half-configured backends. Blue-green deployments can work well with SLB.

Document your configuration

Write down what listeners exist, which ports they forward to, what health check paths are used, and which security groups are involved. Your future self will be grateful, and your current self will feel mildly less chaotic.

Alibaba Cloud account registration Common Configuration Patterns (Quick Recipes)

Here are a few patterns you might want to implement. Think of these as “recipes,” but with fewer dishes and more servers.

Recipe A: HTTP to HTTPS with separate listeners

1) Listener on 80 redirects to 443. 2) Listener on 443 terminates SSL and forwards to backend on 8080 via HTTP. 3) Use HTTP health checks on backend /health:8080.

Recipe B: Separate backends for /api and /web

1) Single HTTPS listener on 443. 2) Routing rules: /api goes to backend group A (port 8080). /web goes to backend group B (port 8081). 3) Health checks for each backend group using their respective health endpoints.

Recipe C: TCP service with simple port checks

1) TCP listener on port 9000. 2) Backend port 9000. 3) TCP health check interval 5 seconds, threshold tuned for your service startup time. 4) Ensure instance firewall allows inbound on port 9000 from SLB.

Frequently Asked Questions

Why are my backend servers unhealthy?

Most commonly: health check path/port is wrong, the application isn’t listening on the expected port, security groups block SLB traffic, or timeouts/status code expectations don’t match.

Should my health check be HTTP or TCP?

HTTP is usually better when you can provide a reliable health endpoint. TCP is fine if your service only needs to be “port open,” but it can’t confirm the application is actually healthy.

Do I need session persistence?

If your application is stateless (sessions stored client-side or in shared storage), no. If session state lives in memory on each backend, then yes, or you’ll see weird login/session behavior.

Can I change backend servers later?

Yes. Typically you can update backend instance sets without fully recreating the SLB. When doing so, ensure new backends become healthy before routing significant traffic to them.

A Quick “Do It Right” Checklist

Before you declare victory, run through this checklist:

Alibaba Cloud account registration Listener front-end protocol and port match client expectations.
Backend port matches what your application actually listens on.
Health check path/protocol/status code matches your app behavior.
Timeouts and intervals are realistic for your app’s performance.
Security groups and network ACLs allow SLB-to-backend traffic.
Instances are in the right region and correctly reachable.
If HTTPS is used: certificate is valid, domains match, and backend protocol expectations are correct.

Conclusion: You’ve Got This

Configuring Alibaba Cloud SLB load balancer instances doesn’t have to feel like navigating a maze while blindfolded. You create the SLB, define listeners, attach backend servers, configure health checks, and verify that traffic actually reaches your apps. Once you do that, SLB handles the heavy lifting: distributing traffic and removing unhealthy servers from rotation.

If you hit problems, remember the pattern: nearly everything boils down to ports, protocols, health checks, and security rules. Treat it like a checklist-driven detective story. You’re not just configuring a load balancer—you’re training the cloud to stop surprising you.

Now go forth and balance your traffic like a responsible adult—preferably with a health endpoint that returns 200 and a security group that doesn’t hate your SLB. Good luck!