The First Azure Platform Decision: Management Groups and Subscription Structure

Before deploying workloads into Azure, one of the first platform decisions is how the environment should be organized.

This sounds simple, but it has long-term consequences. Management groups and subscriptions are not just folders for resources. They define where governance is applied, how responsibilities are separated, how costs are managed, and how workloads inherit security controls.

A messy structure usually does not hurt on day one. It hurts later, when more teams, workloads, policies, and exceptions appear.

Why structure matters

In Azure, management groups provide hierarchy above subscriptions. This allows policies, role assignments, and governance controls to be applied consistently across multiple subscriptions.

That matters because a platform should not depend on every single workload owner remembering every rule manually. The foundation should make the expected structure clear.

For example:

1
Tenant Root Group
2
├── Platform
3
│   ├── Connectivity
4
│   ├── Identity
5
│   └── Management
6
├── Landing Zones
7
│   ├── Production
8
│   └── Non-Production
9
└── Sandbox

This is not the only valid structure, but it shows the idea: shared platform services are separated from application workloads, and production workloads are separated from non-production and sandbox environments.

Platform vs. workload subscriptions

A useful pattern is to separate platform subscriptions from workload subscriptions.

Platform subscriptions usually contain shared services such as networking, connectivity, identity-related infrastructure, security tooling, logging, and management resources.

Workload subscriptions contain application-specific resources such as virtual machines, app services, databases, storage accounts, private endpoints, and Kubernetes clusters.

This separation makes ownership clearer. The platform team owns the foundation. Workload teams own their applications within the boundaries defined by the platform.

Governance starts at the hierarchy

The management group structure should support governance.

For example, policies that should apply everywhere can be assigned higher in the hierarchy. More specific rules can be assigned lower, closer to the workload subscriptions.

A production management group might enforce stricter controls than a sandbox management group. A sandbox can allow more freedom, while production should have stronger requirements around diagnostics, allowed regions, public exposure, tagging, and security settings.

The important point is that governance should be intentional. If everything is assigned randomly at individual subscriptions, the environment becomes harder to understand and harder to audit.

My practical approach

When designing a management group and subscription structure, I would start with these questions:

• Which subscriptions are platform-owned?
• Which subscriptions are workload-owned?
• Where should production and non-production be separated?
• Which policies should apply globally?
• Which policies should only apply to production?
• Who needs access at each level?
• How should costs be separated?
• How much freedom should sandbox environments have?

These questions are more important than copying a perfect diagram. The structure should reflect the operating model.

Common mistakes

One common mistake is putting every workload into one subscription because it feels easier at the beginning. This usually creates problems later with access control, cost ownership, limits, and governance.

Another mistake is overengineering the hierarchy too early. A small environment does not need ten layers of management groups. The structure should be simple enough to understand, but flexible enough to grow.

The third mistake is designing the hierarchy without thinking about ownership. If nobody knows who owns a subscription, who approves changes, or who responds to security findings, the structure is incomplete.

Closing thoughts

Management groups and subscriptions are one of the first real Azure platform decisions.

They are not exciting compared to deploying applications, Kubernetes clusters, or private endpoints. But they create the structure that everything else depends on.

A good Azure platform starts with clear boundaries: what belongs to the platform, what belongs to workloads, where governance is inherited, and who owns each part of the environment.

That clarity is what turns Azure from a collection of resources into a maintainable cloud platform.