Microsoft AZ-104 Certification Exams - Identity: Azure Active Directory

Category: Inviting Users Page 1 of 2

Azure Active Directory – Identity: Azure Active Directory

As mentioned in the introduction of this chapter, Azure AD is Microsoft’s cloud-based identity and access management (IAM) solution. Azure AD is an especially useful solution for IT admins, developers, and subscribers of various Microsoft solutions (such as Microsoft 365, Dynamics 365, and Azure). Primarily, Azure AD deals with helping employees to sign-in to various resources such as O365, M365, Dynamics, Azure, etc. However, the integration does not stop here; you can integrate Azure AD as the IAM solution for third-party applications and your internal applications as well. Developers are constantly working on integrating Azure AD as the IAM solution because of the increased reliability it provides. Since this book is about Azure administration, we will focus on how Azure AD is intended to help IT admins.

Benefits

Let’s explore the different benefits of Azure AD and why organizations should consider Azure AD as the IAM solution.

SSO to Cloud and On-Premises Applications  Having too many credentials for different applications increases the complexity and results in a higher chance of human error because an SSO solution will help users to sign in to all cloud applications, on-premises applications, and devices using their corporate credentials. Azure AD is not only meant for Microsoft Stack, but for thousands of SaaS applications such as Dropbox, ServiceNow, DocuSign, etc.

Easily Extend On-Premises Active Directory to the Cloud  When organizations move from on-premises to the cloud, there is a need to synchronize the users with the cloud. Otherwise, users will end up with two credentials, one for on-premises and another one for the cloud. To avoid this scenario and to provide a seamless SSO experience, Azure AD allows administrators to synchronize users, groups, passwords, and devices across both on-premises and the cloud. This is accomplished using a tool called Azure AD Connect that needs to be installed on your on-premises domain controller or any other domain-joined server with Windows Server 2012 or later, and it will help with the synchronization.

Cross-Platform Support  Regardless of what platform the user is using, be it iOS, Android, Windows, Linux, or macOS, the sign-in experience is going to be the same, and the users can sign-in to their applications using their work credentials.

Increase Security of Your On-Premises Applications  You can use the Azure AD Application Proxy service to access your on-premises applications via a secured remote access. The best part is you do not have to expose any additional ports on your on-premises firewalls; the access is managed by application proxy endpoints. The access can be tightened using multifactor authentication and conditional access policies.

Better Monitoring and Data Protection  Azure AD amplifies the overall security posture of your environment by providing unique identity protection features. Azure AD Identity Protection comprises several features including suspicious sign-in activity, risk alerts, etc. These triggers can be further integrated with conditional access policies to make business decisions. In addition to these capabilities, administrators can leverage security reports, sign-in activities, and potential vulnerability reports that are available off the shelf without the need to deploy any additional components.

Self-Service Capabilities  If you have worked as an IT administrator, you know most of the calls to the help desk will be regarding password resets. Azure AD offers a feature called Self-Service Password Reset by which users can reset their own passwords with the help of an authentication method such as phone, email, security questions, or a combination of these. IT admins need to enroll users into the SSPR program before they can use this feature. Enrolling is also self-serve, and the user will be prompted to verify the authentication methods. Enabling SSPR in your environment can elevate the security and reduce help-desk engagements.

If you are using Office 365, Azure, or Dynamics 365 in your environment, knowingly or unknowingly you are interacting with Azure AD to complete the authentication process.

We have been talking about Azure AD for a while now, and it is time that we understand the concepts that are part of Azure AD.

Resource Groups 2 – Compliance and Cloud Governance

 Listing Resource Groups from the Azure Portal

  1. Sign in to the Azure portal.
  2. Select the Resource Groups blade, and you will be able to list all the resource groups in your subscription. You have already seen how to list the resources groups; if you can’t recall, refer to Exercise 2.1, step 2, to see the resource groups (if there are any).
  3. You can open any resource group by clicking the name of the resource group. If the resource group is a new one, it will be empty. You will see a Create Resources button to add resources to the resource group.

EXERCISE 2.3
 Deleting Resource Groups from the Azure Portal

  1. Sign in to the Azure portal.
  2. Select the Resource Groups blade, and you will be able to list all resource groups in your subscription.
  3. Open the resource group you would like to delete. Once you are inside the resource group, you will be able to see the Delete Resource Group option that can be used to delete the resource group. You need to enter the name of the resource group to confirm the deletion as this action cannot be undone.

