mrvitej.in
Happy Dussehra! May good always win. Happy Diwali! Wishing you a bright year ahead. Merry Christmas! Warm wishes from Vizag. Happy New Year! Here’s to a great year ahead.

Archive · Azure

Azure Basics: Tenants, Subscriptions and Resource Groups

How Azure organises identity, billing and resources, explained for someone who knows AWS: tenants, management groups, subscriptions, resource groups, RBAC scopes, policy, tags and a sensible starting layout.

5 min read

  • Microsoft Azure
  • Microsoft Entra ID
  • Azure RBAC
  • Azure Policy
  • Azure CLI

Azure arranges things differently from AWS, and the differences cause most early confusion. In AWS the account is the boundary for resources, billing and access. In Azure those jobs are split across a tenant (identity), subscriptions (billing and limits) and resource groups (lifecycle). Once that is clear, the rest of the platform is easier to read.

Naming note, current at this date. Microsoft announced on 11 July 2023 that Azure Active Directory (Azure AD) is now Microsoft Entra ID. It is the same service with a new name, and the rename is rolling through the portal, documentation and tools over the following months, so you will see both names in blog posts and older scripts.

The hierarchy

flowchart TB
  T[Microsoft Entra ID tenant<br/>users, groups, apps, managed identities] --> RMG[Root management group]
  RMG --> MGP[Management group Platform]
  RMG --> MGL[Management group Landing zones]
  MGP --> SC[Subscription Connectivity]
  MGP --> SM[Subscription Management]
  MGL --> SP[Subscription Prod]
  MGL --> SD[Subscription Dev]
  SP --> RG1[Resource group shop-prod-rg]
  SP --> RG2[Resource group shop-data-prod-rg]
  RG1 --> VM[VM, VNet, load balancer]
  RG2 --> DB[Database, storage account]
  POL[Azure Policy and RBAC assignments<br/>inherited downward] -.-> MGL
  POL -.-> SP
  POL -.-> RG1

Everything below a scope inherits role assignments and policies assigned above it. That is the main lever for governing many subscriptions.

Mapping to AWS

Azure Closest AWS idea Important difference
Entra ID tenant IAM Identity Center and the identity provider for an organization One tenant holds people and applications for many subscriptions
Management group Organizational unit in AWS Organizations Up to six levels deep; policy and RBAC inherit
Subscription AWS account (billing and limits boundary) Trusted by one tenant; has its own quotas and a spending boundary
Resource group Roughly a CloudFormation stack or a tag-defined group Every resource lives in exactly one group; deleting the group deletes everything inside
Azure RBAC role assignment IAM policy attached to a principal Assigned at a scope; roles are reusable definitions
Azure Policy Service control policies plus AWS Config rules Can audit, deny, or modify and remediate resources
Managed identity IAM role for a workload (instance profile) System-assigned or user-assigned, no secrets to store
Region such as Central India Region such as ap-south-1 Regions are paired and many support Availability Zones
Tags Tags Not inherited by default; use Policy to enforce or copy them

Roles and scopes

Access is granted by assigning a role to a principal (user, group, service principal or managed identity) at a scope:

Scope:     management group → subscription → resource group → single resource
Built-in:  Owner (everything, including granting access)
           Contributor (create and manage resources, cannot grant access)
           Reader (view only)
           and hundreds of service-specific roles, e.g. Storage Blob Data Reader
az login
az account list --output table
az account set --subscription "shop-prod"

# give a group Contributor on one resource group only
az role assignment create --assignee-object-id <group-object-id> --assignee-principal-type Group \
  --role Contributor --scope /subscriptions/<sub-id>/resourceGroups/shop-prod-rg

az role assignment list --scope /subscriptions/<sub-id>/resourceGroups/shop-prod-rg --output table

Principles: assign to groups managed in Entra ID, not individuals; use the narrowest scope that works; prefer built-in roles; keep Owner for very few people. Note that control-plane roles (managing the resource) are separate from data-plane roles (reading blobs or secrets), so a Contributor does not automatically read storage data. Use Privileged Identity Management (a Microsoft Entra ID P2 feature) for just-in-time elevation if your licence includes it.

Organise sensibly

  1. Subscriptions per environment and workload class: separate production from non-production, and put shared networking or management in their own subscriptions. A subscription is also a blast-radius and quota boundary.
  2. One resource group per application and environment (shop-prod-rg, shop-dev-rg), so lifecycle and cost can be understood and deleting the group removes the whole environment. Do not mix long-lived data stores with short-lived test resources in one group.
  3. Naming convention that encodes workload, environment, region and resource type (for example st-shop-prod-cin-001), following the Cloud Adoption Framework’s abbreviations. Storage account names are global, lowercase and 3 to 24 characters.
  4. Tags: Env, Owner, CostCenter, Application. Enforce them with Azure Policy (deny creation without them, or modify to inherit from the resource group).
  5. Locks: add a CanNotDelete lock on critical resource groups, remembering that locks apply to everyone including Owners.
  6. Cost control: set a budget with alerts under Cost Management at the subscription or resource group level before creating anything else, and use cost analysis grouped by tag.
az group create --name shop-dev-rg --location centralindia --tags Env=dev Owner=platform CostCenter=1234
az policy assignment create --name require-owner-tag \
  --policy "<definition-id-of-require-a-tag-on-resource-groups>" \
  --params '{"tagName":{"value":"Owner"}}' --scope /subscriptions/<sub-id>
az group lock create --name protect --lock-type CanNotDelete --resource-group shop-prod-rg

India has regions in Pune (Central India), Chennai (South India) and Mumbai (West India); check which services and Availability Zones each one supports before choosing, and pick a pair deliberately for disaster recovery.

Governance in practice

  • Start with a landing zone layout (the Azure landing zone reference architecture from the Cloud Adoption Framework): platform subscriptions for identity, connectivity and management, and landing-zone subscriptions for workloads under management groups, with policy assigned at the management group.
  • Use Azure Policy initiatives for baselines (allowed regions, required tags, deny public storage accounts, require encryption) and run them in audit mode first.
  • Turn on the Activity Log export to a Log Analytics workspace for audit, and Microsoft Defender for Cloud (at least the free posture features) for recommendations.
  • Protect the tenant: MFA for everyone, conditional access policies, two break-glass emergency accounts excluded from conditional access and monitored, and no standing Global Administrators beyond a small group.
  • Manage the structure as code (Bicep or Terraform), not by clicking, so management groups, policies and assignments are reviewable.

Quick checks for newcomers

Question Where to look
Which tenant and subscription am I using? az account show
Why can I not create this resource? Role assignments at the scope, Policy denials (activity log), and subscription quota
Who can access this resource group? Access control (IAM) blade, Role assignments
What is costing money? Cost Management, Cost analysis, grouped by resource group or tag
Is something blocked by policy? Policy, Compliance, or the error text naming the policy assignment