5.2 Regional Resource Placement & High Availability Planning

Why Regional Placement Planning Matters

Domain 2 of the ACE exam guide asks candidates to plan "availability of resource locations" — in plain terms, deciding whether a workload should live in one zone, span multiple zones in a region, or spread across multiple regions. This decision drives both the availability SLA a workload can achieve and its cost and latency profile, and it shows up constantly in ACE scenario questions framed as "the application must survive a zone outage" or "must survive a regional outage."

Regions and Zones: The Physical Model

Google Cloud's infrastructure is organized into regions (independent geographic areas, such as us-central1 or europe-west1) and zones (isolated deployment areas within a region, such as us-central1-a, each mapping to distinct physical infrastructure with its own power, cooling, and networking). As of mid-2026, Google Cloud operates 43 regions and 130 zones worldwide, and most regions contain three or more zones spread across three or more physical data centers (a handful of newer regions — Stockholm, Mexico, Osaka, and Montreal — currently run three zones across only one or two physical buildings). Zones within a region are connected by high-bandwidth, low-latency links, which is what makes cross-zone replication practical for both compute and storage.

Zonal vs. Regional vs. Multi-Regional Resources

A zonal resource is the cheapest and simplest, but a zone-level incident (power loss, network partition, a bad rollout) takes it offline with no automatic recovery. A regional resource — most importantly a Regional Managed Instance Group spanning two or more zones, or a Regional Persistent Disk, which synchronously replicates data across two zones in the same region — keeps running if any single zone in that region fails, because healthy capacity in the surviving zone(s) absorbs the load. A multi-regional resource goes a step further, replicating across geographically separate regions so an entire region can be lost without an outage — the pattern used for global Cloud Storage buckets and multi-region Spanner configurations.

SLA Numbers Worth Memorizing

Compute Engine's published Service Level Agreement draws a clear line between these placement choices: a single-zone instance is covered at 99.5% monthly uptime (assuming SSD or Balanced Persistent Disk), while an instance workload running as a Regional Managed Instance Group across two or more zones is covered at 99.99% monthly uptime. That's the difference between roughly 3.6 hours of allowed downtime per month and about 4.4 minutes — a gap large enough that "which SLA tier does this architecture qualify for" is a recurring ACE exam pattern. The same logic extends to Cloud SQL: enabling High Availability (HA) configuration creates a standby instance in a second zone with synchronous replication and automatic failover, moving a database from a single point of failure to a design that survives a zone outage.

Choosing a Region: Beyond "Closest to My Users"

Region selection is a planning decision, not just a technical one. Candidates should weigh:

• Latency — placing compute close to end users or to a dependent on-premises system minimizes round-trip time.
• Compliance and data residency — some workloads (regulated financial or health data, government contracts) must stay within a specific country or economic region.
• Service and SKU availability — not every Google Cloud product or machine type is available in every region; newer regions sometimes lag on GPU/TPU SKUs or specific managed services.
• Pricing — compute, storage, and especially egress pricing vary by region; multi-region architectures should account for the cost of cross-region replication traffic, not just the storage itself.
• Disaster recovery posture — an active-passive design (standby resources in a second region, activated on failover) costs less to run but recovers more slowly than active-active (traffic already split across two regions), which costs more but has near-zero recovery time.

Exam Scenarios

Scenario 1: A retail company's checkout service must stay available if a single Google Cloud zone experiences an outage, but a full regional outage is an acceptable (rare) risk given the budget. Answer: Deploy a Regional Managed Instance Group across at least two zones in one region, backed by a Regional Persistent Disk or a stateless design — this meets the 99.99% SLA tier without paying for full multi-region redundancy.

Scenario 2: A hospital network's patient records database cannot go offline even if an entire Google Cloud region fails, and it must remain queryable with strong consistency. Answer: A multi-region Spanner configuration (or Cloud SQL cross-region read replicas with a documented promotion runbook) — the workload needs to survive a regional, not just a zonal, failure.

Scenario 3: A company wants to minimize cost for a small internal reporting tool used only by employees on one office floor, with no availability requirement beyond business hours. Answer: A single zonal VM is appropriate — spending on regional or multi-regional redundancy would be over-engineering for the stated requirement.

Common Traps

• Assuming a regional resource automatically also protects against a regional outage — it does not; regional resources are built to survive a zone failure inside one region, not the loss of the entire region.
• Forgetting that a Regional Persistent Disk needs to be explicitly created as regional (--replica-zones) — attaching a zonal disk to instances in two zones does not make it regionally redundant.
• Over-provisioning multi-region architectures for workloads whose actual availability requirement (as stated in the scenario) is much lower — the exam rewards matching the architecture to the stated requirement, not defaulting to the most redundant option every time.

Key Takeaways

• Google Cloud organizes infrastructure into 43 regions and 130 zones (mid-2026); zones within a region share low-latency links, enabling synchronous cross-zone replication.
• Zonal resources have no built-in failure protection; regional resources (spanning 2+ zones) survive a single zone outage; multi-regional resources survive a full region outage.
• Compute Engine's SLA moves from 99.5% (single zone) to 99.99% (regional, multi-zone) — memorize this jump, since ACE scenario questions often hinge on matching the stated availability requirement to the cheapest architecture that meets it.