Cutting a logistics platform's cloud bill by 41% — while it grew

The situation

Our client ran a logistics platform that was growing quickly — and a cloud bill that was growing faster. Finance had done the sensible first things: reserved capacity, a cost dashboard, a monthly review. The bill kept climbing. The engineering team was stretched running the platform and had no room to step back and ask why.

The instinct was to negotiate harder with the cloud provider. The real problem was in the architecture.

What we did

We started by measuring what the workload actually needed, rather than what had been provisioned during earlier growth spurts. The picture was familiar:

• Environments sized for peak, running at peak around the clock — serving a load that peaked for a few hours around each dispatch window.
• Data moving constantly across zones, quietly accruing egress charges that never surfaced in a design review.
• No back-pressure, so a routine traffic spike would scale the system out aggressively and turn a busy hour into an expensive one.

We reshaped the architecture so capacity followed demand, kept data local to where it was processed, and added back-pressure so the system degraded gracefully instead of scaling into a large bill. Only once the footprint was right did we buy reserved capacity — on the smaller, stable base that remained.

The outcome

Cloud spend fell by 41 per cent over two quarters, during which order volume grew by nearly a third. Because capacity now follows demand, cost rises sensibly with the business instead of running ahead of it. Latency improved as a side effect of right-sizing — the platform was no longer fighting its own over-provisioning.

We now run the platform’s infrastructure under an agreed set of reliability and cost targets, and report against them each month.