Cost

Right-size underutilised Azure Database for MySQL servers

Azure Advisor flags MySQL servers that have run cold for a week and recommends halving their compute. This lesson turns that one cost recommendation into a repeatable habit: find the over-provisioned servers, prove they are genuinely idle, and scale them down without taking an outage you did not plan for.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Right-sizing a MySQL server: the basics

What does an underutilised Azure Database for MySQL server actually cost you?

Azure Database for MySQL Flexible Server bills compute by the tier and size you pick, not by how hard the server works. A General Purpose server sized at four vCores costs the same whether it is pinned at 80 percent CPU or idling at 5 percent. Storage and backup are separate lines, but compute is usually the largest, and it is the line that a quiet server overpays on every hour of every day. The size was almost always chosen once, at provisioning time, against a guess about peak load that never arrived.

Azure Advisor watches for exactly this. Its cost recommendation 'Right-size underutilized MySQL servers' (resource type microsoft.dbformysql/servers, recommendation ID 7e76e54f-7978-4d48-9ab9-a4da5b7c69a3) fires when its telemetry shows a server has run with low resource utilisation for an extended period over the last 7 days. The recommendation is specific: reduce the compute size (vCores) by half. Advisor is not guessing that the server is idle, it is reading a week of actual utilisation and concluding the workload fits in less.

The fix is a single control-plane operation: change the server's SKU to a smaller size, or drop it to a cheaper tier such as Burstable if the workload is spiky rather than steady. The compute charge falls immediately and proportionally. The whole skill is making that change with confidence: confirming the low utilisation is the real steady state rather than a quiet week, choosing the right smaller size, and scaling at a moment when the brief restart the change requires does no harm.

In this lesson you will learn how Azure Database for MySQL Flexible Server charges for compute, how Azure Advisor decides a server is underutilised, and how to scale a flagged server down safely without provoking an avoidable outage. You will see the exact az CLI to find flagged servers and resize them, and a Bicep snippet that pins the right-sized SKU so it does not drift back up on the next redeploy.

Fun fact

The week of data that pays for itself

Advisor's right-sizing call is not a static rule of thumb, it is a reading of the last 7 days of your server's own utilisation. That short window is deliberate: it is long enough to see a full weekly cycle of business and batch load, and short enough that it reflects how the workload behaves now rather than at launch. The recommendation it produces, halve the vCores, is conservative on purpose. Microsoft sizes it so the smaller server still has clear headroom over the measured demand, which is why right-sizing a genuinely idle server so rarely causes a performance problem and so reliably shows up as a lower bill the very next month.

Finding the over-provisioned MySQL servers in a subscription

Priya runs the platform team at a SaaS company whose Azure bill has crept up quarter on quarter. The cost review keeps landing on databases, and Azure Advisor's Cost tab shows several MySQL Flexible Servers flagged as underutilised, each with the same recommendation: reduce the compute size by half.

Rather than open each server in the portal one at a time, Priya pulls the Advisor recommendations and the current server sizes together, so the team can see which servers are flagged, what they run on now, and which ones are worth resizing first.

List the MySQL right-sizing recommendations Advisor has raised, so you are working from Azure's own measurement rather than a hunch.

$ az advisor recommendation list --category Cost \ --query "[?contains(impactedField, 'DBforMySQL')].{server:impactedValue, action:shortDescription.solution}" -o table

Server Action

---------------- -----------------------------------------

orders-prod-mysql Right-size underutilized MySQL servers

reporting-mysql Right-size underutilized MySQL servers

# Two servers flagged. Check their current SKU before resizing.

Start from Advisor's own list. Each flagged server has run cold for a week by Azure's measurement, so it is a real candidate rather than a guess.

How Advisor decides a MySQL server is underutilised, and how compute is priceddeep dive

Azure Database for MySQL Flexible Server compute is defined by two properties on the server: the tier (Burstable, GeneralPurpose or MemoryOptimized) and the SKU name (the size, following the Standard_{VM name} convention, for example Standard_D2ds_v4). The SKU name encodes the vCore count and memory. Your hourly compute charge is set by that pair. Advisor's recommendation, reduce the compute size by half, is a recommendation to move to a SKU name with half the vCores within the same tier, or in some cases to drop to a cheaper tier entirely, and the charge follows the new size from the moment the change takes effect.

