Reducing cloud costs by about 47%

Treat cloud spend as an architecture decision

Cloud infrastructure creates a recurring commitment for the business. In this production environment, the question was whether that commitment still matched what the platform needed. I approached the review as an architecture and operating-cost decision: understand the workload, identify unnecessary capacity and consider the consequences of changing it.

Establish a basis for the decisions

The April–June 2026 baseline was around AUD 31k per month. Reviewing resource use and configuration gave the optimization work a concrete starting point. The objective was to bring the infrastructure footprint closer to the needs of the product, with cost, performance and operational requirements considered together.

Change the footprint with production in mind

The changes included right-sizing resources, reducing minimum replicas, using scale-to-zero where appropriate and retiring idle resources. The judgment was in deciding where each approach belonged. Capacity, availability and responsiveness are part of the same decision as cost; a lower bill alone does not establish that a configuration is appropriate for a live service.

Translate the result into business terms

The monthly Azure spending figure for July–August was around AUD 17k, about 47% below the earlier baseline. That represented around AUD 15k in monthly run-rate savings. Reducing that recurring commitment creates budget flexibility for the business. The figures are rounded for readability; the percentage and saving are calculated from the underlying recorded amounts.

Make the improvement sustainable

Optimization needs to remain connected to how the platform evolves. Sustained reporting across cost, reliability, deployment and quality is the next step, so future capacity decisions can be made with a clearer view of their operational and financial effects. The comparison captures the spending change across the stated periods; it does not establish equivalent workload or performance on its own.

Connect technical choices to business responsibility

This work reflects how I approach technology leadership: make the operating cost of architecture visible, evaluate the tradeoffs and connect implementation decisions to the business’s recurring commitments. My role combined infrastructure review with hands-on changes, while keeping the wider question in view: what should the platform cost to operate, and how should that change as the product grows?