How you structure your Azure environment on day one determines how much governance pain you deal with later. This article covers the best practices, common patterns, and strategic considerations behind a well-architected Azure subscription design.
Why subscription design matters
A properly structured subscription architecture buys you separation of environments and workloads, consistent RBAC, transparent billing and cost allocation, cleaner resource lifecycle management, and simplified policy enforcement.
Key architectural principles
- Environment isolation — separate subscriptions for dev, test/QA, pre-production, and production, each with appropriate controls.
- Workload separation — dedicated subscriptions for line-of-business apps, shared services (identity, monitoring), and platform services like networking.
- Management group hierarchy — a tenant root group with platform, landing zone, and sandbox branches to structure governance top-down.
- Policy and compliance enforcement — Azure Policy at the management group or subscription level, consistent tagging, and Azure Blueprints for repeatable governance.
- Cost management — per-subscription budgets, cost allocation tags, centralized Cost Management + Billing visibility.
- Security and access control — least-privilege RBAC, Azure AD PIM for just-in-time access, custom roles scoped to specific workloads.
The full post also covers subscription naming conventions and automation tooling (Terraform/Bicep, Azure Landing Zones, Azure Lighthouse).