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?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.