Case Study: Reducing Logging Waste in a Complex Azure Integration Environment
At a glance
- Client type: Large government agency
- Problem: Excessive diagnostic logging in a complex Azure integration environment.
- Finding: Cost review showed Log Analytics was the primary cost driver due to verbose logs left enabled.
- Outcome: Five-figure annual saving while maintaining operational and security visibility.
- Related service: Cloud cost optimisation / FinOps
Overview
A large government agency was delivering a complex Azure-based integration solution under tight timelines. The environment included core platform services such as API management, application hosting, serverless functions, messaging, private endpoints, and controlled network traffic flows through firewall rules.
During development and troubleshooting, verbose diagnostic logging had been enabled across multiple resources. This was originally done to help diagnose functionality issues while the solution was being built.
However, once the immediate troubleshooting need had passed, the elevated logging configuration was left in place.
Over time, this created a major cost imbalance. The core application components were not the main cost driver. Instead, most of the environment cost was being generated by Log Analytics ingestion and retention.
Through a structured cost review, CloudQbit identified that approximately 80% of the environment cost was associated with logging, not the application platform itself.
After reviewing the configuration, engaging with delivery and engineering teams, and validating the operational requirement for the logs, excessive diagnostic logging was reduced. This delivered a five-figure annual saving while preserving the logging required for operational support and security visibility.
The Challenge
The delivery team was working on a complex solution with multiple Azure services and private network integration. The environment had several moving parts, including:
| Area | Example components |
|---|---|
| API layer | API management |
| Compute | Application hosting and serverless functions |
| Messaging | Managed messaging services |
| Network security | Private endpoints and firewall-controlled traffic |
| Observability | Diagnostic logs and Log Analytics |
During development, the solution experienced functionality issues. To support troubleshooting, verbose logging was enabled across a number of resources.
That decision made sense during active investigation. The problem was that the logging was not reviewed or reduced after the issue was resolved.
As a result, the environment continued sending excessive diagnostic data into Log Analytics.
The delivery team later raised concerns about the high cost of the solution. The response they received was that the cost was normal, expected, and would need to be absorbed by the business.
CloudQbit's review showed that this was not accurate.
The high cost was not mainly caused by the core business solution. It was largely caused by excessive logging that had been enabled during development and left behind.
Why This Was a Problem
Logging is essential in cloud environments. It supports troubleshooting, security monitoring, auditability, and operational visibility.
But logging also has a cost.
When verbose diagnostics are enabled broadly across multiple resources, the volume of data sent to Log Analytics can grow quickly. If logging levels, diagnostic categories, retention settings, and workspace usage are not reviewed, observability can become one of the largest cost drivers in an environment.
In this case, the issue was not that logging existed. The issue was that the level of logging was no longer aligned with the operational need.
The environment was paying for large volumes of diagnostic data that were not providing proportional business or operational value.
Investigation Approach
CloudQbit reviewed the environment from a cost and service composition perspective.
The first step was to understand which services were contributing most to the monthly cost. The expectation was that the main cost drivers would be the core platform components such as API management, application hosting, functions, messaging, or network services.
Instead, the review showed a very different pattern.
Log Analytics represented the majority of the environment cost.
That changed the focus of the investigation. The key question was no longer:
It became:
CloudQbit then reviewed diagnostic settings, logging categories, and workspace ingestion patterns. Discussions with developers and DevOps engineers confirmed that verbose logging had been enabled during earlier troubleshooting and had not been fully removed afterwards.
This turned the issue from a vague platform cost concern into a specific and remediable configuration problem.
Root Cause
The root cause was excessive diagnostic logging left enabled after development troubleshooting.
Verbose logging had been useful during active issue resolution, but it was not appropriate as a long-term steady-state configuration across the environment.
The cost was being driven by a combination of:
| Cause | Impact |
|---|---|
| Verbose diagnostic settings | Increased log ingestion volume |
| Multiple resources sending logs | Broader-than-needed data collection |
| Lack of post-troubleshooting review | Temporary settings became permanent |
| Insufficient cost visibility | Logging cost was not immediately obvious to the delivery team |
| Assumption that cost was normal | The business was told the cost needed to be accepted |
This is a common cloud delivery issue. During project pressure, teams enable additional diagnostics to solve immediate problems. That is often necessary. But without a clear process to review and reset logging afterwards, temporary troubleshooting settings can become permanent cost waste.
Actions Taken
CloudQbit worked through the issue with a practical remediation approach.
| Area | Action |
|---|---|
| Cost review | Analysed the environment cost breakdown by service |
| Cost driver identification | Confirmed Log Analytics was responsible for the majority of environment cost |
| Configuration review | Reviewed diagnostic settings and logging categories across key resources |
| Stakeholder engagement | Discussed logging requirements with development and DevOps teams |
| Root cause validation | Confirmed verbose logging had been enabled during troubleshooting and left behind |
| Remediation | Reduced unnecessary diagnostic logging while retaining required operational visibility |
| Cost optimisation | Reduced avoidable Log Analytics ingestion |
| Governance improvement | Highlighted the need for logging review as part of deployment and handover processes |
The goal was not to disable logging blindly. The goal was to keep the right logs, reduce unnecessary noise, and align observability with actual operational requirements.
Business Outcome
The remediation delivered a five-figure annual reduction in cloud logging costs.
It also helped the agency better understand the true cost profile of the solution. The core application platform was not as expensive as initially assumed. A large portion of the cost was coming from diagnostic data that no longer needed to be collected at that level.
The outcome included:
| Area | Outcome |
|---|---|
| Cost reduction | Five-figure annual saving |
| Cost visibility | Clear separation between application platform cost and logging cost |
| Operational clarity | Better understanding of which diagnostics were genuinely required |
| Waste reduction | Excessive log ingestion reduced |
| Delivery confidence | Challenged the assumption that the high cost was normal |
| Governance improvement | Reinforced the need to review temporary troubleshooting settings |
The biggest value was not just the saving. It was proving that the cost was not an unavoidable business expense. It was a configuration and governance issue that could be corrected.
The Mindset Shift
This case highlights an important cloud delivery lesson.
When a solution is complex, it is easy for high costs to be accepted as normal. This is especially true when third-party teams, delivery partners, or contractors are involved and the internal team does not have full visibility into every configuration decision.
The original position was effectively:
The better FinOps position was:
That shift matters.
| Old mindset | Better mindset |
|---|---|
| "The solution is expensive because it is complex." | "Complexity does not remove the need for cost validation." |
| "Logging was enabled for troubleshooting, so it must be needed." | "Troubleshooting settings should be reviewed before production steady state." |
| "The business needs to absorb the cost." | "The business should only absorb necessary and justified cost." |
| "Log Analytics is just part of operations." | "Logging must be tuned, governed, and cost-aware." |
| "The vendor says it is expected." | "Cost assumptions should be tested with evidence." |
This is not about blaming delivery teams. Under delivery pressure, decisions are often made quickly to resolve functionality issues. The problem is when those temporary decisions are not revisited.
Why This Matters
Log Analytics and diagnostic logging are powerful tools, but they can become expensive when used without discipline.
In many Azure environments, logging costs grow quietly because they are not reviewed with the same attention as compute, storage, or licensing. Teams may focus on the visible application components while overlooking the cost of telemetry generated around them.
This case demonstrates why cloud cost optimisation needs to include observability and monitoring design, not just infrastructure sizing.
A mature review should ask:
- Which resources are sending logs?
- Which diagnostic categories are enabled?
- Is verbose logging still required?
- Is the ingestion volume proportional to operational value?
- Are retention settings appropriate?
- Are troubleshooting settings reviewed after incidents or development issues?
- Has the business been told the cost is unavoidable without evidence?
These questions can reveal meaningful savings without reducing the quality of the solution.
Conclusion
This case study demonstrates how practical FinOps review can uncover hidden cost waste inside a complex Azure environment.
A government agency was running an integration solution with API management, application hosting, serverless functions, messaging, private endpoints, and controlled network traffic flows. The solution was assumed to be expensive because of its complexity.
CloudQbit's review showed that the majority of the environment cost was not coming from the core application components. It was coming from excessive diagnostic logging that had been enabled during development troubleshooting and left in place.
By identifying and reducing unnecessary logging while preserving required operational visibility, the organisation achieved a five-figure annual saving.
The lesson is simple:
This is the type of practical cloud cost optimisation CloudQbit focuses on: evidence-based analysis, engineering-level detail, and cost reduction without compromising operational outcomes.