Billing, Support and Service Usage
Core concepts
Billing models: pay-as-you-go (hourly/usage, flexible), subscription (prepaid term, discounted), savings plans/reserved capacity for steady workloads, and spot/preemptible instances for fault-tolerant batch work. Costs accrue from compute, storage, network egress, and requests. Alibaba Cloud Cost Center shows bills, budgets, and cost analysis; tags enable cost allocation.
Support plans differ in response time and channels (basic, developer, business, enterprise). Service quotas/limits cap resources per region and can be raised via tickets. Free tiers and trials exist but have limits.
Traps in questions
- Egress vs. ingress: inbound data transfer is often free; outbound (egress) is billed. CDN can reduce origin egress but adds CDN cost.
- Spot interruption: spot instances can be reclaimed; never use them for stateful, always-on production.
- Stopped vs. released billing: stopped subscription instances may still incur storage charges; releasing stops compute billing but deletes resources.
- Support plan scope: a higher support tier does not change service quotas automatically.
- Reserved savings require commitment: they save money only if usage is steady.
Rule of thumb
Match billing to workload shape: steady → subscription/reserved, variable → pay-as-you-go, interruptible → spot. Always model egress and storage, not just compute.
Worked example
A batch image-processing job runs a few hours nightly and can restart. Use spot instances with checkpointing and OSS for intermediate output. Subscription instances would idle most of the day and waste money; spot fits the interruptible profile.
Architecture Best Practices and Application Scenarios
Core concepts
The Well-Architected Framework pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Apply them together: multi-zone deployment for reliability, least privilege for security, right-sizing and autoscaling for cost and performance, and automation for operations.
Common patterns: stateless web tier behind SLB with Auto Scaling; decoupled tiers using message queues; read scaling with caches and read replicas; static content on OSS + CDN; private networking with NAT for egress; backup and DR with cross-zone snapshots and cross-region copies for critical data. Loose coupling and idempotency improve resilience.
Traps in questions
- Single-instance "simplicity": cheaper but fails availability; questions asking for HA require multi-zone and redundancy.
- State on compute: storing uploads or sessions on instance disks breaks horizontal scaling; move state to OSS, a database, or a cache.
- Over-engineering: a small internal tool may not need multi-region active-active; match design to requirements.
- Cache as source of truth: caches and replicas can be stale; critical writes go to the primary.
- Ignoring egress and DR costs: a design can be technically correct but economically poor.
Rule of thumb
Ask three questions for every scenario: What must not fail? What must scale? What must stay cheap? The answer determines redundancy, elasticity, and billing choices.
Worked example
A flash-sale web app must handle spikes and survive a zone failure. Use an SLB across two zones, Auto Scaling for the stateless web tier, Redis for session and hot data, RDS with a standby for the database, and OSS+CDN for assets. A single large ECS instance with local sessions fails both the scaling and availability requirements.