Advisor builds the recommendation from its own internal telemetry of the server's resource utilisation over the last 7 days. When that utilisation stays low for an extended period of the window, it concludes the workload fits comfortably in less compute and raises the recommendation against the server, with a medium impact rating and the resource type microsoft.dbformysql/servers. The 7-day window is chosen to capture a full weekly cycle, so a server that is busy only on a Monday batch run is judged on that peak, not on a quiet Sunday.

Scaling compute is a control-plane change to the server's SKU. It takes effect quickly but does involve a brief restart of the database engine as the server moves to the new compute, so existing connections drop and reconnect. This is the one operational fact that matters: the resize itself is safe and reversible, but it is not completely transparent to a live workload, which is why you choose the moment. The Advisor recommendation clears on its next assessment cycle once utilisation reflects the smaller server, rather than the instant you run the command.

What is the impact of leaving an underutilised server at full size?

The direct impact is straightforward: you pay for compute you are not using, every hour, indefinitely. A server running at half its provisioned capacity is paying roughly twice what the workload needs on its largest line. Unlike a one-off cost, this compounds quietly: the overpayment renews every billing cycle and is easy to miss precisely because nothing is broken. A right-sizing recommendation left unactioned is a standing subscription to unused capacity.

The second-order impact is that it normalises drift. When the team does not act on Advisor's cost flags, server sizes stop reflecting workloads at all, and the estate accumulates a tail of databases that were each sized generously for a peak that never came. The bill grows faster than usage, and the link between what is provisioned and what is needed is lost. Right-sizing the flagged servers re-establishes that link and makes the next round of drift visible.

On the planning side, an estate where compute tracks usage is far easier to forecast and to commit. Once servers are sized to their real workload, a reserved capacity purchase or a savings plan covers what is genuinely run rather than padding, so the discount lands on real demand. Right-sizing first and committing second is the order that captures both savings rather than locking in the over-provisioning.

How do you right-size a MySQL server safely?

Treat right-sizing as a short, deliberate loop rather than a reflex. The order matters: confirm the low utilisation is real, pick the right smaller size, resize at a quiet moment, then pin the new size so it does not drift back up.

1. Confirm the low utilisation is the steady state

Advisor measures 7 days, which is usually representative, but confirm there is no monthly batch job, quarter-end report or seasonal peak that falls outside the window. Check the server's CPU, memory and connection metrics in Azure Monitor over a longer period than a week before committing. The goal is to right-size to the real peak, not to a quiet fortnight.

2. Choose the right smaller size or tier

Advisor recommends halving the vCores. Use list-skus to see the valid sizes in the region, then pick the next size down within the same tier, or drop to the Burstable tier if the workload is spiky and mostly idle rather than steadily moderate. Leave clear headroom over the measured peak so the smaller server is comfortable, not marginal.

3. Resize at a quiet moment and watch it settle

Scaling compute restarts the database engine, so existing connections drop and reconnect. Pick a low-traffic window, make sure the application retries connections cleanly, run the resize, and then watch CPU, memory and connection metrics for a normal cycle to confirm the smaller server carries the load with headroom to spare.

4. Pin the new size in code so it does not drift back

If the server is deployed from Bicep or another template, update the SKU there to match the right-sized value. Otherwise the next redeploy silently restores the old, larger size and the saving evaporates. Pinning the size in code is what turns a one-off resize into a saving that stays captured.

# 1. See the current size of the flagged server.
az mysql flexible-server show \
  --resource-group rg-data --name orders-prod-mysql \
  --query "{tier:sku.tier, sku:sku.name}" -o table

# 2. See the valid sizes in the region before choosing the smaller one.
az mysql flexible-server list-skus --location uksouth -o table

# 3. Halve the compute: drop a 4-vCore GP server to a 2-vCore GP server.
#    This restarts the engine, so run it in a quiet window.
az mysql flexible-server update \
  --resource-group rg-data --name orders-prod-mysql \
  --tier GeneralPurpose --sku-name Standard_D2ds_v4

