Microsoft Azure relies on a few key architectural components to provide redundancy and high availability. Core Azure architectural components include Azure regions, Azure Availability Zones, resource groups, and the Azure Resource Manager.
In this article, we’ll discuss the basics about each component and the functionality it provides. For a deeper dive into Azure Resource Manager, Availability Zones, regions, resource groups, and other Azure architectural components, check out our AZ-900 Learning Path: Microsoft Azure Fundamentals.
Azure Regions
The Azure region is a set of data centers that are deployed within a latency-defined perimeter, and connected via an underlying dedicated regional low-latency network. There are currently 42 regions available around the world, with another 12 additional Azure regions planned for the future.
Paired regions
Microsoft operates Azure data centers all over the world, in many different locations (otherwise referred to as geographies). A geography in Azure refers to an area of the world where at least one Azure region resides. An Azure region refers to an area within a geography that contains one or more Azure data centers.
To facilitate high availability, each Azure region is paired with another region that’s located within the same geography. This pairing is called a “regional pair.” While almost all regional pairs consist of regions with the same geography, there is one exclusion: Brazil South. Brazil South is the only region that is paired with another region outside of its geography.
Regional pairs allow Azure to serialize platform updates and planned maintenance. This ensures that only one paired region is updated at a given time. In the event of an unplanned outage that affects multiple regions, Microsoft prioritizes at least one region in each pair for troubleshooting and recovery.
Microsoft recommends that organizations configure business continuity disaster recovery, or BCDR, so that it spans across regional pairs. Doing so allows the organization to take advantage of Azure’s isolation and availability policies. Applications that can support multiple active regions should be deployed so that they use both regions in a region pair whenever possible. This ensure optimal application availability and minimizes recovery time in the event of a disaster occurring.
Azure Availability Zones
Availability Zones is an Azure offering that is used to protect applications and data centers from data center failures. Each Availability Zone is a unique physical location within an Azure region, and each zone is supported by one or more data centers, equipped with their own independent power, cooling, and networking infrastructure.
Each Availability Zone within an Azure region is comprised of a combination of fault domains and update domains. In a scenario where three or more virtual machines (VMs) are deployed across three different zones in an Azure Region, those virtual machines would be distributed across three different fault domains and three different update domains. Azure recognizes such a distribution across update domains and ensures that virtual machines in different zones are not updated at the same time.
Resiliency is achieved through the existence of at least three separate Availability Zones in each enabled Azure Region. Because Availability Zones are physically separate within each region, applications and data are inherently protected from data center failures. With zone-redundant services replicating apps across Availability Zones, there is no single point-of-failure to deal with.
Azure offers a 99.99% VM uptime SLA for virtual machines that are deployed in an Availability Zone.
Resource Groups in Azure
Resource groups are logical containers in Azure. They hold related Azure resources that are part of a larger Azure solution. These resource groups can host all resources that comprise an overall Azure solution, or they can also host just the resources that need to be managed as part of a group. The administrator gets to decide, based on needs, how to allocate resources in resource groups within Azure.
When working with Azure resource groups, there are a few things to consider. First and foremost, since all resources within a single resource group usually share a similar lifecycle, it’s important to determine the lifecycle of the resources you plan to place in a single resource group. An example of this would be a scenario where you are deploying a web application that relies on a database server. If the database server is only used to host the database for the web app, then it would make sense to host the database server and web app in the same resource group. However, if the database server hosts databases for other applications, its lifecycle is likely different from the web app. That said, the database server might belong in a different resource group with resources that share its lifecycle.
Because a resource can only exist in one resource group, it’s important to determine the best location for the resource. That said, resources CAN be moved between resource groups if necessary. On a similar note, it’s important to understand that a resource group can contain resources from different regions. That said, resource groups are often used to scope access control to resources and to better-organize billing and resource management.
While resources within a resource group are logically separated from resources in other resource groups, this doesn’t prevent the resources from communicating with one another. In fact, it’s quite common for resources from multiple resource groups to interact with one another. For example, a web application in one resource group might rely on a database hosted by a SQL server in another resource group.
Azure Resource Manager
Within Azure, there are several underlying components that provide the infrastructure for an application or service that’s been deployed in Azure. For example, a solution deployed in Azure might consist of a virtual machine or two that run an application, a storage account that’s used to host storage for the application, an Azure web app that provides the front end for the application, and maybe even a database, which is running on a SQL server.
Because all these parts function together to provide a solution, you’ll usually want to deploy, manage, and monitor all these resources as a group. The Azure Resource Manager is a tool that lets you work with all the underlying resources that are part of a solution as a group. With Resource Manager, you can deploy, update, and even delete all resources that form a solution in a single, coordinated operation. Resource Manager also allows you to use templates to streamline deployments. Such templates can be used to uniformly (and easily) deploy separate environments, such as development, staging, and production.
Resource Manager provides a consistent management layer for all Azure resources, security and auditing features, as well as tagging features that you can use to manage your resources once they’ve been deployed into Azure. Using Resource Manager, you can deploy, manage, and monitor all Azure resources for a solution as one group. You can also use Resource Manager to apply access controls to resources within a resource group because Role-Based Access Control (or RBAC) is natively integrated into the Azure platform.
Watch this short video, taken from Cloud Academy’s Managing Role-Based Access Control on Azure Course, to learn more on RBAC.
Another underutilized benefit of Resource Manager is the ability to tag resources. By tagging resources through Resource Manager, you can logically organize them within an Azure subscription. Tagging also helps clarify an organization’s billing because it allows you to break out costs for groups of resources that share the same tag.
Wrap Up
Core Azure architectural components such as regions, resource groups, and Availability Zones serve as the underlying building blocks for any Azure solution that gets deployed. Azure Resource Manager is used to manage these building blocks and the solutions that are built upon them.
While Azure regions dictate where Azure resources are deployed, Availability Zones are used to provide redundancy for those resources that are deployed. Resource groups are used to group and manage related Azure resources that have been deployed to support an overall solution.
By understanding these key architectural components, you will have a better understanding of how Azure solutions are built and supported.
Learn More
Cloud Academy’s AZ-900 Exam Preparation Learning Path will help you understand the core Azure architecture components.
The four major subject areas include:
- Cloud concepts
- Core Azure services
- Security, privacy, compliance, and trust
- Azure pricing and support
To see how you can build, develop, and update your cloud skills with the Cloud Academy platform, request a demo.
