Cloud computing, now an integral part of modern IT infrastructure, has revolutionized organizational operations by introducing key concepts such as cloud regions and availability zones (AZs), which provide critical advantages for developing reliable and highly available applications. Furthermore, these concepts allow for greater flexibility, scalability, and cost-efficiency, making cloud computing an increasingly attractive choice for businesses and organizations worldwide.
Cloud regions are distinct geographical areas where cloud providers operate data centers. Availability zones (AZs) are logical data centers within a cloud region. Cloud regions usually have multiple isolated AZs, with each AZ comprising one or more data centers located in close proximity.
Dgtl Infra explores the meanings of cloud regions and availability zones, their importance, and the factors to consider when organizations select a cloud region. Additionally, we examine the intricacies of multiple region and availability zone deployments, as well as the role of virtual private cloud (VPC) networks and subnets within these architectures.
What are Regions and Availability Zones?
The term “cloud” suggests an abstract and intangible storage space; however, in reality, the cloud represents physical data centers in specific geographical locations containing actual servers, storage systems, and other equipment. In cloud computing, a cloud service provider (CSP) owns and operates these data centers, provisioning them via a network connection.
READ MORE: Cloud vs Data Center – A Comprehensive Guide
To make their services readily accessible worldwide, CSPs usually organize their cloud infrastructure into different geographical regions, known as cloud regions. Cloud regions are essentially arbitrary geographical areas, which means each vendor may have distinct regions with varying names and boundaries. In practice, all cloud providers typically establish regions in key data center markets within the United States, Europe, Asia Pacific, and Latin America.
These cloud regions contain multiple availability zones (AZs). Each availability zone is a logical grouping of one or more closely located data centers. Although an AZ may comprise multiple data centers, no two AZs share the same data center. Each AZ is self-contained and physically isolated from other AZs in the same region to provide additional fault tolerance and resiliency.
This physical separation ensures that a failure or disruption in one AZ does not impact the availability or performance of other AZs in the region. In the event of a catastrophe, the best practice is to have at least two additional availability zones within the region to take over. While not all cloud providers have achieved this level of redundancy across all regions, it remains a common goal.
Importance of Understanding Cloud Regions and Availability Zones
Cloud regions and availability zones (AZs) are foundational to a highly available and resilient cloud deployment. Traditionally, organizations deployed applications in a single data center and occasionally in a second one for backup and disaster recovery. With the cloud, they can easily deploy applications across multiple AZs within a region for high availability.
Leading cloud service providers, including Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud, and IBM Cloud, all support and utilize these familiar concepts to improve application availability. Understanding cloud regions and availability zones can help organizations architect and deploy applications in optimal locations to address instant scalability, load balancing, high availability, and fault tolerance demands.
Region vs Availability Zone
An availability zone (AZ) consists of one or more discrete but closely located data centers. Data centers within a single availability zone are designed to remain operational in the event of a failure in any other data center within the same availability zone. Still, multiple data centers or buildings within a single availability zone are considered a single logical entity. They are treated as a single failure domain, as all the data centers in an availability zone face the same local physical risks, such as natural disasters or power failures.
A region is a set of availability zones in a designated geographical area. Each availability zone within a region is connected independently to all other availability zones within the same region using redundant, low-latency private fiber optic links, ensuring high-speed and reliable communication and replication. These independent interconnections prevent any one availability zone from becoming a single point of failure for communication between other availability zones.
How Many Availability Zones in a Region?
The number of availability zones (AZs) in a region varies depending on the cloud service provider. For example, Amazon Web Services (AWS) currently offers 3 to 6 AZs in each region, while Google Cloud provides 3 to 4 zones per region. In contrast, Microsoft Azure offers 1 to 3 AZs in each region, which means that many of its regions are supported by just a single AZ.
In general, the number of AZs in a region can change over time as cloud providers expand their infrastructure.
What are Cloud Regions?
Major cloud providers divide their operations into regions for fault tolerance and localized performance benefits. A region is not a monolithic data center but an arbitrary geographical area where the cloud provider has a physical presence and hosts one or more clusters of data centers called availability zones (AZs). For example, a cloud provider may have regions located in Dallas, Texas and San Francisco, California in the United States; London, UK and Paris, France in Europe; as well as Sydney, Australia and Tokyo, Japan in Asia Pacific.
All regions are isolated for fault tolerance but interconnected to each other and the internet via high-speed fiber optic networks. It is recommended to select a region and AZs closest to business operations to achieve the highest performance possible. However, not all regions or AZs are equal, and some services may only be available in specific regions or AZs.
Cloud customers can also opt to deploy their operations in one region and replicate them across multiple regions worldwide to establish a global presence and minimize network delays in other geographical areas.
Factors to Consider when Choosing a Cloud Region
When deploying applications and workloads across cloud infrastructure, it is important to consider the following factors when choosing a cloud region:
- Proximity: choose a region geographically closest to users and/or customers to reduce network latency and achieve the highest performance possible
- Feature Availability: when choosing a cloud region, it is crucial to verify that the required services are available in your preferred region. Importantly, not all services are available in every region due to factors such as regulatory restrictions, infrastructure limitations, and differences in user demand
- Compliance and Data Sovereignty: different regions have different regulations and compliance requirements for data storage and processing. Some jurisdictions also prohibit user data storage in outside territories. Choose a region that meets specific compliance needs
- Disaster Recovery: check the number of availability zones and their distribution in each viable region. The higher the number of AZs, the better the redundancy and resilience in case of outages or disasters
- Cost: cloud service provider pricing can vary considerably among regions. Before making a decision, consider the cost of using resources in the selected regions
- Network Connectivity: network infrastructure and connectivity options vary by region. Factors such as high-capacity backbone connections, redundant network paths, and dedicated connections to cloud service providers (e.g., AWS Direct Connect), can impact the performance, reliability, and cost of applications
Multiple Region Deployments
Since each cloud region is completely isolated from every other region, organizations often choose to replicate data hosted in one region to another. Multiple region deployments help with business continuity and data recovery, minimizing the risk of a single point of failure. When one region loses data or experiences an outage, the workloads can be configured to shift automatically to other regions for business continuity. This concept of a system’s ability to remain operational even if certain parts fail is known as fault tolerance.
Another advantage of deploying resources in multiple regions is the reduced latency for end users. This is because they can access cloud resources through data centers located in the region nearest to their physical location.
Examples of Cloud Regions
Below are examples of cloud regions from the leading cloud service providers (CSPs):
Amazon Web Services (AWS)
Amazon Web Services (AWS) has launched 31 cloud regions located all over the world, including in North America, South America, Europe, Asia Pacific, and the Middle East. Examples of AWS regions include: us-east-2 (located in Columbus, Ohio), eu-west-3 (located in Paris, France), and ap-southeast-2 (located in Sydney, Australia).
READ MORE: Amazon Web Services (AWS) Regions and Availability Zones
Microsoft Azure has launched over 60 cloud regions worldwide, including in North America, South America, Europe, Asia Pacific, and Africa. Examples of Microsoft Azure regions include: East US (located in Virginia, United States), West Europe (located in Amsterdam, Netherlands), and Southeast Asia (located in Singapore).
READ MORE: Microsoft Azure’s Regions and Availability Zones
Google Cloud Platform (GCP)
Google Cloud Platform (GCP) has launched 37 cloud regions spread across the world, including in North America, South America, Europe, Asia Pacific, and the Middle East. Examples of Google Cloud regions include: us-central1 (located in Iowa, United States), europe-west2 (located in London, UK), and asia-southeast1 (located in Singapore).
READ MORE: Google Cloud’s Regions and Availability Zones
What is an Availability Zone?
An availability zone (AZ) can be understood as a logical data center entity that may comprise one or more closely located physical data centers or buildings. Although it may consist of multiple facilities, an AZ operates as a single failure domain.
Typically, cloud regions encompass at least two, ideally three, availability zones (AZs). All AZs are fully independent, featuring redundant power, cooling, and networking resources, and are interconnected within a region via dedicated high-bandwidth, low-latency links.
Data transfer rates between AZs in a region are extremely fast, typically ranging from 10 to 400 gigabits per second (Gbps), with latencies as low as a few milliseconds. While some communication between regions occurs over the public internet, communication between AZs never leaves the cloud service provider’s private network.
The precise distance between AZs depends on the region and the specific cloud provider. For instance, to deliver Azure Cloud Services in Northern Virginia, Microsoft has set a self-imposed requirement for its data centers to be located within approximately 12.5 miles (20 kilometers) of existing data centers in their regional network.
In any case, AZs are designed to be sufficiently distant to reduce the likelihood of a single event impacting multiple AZs, such as natural disasters or power outages, while maintaining close proximity for low-latency connectivity in replication and failover scenarios.
Organizations usually choose the AZ closest to their physical location. Moreover, it is advisable to run redundant workloads across geographically dispersed AZs to take advantage of the high availability and resiliency they offer.
Multiple Availability Zones Deployments
When organizations host or replicate resources across multiple AZs, an AZ can no longer become a single point of failure. Organizations can design their cloud infrastructure to automatically fail over between AZs to avoid interruptions in case of malfunction or downtime. Deploying virtual machines (VMs) in multiple AZs within the same region does not incur any additional charges; however, there is a cost for data transfer between VMs located in different AZs.
Fault Tolerance vs High Availability
Organizations can achieve high availability by replicating resources across multiple AZs within the same region. However, fault tolerance is a slightly different concept that requires deployment or replication across multiple regions. Fault-tolerant infrastructures are inherently highly available as they also replicate resources within the region. Nonetheless, highly available infrastructure may or may not be fault-tolerant depending on whether there is replication across multiple regions.
Availability Zone Designations
Major cloud service providers (CSPs) all use slightly different terminology to refer to availability zones (AZs).
- Amazon Web Services (AWS): AWS uses the term availability zone (AZ). AWS offers 99 AZs across its 31 launched regions. Availability zones are identified within the AWS resource configuration process. For example, the us-east-1 region (located in Northern Virginia) will have us-east-1a as the first AZ and us-east-1d as the fourth AZ
- Microsoft Azure: Microsoft uses the term availability zone (AZ). Azure offers more than 115 AZs across its over 60 launched regions
- Google Cloud Platform (GCP): Google uses the term zone. The company offers 112 zones across its 37 launched regions
- Oracle Cloud Infrastructure (OCI): Oracle uses the term availability domain. The company offers more than 50 availability domains across its 41 launched regions
- IBM Cloud: IBM uses the term availability zone (AZ). The company offers 27 AZs across its 9 launched regions
It is worth noting that a CSP’s specific number and location of AZs can change over time.
Virtual Private Cloud (VPC) Networks
A virtual network, also known as a virtual private cloud (VPC) network, is a software-defined network (SDN) created within a cloud computing environment. It provides a logical grouping of cloud infrastructure resources and enables organizations to securely connect and isolate their cloud resources, such as virtual machines (VMs), containers, and storage instances, from other networks and the internet. VPC networks allow organizations to create and control their private network within a cloud service provider’s public infrastructure, offering greater flexibility, scalability, and control over their infrastructure.
Each resource in the virtual network is assigned an IP address and can communicate with the other resources securely based on well-defined rules without having to traverse the public internet. By creating a VPC network in a specific region and AZs, organizations can have granular control over where their resources are deployed. This enables them to ensure that their resources are located close to their customers and other resources they need to interact with. Organizations can connect to the virtual network in a few different ways, such as over the public internet, via a VPN connection, or through a direct, physical link.
Each cloud service provider (CSP) has its own implementation of a virtual network, but they all provide similar functionalities. Virtual network products from the major CSPs include:
- Amazon Virtual Private Cloud (VPC)
- Azure Virtual Network (VNet)
- Google Cloud’s Virtual Private Cloud (VPC)
- Oracle’s Virtual Cloud Network (VCN)
- IBM’s Virtual Private Cloud (VPC)
Subnets – Network Segments within VPCs
Organizations can create multiple subnets to further divide the VPC network into smaller logical networks within a single AZ. They have the flexibility to choose whether to make the subnets public or private, which can help them isolate different parts of their infrastructure and control access between the different subnets.
By default, all public subnets within a virtual network can communicate with one another and with the internet. However, organizations can change this setting to restrict access to a subnet’s resources, making it a private subnet.
To effectively utilize resources within a region, organizations need to properly organize them into network segments or subnets. For example, organizations can isolate their production servers from their development and staging servers to prevent any data leakage. Private network managers can subdivide their allocated IP addresses into hundreds of smaller subnets, although the exact number may vary depending on the CSP.