So far, we used the Azure portal to perform the management actions. You can also use Azure PowerShell or the Azure CLI to perform the same tasks. As of now, you can delete only one resource group at a time from the Azure portal. By using scripting, you can perform the management actions in bulk. It’s recommended that you refer to the documentation to learn how to use one of the scripting languages if you prefer to automate your actions in bulk.

In Figure 2.6, you can see that we have created the resource group using the New-AzResourceGroup command along with the location and name parameters, listing resource groups using the Get-AzResourceGroup command, and finally deleting one of the resource groups using the Remove-AzResourceGroup command.

FIGURE 2.6 Managing resource groups using PowerShell

Similarly, you can perform the command using the Azure CLI, as shown in Figure 2.7.

With that, we will move on to the next topic, which is management groups.

Custom Domains in Azure AD – Identity: Azure Active Directory

Every tenant will have two properties that make it unique from other tenants created by other organizations (tenant ID and the tenant initial domain). By default, when you create a tenant, there will be a default domain that will look like <yourdomainname>.onmicrosoft.com. This initial domain cannot be changed or deleted once the tenant is provisioned. Because of the uniqueness of this domain name, sometimes you will not get the domain name that you are looking for. For example, when you try to sign up for a Gmail or Outlook mailbox, you get an option to choose a username. Though you have a choice, username allocation works based on the availability of the username. Sometimes you might try to get an email with your name, and you might end up with Gmail suggesting some usernames having random numbers because the one you asked for is not available. The same concept applies to the initial domains as well; if the name you request is taken, then you must append some letters or numbers to make the name unique.

 If the tenant was created while you signed up for the Azure subscription using your email address, then Microsoft Azure uses your email address and considers that as the initial domain name. You can create additional domains, and at that point you will get an option to choose the initial domain name. Refer to the “Managing Multiple Directories” section in this chapter to understand multitenant environments.

The problem with this approach is that all the users you create will have this initial domain assigned to their username. Since you have added letters and numbers to make it unique, this initial domain is hard to remember and not user friendly. To resolve this issue, you can use custom domains in Azure AD.

Using custom domains, you can use your domain that you created with the domain registrar. Adding custom domains requires you to validate and prove to Azure that you own the domain. This verification can be completed by adding a TXT/MX record to your DNS domain. The value for this DNS record will be given by Azure. When you add a domain to Azure AD, it will be unverified. After you add the DNS record to your DNS zone, you can initiate the verification request, and Azure AD will start querying your domain to verify if the value given by Azure is returned as the answer for the DNS query. Once the record is returned, Azure AD will mark the domain as verified, and you will be able to use the domain when you create users. You can have multiple domains and keep one of them as your primary.

Nevertheless, this is not a daily task for the administrators, and this is a one-time setup. In the future, if more domains need to be linked, then you may have to repeat the verification process. This topic is not part of the exam; however, understanding custom domains will help you set up your test environment with a custom domain. In this chapter, the exercises will have a custom domain name instead of the onmicrosoft.com domain name. I hope that this quick introduction of custom domains will help you understand why your test environment has an onmicrosoft.com domain and the exercises have a proper domain name.

If you would like to add your custom domain to Azure AD, please follow the process outlined in this documentation:

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain

On that note, we will start with users and groups in Azure AD.

Deleting and Modifying Users – Identity: Azure Active Directory

As mentioned in the previous section, whenever someone gets promoted, moves to a different department, or changes their work location, these details need to be updated on the user profile. Though these fields are not mandatory, they will be important in understanding more details about the user. Assume that there are two John Does in your organization—one works for HR and the other one works for IT. Adding department details here will help the administrator to perform the operations on the right user. In Exercise 1.3, we are going to modify the user we created in Exercise 1.2 and then delete the user.

EXERCISE 1.3
 Modifying and Deleting Users

Let’s perform the update process on the user we created in Exercise 1.2. The tasks we have here are as follows:

  • Reset the password of the user to a new password.
  • Change the department of the user to HR.
  • Add the employee ID as 1322.
  • Verify the user details.
  • Delete the user.

The first step here is to navigate to the All Users blade as we have done in Exercise 1.1; you can follow these steps to update the user attributes:

  1. From the All Users blade, select the user John Doe by clicking the name; that will take you to a screen similar to the following one.

