A single Azure subscription mixes everything: dev, staging, production, security tools, and logs. This creates risk: a misconfigured resource in dev could impact production, costs are hard to track, and access controls become complex.

Microsoft recommends a multi-subscription strategy where you separate workloads, environments, and functions into dedicated subscriptions. Each subscription provides isolation: separate RBAC boundaries, billing, service limits, and resource quotas.

While you can have many subscriptions, Azure best practices start with a foundational 5-subscription structure:

1. Management/Security Subscription: Contains Azure AD / Entra ID, Azure Policy definitions, Azure Security Center / Defender for Cloud, Log Analytics workspace (central), and Azure Monitor. This is your governance hub—the single place where you define guardrails that apply to all subscriptions.

2. Logging/Audit Subscription: A write-only destination for centralized logging. All diagnostic logs, activity logs, and security logs flow here. This subscription is locked down so logs cannot be deleted or modified, meeting compliance requirements.

3. Connectivity/Shared Services Subscription: Hosts common infrastructure used by multiple workload subscriptions: Hub VNet, Azure Firewall, VPN/ExpressRoute gateways, Azure DNS Private Resolver, shared Azure Container Registry (ACR), and Key Vault.

4. Non-Prod Workloads Subscription: Contains development, testing, and staging environments. Developers have broader access here to experiment and iterate. Cost controls are less strict, but Azure Policies still enforce security guardrails.

5. Production Workloads Subscription: Highly restricted production environment. Only CI/CD pipelines and a small SRE team can make changes. Human access is read-only with break-glass roles requiring MFA and approval workflows.

Azure Policy is Azure's equivalent to AWS SCPs. Policies define what actions are denied or what configurations are required across subscriptions, regardless of RBAC permissions. Think of them as safety nets: even if someone has Contributor permissions in a subscription, a Policy can block dangerous operations.

Management Groups organize subscriptions hierarchically. Policies assigned at the Management Group level apply to all subscriptions below it. Common Policy examples: prevent public storage accounts, restrict regions to approved ones only, require encryption for storage and databases, block certain VM sizes, and require tags.

Policies use deny-by-default logic: if a Policy denies an action, it cannot be allowed by RBAC. This ensures consistent security posture across all subscriptions.

All subscriptions send diagnostic logs to Log Analytics workspaces in the Logging subscription via diagnostic settings. This gives you a single source of truth for audit and compliance. Activity logs, resource logs, and security logs also flow to centralized Storage Accounts or Log Analytics.

Azure Security Center / Defender for Cloud runs in each subscription but aggregates findings to the Management subscription. Azure Monitor collects metrics and logs, giving you a unified security and operations dashboard.

This centralized approach means you can answer questions like "Who accessed this resource?" or "What changed in production?" without logging into multiple subscriptions.

Azure AD / Entra ID provides single sign-on for all subscriptions. Users authenticate once and can access multiple subscriptions based on role assignments.

Role assignments use Azure RBAC roles (e.g., `Reader`, `Contributor`, `Owner`) or custom roles that are assigned to users, groups, or service principals. When a user accesses a subscription, they assume permissions based on their role assignments.

This eliminates the need to manage users in each subscription and provides centralized access control with audit trails via Azure AD logs.

Workload subscriptions need to connect to shared services and sometimes to each other. Azure provides several options:

Hub-and-Spoke VNet Peering: The Connectivity subscription hosts a Hub VNet that all spoke VNets (in workload subscriptions) peer to. This is the most common pattern for multi-subscription networking.

Virtual WAN: A central hub in the Connectivity subscription that all subscriptions connect to. More scalable and easier to manage than many peering connections, especially for global deployments.

Private Link: For service-to-service communication without exposing VNets. Ideal for accessing shared APIs, databases, or storage accounts.

Service Endpoints: Allow private access to Azure services (Storage, SQL, Key Vault) without traversing the internet, even across subscriptions.

Within Non-Prod and Production subscriptions, you deploy the same 3-tier architecture per environment:

Web Tier: Azure Front Door or Azure Application Gateway (with WAF) in public subnets across multiple availability zones. Front Door/App Gateway terminates TLS and routes traffic to the app tier.

App Tier: Azure App Service (Web Apps) or Azure Kubernetes Service (AKS) in private subnets. Containers or apps pull images from Azure Container Registry (ACR) in the Connectivity subscription. Apps fetch secrets from Key Vault using managed identities.

Data Tier: Azure SQL Database or Azure SQL Managed Instance in private data subnets with geo-replication for high availability. Azure Cache for Redis for caching. All data encrypted at rest with keys managed in Key Vault.

Network Security Groups (NSGs) enforce least-privilege networking: web tier can only reach app tier on HTTP/HTTPS, app tier can only reach data tier on database ports, and data tier has no internet access.

CI/CD pipelines run in the Connectivity subscription or in each workload subscription. They use managed identities and role assignments to deploy:

1. Pipeline uses a managed identity with Contributor role in the target subscription (Non-Prod or Prod)

2. Managed identity has permissions to update App Service/AKS, SQL, and other resources

3. Deployment happens without storing credentials in the pipeline

For production, pipelines require manual approval gates and can only deploy artifacts that passed tests in Non-Prod. This enforces promotion workflows and prevents untested code from reaching production.

Each subscription has its own billing, making it easy to track costs by environment, team, or project. Azure Cost Management and budgets can be set per subscription or aggregated across Management Groups.

Tags applied consistently across subscriptions (e.g., `Environment: prod`, `Project: webapp`) enable cost allocation reports that show spending by project or team, regardless of which subscription resources live in.