How many subscriptions do you have in your Azure estate?
With a handful of Azure subscriptions, managing Reservations and Savings Plans manually is hard but doable. You can pull data, spot the gaps, and make decisions quickly enough for the analysis to still be relevant by the time you act on it.
At 100 or more subscriptions, the same process breaks down. Commitment exposure fragments across independent subscription boundaries. Because it can take weeks to get a complete picture of the environment, do the analysis, and execute complex Reservation exchanges, data goes stale before decisions get made.
Most organizations don’t realize how far off track they are until they’re already overcommitted. Here’s what to watch for, and where to start.
More Flexibility with Reservations vs. Savings Plans
Savings Plans and Reservations are Microsoft Azure’s primary mechanisms for committing to a term in exchange for a discount rate on resources.
Savings Plans are the simpler path yet come with additional risk. You commit to a fixed spend amount per hour, and Azure applies discounts broadly across eligible resource types. There’s nothing to configure by resource, nothing to exchange, nothing to monitor for utilization drift. That simplicity is appealing, especially in large estates with 100+ subscriptions where managing commitments feels unscalable.
But that simplicity is also a trap. Savings Plans are immutable. Once purchased, the commitment level cannot be adjusted for the duration of the term. If your usage declines below what you committed to, you’re paying for compute you’re not running. If usage grows faster than expected, you’re leaving savings on the table. You have no mechanism to correct either direction until the term expires.
Reservations work differently. They are configured to a specific resource type-region combination and can be exchanged. If you migrate to a different resource, you can exchange existing Reservations to match the new reality. This is essentially a refinancing: the term resets, but you’re aligning coverage to actual usage rather than watching a static commitment drift out of sync.
Unlike immutable Savings Plans, Reservations are more beneficial in dynamic environments because of their ability to correct course as usage shifts. The challenge is exercising that flexibility across hundreds of subscriptions — knowing when to exchange, what to exchange to, and what you’re committing to next. This is where the DIY approach breaks down.
Three DIY Challenges
Each of the following issues compounds at scale.
1. Visibility gaps
Before you can evaluate any exchange, you need to understand your current commitment coverage — what’s deployed, what’s being utilized, and where utilization is drifting. Across hundreds of subscriptions, that requires pulling data from each one, normalizing it, and assembling a picture that doesn’t exist natively in Azure. Microsoft Azure’s native tooling shows you slices, but you have to build the aggregate dataset yourself. Also, if you are not a Global Admin or don’t have the right permissions, your view may exclude a subset of subscriptions.
2. Stale analysis
Even with complete data, evaluating and executing a single decision can be a multi-day exercise. At scale, with multiple commitment actions in flight simultaneously, this can take weeks. By the time you’re done, the usage data has already shifted.
3. Re-commitment risk
An exchange is not a clean swap. It is a cancellation and a rebuy. The remaining term on your original commitment disappears, and the newly exchanged Reservation starts a fresh one- or three-year term. Done manually, there is no reliable way to model how an exchange impacts your overall financial outcomes, especially as usage changes dynamically. If your overall usage declines below your coverage amount over the year, you can be overcommitted and wasting spend.
How Automation Drives Outcomes and Frees Time
Consider a Dsv2-to-Dsv7 migration. Better performance on the Dsv7 family makes it an attractive upgrade. But getting there means dealing with existing Dsv2 Reservations. Exchanging all of them means new, full-term commitments that increase commitment risk.
DIY/Manual
This takes days, sometimes weeks, for large organizations, since it requires back-and-forth with engineering teams and complex spreadsheet modeling. By the time the analysis is complete, the answer it produces is already stale:
- Pull usage data subscription by subscription.
- If access is limited, work with engineering teams to get the complete picture of the environment.
- Normalize and aggregate data across a heterogeneous estate in a large spreadsheet.
- Collect pricing data on Dsv2 and Dsv7 VM series.
- Analyze usage for existing Dsv2 workloads elsewhere in the organization.
- Build a model to determine whether existing Dsv2 workloads could absorb the displaced commitments before any exchange is made.
- Project what the new commitment portfolio looks like afterward.
- Multiple steps to execute on commitment actions concurrently.
Autonomous
An automated approach eliminates each of those failure points. Usage is monitored continuously across every subscription in aggregate, not sampled on a schedule.
When a Dsv2-to-Dsv7 migration is needed, the system automatically checks whether existing Dsv2 utilization elsewhere in the estate can absorb the displaced commitments before any exchange is made. If redeployable coverage exists, it’s used first. Only when no absorption path exists does it proceed to a new-term exchange.
The result is an exact exchange path grounded in current usage across the full estate, not a model built on data that was already stale when the analysis started.
Here is a real-world example. Capita plc, a multinational professional services and business process outsourcing firm, manages its Azure commitments across hundreds of subscriptions using ProsperOps automation. At that subscription count, the complexity of commitment management is beyond what any manual process can reliably handle. You can read Capita’s case study to learn more about how they improved their Effective Savings Rate from 37% to 49%.
Where Do I Start
We return to the initial question: how many subscriptions do you actually have?
The number is often larger than expected, particularly in organizations that have grown through acquisition or structured their cloud by business unit. Getting an accurate count is the starting point for understanding your actual commitment exposure.
The most reliable approach for large estates with hundreds of subscriptions is to combine Management Groups with the Azure CLI. This gives you full structural visibility in one pass. The management group hierarchy surfaces every subscription, and the CLI queries it without requiring you to click through each subscription on the Azure portal. If you’re not a Global Admin or lack the right RBAC role, loop in your Azure platform or cloud operations team to get the complete picture.
For smaller ranges or quick checks, Azure’s native tooling offers other starting points:
- Subscriptions View: Quickest starting point on Azure portal; shows subscriptions you have access to, but may not reflect the full estate.
- Cost Management + Billing View: Best for the billing view; surfaces subscriptions tied to your billing account (even ones you may not have RBAC access to).
Once you have an accurate count, the harder question is whether your current commitment portfolio is optimized against the full estate. This requires continuous analysis across every subscription in aggregate, tracking utilization shifts, modeling exchange paths, and recalculating coverage as usage evolves.
Unlike manual processes, autonomous solutions like ProsperOps are built precisely for analyzing commitment exposure across hundreds of subscriptions simultaneously, and producing exact outcomes rather than estimates.
If you’re managing 100 or more subscriptions today, it’s worth understanding what unoptimized commitment exposure is actually costing you. Sign up for a free Savings Analysis.