2. Since our first task here is to reset the password, you can click Reset Password, and you will be asked to confirm whether you want to proceed with the reset process. You must click again the Reset Password option, which will be visible in the right corner of the screen. To reset a user’s password, you need to be the Global Administrator. User Administrators, Helpdesk Administrators, and Password Administrators can also reset the passwords of non-administrative accounts. However, User Administrators, Helpdesk Administrators, and Password Administrators cannot reset the password of a Global Administrator. Password reset of the Global Administrator can be done only by another Global Administrator.

  1. Confirming the reset password option will display a temporary password on the screen. This needs to be changed on the first sign-in after the reset as this is a temporary password and an administrator is responsible for sending this password securely to the user.
  2. Now that you have reset the password, the next task is to update the department and employee ID. If you recall, we skipped these optional fields while creating the user, and it is time now to update them. To edit the user details, you can click the Edit button, which is on the left side of the Reset Password button.
  3. Clicking the Edit button will enable all the text boxes. Once you have updated the information, you can click Save. You can update all information except the object ID, which is a unique ID assigned to every identity by Azure AD.

6. After saving the details, if you go back to user profile, you will be able to see that all the data you entered is populated to the user profile.

7. From this graphic, we confirmed that the department details and employee ID have been added to the user profile. The next task is to delete the user. Assume that John Doe is leaving the organization and you have to deprovision his account. In the graphic, you can see that there is a Delete button next to the Reset Password button. Clicking Delete will ask for your confirmation.

8. Click Yes, and John Doe’s profile will be deleted. However, this is not a permanent delete action. All deleted users can be viewed from the Deleted Users blade.

9. You will have 30 days from the deletion date if you want to restore the user, using the Restore option. You can also delete the user immediately by selecting the Delete Permanently option instead of waiting for 30 days.

 All these actions can be also performed from the Office 365 Admin panel, PowerShell, or CLI if required.

In Exercises 1.1, 1.2, and 1.3 you have seen how an administrator can view, add, modify, or delete users. Performing these tasks one by one from the portal is not a great idea if you have a large user base. All the actions that you have seen in the previous exercises can be performed in bulk. In the next section, you will learn how administrators can leverage bulk operations available for user accounts.

Bulk Operations – Identity: Azure Active Directory

In an enterprise environment, new users are added, updated, or deleted in bulk. Performing these actions one by one for each user is a hectic task, and there is a higher chance of human error. You need to automate these tasks and should be able to perform these tasks in bulk. Azure AD provides bulk operations by which you can create, invite (for guest users), delete, and download users in your directory. These bulk actions are achieved via uploading a CSV file with the details. This file template will be available for download from Azure Portal itself. In the next exercise, you will use a bulk operation to create nine users (all Avengers characters) in a single shot, and once they are visible on the portal, you will perform a bulk delete operation. See Exercise 1.4.

EXERCISE 1.4
 Performing Bulk Operations

  1. Navigate to the All Users blade. If you are not able to recall the steps to reach the All Users blade, please follow steps 1–5 of Exercise 1.1.
  2. Select Bulk Operations and then select Bulk Create.

3. Selecting Bulk Create will let you download a CSV template. You need to download the template, fill in the details, and upload it to Azure AD for processing. Azure will prompt you with the steps.

4. Once the file is downloaded, you can open it in Microsoft Excel and fill in the details. The headers will be auto populated; some of them are required, while some are optional. The fields that are required will have a [Required] tag in the header. The required fields are Name, Username, Initial Password, and Block Sign In. Fill in the template, as shown here.

  1. You can fill the optional details if required; however, it is mandatory to fill in the required fields; otherwise, the validation will fail.
  2. Let’s upload the file to Azure AD and see if we got it correct. You can use the upload option shown in step 3. If you closed the window after downloading the CSV file, you can click Bulk Operations ➢ Bulk Create and the upload window will be shown again. If the file is uploaded successfully, you will see a message on the screen. Once the file is uploaded, click Submit.

7. As soon as you click Submit, the status will change to “In Progress.” If the format is correct, then you will get a “Succeeded” message.

8. You can also verify the status of any bulk operation by navigating to the Bulk Operation Results blade. You will be able to troubleshoot from this blade if you get an error during the bulk operation.

9. Since our bulk operation was successful, let’s confirm if the users are visible in the All Users blade.

Similarly, you can perform bulk delete and bulk invite operations by downloading the corresponding CSV and uploading them back to Azure AD. Speaking about invitations, let’s see how external users can be invited to your tenant for collaboration.

 From the Deleted Users blade, you can perform bulk delete and restore operations if required.

