Most Azure accounts we’ve inherited weren’t architected so much as accumulated. A resource group here for a proof of concept, a VM sized for a launch that never repeated, a storage account nobody remembers creating. None of that is unusual. It’s just what happens when infrastructure grows around deadlines instead of a plan.
We don’t invent our own framework
Microsoft already publishes a genuinely good one: the Azure Well-Architected Framework, built around five pillars, reliability, security, cost optimisation, operational excellence, and performance efficiency. We use it as the actual checklist when we take over an account, rather than working from instinct or whatever the previous team happened to prioritise. It’s free, it’s maintained by the people who build the platform, and it’s more thorough than anything we’d write from scratch.
Reliability starts with naming the failure you’re protecting against
The most common gap we find isn’t a missing feature, it’s a redundancy decision made without naming the specific failure it’s meant to survive. A multi-region deployment is expensive and only worth it if you can say precisely what regional outage it protects you from, and whether your data layer can actually fail over cleanly. We’ve seen accounts pay for multi-region compute sitting in front of a single-region database, which protects against nothing.
Security: identity first, network second
Azure gives you two different security instincts to reach for: locking down the network (NSGs, private endpoints, firewalls) and locking down identity (RBAC, managed identities, Conditional Access). Teams under time pressure tend to reach for network rules first because they feel more concrete. We start with identity instead, specifically replacing shared keys and connection strings with managed identities wherever the service supports it, because a leaked network rule is a misconfiguration and a leaked key is a live credential.
Cost optimisation is a monthly habit, not a one-time audit
This is the pillar most accounts have never actually applied on an ongoing basis. Azure Advisor will tell you, for free, exactly which of your resources are under-utilised right now, and most teams have never opened that tab. We turn on Advisor recommendations and cost alerts on every account we take over in the first week, before touching anything else, because it’s the fastest way to see what’s actually being paid for versus what’s actually being used.
Operational excellence means the pipeline, not just the app
The framework’s operational excellence pillar covers infrastructure-as-code, deployment automation, and monitoring, the same ground our own DevOps work covers day to day. In practice this means Bicep or Terraform definitions checked into source control instead of resources clicked together in the portal, so the environment can be rebuilt or audited without anyone needing to remember what they did eighteen months ago.
Where to read the source material
If you want the detail beyond what fits in a blog post, start with the framework overview, then go straight to the cost optimisation pillar if that’s the most urgent problem, since it’s usually the one with the fastest payoff. We reference these same pages internally. There’s no separate secret playbook, just the discipline of actually working through it account by account instead of skipping straight to provisioning.
If your Azure bill or architecture hasn’t had a proper pass against this framework, get in touch and we’ll tell you honestly what we’d change first.