Monthly Savings
MAGRID
How We Cut Azure Costs by EUR 3,000/Month and Made Reports 10x Faster
A deep Azure and reporting-system rescue: right-sized hosting, optimized Azure SQL usage, reduced database round trips, moved static workload to Azure Static Web Apps, and cut report generation from 7 minutes to 42 seconds.
Report Runtime
Speed Increase
EUR 3,000/month wasted, 7 min reports
EUR 36k/year saved, 42 sec reports
Challenge
The business problem behind the technical symptoms.
The client had a familiar mid-market problem: the system worked, but it had become expensive and slow to operate. Their Azure bill was higher than it needed to be. The application hosting model had drifted away from the workload it actually served. Dynamic application code, database-heavy reporting, and static frontend delivery were not separated cleanly enough. The result was wasted spend and limited visibility into what should be scaled, optimized, or moved. The reporting workflow had a second problem: critical reports took around 7 minutes to generate. That was not just a slow page. It was a sign that report generation was doing too much database work, making too many round trips, and forcing users to wait while the application assembled data inefficiently. The business needed two outcomes at the same time: reduce Azure cost without destabilizing production, and make reporting fast enough that teams could use it during real work instead of waiting around for exports.
Technical breakdown
What actually changed.
Azure hosting model review
The first step was to stop treating the Azure bill as a pricing problem and treat it as an architecture problem. I reviewed how the workload was split across App Service, the App Service Plan, SQL Server, and static assets. The goal was not to blindly downgrade resources. The goal was to put each workload on the model that matched its actual runtime behavior.
- Reviewed the App Service model against real traffic and compute requirements.
- Selected a more appropriate App Service Plan instead of paying for capacity that was not creating business value.
- Separated static frontend delivery from backend application hosting where Azure Static Web Apps was the better fit.
- Kept dynamic backend workloads on Azure App Service where server-side execution, identity, integrations, and API behavior belonged.
Azure SQL and database access optimization
The reporting bottleneck was not fixed by one magic query. It required reducing the amount of unnecessary work between the application and the database. I focused on the actual shape of the report-generation path: what data was fetched, how often it was fetched, where aggregation happened, and how many database calls were required before one report could be returned.
- Reduced repeated database round trips during report generation.
- Removed unnecessary data fetching from the reporting path.
- Improved query shape so SQL Server did less avoidable work.
- Reviewed indexing and data-access patterns around the highest-cost report flows.
- Moved repeated calculations and report assembly away from inefficient request-time loops where appropriate.
Report Centre refactor currently in progress
After the first performance win, the client trusted me with a larger refactor of the Report Centre. That matters because the initial fix proved the direction, but the larger system still needs cleanup so reporting remains maintainable as new reports, filters, permissions, and exports are added.
- Refactoring report-generation boundaries so each report has a clearer execution path.
- Reducing shared technical debt inside the reporting module.
- Making future report changes safer by separating query logic, report orchestration, and output formatting.
- Improving maintainability without pausing ongoing business use of the system.
Solution
The fix path.
I approached the project as an Azure cost and reliability rescue, not as a cosmetic cleanup. 1. Right-sized the Azure hosting footprint. The App Service and App Service Plan were reviewed against the workload instead of accepted as-is. Static workload was moved to Azure Static Web Apps where it made sense, reducing pressure on the backend hosting layer. 2. Optimized SQL Server usage. The reporting path was inspected for high-cost database access patterns, repeated calls, inefficient query shape, and unnecessary request-time work. 3. Reduced database round trips. Report generation was changed so the application did less back-and-forth work with the database before producing the final output. 4. Improved report-generation flow. The system now spends less time assembling data inefficiently and more time returning the actual report the business needs. 5. Started the deeper Report Centre overhaul. The current phase is refactoring the reporting module so the performance improvements are not a one-off patch, but part of a cleaner reporting architecture.
Results
What changed for the client.
The project delivered measurable business impact. Azure costs were reduced by EUR 3,000 per month, or EUR 36,000 per year annualized. That saving did not come from reckless resource cutting. It came from choosing a better hosting model, right-sizing the App Service Plan, separating static workload where appropriate, and reducing waste in how the system used Azure resources. Report generation dropped from roughly 7 minutes to 42 seconds. That is a 90% runtime reduction and about a 10x improvement in the reporting workflow. The larger proof is trust: the client is now moving forward with a broader refactor and overhaul of the entire Report Centre. That is the strongest signal in B2B services. The first intervention saved money and proved technical judgment. The next phase is deeper ownership of a critical business system.
Face a similar problem?
Start with the smallest useful diagnosis.
Bring the Azure bill, slow report, unstable app, or failed deployment. We will scope the first useful move.