How I would build a practical Microsoft Azure platform for a small enterprise

I would treat Microsoft Azure platform design as an operating decision, not an architecture exercise: choose the simplest foundation that the team can secure, change safely and restore under pressure, then add complexity only when a workload’s ownership, risk or recovery need demands it.

For this design, assume an organisation of roughly 75 to 500 people, probably already using Microsoft 365 and Microsoft Entra ID. It has a lean internal IT team or capable managed partner, a handful of business applications, some legacy Windows or line-of-business systems, and perhaps a modest on-premises footprint to connect or retire over time. It isn’t operating a sovereign cloud and doesn’t have a full-time cloud platform team.

Those constraints should shape the platform. Azure can reward ambition with a monthly bill and an operational estate far larger than the problem warrants. Microsoft’s Azure landing-zone guidance is designed to scale across many workloads and teams; its principles remain useful, but the reference architecture is a menu of controls, not a shopping list. Microsoft’s definition of a platform landing zone covers organising resources, applying governance and providing shared capabilities. For a small enterprise, the important word is needed. (learn.microsoft.com)

Start with operating assumptions, not Azure services

Before creating a resource group, I would ask four questions of each workload: who owns it; what data it handles; how long it can be unavailable; and how much data loss is acceptable. The last two are the recovery time objective (RTO) and recovery point objective (RPO). They are business commitments, not technical decoration.

This avoids a familiar mistake: treating every application as if it needs active-active deployment across regions. Microsoft’s reliability guidance makes the trade-off plain. A single-region deployment is cheaper and simpler to operate, while multi-region resilience brings duplicated resources, replication cost and a heavier operational burden. Every workload still needs some disaster-recovery mitigation, but that doesn’t make multi-region production the default. (learn.microsoft.com)

I would divide workloads into three practical classes. A disposable development service can be rebuilt. An ordinary internal application needs backup, documented restoration and sensible availability within one region. A genuinely business-critical service may need zone-redundant components, tested failover and possibly a secondary-region recovery design. Review the classification when the business changes; don’t assume it is permanent.

Two viable foundations — and where I would draw the line

There are two useful starting patterns. Both can be secure. The choice depends less on headcount than on whether the organisation has hybrid connectivity, virtual machines and multiple independently owned workloads.

For the assumed organisation, I would choose the second pattern where there is a serious hybrid requirement or more than a couple of production applications. Otherwise, I would start with the first while reserving address space and subscription names that make a later move straightforward. Microsoft’s current networking guidance describes a minimal hub-and-spoke pattern for small and medium-sized organisations, with a hub for shared services and workload spokes that can grow independently. It also makes Azure Firewall optional rather than compulsory — an important distinction for a small platform. (learn.microsoft.com)

A small hierarchy, with subscriptions doing real work

I would create a flat management-group hierarchy beneath the Microsoft Entra tenant root: an organisation-level management group, then Platform, Workloads and Sandbox. Under Workloads, I would add Production and Non-production only if policy differences genuinely justify them. I would not apply day-to-day policy at the tenant root or reproduce the corporate org chart in management groups.

Management groups apply governance consistently to subscriptions. Microsoft recommends keeping the hierarchy reasonably flat, ideally no more than three or four levels, and warns against using it as a regional filing system. That’s sound advice: deeply nested management groups are hard to reason about when a policy unexpectedly blocks a deployment. (learn.microsoft.com)

My opening subscription model would look like this:

• Platform: shared connectivity, central monitoring components and any genuinely shared private DNS or management services.
• Production: the first production workload, with later critical applications receiving their own production subscription when ownership, risk or cost visibility warrants it.
• Non-production: development, test and pre-production resources. It is separate because careless test work should not share the same limits and permissions as production.
• Sandbox: tightly budgeted experimentation. It gives technical staff somewhere to learn without weakening production controls.

I would not create a separate “identity subscription” simply because an enterprise-scale diagram includes one. Microsoft Entra ID is tenant-level; an identity subscription makes sense when hosting identity infrastructure such as domain controllers or Microsoft Entra Domain Services in Azure. Without that infrastructure, the subscription is an empty administrative gesture.

