Cloud Computing Fundamentals and Alibaba Cloud Architecture
Core mental model
Alibaba Cloud organizes resources by region (geographic location) and zone (isolated datacenter within a region). A region is chosen for latency, compliance, and service availability; zones are chosen for fault isolation. Services are either regional (ECS, VPC, SLB) or global (RAM, CDN, DNS). Understanding which scope a resource belongs to is the single most tested fundamental.
The shared responsibility split
Alibaba Cloud secures the physical infrastructure, hypervisor, and managed-service platform. The customer secures guest OS patching, security groups, RAM policies, data classification, and application code. Questions that ask "who is responsible for X" usually hinge on whether X lives above or below the virtualization boundary.
Resource hierarchy
Accounts sit under an enterprise/organization structure with resource groups and tags for cost and permission scoping. RAM is identity; resource groups are organizational containers; tags are metadata. Mixing these up is a classic trap.
Traps to watch
- Assuming a zone failure is a region failure - multi-zone designs survive zone loss, not region loss.
- Confusing high availability (survive failure) with disaster recovery (survive region loss).
- Assuming all services are available in every region; check regional product availability.
- Treating SLB or ECS as global - they are regional and zone-scoped for instances.
Rule of thumb
Design for zone-level redundancy inside one region first; add a second region only when the RTO/RPO or compliance requirement explicitly demands region-loss survival, because cross-region replication adds cost and latency.
Worked example
A team needs 99.95% uptime for a web tier. Deploying two ECS instances in the same zone gives no protection against a zone outage. Spreading them across two zones in one region behind a multi-zone SLB removes the single-zone failure; adding a second region is only justified if a region-wide event is in scope.