Azure MySQL General Purpose vCore consumption dropped drastically in June and resumed in July – need root cause

We are investigating a significant unexplained variation in Azure Database for MySQL General Purpose vCore consumption.

Our consumption reports show:

• May (4–31 May): 2,928 vCore consumption units, approximately ₹33,359
• June: Only 112 vCore consumption units, approximately ₹129
• July (1–8 July): 1,536 vCore consumption units, approximately ₹17,471

May and July indicate consumption of approximately 192 units per day, whereas June shows a completely different usage pattern.

Microsoft Billing Support has confirmed that the billing is in line with the recorded consumption and pricing, but has advised us to raise this as a technical query to understand the reason for the consumption variation.

We need help identifying:

1. What configuration or resource change caused MySQL vCore consumption to drop from 2,928 units in May to only 112 units in June?
2. What changed on or around 1 July that caused consumption of approximately 192 units/day to resume?
3. Was the MySQL server stopped, paused, resized, restarted, moved to another compute tier, or otherwise reconfigured during June?
4. Which Azure logs/activity history should we check to identify the exact configuration changes during this period?
5. Is there a way to retrieve the historical MySQL server configuration/tier/status for May, June and July to determine what caused this difference?

We are trying to determine the technical reason for the drastic change in recorded MySQL vCore consumption between May, June and July.

Any guidance on the specific Azure logs, Activity Log events, metrics or configuration history we should examine would be appreciated.