Alibaba Cloud Application Load Balancer (ALB) Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking and CDN

by

Category

Networking and CDN

1. Introduction

Application Load Balancer (ALB) on Alibaba Cloud is a managed Layer 7 (application layer) load balancer designed to distribute HTTP/HTTPS traffic across backend services. It sits in front of your applications, receives client requests, and forwards them to healthy backend targets based on routing rules and health checks.

In simple terms: ALB gives your application a stable entry point (a DNS name and optional public endpoint) and spreads traffic across multiple servers so you get better availability, scalability, and safer deployments.

Technically, Application Load Balancer (ALB) provides L7 capabilities such as host/path-based routing, TLS termination, listener rules, server groups, and health checks inside an Alibaba Cloud VPC. It integrates with common Alibaba Cloud services for compute (ECS), container platforms (ACK), networking (VPC, EIP), observability (CloudMonitor, Log Service), and security (RAM, certificates, and optional WAF integration where available—verify in official docs).

The problem it solves: building reliable, scalable web entry points without managing your own reverse-proxy fleet (like NGINX/HAProxy) and without manually implementing health checks, failover, routing rules, and TLS handling.

Naming and service positioning note (important): Alibaba Cloud historically used Server Load Balancer (SLB) as an umbrella concept. Today, load balancing on Alibaba Cloud typically includes Classic Load Balancer (CLB) (legacy), Network Load Balancer (NLB) (Layer 4), and Application Load Balancer (ALB) (Layer 7). This tutorial focuses strictly on Application Load Balancer (ALB).

2. What is Application Load Balancer (ALB)?

Official purpose (what ALB is for)
Application Load Balancer (ALB) is Alibaba Cloud’s managed application-layer load balancing service used to route HTTP and HTTPS traffic to backend services running in a VPC. It is designed for modern web applications and APIs that need advanced routing (for example, host- and path-based forwarding), TLS termination, and elastic scaling.

Core capabilities (what it can do) – Distribute HTTP/HTTPS traffic to backend targets using server groups – Perform health checks and only send traffic to healthy backends – Support advanced routing through listener rules (for example, forwarding based on host or URL path) – Terminate TLS/SSL at the load balancer and optionally re-encrypt to backends – Provide high availability through multi-zone deployment (within a region) – Integrate with Alibaba Cloud networking, compute, and observability tooling

Major components (what you configure) – ALB instance: The load balancer resource that provides a service endpoint (DNS name) and runs in a VPC. – Listeners: Protocol/port configurations (e.g., HTTP:80, HTTPS:443) that define how ALB receives traffic. – Listener rules: Matching conditions (host, path, headers, etc.) and forwarding actions to route traffic. – Server groups: Collections of backend targets (ECS instances, IP targets, or other supported target types—verify exact target types per region/version in official docs). – Health checks: Probes used to determine backend health. – Certificates (for HTTPS): TLS certs associated with HTTPS listeners.

Service type – Fully managed Layer 7 (application-layer) load balancer. – Operates inside Alibaba Cloud Networking and CDN domain as an application entry-point component.

Scope (regional/global/zonal/account) – Regional: An ALB instance is created in a specific region and attached to VPC subnets (vSwitches) in one or more zones within that region. – Multi-zone within a region: Typically you attach at least two vSwitches in different zones for resilience. – Account-scoped resource: Created and billed in your Alibaba Cloud account (and controlled through RAM).

How ALB fits into the Alibaba Cloud ecosystem ALB is commonly paired with: – ECS (Elastic Compute Service) for VM-based backends – ACK (Alibaba Cloud Container Service for Kubernetes) for ingress/traffic routing to Kubernetes workloads (via an ALB Ingress Controller—verify the current controller name and capabilities in official docs) – VPC, vSwitch, Security Groups, EIP for networking – CloudMonitor for metrics/alarms – Log Service (SLS) and/or OSS for logs (verify exact logging destinations supported for ALB in your region) – Certificate Management Service (SSL Certificates) for HTTPS certificates – Optional security services such as WAF in front of ALB or integrated depending on product capabilities and region (verify in official docs)

3. Why use Application Load Balancer (ALB)?

Business reasons

  • Higher availability: A single server outage should not take down your website/API.
  • Faster delivery: You can deploy new versions behind ALB using canary/blue-green patterns with minimal disruption.
  • Simplified operations: Avoid running and patching your own L7 proxies at scale.

