Zonal vs Regional Services
Whether a cloud resource lives in one availability zone or is inherently spread across several — a property that determines what a zone failure takes with it.
Every cloud resource is one or the other, and knowing which for each component of a design is the substance of zone-level availability planning.
Zonal: virtual machines, block volumes, some database instances, NAT gateways, single-zone subnets. A zone failure takes them with it. Redundancy is your responsibility — run instances in several zones behind a load balancer, and replicate volumes rather than relying on them.
Regional: object storage, managed load balancers, most managed queues, and multi-AZ database deployments. The provider handles the zonal spread internally.
The design exercise is to walk each component and label it, then ask what happens to the zonal ones when their zone fails. What this reliably surfaces: a NAT gateway in a single zone that all private egress depends on; a volume holding state with no replica; a cache cluster deployed to one zone; and stateful workloads assumed to be highly available because they run on a platform that is.
Two things worth checking beyond the label. Multi-AZ is often not the default and must be selected — and it typically doubles the cost, which is why it is sometimes quietly disabled in non-production and then copied into production. And a regional service still has a regional control plane, so regional does not mean immune.