Azure accounts

To use Azure services, you need an Azure subscription, which can be temporary in the Learn sandbox for training or permanent for business needs, allowing multiple subscriptions under one account for different departments and resource management.

Azure management infrastructure

The management infrastructure includes Azure resources and resource groups, subscriptions, and accounts. Understanding the hierarchical organization will help you plan your projects and products within Azure.

Azure resources and resource groups

A resource is the basic building block of Azure. Anything you create, provision, deploy, etc. is a resource. Virtual Machines (VMs), virtual networks, databases, cognitive services, etc. are all considered resources within Azure.

A resource group is a container for resources, where each resource belongs to only one group at a time; while some resources can be moved between groups, nesting resource groups is not allowed.

Resource groups provide a convenient way to group resources together. When you apply an action to a resource group, that action will apply to all the resources within the resource group. If you delete a resource group, all the resources will be deleted. If you grant or deny access to a resource group, you’ve granted or denied access to all the resources within the resource group.

Azure subscriptions

Azure subscriptions serve as a unit of management, billing, and scale, allowing users to organize resource groups and facilitate billing. A subscription provides authenticated access to Azure services and is linked to an Azure account in Microsoft Entra ID.

Accounts can have multiple subscriptions, which help configure different billing models and access policies. There are two types of subscription boundaries:

• Billing boundary: Determines how an account is billed, with separate invoices for each subscription.
• Access control boundary: Defines access policies at the subscription level, enabling organizations to manage access by departments or teams.

Additional subscriptions can be created for:

• Environments (e.g., development, testing, compliance).
• Organizational structures (e.g., restricting teams to specific resources).
• Billing purposes (e.g., separating production from development costs).

Azure management groups further help organize and manage multiple subscriptions.

Azure management groups

Azure management groups provide a higher level of organization above subscriptions, helping manage access, policies, and compliance across multiple subscriptions.

Subscriptions are grouped into management groups, which allow governance conditions to be applied consistently. All subscriptions within a management group automatically inherit these conditions, similar to how resource groups inherit settings from subscriptions.

Management groups enable enterprise-scale management and can be nested for better organization across multiple applications, teams, and regions.

Management group, subscriptions, and resource group hierarchy

Azure management groups allow you to create a flexible hierarchy of subscriptions for unified policy and access management.

Key use cases include:

• Applying policies at scale: For example, restricting VM locations to a specific region in a “Production” management group, ensuring compliance across all descendant subscriptions.
• Simplified access management: By grouping multiple subscriptions under a management group, a single Azure RBAC assignment can grant access across all underlying subscriptions, resource groups, and resources.

This structure enhances governance, security, and efficiency in managing large Azure environments.

Some examples of how you could use management groups might be:

Important facts about management groups:

🞄 10,000 management groups can be supported in a single directory.
🞄 A management group tree can support up to six levels of depth. This limit doesn’t include the root level or the subscription level.
🞄 Each management group and subscription can support only one parent.

Physical infrastructure

Regions

A region is a geographical area on the planet that contains at least one, but potentially multiple datacenters that are nearby and networked together with a low-latency network.

When you deploy a resource in Azure, you’ll often need to choose the region where you want your resource deployed.

Note

Some services or virtual machine (VM) features are only available in certain regions, such as specific VM sizes or storage types. There are also some global Azure services that don’t require you to select a particular region, such as Microsoft Entra ID, Azure Traffic Manager, and Azure DNS.

Availability Zones

Availability zones are physically separate datacenters within an Azure region. Each availability zone is made up of one or more datacenters equipped with independent power, cooling, and networking.

Important

To ensure resiliency, a minimum of three separate availability zones are present in all availability zone-enabled regions. However, not all Azure Regions currently support availability zones.

Use availability zones in your apps

You want to ensure your services and data are redundant so you can protect your information in case of failure. When you host your infrastructure, setting up your own redundancy requires that you create duplicate hardware environments.

Availability zones are primarily for VMs, managed disks, load balancers, and SQL databases. Azure services that support availability zones fall into three categories:

• Zonal services: You pin the resource to a specific zone (for example, VMs, managed disks, IP addresses).
• Zone-redundant services: The platform replicates automatically across zones (for example, zone-redundant storage, SQL Database).
• Non-regional services: Services are always available from Azure geographies and are resilient to zone-wide outages as well as region-wide outages.

Even with the additional resiliency that availability zones provide, it’s possible that an event could be so large that it impacts multiple availability zones in a single region. To provide even further resilience, Azure has Region Pairs.

Region pairs

Most Azure regions are paired with another region within the same geography (such as US, Europe, or Asia) at least 300 miles away. This approach allows for the replication of resources across a geography that helps reduce the likelihood of interruptions because of events such as natural disasters, civil unrest, power outages, or physical network outages that affect an entire region. For example, if a region in a pair was affected by a natural disaster, services would automatically fail over to the other region in its region pair.

Important

Not all Azure services automatically replicate data or automatically fall back from a failed region to cross-replicate to another enabled region. In these scenarios, recovery and replication must be configured by the customer.

Examples of region pairs in Azure are West US paired with East US and South-East Asia paired with East Asia. Because the pair of regions are directly connected and far enough apart to be isolated from regional disasters, you can use them to provide reliable services and data redundancy.

Additional advantages of region pairs:

• If an extensive Azure outage occurs, one region out of every pair is prioritized to make sure at least one is restored as quickly as possible for applications hosted in that region pair.
• Planned Azure updates are rolled out to paired regions one region at a time to minimize downtime and risk of application outage.
• Data continues to reside within the same geography as its pair (except for Brazil South) for tax- and law-enforcement jurisdiction purposes.

Important

Most regions are paired in two directions, meaning they are the backup for the region that provides a backup for them (West US and East US back each other up). However, some regions, such as West India and Brazil South, are paired in only one direction. In a one-direction pairing, the Primary region does not provide backup for its secondary region. So, even though West India’s secondary region is South India, South India does not rely on West India. West India’s secondary region is South India, but South India’s secondary region is Central India. Brazil South is unique because it’s paired with a region outside of its geography. Brazil South’s secondary region is South Central US. The secondary region of South Central US isn’t Brazil South.

Sovereign Regions

In addition to regular regions, Azure also has sovereign regions. Sovereign regions are instances of Azure that are isolated from the main instance of Azure. You may need to use a sovereign region for compliance or legal purposes.

Azure sovereign regions include:

• US DoD Central, US Gov Virginia, US Gov Iowa and more: These regions are physical and logical network-isolated instances of Azure for U.S. government agencies and partners. These datacenters are operated by screened U.S. personnel and include additional compliance certifications.
• China East, China North, and more: These regions are available through a unique partnership between Microsoft and 21Vianet, whereby Microsoft doesn’t directly maintain the datacenters.