Subscriptions are the meaningful boundary for billing, policy, quotas and access delegation. Microsoft calls this subscription democratisation; at small-enterprise scale, I would put it more simply: give an application owner enough autonomy to run their service, but not enough standing privilege to alter the platform’s guardrails. (learn.microsoft.com)

Identity is the control plane, so keep it uncompromising

I would make Microsoft Entra ID the only normal route into Azure. Human access would use named accounts, group-based Azure role-based access control (RBAC) assignments and least-privilege built-in roles wherever possible. There should be no shared administrator account, no routine use of Global Administrator and no application secrets sitting in deployment scripts.

Privileged Identity Management (PIM), where licensing permits, is worth prioritising for tenant and subscription administration. It makes high privilege eligible and time-limited rather than permanently assigned. For application access to Azure services, I would use managed identities, which let workloads authenticate without stored credentials; for secrets and certificates that cannot yet be eliminated, I would use Azure Key Vault with Azure RBAC rather than its legacy access-policy model. Microsoft explicitly recommends managed identities for service connections and says legacy Key Vault access policies have known security limitations. (learn.microsoft.com)

There must also be two cloud-only emergency access accounts, protected differently from routine administrators, monitored and tested at least quarterly. This isn’t paranoia. Conditional Access mistakes, federation failures and licence problems are exactly when a normal account can become unavailable. Microsoft’s emergency-access guidance is direct on this point. (learn.microsoft.com)

Network for the traffic you have, not the topology you admire

I would plan IP address ranges on day one, including room for future workload virtual networks, even if the estate starts with one. Address overlap becomes an unpleasant obstacle when connecting a branch site, a new acquisition or a hub network later. Each workload that needs private networking should normally have its own virtual network or a clearly isolated subnet structure, network security groups and no public management ports.

For virtual machines, I would use Azure Bastion rather than exposing Remote Desktop Protocol or SSH to the internet. For outbound connectivity from private subnets, I would choose an explicit method such as NAT Gateway, which provides network address translation (NAT), rather than rely on accidental defaults. Microsoft says new virtual networks default to private subnets from 31 March 2026, making explicit egress, or outbound, design more important rather than less. (learn.microsoft.com)

Azure Firewall isn’t an automatic purchase. I would add it when central outbound filtering, fully qualified domain name (FQDN)-based controls, inspection or compliance evidence creates a real requirement. Until then, well-designed network security groups, private endpoints for sensitive platform-as-a-service (PaaS) services and an explicit outbound path are often more proportionate. A firewall with a broad “allow anything” rule provides limited control for its cost.

Private endpoints deserve the same restraint. I would use them for production databases, storage, Key Vault and services handling confidential material where the workload is already inside a virtual network. But private endpoints introduce DNS work. Azure’s guidance is clear that private DNS zones must be linked to networks that need to resolve the private endpoint name; hybrid environments may need Azure DNS Private Resolver as well. This is a design dependency, not an afterthought. (learn.microsoft.com)

Choose managed services first, but don’t treat PaaS as magic

My default compute order would be managed application services first, virtual machines second and Kubernetes last. For conventional web applications and APIs, Azure App Service is usually the practical starting point. Azure Functions suit event-driven or scheduled tasks. Azure Container Apps can fit where the application is genuinely containerised and benefits from that deployment model. I would use virtual machines for commercial packages, legacy dependencies, specialist software and transitional migrations — not as the reflex answer to every application.

I would not introduce Azure Kubernetes Service simply because developers use containers. AKS can be useful, but it creates a platform inside the platform: cluster upgrades, ingress, networking, policy, image supply chains, observability and skills all need ownership. Small enterprises should earn that complexity through a real application requirement or a team that already operates Kubernetes competently.

For data, I would favour managed database services where the application supports them, and Azure Blob Storage for object data. Azure Files has a clear role for lift-and-shift file shares, user profiles and applications that genuinely need Server Message Block access; it should not be casually replaced with a high-performance service designed for more demanding workloads. The distinction between Azure Files and Azure NetApp Files is largely about workload behaviour, not brand hierarchy.

Every production workload should have its infrastructure described in code, preferably using Bicep if the organisation is firmly Microsoft-centred, or Terraform if it already has established cross-cloud practice and skills. The important choice isn’t the tool badge. It is one reviewed, repeatable route to create and change infrastructure, with the code stored outside the production subscription.

