Considerations and recommendations for multi-tenant Azure landing zone scenarios

The article, Azure landing zones and multiple Microsoft Entra tenants, describes how management groups and Azure Policy and subscriptions interact and operate with Microsoft Entra tenants. The article describes the limitation of these resources when they operate within a single Microsoft Entra tenant. Under these conditions, if multiple Microsoft Entra tenants exist, or are required for an organization, the Azure landing zones must be deployed into each of the Microsoft Entra tenants separately.

Azure landing zones with multiple Microsoft Entra tenants

Diagram of multiple Microsoft Entra tenants with Azure landing zones deployed.

The previous diagram shows an example of the Contoso Corporation, which has four Microsoft Entra tenants due to mergers and acquisitions as the corporation has grown over time.

Microsoft Entra tenant *.onmicrosoft.com domain Usage notes
contoso.onmicrosoft.com Primary corporate Microsoft Entra tenant that's used by the Contoso Corporation. Azure and Microsoft 365 services are used in this tenant.
fabrikam.onmicrosoft.com Primary Microsoft Entra tenant that's used by Fabrikam. Azure and Microsoft 365 services are used in this tenant. This tenant has remained separated since the acquisition by the Contoso Corporation.
tailwind.onmicrosoft.com Primary Microsoft Entra tenant that's used by Tailwind. Azure and Microsoft 365 services are used in this tenant. This tenant has remained separated since the acquisition by the Contoso Corporation.
contoso365test.onmicrosoft.com Microsoft Entra tenant that's used by the Contoso Corporation for testing Microsoft Entra ID and Microsoft 365 services and configuration only. All Azure environments live within the contoso.onmicrosoft.com Microsoft Entra tenant.

The Contoso Corporation started out with one Microsoft Entra tenant of contoso.onmicrosoft.com. Over time, they made multiple acquisitions of other companies and brought these companies into the Contoso Corporation.

The acquisitions of Fabrikam (fabrikam.onmicrosoft.com) and Tailwind (tailwind.onmicrosoft.com) brought with them existing Microsoft Entra tenants in which Microsoft 365 (Exchange Online, SharePoint, OneDrive) and Azure services are used within. These companies, and associated Microsoft Entra tenants, are kept separated because parts of the Contoso Corporation and its companies might be sold in the future.

The Contoso Corporation has a separate Microsoft Entra tenant for the sole purpose of testing Microsoft Entra ID and Microsoft 365 services and features. But no Azure services are tested in this separate Microsoft Entra tenant. They're tested in the contoso.onmicrosoft.com Microsoft Entra tenant.

Tip

For more information about testing Azure landing zones and Azure workloads and resources within Azure landing zones environments, see:

Note

Azure landing zones are deployed within a single Microsoft Entra tenant. If you have multiple Microsoft Entra tenants that you want to deploy Azure resources within, and you want to control, govern, and monitor them by using Azure landing zones, you must deploy Azure landing zones within each of those tenants individually.

Considerations and recommendations for Azure landing zones in multi-tenant scenarios

This section explains key considerations and recommendations about Azure landing zones and Microsoft Entra multi-tenant scenarios and usage.

