What's changed: Created Professional Cloud Architect Chapter 2 (Domain 1 "Design and plan" part 2: HA/scalability/DR = zonal/regional/multi-region, MIG/autoscaling, load balancers, RTO/RPO, backup/warm/hot standby; migration and hybrid = lift-and-shift/improve-and-move/refactor, Migrate to VMs/DMS/Storage Transfer/Transfer Appliance, Cloud VPN/Interconnect, phased migration).
2.1Designing for high availability, scalability, and disaster recovery
Understand availability levels (zonal/regional/multi-regional), elasticity via managed instance groups (MIGs) and autoscaling, traffic distribution via load balancers, and disaster recovery strategies (backup-and-restore, warm/hot standby) based on RTO/RPO.
Production systems must stay up and scale with load. The architect designs availability, scalability, and disaster recovery to match requirements (and cost).
2.1.1Availability and scalability
Availability comes from spread: single zone (weak) → multi-zone region (tolerates zone failure) → multi-region (tolerates regional failure, best). Elasticity uses managed instance groups (MIGs) and autoscaling to auto-scale VMs with self-healing. Distribute inbound traffic via load balancers (global/regional, L7/L4) to healthy backends. Map "tolerate zone failure = regional (multi-zone)" and "tolerate regional failure = multi-region."
2.1.2Disaster recovery (RTO/RPO)
Design disaster recovery (DR) by two targets: RTO (recovery time objective—how fast to restore) and RPO (recovery point objective—how much data loss is acceptable). With loose RTO/RPO, choose cheap backup-and-restore; with strict targets, warm standby (scaled-down on standby) or hot standby (fully running redundancy). Stricter targets cost more. Map "shorter RTO/RPO = costlier architecture."
Common: requirement → architecture. E.g., "tolerate zone failure" = regional (multi-zone); "tolerate regional failure" = multi-region; "auto-scale with load" = MIG + autoscaling; "low-latency global delivery" = global external LB; "recover within minutes" = warm/hot standby; "some loss/time acceptable" = backup-and-restore.
Watch the mix-ups: (1) Do not confuse RTO (time) and RPO (data loss). (2) Availability comes from spread (single zone is weak to regional failure). (3) Stricter RTO/RPO costs more—match the architecture to the requirement.
2.1.3Section summary
- Availability = zone < region (multi-zone) < multi-region; elasticity via MIG + autoscaling
- Load balancers distribute to healthy backends (global/regional, L7/L4)
- Design DR by RTO (time)/RPO (loss); stricter = warm/hot standby (costlier)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To tolerate a single-zone failure, which placement best fits?
Q2. To auto-scale VMs with load and self-heal on failure, what do you use?
Q3. You need the highest availability that tolerates a whole-region failure. Which placement?
Q4. Which correctly contrasts RTO and RPO?
Q5. Which DR strategy tolerates some recovery time/data loss to cut cost?
Q6. For a strict RTO requiring recovery within minutes, which DR strategy best fits?