With a Microsoft Enterprise Agreement, Azure subscriptions follow a hierarchical structure to isolate user roles...
and privileges. The terminology around these subscriptions can sometimes be difficult to navigate, especially around Azure departments and accounts.
Azure's management structure has four levels that serve to partition responsibilities and improve accountability in large organizations. These levels include:
- Enrollment: An enrollment is the foundation of an Azure management structure. Microsoft uses what it calls hierarchical "scaffolding" to help organizations build flexible controls over Azure governance policies and accommodate a variety of organizational needs. An enrollment is the control point for all Azure services and usage within an enterprise. Admins typically use enrollment to consolidate billing and allocate costs to various business units, projects and workgroups.
Enterprise Agreement customers receive an Azure enrollment number and access key when they initially sign up for Azure.
Although an organization can have multiple enrollments, this is intended more for service providers that bundle and resell Azure services; most enterprises will have just one. For example, service providers that use Azure Stack to create private cloud environments have more control points, such as plans and offers, but enterprises will only encounter these terms when they buy Azure services from a third party.
- Departments: These provide a means to subdivide Azure resource privileges, usage and billing within a large organization. Departments are optional, but they help partition a large number of Azure resources into logical units that correspond to a business group, development project, application or any other organizational structure.
Azure department administrators have management authority over groups of accounts and Azure subscriptions.
- Accounts: These are more granular Azure resource and usage controls that admins use for reporting and to manage access to underlying Azure services. The account creator is the default account administrator and controls all Azure subscriptions and the services available to them within an account. This makes accounts, primarily, a billing construct.
Before individual developers begin to use Azure, they must create an account that is tied to a unique ID and credit card number.
- Subscriptions: Subscriptions are the level where users actually create and consume Azure resources. A subscription can also help an organization enforce limits; for example, a limit could prevent the accidental deployment of a massive amount of resources, such as VMs, that results in high monthly costs. Within an enterprise, subscriptions provide a mechanism to control the Azure services available to individual users and workgroups and to create three parameters: a unique subscriber ID, a billing location and a group of available resources.
Much like an enterprise typically has multiple departments under a single enrollment, each department can host multiple accounts, and accounts can have many subscriptions. Think of subscriptions as the leaves where actual work gets done on a vast tree of branches (accounts) and limbs (departments) attached to a single trunk (enrollment).
Hierarchical design patterns
A few examples make these management concepts easier to understand. Microsoft documentation illustrates three useful patterns to organize Azure enterprise enrollments:
- Function: A model in which Azure departments map to functional areas within an enterprise, such as HR, IT, finance and product development. Typically, each department, or function, has a single account owner/manager with different Azure subscriptions for each project within the function.
- Unit: A model in which Azure departments map to formal business units -- such as agricultural products vs. industrial equipment within a manufacturing company or hotels vs. restaurants within a hospitality company. Again, each department usually has a single account with Azure subscriptions allocated to individual business applications within the unit. For example, there could be a subscription for a mobile ordering and payment app in the restaurant unit and another for an employee scheduling system.
- Geography: This model maps Azure departments to defined geographic regions in an enterprise. These might be continental subdivisions for a global company or different parts of the country for a domestic company. As with a functional organization, each geography has a single account with Azure subscriptions mapped to different projects within the geography.
Azure's four-level organizational hierarchy gives enterprises flexibility in how they organize and subdivide responsibility for Azure billing and resource management. They also help ensure that decisions are made closest to the actual service user, rather than within a central management bureaucracy.
Microsoft does emphasize in its documentation, however, that this hierarchical structure is only part of an organizational design, which must also include naming conventions that make it easy to understand the structure and manage service usage. Also, since each level of the hierarchy defines rights, roles and responsibilities, enterprises must define security and usage policies to control access and resource consumption and monitor activity.
Use resource tags and groups for more granularity
Although the department, account and subscription hierarchy enables organizations to compartmentalize Azure administration and usage, large organizations will want even more granularity, particularly to allocate costs. That's where resource tags come in. These allow admins to add metadata to resources so they can more efficiently aggregate and group them for reporting and billing. Typical tags include department or business unit, billing location code, application and project name.
Another handy management abstraction is Azure resource groups, or bundles of Azure resources or services that share a common purpose. Admins can manage these groups within Azure Resource Manager, and any actions they apply to the group affects each resource contained in it.
Both tags and resource groups are highly recommended. However, the downside to resource groups is that they make it easy to accidentally create big problems via a single configuration change. To protect mission-critical services, such as a vital database object, use resource locks, which prevent the accidental deletion or modification of particular resources, no matter what happens to other resources in their group.
Migrate to Azure cloud with the help of Microsoft tools
Explore the most recent cloud services in Azure
Use these three Azure tools for monitoring