The last lesson was about the physical side: datacenters, zones, regions. This lesson covers the counterpart, the organization of your own Azure environment. Anyone who creates a few virtual machines hardly needs any structure for it. But anyone with many teams, several environments and a shared bill has to decide where things live, who may do what and who pays for what. Azure offers four levels for this: resources, resource groups, subscriptions and management groups.
Resources
A resource is the basic building block in Azure. Everything you create or deploy is a resource: a virtual machine, a virtual network, a database, a storage account, a web app. A resource always belongs to exactly one resource group.
Resource groups
A resource group is a container for related resources. Microsoft names the following rules for it:
- Every resource lives in exactly one resource group. You can move a resource to another group later.
- Resource groups cannot be nested, and they cannot be renamed after they are created. So a clear naming scheme is worthwhile from the start.
- When you delete a resource group, all resources in it are deleted.
- Access rights, policies and locks that you apply to the group apply to all resources in it.
- A resource may work together with resources in other groups, for example a web app with a database from another group.
As a rule of thumb: A group should contain what has the same lifecycle, that is, what is deployed, changed and deleted together. A test setup for one week belongs in a group of its own. Then you clear it away completely with one click.
A resource group itself has a location. It stores metadata about its resources, and the location determines where this metadata is stored. The resources in the group may be in other regions, but Microsoft recommends the same location. Tags that you set on a group are not inherited by the resources in it.
Subscriptions
Anyone who uses Azure needs a subscription. According to Microsoft's description, it is a unit of management, billing and scale. It grants access to Azure services and is the unit that is billed. A subscription itself is not expensive: Costs arise from the resources in it. A subscription trusts one Microsoft Entra tenant, which signs in the users and devices. A tenant can have many subscriptions, but a subscription trusts only one tenant.
Two kinds of boundaries make subscriptions useful:
- Billing boundary: Azure generates separate invoices and reports for each subscription. If you want to see costs separately, you create another subscription.
- Access boundary: Access rules apply at the subscription level. A subscription for development and one for operations can have different rules and spending limits.
Typical reasons for several subscriptions are separate environments (development, test, production), separate teams or workloads, and separate billing. A subscription, by the way, is not tied to a region: You don't need a separate one per region.
Management groups
With many subscriptions it gets tedious to regulate each one individually. A management group sits above the subscriptions. You arrange subscriptions into management groups and put rules on the group. All subscriptions in it inherit these rules automatically. Two examples from Microsoft's documentation:
- A policy on a management group "Production" limits the regions in which virtual machines may be created. It applies to all subscriptions below it, and the owner of a subscription cannot override it.
- A role assignment on the management group gives people access to all subscriptions below it. That is easier than setting the rights in each subscription individually.
For management groups, Microsoft names these key facts:
- Every management group and every subscription has exactly one parent.
- Management groups can be nested up to six levels deep. The root and the subscription level do not count.
- A directory supports up to 10,000 management groups.
- At the top of every tenant is the root management group (Tenant Root Group). New subscriptions land there by default.
- All subscriptions in a management group must trust the same Entra tenant.
The hierarchy
The four levels build on each other. Settings you make at one level are inherited by all levels below.
| Level | Contains | Typical task |
|---|---|---|
| Management group | subscriptions and further management groups | policies and access for many subscriptions |
| Subscription | resource groups | billing and access boundary |
| Resource group | resources with the same lifecycle | manage and delete together |
| Resource | a single service or building block | the actual work |
So if you put a policy on a subscription, for example, it applies to all resource groups and resources in it. If you put it on a resource group, it applies there but not in other groups.
An example
The made-up "Hartmann Möbel AG" has a development department and an online shop. There are two subscriptions: "Development" and "Production." Both hang under a management group "Hartmann," on which a policy limits the allowed regions. In the "Production" subscription there is a resource group "shop-prod" for the shop, with web app, database and storage account. In the "Development" subscription, the team creates a group for every sprint, which it deletes afterwards. The invoices arrive separately, the rules centrally.
Exercise 1
The made-up agency "Mertens Medien" has two client projects and an internal test environment. The clients' costs are to be billed separately. A rule that limits the allowed regions is to apply to all projects. One project's test system is torn down after every week.
Draw or describe a structure made of a management group, subscriptions and resource groups. Justify each decision with a rule from this lesson.
Solution 1
One possible design:
- One management group "Mertens" above everything. You put the rule for the allowed regions there. All subscriptions below inherit it, and nobody can override it in a subscription.
- One subscription each for client A, client B and "Internal." The subscription is the billing boundary: Each generates its own invoices, so the clients' costs stay separate. It is also the access boundary, so client A's team gets no access to client B.
- At least one resource group per environment in each subscription, for example "client-a-prod" and "client-a-test." The test system has a different lifecycle than production. If it sits in a group of its own, you delete the group after the week, and all resources in it are gone.
There is no single correct solution. What matters is that each decision fits a rule: billing and access at the subscription, shared rules at the management group, shared lifecycle at the resource group.