Azure

The directory is a different product from the cloud

Microsoft Entra ID — the directory formerly called Azure Active Directory — is where users, groups and application identities live. It is not part of Azure in the way a virtual machine is: the same directory authenticates corporate email, document sharing and every other Microsoft service the organisation uses, and it exists perfectly well for companies that run nothing in Azure at all. What Azure adds is a separate permission system, role-based access control, that binds a directory identity to a scope in the resource tree.

This is the source of the first confusion nearly everyone has. There are two separate sets of roles with similar names, and holding one says nothing about the other. A directory role — Global Administrator, User Administrator — governs the directory: creating users, managing groups, consenting to applications. A resource role — Owner, Contributor, Reader — governs things in Azure: reading a database, restarting a virtual machine, deleting a resource group. A Global Administrator can, by design, see no resources at all. There is a deliberate elevation step that lets one grant themselves access across the resource tree, and the fact that it is a step rather than an implication is the point.

The mechanism that makes this workable for applications is the managed identity: an identity in the directory that Azure creates and rotates for a specific resource, so a virtual machine or a function has something to be without any secret existing. It is the direct equivalent of the short-lived credential story on the other clouds, and it should be the default for anything running inside Azure that needs to call anything else inside Azure. Registering an application and storing its secret is the fallback for things outside — and a secret in a configuration file is a secret in a repository within a year.

Four scopes, and one that deletes

The resource plane is a chain of four levels and a role assignment can be made at any of them. A management group holds subscriptions and other management groups, and exists so a rule can be applied across many subscriptions at once. A subscription is the billing and quota boundary — limits are per subscription, so it is also a scaling boundary whether you meant it to be or not. A resource group holds resources. A resource is the thing itself. An assignment made high in that chain reaches everything below it, which makes the scope you choose the most consequential part of granting access.

The resource group deserves a paragraph of its own, because it behaves differently from anything on the other clouds. Every resource belongs to exactly one, it is chosen at creation, and moving a resource between groups is possible but not universally supported. More importantly, the group is a lifecycle unit: deleting it deletes everything inside it, in one action. That makes it an excellent container for a thing with a beginning and an end — a review environment, an experiment, one application's complete footprint — and a poor container for a mixture of things that merely happened to be created in the same week.

Above role assignments sits a separate guardrail layer that answers a different question. Roles say who may act; policy says what may exist. A policy can require a tag on every resource, forbid a region, forbid a virtual machine size, or force a storage account to reject unencrypted connections — and it applies regardless of who is asking, including owners. Some policies simply refuse the deployment; others fix the resource as it is created. Assigned at a management group, that is the mechanism for rules that must hold across an organisation, and it is the closest equivalent to the organisation-level ceilings on the other clouds.

Where Azure is genuinely the right answer

The honest case for Azure is rarely a specific service, and pretending otherwise wastes everyone's time. It is that a large number of organisations already run their identity, their email and their desktops on Microsoft, and their people already exist in the directory Azure authenticates against. In that situation, single sign-on, conditional access rules, device compliance and group membership are not integration work — they are already true. Choosing another cloud means either federating that identity across or maintaining a second set of accounts, and both are real ongoing costs that no architecture diagram shows.

Two more things follow from that position rather than from technology. Licensing economics are frequently decisive: an organisation with existing server or database licences can often apply them to cloud instances, and the resulting difference is large enough to settle a procurement argument on its own. And hybrid is treated as a permanent state rather than a migration phase — the tooling assumes some servers stay in a building, which suits regulated industries and manufacturing far better than a story that begins "first, move everything".

The fair critique is about coherence rather than capability. Services and portal sections have been renamed often enough that documentation, blog posts and your own runbooks disagree about what a thing is called, and the same task frequently has three supported paths that behave slightly differently. Budget for that: prefer the command line and infrastructure code over portal walkthroughs, because a documented command survives a rename better than a documented click path, and write down which of the three ways your team uses so the next person is not choosing again.

How this shows up in real delivery

Every deployment goes through one control plane, and knowing that explains several behaviours at once. A template describes the desired resources and is submitted as a deployment; the plane works out what to create, update or leave alone. The practical consequence people meet is that a deployment is not atomic in the way a database transaction is — a failure part way through leaves what already succeeded in place, so templates need to be safe to submit again. That is straightforward if you write them declaratively and avoid steps that are only correct the first time.

Subscription limits are the constraint that catches growing systems, because they are quiet until they are not. Quotas are per subscription and per region, several defaults are lower than teams assume, and increases need a request and an approval rather than a click. Two habits follow: check the limits for whatever you intend to scale before the launch that scales it, and treat the subscription as a design boundary — separating production from everything else is as much about not sharing a quota as it is about not sharing a permission.

On cost, the specifically Azure habit worth forming is to make the resource group and the tag tell the same story, because reporting groups by both and a resource that sits in the wrong group is misattributed forever. Beyond that the pattern is familiar: reserved capacity and savings commitments cut the rate substantially for anything running continuously, the applicable licence benefits are frequently forgotten by the people who already own the licences, and the largest single line on many invoices is something nobody uses — an orphaned disk, an idle gateway, a development environment left running since a demo.

Where it degrades

• Confusing a directory role with a resource role, and wondering why an administrator sees nothing.
• Role assignments made to individual people, which no access review can untangle later.
• An assignment made at the subscription because it was easier than finding the right scope.
• A resource group used as a folder for unrelated things, so it can never safely be deleted.
• Application secrets in configuration, where a managed identity would need no secret at all.
• Runbooks written as portal click paths, which the next rename quietly invalidates.
• Growth planned without reading the per-subscription quota, which needs an approval to raise.
• Existing licence benefits left unapplied by the organisation that already paid for them.

When to use it

Related pages

• InfrastructureAWSAWS is Amazon's cloud platform and the oldest of the large clouds, which shows in two ways: it has the most services, and it makes you confront permissions before it lets you do anything useful. Both are the same fact — nothing is implicitly allowed, and the account is the only boundary that really contains a mistake. This page covers how a request is actually authorised, why multi-account is the default answer to isolation, what you trade as you move up the managed-service ladder, and the line items that make the bill a surprise.
• InfrastructureGCPGoogle Cloud (GCP) is organised around a hierarchy that inherits: an organisation contains folders, folders contain projects, and a project contains everything else. That sounds administrative and it is the most consequential thing on the platform, because a project is cheap enough to create for one service and complete enough to delete in one action. This page covers the hierarchy and what inherits down it, why service accounts are the usual way in, the network model that differs from everyone else's, and where the platform is genuinely strong and genuinely not.
• InfrastructureCI/CDContinuous integration is not a server that runs your tests — it is the habit of merging into one shared branch often enough that conflicts stay small, and the automation exists to make that habit safe. Continuous delivery is the second half: one artifact, built once, promoted through environments without being rebuilt. This page covers how to order the stages, why a flaky test destroys the pipeline's authority, what the deployment strategies actually trade, and the four numbers that tell you whether any of it is working.