# 4. Pin the right-sized SKU in Bicep so a redeploy cannot push it back up.
#    resource mysql 'Microsoft.DBforMySQL/flexibleServers@2023-12-30' = {
#      name: 'orders-prod-mysql'
#      location: 'uksouth'
#      sku: {
#        name: 'Standard_D2ds_v4'
#        tier: 'GeneralPurpose'
#      }
#      properties: { /* ...existing properties... */ }
#    }

Quick quiz

Question 1 of 5

Azure Advisor raises 'Right-size underutilized MySQL servers' against a Flexible Server. What is it actually telling you?

Keep learning

Go deeper on how Azure Database for MySQL Flexible Server prices compute and how to scale it without surprises.

You can now treat Azure Advisor's MySQL right-sizing flag as a clear, actionable saving rather than a notification to ignore: confirm the low utilisation is the real steady state, choose the right smaller size or tier, resize in a quiet window because the engine restarts, and pin the new SKU in code so the saving sticks. Done as a habit across every flagged server, this keeps the compute bill matched to what the workloads actually use.

Back to the library

Right-sizing a MySQL server: the savings view

A recommendation that turns directly into a lower monthly Azure bill, with a near-zero payback period

This is one of the cleanest savings opportunities Azure surfaces, because the lever and the result are the same line on the bill. Compute on a Flexible Server scales roughly with vCore count, so halving the compute size on a server Advisor has flagged moves its compute charge down by close to half from the next billing hour. There is no migration project, no new resource to buy, and no licence to negotiate. The saving is the difference between the old SKU's hourly rate and the new one, every hour, until something changes.

Frame each flagged server as a recurring annual saving, not a one-off. A four vCore General Purpose server dropped to two vCores saves the gap between those two rates for as long as the workload stays small, which on an idle server is indefinitely. Multiply by the number of servers Advisor has flagged across the estate and the recommendation usually clears far more than the engineering hours it takes to action it. The payback period is effectively the time it takes to run one command.

The only cost on the other side of the ledger is risk, and it is bounded. If a server is scaled down too far it can be scaled back up just as quickly, and the workload was already running cold by Advisor's own measurement. So the finance question is not whether to act, it is how to confirm the saving is safe and then capture it across every flagged server rather than the loudest one.

This lesson is for the finance partner who sees Azure Advisor's potential cost savings and wants to know how real they are, how durable, and what it takes to capture them. It covers why a halved vCore count maps almost directly to a halved compute charge, how to express each flagged server as a recurring annual saving, and how to make sure the saving sticks rather than being undone by the next deployment.

Fun fact

The week of data that pays for itself

How a finance partner frames the right-sizing decision

Priya is the finance partner sitting in the quarterly cost review. The Azure bill has crept up, the databases keep coming up, and Advisor's Cost tab now lists two MySQL servers flagged as underutilised with an estimated saving attached to each. The instinct is not to ask whether to do it, because the lever and the saving are the same line: halving the vCores on a flagged server moves its compute charge down by close to half from the next billing hour, and there is nothing to buy to make that happen.

Priya asks the team to turn each flagged server into a recurring number. The orders database is a four vCore General Purpose server that Advisor says will run fine on two; the reporting database is similar. Expressed annually, the two right-sizings together save a meaningful, repeatable amount for a change that takes minutes to apply and can be reversed just as fast if anything looks wrong. The finance pack reads: 'Two servers, each running roughly twice the compute Azure says they need, each saving close to half their compute charge every month from the moment we resize, with the larger of the two cleared first. The payback period is the length of one command.'

Why an unactioned right-sizing flag is a recurring leak

The cost model here is unusually clean for a savings exercise: the action and the saving are the same line, and the saving recurs. Each flagged server left at full size keeps overpaying its compute charge every billing cycle, so the cost of inaction is not a one-off, it is an annuity running the wrong way. Halving the vCores on a server Advisor has measured as idle captures close to half its compute charge from the next hour and keeps capturing it for as long as the workload stays small.