Inviting Users – Identity: Azure Active Directory

In the “Adding Users” section, we discussed several types of users. If you recall, we talked about Guest accounts (Microsoft accounts and users from external Azure ADs). These users need to be invited to your tenant. Recipients can redeem the invitation and join your tenant for collaboration.

In the All Users blade, you have an option to add a new Guest user. Clicking New Guest User will redirect you to a screen similar to Figure 1.2.

FIGURE 1.2 Inviting users

 You can also add a guest user by clicking New User and then selecting the Invite User radio button instead of Create User.

The only email address is the mandatory field, and you can even customize the personalized message. By clicking Submit, this message will be appended to the email invitation, which will be triggered to the recipient, as shown in Figure 1.3.

A sample invitation has been added for your reference (refer to Figure 1.4).

These users can be easily spotted in the All Users blade by looking at the User Type column. You can further add a filter in the blade as shown in Figure 1.5 to list all the Guest users in your tenant.

FIGURE 1.3 Customizing the invite

FIGURE 1.4 Invitation for Guest user

FIGURE 1.5 Filtering Guest users

So far, you have been working on user accounts and different operations that administrators can perform for managing users. Basic administrative tasks are limited not only to user management but can include group management as well. In the next section, we will talk about group accounts in Azure AD.

Group Accounts

When it comes to access management, applying permissions or roles to each user one by one is cumbersome, so to solve this complexity, we have groups in Azure AD. We can group users to create group accounts and then apply the permissions or roles to the group so that all members of the group get that access. Group accounts make access management easier. You can also synchronize groups from on-premises to the cloud, the same as with users.

Azure AD allows you to create two types of groups, security groups and Microsoft 365 Groups. Let’s understand the differences between these types.

Security Groups  Groups play an inevitable role in access management. Security groups can be used to control access to resources easily. For instance, you can create a security group called All HR and give access to all HR-related resources. As an administrator, the advantage here is you do not have to manage individual access; this can be controlled at the group level. Security groups require the Azure AD administrator to perform management actions.

Microsoft 365 Groups  Microsoft 365 groups serve the same purpose as security groups; however, they provide additional capabilities such as access to a shared mailbox, shared calendar, SharePoint, and more. You can extend the collaboration and provide access to external users as well. Unlike security groups, both users and admins can use Microsoft 365 groups.

Another point to understand here is about membership to groups. You can add users as well as groups (nested groups) to a group as members. The rights can be accessed in three diverse ways, as follows:

Assigned  This one is straightforward; this will let you add users (or groups) to the group as members. This type of addition is also known as direct membership.

Dynamic User  Group memberships are controlled using member attributes; using them we can dynamically add or remove users from a group. For example, you can have a rule like if the department of a user is HR, then that user should be added to the group All HR. Here Azure constantly reviews user attributes. If a new user is added with the department as HR, then Azure will add that user to the All HR group. Similarly, when someone leaves the department, Azure automatically removes the user from the group. This is especially useful for administrators, as they do not have to remove or add access whenever a new user is added or removed; but they must make sure that the attributes are added to the user correctly.

Dynamic Device  This is applicable only in the case of security groups and is like the dynamic user concept. The primary difference is that instead of looking at the user attributes, here you are looking at the device attributes. You can register or join our devices to Azure AD, and based on the device attributes, the group membership can be controlled; we will cover AD Join later in this chapter.

Now that you are familiar with the membership types, let’s go ahead and perform some hands-on tasks related to groups.

Azure AD Join – Identity: Azure Active Directory

Single sign-on is one of the features offered by Azure AD. You can use SSO on devices, apps, and services from anywhere in the world. Joining devices to Azure AD assures the corporate devices are protected and that they follow the compliance standards set by the organization. Users can bring their own devices and join them to Azure AD, and administrators can make sure that these devices also follow the standards of your organization. Now, we will look at the benefits of Azure AD Join.

Benefits

Azure AD Join has the following benefits:

Single Sign-On  This is the primary feature of AD Join; you can sign-in to any of your applications and services without a username and password prompt. The best part is it is not necessary to connect to the domain network to use SSO.

Enterprise Client Roaming  The settings are synchronized across devices that are joined to Azure AD.

Microsoft Store for Business  Joining your device and signing-in to the store with work or school accounts gives you a customized catalog of applications that are shared by your organization.