Technical reasons

  • Layer 7 routing: Route traffic by hostname (api.example.com vs www.example.com) and by path (/v1/* vs /v2/*).
  • TLS offload: Centralize certificate management and reduce CPU load on backends.
  • Health-based forwarding: ALB automatically removes unhealthy targets from rotation.
  • Scalable front door: ALB is designed to scale with traffic demand (exact scaling behavior varies—verify in official docs).

Operational reasons

  • Standardized ingress pattern: Teams can consistently onboard services behind ALB.
  • Observability: Centralized metrics and logs can simplify troubleshooting and SLO reporting.
  • Safer change management: Rules and server groups reduce the need for frequent DNS changes.

Security/compliance reasons

  • Reduced exposure: Keep backends private in VPC; expose only ALB publicly.
  • Centralized TLS policy: Enforce strong ciphers/TLS versions at the edge (options vary—verify in official docs).
  • IAM governance: RAM policies can restrict who can modify listeners, rules, and backend targets.
  • Auditability: Use ActionTrail for API audit logs (verify service support and event coverage).

Scalability/performance reasons

  • Connection management: ALB handles client connections and can reuse connections to backends depending on configuration.
  • Horizontal scaling: Add/remove backend targets without changing client endpoints.
  • Multi-zone design: Better resilience to zone-level faults.

When teams should choose ALB

Choose Application Load Balancer (ALB) when you need: – HTTP/HTTPS entry point – Host/path-based routing and multiple services behind one IP/DNS – TLS termination and certificate management – Web apps, APIs, microservices, or Kubernetes ingress

When teams should not choose ALB

Avoid ALB (or consider alternatives) when: – You need Layer 4 TCP/UDP pass-through with minimal L7 features (consider Network Load Balancer (NLB)). – You are running legacy architectures that depend on CLB-specific features or existing CLB operational patterns (consider Classic Load Balancer (CLB), but treat it as legacy where applicable). – You need global anycast or cross-region acceleration (consider Global Accelerator and/or CDN depending on use case). – Your traffic is not HTTP/HTTPS (ALB is L7; non-HTTP workloads typically don’t fit).

4. Where is Application Load Balancer (ALB) used?

Industries

  • SaaS and internet platforms (web apps, APIs)
  • E-commerce (high availability storefronts, checkout APIs)
  • FinTech (API gateways behind controlled entry points)
  • Media and content platforms (origin routing to multiple services)
  • Enterprise IT (internal apps, portals, shared services)
  • Gaming backends (HTTP APIs and admin consoles)

Team types

  • Platform engineering teams building standardized ingress
  • DevOps/SRE teams managing reliability and scaling
  • Application teams deploying multiple microservices
  • Security teams enforcing TLS and exposure boundaries
  • Network teams standardizing VPC ingress/egress patterns

Workloads

  • REST/GraphQL APIs
  • Web frontends
  • Microservices with multiple routes
  • Internal admin portals (intranet ALB)
  • CI/CD preview environments (one ALB, many routes)
  • Kubernetes ingress for services

Architectures

  • Three-tier web apps (ALB → app tier → database tier)
  • Microservices (ALB → services based on path/host)
  • Shared ingress with multiple environments (e.g., dev.*, prod.* separated by rules)
  • Zero-trust-ish patterns where only ALB is exposed and backends are private

Production vs dev/test usage

  • Production: Multi-zone, strict TLS policies, access logging, alarms, controlled IAM, runbooks.
  • Dev/test: Smaller backend pools, fewer rules, relaxed logging, but still useful for realistic traffic routing and release testing.

5. Top Use Cases and Scenarios

Below are realistic ways teams use Application Load Balancer (ALB) on Alibaba Cloud.

1) Host-based routing for multi-domain SaaS

  • Problem: You host multiple customer domains or subdomains on the same platform.
  • Why ALB fits: Listener rules can route by Host header to different server groups.
  • Example: tenant-a.example.com → server group A, tenant-b.example.com → server group B.

2) Path-based routing for microservices

  • Problem: Multiple services share one public endpoint.
  • Why ALB fits: Route by path prefixes.
  • Example: /api/* → API service; /static/* → static service; /admin/* → admin service.

3) TLS termination and certificate centralization

  • Problem: Managing certificates on many backend servers is error-prone.
  • Why ALB fits: Terminate HTTPS at ALB; rotate certificates centrally.
  • Example: ALB uses a managed certificate; backends run plain HTTP inside VPC.

4) Blue/green deployment with weighted split (if supported)

  • Problem: Need to release a new version with controlled traffic.
  • Why ALB fits: Some L7 load balancers support splitting traffic between server groups by weight (verify ALB support in official docs).
  • Example: Route 90% to v1 server group, 10% to v2.

5) Canary releases by header or cookie routing

  • Problem: Target QA users or internal testers without changing DNS.
  • Why ALB fits: Advanced rules can match headers/cookies (verify available match types).
  • Example: If header X-Canary: true then forward to canary server group.

6) Intranet application gateway for enterprise apps

  • Problem: Internal apps need a consistent entry point inside the VPC.
  • Why ALB fits: Internal-facing ALB provides private DNS endpoint and controlled routing.
  • Example: HR portal and internal API behind a private ALB.

7) Kubernetes ingress for services on ACK

  • Problem: Need managed ingress routing to Kubernetes services.
  • Why ALB fits: ALB can act as ingress (through an ALB Ingress Controller—verify the current supported controller and features).
  • Example: One ALB routes /svc-a to Service A and /svc-b to Service B.

8) Centralized access logging for compliance

  • Problem: Compliance needs request logs (source IP, request path, status).
  • Why ALB fits: ALB can emit access logs to centralized storage/log analytics (verify exact options).
  • Example: Send logs to Log Service (SLS) and build dashboards/alerts.

9) HTTP to HTTPS redirects

  • Problem: Enforce secure transport for all users.
  • Why ALB fits: Listener actions can redirect HTTP to HTTPS (verify redirect configuration).
  • Example: Port 80 listener returns 301 to https://$host$request_uri.

10) Multi-zone resiliency for web entry points

  • Problem: Zone failures cause downtime if all backends are in one zone.
  • Why ALB fits: Deploy ALB across multiple zones and register backends in multiple zones.
  • Example: Backends in Zone A and Zone B; ALB continues routing if one zone fails.

11) API front door for rate-limited backends (partial)

  • Problem: Prevent backend overload from spikes.
  • Why ALB fits: ALB can smooth connection handling; however full rate limiting is usually a WAF/API gateway feature. Use ALB plus WAF/API Gateway when needed (verify ALB’s native throttling features, if any).
  • Example: ALB forwards to API Gateway or WAF enforces policies.

12) Migration off self-managed reverse proxies

  • Problem: You maintain HAProxy/NGINX fleets for load balancing.
  • Why ALB fits: Offload patching, scaling, and HA of the L7 edge.
  • Example: Replace NGINX edge nodes with ALB; keep NGINX only for app-level concerns if needed.

6. Core Features

This section lists important current ALB feature areas. Exact availability can vary by region and account settings—verify in official docs for the newest options.

6.1 Layer 7 HTTP/HTTPS load balancing

  • What it does: Distributes application-layer traffic across backend targets.
  • Why it matters: Enables web- and API-specific behaviors (routing, TLS termination).
  • Practical benefit: One stable endpoint for many services.
  • Caveat: ALB is primarily for HTTP/HTTPS; non-HTTP protocols typically require NLB/CLB.

6.2 Listeners (HTTP and HTTPS)

  • What it does: Defines ports/protocols and how ALB accepts connections.
  • Why it matters: Separates ingress concerns per protocol.
  • Benefit: Run HTTP:80 and HTTPS:443 with different policies.
  • Caveat: Listener limits exist (verify quotas).

6.3 Listener rules and routing conditions

  • What it does: Matches requests and routes them to specific server groups.
  • Why it matters: Enables microservices and multi-site hosting without extra load balancers.
  • Benefit: Clear separation of routing logic from application code.
  • Caveat: The set of match conditions (host/path/header/query/cookie) varies—verify supported match types.

6.4 Server groups (backend target groups)

  • What it does: Defines pools of backends receiving traffic.
  • Why it matters: Lets you attach/detach targets without changing the frontend endpoint.
  • Benefit: Simplifies scaling and maintenance.
  • Caveat: Supported backend types and max targets per group can vary (verify in docs).

6.5 Health checks

  • What it does: Periodically probes backends to determine whether they should receive traffic.
  • Why it matters: Prevents routing to broken instances.
  • Benefit: Automatic failover at the load balancing layer.
  • Caveat: Misconfigured health checks are a common cause of outages (wrong path, security group blocks).

6.6 Session persistence (sticky sessions)

  • What it does: Keeps a client’s requests going to the same backend for a period (typically cookie-based for HTTP/HTTPS).
  • Why it matters: Some apps require stateful sessions.
  • Benefit: Reduces app refactoring pressure during migrations.
  • Caveat: Stickiness can reduce load distribution and complicate deployments; prefer stateless apps where possible.

6.7 TLS termination and certificate management

  • What it does: Terminates HTTPS at ALB and uses configured certificates (often from Alibaba Cloud certificate services).
  • Why it matters: Central point to manage certificates and enforce TLS policies.
  • Benefit: Simplified rotation and consistent encryption posture.
  • Caveat: Mutual TLS (mTLS) and advanced TLS features depend on ALB support—verify in official docs.

6.8 HTTP/2 support (if available)

  • What it does: Allows clients to use HTTP/2 to the load balancer for improved performance.
  • Why it matters: Better multiplexing and latency, especially for web apps.
  • Benefit: Potential performance improvement without changing backends.
  • Caveat: Confirm support and configuration requirements in your region (verify in docs).

6.9 Access logging (observability)

  • What it does: Emits request logs for analytics and troubleshooting.
  • Why it matters: Essential for debugging 4xx/5xx, latency, and security investigations.
  • Benefit: Central source of truth at the edge.
  • Caveat: Logging destinations and formats vary; storage/ingestion adds cost (verify destinations such as Log Service or OSS).

6.10 Metrics and alarms (CloudMonitor)

  • What it does: Provides operational metrics (connections, QPS, latency, errors).
  • Why it matters: Enables SLO monitoring and alerting.
  • Benefit: Faster detection of incidents.
  • Caveat: High-cardinality analytics may require log-based analysis rather than metrics alone.

6.11 High availability within a region (multi-zone)

  • What it does: ALB can be deployed across multiple zones using multiple vSwitches.
  • Why it matters: Zone-level resilience.
  • Benefit: Improved uptime and reduced blast radius.
  • Caveat: Requires you to also place backends across zones and handle data tier HA.

6.12 Integration with Alibaba Cloud RAM and governance

  • What it does: Uses RAM for access control and supports tagging for governance.
  • Why it matters: Enforces least privilege and operational ownership.
  • Benefit: Safer operations at scale.
  • Caveat: Fine-grained resource-level policies require careful testing.

7. Architecture and How It Works

High-level architecture

At runtime, ALB acts as the entry point: 1. A client resolves the ALB DNS name (or your custom domain CNAME). 2. Client connects to ALB listener (HTTP/HTTPS). 3. ALB evaluates listener rules to select a server group. 4. ALB performs health-aware load balancing to a backend target. 5. Response returns through ALB to the client.

Request/data/control flow

  • Data plane: Client ↔ ALB ↔ Backend.
  • Control plane: You configure ALB instances, listeners, rules, server groups via Console, API, SDK, or CLI; changes propagate to ALB.

Integrations with related services

Common integrations include: – VPC/vSwitch: ALB lives in your VPC and attaches to vSwitches (subnets). – EIP: For internet-facing ALB, you typically associate public connectivity (EIP or managed public addressing depending on ALB type/region—verify in docs). – ECS: Backends often run on ECS instances in private subnets. – ACK (Kubernetes): ALB used as ingress controller front end (verify current controller). – Certificate Management Service: Upload/issue and bind certs to HTTPS listeners. – CloudMonitor: Metrics and alarms. – Log Service (SLS) / OSS: Access logs and storage/analysis (verify exact support).

Dependency services (what you usually need)

  • VPC + vSwitches in at least two zones (recommended for production)
  • Backends (ECS/containers) reachable from ALB subnets
  • Security groups/NACLs allowing ALB-to-backend traffic
  • DNS (Alibaba Cloud DNS or external) for custom domain mapping

Security/authentication model

  • Management-plane access: Controlled via RAM users/roles and policies.
  • Traffic security: TLS termination for HTTPS; backend security via VPC isolation and security groups.
  • Auditability: Use ActionTrail for tracking API actions (verify coverage for ALB operations).

Networking model

  • ALB attaches to one or more vSwitches within a VPC.
  • Backends are typically private IPs in the same VPC (or reachable through VPC connectivity such as peering/CEN—verify supported patterns).
  • For internet access, ALB is configured as internet-facing; for internal apps, it is internal-facing.

Monitoring/logging/governance considerations

  • Enable CloudMonitor alarms (latency, 5xx, unhealthy backends).
  • Enable access logs for troubleshooting and security analytics.
  • Use tags and naming conventions to separate environments and owners.
  • Track configuration changes with ActionTrail and change-management processes.

Simple architecture diagram (Mermaid)

flowchart LR
  U[User Browser / API Client] --> DNS[DNS: app.example.com]
  DNS --> ALB[Alibaba Cloud Application Load Balancer (ALB)\nHTTP/HTTPS Listener]
  ALB --> SG[Server Group]
  SG --> ECS1[ECS Backend 1\n(Private IP)]
  SG --> ECS2[ECS Backend 2\n(Private IP)]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Internet[Internet]
    Client[Clients]
  end

  subgraph Region[Alibaba Cloud Region]
    subgraph VPC[VPC]
      subgraph ZoneA[Zone A]
        VSWA[vSwitch A]
        ECS_A1[ECS / Pod Backend A1]
        ECS_A2[ECS / Pod Backend A2]
      end

      subgraph ZoneB[Zone B]
        VSWB[vSwitch B]
        ECS_B1[ECS / Pod Backend B1]
        ECS_B2[ECS / Pod Backend B2]
      end

      ALB[Application Load Balancer (ALB)\nMulti-zone\nHTTPS Listener + Rules]
      SG1[Server Group: web]
      SG2[Server Group: api]

      ALB --> SG1
      ALB --> SG2

      SG1 --> ECS_A1
      SG1 --> ECS_B1
      SG2 --> ECS_A2
      SG2 --> ECS_B2
    end

    Logs[Log Service (SLS) / OSS\nAccess Logs]
    Mon[CloudMonitor\nMetrics & Alarms]
    Certs[Certificate Mgmt\nSSL/TLS Certificates]
  end

  Client -->|HTTPS 443| ALB
  ALB --> Logs
  ALB --> Mon
  Certs --> ALB

8. Prerequisites

Before you start the hands-on lab, ensure you have:

Account and billing

  • An active Alibaba Cloud account with billing enabled (Pay-As-You-Go or subscription depending on your org model).
  • Sufficient quota to create:
  • VPC, vSwitches
  • ECS instances
  • Application Load Balancer (ALB) instance
  • Elastic IP (EIP) if creating an internet-facing endpoint (region-specific—verify ALB public connectivity model)

Permissions (RAM / IAM)

Use a RAM user or RAM role with least privilege. For a lab, you may temporarily use broad policies, then tighten later.

Typical policies (names can vary by partition and time—verify in Alibaba Cloud policy reference): – ALB management (e.g., AliyunALBFullAccess or equivalent) – ECS management (e.g., AliyunECSFullAccess) – VPC management (e.g., AliyunVPCFullAccess) – CloudMonitor read/alarms (optional) – Certificate service access if configuring HTTPS (optional)

Also ensure you can: – Create and manage security groups – Attach backends to server groups

Tools (optional but helpful)

  • Alibaba Cloud Console (browser)
  • curl for testing
  • Optional: Alibaba Cloud CLI (aliyun) if you prefer automation (verify the latest CLI commands for ALB; they can change)

Region availability

  • Choose a region where Application Load Balancer (ALB) is available.
  • Confirm multi-zone availability (at least two zones) for best practice.

Quotas / limits

  • Limits for number of ALB instances, listeners, rules, server groups, and targets exist.
  • For production planning, confirm quotas in the official docs and request quota increases if needed.

Prerequisite services

  • VPC and vSwitches
  • ECS (or ACK) for backend targets
  • Security groups allowing ALB-to-backend traffic

9. Pricing / Cost

Alibaba Cloud pricing for Application Load Balancer (ALB) is usage-based and region-dependent. You should always validate current rates in your target region.

Official pricing sources (use these)

  • Product page (includes pricing entry points): https://www.alibabacloud.com/product/alb
  • Pricing calculator (if available in your account/locale): https://www.alibabacloud.com/pricing-calculator
  • Official documentation landing page: https://www.alibabacloud.com/help/en/application-load-balancer/

If the pricing model shown in your console differs from the public site, follow what your console shows for your billing account and region.

Pricing dimensions (common patterns)

While exact line items differ by region and billing mode, ALB pricing commonly includes some combination of:

  1. ALB instance-hours
    – You pay for the load balancer instance running time.

  2. Capacity-based usage
    – Many modern L7 load balancers bill on capacity/throughput units (similar in concept to an LCU).
    – This can be based on new connections, active connections, processed bytes, and/or rule evaluations.
    – Verify the specific capacity measurement used by Alibaba Cloud ALB in your region.

  3. Network charges – Public data transfer out to the internet is typically billed. – If using EIP, EIP billing and bandwidth plans can add cost. – Intra-VPC traffic is often cheaper than internet egress, but still validate your network billing rules.

  4. Optional features – HTTPS certificates (if purchased through Alibaba Cloud) may have separate costs. – Logging (Log Service ingestion + storage, or OSS storage) adds cost. – WAF (if used) adds cost. – Backends (ECS, disks, snapshots) are separate and often dominate total cost.

Cost drivers (what increases your bill)

  • High request rate (RPS/QPS) and throughput
  • Large responses (e.g., file downloads)
  • Many rules and complex routing (can increase processing)
  • Public internet egress
  • High volume access logs stored for long retention
  • Over-provisioned backend compute due to poor autoscaling

Hidden/indirect costs to plan for

  • ECS costs: instances, system disks, data disks
  • OSS/SLS logging storage and analytics queries
  • NAT Gateway costs if private instances need outbound internet (for patching, package downloads)
  • Cross-zone traffic implications (depends on Alibaba Cloud billing rules—verify in docs for your region)

How to optimize cost

  • Use ALB only where L7 features are needed; use NLB for pure TCP/UDP.
  • Keep responses small (compression at app layer, caching via CDN when appropriate).
  • Turn on access logs with a sensible retention period; archive to OSS if needed.
  • Use autoscaling for backends so you don’t keep excess ECS instances running.
  • Use internal ALB for internal services; avoid unnecessary internet egress.
  • Consider CDN in front of ALB for cacheable content to reduce origin traffic.

Example low-cost starter estimate (no fabricated numbers)

A minimal lab environment typically includes: – 1 ALB instance (pay-as-you-go) – 2 small ECS instances – Optional EIP/public endpoint – Minimal logging

Because ALB and network egress pricing varies by region and account, do this to estimate safely: 1. Open the pricing calculator. 2. Add ALB (region), set expected hours, and modest traffic assumptions. 3. Add ECS and EIP/bandwidth if used. 4. Add log ingestion/storage if enabling access logs.

Example production cost considerations

For production, plan and model: – Peak and sustained RPS and Mbps/Gbps – TLS handshake rates (certificate and cipher choices affect CPU/latency) – Log volume: requests/day × log line size × retention – Egress and CDN offload strategy – Multi-environment separation (prod/stage/dev) and whether each needs its own ALB

10. Step-by-Step Hands-On Tutorial

This lab builds a simple, realistic setup:

  • Two ECS instances running NGINX
  • One ALB instance forwarding HTTP traffic to those ECS backends
  • A path-based rule to demonstrate L7 routing
  • Validation with curl
  • Safe cleanup steps

Objective

Deploy Application Load Balancer (ALB) in Alibaba Cloud to load balance HTTP traffic across two ECS instances, verify health checks and load distribution, and then clean up resources to avoid ongoing charges.

Lab Overview

You will: 1. Create networking (VPC + 2 vSwitches in different zones recommended) 2. Create two ECS backends with a simple web page 3. Create a server group and register the ECS instances 4. Create an ALB instance and an HTTP listener 5. Add routing rules and validate behavior 6. Troubleshoot common issues 7. Clean up

Notes: – The exact Alibaba Cloud Console wording can change. Use the closest matching fields. – If you prefer Infrastructure as Code (Terraform), use the official Alibaba Cloud Terraform provider docs (verify current resource names).

Step 1: Create a VPC and two vSwitches (recommended)

Goal: Provide a private network environment for ALB and ECS.

  1. In the Alibaba Cloud Console, go to VPC.
  2. Create a VPC: – Name: lab-alb-vpc – CIDR: e.g., 10.0.0.0/16
  3. Create two vSwitches in different zones within the same region: – lab-alb-vsw-a in Zone A: 10.0.1.0/24 – lab-alb-vsw-b in Zone B: 10.0.2.0/24

Expected outcome – One VPC with two subnets (vSwitches) across two zones.

Verification – In VPC console, confirm both vSwitches show Available and are in different zones.

Step 2: Create a security group for the backends

Goal: Allow ALB to reach backend web servers and (optionally) allow you to SSH for setup.

  1. Go to ECS → Security Groups → Create Security Group.
  2. Name: lab-alb-backend-sg
  3. Inbound rules: – Allow HTTP 80 from:
    • For lab simplicity: 0.0.0.0/0 (not recommended for production), or
    • Better: allow from your VPC CIDR (10.0.0.0/16) so only ALB can reach it.
    • Allow SSH 22 from your public IP only (e.g., x.x.x.x/32) for setup.
  4. Outbound rules: – Default allow is usually fine for labs.

Expected outcome – A security group that permits backend HTTP traffic and limited SSH.

Verification – Confirm inbound rules are present and correct.

Step 3: Create two ECS instances (backend servers)

Goal: Run a simple web server on two different backends so you can see load balancing.

  1. Go to ECS Instances → Create Instance.
  2. Choose: – Same region as your VPC – Network: lab-alb-vpc – vSwitch: put the first ECS in lab-alb-vsw-a, second in lab-alb-vsw-b – Security group: lab-alb-backend-sg – OS: Alibaba Cloud Linux / CentOS / Ubuntu (choose one you’re comfortable with)
  3. Instance naming: – lab-alb-ecs-1 – lab-alb-ecs-2
  4. Assign public IP: – Optional. If you don’t assign public IPs, you will need a bastion host, VPN, or Session Manager equivalent to configure them. For a beginner lab, a temporary public IP can be simpler (but costs and exposure increase).

Configure NGINX on both instances

SSH into each ECS and run one of the following sets of commands.

For Ubuntu/Debian

sudo apt-get update
sudo apt-get -y install nginx
echo "Hello from $(hostname) - backend 1/2" | sudo tee /var/www/html/index.html
sudo systemctl enable nginx
sudo systemctl restart nginx

For RHEL/CentOS/Alibaba Cloud Linux (package names vary)

sudo yum -y install nginx || sudo dnf -y install nginx
echo "Hello from $(hostname) - backend 1/2" | sudo tee /usr/share/nginx/html/index.html
sudo systemctl enable nginx
sudo systemctl restart nginx

Expected outcome – Both ECS instances serve HTTP on port 80 with different content.

Verification From your laptop (if instances have public IPs):

curl -s http://<ECS_PUBLIC_IP_1>/
curl -s http://<ECS_PUBLIC_IP_2>/

You should see different hostnames in the responses.

If instances do not have public IPs, verify from within the VPC (via bastion or other access).

Step 4: Create a server group and register ECS backends

Goal: Define the pool of backends ALB will forward to.

  1. Go to Application Load Balancer (ALB) console.
  2. Create a Server Group: – Name: lab-alb-sg-web – VPC: lab-alb-vpc – Backend protocol: HTTP (typical for L7 forwarding)
  3. Add backend servers: – Add lab-alb-ecs-1 (port 80) – Add lab-alb-ecs-2 (port 80)
  4. Configure health check (typical values): – Protocol: HTTP – Path: / – Expected HTTP codes: 200 (or range; depends on UI options) – Interval/timeout: defaults are fine for a lab

Expected outcome – Server group exists and includes two ECS targets.

Verification – In server group target list, wait until health status shows Healthy. – If they remain unhealthy, proceed to the Troubleshooting section.

Step 5: Create an ALB instance (multi-zone)

Goal: Create the actual ALB resource that will receive traffic.

  1. In the ALB console, create an ALB Instance.
  2. Select: – Region: your lab region – VPC: lab-alb-vpc – vSwitches: select both lab-alb-vsw-a and lab-alb-vsw-b
  3. Choose endpoint type: – Internet-facing if you want to test from your laptop without VPN – Internal-facing if you will test from within the VPC

Public connectivity details vary by ALB offering and region (EIP association vs built-in public addressing). Follow the console workflow and verify in official docs for your region.

Expected outcome – ALB instance is created and shows a DNS name.

Verification – In ALB instance details, copy the provided DNS name.

Step 6: Create an HTTP listener and forward to the server group

Goal: Make ALB accept traffic on port 80 and send it to your ECS servers.

  1. In your ALB instance, go to Listeners → Create Listener.
  2. Configure: – Protocol: HTTP – Port: 80
  3. Default action: – Forward to server group: lab-alb-sg-web

Expected outcome – HTTP listener is active.

Verification From your laptop:

curl -i http://<ALB_DNS_NAME>/

You should receive an HTTP 200 response from one backend.

Run it multiple times:

for i in {1..6}; do curl -s http://<ALB_DNS_NAME>/; done

You should see responses alternating between the two backend hostnames (depending on load balancing behavior and keep-alives).

Step 7: Add a path-based routing rule (demo)

Goal: Demonstrate ALB’s application-layer routing.

You’ll create a second server group and rule that routes /api/* to a different backend set (for demo, we can reuse the same ECS but with a different page path).

7.1 Update backends to serve an /api endpoint

On both ECS instances:

sudo mkdir -p /var/www/html/api || true
echo "API response from $(hostname)" | sudo tee /var/www/html/api/index.html
sudo systemctl restart nginx

7.2 Create a second server group

  • Name: lab-alb-sg-api
  • Add both ECS instances on port 80 (or only one if you want deterministic responses)

7.3 Create a listener rule

In the HTTP listener: – Add rule: – Condition: Path is /api/* (or equivalent syntax in console) – Action: Forward to server group lab-alb-sg-api – Ensure rule priority/order is correct (more specific rules should win).

Expected outcome – Requests to / go to lab-alb-sg-web – Requests to /api/ go to lab-alb-sg-api

Verification

curl -s http://<ALB_DNS_NAME>/
curl -s http://<ALB_DNS_NAME>/api/

Validation

Use this checklist:

  1. ALB instance status is Running/Active.
  2. Listener is active on port 80.
  3. Server group targets show Healthy.
  4. curl http://ALB_DNS/ returns backend content.
  5. curl http://ALB_DNS/api/ returns API content.
  6. Repeated curls show distribution across backends (not always perfectly alternating due to connection reuse, but you should see both servers).

Troubleshooting

Common errors and realistic fixes:

  1. Backends show Unhealthy – Check the backend security group inbound rule allows port 80 from ALB/VPC CIDR. – Confirm NGINX is running: sudo systemctl status nginx – Confirm the health check path is valid (/ returns 200). – Confirm ECS is in the same VPC and reachable (routing tables, NACLs if used).

  2. curl to ALB DNS times out – If internet-facing: confirm ALB is truly public and has a public endpoint/EIP association. – Confirm any ALB security controls (if applicable) allow inbound HTTP from your IP (some load balancers support ACLs—verify in docs). – Ensure local firewall/proxy is not blocking.

  3. Always hits the same backend – Keep-alive can reuse the same connection. – Try forcing new connections: bash curl -s --no-keepalive http://<ALB_DNS_NAME>/ (If your curl doesn’t support --no-keepalive, run curl in separate processes or add headers; behavior can vary.)

  4. 404 on /api/ – Verify NGINX path exists and permissions are correct. – Ensure the listener rule match is correct and prioritized above default forwarding.

  5. HTTPS not working (if you later add it) – Confirm certificate is valid and bound to the HTTPS listener. – Confirm SNI configuration if using multiple domains (verify ALB supports and how it is configured). – Confirm security policies allow modern TLS versions.

Cleanup

To avoid charges, delete resources in this order:

  1. In ALB console: – Delete listener rules (if required by UI) – Delete listeners – Delete server groups (or remove targets first if required) – Delete the ALB instance
  2. Release EIP (if one was allocated separately)
  3. In ECS: – Delete lab-alb-ecs-1 and lab-alb-ecs-2
  4. In VPC: – Delete vSwitches – Delete VPC
  5. Delete security group (if no longer used)

Verification – Check Billing/Resource list to ensure ALB instances and EIPs are not present.

11. Best Practices

Architecture best practices

  • Use multi-zone: Attach ALB to at least two vSwitches and run backends in at least two zones.
  • Separate concerns: Use ALB for L7 routing and TLS, keep application services stateless where possible.
  • Use multiple server groups: One per service/component to simplify deployments and ownership.
  • Design for failure: Assume a backend, a zone, or a deployment can fail; use health checks and fast rollback.

IAM/security best practices

  • Least privilege RAM policies:
  • Separate “network admins” who create ALB from “app teams” who can only update server group targets/rules as needed.
  • Use RAM roles for automation instead of long-lived access keys.
  • Tag resources (env=prod, app=payments, owner=platform) and enforce tagging policies if your governance model supports it.

Cost best practices

  • Right-size backend compute; ALB doesn’t reduce backend cost by itself.
  • Prefer CDN for cacheable static content to reduce ALB traffic and egress.
  • Enable logging intentionally with retention control; archive/roll logs.
  • Avoid unnecessary public exposure: internal ALB for internal apps.

Performance best practices

  • Tune health checks to balance fast failover and false positives (avoid overly aggressive timeouts).
  • Use connection reuse/keep-alives appropriately; verify your backend server settings.
  • If HTTP/2 is supported and appropriate, enable it for web clients (verify ALB support).

Reliability best practices

  • Use infrastructure-as-code for repeatability (Terraform or equivalent).
  • Deploy backends with autoscaling (ECS Auto Scaling or Kubernetes HPA).
  • Set CloudMonitor alarms for:
  • Unhealthy hosts > 0
  • 5xx error rate threshold
  • High latency / saturation indicators
  • Keep rollback procedures documented (remove rule, shift traffic to stable server group).

Operations best practices

  • Implement change management for listener rules; misordered rules can break routing.
  • Maintain runbooks:
  • “Backends unhealthy”
  • “High 5xx at ALB”
  • “Latency regression”
  • Periodically test failover by taking one backend out of service.

Governance/tagging/naming best practices

  • Naming pattern example:
  • alb-prod-main, alb-stg-main
  • sg-prod-web, sg-prod-api
  • lis-prod-https-443
  • Use consistent tags and enforce them in CI pipelines.

12. Security Considerations

Identity and access model (RAM)

  • ALB is managed through Alibaba Cloud APIs and Console; access is controlled with RAM.
  • Recommended pattern:
  • Human users: RAM users with MFA + least privilege.
  • Automation: RAM roles assumed by CI/CD (short-lived credentials).
  • Audit RAM policy changes and ALB configuration changes.

Encryption

  • Use HTTPS listeners for encryption in transit from clients to ALB.
  • For ALB-to-backend encryption:
  • If you handle sensitive data, consider HTTPS from ALB to backends too, or ensure the VPC network and host hardening meets your threat model.
  • Confirm how ALB validates backend certificates (if supported)—verify in official docs.

Network exposure

  • Prefer internal-facing ALB for internal services.
  • For internet-facing ALB:
  • Restrict management access via RAM
  • Restrict backend exposure: backends should not have public IPs unless required
  • Use security groups to allow inbound only from VPC/ALB, not the internet

Secrets handling

  • Don’t store private keys on ECS instances if ALB terminates TLS.
  • Use Alibaba Cloud certificate services and proper access controls for certificate management.
  • Store app secrets in a secrets manager service (verify your org’s standard—Alibaba Cloud has secrets services; confirm the current product and best practice).

Audit/logging

  • Enable ActionTrail for control-plane auditing (verify ALB event types).
  • Enable access logs for data-plane visibility (consider PII handling and retention).
  • Centralize logs and apply access controls and retention policies.

Compliance considerations

  • Ensure logs, certificates, and endpoints comply with:
  • Data residency rules (region selection)
  • Retention requirements
  • Encryption requirements
  • For regulated environments, document:
  • TLS versions/ciphers
  • Change management processes
  • Incident response steps

Common security mistakes

  • Exposing backends publicly (public IP + open security group) while also placing ALB in front.
  • Health check endpoint exposes sensitive debug data.
  • Overly broad RAM permissions allowing anyone to modify routing rules.
  • Lack of logging/alerting for 5xx spikes or WAF events (if used).

Secure deployment recommendations

  • Internet-facing ALB + private backends only.
  • Use HTTPS everywhere; redirect HTTP to HTTPS.
  • Use WAF where threat models require it (verify best-practice integration path in Alibaba Cloud docs).
  • Implement infrastructure-as-code + peer-reviewed change process for listener rules.

13. Limitations and Gotchas

Because limits evolve and differ by region, treat this as a planning checklist and verify in official docs.

Known limitation categories

  • Regional scope: ALB is regional. For multi-region active-active, use DNS/GA/CDN patterns.
  • Listener/rule quotas: Max number of listeners per instance, rules per listener, conditions per rule.
  • Server group limits: Max targets per group and per instance.
  • Backend target types: ECS, IP targets, and others may be supported, but availability varies. Confirm for your region.
  • Protocol scope: ALB focuses on HTTP/HTTPS; use NLB for TCP/UDP.
  • Feature availability by region: Some advanced capabilities (HTTP/2, logging destinations, WAF integration) can vary.

Operational gotchas

  • Health check misconfigurations cause silent outages (ALB returns 5xx when no healthy targets).
  • Rule priority/order: A broad rule can shadow a more specific rule.
  • Keep-alives can make load distribution appear “sticky” even without session persistence.
  • Security group scope: If backends only allow 0.0.0.0/0 on port 80 for convenience, you’ve created unnecessary exposure.
  • Logging costs: Access logs can become expensive at scale if you retain everything forever.

Migration challenges

  • Migrating from self-managed NGINX/HAProxy:
  • Some custom behaviors may not map 1:1 (rewrite logic, special headers, bespoke auth).
  • Migrating from CLB:
  • Feature parity can differ; validate listener behaviors, timeouts, header handling, and certificates.

14. Comparison with Alternatives

How ALB compares inside Alibaba Cloud

  • Classic Load Balancer (CLB): Older load balancing product; may support some legacy patterns. Often used for existing deployments. Confirm current recommendation status in official docs.
  • Network Load Balancer (NLB): Layer 4 load balancing for TCP/UDP, typically lower overhead and better for non-HTTP protocols.
  • Global Accelerator (GA): Improves global access latency and availability; pairs with regional endpoints like ALB for cross-region acceleration.
  • CDN: Best for caching and edge delivery of static/streaming content; can sit in front of ALB as origin.
  • API Gateway: Adds API management features (auth, throttling, transformations). ALB is not a full API management product.

How ALB compares to other clouds

  • AWS Application Load Balancer (ALB): Similar concept; feature names differ.
  • Azure Application Gateway: Similar L7 load balancing; integrates tightly with Azure VNets and WAF.
  • Google Cloud HTTPS Load Balancer: Global L7 load balancing with different architecture (often global by design).

Self-managed alternatives

  • NGINX/HAProxy/Envoy: Maximum flexibility, but you manage scaling, patching, HA, and observability.

Comparison table

Option Best For Strengths Weaknesses When to Choose
Alibaba Cloud Application Load Balancer (ALB) HTTP/HTTPS apps needing L7 routing Managed, L7 rules, TLS termination, multi-zone Regional scope, feature set depends on region, costs scale with traffic Web/apps/APIs, microservices routing, Kubernetes ingress needs
Alibaba Cloud Network Load Balancer (NLB) TCP/UDP workloads Efficient L4, good for non-HTTP protocols No L7 routing Databases proxies, MQTT, game TCP, custom protocols
Alibaba Cloud Classic Load Balancer (CLB) Legacy deployments Familiar to existing Alibaba Cloud users Legacy positioning; feature parity varies Existing CLB-heavy estates, gradual migration
Alibaba Cloud Global Accelerator (GA) Global users accessing regional apps Improves latency/availability globally Additional service/cost; not a full L7 router by itself Multi-region front door patterns, global performance needs
CDN (Alibaba Cloud CDN) Static content delivery Caching, edge offload Not a general-purpose app router Put in front of ALB to reduce origin load
Self-managed NGINX/HAProxy Custom proxy logic Full control and extensibility You manage HA/scaling/patching Specialized behaviors, bespoke routing, extreme customization

15. Real-World Example

Enterprise example: Internal + external portals with compliance logging

Problem
A large enterprise hosts: – A customer-facing portal (portal.company.com) – An API (api.company.com) – Multiple internal apps for employees
They require TLS enforcement, centralized logging, and clear separation between internal and external entry points.

Proposed architecture – Internet-facing Application Load Balancer (ALB) for external traffic: – HTTPS listener with enterprise certificate – Host-based rules: – portal.company.com → sg-portal – api.company.com → sg-api – Internal-facing ALB for intranet apps: – Private DNS names – Access limited to corporate network via VPN/Express Connect (depending on design) – Backends on ECS/ACK spread across two zones – Logs shipped to Log Service with retention policies and access controls – CloudMonitor alarms integrated to on-call rotation

Why ALB was chosen – L7 routing reduces the number of separate load balancers. – TLS centralized at the edge. – Multi-zone deployment supports high availability. – Operational governance via RAM and audit logs.

Expected outcomes – Reduced downtime due to health-checked backends – Faster certificate rotation and fewer misconfigurations – Improved audit readiness with centralized access logging

Startup/small-team example: One ALB for multiple microservices

Problem
A startup runs 6 microservices and a React frontend. Managing multiple public endpoints is messy, and they want simple routing plus HTTPS.

Proposed architecture – One internet-facing ALB – HTTPS listener with a single wildcard certificate (if appropriate) – Path-based routing: – / → frontend service – /api/auth/* → auth service – /api/payments/* → payments service – /api/* → general API gateway service (or monolith API) – Backends on a small ECS autoscaling group or ACK

Why ALB was chosen – Simplifies DNS and ingress. – Lets them add services by adding rules, not by provisioning new public endpoints. – Reduces time spent managing edge proxy infrastructure.

Expected outcomes – Faster deployments, clearer routing, fewer operational tasks – Ability to scale backends independently behind server groups

16. FAQ

1) Is Application Load Balancer (ALB) the same as Server Load Balancer (SLB)?

Historically, “SLB” was often used as a general term on Alibaba Cloud. Today, Application Load Balancer (ALB) is a specific L7 product, distinct from Classic Load Balancer (CLB) and Network Load Balancer (NLB).

2) Is ALB Layer 4 or Layer 7?

ALB is Layer 7, primarily for HTTP/HTTPS routing. For TCP/UDP, consider NLB.

3) Is ALB regional or global?

ALB is typically regional (deployed in a single region, multi-zone within that region). For global acceleration, consider Global Accelerator and/or CDN patterns.

4) Can ALB route traffic based on hostname and path?

Yes, ALB is designed for L7 routing and commonly supports host- and path-based rules. Confirm the exact rule conditions supported in your region in the official docs.

5) Can I use ALB for internal/private applications?

Yes. Create an internal-facing ALB in a VPC and restrict access via network controls.

6) Does ALB support HTTPS and TLS termination?

Yes. You can configure HTTPS listeners and bind certificates. Certificate sourcing and advanced TLS options vary—verify in official docs.

7) Do I need public IPs on my ECS backends?

No. A recommended design is: public ALB + private backends. Backends can remain private in VPC subnets.

8) How do health checks work?

ALB periodically probes each backend using configured protocol/path/port and only routes to healthy targets. If all targets are unhealthy, ALB will return errors.

9) Why are my backends unhealthy even though the service works locally?

Most common causes: – Security group blocks ALB-to-backend traffic – Wrong health check path (returns 404/500) – Backend listens on a different port – App requires Host header and health check doesn’t match expected host (verify ALB health check header options)

10) Can I do blue/green or canary deployments with ALB?

Often yes via server groups and routing rules (and sometimes weight-based forwarding). Confirm whether weighted routing or header/cookie routing is supported in your ALB version/region.

11) How do I connect a custom domain to ALB?

Create a DNS record (often CNAME) from your domain to the ALB DNS name. For apex domains, you may need ALIAS/ANAME support depending on DNS provider.

12) Does ALB integrate with Kubernetes (ACK)?

Commonly yes through an ALB ingress controller. Verify the current controller name, supported annotations, and feature coverage in the ACK/ALB docs.

13) What are the main cost drivers for ALB?

Instance runtime, capacity/processing units (model varies), public egress, and logging storage/ingestion. Backends (ECS/ACK) are separate costs.

14) How do I monitor ALB?

Use CloudMonitor for metrics and alarms, and enable access logs for request-level troubleshooting.

15) What’s the safest way to operate ALB at scale?

Use: – Infrastructure-as-code – Least-privilege RAM policies – Standard naming/tagging – Change review for listener rules – Multi-zone deployments – Central logging and alarming

17. Top Online Resources to Learn Application Load Balancer (ALB)

Resource Type Name Why It Is Useful
Official documentation Alibaba Cloud ALB Documentation Primary reference for features, limits, configuration steps, and APIs: https://www.alibabacloud.com/help/en/application-load-balancer/
Official product page Alibaba Cloud Application Load Balancer (ALB) Product Page High-level overview, region availability entry points, and pricing access: https://www.alibabacloud.com/product/alb
Official pricing ALB Pricing (via product page) Pricing varies by region and billing mode; use the Pricing tab/section: https://www.alibabacloud.com/product/alb
Pricing tool Alibaba Cloud Pricing Calculator Build estimates across ALB + ECS + EIP + logging: https://www.alibabacloud.com/pricing-calculator
Official docs (RAM) Resource Access Management (RAM) Documentation Learn IAM best practices and policy writing: https://www.alibabacloud.com/help/en/ram/
Official docs (VPC) VPC Documentation Understand VPC/vSwitch design and routing dependencies: https://www.alibabacloud.com/help/en/vpc/
Official docs (ECS) ECS Documentation Backend compute setup and security groups: https://www.alibabacloud.com/help/en/ecs/
Official docs (CloudMonitor) CloudMonitor Documentation Metrics and alarms for operations: https://www.alibabacloud.com/help/en/cloudmonitor/
Official docs (Log Service) Log Service (SLS) Documentation Central logging pipeline and retention/cost controls: https://www.alibabacloud.com/help/en/sls/
Official docs (Certificates) SSL Certificates Service Documentation TLS cert issuance/import and lifecycle: https://www.alibabacloud.com/help/en/ssl-certificate-service/
Official docs (ActionTrail) ActionTrail Documentation Audit trail for control-plane changes: https://www.alibabacloud.com/help/en/actiontrail/
Community learning Alibaba Cloud Community Practical posts and patterns; validate against official docs: https://www.alibabacloud.com/blog/ and https://www.alibabacloud.com/community
Video learning Alibaba Cloud YouTube Channel Recorded webinars and demos (availability varies): https://www.youtube.com/@AlibabaCloud

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website
DevOpsSchool.com DevOps engineers, SREs, platform teams DevOps/cloud fundamentals, deployment and operations practices that can include load balancing Check website https://www.devopsschool.com/
ScmGalaxy.com Beginners to intermediate engineers SCM/DevOps tooling and practical labs that may include cloud networking Check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud ops practitioners Operations, monitoring, automation practices (verify Alibaba Cloud coverage on site) Check website https://www.cloudopsnow.in/
SreSchool.com SREs, reliability-focused engineers SRE practices: SLOs, incident response, monitoring (applies to ALB operations) Check website https://www.sreschool.com/
AiOpsSchool.com Ops teams exploring AIOps Observability, automation, AIOps concepts (useful for ALB monitoring/log analysis) Check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website
RajeshKumar.xyz DevOps/cloud training content (verify exact offerings) Students, engineers looking for practical guidance https://www.rajeshkumar.xyz/
devopstrainer.in DevOps training platform (verify Alibaba Cloud coverage) Beginners to intermediate DevOps learners https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps expertise marketplace/platform (verify services) Teams needing short-term DevOps support https://www.devopsfreelancer.com/
devopssupport.in DevOps support/training resource (verify exact offerings) Ops teams seeking troubleshooting help https://www.devopssupport.in/

20. Top Consulting Companies

Company Likely Service Area Where They May Help Consulting Use Case Examples Website
cotocus.com Cloud/DevOps consulting (verify service catalog) Architecture reviews, migrations, automation ALB/ingress design, HA reviews, cost optimization workshops https://cotocus.com/
DevOpsSchool.com DevOps consulting and training Implementation and enablement Standardizing ALB patterns, CI/CD integration, monitoring/runbooks https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting (verify service catalog) Delivery acceleration and operations Setting up ALB + observability + security baselines for production https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

To use Alibaba Cloud Application Load Balancer (ALB) effectively, learn: – Networking basics: IPs, CIDR, subnets, routing, DNS – HTTP/HTTPS fundamentals: headers, status codes, TLS basics – Alibaba Cloud VPC fundamentals: VPC, vSwitch, security groups – Compute basics: ECS instances, images, basic Linux operations – Observability basics: metrics vs logs, basic troubleshooting

What to learn after this service

To level up beyond a basic ALB deployment: – Network Load Balancer (NLB) vs ALB selection for mixed workloads – Kubernetes ingress on ACK with ALB ingress controller – Zero-downtime deployment strategies (blue/green, canary) – Centralized logging with Log Service (SLS) and alerting pipelines – Security hardening with WAF, TLS policy enforcement, and IAM governance – Infrastructure as Code (Terraform) for repeatable ALB patterns

Job roles that use it

  • Cloud Engineer
  • DevOps Engineer
  • Site Reliability Engineer (SRE)
  • Platform Engineer
  • Network/Cloud Network Engineer
  • Solutions Architect
  • Security Engineer (for TLS, exposure boundaries, logging/audit)

Certification path (if available)

Alibaba Cloud certifications evolve over time and vary by region. Check the Alibaba Cloud certification portal for the latest tracks that cover networking/load balancing. (Verify in official Alibaba Cloud training/certification pages for current offerings.)

Project ideas for practice

  1. Multi-service routing: host + path routing to 3 microservices
  2. HTTPS everywhere: HTTP→HTTPS redirect, certificate rotation exercise
  3. Multi-zone resilience test: simulate one backend/zone outage and measure impact
  4. Observability setup: CloudMonitor alarms + log dashboards in SLS
  5. Kubernetes ingress: route multiple services with ALB ingress controller (verify annotations/features)
  6. Cost optimization: compare ALB+CDN vs ALB-only for static-heavy workloads

22. Glossary

  • ALB (Application Load Balancer): Managed Layer 7 load balancer for HTTP/HTTPS on Alibaba Cloud.
  • Listener: A protocol/port configuration on ALB that receives client connections.
  • Listener rule: A match-and-forward rule (e.g., host/path) that routes traffic to a server group.
  • Server group: A logical group of backend targets (instances/IPs) that receive traffic.
  • Backend target: A server endpoint (e.g., ECS instance on port 80) registered in a server group.
  • Health check: Periodic probe to determine whether a backend should receive traffic.
  • VPC (Virtual Private Cloud): Your isolated network in Alibaba Cloud.
  • vSwitch: A subnet within a VPC, tied to a specific zone.
  • Zone: An isolated location within a region. Multi-zone designs increase availability.
  • EIP (Elastic IP Address): Public IP resource used for internet access in many Alibaba Cloud designs.
  • TLS termination: Decrypting HTTPS at the load balancer so backends can receive HTTP (or re-encrypted HTTPS).
  • CloudMonitor: Alibaba Cloud monitoring service for metrics and alarms.
  • Log Service (SLS): Alibaba Cloud log ingestion, storage, and analytics platform.
  • RAM (Resource Access Management): Alibaba Cloud IAM for users, roles, and permissions.
  • ActionTrail: Alibaba Cloud service for auditing API actions (control-plane events).
  • Ingress: Kubernetes concept for routing external traffic to services; can be implemented using ALB.

23. Summary

Application Load Balancer (ALB) in Alibaba Cloud (Networking and CDN) is a managed Layer 7 load balancer for HTTP/HTTPS applications. It provides a stable entry point, health-checked backend distribution, TLS termination, and rule-based routing—making it a strong fit for web apps, APIs, and microservices.

Where it fits: ALB is the standard L7 front door inside a region, typically paired with VPC, ECS/ACK backends, CloudMonitor, and centralized logging. For TCP/UDP, use NLB; for global acceleration, use GA/CDN patterns.

Key cost/security points: – Cost scales with runtime, capacity/traffic, egress, and logging. – Security improves when ALB is the only public endpoint and backends remain private with least-privilege RAM, HTTPS, and auditing.

When to use it: choose ALB when you need HTTP/HTTPS routing, TLS, and multi-service ingress in a regional architecture. Next step: implement HTTPS, access logs, CloudMonitor alarms, and (if applicable) Kubernetes ingress patterns using the official Alibaba Cloud documentation for your region.