Against that recurring saving, the only cost is a short, reversible change and the small operational care of choosing when to apply it. There is no purchase, no migration and no licence. The finance role is to make sure every flagged server is actioned, not just the most obvious one, and to express the result as a recurring annual figure so the saving is recognised in the forecast rather than disappearing into noise. The metric that belongs on the review is the count of open Advisor cost recommendations for databases and the recurring spend they represent, trending to zero.

What finance can do about the right-sizing opportunity

Finance cannot run the resize, but it owns the framing that turns Advisor's flags into captured, durable savings rather than a list that is admired and forgotten. Three levers.

1. Express every flagged server as a recurring annual saving

Advisor shows a per-server estimate, but the figure that drives action is the annualised saving across all flagged servers, because the overpayment recurs every cycle. Ask the team to total the recurring saving the open recommendations represent and put that number, not the count of flags, on the cost review. It reframes right-sizing from a tidy-up into a line-item the forecast can claim.

2. Require that the saving is pinned in code, not just applied once

A resize that is not reflected in the deployment template gets quietly undone by the next redeploy, and the saving leaks back out without anyone noticing. Make 'updated in Bicep or template' part of the definition of done for each right-sizing, so finance is signing off a durable saving rather than a temporary dip that reappears next quarter.

3. Right-size before you commit to reserved capacity

Reserved capacity and savings plans lock in a discount against a level of usage. Buying them before right-sizing locks in the over-provisioning at a discount, which is worse than it sounds. Insist that flagged servers are resized first, then commitments are sized against the right-sized estate, so the discount lands on real demand and the two savings stack instead of cancelling.

Quick quiz

Question 1 of 5

Advisor flags a four-vCore MySQL server and recommends halving the vCores. As the finance partner, what is the right way to read the saving?

Keep learning

Go deeper on how Azure Database for MySQL Flexible Server prices compute and how to scale it without surprises.

You have finished the finance view of right-sizing MySQL servers. You know the saving and the action are the same line: halving the vCores on a flagged server captures close to half its compute charge from the next billing hour, the payback is the length of one command, and the only risk is small and reversible. Next time Advisor flags a database, you will express the saving as a recurring annual figure across every flagged server, insist it is pinned in code so it does not drift back, and make sure right-sizing happens before any reserved-capacity commitment.

Back to the library

Right-sizing a MySQL server: the headline

Whether the estate pays for compute it provisioned but never used

Cloud bills drift upward through provisioning that was generous at the time and never revisited. A database sized for a launch that under-delivered, or a forecast that doubled and then halved, keeps charging for capacity nobody uses. Azure Advisor measures this directly and tells you which servers are paying for headroom they do not need.

The leadership question is not 'is the database working?' It is 'are we paying for compute we are not using, and would we notice if we were?' Right-sizing the servers Advisor flags is found money: a lower run rate for the same delivered service, captured by a routine change rather than a project.

The discipline that matters is making this a habit rather than a one-off cleanup. A single right-sizing pass saves money once. A standing practice of acting on Advisor's cost recommendations keeps the estate honest as workloads grow, shrink and get forgotten, so the bill tracks what is actually used instead of what was once provisioned.

A short read for the leader who wants the bill to track actual usage rather than old provisioning decisions. It covers what an underutilised database costs, why right-sizing is found money rather than a budget request, and why acting on Advisor's cost recommendations as a habit, not a one-off, is the thing that keeps the estate efficient.

Fun fact

The week of data that pays for itself

What it looks like when the bill tracks usage instead of old guesses

After a board question about why the cloud bill kept rising while the customer base was flat, the CFO asked the platform team a simple thing: are we paying for capacity we are not using? The honest answer was that nobody was sure, because server sizes had been chosen at provisioning time and never revisited, and there was no routine that checked whether they still fit the workload.

The team's response was to make Advisor's cost recommendations a standing item rather than a one-off audit. They pulled every MySQL server Azure had flagged as underutilised, confirmed the low utilisation was the steady state and not a quiet week, scaled each one down to the recommended size, and then added a recurring review so new drift gets caught. The next time the bill came up, the answer to the CFO had changed from 'we think it is fine' to 'we right-sized the databases Azure flagged, the compute line came down, and we now check this every cycle.' That shift, from sizing once and forgetting to continuously matching spend to usage, is the durable win this recommendation delivers, and it lowers the bill rather than raising it.

