What Azure is and who it suits best
Microsoft Azure is a full cloud platform, but its defining strength is integration. If your people sign in with Entra ID, your documents live in Microsoft 365, your applications run on .NET and SQL Server, and your procurement already has a Microsoft agreement, Azure removes a great deal of friction. Identity, licensing, device management and developer tooling share one model.
That integration is also how you should judge whether Azure fits. If none of those ties exist, you are choosing it on its merits, and the honest comparison with AWS or Google Cloud matters more. We cover that at the end of this page. Our own background includes Microsoft certified engineering, so Azure consulting is a core part of what we do rather than a side offering.
Landing zone: management groups, subscriptions and policy
Azure organises resources in a hierarchy: tenant, management groups, subscriptions, resource groups, resources. The useful insight is that policy and role assignments inherit downward, so structure is a governance tool, not just filing.
We keep the hierarchy small. A typical layout for a scale-up has a platform group (connectivity, identity, management) and a workloads group with separate subscriptions for production and non-production. Subscriptions are the unit of billing, quota and access, so splitting them early makes cost and permission questions simple to answer.
Azure Policy then enforces the rules you would otherwise write in a wiki:
- Require approved regions and deny public IP addresses on selected resource types.
- Require tags such as environment and owner, and inherit them from the resource group.
- Deploy diagnostic settings automatically so logs always reach the central workspace.
- Audit or deny storage accounts that allow public blob access.
Start policies in audit mode, review what would break, and only then switch to deny. Switching on deny blindly is a common way to halt a team.
Defined in code
We build the hierarchy, subscriptions, policy assignments and networks with Terraform, with separate state per layer and a pipeline that plans on pull request. A minimal example of a resource group with enforced tagging inputs:
resource "azurerm_resource_group" "app" {
name = "rg-app-prod-weu"
location = "westeurope"
tags = {
environment = "prod"
owner = "platform-team"
service = "orders-api"
}
}
If your estate was created in the portal, our Terraform service imports it safely rather than rebuilding it.
Identity and access with Entra ID
In Azure, identity is the perimeter. Our baseline:
- Conditional Access requiring MFA for all users and stronger controls for administrators, with break-glass accounts excluded and monitored.
- Privileged Identity Management so elevated roles are time-bound and approved, not permanent.
- Azure RBAC assignments to groups, never to individuals, at the lowest scope that works.
- Managed identities for resources, and workload identity federation for CI pipelines, so there are no client secrets to leak or rotate.
- Key Vault for the secrets that remain, with RBAC-based access and soft delete enabled.
A common mistake is granting Owner at subscription scope to a whole engineering team because it is convenient. We replace it with scoped roles and a documented path to elevation.
Networking: hub and spoke, used carefully
For anything beyond a single application, we use a hub and spoke topology: a hub virtual network holding shared services such as firewall, DNS and VPN or ExpressRoute connectivity, with spoke networks for workloads peered to it. This gives central inspection and one place to manage egress.
The trade-offs are worth stating plainly. A central firewall adds cost and a potential bottleneck, and peering data transfer is charged. For a small team with one application, a single virtual network with network security groups and private endpoints may be enough, and simpler to run. We choose the lightest design that meets your security requirements. Private endpoints for PaaS services such as storage, Key Vault and databases are almost always worth it.
Cost control
Azure Cost Management shows spend by subscription, resource group and tag, which is why the hierarchy matters. We set budgets with alerts per subscription, enforce tags through policy, schedule non-production shutdowns and review Advisor recommendations for idle or oversized resources. Reservations and savings plans come after right-sizing, applied only to steady baseline usage. Dev and test environments deserve special attention, because they are frequently left running at production size.
Managed services we lean on
We prefer platform services to virtual machines wherever the workload allows: Azure Kubernetes Service for container platforms, App Service or Container Apps for simpler web workloads, Azure SQL or PostgreSQL flexible server for data, Storage for objects, and Service Bus for messaging. Delivery commonly runs through Azure Pipelines or GitHub Actions; our Azure DevOps pipelines guide covers the patterns we use.
Common failure modes
- Everything in one subscription. Quotas, permissions and cost all tangle together.
- Permanent Owner roles. Standing privilege is the easiest thing for an attacker to inherit.
- Policy switched to deny without testing. Deployments fail unexpectedly across teams.
- Missing diagnostic settings. You find out logs were never collected after an incident.
- Unplanned address space. Overlapping ranges block peering and VPN later.
When Azure is not the right choice
Choose AWS if you want the broadest service catalogue and have no Microsoft ties, or Google Cloud if analytics and data engineering define your product. Portal-heavy administration and naming differences can also slow teams who come from another cloud. If you are weighing options, talk to us and we will give you a straight comparison for your workload.
Official documentation: azure.microsoft.com