Azure — Frequently Asked Questions
Practical answers on running workloads in Azure — subscription structure, identity and conditional access, what drives the bill, App Service versus containers, and the mistakes that are expensive to undo.
Structure#
How should we organise subscriptions?#
At minimum, separate production from everything else. Beyond that, a management group hierarchy with subscriptions per environment and per major workload, so policy and cost roll up sensibly.
The subscription is where policy applies, where quotas bite and where cost is attributed. Getting it roughly right at the start is cheap; reorganising a busy estate later is a project.
Management groups — worth the effort?#
Yes, as soon as you have more than a couple of subscriptions. They are how you apply policy and access once rather than repeatedly, and they are the difference between an estate that stays consistent and one that drifts.
How should resource groups be organised?#
By lifecycle — things created, updated and deleted together. Grouping by resource type ("all the databases") feels tidy and makes deletion and access control awkward, because a resource group is a deletion boundary as much as an organisational one.
Identity#
What is the most common Azure identity mistake?#
Standing privileged access. Administrators with permanent elevated roles, because time-bound elevation is slightly inconvenient. It works fine until an account is compromised.
Close behind: no break-glass account, or one that conditional access can lock out.
What is a break-glass account and why does it matter?#
An emergency administrator account excluded from conditional access, with sealed credentials stored where two people can reach them.
It exists because conditional access policies can lock out every administrator — a misconfigured policy, an expired certificate on your identity provider, an outage in your MFA service. Without an excluded account you can lose administrative access to your own tenant, and recovering that is slow and unpleasant.
Create it, monitor its use, and test it before you need it.
Managed identity or service principal?#
Managed identity wherever the resource supports it — no secret exists, so no secret can leak or expire unnoticed. Service principals where you need something outside Azure to authenticate, with credentials in a vault and a rotation date.
The number of outages caused by an unnoticed expiring secret is high, and entirely preventable.
Cost#
Why is our Azure bill higher than expected?#
Common causes, in rough order: over-provisioned compute and database tiers; non-production environments running at production size around the clock; egress and cross-region traffic; log and metric ingestion at default verbosity; and orphaned resources — unattached disks, reserved addresses, old snapshots — that nobody owns.
Most of that is an ownership problem. Enforce tags by policy from the first resource and the anomalies become visible instead of archaeological.
Are reservations worth it?#
Once your baseline is measured and stable, yes — the discount on capacity you were going to run anyway is substantial. Before that, no: committing to an unmeasured baseline converts a variable cost into a fixed one at the wrong level.
Commit to the floor, keep the peak on demand.
How do we control non-production spend?#
Schedule it off. Development and test environments running 168 hours a week to be used for 40 is the single most reliable saving available, and it is a scheduling job rather than an architectural change.
Building#
App Service, Container Apps, or AKS?#
Take the most managed option that meets the requirement. App Service for straightforward web applications — least to operate. Container Apps when you want containers without running a cluster. AKS when you genuinely need Kubernetes, and can name what for.
The common mistake is choosing AKS because it is the most capable, then discovering that capability is a synonym for operational responsibility. See Kubernetes for whether you need it at all.
Where do secrets go?#
Key Vault, referenced by managed identity, never in application settings committed to a repository and never in an image. Enable soft delete and purge protection — an accidentally deleted vault is a very bad day otherwise.
Do we need private endpoints?#
For platform services holding data that should not be reachable from the internet, yes. Public endpoints with firewall rules are better than nothing and still expose a public surface.
Plan DNS carefully at the same time; private endpoint name resolution, particularly in hybrid setups, is where most of the difficulty actually lives.
Operating#
What should we monitor first?#
Whatever indicates a customer is affected — errors and latency at the entry point — then saturation of whatever runs out first. Route logs to a central workspace with deliberate retention, because default retention plus default verbosity is a meaningful line on the bill.
How do we keep the estate consistent as it grows?#
Policy, applied at management group level. It is the difference between guardrails and a quarterly cleanup exercise. Prefer deny over audit where the risk justifies it — an audit policy tells you about the drift you now have to chase.
What is the most expensive thing to get wrong early?#
Subscription and management group structure, followed by identity and tagging. All three are a day's work at the start and a migration project after a year. If you are early, spend the day.