Governance should stop the costly mistakes, not every unusual one

I would begin Azure Policy in audit mode for unfamiliar controls, inspect the results, then enforce a small set of rules that reflect actual risk. The first policy set would normally cover allowed regions, mandatory ownership and cost-centre tags, approved resource types where appropriate, diagnostic settings, sensible requirements for Key Vault and storage, and restrictions on accidental public exposure.

That last point needs care. A blanket policy denying every public endpoint can break legitimate internet-facing applications and push teams into unmanaged workarounds. I would instead define an approved front-door pattern — for example, a web application protected by a web application firewall — and make exceptions visible, time-bound and owned.

I would enable Microsoft Defender for Cloud selectively, starting with plans that cover resources actually in use and making somebody responsible for reviewing findings. Its recommendations are generated from continuous assessment against security policies and standards, but a long recommendation list isn’t a security programme. What matters is whether high-risk findings are fixed, accepted with a reason or escalated. (learn.microsoft.com)

Backups, monitoring and recovery are one operating system

Backup is not a tick box, and replication is not recovery. I would define backup by application dependency: databases, file data, virtual machines where they remain necessary, configuration, keys and infrastructure code. The restoration route must include credentials, DNS, network dependencies and a named person able to make the business decision to invoke it.

Azure Backup is often enough for Azure-native protection, but it is not automatically the whole answer for estate-wide recovery, specialist applications or existing backup operations. The choice between Azure Backup and Veeam should follow workload coverage and restoration responsibility, not an assumption that one vendor must replace the other.

I would test restores on a schedule, record the achieved RTO and RPO, and feed failures back into the design. The cost of disaster recovery isn’t just dormant capacity; it includes the people and procedures capable of using it. That is why a well-rehearsed single-region rebuild can be more credible than an untested multi-region architecture. Where regional recovery is justified, examine the likely spend and operational implications before promising a failover target; Azure disaster-recovery cost is rarely limited to one replication feature.

For observability, I would centralise the minimum useful signals: Azure activity logs, service-health alerts, workload logs, application performance telemetry, backup failures, key expiry warnings and alerts tied to user impact. One or two Log Analytics workspaces are normally enough at this scale. Set retention deliberately and don’t send every verbose diagnostic category to an expensive workspace forever.

Cost control belongs in the platform, not in an end-of-month meeting

Every subscription would have an owner, a budget and alert thresholds. Budgets are warnings rather than hard spending caps, and Azure evaluates them daily, so they are useful only when someone is expected to respond. Azure Cost Management also supports automation around budget notifications. (learn.microsoft.com)

Tags should answer mundane questions: who owns this, what workload is it for, which environment is it, and which cost centre pays. I would enforce tags on resources where feasible but would not make a tag policy so brittle that it blocks recovery during an incident. Monthly cost review should focus on orphaned disks and IP addresses, idle development machines, old snapshots, unexpected data egress, over-sized compute and abandoned proof-of-concepts.

Reservations and savings plans come later. Microsoft’s reservation recommendations examine historic usage over periods including seven, 30 and 60 days, but a recommendation is no promise that a newly migrated or poorly understood workload will remain stable. I would buy commitments only after predictable, continuously used capacity has proved demonstrably boring. (learn.microsoft.com)

What I would deliberately defer

I would defer Azure Virtual WAN, a large central firewall estate, dedicated identity infrastructure, full automated subscription vending, multiple Log Analytics designs, custom policy initiatives, AKS, Microsoft Sentinel and active-active multi-region applications unless a stated workload requirement justifies each one. None is inherently wrong. Each can be right for a larger, more regulated or more security-mature organisation. At small-enterprise scale, buying all of them early usually means paying for complexity before gaining resilience.

I would also keep a living inventory of services, owners, dependencies and support dates. Azure’s rate of service change makes this basic housekeeping a security and continuity control, especially where old components are retained for compatibility. A platform cannot be governed well if nobody can say what it contains.

The result is intentionally modest: a clear Microsoft Entra identity boundary; a flat management-group hierarchy; a few purposeful subscriptions; PaaS-first workloads; private networking where risk justifies it; policies that prevent known mistakes; tested restoration; and cost ownership close to the people creating resources. It leaves room to grow without asking a small team to operate a miniature hyperscale cloud.