Global, regional, and zonal resources
Now, of course, there is no free lunch in life and you have to pay for (almost) all of this, and the payment models are going to differ. For instance, with persistent disks, you pay for the capacity that you allocate, whereas with cloud storage buckets, you pay for the capacity that you actually use. However, the basic idea is that there are resources that will be billed. All billable resources are grouped into entities named projects.
Let's now look at how resources are structured. The way the Google Cloud Platform operates, all resources are scoped as being the following:
- Global
- Regional
- Zonal
Now you might think that this geographical location of resources is an implementation detail that you shouldn't have to worry about, but that's only partially true. The scoping actually also determines how you architect your cloud applications and infrastructure.
Regions are geographical regions at the level of a subcontinent—the central US, western Europe, or east Asia. Zones are basically data centers within regions. This mapping between a zone and a data center is loose, and it's not really explicit anywhere, but that really is what a zone is.
These distinctions matter to use as an end users because regional and zonal resources are often billed and treated differently by the platform. You will pay more or less depending on the choices you make regarding these levels of scope access. The reason that you pay more or less is that there are some implicit promises made about performance within regions.
For instance, the Cloud Docs tell us that zones within the same region will typically have network latencies in the order of less than 5 milliseconds. What does typical mean? Well here, it is the 95 percentile delay latency, that is, 95% of all network traffic within a region will have latency of less than 5 ms. That's a fancy way of saying that within a region, network speeds will be very high, whereas across regions, those speeds will be slower.
Cost and latency are two reasons why these geographical choices are important to you, another has to do with failure locations. Zones can be thought of as single failure domains within a region. Now common sense says that, basically, it is a data center, so you might want to create different versions of resources situated in different zones or even in regions depending on your budget and your user base. That's because a zone is a single failure domain. Zones reside inside regions, and they are identified using the name of the corresponding region as well as a single lowercase letter, asia-east1-a for instance. A zone is a single point of failure in Google's data center network. Zones are analogous to Availability Zones in AWS. If you replicate resources across different zones, such architecture can legitimately be termed as high-availability architecture.
If a resource is available globally, it's known as a global or a multiregional resource. These multiregional resources tend to be the most expensive, the most available, and also the most widely replicated and backed up kind of resources. One level down come regional resources; these only need to be backed up to different data centers within the same region and then at the bottom of this access hierarchy are the zonal resources. These only need to be replicated within the same data center.
There are lots of examples in each of these categories, for instance, tools such as Cloud Storage, DataStore, and BigQuery. All of this can be global or multiregional; this makes sense intuitively, as we expect storage technologies to be global rather than regional (Cloud SQL and BigTable are regional; however, Cloud Spanner can be either regional or multiregional).
On the other hand, compute tends to be regional or zonal. AppEngine is regional, whereas VM instances are zonal. Disk storage that takes the format of either persistent ordinary hard disks or persistent SSD disks is zonal as well. Disks need to be local, and they need to be in the same zone as the corresponding virtual machine instance they are used by:
