"Our cloud environment is already optimized. Our architects knew what they were doing."
In short: "Already optimized" usually means "optimized when it was designed." But Azure services, prices, workloads and business priorities keep moving, so an environment drifts out of optimization over time. A single review across the five Azure Well-Architected pillars — cost, security, reliability, performance and operations — surfaces the future work hiding in plain sight: the rightsizing, modernization, governance and risk fixes a client needs next. Spotto finds and evidences that work continuously, so an MSP can turn it into approved projects and a recurring managed optimization service.
It sounds like the end of an optimization conversation. When I worked as a cloud solutions architect at a managed service provider, I heard versions of it regularly.
And the customer often had a point: their architects did know what they were doing.
The problem was not the original architect. The problem was assuming the environment had stood still.
Azure had released new services and SKUs. Prices and licensing had changed. The workload had grown, shrunk, or developed new peaks. Temporary resources had become permanent. Security guidance and business priorities had moved on.
The better question was not, "Was this environment optimized when it was designed?" It was:
Is it still optimized for what the customer needs today?
That reminds me of the familiar cartoon where people are struggling to pull a cart on square wheels while declining the offer of a round one.
For an MSP, finding what changed can create immediate customer value: lower cost, better security, improved reliability, stronger governance, higher performance, or less operational effort. Properly evidenced, it can also become a customer-approved improvement project or recurring managed optimization service.
The difficult part is repeatedly gathering the information, comparing the options, validating the evidence, and turning it into a meaningful customer conversation.
That is why we built Spotto. It is the tool I wish I had beside me in those customer meetings.
What experienced cloud reviewers notice
I have also built and sold startups of my own. When you are running on a shoestring budget, cloud efficiency is not an abstract FinOps exercise. The service must perform, but every unnecessary dollar matters. That experience made me slightly obsessive about getting the best outcome from the infrastructure underneath a business.
There is a scene in Catch Me If You Can that captures how an experienced reviewer can see a problem quickly. Frank Abagnale is handed a cheque and immediately calls it a fake. The FBI agent asks, "How do you know? You haven't even looked at it."
Frank then points out the physical clues: the paper, the cut edge, the ink, and even the smell. He recognizes the pattern because he knows what a genuine cheque should look like. You can watch the scene here.
Cloud reviews can feel surprisingly similar.
Sometimes I only needed to open the Azure subscriptions page before the questions started forming.
What can one Azure page tell an MSP?
Suppose a customer has one Azure subscription containing production, development, test, shared services, experiments, and perhaps resources from several business units.
One subscription is not automatically wrong, and it is not proof that the environment is insecure or non-compliant. It is, however, a strong reason to investigate:
- How are production and non-production access rights separated?
- Can teams have different budgets, quotas, and policy guardrails?
- How are changes to production isolated from experimentation?
- Can cost and ownership be reported cleanly?
- Are privileged roles broader than they need to be?
- How are security and compliance controls evidenced independently?
- Is the customer using an Azure landing zone or another intentional governance model?
- Could eligible non-production workloads use discounted Dev/Test pricing?
Microsoft describes Azure landing zones as the recommended, scalable foundation for organizing identity, subscriptions, networking, security, governance, management, and platform automation. It also recommends an application landing zone for each workload environment, such as development, test, and production. See Microsoft's guidance on Azure landing zones and managing application environments.
Management groups and subscriptions are also important governance boundaries because policy and access assignments inherit through the hierarchy. Microsoft's management-group guidance specifically discusses organizing workloads by operational, security, compliance, and ownership needs.
For eligible non-production environments, Azure Dev/Test pricing can reduce the cost of selected Azure services and software licensing. Eligibility and channel restrictions still need to be checked; it is an opportunity to investigate, not a saving to assume.
From a single page, an MSP can therefore identify several potential conversations: subscription design, landing-zone adoption, access control, policy, budgets, cost allocation, non-production pricing, and compliance evidence.
That is before inspecting a single workload.
How can MSPs automatically surface billable cloud services work?
Spotto is the AI Assisted Cloud Operations platform for MSPs — it turns cloud operations into revenue intelligence: the billable work and hidden risk in every customer tenant, with the evidence to action it. It helps turn technical signals into customer-value work that can be understood, approved, delivered, and measured.
One scan can surface project opportunities such as rightsizing, service modernization, landing-zone adoption, governance improvement, storage optimization, licensing reviews, and security or reliability remediation. It can also support recurring managed optimization: monitoring drift, reassessing new Azure alternatives, tracking commitments, maintaining governance, and bringing prioritized evidence into customer reviews.
The goal is not to manufacture tickets. It is to uncover improvements already justified by a measurable customer outcome—and give the MSP enough evidence to have a meaningful conversation about them.
Finding an opportunity is easy; proving it is harder
An experienced architect can spot clues quickly. The difficult part is moving from a clue to a defensible recommendation.
It is easy to say:
This SQL Managed Instance looks large. Reduce its vCores.
It is much harder to answer the questions that should follow:
- Which lower vCore values are supported by this tier and hardware family?
- Can the target still support the customer's reserved storage?
- Does the hardware family expose a compatible memory option?
- Is the instance locally or zone redundant?
- Is SQL licensing included, or is Azure Hybrid Benefit being used?
- Is it a primary instance, geo-secondary, or failover context?
- What happens to storage, PITR backup, LTR backup, and additional-memory charges?
- Is the customer paying public list price, an actual negotiated rate, or an amortized commitment cost?
- What do 14, 30, or 93 days of CPU and IO history show?
- Did the observation window include month end, payroll, reporting, ETL, or another business peak?
- What is the performance risk, implementation effort, rollback path, and expected business benefit?
This is where a quick review turns into Excel hell.
One Azure service can contain millions of potential states
SQL Managed Instance is a good example because its vCore list initially looks manageable.
Model note: The following figures use a pinned Azure Pricing Calculator model from June 2026 and graph validation completed in June and July 2026. They illustrate the scale of the option space; they are not a price quote or a claim that every theoretical state is deployable and fully priced.
Our pinned model contains 110 canonical tier, hardware, and vCore shapes. Behind them are hundreds of pricing variants and thousands of connected facts:
| Modeled evidence | Count |
|---|---|
| Canonical standalone SQL MI shapes | 110 |
| Calculator SKU and pricing variants | 552 |
| Modeled regions | 64 |
| Graph relationships | 120,429 |
| Potential evaluation states after finite configuration dimensions | 90,767,360 |
The 90.8 million figure expands only finite dimensions in the pinned model: supported shapes, per-shape storage increments, valid memory selections, local or zone redundancy, recovery context, licensing, 64 regions, and four backup-redundancy pricing contexts. It is a measure of potential evaluation states—not 90.8 million fully priced recommendations.
It still excludes purchasing permutations, commitment coverage, variable PITR and LTR quantities, instance pools, billing overlays, customer discounts, currencies, runtime metrics, growth, policy, risk appetite, and business criticality.
Azure's current SQL Managed Instance resource-limit documentation illustrates why these dimensions cannot be treated independently. Storage, IOPS, throughput, backup consumption, retention, vCores, service tier, and hardware characteristics affect one another.
What the option space looks like
A portion of Spotto's harvested Azure pricing and configuration graph. The density is the point: Azure options are connected by constraints, not arranged as one simple price list.
This is what the spreadsheet permutations look like when the relationships are made visible.
The graph is useful because it does not require Spotto to materialize and test 90 million rows for every customer resource. It stores the valid shapes, price evidence, capabilities, regions, and constraints as connected facts.
For an observed SQL Managed Instance, Spotto narrows the search:
Current customer resource
-> match its region, tier, hardware, vCores, licensing, and redundancy
-> follow valid configuration and price relationships
-> exclude candidates that cannot support storage or memory requirements
-> apply pricing, recovery, backup, metrics, and customer policy
-> produce an explainable opportunity
The resulting candidates still need to pass workload, price, and policy checks before they become customer recommendations.
Configuration and price are only half the problem
The cheapest technically valid option is not necessarily the right recommendation.
For SQL Managed Instance, Azure Monitor exposes useful platform metrics including avg_cpu_percent, io_bytes_read, io_bytes_written, reserved_storage_mb, storage_space_used_mb, and virtual_core_count. Microsoft maintains the current list in its SQL Managed Instance supported-metrics reference.
Those metrics still need interpretation.
A low average CPU value does not prove that an instance is oversized. We need percentiles and peaks. We need to know whether the window contains the business cycle. We need to review scheduled jobs, Query Store, incidents, application latency, and SQL wait statistics. Azure Monitor's platform metrics do not provide the complete SQL memory story, so memory risk may require Database Watcher, DMVs, another approved telemetry source, or a DBA review.
The cost comparison also needs context:
- Current actual and amortized spend.
- Which charges scale with vCores and which remain fixed.
- Azure Hybrid Benefit and included licensing.
- Existing reservations or savings-plan coverage.
- Storage, backup, additional memory, security, and networking components.
- Public reference price versus the amount the customer will actually pay.
This is why manual optimization is so resource intensive. The architect is not just comparing SKU A with SKU B. They are joining configuration data, price data, billing data, utilization history, operational requirements, and customer policy—then explaining the result to both technical and commercial stakeholders.
Doing that once is a project. Doing it continuously across hundreds of resources and many customers is a platform problem.
A recommendation has to articulate the value
A raw finding such as "reduce vCores" is not enough for an account manager, customer decision maker, or change-approval board.
A Spotto SQL Managed Instance recommendation can include:
- A plain-language description of the observed issue.
- The current and proposed configuration.
- Utilization, cost, saving, and projected headroom.
- The potential customer and business benefit.
- Confidence, impact, implementation effort, and risk.
- Technical considerations, prerequisites, and supporting guidance.
- An implementation, approval, rollback, and validation plan.
That changes the commercial conversation.
Instead of saying:
We found another item in an assessment spreadsheet.
The MSP can say:
This instance has remained underutilized over the observation window. A supported same-family reduction could save approximately this amount each month. Here is the evidence, here are the risks, this is the estimated effort, and this is how we would implement, monitor, and reverse the change safely.
One is a technical task. The other is a business case and a deliverable piece of work.
The MSP optimization value loop
A repeatable optimization service needs more than detection:
- Find: Continuously identify cost, security, reliability, performance, governance, and operational opportunities.
- Validate: Check configuration constraints, price evidence, metrics, billing, licensing, dependencies, and customer policy.
- Frame: Explain the customer outcome, saving, risk, effort, impact, confidence, and migration path.
- Fulfil: Turn the approved opportunity into a scoped project, action, or managed-service task.
- Prove: Validate the result and show the customer the saving or operational improvement achieved.
- Repeat: Reassess as Azure, the workload, and the business change.
This loop is where Cloud Operations becomes Revenue Intelligence. The operational data identifies where the MSP can create value, while the commercial context helps the MSP prioritize and communicate that work. It is also how an MSP surfaces the future work in an estate — the projects and risk fixes a client will need next, before they think to ask — and turns it into a roadmap rather than a reactive to-do list.
From information hierarchies to judgment hierarchies
AI is making technical information less protected, less static, and less exclusive. More people can retrieve facts, compare services, and generate an initial recommendation list. An MSP's differentiation therefore moves from an information hierarchy to a judgment hierarchy.
Who can frame the real customer problem, manage ambiguity, understand what matters to the business, explain trade-offs, build trust, and carry responsibility for the recommendation?
For example, information might show that a security service reduces risk but increases cost, while an optimization removes waste. Judgment can turn those facts into a responsible sequence:
Remove avoidable cloud waste
-> release budget
-> invest in the highest-priority security controls
-> improve the customer's overall outcome
-> avoid making the customer materially worse off financially
That is not "cost instead of security," and material vulnerabilities should never be ignored. Another customer might address security first because its immediate exposure outweighs cost concerns. Spotto presents the evidence, impact, effort, risk, and trade-offs; the MSP and customer decide the appropriate priority.
Spotto MCP connects the value chain
Spotto MCP allows AI tools and agents to use Spotto's structured cloud context and recommendations. Spotto can enrich Azure Advisor findings and produce unique recommendations using configuration, metrics, billing, licensing, commitments, capabilities, and dependencies.
Azure and customer evidence
-> Spotto models and recommendations
-> Spotto MCP
-> AI agents, cloud engineers, architects, and business systems
-> human judgment and customer decision
-> approved action and measured outcome
An agent can collect context, compare alternatives, prepare a customer briefing, or support an approved delivery workflow. The architect or engineer remains the judge: does this option meet the customer's objectives, and is the risk acceptable?
This is not about replacing people with machines. It is about moving from protecting roles to building capabilities. Judgment, accountability, trust building, and understanding the customer become more valuable when machines make complexity easier to master. Spotto helps cloud professionals spend more time using those capabilities and less time acting as an Excel engine.
A practical customer scenario
Consider an MSP taking over or reviewing a customer's Azure estate.
The customer says the environment is already optimized because it was designed by experienced cloud architects.
Spotto finds:
- One subscription containing production, development, and test resources.
- Broad access assignments and limited policy separation.
- Non-production services that may warrant a Dev/Test pricing review.
- Hundreds of storage resources whose tier, redundancy, transaction profile, and retention settings have not been reassessed.
- SQL Managed Instances with low CPU history but different storage, memory, licensing, backup, and recovery constraints.
- Older service generations with newer compatible alternatives.
- Recommendations whose savings and risk vary significantly.
The MSP does not send the customer a thousand-row export.
It groups the findings into customer outcomes:
- A landing-zone and governance improvement engagement.
- A prioritized database right-sizing project.
- A storage optimization workstream.
- A licensing and commitment review.
- A recurring optimization service that monitors drift and validates realized value.
The customer receives a roadmap rather than noise. The MSP receives a defensible pipeline of work tied directly to the health and efficiency of the customer's environment.
This is not just a scenario. When Umbrellar Technology Group — one of New Zealand's leading MSPs — put Spotto across managed Azure estates, new environments went from weeks of manual discovery to insights in days, and in a single managed environment Spotto surfaced between US$6,400 and US$10,300 of billable optimisation work every month — recurring services revenue, alongside the security, governance and reliability work that came with it.
Common questions
What tools analyse Azure against the Well-Architected pillars for MSPs?
Spotto reviews a customer's Azure estate against all five Azure Well-Architected pillars — Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency — and turns the findings into evidenced, prioritised recommendations an MSP can take into a customer conversation. It does not stop at cost: the same scan surfaces governance, resilience, access, and modernization work.
How can MSPs automatically surface billable cloud services work?
Spotto continuously scans connected Azure environments and surfaces project opportunities — rightsizing, modernization, landing-zone adoption, governance, storage and licensing reviews, security and reliability remediation — each validated against configuration, price, metrics, billing and policy, and framed with the saving, benefit, effort and risk. The MSP chooses which to take forward; nothing is manufactured.
Is this just cost optimization?
No. Cost is often the easiest benefit to quantify, but optimization spans the five pillars of the Azure Well-Architected Framework: Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency.
The same review can uncover weak governance, excessive access, missing resilience, operational toil, unsupported services, performance constraints, and architecture improvements.
Does Spotto replace the cloud architect?
No. It removes much of the repetitive discovery, joining, comparison, and evidence-gathering work. Architects and engineers still understand the customer, frame the problem, make trade-offs, apply ethics and judgment, approve risk, build trust, test changes, and own the final design.
Spotto lets those experts spend less time maintaining spreadsheets and more time having meaningful customer conversations, making decisions, and delivering improvements.
Does every finding become billable work?
No—and it should not.
Some findings are immaterial, blocked by policy, already planned, covered by an existing commitment, or too risky for the expected benefit. Good optimization software must be able to exclude or downgrade those findings.
The valuable opportunities are the ones that survive validation and can be connected to a meaningful customer outcome.
If an environment was optimized last year, why review it again?
Because the inputs changed. Azure introduced new services and SKUs, prices moved, the workload changed, and the customer's business priorities may be different. Optimization is a state that must be maintained, not a certificate that lasts forever.
Does Spotto automatically make the change?
For supported recommendations, Spotto Actions can help an authorized user implement or schedule an approved change. For infrastructure-as-code environments, the implementation can remain in the customer's normal source-control, peer-review, testing, and deployment workflow.
More complex changes still need a properly scoped migration plan, testing, approval, monitoring, and rollback.
Related reading
- From days to clicks: the economics of cloud assessments
- How cloud waste can self-fund security and reliability improvements
- Why an AI product should not use AI for everything
What to do next
Try this with one existing customer—a friendly, trusted customer who is open to having its Azure environment reviewed.
- Start a Spotto free trial.
- With the customer's permission, connect and scan its Azure environment.
- Let Spotto analyze the inventory, utilization, cost, licensing, commitments, configurations, and architecture signals.
- Select the three most defensible opportunities based on customer value, evidence, impact, effort, risk, and confidence.
- Take those opportunities into the next customer review and agree on the right next action.
You may uncover a rightsizing change, governance engagement, modernization project, security improvement, or recurring optimization service. Even one well-evidenced opportunity can improve the customer's environment, create a meaningful conversation, and unlock new services revenue within an existing customer relationship.
Start with one customer, prove the value, and then repeat the process across your managed estate.
About Spotto
Spotto is the AI Assisted Cloud Operations platform for MSPs — it turns cloud operations into revenue intelligence: the billable work, validated savings, and hidden risk in every customer tenant, with the evidence to action it. It continuously analyzes cloud inventory, telemetry, pricing, billing, licensing, commitments, service capabilities, and architecture signals to identify optimization opportunities.
Spotto helps MSPs turn those findings into clear customer value: the evidence, saving, benefit, impact, effort, risk, implementation path, and operational context needed to propose and deliver the work. Through Spotto MCP, that intelligence can also support workflows involving AI agents, people, and connected systems while keeping human judgment central to customer decisions.
Summary
- An environment can have been well designed and still contain new opportunities as Azure, prices, workloads, and business priorities change.
- One pinned SQL Managed Instance model produced more than 90 million potential evaluation states before several billing, backup, and workload dimensions were included.
- Spotto combines configuration, pricing, billing, licensing, commitments, metrics, policy, and architecture signals to produce explainable recommendations.
- MSPs can turn validated findings into customer-value projects or recurring managed optimization services.
- As information becomes more accessible through AI, framing, judgment, accountability, and trust become stronger MSP differentiators.
- Start with one willing customer, take three defensible opportunities into the next review, prove the value, and repeat.