{"id":34,"date":"2026-04-12T14:37:18","date_gmt":"2026-04-12T14:37:18","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/alibaba-cloud-application-load-balancer-alb-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-cdn\/"},"modified":"2026-04-12T14:37:18","modified_gmt":"2026-04-12T14:37:18","slug":"alibaba-cloud-application-load-balancer-alb-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-cdn","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/alibaba-cloud-application-load-balancer-alb-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-cdn\/","title":{"rendered":"Alibaba Cloud Application Load Balancer (ALB) Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking and CDN"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking and CDN<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Application Load Balancer (ALB) on <strong>Alibaba Cloud<\/strong> 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.<\/p>\n\n\n\n<p>In simple terms: <strong>ALB gives your application a stable entry point<\/strong> (a DNS name and optional public endpoint) and <strong>spreads traffic across multiple servers<\/strong> so you get better availability, scalability, and safer deployments.<\/p>\n\n\n\n<p>Technically, <strong>Application Load Balancer (ALB)<\/strong> provides L7 capabilities such as host\/path-based routing, TLS termination, listener rules, server groups, and health checks inside an Alibaba Cloud <strong>VPC<\/strong>. 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\u2014verify in official docs).<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<blockquote>\n<p>Naming and service positioning note (important): Alibaba Cloud historically used <strong>Server Load Balancer (SLB)<\/strong> as an umbrella concept. Today, load balancing on Alibaba Cloud typically includes <strong>Classic Load Balancer (CLB)<\/strong> (legacy), <strong>Network Load Balancer (NLB)<\/strong> (Layer 4), and <strong>Application Load Balancer (ALB)<\/strong> (Layer 7). This tutorial focuses strictly on <strong>Application Load Balancer (ALB)<\/strong>.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Application Load Balancer (ALB)?<\/h2>\n\n\n\n<p><strong>Official purpose (what ALB is for)<\/strong><br\/>\nApplication Load Balancer (ALB) is Alibaba Cloud\u2019s managed <strong>application-layer<\/strong> 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.<\/p>\n\n\n\n<p><strong>Core capabilities (what it can do)<\/strong>\n&#8211; Distribute HTTP\/HTTPS traffic to backend targets using <strong>server groups<\/strong>\n&#8211; Perform <strong>health checks<\/strong> and only send traffic to healthy backends\n&#8211; Support <strong>advanced routing<\/strong> through listener rules (for example, forwarding based on host or URL path)\n&#8211; Terminate <strong>TLS\/SSL<\/strong> at the load balancer and optionally re-encrypt to backends\n&#8211; Provide <strong>high availability<\/strong> through multi-zone deployment (within a region)\n&#8211; Integrate with Alibaba Cloud networking, compute, and observability tooling<\/p>\n\n\n\n<p><strong>Major components (what you configure)<\/strong>\n&#8211; <strong>ALB instance<\/strong>: The load balancer resource that provides a service endpoint (DNS name) and runs in a VPC.\n&#8211; <strong>Listeners<\/strong>: Protocol\/port configurations (e.g., HTTP:80, HTTPS:443) that define how ALB receives traffic.\n&#8211; <strong>Listener rules<\/strong>: Matching conditions (host, path, headers, etc.) and forwarding actions to route traffic.\n&#8211; <strong>Server groups<\/strong>: Collections of backend targets (ECS instances, IP targets, or other supported target types\u2014verify exact target types per region\/version in official docs).\n&#8211; <strong>Health checks<\/strong>: Probes used to determine backend health.\n&#8211; <strong>Certificates<\/strong> (for HTTPS): TLS certs associated with HTTPS listeners.<\/p>\n\n\n\n<p><strong>Service type<\/strong>\n&#8211; Fully managed <strong>Layer 7 (application-layer) load balancer<\/strong>.\n&#8211; Operates inside <strong>Alibaba Cloud Networking and CDN<\/strong> domain as an application entry-point component.<\/p>\n\n\n\n<p><strong>Scope (regional\/global\/zonal\/account)<\/strong>\n&#8211; <strong>Regional<\/strong>: An ALB instance is created in a specific region and attached to VPC subnets (vSwitches) in one or more zones within that region.\n&#8211; <strong>Multi-zone within a region<\/strong>: Typically you attach at least two vSwitches in different zones for resilience.\n&#8211; <strong>Account-scoped resource<\/strong>: Created and billed in your Alibaba Cloud account (and controlled through RAM).<\/p>\n\n\n\n<p><strong>How ALB fits into the Alibaba Cloud ecosystem<\/strong>\nALB is commonly paired with:\n&#8211; <strong>ECS<\/strong> (Elastic Compute Service) for VM-based backends\n&#8211; <strong>ACK<\/strong> (Alibaba Cloud Container Service for Kubernetes) for ingress\/traffic routing to Kubernetes workloads (via an ALB Ingress Controller\u2014verify the current controller name and capabilities in official docs)\n&#8211; <strong>VPC<\/strong>, <strong>vSwitch<\/strong>, <strong>Security Groups<\/strong>, <strong>EIP<\/strong> for networking\n&#8211; <strong>CloudMonitor<\/strong> for metrics\/alarms\n&#8211; <strong>Log Service (SLS)<\/strong> and\/or <strong>OSS<\/strong> for logs (verify exact logging destinations supported for ALB in your region)\n&#8211; <strong>Certificate Management Service<\/strong> (SSL Certificates) for HTTPS certificates\n&#8211; Optional security services such as <strong>WAF<\/strong> in front of ALB or integrated depending on product capabilities and region (verify in official docs)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Application Load Balancer (ALB)?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Higher availability<\/strong>: A single server outage should not take down your website\/API.<\/li>\n<li><strong>Faster delivery<\/strong>: You can deploy new versions behind ALB using canary\/blue-green patterns with minimal disruption.<\/li>\n<li><strong>Simplified operations<\/strong>: Avoid running and patching your own L7 proxies at scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Layer 7 routing<\/strong>: Route traffic by hostname (<code>api.example.com<\/code> vs <code>www.example.com<\/code>) and by path (<code>\/v1\/*<\/code> vs <code>\/v2\/*<\/code>).<\/li>\n<li><strong>TLS offload<\/strong>: Centralize certificate management and reduce CPU load on backends.<\/li>\n<li><strong>Health-based forwarding<\/strong>: ALB automatically removes unhealthy targets from rotation.<\/li>\n<li><strong>Scalable front door<\/strong>: ALB is designed to scale with traffic demand (exact scaling behavior varies\u2014verify in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardized ingress pattern<\/strong>: Teams can consistently onboard services behind ALB.<\/li>\n<li><strong>Observability<\/strong>: Centralized metrics and logs can simplify troubleshooting and SLO reporting.<\/li>\n<li><strong>Safer change management<\/strong>: Rules and server groups reduce the need for frequent DNS changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduced exposure<\/strong>: Keep backends private in VPC; expose only ALB publicly.<\/li>\n<li><strong>Centralized TLS policy<\/strong>: Enforce strong ciphers\/TLS versions at the edge (options vary\u2014verify in official docs).<\/li>\n<li><strong>IAM governance<\/strong>: RAM policies can restrict who can modify listeners, rules, and backend targets.<\/li>\n<li><strong>Auditability<\/strong>: Use ActionTrail for API audit logs (verify service support and event coverage).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Connection management<\/strong>: ALB handles client connections and can reuse connections to backends depending on configuration.<\/li>\n<li><strong>Horizontal scaling<\/strong>: Add\/remove backend targets without changing client endpoints.<\/li>\n<li><strong>Multi-zone design<\/strong>: Better resilience to zone-level faults.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose ALB<\/h3>\n\n\n\n<p>Choose <strong>Application Load Balancer (ALB)<\/strong> when you need:\n&#8211; HTTP\/HTTPS entry point\n&#8211; Host\/path-based routing and multiple services behind one IP\/DNS\n&#8211; TLS termination and certificate management\n&#8211; Web apps, APIs, microservices, or Kubernetes ingress<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose ALB<\/h3>\n\n\n\n<p>Avoid ALB (or consider alternatives) when:\n&#8211; You need <strong>Layer 4<\/strong> TCP\/UDP pass-through with minimal L7 features (consider <strong>Network Load Balancer (NLB)<\/strong>).\n&#8211; You are running legacy architectures that depend on CLB-specific features or existing CLB operational patterns (consider <strong>Classic Load Balancer (CLB)<\/strong>, but treat it as legacy where applicable).\n&#8211; You need <strong>global anycast<\/strong> or cross-region acceleration (consider <strong>Global Accelerator<\/strong> and\/or CDN depending on use case).\n&#8211; Your traffic is not HTTP\/HTTPS (ALB is L7; non-HTTP workloads typically don\u2019t fit).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Application Load Balancer (ALB) used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and internet platforms (web apps, APIs)<\/li>\n<li>E-commerce (high availability storefronts, checkout APIs)<\/li>\n<li>FinTech (API gateways behind controlled entry points)<\/li>\n<li>Media and content platforms (origin routing to multiple services)<\/li>\n<li>Enterprise IT (internal apps, portals, shared services)<\/li>\n<li>Gaming backends (HTTP APIs and admin consoles)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building standardized ingress<\/li>\n<li>DevOps\/SRE teams managing reliability and scaling<\/li>\n<li>Application teams deploying multiple microservices<\/li>\n<li>Security teams enforcing TLS and exposure boundaries<\/li>\n<li>Network teams standardizing VPC ingress\/egress patterns<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>REST\/GraphQL APIs<\/li>\n<li>Web frontends<\/li>\n<li>Microservices with multiple routes<\/li>\n<li>Internal admin portals (intranet ALB)<\/li>\n<li>CI\/CD preview environments (one ALB, many routes)<\/li>\n<li>Kubernetes ingress for services<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Three-tier web apps (ALB \u2192 app tier \u2192 database tier)<\/li>\n<li>Microservices (ALB \u2192 services based on path\/host)<\/li>\n<li>Shared ingress with multiple environments (e.g., <code>dev.*<\/code>, <code>prod.*<\/code> separated by rules)<\/li>\n<li>Zero-trust-ish patterns where only ALB is exposed and backends are private<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Multi-zone, strict TLS policies, access logging, alarms, controlled IAM, runbooks.<\/li>\n<li><strong>Dev\/test<\/strong>: Smaller backend pools, fewer rules, relaxed logging, but still useful for realistic traffic routing and release testing.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic ways teams use <strong>Application Load Balancer (ALB)<\/strong> on Alibaba Cloud.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Host-based routing for multi-domain SaaS<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You host multiple customer domains or subdomains on the same platform.<\/li>\n<li><strong>Why ALB fits<\/strong>: Listener rules can route by <code>Host<\/code> header to different server groups.<\/li>\n<li><strong>Example<\/strong>: <code>tenant-a.example.com<\/code> \u2192 server group A, <code>tenant-b.example.com<\/code> \u2192 server group B.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Path-based routing for microservices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Multiple services share one public endpoint.<\/li>\n<li><strong>Why ALB fits<\/strong>: Route by path prefixes.<\/li>\n<li><strong>Example<\/strong>: <code>\/api\/*<\/code> \u2192 API service; <code>\/static\/*<\/code> \u2192 static service; <code>\/admin\/*<\/code> \u2192 admin service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) TLS termination and certificate centralization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Managing certificates on many backend servers is error-prone.<\/li>\n<li><strong>Why ALB fits<\/strong>: Terminate HTTPS at ALB; rotate certificates centrally.<\/li>\n<li><strong>Example<\/strong>: ALB uses a managed certificate; backends run plain HTTP inside VPC.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Blue\/green deployment with weighted split (if supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Need to release a new version with controlled traffic.<\/li>\n<li><strong>Why ALB fits<\/strong>: Some L7 load balancers support splitting traffic between server groups by weight (verify ALB support in official docs).<\/li>\n<li><strong>Example<\/strong>: Route 90% to v1 server group, 10% to v2.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Canary releases by header or cookie routing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Target QA users or internal testers without changing DNS.<\/li>\n<li><strong>Why ALB fits<\/strong>: Advanced rules can match headers\/cookies (verify available match types).<\/li>\n<li><strong>Example<\/strong>: If header <code>X-Canary: true<\/code> then forward to canary server group.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Intranet application gateway for enterprise apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Internal apps need a consistent entry point inside the VPC.<\/li>\n<li><strong>Why ALB fits<\/strong>: Internal-facing ALB provides private DNS endpoint and controlled routing.<\/li>\n<li><strong>Example<\/strong>: HR portal and internal API behind a private ALB.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Kubernetes ingress for services on ACK<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Need managed ingress routing to Kubernetes services.<\/li>\n<li><strong>Why ALB fits<\/strong>: ALB can act as ingress (through an ALB Ingress Controller\u2014verify the current supported controller and features).<\/li>\n<li><strong>Example<\/strong>: One ALB routes <code>\/svc-a<\/code> to Service A and <code>\/svc-b<\/code> to Service B.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Centralized access logging for compliance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Compliance needs request logs (source IP, request path, status).<\/li>\n<li><strong>Why ALB fits<\/strong>: ALB can emit access logs to centralized storage\/log analytics (verify exact options).<\/li>\n<li><strong>Example<\/strong>: Send logs to Log Service (SLS) and build dashboards\/alerts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) HTTP to HTTPS redirects<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Enforce secure transport for all users.<\/li>\n<li><strong>Why ALB fits<\/strong>: Listener actions can redirect HTTP to HTTPS (verify redirect configuration).<\/li>\n<li><strong>Example<\/strong>: Port 80 listener returns 301 to <code>https:\/\/$host$request_uri<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Multi-zone resiliency for web entry points<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Zone failures cause downtime if all backends are in one zone.<\/li>\n<li><strong>Why ALB fits<\/strong>: Deploy ALB across multiple zones and register backends in multiple zones.<\/li>\n<li><strong>Example<\/strong>: Backends in Zone A and Zone B; ALB continues routing if one zone fails.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) API front door for rate-limited backends (partial)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Prevent backend overload from spikes.<\/li>\n<li><strong>Why ALB fits<\/strong>: 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\u2019s native throttling features, if any).<\/li>\n<li><strong>Example<\/strong>: ALB forwards to API Gateway or WAF enforces policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Migration off self-managed reverse proxies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You maintain HAProxy\/NGINX fleets for load balancing.<\/li>\n<li><strong>Why ALB fits<\/strong>: Offload patching, scaling, and HA of the L7 edge.<\/li>\n<li><strong>Example<\/strong>: Replace NGINX edge nodes with ALB; keep NGINX only for app-level concerns if needed.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section lists important <strong>current<\/strong> ALB feature areas. Exact availability can vary by region and account settings\u2014<strong>verify in official docs<\/strong> for the newest options.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Layer 7 HTTP\/HTTPS load balancing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Distributes application-layer traffic across backend targets.<\/li>\n<li><strong>Why it matters<\/strong>: Enables web- and API-specific behaviors (routing, TLS termination).<\/li>\n<li><strong>Practical benefit<\/strong>: One stable endpoint for many services.<\/li>\n<li><strong>Caveat<\/strong>: ALB is primarily for HTTP\/HTTPS; non-HTTP protocols typically require NLB\/CLB.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Listeners (HTTP and HTTPS)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Defines ports\/protocols and how ALB accepts connections.<\/li>\n<li><strong>Why it matters<\/strong>: Separates ingress concerns per protocol.<\/li>\n<li><strong>Benefit<\/strong>: Run HTTP:80 and HTTPS:443 with different policies.<\/li>\n<li><strong>Caveat<\/strong>: Listener limits exist (verify quotas).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Listener rules and routing conditions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Matches requests and routes them to specific server groups.<\/li>\n<li><strong>Why it matters<\/strong>: Enables microservices and multi-site hosting without extra load balancers.<\/li>\n<li><strong>Benefit<\/strong>: Clear separation of routing logic from application code.<\/li>\n<li><strong>Caveat<\/strong>: The set of match conditions (host\/path\/header\/query\/cookie) varies\u2014verify supported match types.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Server groups (backend target groups)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Defines pools of backends receiving traffic.<\/li>\n<li><strong>Why it matters<\/strong>: Lets you attach\/detach targets without changing the frontend endpoint.<\/li>\n<li><strong>Benefit<\/strong>: Simplifies scaling and maintenance.<\/li>\n<li><strong>Caveat<\/strong>: Supported backend types and max targets per group can vary (verify in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 Health checks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Periodically probes backends to determine whether they should receive traffic.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents routing to broken instances.<\/li>\n<li><strong>Benefit<\/strong>: Automatic failover at the load balancing layer.<\/li>\n<li><strong>Caveat<\/strong>: Misconfigured health checks are a common cause of outages (wrong path, security group blocks).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 Session persistence (sticky sessions)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Keeps a client\u2019s requests going to the same backend for a period (typically cookie-based for HTTP\/HTTPS).<\/li>\n<li><strong>Why it matters<\/strong>: Some apps require stateful sessions.<\/li>\n<li><strong>Benefit<\/strong>: Reduces app refactoring pressure during migrations.<\/li>\n<li><strong>Caveat<\/strong>: Stickiness can reduce load distribution and complicate deployments; prefer stateless apps where possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 TLS termination and certificate management<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Terminates HTTPS at ALB and uses configured certificates (often from Alibaba Cloud certificate services).<\/li>\n<li><strong>Why it matters<\/strong>: Central point to manage certificates and enforce TLS policies.<\/li>\n<li><strong>Benefit<\/strong>: Simplified rotation and consistent encryption posture.<\/li>\n<li><strong>Caveat<\/strong>: Mutual TLS (mTLS) and advanced TLS features depend on ALB support\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 HTTP\/2 support (if available)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows clients to use HTTP\/2 to the load balancer for improved performance.<\/li>\n<li><strong>Why it matters<\/strong>: Better multiplexing and latency, especially for web apps.<\/li>\n<li><strong>Benefit<\/strong>: Potential performance improvement without changing backends.<\/li>\n<li><strong>Caveat<\/strong>: Confirm support and configuration requirements in your region (verify in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.9 Access logging (observability)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Emits request logs for analytics and troubleshooting.<\/li>\n<li><strong>Why it matters<\/strong>: Essential for debugging 4xx\/5xx, latency, and security investigations.<\/li>\n<li><strong>Benefit<\/strong>: Central source of truth at the edge.<\/li>\n<li><strong>Caveat<\/strong>: Logging destinations and formats vary; storage\/ingestion adds cost (verify destinations such as Log Service or OSS).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.10 Metrics and alarms (CloudMonitor)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides operational metrics (connections, QPS, latency, errors).<\/li>\n<li><strong>Why it matters<\/strong>: Enables SLO monitoring and alerting.<\/li>\n<li><strong>Benefit<\/strong>: Faster detection of incidents.<\/li>\n<li><strong>Caveat<\/strong>: High-cardinality analytics may require log-based analysis rather than metrics alone.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.11 High availability within a region (multi-zone)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: ALB can be deployed across multiple zones using multiple vSwitches.<\/li>\n<li><strong>Why it matters<\/strong>: Zone-level resilience.<\/li>\n<li><strong>Benefit<\/strong>: Improved uptime and reduced blast radius.<\/li>\n<li><strong>Caveat<\/strong>: Requires you to also place backends across zones and handle data tier HA.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.12 Integration with Alibaba Cloud RAM and governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses RAM for access control and supports tagging for governance.<\/li>\n<li><strong>Why it matters<\/strong>: Enforces least privilege and operational ownership.<\/li>\n<li><strong>Benefit<\/strong>: Safer operations at scale.<\/li>\n<li><strong>Caveat<\/strong>: Fine-grained resource-level policies require careful testing.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At runtime, ALB acts as the entry point:\n1. A client resolves the ALB DNS name (or your custom domain CNAME).\n2. Client connects to ALB listener (HTTP\/HTTPS).\n3. ALB evaluates listener rules to select a server group.\n4. ALB performs health-aware load balancing to a backend target.\n5. Response returns through ALB to the client.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Data plane<\/strong>: Client \u2194 ALB \u2194 Backend.<\/li>\n<li><strong>Control plane<\/strong>: You configure ALB instances, listeners, rules, server groups via Console, API, SDK, or CLI; changes propagate to ALB.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>VPC\/vSwitch<\/strong>: ALB lives in your VPC and attaches to vSwitches (subnets).\n&#8211; <strong>EIP<\/strong>: For internet-facing ALB, you typically associate public connectivity (EIP or managed public addressing depending on ALB type\/region\u2014verify in docs).\n&#8211; <strong>ECS<\/strong>: Backends often run on ECS instances in private subnets.\n&#8211; <strong>ACK (Kubernetes)<\/strong>: ALB used as ingress controller front end (verify current controller).\n&#8211; <strong>Certificate Management Service<\/strong>: Upload\/issue and bind certs to HTTPS listeners.\n&#8211; <strong>CloudMonitor<\/strong>: Metrics and alarms.\n&#8211; <strong>Log Service (SLS) \/ OSS<\/strong>: Access logs and storage\/analysis (verify exact support).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services (what you usually need)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VPC + vSwitches in at least two zones (recommended for production)<\/li>\n<li>Backends (ECS\/containers) reachable from ALB subnets<\/li>\n<li>Security groups\/NACLs allowing ALB-to-backend traffic<\/li>\n<li>DNS (Alibaba Cloud DNS or external) for custom domain mapping<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Management-plane access<\/strong>: Controlled via <strong>RAM users\/roles<\/strong> and policies.<\/li>\n<li><strong>Traffic security<\/strong>: TLS termination for HTTPS; backend security via VPC isolation and security groups.<\/li>\n<li><strong>Auditability<\/strong>: Use <strong>ActionTrail<\/strong> for tracking API actions (verify coverage for ALB operations).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>ALB attaches to one or more <strong>vSwitches<\/strong> within a VPC.<\/li>\n<li>Backends are typically private IPs in the same VPC (or reachable through VPC connectivity such as peering\/CEN\u2014verify supported patterns).<\/li>\n<li>For internet access, ALB is configured as internet-facing; for internal apps, it is internal-facing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable CloudMonitor alarms (latency, 5xx, unhealthy backends).<\/li>\n<li>Enable access logs for troubleshooting and security analytics.<\/li>\n<li>Use tags and naming conventions to separate environments and owners.<\/li>\n<li>Track configuration changes with ActionTrail and change-management processes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User Browser \/ API Client] --&gt; DNS[DNS: app.example.com]\n  DNS --&gt; ALB[Alibaba Cloud Application Load Balancer (ALB)\\nHTTP\/HTTPS Listener]\n  ALB --&gt; SG[Server Group]\n  SG --&gt; ECS1[ECS Backend 1\\n(Private IP)]\n  SG --&gt; ECS2[ECS Backend 2\\n(Private IP)]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Internet[Internet]\n    Client[Clients]\n  end\n\n  subgraph Region[Alibaba Cloud Region]\n    subgraph VPC[VPC]\n      subgraph ZoneA[Zone A]\n        VSWA[vSwitch A]\n        ECS_A1[ECS \/ Pod Backend A1]\n        ECS_A2[ECS \/ Pod Backend A2]\n      end\n\n      subgraph ZoneB[Zone B]\n        VSWB[vSwitch B]\n        ECS_B1[ECS \/ Pod Backend B1]\n        ECS_B2[ECS \/ Pod Backend B2]\n      end\n\n      ALB[Application Load Balancer (ALB)\\nMulti-zone\\nHTTPS Listener + Rules]\n      SG1[Server Group: web]\n      SG2[Server Group: api]\n\n      ALB --&gt; SG1\n      ALB --&gt; SG2\n\n      SG1 --&gt; ECS_A1\n      SG1 --&gt; ECS_B1\n      SG2 --&gt; ECS_A2\n      SG2 --&gt; ECS_B2\n    end\n\n    Logs[Log Service (SLS) \/ OSS\\nAccess Logs]\n    Mon[CloudMonitor\\nMetrics &amp; Alarms]\n    Certs[Certificate Mgmt\\nSSL\/TLS Certificates]\n  end\n\n  Client --&gt;|HTTPS 443| ALB\n  ALB --&gt; Logs\n  ALB --&gt; Mon\n  Certs --&gt; ALB\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before you start the hands-on lab, ensure you have:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Account and billing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Alibaba Cloud account<\/strong> with billing enabled (Pay-As-You-Go or subscription depending on your org model).<\/li>\n<li>Sufficient quota to create:<\/li>\n<li>VPC, vSwitches<\/li>\n<li>ECS instances<\/li>\n<li>Application Load Balancer (ALB) instance<\/li>\n<li>Elastic IP (EIP) if creating an internet-facing endpoint (region-specific\u2014verify ALB public connectivity model)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions (RAM \/ IAM)<\/h3>\n\n\n\n<p>Use a <strong>RAM user<\/strong> or RAM role with least privilege. For a lab, you may temporarily use broad policies, then tighten later.<\/p>\n\n\n\n<p>Typical policies (names can vary by partition and time\u2014verify in Alibaba Cloud policy reference):\n&#8211; ALB management (e.g., <code>AliyunALBFullAccess<\/code> or equivalent)\n&#8211; ECS management (e.g., <code>AliyunECSFullAccess<\/code>)\n&#8211; VPC management (e.g., <code>AliyunVPCFullAccess<\/code>)\n&#8211; CloudMonitor read\/alarms (optional)\n&#8211; Certificate service access if configuring HTTPS (optional)<\/p>\n\n\n\n<p>Also ensure you can:\n&#8211; Create and manage security groups\n&#8211; Attach backends to server groups<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools (optional but helpful)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Alibaba Cloud Console (browser)<\/li>\n<li><code>curl<\/code> for testing<\/li>\n<li>Optional: <strong>Alibaba Cloud CLI (<code>aliyun<\/code>)<\/strong> if you prefer automation (verify the latest CLI commands for ALB; they can change)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Choose a region where <strong>Application Load Balancer (ALB)<\/strong> is available.<\/li>\n<li>Confirm multi-zone availability (at least two zones) for best practice.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas \/ limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits for number of ALB instances, listeners, rules, server groups, and targets exist.<\/li>\n<li>For production planning, confirm quotas in the official docs and request quota increases if needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VPC<\/strong> and <strong>vSwitches<\/strong><\/li>\n<li><strong>ECS<\/strong> (or ACK) for backend targets<\/li>\n<li><strong>Security groups<\/strong> allowing ALB-to-backend traffic<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Alibaba Cloud pricing for <strong>Application Load Balancer (ALB)<\/strong> is usage-based and region-dependent. You should always validate current rates in your target region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing sources (use these)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Product page (includes pricing entry points): https:\/\/www.alibabacloud.com\/product\/alb  <\/li>\n<li>Pricing calculator (if available in your account\/locale): https:\/\/www.alibabacloud.com\/pricing-calculator  <\/li>\n<li>Official documentation landing page: https:\/\/www.alibabacloud.com\/help\/en\/application-load-balancer\/<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>If the pricing model shown in your console differs from the public site, follow what your console shows for your billing account and region.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (common patterns)<\/h3>\n\n\n\n<p>While exact line items differ by region and billing mode, ALB pricing commonly includes some combination of:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>ALB instance-hours<\/strong><br\/>\n   &#8211; You pay for the load balancer instance running time.<\/p>\n<\/li>\n<li>\n<p><strong>Capacity-based usage<\/strong><br\/>\n   &#8211; Many modern L7 load balancers bill on capacity\/throughput units (similar in concept to an LCU).<br\/>\n   &#8211; This can be based on new connections, active connections, processed bytes, and\/or rule evaluations.<br\/>\n   &#8211; <strong>Verify the specific capacity measurement used by Alibaba Cloud ALB in your region<\/strong>.<\/p>\n<\/li>\n<li>\n<p><strong>Network charges<\/strong>\n   &#8211; <strong>Public data transfer out<\/strong> to the internet is typically billed.\n   &#8211; If using <strong>EIP<\/strong>, EIP billing and bandwidth plans can add cost.\n   &#8211; Intra-VPC traffic is often cheaper than internet egress, but still validate your network billing rules.<\/p>\n<\/li>\n<li>\n<p><strong>Optional features<\/strong>\n   &#8211; <strong>HTTPS certificates<\/strong> (if purchased through Alibaba Cloud) may have separate costs.\n   &#8211; <strong>Logging<\/strong> (Log Service ingestion + storage, or OSS storage) adds cost.\n   &#8211; <strong>WAF<\/strong> (if used) adds cost.\n   &#8211; <strong>Backends<\/strong> (ECS, disks, snapshots) are separate and often dominate total cost.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (what increases your bill)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>High request rate (RPS\/QPS) and throughput<\/li>\n<li>Large responses (e.g., file downloads)<\/li>\n<li>Many rules and complex routing (can increase processing)<\/li>\n<li>Public internet egress<\/li>\n<li>High volume access logs stored for long retention<\/li>\n<li>Over-provisioned backend compute due to poor autoscaling<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs to plan for<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>ECS<\/strong> costs: instances, system disks, data disks<\/li>\n<li><strong>OSS\/SLS<\/strong> logging storage and analytics queries<\/li>\n<li><strong>NAT Gateway<\/strong> costs if private instances need outbound internet (for patching, package downloads)<\/li>\n<li><strong>Cross-zone traffic<\/strong> implications (depends on Alibaba Cloud billing rules\u2014verify in docs for your region)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use ALB only where L7 features are needed; use <strong>NLB<\/strong> for pure TCP\/UDP.<\/li>\n<li>Keep responses small (compression at app layer, caching via CDN when appropriate).<\/li>\n<li>Turn on access logs with a sensible retention period; archive to OSS if needed.<\/li>\n<li>Use autoscaling for backends so you don\u2019t keep excess ECS instances running.<\/li>\n<li>Use internal ALB for internal services; avoid unnecessary internet egress.<\/li>\n<li>Consider CDN in front of ALB for cacheable content to reduce origin traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated numbers)<\/h3>\n\n\n\n<p>A minimal lab environment typically includes:\n&#8211; 1 ALB instance (pay-as-you-go)\n&#8211; 2 small ECS instances\n&#8211; Optional EIP\/public endpoint\n&#8211; Minimal logging<\/p>\n\n\n\n<p>Because <strong>ALB and network egress pricing varies by region and account<\/strong>, do this to estimate safely:\n1. Open the <strong>pricing calculator<\/strong>.\n2. Add ALB (region), set expected hours, and modest traffic assumptions.\n3. Add ECS and EIP\/bandwidth if used.\n4. Add log ingestion\/storage if enabling access logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, plan and model:\n&#8211; Peak and sustained RPS and Mbps\/Gbps\n&#8211; TLS handshake rates (certificate and cipher choices affect CPU\/latency)\n&#8211; Log volume: requests\/day \u00d7 log line size \u00d7 retention\n&#8211; Egress and CDN offload strategy\n&#8211; Multi-environment separation (prod\/stage\/dev) and whether each needs its own ALB<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab builds a simple, realistic setup:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Two ECS instances running NGINX<\/li>\n<li>One ALB instance forwarding HTTP traffic to those ECS backends<\/li>\n<li>A path-based rule to demonstrate L7 routing<\/li>\n<li>Validation with <code>curl<\/code><\/li>\n<li>Safe cleanup steps<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy <strong>Application Load Balancer (ALB)<\/strong> 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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create networking (VPC + 2 vSwitches in different zones recommended)\n2. Create two ECS backends with a simple web page\n3. Create a server group and register the ECS instances\n4. Create an ALB instance and an HTTP listener\n5. Add routing rules and validate behavior\n6. Troubleshoot common issues\n7. Clean up<\/p>\n\n\n\n<blockquote>\n<p>Notes:\n&#8211; The exact Alibaba Cloud Console wording can change. Use the closest matching fields.\n&#8211; If you prefer Infrastructure as Code (Terraform), use the official Alibaba Cloud Terraform provider docs (verify current resource names).<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create a VPC and two vSwitches (recommended)<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Provide a private network environment for ALB and ECS.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the Alibaba Cloud Console, go to <strong>VPC<\/strong>.<\/li>\n<li>Create a <strong>VPC<\/strong>:\n   &#8211; Name: <code>lab-alb-vpc<\/code>\n   &#8211; CIDR: e.g., <code>10.0.0.0\/16<\/code><\/li>\n<li>Create two <strong>vSwitches<\/strong> in different zones within the same region:\n   &#8211; <code>lab-alb-vsw-a<\/code> in Zone A: <code>10.0.1.0\/24<\/code>\n   &#8211; <code>lab-alb-vsw-b<\/code> in Zone B: <code>10.0.2.0\/24<\/code><\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; One VPC with two subnets (vSwitches) across two zones.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In VPC console, confirm both vSwitches show <strong>Available<\/strong> and are in different zones.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a security group for the backends<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Allow ALB to reach backend web servers and (optionally) allow you to SSH for setup.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>ECS<\/strong> \u2192 <strong>Security Groups<\/strong> \u2192 Create Security Group.<\/li>\n<li>Name: <code>lab-alb-backend-sg<\/code><\/li>\n<li>Inbound rules:\n   &#8211; Allow <strong>HTTP 80<\/strong> from:<ul>\n<li>For lab simplicity: <code>0.0.0.0\/0<\/code> (not recommended for production), <strong>or<\/strong><\/li>\n<li>Better: allow from your VPC CIDR (<code>10.0.0.0\/16<\/code>) so only ALB can reach it.<\/li>\n<li>Allow <strong>SSH 22<\/strong> from your public IP only (e.g., <code>x.x.x.x\/32<\/code>) for setup.<\/li>\n<\/ul>\n<\/li>\n<li>Outbound rules:\n   &#8211; Default allow is usually fine for labs.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A security group that permits backend HTTP traffic and limited SSH.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Confirm inbound rules are present and correct.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create two ECS instances (backend servers)<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Run a simple web server on two different backends so you can see load balancing.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>ECS Instances<\/strong> \u2192 Create Instance.<\/li>\n<li>Choose:\n   &#8211; Same region as your VPC\n   &#8211; Network: <code>lab-alb-vpc<\/code>\n   &#8211; vSwitch: put the first ECS in <code>lab-alb-vsw-a<\/code>, second in <code>lab-alb-vsw-b<\/code>\n   &#8211; Security group: <code>lab-alb-backend-sg<\/code>\n   &#8211; OS: Alibaba Cloud Linux \/ CentOS \/ Ubuntu (choose one you\u2019re comfortable with)<\/li>\n<li>Instance naming:\n   &#8211; <code>lab-alb-ecs-1<\/code>\n   &#8211; <code>lab-alb-ecs-2<\/code><\/li>\n<li>Assign public IP:\n   &#8211; Optional. If you don\u2019t 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).<\/li>\n<\/ol>\n\n\n\n<h4 class=\"wp-block-heading\">Configure NGINX on both instances<\/h4>\n\n\n\n<p>SSH into each ECS and run one of the following sets of commands.<\/p>\n\n\n\n<p><strong>For Ubuntu\/Debian<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo apt-get update\nsudo apt-get -y install nginx\necho \"Hello from $(hostname) - backend 1\/2\" | sudo tee \/var\/www\/html\/index.html\nsudo systemctl enable nginx\nsudo systemctl restart nginx\n<\/code><\/pre>\n\n\n\n<p><strong>For RHEL\/CentOS\/Alibaba Cloud Linux (package names vary)<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo yum -y install nginx || sudo dnf -y install nginx\necho \"Hello from $(hostname) - backend 1\/2\" | sudo tee \/usr\/share\/nginx\/html\/index.html\nsudo systemctl enable nginx\nsudo systemctl restart nginx\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Both ECS instances serve HTTP on port 80 with different content.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\nFrom your laptop (if instances have public IPs):<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s http:\/\/&lt;ECS_PUBLIC_IP_1&gt;\/\ncurl -s http:\/\/&lt;ECS_PUBLIC_IP_2&gt;\/\n<\/code><\/pre>\n\n\n\n<p>You should see different hostnames in the responses.<\/p>\n\n\n\n<p>If instances do not have public IPs, verify from within the VPC (via bastion or other access).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a server group and register ECS backends<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Define the pool of backends ALB will forward to.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Application Load Balancer (ALB)<\/strong> console.<\/li>\n<li>Create a <strong>Server Group<\/strong>:\n   &#8211; Name: <code>lab-alb-sg-web<\/code>\n   &#8211; VPC: <code>lab-alb-vpc<\/code>\n   &#8211; Backend protocol: HTTP (typical for L7 forwarding)<\/li>\n<li>Add backend servers:\n   &#8211; Add <code>lab-alb-ecs-1<\/code> (port 80)\n   &#8211; Add <code>lab-alb-ecs-2<\/code> (port 80)<\/li>\n<li>Configure health check (typical values):\n   &#8211; Protocol: HTTP\n   &#8211; Path: <code>\/<\/code>\n   &#8211; Expected HTTP codes: <code>200<\/code> (or range; depends on UI options)\n   &#8211; Interval\/timeout: defaults are fine for a lab<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Server group exists and includes two ECS targets.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In server group target list, wait until health status shows <strong>Healthy<\/strong>.\n&#8211; If they remain unhealthy, proceed to the Troubleshooting section.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create an ALB instance (multi-zone)<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Create the actual ALB resource that will receive traffic.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the ALB console, create an <strong>ALB Instance<\/strong>.<\/li>\n<li>Select:\n   &#8211; Region: your lab region\n   &#8211; VPC: <code>lab-alb-vpc<\/code>\n   &#8211; vSwitches: select <strong>both<\/strong> <code>lab-alb-vsw-a<\/code> and <code>lab-alb-vsw-b<\/code><\/li>\n<li>Choose endpoint type:\n   &#8211; <strong>Internet-facing<\/strong> if you want to test from your laptop without VPN\n   &#8211; <strong>Internal-facing<\/strong> if you will test from within the VPC<\/li>\n<\/ol>\n\n\n\n<blockquote>\n<p>Public connectivity details vary by ALB offering and region (EIP association vs built-in public addressing). Follow the console workflow and <strong>verify in official docs<\/strong> for your region.<\/p>\n<\/blockquote>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; ALB instance is created and shows a <strong>DNS name<\/strong>.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In ALB instance details, copy the provided DNS name.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create an HTTP listener and forward to the server group<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Make ALB accept traffic on port 80 and send it to your ECS servers.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In your ALB instance, go to <strong>Listeners<\/strong> \u2192 Create Listener.<\/li>\n<li>Configure:\n   &#8211; Protocol: HTTP\n   &#8211; Port: 80<\/li>\n<li>Default action:\n   &#8211; Forward to server group: <code>lab-alb-sg-web<\/code><\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; HTTP listener is active.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\nFrom your laptop:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i http:\/\/&lt;ALB_DNS_NAME&gt;\/\n<\/code><\/pre>\n\n\n\n<p>You should receive an HTTP 200 response from one backend.<\/p>\n\n\n\n<p>Run it multiple times:<\/p>\n\n\n\n<pre><code class=\"language-bash\">for i in {1..6}; do curl -s http:\/\/&lt;ALB_DNS_NAME&gt;\/; done\n<\/code><\/pre>\n\n\n\n<p>You should see responses alternating between the two backend hostnames (depending on load balancing behavior and keep-alives).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Add a path-based routing rule (demo)<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Demonstrate ALB\u2019s application-layer routing.<\/p>\n\n\n\n<p>You\u2019ll create a second server group and rule that routes <code>\/api\/*<\/code> to a different backend set (for demo, we can reuse the same ECS but with a different page path).<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">7.1 Update backends to serve an <code>\/api<\/code> endpoint<\/h4>\n\n\n\n<p>On both ECS instances:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mkdir -p \/var\/www\/html\/api || true\necho \"API response from $(hostname)\" | sudo tee \/var\/www\/html\/api\/index.html\nsudo systemctl restart nginx\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">7.2 Create a second server group<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Name: <code>lab-alb-sg-api<\/code><\/li>\n<li>Add both ECS instances on port 80 (or only one if you want deterministic responses)<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">7.3 Create a listener rule<\/h4>\n\n\n\n<p>In the HTTP listener:\n&#8211; Add rule:\n  &#8211; Condition: Path is <code>\/api\/*<\/code> (or equivalent syntax in console)\n  &#8211; Action: Forward to server group <code>lab-alb-sg-api<\/code>\n&#8211; Ensure rule priority\/order is correct (more specific rules should win).<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Requests to <code>\/<\/code> go to <code>lab-alb-sg-web<\/code>\n&#8211; Requests to <code>\/api\/<\/code> go to <code>lab-alb-sg-api<\/code><\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s http:\/\/&lt;ALB_DNS_NAME&gt;\/\ncurl -s http:\/\/&lt;ALB_DNS_NAME&gt;\/api\/\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>ALB instance status<\/strong> is Running\/Active.<\/li>\n<li><strong>Listener<\/strong> is active on port 80.<\/li>\n<li><strong>Server group targets<\/strong> show Healthy.<\/li>\n<li><code>curl http:\/\/ALB_DNS\/<\/code> returns backend content.<\/li>\n<li><code>curl http:\/\/ALB_DNS\/api\/<\/code> returns API content.<\/li>\n<li>Repeated curls show distribution across backends (not always perfectly alternating due to connection reuse, but you should see both servers).<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common errors and realistic fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Backends show Unhealthy<\/strong>\n   &#8211; Check the backend security group inbound rule allows port 80 from ALB\/VPC CIDR.\n   &#8211; Confirm NGINX is running: <code>sudo systemctl status nginx<\/code>\n   &#8211; Confirm the health check path is valid (<code>\/<\/code> returns 200).\n   &#8211; Confirm ECS is in the same VPC and reachable (routing tables, NACLs if used).<\/p>\n<\/li>\n<li>\n<p><strong><code>curl<\/code> to ALB DNS times out<\/strong>\n   &#8211; If internet-facing: confirm ALB is truly public and has a public endpoint\/EIP association.\n   &#8211; Confirm any ALB security controls (if applicable) allow inbound HTTP from your IP (some load balancers support ACLs\u2014verify in docs).\n   &#8211; Ensure local firewall\/proxy is not blocking.<\/p>\n<\/li>\n<li>\n<p><strong>Always hits the same backend<\/strong>\n   &#8211; Keep-alive can reuse the same connection.\n   &#8211; Try forcing new connections:\n     <code>bash\n     curl -s --no-keepalive http:\/\/&lt;ALB_DNS_NAME&gt;\/<\/code>\n     (If your curl doesn\u2019t support <code>--no-keepalive<\/code>, run <code>curl<\/code> in separate processes or add headers; behavior can vary.)<\/p>\n<\/li>\n<li>\n<p><strong>404 on <code>\/api\/<\/code><\/strong>\n   &#8211; Verify NGINX path exists and permissions are correct.\n   &#8211; Ensure the listener rule match is correct and prioritized above default forwarding.<\/p>\n<\/li>\n<li>\n<p><strong>HTTPS not working (if you later add it)<\/strong>\n   &#8211; Confirm certificate is valid and bound to the HTTPS listener.\n   &#8211; Confirm SNI configuration if using multiple domains (verify ALB supports and how it is configured).\n   &#8211; Confirm security policies allow modern TLS versions.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid charges, delete resources in this order:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In ALB console:\n   &#8211; Delete listener rules (if required by UI)\n   &#8211; Delete listeners\n   &#8211; Delete server groups (or remove targets first if required)\n   &#8211; Delete the ALB instance<\/li>\n<li>Release EIP (if one was allocated separately)<\/li>\n<li>In ECS:\n   &#8211; Delete <code>lab-alb-ecs-1<\/code> and <code>lab-alb-ecs-2<\/code><\/li>\n<li>In VPC:\n   &#8211; Delete vSwitches\n   &#8211; Delete VPC<\/li>\n<li>Delete security group (if no longer used)<\/li>\n<\/ol>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Check Billing\/Resource list to ensure ALB instances and EIPs are not present.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use multi-zone<\/strong>: Attach ALB to at least two vSwitches and run backends in at least two zones.<\/li>\n<li><strong>Separate concerns<\/strong>: Use ALB for L7 routing and TLS, keep application services stateless where possible.<\/li>\n<li><strong>Use multiple server groups<\/strong>: One per service\/component to simplify deployments and ownership.<\/li>\n<li><strong>Design for failure<\/strong>: Assume a backend, a zone, or a deployment can fail; use health checks and fast rollback.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege RAM policies<\/strong>:<\/li>\n<li>Separate \u201cnetwork admins\u201d who create ALB from \u201capp teams\u201d who can only update server group targets\/rules as needed.<\/li>\n<li><strong>Use RAM roles<\/strong> for automation instead of long-lived access keys.<\/li>\n<li><strong>Tag resources<\/strong> (<code>env=prod<\/code>, <code>app=payments<\/code>, <code>owner=platform<\/code>) and enforce tagging policies if your governance model supports it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Right-size backend compute; ALB doesn\u2019t reduce backend cost by itself.<\/li>\n<li>Prefer CDN for cacheable static content to reduce ALB traffic and egress.<\/li>\n<li>Enable logging intentionally with retention control; archive\/roll logs.<\/li>\n<li>Avoid unnecessary public exposure: internal ALB for internal apps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Tune health checks to balance fast failover and false positives (avoid overly aggressive timeouts).<\/li>\n<li>Use connection reuse\/keep-alives appropriately; verify your backend server settings.<\/li>\n<li>If HTTP\/2 is supported and appropriate, enable it for web clients (verify ALB support).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use infrastructure-as-code for repeatability (Terraform or equivalent).<\/li>\n<li>Deploy backends with autoscaling (ECS Auto Scaling or Kubernetes HPA).<\/li>\n<li>Set CloudMonitor alarms for:<\/li>\n<li>Unhealthy hosts &gt; 0<\/li>\n<li>5xx error rate threshold<\/li>\n<li>High latency \/ saturation indicators<\/li>\n<li>Keep rollback procedures documented (remove rule, shift traffic to stable server group).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Implement change management for listener rules; misordered rules can break routing.<\/li>\n<li>Maintain runbooks:<\/li>\n<li>\u201cBackends unhealthy\u201d<\/li>\n<li>\u201cHigh 5xx at ALB\u201d<\/li>\n<li>\u201cLatency regression\u201d<\/li>\n<li>Periodically test failover by taking one backend out of service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Naming pattern example:<\/li>\n<li><code>alb-prod-main<\/code>, <code>alb-stg-main<\/code><\/li>\n<li><code>sg-prod-web<\/code>, <code>sg-prod-api<\/code><\/li>\n<li><code>lis-prod-https-443<\/code><\/li>\n<li>Use consistent tags and enforce them in CI pipelines.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model (RAM)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>ALB is managed through Alibaba Cloud APIs and Console; access is controlled with <strong>RAM<\/strong>.<\/li>\n<li>Recommended pattern:<\/li>\n<li>Human users: RAM users with MFA + least privilege.<\/li>\n<li>Automation: RAM roles assumed by CI\/CD (short-lived credentials).<\/li>\n<li>Audit RAM policy changes and ALB configuration changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>HTTPS listeners<\/strong> for encryption in transit from clients to ALB.<\/li>\n<li>For ALB-to-backend encryption:<\/li>\n<li>If you handle sensitive data, consider HTTPS from ALB to backends too, or ensure the VPC network and host hardening meets your threat model.<\/li>\n<li>Confirm how ALB validates backend certificates (if supported)\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>internal-facing ALB<\/strong> for internal services.<\/li>\n<li>For internet-facing ALB:<\/li>\n<li>Restrict management access via RAM<\/li>\n<li>Restrict backend exposure: backends should not have public IPs unless required<\/li>\n<li>Use security groups to allow inbound only from VPC\/ALB, not the internet<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Don\u2019t store private keys on ECS instances if ALB terminates TLS.<\/li>\n<li>Use Alibaba Cloud certificate services and proper access controls for certificate management.<\/li>\n<li>Store app secrets in a secrets manager service (verify your org\u2019s standard\u2014Alibaba Cloud has secrets services; confirm the current product and best practice).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable <strong>ActionTrail<\/strong> for control-plane auditing (verify ALB event types).<\/li>\n<li>Enable <strong>access logs<\/strong> for data-plane visibility (consider PII handling and retention).<\/li>\n<li>Centralize logs and apply access controls and retention policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure logs, certificates, and endpoints comply with:<\/li>\n<li>Data residency rules (region selection)<\/li>\n<li>Retention requirements<\/li>\n<li>Encryption requirements<\/li>\n<li>For regulated environments, document:<\/li>\n<li>TLS versions\/ciphers<\/li>\n<li>Change management processes<\/li>\n<li>Incident response steps<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Exposing backends publicly (public IP + open security group) while also placing ALB in front.<\/li>\n<li>Health check endpoint exposes sensitive debug data.<\/li>\n<li>Overly broad RAM permissions allowing anyone to modify routing rules.<\/li>\n<li>Lack of logging\/alerting for 5xx spikes or WAF events (if used).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Internet-facing ALB + private backends only.<\/li>\n<li>Use HTTPS everywhere; redirect HTTP to HTTPS.<\/li>\n<li>Use WAF where threat models require it (verify best-practice integration path in Alibaba Cloud docs).<\/li>\n<li>Implement infrastructure-as-code + peer-reviewed change process for listener rules.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because limits evolve and differ by region, treat this as a planning checklist and <strong>verify in official docs<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitation categories<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional scope<\/strong>: ALB is regional. For multi-region active-active, use DNS\/GA\/CDN patterns.<\/li>\n<li><strong>Listener\/rule quotas<\/strong>: Max number of listeners per instance, rules per listener, conditions per rule.<\/li>\n<li><strong>Server group limits<\/strong>: Max targets per group and per instance.<\/li>\n<li><strong>Backend target types<\/strong>: ECS, IP targets, and others may be supported, but availability varies. Confirm for your region.<\/li>\n<li><strong>Protocol scope<\/strong>: ALB focuses on HTTP\/HTTPS; use NLB for TCP\/UDP.<\/li>\n<li><strong>Feature availability by region<\/strong>: Some advanced capabilities (HTTP\/2, logging destinations, WAF integration) can vary.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Health check misconfigurations<\/strong> cause silent outages (ALB returns 5xx when no healthy targets).<\/li>\n<li><strong>Rule priority\/order<\/strong>: A broad rule can shadow a more specific rule.<\/li>\n<li><strong>Keep-alives<\/strong> can make load distribution appear \u201csticky\u201d even without session persistence.<\/li>\n<li><strong>Security group scope<\/strong>: If backends only allow <code>0.0.0.0\/0<\/code> on port 80 for convenience, you\u2019ve created unnecessary exposure.<\/li>\n<li><strong>Logging costs<\/strong>: Access logs can become expensive at scale if you retain everything forever.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating from self-managed NGINX\/HAProxy:<\/li>\n<li>Some custom behaviors may not map 1:1 (rewrite logic, special headers, bespoke auth).<\/li>\n<li>Migrating from CLB:<\/li>\n<li>Feature parity can differ; validate listener behaviors, timeouts, header handling, and certificates.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">How ALB compares inside Alibaba Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Classic Load Balancer (CLB)<\/strong>: Older load balancing product; may support some legacy patterns. Often used for existing deployments. Confirm current recommendation status in official docs.<\/li>\n<li><strong>Network Load Balancer (NLB)<\/strong>: Layer 4 load balancing for TCP\/UDP, typically lower overhead and better for non-HTTP protocols.<\/li>\n<li><strong>Global Accelerator (GA)<\/strong>: Improves global access latency and availability; pairs with regional endpoints like ALB for cross-region acceleration.<\/li>\n<li><strong>CDN<\/strong>: Best for caching and edge delivery of static\/streaming content; can sit in front of ALB as origin.<\/li>\n<li><strong>API Gateway<\/strong>: Adds API management features (auth, throttling, transformations). ALB is not a full API management product.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How ALB compares to other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Application Load Balancer (ALB)<\/strong>: Similar concept; feature names differ.<\/li>\n<li><strong>Azure Application Gateway<\/strong>: Similar L7 load balancing; integrates tightly with Azure VNets and WAF.<\/li>\n<li><strong>Google Cloud HTTPS Load Balancer<\/strong>: Global L7 load balancing with different architecture (often global by design).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>NGINX\/HAProxy\/Envoy<\/strong>: Maximum flexibility, but you manage scaling, patching, HA, and observability.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Comparison table<\/h4>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Alibaba Cloud Application Load Balancer (ALB)<\/td>\n<td>HTTP\/HTTPS apps needing L7 routing<\/td>\n<td>Managed, L7 rules, TLS termination, multi-zone<\/td>\n<td>Regional scope, feature set depends on region, costs scale with traffic<\/td>\n<td>Web\/apps\/APIs, microservices routing, Kubernetes ingress needs<\/td>\n<\/tr>\n<tr>\n<td>Alibaba Cloud Network Load Balancer (NLB)<\/td>\n<td>TCP\/UDP workloads<\/td>\n<td>Efficient L4, good for non-HTTP protocols<\/td>\n<td>No L7 routing<\/td>\n<td>Databases proxies, MQTT, game TCP, custom protocols<\/td>\n<\/tr>\n<tr>\n<td>Alibaba Cloud Classic Load Balancer (CLB)<\/td>\n<td>Legacy deployments<\/td>\n<td>Familiar to existing Alibaba Cloud users<\/td>\n<td>Legacy positioning; feature parity varies<\/td>\n<td>Existing CLB-heavy estates, gradual migration<\/td>\n<\/tr>\n<tr>\n<td>Alibaba Cloud Global Accelerator (GA)<\/td>\n<td>Global users accessing regional apps<\/td>\n<td>Improves latency\/availability globally<\/td>\n<td>Additional service\/cost; not a full L7 router by itself<\/td>\n<td>Multi-region front door patterns, global performance needs<\/td>\n<\/tr>\n<tr>\n<td>CDN (Alibaba Cloud CDN)<\/td>\n<td>Static content delivery<\/td>\n<td>Caching, edge offload<\/td>\n<td>Not a general-purpose app router<\/td>\n<td>Put in front of ALB to reduce origin load<\/td>\n<\/tr>\n<tr>\n<td>Self-managed NGINX\/HAProxy<\/td>\n<td>Custom proxy logic<\/td>\n<td>Full control and extensibility<\/td>\n<td>You manage HA\/scaling\/patching<\/td>\n<td>Specialized behaviors, bespoke routing, extreme customization<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Internal + external portals with compliance logging<\/h3>\n\n\n\n<p><strong>Problem<\/strong><br\/>\nA large enterprise hosts:\n&#8211; A customer-facing portal (<code>portal.company.com<\/code>)\n&#8211; An API (<code>api.company.com<\/code>)\n&#8211; Multiple internal apps for employees<br\/>\nThey require TLS enforcement, centralized logging, and clear separation between internal and external entry points.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; Internet-facing <strong>Application Load Balancer (ALB)<\/strong> for external traffic:\n  &#8211; HTTPS listener with enterprise certificate\n  &#8211; Host-based rules:\n    &#8211; <code>portal.company.com<\/code> \u2192 <code>sg-portal<\/code>\n    &#8211; <code>api.company.com<\/code> \u2192 <code>sg-api<\/code>\n&#8211; Internal-facing <strong>ALB<\/strong> for intranet apps:\n  &#8211; Private DNS names\n  &#8211; Access limited to corporate network via VPN\/Express Connect (depending on design)\n&#8211; Backends on ECS\/ACK spread across two zones\n&#8211; Logs shipped to Log Service with retention policies and access controls\n&#8211; CloudMonitor alarms integrated to on-call rotation<\/p>\n\n\n\n<p><strong>Why ALB was chosen<\/strong>\n&#8211; L7 routing reduces the number of separate load balancers.\n&#8211; TLS centralized at the edge.\n&#8211; Multi-zone deployment supports high availability.\n&#8211; Operational governance via RAM and audit logs.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Reduced downtime due to health-checked backends\n&#8211; Faster certificate rotation and fewer misconfigurations\n&#8211; Improved audit readiness with centralized access logging<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: One ALB for multiple microservices<\/h3>\n\n\n\n<p><strong>Problem<\/strong><br\/>\nA startup runs 6 microservices and a React frontend. Managing multiple public endpoints is messy, and they want simple routing plus HTTPS.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; One internet-facing <strong>ALB<\/strong>\n&#8211; HTTPS listener with a single wildcard certificate (if appropriate)\n&#8211; Path-based routing:\n  &#8211; <code>\/<\/code> \u2192 frontend service\n  &#8211; <code>\/api\/auth\/*<\/code> \u2192 auth service\n  &#8211; <code>\/api\/payments\/*<\/code> \u2192 payments service\n  &#8211; <code>\/api\/*<\/code> \u2192 general API gateway service (or monolith API)\n&#8211; Backends on a small ECS autoscaling group or ACK<\/p>\n\n\n\n<p><strong>Why ALB was chosen<\/strong>\n&#8211; Simplifies DNS and ingress.\n&#8211; Lets them add services by adding rules, not by provisioning new public endpoints.\n&#8211; Reduces time spent managing edge proxy infrastructure.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Faster deployments, clearer routing, fewer operational tasks\n&#8211; Ability to scale backends independently behind server groups<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) Is Application Load Balancer (ALB) the same as Server Load Balancer (SLB)?<\/h3>\n\n\n\n<p>Historically, \u201cSLB\u201d was often used as a general term on Alibaba Cloud. Today, <strong>Application Load Balancer (ALB)<\/strong> is a specific L7 product, distinct from <strong>Classic Load Balancer (CLB)<\/strong> and <strong>Network Load Balancer (NLB)<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Is ALB Layer 4 or Layer 7?<\/h3>\n\n\n\n<p><strong>ALB is Layer 7<\/strong>, primarily for HTTP\/HTTPS routing. For TCP\/UDP, consider <strong>NLB<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Is ALB regional or global?<\/h3>\n\n\n\n<p>ALB is typically <strong>regional<\/strong> (deployed in a single region, multi-zone within that region). For global acceleration, consider <strong>Global Accelerator<\/strong> and\/or CDN patterns.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) Can ALB route traffic based on hostname and path?<\/h3>\n\n\n\n<p>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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) Can I use ALB for internal\/private applications?<\/h3>\n\n\n\n<p>Yes. Create an internal-facing ALB in a VPC and restrict access via network controls.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) Does ALB support HTTPS and TLS termination?<\/h3>\n\n\n\n<p>Yes. You can configure HTTPS listeners and bind certificates. Certificate sourcing and advanced TLS options vary\u2014verify in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) Do I need public IPs on my ECS backends?<\/h3>\n\n\n\n<p>No. A recommended design is: <strong>public ALB + private backends<\/strong>. Backends can remain private in VPC subnets.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) How do health checks work?<\/h3>\n\n\n\n<p>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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) Why are my backends unhealthy even though the service works locally?<\/h3>\n\n\n\n<p>Most common causes:\n&#8211; Security group blocks ALB-to-backend traffic\n&#8211; Wrong health check path (returns 404\/500)\n&#8211; Backend listens on a different port\n&#8211; App requires Host header and health check doesn\u2019t match expected host (verify ALB health check header options)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) Can I do blue\/green or canary deployments with ALB?<\/h3>\n\n\n\n<p>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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) How do I connect a custom domain to ALB?<\/h3>\n\n\n\n<p>Create a DNS record (often <strong>CNAME<\/strong>) from your domain to the ALB DNS name. For apex domains, you may need ALIAS\/ANAME support depending on DNS provider.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) Does ALB integrate with Kubernetes (ACK)?<\/h3>\n\n\n\n<p>Commonly yes through an ALB ingress controller. Verify the current controller name, supported annotations, and feature coverage in the ACK\/ALB docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) What are the main cost drivers for ALB?<\/h3>\n\n\n\n<p>Instance runtime, capacity\/processing units (model varies), public egress, and logging storage\/ingestion. Backends (ECS\/ACK) are separate costs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) How do I monitor ALB?<\/h3>\n\n\n\n<p>Use <strong>CloudMonitor<\/strong> for metrics and alarms, and enable <strong>access logs<\/strong> for request-level troubleshooting.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) What\u2019s the safest way to operate ALB at scale?<\/h3>\n\n\n\n<p>Use:\n&#8211; Infrastructure-as-code\n&#8211; Least-privilege RAM policies\n&#8211; Standard naming\/tagging\n&#8211; Change review for listener rules\n&#8211; Multi-zone deployments\n&#8211; Central logging and alarming<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Application Load Balancer (ALB)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Alibaba Cloud ALB Documentation<\/td>\n<td>Primary reference for features, limits, configuration steps, and APIs: https:\/\/www.alibabacloud.com\/help\/en\/application-load-balancer\/<\/td>\n<\/tr>\n<tr>\n<td>Official product page<\/td>\n<td>Alibaba Cloud Application Load Balancer (ALB) Product Page<\/td>\n<td>High-level overview, region availability entry points, and pricing access: https:\/\/www.alibabacloud.com\/product\/alb<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>ALB Pricing (via product page)<\/td>\n<td>Pricing varies by region and billing mode; use the Pricing tab\/section: https:\/\/www.alibabacloud.com\/product\/alb<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Alibaba Cloud Pricing Calculator<\/td>\n<td>Build estimates across ALB + ECS + EIP + logging: https:\/\/www.alibabacloud.com\/pricing-calculator<\/td>\n<\/tr>\n<tr>\n<td>Official docs (RAM)<\/td>\n<td>Resource Access Management (RAM) Documentation<\/td>\n<td>Learn IAM best practices and policy writing: https:\/\/www.alibabacloud.com\/help\/en\/ram\/<\/td>\n<\/tr>\n<tr>\n<td>Official docs (VPC)<\/td>\n<td>VPC Documentation<\/td>\n<td>Understand VPC\/vSwitch design and routing dependencies: https:\/\/www.alibabacloud.com\/help\/en\/vpc\/<\/td>\n<\/tr>\n<tr>\n<td>Official docs (ECS)<\/td>\n<td>ECS Documentation<\/td>\n<td>Backend compute setup and security groups: https:\/\/www.alibabacloud.com\/help\/en\/ecs\/<\/td>\n<\/tr>\n<tr>\n<td>Official docs (CloudMonitor)<\/td>\n<td>CloudMonitor Documentation<\/td>\n<td>Metrics and alarms for operations: https:\/\/www.alibabacloud.com\/help\/en\/cloudmonitor\/<\/td>\n<\/tr>\n<tr>\n<td>Official docs (Log Service)<\/td>\n<td>Log Service (SLS) Documentation<\/td>\n<td>Central logging pipeline and retention\/cost controls: https:\/\/www.alibabacloud.com\/help\/en\/sls\/<\/td>\n<\/tr>\n<tr>\n<td>Official docs (Certificates)<\/td>\n<td>SSL Certificates Service Documentation<\/td>\n<td>TLS cert issuance\/import and lifecycle: https:\/\/www.alibabacloud.com\/help\/en\/ssl-certificate-service\/<\/td>\n<\/tr>\n<tr>\n<td>Official docs (ActionTrail)<\/td>\n<td>ActionTrail Documentation<\/td>\n<td>Audit trail for control-plane changes: https:\/\/www.alibabacloud.com\/help\/en\/actiontrail\/<\/td>\n<\/tr>\n<tr>\n<td>Community learning<\/td>\n<td>Alibaba Cloud Community<\/td>\n<td>Practical posts and patterns; validate against official docs: https:\/\/www.alibabacloud.com\/blog\/ and https:\/\/www.alibabacloud.com\/community<\/td>\n<\/tr>\n<tr>\n<td>Video learning<\/td>\n<td>Alibaba Cloud YouTube Channel<\/td>\n<td>Recorded webinars and demos (availability varies): https:\/\/www.youtube.com\/@AlibabaCloud<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps\/cloud fundamentals, deployment and operations practices that can include load balancing<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>SCM\/DevOps tooling and practical labs that may include cloud networking<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops practitioners<\/td>\n<td>Operations, monitoring, automation practices (verify Alibaba Cloud coverage on site)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, reliability-focused engineers<\/td>\n<td>SRE practices: SLOs, incident response, monitoring (applies to ALB operations)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>Observability, automation, AIOps concepts (useful for ALB monitoring\/log analysis)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify exact offerings)<\/td>\n<td>Students, engineers looking for practical guidance<\/td>\n<td>https:\/\/www.rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training platform (verify Alibaba Cloud coverage)<\/td>\n<td>Beginners to intermediate DevOps learners<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps expertise marketplace\/platform (verify services)<\/td>\n<td>Teams needing short-term DevOps support<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resource (verify exact offerings)<\/td>\n<td>Ops teams seeking troubleshooting help<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service catalog)<\/td>\n<td>Architecture reviews, migrations, automation<\/td>\n<td>ALB\/ingress design, HA reviews, cost optimization workshops<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training<\/td>\n<td>Implementation and enablement<\/td>\n<td>Standardizing ALB patterns, CI\/CD integration, monitoring\/runbooks<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify service catalog)<\/td>\n<td>Delivery acceleration and operations<\/td>\n<td>Setting up ALB + observability + security baselines for production<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before this service<\/h3>\n\n\n\n<p>To use <strong>Alibaba Cloud Application Load Balancer (ALB)<\/strong> effectively, learn:\n&#8211; Networking basics: IPs, CIDR, subnets, routing, DNS\n&#8211; HTTP\/HTTPS fundamentals: headers, status codes, TLS basics\n&#8211; Alibaba Cloud VPC fundamentals: VPC, vSwitch, security groups\n&#8211; Compute basics: ECS instances, images, basic Linux operations\n&#8211; Observability basics: metrics vs logs, basic troubleshooting<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after this service<\/h3>\n\n\n\n<p>To level up beyond a basic ALB deployment:\n&#8211; <strong>Network Load Balancer (NLB)<\/strong> vs ALB selection for mixed workloads\n&#8211; Kubernetes ingress on <strong>ACK<\/strong> with ALB ingress controller\n&#8211; Zero-downtime deployment strategies (blue\/green, canary)\n&#8211; Centralized logging with <strong>Log Service (SLS)<\/strong> and alerting pipelines\n&#8211; Security hardening with WAF, TLS policy enforcement, and IAM governance\n&#8211; Infrastructure as Code (Terraform) for repeatable ALB patterns<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Network\/Cloud Network Engineer<\/li>\n<li>Solutions Architect<\/li>\n<li>Security Engineer (for TLS, exposure boundaries, logging\/audit)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>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.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Multi-service routing: host + path routing to 3 microservices<\/li>\n<li>HTTPS everywhere: HTTP\u2192HTTPS redirect, certificate rotation exercise<\/li>\n<li>Multi-zone resilience test: simulate one backend\/zone outage and measure impact<\/li>\n<li>Observability setup: CloudMonitor alarms + log dashboards in SLS<\/li>\n<li>Kubernetes ingress: route multiple services with ALB ingress controller (verify annotations\/features)<\/li>\n<li>Cost optimization: compare ALB+CDN vs ALB-only for static-heavy workloads<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>ALB (Application Load Balancer)<\/strong>: Managed Layer 7 load balancer for HTTP\/HTTPS on Alibaba Cloud.<\/li>\n<li><strong>Listener<\/strong>: A protocol\/port configuration on ALB that receives client connections.<\/li>\n<li><strong>Listener rule<\/strong>: A match-and-forward rule (e.g., host\/path) that routes traffic to a server group.<\/li>\n<li><strong>Server group<\/strong>: A logical group of backend targets (instances\/IPs) that receive traffic.<\/li>\n<li><strong>Backend target<\/strong>: A server endpoint (e.g., ECS instance on port 80) registered in a server group.<\/li>\n<li><strong>Health check<\/strong>: Periodic probe to determine whether a backend should receive traffic.<\/li>\n<li><strong>VPC (Virtual Private Cloud)<\/strong>: Your isolated network in Alibaba Cloud.<\/li>\n<li><strong>vSwitch<\/strong>: A subnet within a VPC, tied to a specific zone.<\/li>\n<li><strong>Zone<\/strong>: An isolated location within a region. Multi-zone designs increase availability.<\/li>\n<li><strong>EIP (Elastic IP Address)<\/strong>: Public IP resource used for internet access in many Alibaba Cloud designs.<\/li>\n<li><strong>TLS termination<\/strong>: Decrypting HTTPS at the load balancer so backends can receive HTTP (or re-encrypted HTTPS).<\/li>\n<li><strong>CloudMonitor<\/strong>: Alibaba Cloud monitoring service for metrics and alarms.<\/li>\n<li><strong>Log Service (SLS)<\/strong>: Alibaba Cloud log ingestion, storage, and analytics platform.<\/li>\n<li><strong>RAM (Resource Access Management)<\/strong>: Alibaba Cloud IAM for users, roles, and permissions.<\/li>\n<li><strong>ActionTrail<\/strong>: Alibaba Cloud service for auditing API actions (control-plane events).<\/li>\n<li><strong>Ingress<\/strong>: Kubernetes concept for routing external traffic to services; can be implemented using ALB.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p><strong>Application Load Balancer (ALB)<\/strong> in <strong>Alibaba Cloud<\/strong> (Networking and CDN) is a managed Layer 7 load balancer for <strong>HTTP\/HTTPS<\/strong> applications. It provides a stable entry point, health-checked backend distribution, TLS termination, and rule-based routing\u2014making it a strong fit for web apps, APIs, and microservices.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>Key cost\/security points:\n&#8211; Cost scales with runtime, capacity\/traffic, egress, and logging.\n&#8211; Security improves when ALB is the only public endpoint and backends remain private with least-privilege RAM, HTTPS, and auditing.<\/p>\n\n\n\n<p>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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking and CDN<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,8],"tags":[],"class_list":["post-34","post","type-post","status-publish","format-standard","hentry","category-alibaba-cloud","category-networking-and-cdn"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/34","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=34"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/34\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=34"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=34"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=34"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}