In short: An Azure Well-Architected review isn't a framework recital — it's a diagnosis. Read the landing zone and the workloads together, treat "we're already optimised" as a hypothesis to test rather than a fact, and go past what Azure Advisor surfaces: in one client environment Advisor had run out of cost recommendations and the manual review had not. The value isn't a tidier tenant — it's turning what you find into scoped, billable work the client actually approves, and a leadership team that finally understands what it's paying for. Spotto's Review Checklists compress the days of manual digging into minutes, so the architect spends the time on judgement and the client conversation, not on rebuilding the same spreadsheet.
Before Spotto, I spent years running Well-Architected reviews by hand. I would sit inside a client's Azure environment and pull it apart pillar by pillar, trying to understand not just what had been deployed, but why.
Honestly, it always felt a bit like a scavenger hunt—and I genuinely enjoyed it. Not because I wanted the environment to be in bad shape, but because finding something useful was good news for the client. A cost saving, a fixable security gap, or a performance improvement sitting there unused was not an awkward conversation. It was the best part of the job.
That work drew on more than twenty years: helping cloud service providers scale and automate hosted infrastructure, architecture and governance at a major bank using frameworks such as TOGAF, and performance and scaling in the travel industry at very high transaction volumes.
What that combined experience taught me is that knowing a framework and knowing an environment are very different things.
It is also where Spotto came from. Review after review taught me where the time really goes and what a client actually needs to see before they can act. Building Spotto has been about automating the collection and repeatable analysis, so an architect can spend more time applying judgement and less time beginning every review with an empty spreadsheet.
We started with Azure. The principles travel well to other clouds, but the examples here are Azure examples because they are the environments where these particular lessons were learned.
I Start With a Landing Zone Lens
People often blur a Well-Architected review with a landing zone assessment. They are not the same thing: the landing zone is the governed platform foundation, while the Well-Architected Framework focuses on the workloads running within it. In practice, however, I learned to review them together.
Before going deep into security posture, performance, or rightsizing, I want to know how the environment is organised. Is production separated appropriately from non-production? Is tagging consistent enough for billing and ownership to mean something? How are identity, policy, networking, monitoring, and recovery handled? What services are in play, and how do they fit together?
One engagement sticks with me. A retailer was preparing for ISO certification and wanted its Azure environment reviewed as part of that programme. We found secret-bearing connection strings in App Service configuration where managed identity could remove the credential. Production and non-production were tangled together in a single subscription, making access and ownership much harder to reason about.
The biggest concern was regional. Their data was in Australia Southeast, which did not support availability zones for the services involved. The team had not understood the practical difference between a region with availability zones and one without them, or how that changed the failure scenarios their design could tolerate. Recovery was central to the certification work, yet the technical design did not provide the resilience they believed it did.
The result was not a list of isolated fixes. It became a recommendation to move towards a proper Azure landing zone and an explicit resilience and recovery design.
"We're Already Optimised" Rarely Survives the First Few Questions
I hear this often, and I have learned to be sceptical.
One of my quickest tests is to ask about a newer capability such as Premium SSD v2. Not knowing one service does not prove that an environment is poorly designed. It does tell me that optimisation might have been treated as a one-off project rather than a continuous discipline. Azure keeps changing after the architecture diagram has been signed off.
An agriculture company gave me a memorable example. It had migrated older, chatty application code from on-premises infrastructure to Azure. Performance was, in the client's words, horrendous - bad enough that the company was considering renewing its ageing on-premises hardware even though that was not the direction it wanted to take.
The application and database components were not even in the same availability zone, despite communicating constantly. We placed them in the same zone, enabled accelerated networking to reduce latency and jitter, and used a proximity placement group to keep the database and application servers in the same datacenter and as physically close together as Azure could place them.
That was an intentional performance trade-off, not a universal design pattern. Bringing components closer can reduce latency, but concentrating them also changes the failure boundary. The wider architecture still needs an appropriate availability and recovery design.
In this case, performance came back faster than the original on-premises setup. More importantly, it gave us the opening to help the client properly: we could build out a secure Azure landing zone instead of leaving the company stuck between a poor cloud experience and another hardware refresh.
The client was right that something was broken. It just did not yet know what "optimised" required.
Why the Radar Chart Works
The strengths-and-weaknesses radar in Spotto gives me a quick view across six recommendation categories: Cost, Security, Compliance, Performance, Reliability, and Operational Excellence.
A category with fewer and less severe open recommendations appears healthier towards the outside of the radar. A category with more work accumulating pulls towards the centre. If cost looks strong while security health is sitting at 30–40%, the imbalance is immediately visible.
That percentage is a directional recommendation-health signal, not a certification result or a guarantee that the environment is secure. It is also not automatically a priority ranking. A client's business reality might make one issue more urgent than a lower score elsewhere.
As a five-second visual gut-check, however, the radar replaces hours of manual pillar-by-pillar work just to see the shape of the environment. It tells me where to start asking better questions.
Why Governance Still Deserves Its Own Review
Microsoft's Azure Well-Architected Framework has five pillars. Spotto's recommendation radar uses six practical categories, including Compliance, but governance deserves attention beyond any single point on that chart.
Governance cuts across the environment. It includes how management groups and subscriptions are organised, which policies are assigned, where exemptions exist, how RBAC is controlled, whether privileged access is understood, and whether tagging and ownership are enforced consistently.
Some of that evidence influences Security, Compliance, or Operational Excellence. Some belongs in a landing zone assessment. The important lesson for me was not to force every governance finding into whichever pillar happened to be closest. I want to review the governance model directly and then understand how it affects each workload.
The Hard Part Was Never the Pillars
I say this often: knowing there is a pillar called Performance Efficiency has no value on its own.
The hard part is working out what good performance means for this particular client, whether there is a real performance problem, and where it lives. That means digging into metrics, checking whether autoscaling is enabled and sensible, and looking for architectural patterns. Is there a queue that should be handling load levelling and asynchronous processing? Is the application constrained by compute, storage, network latency, locks, or a dependency somewhere else?
The pillar name is a label. The real work is diagnostic: understanding the specific systems, bottlenecks, business requirements, and trade-offs that apply.
"Azure Advisor Already Tells Me This"
I hear this pushback often, and I have plenty of counterexamples.
In one client environment, Azure Advisor had effectively run out of cost recommendations. We had not.
The client's App Service plans were still on Premium v2 when a newer generation offered better price-performance. A SignalR service had seen no traffic for a long time but was still sitting there orphaned. The scaling configuration deserved review because the application was running more instances than its observed traffic appeared to need. The wider cost picture also depended on Azure Hybrid Benefit, reservations, actual utilisation, and how those commitments related to the workloads consuming them.
Azure Advisor is useful, and its capabilities continue to improve. It includes App Service rightsizing and reservation recommendations. The gap is not that Advisor knows nothing. The gap is that provider-native recommendations do not always join current pricing, utilisation history, architecture, licensing, commitments, customer priorities, and migration trade-offs into one workload-level decision.
In that engagement, the important findings were in those connections.
From a Finding to a Scoped Project
A review usually surfaces a mixture of work: quick cost wins, straightforward security improvements such as moving from stored credentials to managed identity, and larger architectural changes.
The larger opportunities appear when the client can finally see why a longer piece of work matters. A landing zone rebuild is a common example. It is difficult to secure approval for "better governance" in the abstract. It becomes much easier when the current access, recovery, ownership, and operational gaps are visible.
One case turned into a much longer relationship. A medical company came to us because its application kept crashing and nobody knew why. Availability was critical, so the company had tried to compensate by running twenty instances across two regions, at considerable cost, just to keep the application limping along.
Diagnostic logging had not been enabled on the App Services, so the team did not have the evidence needed to understand the failure. When we investigated, the root cause was an outdated NuGet package.
Fixing it meant the company no longer needed anywhere near that many instances. That saved significant money on its own, on top of the other improvements uncovered during the review. What began as "fix this one problem" became an ongoing monthly engagement, and the client kept us on as trusted advisers.
The value did not come from reciting a pillar. It came from finding the actual cause, explaining it, and turning the wider evidence into a sensible programme of work.
What Actually Changes for the Business
The technical fixes matter, but the bigger shift is often educational.
In one review, we found a business-critical Azure SQL Database using the Business Critical tier in Australia Southeast. Business Critical was providing high availability through its four-node replica architecture, so it was not accurate to say that the database had no high availability.
The problem was the protection boundary. Because the region did not support availability zones for that deployment, those always-on replicas could not be distributed across three physically separate zones. The client was paying for the Business Critical architecture, but it was not receiving the additional zone-failure isolation it could have gained in a region that supported zone redundancy. There was also no secondary-region design capable of carrying the workload through a regional failure.
That distinction matters. Local replicas provide high availability. Zone redundancy improves resilience to a datacenter or zone failure within the region. A tested geo-secondary or failover design addresses the larger regional disaster scenario. They are related layers, but they are not interchangeable.
The leadership team had believed that paying for four underlying replicas meant the whole recovery problem was covered. It did not. The architecture provided real value, but the protection was narrower than the business thought it was buying.
That finding was significant enough that the leadership team asked to join the review session so they could hear the fundamentals directly.
That is the outcome I care about most: not merely a tidier Azure tenant, but a leadership team that understands what it is paying for, which failures the design can tolerate, and which risks it is still carrying.
Why We Built Review Checklists Into Spotto
Every story in this article took manual digging to uncover. That is what we set out to compress with Spotto's Review Checklists.
I can select the Well-Architected checklist, choose the relevant subscriptions, and run the review across them. Spotto automates the checks it can, aggregates the results, shows the affected resources and likely effort, and keeps manual verification visible for the questions telemetry cannot answer.
That last part matters. A scan can tell me how something is configured. It cannot always tell me whether the configuration reflects an accepted business trade-off, whether a recovery process has really been exercised, or whether the client can tolerate the stated downtime. Those questions still require people.
It does not try to be the architect. What it does is get me to a good starting point in minutes instead of days, so I spend my time validating the evidence, talking to the client, and deciding what matters — not assembling the first view of the environment by hand.
It has also become one of the best ways I have found to open with a new customer. Instead of a generic pitch, I can review their own environment and put something concrete in front of them on day one. That is a conversation the client actually values — and it is usually where the next scoped piece of work comes from.
That is the same conversation I used to create by hand, engagement by engagement. Spotto makes it repeatable and continuous.
The Part I Never Wanted to Automate
When I look back, I never wanted to remove the customer conversation or the architectural thinking. Those were the valuable parts.
I wanted to remove the scavenger hunt as a prerequisite for having that conversation.
I still want an architect to challenge the evidence, understand the business context, notice what telemetry cannot explain, and take responsibility for the recommendation. I just do not want that architect spending the first week clicking through portals and rebuilding the same spreadsheet.
The framework is just a common language and the tooling is just evidence. What the client is actually paying for is someone who has seen this before, can tell them which risks matter, and will stand behind the recommendation. That part I never wanted to automate.
What to Do Next
Try the review on one real Azure customer:
- Start a Spotto free trial and connect the customer's Azure environment.
- Select the Well-Architected or Landing Zone checklist and the subscriptions in scope.
- Run the scan and review the automated findings alongside the items that still need manual verification.
- Choose the first small group of findings that best reflects the customer's business priority.
- Turn that group into a scoped, evidence-backed improvement conversation.
Common questions
What is an Azure Well-Architected review?
It is a structured assessment of how well a workload aligns to the pillars of Microsoft's Azure Well-Architected Framework — cost optimisation, security, reliability, performance efficiency, and operational excellence — and, in practice, the landing zone the workload runs on. But the framework is only the common language. The real work is diagnostic: deciding what "good" means for this particular client, whether there is a real problem, and where it lives.
What is the difference between a Well-Architected review and a landing zone assessment?
The landing zone is the governed platform foundation — management groups, subscriptions, identity, policy, networking, monitoring, and recovery. The Well-Architected Framework focuses on the workloads running inside it. They are not the same thing, but in practice you review them together, because you cannot judge a workload's resilience without knowing how the platform underneath it is organised.
Does a Well-Architected review replace Azure Advisor?
No — and Advisor is genuinely useful. But provider-native recommendations do not always join current pricing, utilisation history, architecture, licensing, commitments, and customer priorities into one workload-level decision. In one client environment, Azure Advisor had run out of cost recommendations and the manual review had not: an orphaned SignalR service, an older App Service generation, and scaling running ahead of real traffic were all still on the table.
How do you turn a Well-Architected review into billable work?
Pick the first small group of findings that best reflects the client's business priority, and turn that group into a scoped, evidence-backed improvement conversation — quick cost wins, a security fix such as moving to managed identity, or a larger landing zone rebuild. The larger opportunities land when the client can finally see why the longer piece of work matters; "better governance" is hard to approve in the abstract and much easier once the current gaps are visible.
About Spotto
Spotto is an AI-native CloudOps platform for MSPs and cloud teams. It investigates Azure spend, configuration, and health, turns what it finds into prioritised, workload-level recommendations, and helps teams run structured reviews, generate customer-ready reports, and act on the findings.
Sources
- What is the Azure Well-Architected Framework?
- What is an Azure landing zone?
- Azure Well-Architected Framework workloads and landing zones
- Azure proximity placement groups
- Azure Advisor cost recommendations
- Azure SQL Database vCore service tiers and Business Critical architecture
- Reliability in Azure SQL Database
- Azure SQL Database high availability and disaster recovery checklist
- Spotto Review Checklists