Windows Hello  This provides you with biometric authentication using facial recognition or fingerprints to access corporate resources and sign-in to devices. The devices should have hardware that supports Windows Hello to use this feature.

Block Access  Administrators can enforce policies and devices that do not meet the requirements can be easily blocked.

Let’s see what connection options are offered by Azure AD Join.

Connection Options

You can connect your devices to Azure AD using the following options:

Register to Azure AD  Registration creates an identity for the device, and this identity can be used for authentication. Whenever a user signs in, the identity of the device can be used for authentication. Administrators have the right to enable or disable this identity.

Join to Azure AD  Joining to Azure AD provides the same features as registration and additionally changes the local state of the device. With a change of local state, users can sign in to their device using their work or school account. Joining is more like an extension to the registration process.

Combining the registration process with Microsoft Intune (it is a mobile device management [MDM] solution) will help you create conditional policies using the device attribute. Using this combo, you can block devices that do not follow the organizational compliance standards. For example, you could block all devices that are using Windows XP or Windows 7 and make Windows 10 the prerequisite for accessing corporate resources.

You could join your device to Azure AD by going to your Windows 10 Settings ➢ Accounts ➢ Access To Work Or School. Signing in with your work or school account will connect your device to the Azure AD domain, and you can sign in to corporate resources using SSO. Figure 1.7 shows how a connected device looks.

FIGURE 1.7 Connecting a device to Azure AD

All the devices that are connected to Azure AD can be explored from the Azure Active Directory ➢ Devices blade. This blade will show OS information, OS version, join type, and owner of the devices that are joined (refer to Figure 1.8).

FIGURE 1.8 Listing all devices connected to Azure AD

Now we will talk about a lifesaver for administrators: self-service password reset. Using self-serve options reduces the incoming requests to the IT help desk so administrators can utilize their time for more productive work.

Managing Multiple Directories – Identity: Azure Active Directory

Each tenant represents an organization, and it is a fully independent resource. Every tenant that you create is logically separated from other tenants that you manage in a multitenant environment. Even if you are the common administrator for all these tenants, there will not be any parent-child relationship between these tenants or directories. Resource independence, administrative independence, and synchronization independence are there between the tenants.

Resource independence is when you create or delete a resource in one tenant; this action will have no impact on any other resource in another tenant. However, there is a small exception that we discussed in the case of cloud identities from external AD. By default, Azure AD doesn’t delete Guest users when they are deleted from their home tenant; however, we can set this up manually.

Administrative independence is when a non-admin user (say the user’s name is John) of tenant A creates a new tenant, say tenant B.

  • John will be the Global Administrator of the tenant B as he created the new tenant. The user will be added as a user from external AD. Here it says external AD, because John is not from tenant B but from tenant A.
  • Administrators of tenant A have no control over tenant B. If the users of tenant A need to access or manage tenant B, then John must invite these users to tenant B and give the necessary role. One thing to note here is that if the admins of tenant A takeover John’s account, they can access tenant B.
  • Adding or removing an admin role in one tenant will not affect the role of the user in the other tenant. Here we’re not removing the user; we are adding or removing the Azure AD roles, which will have no impact on the other tenant, and all roles the user has in the other tenant will be retained.

When it comes to synchronization independence, you can set up independent synchronization on each Azure AD.

With that, we have covered all the topics that are within the scope of the exam.

Summary

In this chapter, we talked about the identity and access management solution in Azure: Azure Active Directory. We started the chapter looking at the benefits of Azure AD, and then we examined how Azure AD is different from the traditional Windows Server Active Directory deployment.

As we progressed, we spoke about Azure AD licensing and how administrators can set up custom domains. After that, we learned about user accounts and group accounts. This is a major element of this chapter; understanding user and group management is crucial for cloud administrators. If you are not confident with identity and access management, there can be a chance of security flaws. Security issues are not something welcomed in an organization as they can cause damage to the reputation of the organization, especially when you are dealing with customer data. Along with the impact on the reputation, this can also lead to revenue loss. As an administrator, you should excel in the identity and access management field.

Then we spoke about Azure AD roles and how administrators should put emphasis on the principle of least privilege. Several other key ideas were reviewed including AD Join and SSPR. You learned about the advantages of incorporating these features in your environment.

Toward the end of the chapter, we covered multitenant environments and the independence they provide in terms of administration, resources, and synchronization.