Considerations

  • Start with a single tenant approach to your Microsoft Entra tenant design.
    • The single tenant is typically the organization's corporate Microsoft Entra tenant where the user's identities exist and a service, like Microsoft 365, is running.
    • Only create more Microsoft Entra tenants when there are requirements that can't be met by using the corporate Microsoft Entra tenant.
  • Consider using Microsoft Entra ID administrative units to manage the segregation and isolation of users, groups, and devices (for example, different teams) within a single Microsoft Entra tenant. Use this resource instead of creating multiple Microsoft Entra tenants.
  • Consider using sandbox subscriptions for the initial application workload development and investigation. For more information, see How to handle "dev/test/production" workload landing zones in Azure landing zone architecture.
  • Migrating Azure subscriptions between Microsoft Entra tenants is complex and requires pre and post migration activities to be completed to enable a migration. For more information, see Transfer an Azure subscription to a different Microsoft Entra directory. It's easier to rebuild the application workload in a new Azure subscription in the destination tenant. It gives you more control over the migration.
  • Consider the complexities of managing, governing, configuring, monitoring, and securing multiple Microsoft Entra tenants. A single Microsoft Entra tenant is easier to manage, govern, and secure.
  • Consider your JML (joiners, movers, and leavers) process, workflows, and tooling. Ensure that these resources can support and handle multiple Microsoft Entra tenants.
  • Consider the effect on end users when they manage, govern, and secure multiple identities for themselves.
  • When choosing multiple Microsoft Entra tenants, consider the effect on cross-tenant collaboration, especially from an end user's perspective. The Microsoft 365 collaboration experience and support between users within a single Microsoft Entra tenant is optimal.
  • Consider the effect on auditing and regulatory compliance checks across multiple Microsoft Entra tenants before choosing an approach.
  • Consider the increase in licensing costs when multiple Microsoft Entra tenants are used. Licenses for products like Microsoft Entra ID P1 or P2 or Microsoft 365 services don't span across Microsoft Entra tenants.
  • A single Enterprise Agreement enrollment can support and provide subscriptions to multiple Microsoft Entra tenants by setting the authentication level on the enrollment to work and school account cross-tenant. For more information, see Azure EA portal administration.
  • A single Microsoft Customer Agreement can support and provide subscriptions to multiple Microsoft Entra tenants. For more information, see Manage tenants in your Microsoft Customer Agreement billing account.
  • When opting for a Microsoft Entra multi-tenant architecture, consider the limitations that might occur for application teams and developers. Be aware of limitations in Microsoft Entra integration for Azure products and services, such as Azure Virtual Desktop, Azure Files, and Azure SQL. For more information, see the Azure products and services Microsoft Entra integration section in this article.
  • Consider using Microsoft Entra B2B to simplify and enhance user experience and administration when your organization has multiple Microsoft Entra tenants.
  • Consider using the Microsoft identity platform, with Microsoft Entra ID with B2B and B2C capabilities, so developers can create applications in a single Azure subscription and within a single tenant. This method supports users from many identity sources. For more information, see Multi-tenant apps and Architect multi-tenant solutions on Azure.
  • Consider using the features available for multi-tenant organizations. For more information, see What is a multi-tenant organization in Microsoft Entra ID.
  • Consider keeping your Azure landing zone up to date.

Azure products and services Microsoft Entra integration

Many Azure products and services don't support Microsoft Entra B2B as part of their native Microsoft Entra integration. There are only a few services that support Microsoft Entra B2B authentication as part of their Microsoft Entra integrations. It's safer for the service default to not support Microsoft Entra B2B as part of their Microsoft Entra integration.

Services that provide a native integration with Microsoft Entra ID, such as Azure Storage, Azure SQL, Azure Files, and Azure Virtual Desktop, use a "one-click" or "no-click" style approach to integrate. They require authentication and authorization scenarios as part of their service. This approach is typically supported against the “home tenant”, and some services might enable support for Microsoft Entra B2B/B2C scenarios. For more information about the Azure subscription's relationship to Microsoft Entra ID, see Associate or add an Azure subscription to your Microsoft Entra tenant.

It's important to carefully consider which Microsoft Entra tenant your Azure subscriptions are associated with. This relationship dictates which products and services, and their features, the application or workload teams use that need to support the identities and from which tenant the identities are from. Typically, identities are in the corporate Microsoft Entra tenant.

If multiple Microsoft Entra tenants are used to host all Azure subscriptions, application workload teams can't take advantage of some Azure products and services Microsoft Entra integrations. If the application workload teams have to develop their applications around these imposed limitations, the authentication and authorization process becomes more complex and less secure.

Avoid this problem by using a single Microsoft Entra tenant as the home for all your Azure subscriptions. A single tenant is the best approach for authentication and authorization for your application or service. This simple architecture gives the application workload team less to manage, govern, and control, and it removes potential constraints.

For more information, see Resource isolation in a single tenant.

Recommendations

Important

Microsoft recommends that you use roles with the fewest permissions. This helps improve security for your organization. Global Administrator is a highly privileged role that should be limited to emergency scenarios when you can't use an existing role.

Next steps