Executive summary
This article walks through the design of a highly available enterprise infrastructure on Alibaba Cloud using Elastic Compute Service (ECS) instances, Virtual Private Cloud (VPC) networking, and Server Load Balancer (SLB). It explains the underlying networking model, compares the three SLB families, shows a concrete deployment diagram, and gives step‑by‑step guidance for implementing multi‑zone redundancy, security controls, and operational processes. The guidance is derived entirely from Alibaba Cloud documentation and is intended for architects who need to build resilient services that stay online even when a single zone or an individual server fails.
Introduction
Enterprises that run mission‑critical workloads need continuous availability, predictable performance, and clear separation of responsibilities across teams. Alibaba Cloud provides a set of building blocks—ECS, VPC, and SLB—that can be combined to satisfy those requirements. The high‑availability pattern described in the official guide emphasizes three pillars: multiple ECS instances, a load balancer, and deployment across more than one availability zone within the same region. By following this pattern, a failure in a single zone or an individual instance does not interrupt service, and the architecture remains simple enough to be managed by a small operations team.
Technical fundamentals
ECS networking
When an ECS instance is launched inside a VPC, it receives a private IP address from the CIDR block of the vSwitch to which it is attached. This private address is used for intra‑VPC communication, including calls to Object Storage Service (OSS) and ApsaraDB RDS. Public connectivity is provided either by an automatically assigned public IP or by an elastic IP that can be bound to the instance. The private IP remains stable for the lifetime of the instance, which simplifies firewall rules and service discovery.
Zones and regions
A region groups several zones, each of which is an isolated set of data‑center facilities. Because zones are independent, a hardware or power outage in one zone does not affect the others. High‑availability designs therefore spread ECS instances across at least two zones in the same region, ensuring that a single‑zone outage cannot bring down the entire service.
Server Load Balancer families
Alibaba Cloud offers three SLB families, each optimized for different protocol layers and traffic patterns:
| SLB family | Protocol support | Architecture | Documented ceiling |
|---|
| Classic Load Balancer (CLB) | TCP, UDP, HTTP, HTTPS (Layer 4 & basic Layer 7) | Physical‑machine based | Up to 1 million concurrent connections and 50 000 queries per second |
| Application Load Balancer (ALB) | HTTP, HTTPS, QUIC (Layer 7) | Network‑functions virtualization platform with auto‑scaling | Up to 1 million queries per second, plus rewrites, redirects, content‑based routing |
| Network Load Balancer (NLB) | TCP, UDP, SSL over TCP (Layer 4) | Same NFV platform as ALB | Up to 100 million concurrent connections, SSL offloading, connection draining |
These limits are product caps, not performance benchmarks, and they help architects decide which family matches the expected traffic volume and protocol requirements.
Architecture and components
A typical highly available deployment consists of:
- Clients accessing the service via DNS.
- DNS resolving the service name to the public domain of an SLB instance.
- One SLB (CLB, ALB, or NLB) acting as the single entry point.
- Two or more ECS instances placed in separate zones but inside the same VPC.
- Health‑check configuration on the SLB that probes each ECS instance.
- Optional shared VPC to allow multiple Alibaba Cloud accounts within the same organization to create resources in the same vSwitch while keeping billing separate.
The following diagram illustrates the core data flow:
+--------+ DNS +-------------------+ +-----------------+
| Client | ------------> | SLB (public IP) | ---> | ECS Zone A |
+--------+ +-------------------+ | (private IP) |
+-----------------+
| ECS Zone B |
| (private IP) |
+-----------------+
Health checks travel from the SLB back to each instance; an unhealthy instance is removed from the server group until it passes the check again. This simple loop provides automatic failover without human intervention.
Detailed implementation approach
- Create a VPC with a CIDR block that provides enough address space for all vSwitches and instances. Choose a block that aligns with internal IP‑addressing policies and leaves room for future expansion.
- Provision two vSwitches, each in a different zone, using subnet CIDRs that fall within the VPC range. For example,
10.0.1.0/24 in zone A and 10.0.2.0/24 in zone B.
- Launch ECS instances in each vSwitch. Verify that each instance receives a private IP from the vSwitch CIDR and, if needed, an elastic IP for internet‑facing traffic.
- Configure security groups to allow inbound traffic from the SLB on the required service ports (for example, 80/443 for web traffic) and outbound traffic to dependent services such as OSS or RDS.
- Create an SLB of the desired family (CLB, ALB, or NLB) in the same VPC. For an internet‑facing load balancer, assign a static public IP or an elastic IP for NLB.
- Add the ECS instances to a backend server group. Associate each instance with its zone to enable multi‑zone routing and to allow the SLB to prefer the nearest healthy instance.
- Enable health checks (TCP or HTTP depending on the service) and configure the health‑check interval, timeout, and unhealthy threshold as recommended in the high‑availability guide. Conservative thresholds reduce the chance of flapping.
- Set up DNS to point the service name to the SLB’s domain name. For NLB, use the domain name rather than the elastic IP so that automatic removal of a failed virtual IP does not break the record.
- Optionally enable hot upgrades on the SLB to apply configuration changes without service interruption. This feature is useful for rolling out new routing rules or TLS certificates.
A short example of an ECS instance network configuration (excerpt from the VPC documentation) is shown below:
{
"InstanceId": "i-abc123",
"PrivateIpAddress": "10.0.1.15",
"PublicIpAddress": ["203.0.113.5"]
}
Architecture and data‑flow
The data‑flow can be broken into three phases:
- Ingress – Clients resolve the DNS name, reach the SLB’s public endpoint, and the SLB forwards traffic based on its routing policy (round‑robin, weighted, or content‑based).
- Processing – The selected ECS instance processes the request, accesses internal services (OSS, RDS) over the private VPC network, and generates a response.
- Egress – The SLB sends the response back to the client, preserving source IP information when required for logging or compliance.
Because the SLB performs health checks, any instance that becomes unreachable is automatically excluded, and traffic is redistributed to the remaining healthy instances across zones. This mechanism satisfies the multi‑instance redundancy requirement and eliminates single points of failure.
Security and governance
- Security groups act as virtual firewalls; they are attached to ECS instances and must allow inbound traffic only from the SLB’s private IP range. Outbound rules should be limited to necessary services such as OSS, RDS, and any third‑party APIs.
- Shared VPC enables an organization to share non‑default vSwitches across accounts. Participants can create ECS, SLB, and RDS resources, but they cannot attach security groups owned by another participant or the VPC owner. The VPC owner retains responsibility for gateway resources such as NAT and VPN gateways.
- Encryption – For NLB, SSL offloading is supported, allowing termination of TLS at the load balancer while traffic between the SLB and ECS remains encrypted if required by the application.
- Audit – Alibaba Cloud CloudMonitor and ActionTrail can be enabled to record configuration changes, health‑check results, and traffic patterns for compliance and forensic analysis.
Enterprise use cases
| Use case | How the architecture meets the need |
|---|
| Global e‑commerce front‑end | Multi‑zone ECS instances behind an ALB provide HTTP/HTTPS routing, content‑based routing, and automatic scaling to handle traffic spikes from worldwide shoppers. |
| Real‑time gaming backend | NLB delivers ultra‑high concurrent connections with TCP/UDP support and SSL offloading, ensuring low latency for game sessions. |
| Financial transaction processing | CLB with Layer 4 health checks ensures deterministic failover and meets strict latency and regulatory requirements. |
Benefits and limitations
Benefits
- Fault isolation at the zone level prevents a single hardware or power failure from taking down the whole service.
- Automatic traffic redistribution via health checks removes the need for manual intervention during incidents.
- Flexible load‑balancing capabilities across three SLB families let architects choose the right tool for HTTP, HTTPS, or high‑throughput TCP/UDP workloads.
- Centralized security via security groups and shared VPC simplifies policy enforcement across multiple accounts.
Limitations
- All instances must reside in the same region; cross‑region failover requires additional replication mechanisms such as disaster‑recovery sites or global traffic manager services.
- Product ceilings (for example, 1 million queries per second for ALB) may require architectural scaling or multiple SLB instances if traffic approaches those caps.
- A single SLB cluster is not a single point of failure because the service runs on a distributed cluster with session synchronization, but the DNS entry points to that cluster; loss of the entire cluster would still cause downtime until a new SLB is provisioned and DNS is updated.
Operational considerations
- Monitoring – Use CloudMonitor to track SLB health‑check status, backend instance CPU/memory, network throughput, and error rates. Set alarms on unhealthy instance counts to trigger incident response.
- Scaling – ALB supports auto‑scaling of backend server groups based on metrics; CLB and NLB require manual addition of instances, although scripts can automate this process.
- Patch management – Enable hot upgrades on the SLB to apply firmware or configuration updates without interrupting traffic. Regularly review release notes for security patches.
- Backup – Regularly snapshot ECS instance disks and export SLB configurations as JSON files. Store these artifacts in a separate OSS bucket for disaster recovery.
- Cost monitoring – Track elastic IP usage, data transfer, and SLB pricing tiers to avoid unexpected expense spikes.
Best practices
- Deploy at least two ECS instances in different zones to guarantee zone‑level redundancy.
- Use an ALB for HTTP/HTTPS services that need content‑based routing, header rewriting, or advanced health checks.
- Use an NLB for high‑throughput TCP/UDP workloads such as gaming, streaming, or database proxies.
- Keep SLB and ECS in the same VPC and region to minimize latency and avoid cross‑region data charges.
- Configure health checks with conservative thresholds (e.g., five consecutive failures before marking unhealthy) to avoid flapping caused by brief network hiccups.
- Leverage shared VPC for multi‑account governance while keeping gateway cost centralized and audit trails unified.
- Document DNS names, SLB domain names, and associated security‑group rules in a version‑controlled repository.
- Periodically test failover by manually terminating an ECS instance or disabling a zone in a staging environment.
Analysis
The sources provide clear guidance on the networking model, load‑balancing limits, and multi‑zone redundancy. The high‑availability pattern—multiple instances, a load balancer, and distribution across zones—is consistently described across the documentation. The SLB product comparison supplies concrete capacity limits that inform capacity planning, while the VPC documentation clarifies how private and public IP addressing works for ECS instances. Together these facts allow a practitioner to design a resilient architecture without relying on external benchmarks or undocumented assumptions.
What the sources do not settle
- Exact failover time when a zone becomes unavailable is not quantified; the documentation mentions zone‑level isolation but does not give a measurable recovery time objective.
- Cost implications of using multiple zones, shared VPC gateway fees, or elastic IPs are not covered, leaving budgeting decisions to be made based on pricing calculators.
- Guidance on choosing between ALB and NLB for mixed‑protocol workloads is limited to protocol support and capacity caps; performance trade‑offs such as latency overhead or connection‑setup time are not detailed.
Conclusion
By combining ECS instances, a VPC, and an appropriate SLB family, enterprises can build a highly available infrastructure that survives zone‑level failures and scales to meet traffic demands. The documented pattern of multi‑instance redundancy, health‑checked load balancing, and zone distribution provides a solid foundation. Teams should supplement this design with robust monitoring, regular backups, and clear governance policies to ensure long‑term reliability and compliance.
References
- High‑availability architecture on the cloud
- What is SLB?
- IP addresses of ECS instances within VPCs
These published CloudExchangers articles are further desk reading. They are not sources for the technical claims above.