Like with security, implementing governance and compliance is crucial in setting up the environment. In the next chapter, we will cover governance and compliance.

Azure Regions – Compliance and Cloud Governance

Microsoft Azure comprises datacenters that are located across the globe. At the time of authoring this book, Azure has more than 60 regions, and there are more in the pipeline. This global presence makes Azure the cloud provider with the highest number of regions. Also, this omnipresence gives customers the ability to choose the regions that are right for them. If you are wondering what an Azure region is, a region is a geographical area on the planet comprising at least one datacenter, but usually multiple. The datacenters are isolated from each other in close proximity and connected to each other via low-latency networks, enabling faster and seamless communication.

East US, Brazil South, UK South, India West, and Australia Central are some examples of Azure regions. Figure 2.1 shows the list of public regions available for Azure at the time of authoring this book.

FIGURE 2.1 Azure regions

Let’s understand some key points about regions.

Facts

The following are some of the facts related to regions:

  • Regions offer flexibility for customers to deploy resources to regions that are close to their customers.
  • Regions ensure data residency for customers.
  • Regions offer compliance and resiliency options.
  • When you deploy a resource in Azure, in most cases you will be asked to choose a region.
  • Certain services are region specific, and the availability is limited to some regions when they are launched. Gradually, Microsoft will expand the service to other regions.
  • Services like Azure AD, Azure Traffic Manager, and Azure DNS do not require a region. The region for these resources will be shown as Global in the Azure portal.
  • Each Azure region is paired with another region within the same geography to form regional pairs.

Understanding these facts will help you plan your resource deployment, choose a region, and understand why you are not able to find a specific service in a region. Let’s shift our focus to regional pairs, which is an important concept in Azure.

Regional Pairs – Compliance and Cloud Governance

As you already know, each region consists of one or more datacenters that are in close proximity and connected via a low-latency network. Now, an Azure geography is defined as an area of the world that consists of one or more Azure regions. Some examples are United States, India, Asia Pacific, United Kingdom, etc. If we take the United States geography, it consists of several regions such as East US, West US, Central US, etc. So, an Azure geography ensures the data residency and compliance requirements are met. If you are an organization working with a US government organization, then you cannot store data outside of the United States. Similarly, the European Union has the General Data Protection Regulation (GDPR) where organizations cannot store personal data of the EU citizens outside EU member states. As an administrator, if your organization is GDPR compliant, you can pick a geography that is within the EU and stay compliant.

Azure pairs one region with another region within the same geography. Regional pairs play a vital role in business continuity and disaster recovery (BCDR). Whenever there is a planned update on the Azure platform, Azure rolls out the update sequentially across regional pairs. This guarantees that only one region in the regional pair is updated at a time and the other one can be leveraged for the recovery of the services if something goes wrong.

Figure 2.2 shows a graphical representation of regional pairs in Azure.

FIGURE 2.2 Graphical representation of Azure regional pairs

The following are some of the focus points about Azure regional pairs:

Physical Separation  Three hundred miles is the preferred distance between datacenters that are part of the regional pair; however, this might not be feasible in certain geographies. This isolation will diminish the probability of both regions being affected at the same time due to outages caused by natural disasters, power outages, etc.

Replication  Services like storage accounts provide georedundant storage (GRS). Using GRS, your data will be replicated to the paired region and thus provide reliability.

Recovery Order  If a mass outage happens, Microsoft will prioritize the recovery of one region out of every regional pair.

Serialized Updates  Azure planned updates are rolled out sequentially to the regions in a region pair. As the update is not done simultaneously, even if something goes wrong, one of the regions in the region pair can be used for recovery.

Data Residency  As the regions in a regional pair are part of the same geography, customers can get the benefit of regional pairs without breaking any of the data residency policies.

  • All region pairs have regions from the same geography; the only exception is Brazil South, and the paired region for Brazil South is South Central US. South Central US is part of the United States geography. However, the South Central US paired region is not Brazil South.
  • All region pairs are paired in both directions. One exception here is West India. West India’s pair is South India; however, South India’s secondary region is Central India.

Understanding regional pairs and incorporating them into your infrastructure will help you architect highly available solutions with business continuity in Azure. The complete list of Azure region pairs and how services can leverage regional pairs is available here:

https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions

With that, we will move on to Azure accounts and subscriptions.

Page 1 of 2

Powered by Dianne & Theme by Diannehill