Business Challenge
A team is asked to make an application multi-region. It runs happily in one zone of one region, and the plan they write is the one their instincts hand them: stand up a second network in the second region, copy the firewall rules across, and peer the two together.
A VPC network is a global resource. The existing network already spanned every region in the project. What the second region actually needed was a subnet — subnets are regional — inside the network that was already there.
Correct approachAdd a regional subnet to the existing global network. A second network is a deliberate isolation decision, not a step in expanding to another region.
Firewalls are global too. The rule written months earlier for the first region was already applying to the new one the moment its instances joined the network. Copying it created a duplicate; the real risk was the rules nobody re-read, which had quietly widened.
Correct approachRead the existing rules before expanding, not after. Adding a region does not create a fresh security boundary — it enters an existing one.
An instance cannot access per-zone resources in a different zone, such as a disk. Rebuilding into the neighbouring zone to dodge a capacity problem left the data behind, because a zonal Persistent Disk does not follow.
Correct approachDecide early whether the disk is zonal or regional. Moving a zone is not a redeploy; for zonal disks it is a data migration.
Machine types are zonal resources. A shape that exists in one zone is not guaranteed in the zone next door, so a template that worked in the original zone failed on first launch elsewhere.
Correct approachCheck machine type availability per zone before committing a design to one, and prefer families available across the zones you intend to spread over.
All four come from the same root: assuming the scope of a resource rather than looking it up. The scopes are documented plainly, and they are not the ones an instinct formed on another platform supplies.
A narrower scope can use a wider one — a zonal instance can use a regional subnet and a global image. The reverse never holds. Almost every surprise in this post is somebody expecting a wider resource to be narrow, or a narrow one to follow them around.
Architecture
There are three scopes. Global resources are accessible by resources in any region or zone. Regional resources are accessible only within the same region. Zonal resources are accessible only within the same zone, and may reach regional and global resources above them.
What is actually in each scope
Global: VPC networks, firewalls, images, snapshots, instance templates, global static external IP addresses and Cloud Interconnects.
Regional: subnets, regional static external IP addresses, regional managed instance groups, regional instance templates and Cloud Interconnect attachments.
Zonal: compute instances, zonal Persistent Disks and Hyperdisks, machine types, zonal managed instance groups, GPUs and Cloud TPUs.
Two of those placements do most of the work. The network being global means one network spans your whole estate, so "add a region" is a subnet, not a build. And machine types being zonal means the menu of available shapes is a per-zone question rather than a per-region one.
The two cross-zone rules
They sit next to each other in the documentation and they pull in opposite directions, which is why the boundary is easy to misjudge.
An instance cannot access per-zone resources in a different zone, such as a disk. Storage does not reach across a zone boundary.
An instance can communicate with an instance in another zone, provided both belong to the same VPC network. Traffic does reach across, because the thing carrying it is global.
So a zone boundary is a hard wall for attachment and no wall at all for networking. Designs that treat it as uniformly hard build unnecessary per-zone plumbing; designs that treat it as uniformly soft discover the disk problem during an incident.
Zones and regions, precisely
Regions are collections of zones, and zones have high-bandwidth, low-latency network connections to other zones in the same region. A zone is a deployment area within a region, named as the region identifier plus a letter — us-central1-a.
That low-latency link between zones in a region is what makes spreading across zones cheap in practice. It is the reason the default answer to "how do I survive an outage" starts with multiple zones rather than multiple regions.
Why This Architecture Holds Up
Scope reads like an addressing detail. It is really a statement about what fails together, which is why it belongs this early in the series rather than in the networking phase.
Google's own guidance puts it plainly: putting resources in different zones in a region reduces the risk of an infrastructure outage affecting all resources simultaneously, and putting them in different regions provides an even higher degree of failure independence.
Read alongside the scope list, that produces a design rule. Anything zonal is something you need at least two of, in different zones, if it matters. Anything regional survives a zone but not a region. Anything global is not a redundancy problem at all — it is a blast-radius problem, because a mistake in it applies everywhere at once.
Global is convenient and it is also the widest possible blast radius. A firewall rule is global, so a rule loosened for one workload in one region is loosened for every region on that network. The same property that spares you from rebuilding the network per region removes the natural containment that a per-region network would have given you for free.
What to actually decide, and when
The scope of a resource is fixed by the platform, so the decision is not what scope something has — it is which scope you choose when the platform offers both.
That choice appears repeatedly: a zonal or regional managed instance group, a zonal or regional Persistent Disk, a regional or global static external IP address. In each pair the wider option costs more or constrains more, and buys survival of a zone failure. Making that choice deliberately, per workload, is most of what "designing for availability" means on this platform.
The trap is defaulting. The zonal option is usually the simpler one to create, so an estate drifts toward zonal resources without anyone deciding that the application should not survive a zone.
Reading a resource's scope off its name
There is a practical habit worth forming early: the scope is usually visible in how a resource is addressed. A zonal thing needs a zone to identify it, a regional thing needs a region, and a global thing needs neither.
When a command or a Terraform resource asks for a zone, it is telling you the thing you are creating will not survive that zone. That is a more reliable signal than memory, and it works for services this post has not covered.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| Expanding to a second region | Add a subnet to the existing network | VPC networks are global and already span every region. A second network is an isolation decision, not an expansion step. |
| Firewall rules when adding a region | Review the existing ones first | Firewalls are global. The new region enters rules already in force rather than starting from a clean boundary. |
| Persistent Disk: zonal or regional | Regional for anything that must survive a zone | An instance cannot attach a disk in another zone, so a zonal disk turns a zone move into a data migration. |
| Managed instance groups | Regional unless there is a reason not to | The zonal variant is easier to create and quietly decides the workload will not survive a zone failure. |
| Machine type selection | Verify availability in every zone you intend to use | Machine types are zonal. A shape present in one zone is not guaranteed next door, and the failure lands at first launch. |
| First step toward availability | Multiple zones in one region | Zones in a region have high-bandwidth, low-latency links, which is what makes spreading across them cheap enough to be the default. |
| Changes to a global resource | Treat as an estate-wide change | Global means every region at once. The blast radius of a mistake is the whole network, not the region you were thinking about. |
| Working out an unfamiliar resource's scope | Look at what identifies it | If it needs a zone to name it, it dies with that zone. That signal generalises to services this post does not list. |
Every zonal-or-regional pair has an easier half, and it is always the zonal one. An estate that never makes that choice explicitly ends up single-zone by accumulation — not because anyone decided the application could tolerate losing a zone, but because the simpler option was chosen eight times in a row.
Closing Thought
Location scope is the least glamorous topic in this phase and the one that quietly constrains the most. It determines what a resource can attach to, what can talk to it, what fails with it, and how far a mistake in it travels.
The part worth carrying into the networking phase is the shape of the assignment: the network is global, its subnets are regional, and the machines are zonal. Almost every design question later in this series is a consequence of those three facts sitting at different levels.
#9 covers multi-region and dual-region locations: what those location types actually mean for storage, how they differ from simply running in two regions, and the choice they force between availability, latency and where your data is allowed to be.
Comments