Why this is a run-rate question for leadership

Nearly every cloud bill that grows faster than the business does so partly through provisioning that was never revisited. Right-sizing the servers Advisor flags is the most direct correction available: it lowers the run rate for the same delivered service, with no project and no trade-off in capability. Left alone, those flags become a permanent overpayment that compounds every cycle.

The leadership value is not the single saving, it is the habit. An estate where Advisor's cost recommendations are actioned routinely keeps spend matched to usage as workloads change, which is exactly the discipline that makes a later reserved-capacity or savings-plan commitment land on real demand rather than padding. This is the rare class of cost work where acting is both cheaper and lower risk than not acting, which is why it should be a standing practice rather than an occasional clean-up.

The leadership move on right-sizing

The executive handle is not to approve each resize; it is to make acting on Advisor's cost recommendations a standing discipline so the estate stays matched to usage by default.

1. Make Advisor cost recommendations a standing review item

Ask for the count of open Advisor cost recommendations and the recurring spend they represent at every cost review, trending to zero. A one-off right-sizing pass saves money once; a standing practice of clearing these flags keeps the bill tracking usage as workloads grow and shrink. The goal is a process that catches drift continuously, not a heroic annual clean-up.

2. Ask for the saving as a run-rate change, not a headline

The proof that right-sizing worked is not 'we resized some databases.' It is a measurable drop in the compute line that persists across billing cycles. Ask for the before-and-after run rate and confirm it has held the following month, because that is the difference between a saving that was captured and one that drifted back when a template redeployed the old size.

3. Sequence right-sizing ahead of any commitment purchase

If a reserved-capacity or savings-plan purchase is on the table, require that the flagged servers are right-sized first. Committing to a discount on over-provisioned compute bakes the waste in for the term of the commitment. Right-size first, commit second, and the discount applies to what the estate genuinely uses.

Quick quiz

Question 1 of 5

The board asks why the cloud bill is rising while usage is flat. What end state should right-sizing be aiming for as the answer?

Keep learning

Go deeper on how Azure Database for MySQL Flexible Server prices compute and how to scale it without surprises.

Two takeaways. Right-sizing the servers Advisor flags is found money: a lower run rate for the same delivered service, captured by a routine change rather than a budget request, with acting both cheaper and lower risk than not acting. And the durable win is the habit, not the single pass: make Advisor's cost recommendations a standing review item so the bill keeps tracking usage as workloads change, and right-size before you commit to reserved capacity so the discount lands on real demand.

Back to the library

Part of the learning path Right-size your Azure compute

Right-size underutilised Azure Database for MySQL servers

Right-sizing a MySQL server: the basics

The week of data that pays for itself

Finding the over-provisioned MySQL servers in a subscription

How Advisor decides a MySQL server is underutilised, and how compute is priceddeep dive

What is the impact of leaving an underutilised server at full size?

How do you right-size a MySQL server safely?

1. Confirm the low utilisation is the steady state

2. Choose the right smaller size or tier

3. Resize at a quiet moment and watch it settle

4. Pin the new size in code so it does not drift back

Quick quiz

Keep learning

Right-sizing a MySQL server: the savings view

The week of data that pays for itself

How a finance partner frames the right-sizing decision

Why an unactioned right-sizing flag is a recurring leak

What finance can do about the right-sizing opportunity

1. Express every flagged server as a recurring annual saving

2. Require that the saving is pinned in code, not just applied once

3. Right-size before you commit to reserved capacity

Quick quiz

Keep learning

Right-sizing a MySQL server: the headline

The week of data that pays for itself

What it looks like when the bill tracks usage instead of old guesses

Why this is a run-rate question for leadership

The leadership move on right-sizing

1. Make Advisor cost recommendations a standing review item

2. Ask for the saving as a run-rate change, not a headline

3. Sequence right-sizing ahead of any commitment purchase

Quick quiz

Keep learning

Related cost lessons