Cloud resources, of course, are still physical devices located somewhere on planet Earth. So even though your resources are stored in the cloud, you will still have to choose where they will be used. Selecting your Region and Availability Zone are about the first option when setting up any cloud resource.
A Zone is a single logical datacenter with its own power, network, and cooling resources. The Zone’s power, network, and cooling resources are independent of any nearby or collaborating Zones. One or more buildings may provide the physical space for the Zone’s compute and storage devices, however all of the buildings in the Zone are generally considered one failure domain because they share network/power/cooling resources and are subject to the same local physical risks such as weather and fire.
A Region is set of collaborating Zones (datacenters) grouped together based on their geographical proximity. The Zones within a Region are connected with high-speed networking to facilitate low-latency communication between compute instances and reliable replication of data. These connections are done in such a way that no Zone becomes a point of failure between for an unrelated zone. That is, Zone 1 and Zone 3 must be able to communicate even if Zone 2 is down.
Applications should be deployed across multiple Zones in a Region as a foundation for achieving high availability. Most high availability deployment architectures start by deploying an application into 3 zones so that when one zone has a problem there are at least two healthy zones serving customer traffic and keeping data safe.
An Availability Zone is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there’s a minimum of three separate zones in all enabled regions. The physical separation of Availability Zones within a region protects applications and data from datacenter failures. Zone-redundant services replicate your applications and data across Availability Zones to protect from single-points-of-failure. With Availability Zones, Azure offers industry best 99.99% VM uptime SLA. The full Azure SLA explains the guaranteed availability of Azure as a whole.
An Availability Zone in an Azure region is a combination of a fault domain and an update domain. For example, if you create three or more VMs across three zones in an Azure region, your VMs are effectively distributed across three fault domains and three update domains. The Azure platform recognizes this distribution across update domains to make sure that VMs in different zones are not scheduled to be updated at the same time.
A regional pair consists of two regions within the same geography. Azure serializes platform updates (planned maintenance) across regional pairs, ensuring that only one region in each pair updates at a time. If an outage affects multiple regions, at least one region in each pair will be prioritized for recovery.
Some Azure services take further advantage of paired regions to ensure business continuity and to protect against data loss. Azure provides several storage solutions that take advantage of paired regions to ensure data availability. For example, Azure Geo-redundant Storage (GRS) replicates data to a secondary region automatically, ensuring that data is durable even in the event that the primary region isn’t recoverable.
Note that not all Azure services automatically replicate data, nor do all Azure services automatically fall-back from a failed region to its pair. In such cases, recovery and replication must be configured by the customer.
Resource groups (RG) & Azure Resource Manager (ARM).
Resource groups (RG) is used to group a collection of assets in logical groups for easy or even automatic provisioning, monitoring, and access control, and for more effective management of their costs. One benefit of using RGs in Azure is grouping related resources that belong to an application together, as they share a unified lifecycle from creation to usage and finally, de-provisioning. It help in applying restricted access to specific employees on RG with Azure policy.
Resource can be anything VM, virtual network, Table structure, Sql DB. Resource group can be into a specific subscription and Subscription get managed by Management group.
The underlying technology that powers resource groups is the Azure Resource Manager (ARM). ARM was built by Microsoft in response to the shortcomings of the old Azure Service Manager (ASM) technology that powered the old Azure management portal. With ASM, users could create resources in an unstructured manner, leading to many challenges in tracking such resources or understanding their dependencies. This led to huge difficulties that discouraged people from using Azure, as they would have a big mess once they had to deal with multiple applications that spanned more than one region.
To better understand this challenge, imagine you wanted to create an application in the old Azure management portal. To do so, you would create the virtual networks, the storage account(s), the cloud services, virtual machines, and potentially many other components of that application — without the ability to group them. If you were to build or deploy more than one application, it would become a difficult to find which resources depended on which, what order to create them by, or even which application they belonged to.