Azure Solutions Architecture — Governance & Foundations: Management Groups, Policy & RBAC

Azure Solutions Architecture · AZ-305 · Architecture Foundations · by Raushan Ranjan, MCT

Whether you’re a new cloud architect or a seasoned pro, the first step in any Azure project isn’t coding—it’s designing your foundation. A solid foundation ensures your cloud environment is secure, cost-effective, and easy to manage as it grows. Think of it as a city's infrastructure: you can’t build houses without roads, zoning laws, and a power grid. In this guide, we'll break down the core components of Azure governance and architecture using simple analogies to help you build a well-run cloud city.

Azure Governance: Setting the Rules

Governance is the rules and guardrails that ensure your Azure environment is used the right way for cost, security, and compliance. It’s like a city's municipal government, setting building codes and enforcing zoning laws to prevent chaos. As an architect, you must understand your stakeholders (Finance, Security, IT) and their needs. You’ll decide on a governance model—whether it’s a strict, centralized model where corporate IT calls the shots, a more flexible federated model that gives business units autonomy, or a hybrid of both. The key is to avoid overly prescriptive rules that hamper agility and to make sure your rules are consistently enforced.

Management Groups: Your Organizational Chart

Management groups are high-level containers that help you apply policies, roles, and cost controls to a collection of subscriptions. They are the cloud equivalent of your company’s organizational chart: HQ → Division → Department. Policies applied at a higher level flow down, just like corporate memos. You should design your management group hierarchy to reflect your business structure and billing needs, keeping it shallow and meaningful. A common pitfall is adding management groups as a last-minute thought, so it’s crucial to define them early in your planning.

Subscriptions: The Bank Accounts of Your Cloud

An Azure subscription is the billing and accounting boundary. Think of it as a bank account for a team or project, complete with its own statement and spending limits. Subscriptions are also a way to isolate fault and security boundaries. Your subscription model should be based on your company’s needs:

• Department/BU per subscription: Best for direct cost ownership.
• Environment per subscription: Ideal for separating dev, test, and production workloads to manage risk.
• Project per subscription: Perfect for large, temporary, or highly regulated projects.

A great best practice is to keep shared platform services, like monitoring and security, in their own dedicated subscriptions.

Resource Groups: The Project Folders

A resource group is a logical container for resources that share a lifecycle. It’s like a project folder on a shared drive—everything inside relates to the same deliverable and can be managed or deleted together. The most important thing to remember is that a resource group is not a security boundary; RBAC can be assigned at the RG level, but broader security should be handled at a higher scope. You should design your RGs around the lifecycle and ownership of your applications. A common pitfall is putting unrelated workloads in the same RG, which can make it harder to manage and increases the risk of accidental deletion.

Resource Tagging: Labeling for Clarity

Tags are key/value metadata applied to your Azure resources. They're like sticky labels on office equipment—"Finance," "Project: Phoenix," "Owner: Alice." Tags are the primary way to track costs and automate operations when your subscriptions don’t perfectly align with your cost centers. The key to a successful tagging strategy is discipline. You should define a tag dictionary and use Azure Policy to enforce mandatory tags and controlled values. Relying on users to remember to tag resources without programmatic help is a classic pitfall.

Policy and RBAC: Your Guards and Gatekeepers

Azure Policy and Role-Based Access Control (RBAC) are two of your most powerful governance tools, and they are complementary.

• Azure Policy is like the city's building code and zoning rules. It controls what resources can be created and how they are configured (e.g., only allowing certain VM sizes). Policies can audit, deny, or even modify resources to ensure compliance.
• RBAC is like keys and access cards. It controls who can perform actions on resources (e.g., who can deploy a VM). You should follow the principle of least privilege and assign roles to groups, not individuals.

The best approach is to start with an Audit effect to understand the impact of your policies before moving to a stricter Deny effect.

Azure Landing Zones: The Quick-Start Foundation

A landing zone is a pre-built, secure, and scalable foundation for running workloads in Azure. It’s the prepared site for a new neighborhood: roads, power, and rules are all in place so you can build your house (workload) quickly. A well-designed landing zone sets up identity, networking, management groups, subscriptions, and a security baseline from day one. You can start with a simple, minimal viable product (MVP) landing zone and mature it over time, ensuring your foundation is always aligned with your business needs.