Most cloud cost advice is architectural. Refactor to serverless. Containerise the monolith. Rebuild the data pipeline. All of it is usually correct and none of it helps the finance director who has just seen this month's invoice and wants to know what changes before the next one.
There is a separate category of cost work that gets far less attention because it is unglamorous: settings, schedules and cleanup. No redesign, no migration, no business case. Ten of these are listed below, with the specific mechanism on each of the three major providers. A competent platform engineer can land most of them inside a week, and the savings show up on the next billing cycle rather than the next financial year.
None of this replaces the architectural work. It buys you the credibility and the budget headroom to go and do it.
The compute that runs when nobody is using it
The single largest source of avoidable spend in a typical South African cloud estate is non-production compute running twenty-four hours a day to serve a team that works roughly fifty hours a week. Development, test, UAT and training environments are provisioned like production because that is the template everyone copied, and then nobody turns them off.
First: schedule your non-production environments off. Azure has auto-shutdown built into the VM blade, and Azure Automation or a Logic App handles the start side. AWS ships the Instance Scheduler solution, though a tagged Lambda on an EventBridge rule is often simpler. GCP handles it through instance schedules attached to a resource policy. If you run non-production from 06:00 to 20:00 on weekdays only, you are paying for about 50 hours of a 168-hour week — a reduction of roughly 70% on that portion of the estate. For many mid-sized organisations, non-production is a third to a half of total compute.
Second: act on the right-sizing recommendations you already have. Azure Advisor, AWS Compute Optimizer and GCP's Recommender have been quietly generating these for months. They are conservative by design, they are based on your actual utilisation telemetry, and in most estates a meaningful share of VMs are two sizes larger than anything they have ever needed. The work is not analysis, it is change control. Pick the twenty highest-cost instances, check the recommendation, schedule the resize window.
Third: move interruptible work to spot capacity. Batch jobs, CI runners, data processing, rendering, test suites — anything that can be restarted without a human noticing. Azure Spot VMs, AWS Spot Instances and GCP Spot VMs all price at a substantial discount to on-demand in exchange for the provider's right to reclaim the capacity. Your build agents are the obvious first candidate and usually the easiest sell, because nobody has an SLA on them.
Storage, where the money leaks quietly
Storage rarely triggers alarm because no single line item looks large. In aggregate it is frequently the second biggest avoidable cost, and it is almost entirely a housekeeping problem.
Fourth: delete the disks nothing is attached to. When a VM is deleted, its managed disk often is not. Azure unattached managed disks, AWS unattached EBS volumes and GCP orphaned persistent disks all continue billing at full provisioned rate indefinitely. Every estate we look at has them. Some have years of them. A single query in the portal or CLI gives you the list; the only real work is confirming with the owning team before you delete, and if the tagging is poor that confirmation is the slow part.
Fifth: put a lifecycle policy on object storage. Azure Blob lifecycle management, AWS S3 lifecycle rules and GCP Object Lifecycle Management all do the same thing — move data to cooler tiers as it ages, and delete it when retention allows. Logs, backups, exports and archived documents are usually sitting in the hot tier because that is where they landed. Cool and archive tiers cost a fraction of hot storage. The caution worth stating plainly: archive tiers charge for early deletion and for retrieval, so the policy needs to match how the data is actually accessed, not how you assume it is.
Sixth: audit your snapshot and backup retention. Automated snapshot policies are set once and reviewed never. Seven years of daily snapshots on a database that needs thirty days of recovery point is not a compliance posture, it is a default nobody revisited. Check the retention against what your actual policy requires — and if the actual policy does not exist in writing, that is the finding.
Seventh: fix your storage tier and disk type defaults. On AWS, gp3 volumes cost materially less per gigabyte than gp2 and decouple IOPS from capacity; the migration is in-place and does not require downtime. On Azure, a significant share of Premium SSD disks are attached to workloads whose measured IOPS would be comfortably served by Standard SSD. This is not a performance compromise if you check the telemetry first — it is correcting a provisioning decision made without telemetry.
Commitments, but only against a baseline you trust
Eighth: buy commitment discounts for the floor, not the forecast. Azure Reserved Instances and Savings Plans, AWS Savings Plans and Reserved Instances, and GCP Committed Use Discounts all trade flexibility for a discount that is large enough to be worth the trade. The mistake is committing against a forecast. Commit against your floor — the compute that has been running continuously for the past ninety days and will still be running in a year. Then revisit quarterly and layer on more as the floor rises.
The sequencing matters and is routinely got wrong: right-size first, then commit. Committing to an oversized baseline locks in the waste for one to three years and makes the optimisation work harder to justify afterwards.
Ninth: claim the licensing entitlements you are already paying for. Azure Hybrid Benefit lets organisations with Software Assurance apply existing Windows Server and SQL Server licences to Azure compute, which removes the licence component from the VM rate. Azure Dev/Test subscription pricing removes the Windows licence charge on non-production entirely for eligible subscriptions. Both are commonly unclaimed because the person managing the Azure estate and the person managing the EA licensing are not the same person, and neither has been asked to check.
Making the bill legible before the next cycle
Tenth: turn on budgets and anomaly alerts, and put a tag policy behind them. Azure Cost Management, AWS Budgets with Cost Anomaly Detection, and GCP Budgets and alerts all take under an hour to configure. Set them at team and subscription level, not only at the top of the account, because a single account-level alert tells you that something went wrong without telling you where.
Tagging is the multiplier on all of it. Without an enforced tag schema — owner, environment, cost centre, project — every one of the nine changes above becomes an archaeology exercise, because you cannot safely delete what you cannot attribute. Azure Policy can deny untagged resource creation outright, AWS can do the same with tag-condition Service Control Policies alongside tag policies, and Google Cloud can enforce labels for supported resources through custom organisation policy constraints. Turning that on going forward is a one-day task. Backfilling the existing estate is the harder job, and it is worth scoping it honestly rather than pretending it is quick.
What the local context adds
Three things change the arithmetic for South African organisations in ways the global playbooks do not cover.
Your bill is denominated in dollars. Every percentage point of optimisation is worth more in rand terms when the currency weakens, and the inverse is also true — an estate that looks like it is growing may simply be an estate that is being repriced. Track your cloud spend in both currencies so you can tell the difference between a consumption problem and an exchange rate movement. A finance team that cannot separate the two will either panic at the wrong time or relax at the wrong time.
Data residency shapes what you can move. POPIA does not require that personal information stay in South Africa, but sector requirements, contractual commitments and internal policy frequently do. Before you move data to a cheaper tier or a cheaper region, establish which classifications are actually constrained. In practice, most estates find that a minority of their data carries the constraint and the majority has been treated as though it does.
Resilience should be sized to the risk you actually carry. Load-shedding has been less disruptive than in the worst years, but the risk has not been retired, and neither have the multi-region architectures built in response to it. Some of those are correctly specified. Others are paying enterprise-global resilience premiums for workloads where a few hours of degraded service would be an inconvenience rather than a material loss. That is worth a deliberate decision rather than a default.
The honest limits of this list
These ten changes will not fix a badly architected estate. If you lifted and shifted a monolith onto oversized VMs three years ago, scheduling and right-sizing will reduce the bill without changing the fact that the workload is in the wrong shape. Treat the savings as funding and breathing room for the modernisation conversation, not as a substitute for it.
They will also not hold. Every one of them reverts unless someone owns it — a monthly review, a named accountable engineer, and tagging enforced at provisioning rather than cleaned up quarterly. Organisations that run this as a once-off exercise are usually back at the same number within a year, and the second cleanup is harder to get approved than the first.
Start with the scheduling and the orphaned storage. Both are low-risk, both are measurable on the next invoice, and both give you the evidence to ask for the time to do the rest properly.
How CloudNala can help
We run cloud cost assessments and FinOps enablement across Azure, AWS and Google Cloud, starting with exactly these settings-level changes and then putting in place the ownership, tagging and monthly review that stop the savings from drifting back.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Review or write to us at consult@cloudnala.co.za