Azure Enterprise Architecture

Microsoft Azure is a cloud platform whose defining characteristic is that it is organised as a strict resource hierarchy governed by one identity system. Where other providers give you a flat collection of services bound together by policy, Azure gives you a tree — tenant, management groups, subscriptions, resource groups, resources — and nearly every governance, billing, quota, and access decision is expressed as something attached to a node of that tree. Learning Azure is mostly learning that tree and the two control systems that hang off it: role-based access control and Azure Policy.

The Resource Hierarchy

At the top is the tenant, which is a Microsoft Entra ID directory. The tenant owns identities; it is not where resources live. Below it, management groups form a tree used to apply policy and access assignments to many subscriptions at once. Subscriptions sit under management groups and are the billing boundary, the primary quota boundary, and a hard limit for several resource types. Resource groups live inside a subscription and are the deployment and lifecycle container. Resources live in exactly one resource group.

Everything above the resource is manipulated through Azure Resource Manager, the control plane. Every resource has a fully qualified resource ID that encodes its path through the hierarchy, and every portal click, CLI command, and infrastructure-as-code deployment is an ARM operation against that ID. This uniformity is Azure's real ergonomic advantage: the same permission model, the same tagging, the same locks, and the same activity log apply to essentially everything.

Two properties of this tree catch people out. First, a resource group deletion deletes everything inside it, which makes resource-group design a safety decision rather than a filing decision — do not put the production database and a scratch VM in the same group. Second, resource group membership is mostly a management convenience: resources in different resource groups can talk to each other freely, so a resource group is not a network or security boundary. Use subscriptions and networking for isolation, not resource groups.

Designing the Subscription Layout

Because quotas, some service limits, and billing all land on the subscription, subscription design is capacity planning as much as it is organisation. The common enterprise pattern is a management group tree that mirrors governance rather than the org chart — a platform branch for shared connectivity, identity, and management, and a landing-zone branch for workloads, split by environment and sensitivity. Policy and access are assigned as high in the tree as they are true, so that new subscriptions inherit the guardrails on creation rather than being retrofitted.

Entra ID, RBAC, and Managed Identities

Azure RBAC assigns a role definition to a principal at a scope, and the assignment is inherited by everything below that scope. Permissions are additive across assignments, with deny assignments taking precedence where they exist. The important distinction — and the source of a great many "I have Owner but it still says forbidden" tickets — is between the control plane and the data plane. Owner on a storage account lets you manage the account, rotate its keys, and delete it; it does not by itself let you read a blob. Reading data requires a data-plane role such as Storage Blob Data Reader. The same split exists for Key Vault, Service Bus, and Cosmos DB. Treat management access and data access as two separate grants.

For workload identity, prefer managed identities over service principals with secrets. A system-assigned managed identity is created with a resource and deleted with it, which makes lifecycle automatic but makes the identity non-portable. A user-assigned managed identity is an independent resource that several workloads can share, which suits blue/green deployments and shared platform components. Either removes the credential from your configuration entirely. Where an external system must authenticate — a CI runner outside Azure, for instance — use workload identity federation with OIDC rather than issuing a client secret.

Azure Policy as the Guardrail Layer

RBAC answers "who may act." Azure Policy answers "what may exist." Policies evaluate resource properties and take an effect: audit records non-compliance, deny blocks the deployment outright, and deployIfNotExists or modify remediate by adding the missing configuration. Initiatives group policies into a single assignable set.

The practical discipline is to start in audit mode, measure the existing estate, fix or exempt what is non-compliant, and only then move to deny. Assigning a deny policy to a populated management group without that step does not retroactively delete anything — existing resources simply become non-compliant — but it will break the next deployment pipeline that touches them, usually at an inconvenient moment. Policy is also the right home for rules that must survive a determined subscription owner, such as allowed regions, required tags for cost allocation, and mandatory diagnostic settings.

Networking and the Hub-and-Spoke Pattern

A virtual network is regional and carries an address space you choose; subnets are slices of it. Network security groups are stateful filters applied to a subnet or a network interface, evaluated by priority, with default rules that already permit intra-VNet traffic and deny inbound from the internet. Application security groups let rules reference a logical group of NICs instead of an address range, which keeps rules readable as the estate grows.

VNet peering connects two virtual networks with routing that behaves as though they were one network — but peering is not transitive. If A peers with B and B peers with C, A cannot reach C. This single property is what produces the hub-and-spoke topology: a hub VNet holds shared services (firewall or network virtual appliance, VPN and ExpressRoute gateways, DNS resolvers), every workload spoke peers only with the hub, and user-defined routes push spoke traffic through the hub's appliance so that transitivity becomes a deliberate, inspected path rather than an accident. Azure Virtual WAN provides a managed version of the same shape.

For reaching Azure PaaS services privately, private endpoints place a NIC with a private address from your VNet in front of the service and rely on private DNS zones to resolve the public hostname to that address. Getting the DNS half wrong is the most common private-endpoint failure: the network path exists but the name still resolves publicly, so traffic leaves through the internet path and the change silently accomplishes nothing. The broader routing and connectivity concepts are covered in cloud network engineering.

Common Failure Modes

Confusing control-plane and data-plane roles. Owner is not a data role. Grant the specific data role, and audit for data-role assignments separately.
Resource group blast radius. A deletion cascades to every resource in the group. Use resource locks on anything stateful and keep lifecycles aligned within a group.
Global name collisions. Storage accounts, Key Vaults, and default App Service hostnames take names from a global DNS namespace. A naming convention that works in one subscription can fail in another because someone else, anywhere, took the name.
Deleting a Key Vault you cannot re-create. Soft delete retains the vault name for a retention period, and purge protection prevents early removal. Both are desirable, and both mean a name is not immediately reusable after a mistake — plan for it rather than being surprised by it.
Assuming peering is transitive. Spoke-to-spoke traffic needs an appliance in the hub and user-defined routes, or it will not flow.
Private endpoints without private DNS. The name must resolve to the private address inside the VNet, or the endpoint is decorative.
Availability zones assumed rather than configured. Zone redundancy is a deployment choice per service and per region, not a default. A zonal resource in a zone-capable region is still single-zone.
Quota discovered during failover. Compute quotas are per-subscription and per-region and per-VM-family. A disaster-recovery region with no pre-raised quota will not accept your capacity when you need it.

When Azure Fits — and When It Doesn't

Azure is the natural choice when the organisation already runs on Microsoft identity and productivity tooling, because the tenant becomes a single identity plane for both. It is strong for hybrid estates that need directory integration, dedicated circuits into on-premises data centres, and a governance story that auditors recognise. It is also the pragmatic answer when the applications themselves are Microsoft-stack — .NET, SQL Server, Dynamics — where the migration path is shortest.

It is a weaker fit when a team wants the finest-grained primitives and the largest third-party ecosystem, where AWS generally has more prior art. It is a weaker fit when the centre of gravity is large-scale analytics, where GCP's data platform requires less assembly. And no cloud is a good fit for a workload that is steady, predictable, and fully utilised, with no elasticity requirement and no appetite for the operational model that comes with a shared control plane.

Key Takeaways

The hierarchy is the product: management groups and subscriptions carry policy, access, and quota, and everything inherits downward.
RBAC decides who may act; Azure Policy decides what may exist. You need both, and Policy should start in audit mode.
Control-plane roles do not grant data-plane access. Grant data roles explicitly.
Use managed identities and federation; treat a client secret as an exception with an owner.
Peering is not transitive — hub-and-spoke exists because of that fact, not because of fashion.
A private endpoint without matching private DNS changes nothing. Verify resolution, not just the resource.