Preparing for AZ-900:
Understanding Core Azure Architectural Components

If you plan on taking the AZ-900 Microsoft Azure Fundamentals exam when it becomes available, you need to have a solid understanding of several core Azure architectural components.  Such architectural components include Azure Regions, Resource Groups, and Availability Zones.  This article is intended to provide you with a foundational understanding of what each of these components is and what each does.

Azure Regions

An Azure region is a set of datacenters that’s deployed within a latency-defined perimeter. This set of datacenters is connected through a dedicated regional low latency network.

With roughly 42 regions already deployed, and another 12 planned, Azure provides flexibility to deploy applications where they are needed.

Azure operates in several geographies around the world. An Azure geography is a defined area of the world where at least one Azure region exists. An Azure region itself is an area within a geography that contains one or more datacenters.

Every region that exists is paired with another region in the same geography.  This is called regional pairing. Regional pairs allow Azure to serialize platform updates and maintenance so that only one paired region is updated at a time. In addition, in the event of an outage that affects multiple regions, at least one region in each pair is prioritized by Azure for recovery.

Microsoft recommends that organizations configure business continuity so that it spans across regional pairs in order to benefit from Azure’s isolation and availability policies that are based on regional pairs.

Applications that support multiple active regions should use both regions in a regional pair when possible. This ensures optimal availability for applications that are hosted there and minimizes recovery time in the event of a disaster.

Resource Groups

A resource group is a container in azure that holds related resources that are part of an azure solution. An azure resource group can include all resources that are part of an azure solution or only resources that need to be managed as a group. You can decide how to allocate resources in resource groups, based on organizational needs.

There are a few key factors to consider when deploying and defining resource groups. For example, all resources within a resource group should share the same lifecyle. You would typical deploy, update, and delete resource within a resource group together. For example, if a DB server resides in a resource group but needs to exist on a different lifecycle than everything else in the resource group, the DB server should probably belong to a different resource group that share the same deployment cycle.

Each resource, by the way, can only exist in one resource group. As far as adding, moving, and removing resources goes, you can add and remove resources to/from a resource group at any time. You can also move resources between resource groups.

A resource group can also contain resources from multiple regions. A key function of the resource group is ability to scope access control to resources within it for admin action. Be it resource management, bulling, etc.

Just because a resource resides in on resource group doesn’t mean it can’t interact with resources from another resource group. This is quite common. For example, web applications in one resource group may interact with a database in another resource group.

When creating a resource group, you need to provide some key information, including a location for the resource group. This is necessary because the resource group stores metadata about resources within it. As such, when you specify a location for eh resource group, this tells azure where to save this meta data. Organizations with certain compliance requirements may need to ensure that data is stored in a specific region. This is an important consideration when choosing where to deploy a resource group and associated resources.

Availability Zones

MS azure offers a feature called availability zones. Availability zones is an HA offering that protects applications and data from datacenter failures. An availability zone is a unique physical location within an azure region. Each availability zone is made up of one or more data centers that are equipped with their own power, cooling, and networking equipment.

To provide resiliency, there are a minimum of three separate zones in all azure regions. The physical separation of each availability zone within each region is what protects applications and data from datacenter failures in azure.  There are zone redundant services that replication applications and data across these available zones in order to protect them from single points of failure.

Availability zones offer a 99.99% VM uptime SLA.  An availability zone within an azure region consists of a combination of a fault domain and an update domain. For example, if you create 3 or more VMs that span across three zones within a region, those VMs are distributed across 3 fault domains and 3 update domains. Azure recognizes this distribution and ensures that VMs in different availability zones are not updated at the same time.  This is what provides the availability that availability zones offer.

Azure Resource Manager

The infrastructure for an application that’s been deployed in Azure is typically made up of several different components.  For example, it may consist of a virtual machine that runs the app, as storage account that hosts storage for the application, a web app that serves as the front end for the app, and maybe a database.

You will often want to deploy, manage, and monitor all of these resources as a group.  Azure Resource Manager is a tool that allows you to work with all of the resources that are part of a solution as a group. The Resource Manager allows you to deploy, update, or delete all of a solutions resources in a single, coordinated operation. It also allows you to leverage templates for deployment. Such templates can then be used to deploy different environments such as testing, staging, and production.

Essentially, Resource Manager offers a consistent management layer for all resources, while providing security, auditing, and tagging features that can help you manage your resources once they’ve been deployed.  With Resource Manager, you can deploy, manage, and monitor all the resources for a particular solution as one group, instead of managing them individually.  You can also apply access controls to all services in a resource group, using Resource Manager, because Role-Based Access Control is natively integrated into the platform.

Other helpful benefits of the Resource Manager include the ability to apply tags to resources, so you can logically organize them within your subscription.  Tags also help you to clarify your organization’s billing by allowing you to view costs for a group of resources that share the same tag.

Wrap Up

The core Azure architectural components that serve as the building blocks for any Azure solution include Azure Regions, Availability Zones, Resource Groups, and the Azure Resource Manager.  Azure Regions are locations where Azure resources are deployed.  Availability Zones provide redundancy for resources deployed in Azure.  Resource Groups provide a way to group related resources that have been deployed and the Resource Manager provides the underlying management platform and functionality for all Azure resources that you deploy.