1. Overview
    1. Compute Engine resources are hosted in multiple locations worldwide
    2. Compute Engine resource locations are composed of regions and zones
    3. A region is a specific geographical location where resources can be hosted
    4. Most regions have three or more zones
    5. Resources in a zone, such as virtual machine instances or zonal persistent disks, are referred to as zonal resources
    6. Resources such as static external IP addresses are regional
    7. Regional resources can be used by any resources in that region, regardless of zone
    8. Zonal resources can only be used by other resources in the same zone
    9. To attach a zonal persistent disk to an instance, both resources must be in the same zone
    10. To assign a static IP address to an instance, the instance must be in the same region as the static IP address
    11. Putting resources in different zones in a region provides isolation from most types of physical infrastructure and infrastructure software service failures
    12. Putting resources in different regions provides a high degree of failure independence
    13. Putting resources in different regions allows customers to design robust systems with resources spread across different failure domains
    14. Communication within and across regions will incur different costs
    15. Generally, communication within regions will always be cheaper and faster than communication across different regions
    16. Design important systems with redundancy across multiple zones
    17. At some point in time, it is possible that instances might experience an unexpected failure
    18. To mitigate the effects of failure events, duplicate important systems in multiple zones and regions
  2. Zones and clusters
    1. Compute Engine implements a layer of abstraction between zones and the physical clusters where the zones are hosted
    2. A cluster represents a distinct physical infrastructure that is housed in a data center
    3. Each cluster has independent software infrastructure, power, cooling, network, and security infrastructure, and includes a large pool of compute and storage resources
    4. Each zone is hosted in one or more clusters and Compute Engine independently maps zones to clusters for each organization
    5. us-central1-a zone for one organization might not map to the same cluster as the us-central1-a zone for another organization
    6. Decoupling zones from clusters allows Compute Engine to ensure resources are balanced across the clusters in a region
    7. The list of zones to choose from remains manageable as Compute Engine continues to grow its regions over time by adding more clusters
    8. For most organizations, Compute Engine ensures that all projects in an organization have a consistent zone to cluster mapping
    9. For organizations with projects that use VPC Network Peering or Private services access to share networks or services with other organizations, Compute Engine tries to ensure that the peered organizations all have a consistent zone to cluster mapping
    10. In the case of large-scale SaaS providers, it might not be possible for Compute Engine to provide a consistent mapping for all peered organizations
    11. In the case of large-scale SaaS providers, Compute Engine ensures that the peered projects have a consistent zone to cluster mapping
  3. Location selection
    1. Each region in Compute Engine contains a number of zones
    2. Regions are collections of zones
    3. Zones have high-bandwidth, low-latency network connections to other zones in the same region
    4. In order to deploy fault-tolerant applications that have high availability, Google recommends deploying applications across multiple zones and multiple regions
    5. Deploying applications across multiple zones and multiple regions helps protect against unexpected failure of components, up to and including a single zone or region
    6. Choose regions that makes sense for each scenario
    7. If all customers are in the US, or if data needs to be stored in the US, it makes sense to store resources in zones in the us-central1 region or zones in the us-east1 region
    8. A zone is an isolated location within a region. The fully-qualified name for a zone is made up of <region>-<zone>. For example, the fully qualified name for zone a in region us-central1 is us-central1-a
    9. Depending on how widely a user wants to distribute resources, instances can be created across multiple zones in multiple regions for redundancy
    10. Each zone supports a combination of platforms
    11. When users create an instance in a zone, the instance will use the default processor supported in that zone, unless a CPU platform is specified
    12. Users can choose which region or zone hosts resources, which controls where data is stored and used
    13. Google designs zones to be independent from each other: a zone usually has power, cooling, networking, and control planes that are isolated from other zones, and most single failure events will affect only a single zone
    14. If a zone becomes unavailable, traffic can be transferred to another zone in the same region to keep services running
    15. Backup services should be running in a different region, should a region experience disturbances
    16. To decrease network latency, choose a region or zone that is close to the point of service
    17. Where customers are mostly on the East Coast of the US, choose a primary region and zone that is close to that area and a backup region and zone that is also close by
  4. Maintenance
    1. Google regularly maintains its infrastructure by patching systems with the latest software, performing routine tests and preventative maintenance, and generally ensuring that Google infrastructure is as fast and efficient as Google knows how to make it
    2. By default, all instances are configured so that these maintenance events are transparent to applications and workloads
    3. Google uses a combination of datacenter innovations, operational best practices, and live migration technology to move running virtual machine instances out of the way of maintenance that is being performed
    4. Instances continue to run within the same zone with no action on the customer's part
    5. By default, all virtual machines are set to live migrate, but can be set to terminate and reboot
    6. With Live migrate, Compute Engine automatically migrates running instance
    7. The migration process impacts guest performance to some degree but instance remains online throughout the migration process
    8. The exact guest performance impact and duration depends on many factors, but it is expected most applications and workloads will not notice
    9. With Terminate and reboot, Compute Engine automatically signals the instance to shut down, waits a short time for it to shut down cleanly, and then restarts it away from the maintenance event
  5. Deprecation
    1. It is never necessary to decommission an existing zone for a ground-up infrastructure refresh (power, cooling, network fabric, servers, and so on)
    2. Infrastructure refreshes are rare and zones typically run for three to five years between refreshes
    3. Refreshes should be transparent to customers
    4. If it ever becomes necessary to deprecate a zone, Compute Engine will notify users well in advance of when it will go offline so there is ample time to move virtual machine instances and workloads
  6. Quotas
    1. Certain resources, such as static IPs, images, firewall rules, and VPC networks, have defined project-wide quota limits and per-region quota limits
    2. When resources are created, it counts towards the total project-wide quota or per-region quota, if applicable
    3. If any of the affected quota limits are exceeded, it will not be possible to add more resources of the same type in that project or region