FinOps — The PDF that cost $1,500 a month for an unsupervised design

When scaling infrastructure is easier than fixing the design. In a Peruvian account, we identified the need to build PDFs from the data generated on each request. The design choice was to use a virtual machine and a library that built the PDF from HTML — with a quirk no one caught in time: each API call spawned a Chrome instance, and that instance was never destroyed.

The cost of masking the symptom with more compute

Memory consumption grew with each request until it exhausted the available resource. On top of that, no load tests were ever run. When it went to production — and worse, when that same component was defined as the generic mechanism for all clients with similar needs — two things happened at once: a downtime, because the system couldn't handle the real load, and the confirmation that the original virtual machine had never had the capacity to sustain the combined volume of all those clients.

The immediate response, as containment, was to create a Windows VM Scale Set to absorb the load. It took 5 instances, at a cost of over $1,500 a month — to sustain, with more compute, a problem that was fundamentally a design problem, with no testing, and no proper operations from the start.

The pattern that repeats: scaling instead of asking why

It's exactly the pattern I've most hated watching repeat over 15 years of operations: when something fails, the first proposed fix is adding compute. The problem disappears from the dashboard. The cost goes up. And the root cause —a Chrome instance that never closes— stays there, waiting for the next demand peak to reappear, now more expensive to sustain.

The real fix came later: it was suggested the component could live on Kubernetes, and the API consumption was modernized specifically to remove the memory overflow at its origin — not to tolerate it with more machines. The result was twofold: stability was gained, and cost was reduced, solving at its root an architecture problem that never had proper technical oversight from the initial design.

The pattern has a name and a number in the industry

Cast AI's 2026 Kubernetes optimization report, measured across tens of thousands of production clusters, finds that unmanaged clusters waste between 30% and 50% of their total spend — and that structured optimization programs (rightsizing, autoscaler tuning, cleaning non-production resources) typically recover that same range, 30-50% of cluster spend. The migration in this specific case — from a reactive VM Scale Set to a Kubernetes architecture with the root cause fixed — is almost the textbook case of why that savings range exists.

The lesson I take away

The same one that grounds the first article I wrote on this blog: compute is never free, and scaling it to mask an untested design isn't a solution — it's postponing the real cost and making it bigger in the meantime.