As stated earlier, when creating an Azure subscription an AAD tenant is automatically created for you. With this, after creating and/or synchronizing users in Azure Active Directory, you can now allow your ADF users to subscribe to your subscription and its existing resources.
According with the size of your cloud environment, you can also create additional subscriptions or associate other existing subscriptions with your Azure Active Directory tenant. Having at least two signatures, one for the productive environment and the other for non-productive ones, is a good practice for segregation of the environment and for scalability.
An important point to be taken into account about permissioning is that there are two types of functions/attributions that are distinct but totally related to each other:
- Azure Roles: Azure Roles use Role Based Access Control (RBAC) and are granted in the context of Azure resources within a subscription. There are three basic roles of Owner, Collaborator and Reader. In addition to them there are more than 70 other roles that are more related to services specifically, here you can see the list with all. In addition to the native functions, you may want to create your own custom roles and maximize the type of control you want to apply.
- Azure Active Directory roles: Azure Active Directory roles are used exclusively for the management of Azure Active Directory resources.
This image can help you understand a little about how the functions of Azure and Azure Active Directory are related:
An Azure subscription has a trust relationship with the AAD to authenticate and authorize users, services and devices.
It is important to know that the same AAD tenant can have multiple signatures trusting him, but each signature can only confirm on a single AAD tenant. It means that you can have the same user base on the AAD tenant for different subscriptions.
A signature is a logical container for your resources and each resource is associated with only one signature. They are directly related to billing and payment.
The data in the subscriptions remains for a while after being canceled, and the subscriptions themselves are usually visible, even after being canceled in the Portal and in the APIs. There is information about the cancellation process in the documentation available here.
A subscription serves different purposes because it is a legal contract, a payment contract, a scale limit and an administrative limit. All details are described in this link.
It is important to define an architecture on the use of signatures so that there is a better organization and management of resources, especially on the segregation of permission and control of existing limits on signatures. To help with this, there is a documented decision guide that is super interesting to understand the best way to model your organization and define signature design strategies.
As described in this link, the recommendation is that there are at least two signatures, one for the productive environment and the other for the non-productive environment. Depending on the size of your environment or the strategy of your company, it may be necessary to create more signatures and in addition to combine the design of signatures with the definition of the landing zone to be created.
The Microsoft Cloud Adoption Framework describes in details about several topics over the enterprise-scale landing zone architecture, which offers a modular design and not only makes it simple to deploy existing and new applications but also allows organizations to start with a lighter deployment implementation and scale depending on their business needs.
Basically, the landing zone will deal with a set of considerations and recommendations based on some design areas:
- Enterprise agreement (EA) enrolment and Azure Active Directory tenants
- Identity and access management
- Management group and subscription organization
- Network topology and connectivity
- Management and monitoring
- Business continuity and disaster recovery
- Security, governance, and compliance
- Platform automation and DevOps
In the landing zone, the choice of network topology to be used is important for the process of governance defitinition. As example, the Hub and Spoke topology may be inserted in the context of subscriptions as follows:
- A first subscription to shared services (Hub Virtual Network)
- A second subscription to the production environment (Spoke 1 Virtual Network)
- A third subscription to the non-production environment (Spoke2 Virtual Network)
- Some references about Hub and Spoke topology:
Currently, enterprise-scale offers three different reference implementations, which all can be scaled without refactoring when requirements change over time:
✔️ Enterprise-Scale - Reference Implementation
| Previous | Next |
|---|---|
| Naming Standards | Resource Groups |