Cloud cost problems are not primarily a technology problem. They are a governance problem.
The organisations that consistently overpay for cloud are not doing so because they picked the wrong services or missed a pricing tier. They are doing so because no one in the organisation has clear accountability for cloud spend, the visibility into what is being spent does not exist in a usable form, and the incentives that govern day-to-day engineering decisions do not include cost.
A cost governance framework addresses all three. This is what one looks like in practice, built for the South African context and applicable whether your workloads run on Azure, AWS, GCP, or some combination.
What governance actually means here
Cloud cost governance is not the same as cloud cost optimisation. Optimisation is a one-time activity — a review that finds wasted spend and makes recommendations. Governance is the ongoing structure that prevents waste from accumulating in the first place and catches it quickly when it does.
The distinction matters because most South African organisations that engage with cloud cost do so reactively. A bill arrives that is larger than expected, someone investigates, a few quick wins are found, and six months later the same pattern repeats. Governance breaks that cycle by creating accountability, visibility, and decision rights that operate continuously, not just when the bill hurts enough.
A functional cloud cost governance framework has four components: tagging and attribution, budget controls, review cadence, and accountability ownership. None of them are technically complex. All of them require organisational will to implement and maintain.
Component one: tagging and attribution
You cannot govern what you cannot see, and cloud cost visibility starts with tagging.
Every cloud resource — virtual machines, databases, storage accounts, functions, networking components — should carry a consistent set of tags that answer: which team owns this, which application or product it belongs to, which environment it is in (production, staging, development), and which cost centre or project code it maps to.
This sounds obvious. In practice, most cloud environments in South Africa have inconsistent or absent tagging, because tagging was not enforced at provisioning time and retrofitting it is painful. The cost of that gap is real: without attribution, cost anomalies cannot be traced to their source, chargebacks to business units are impossible, and the data needed to make intelligent optimisation decisions does not exist.
The practical fix is tag enforcement at provisioning. Azure Policy, AWS Service Control Policies, and GCP Organisation Policies all support required tagging rules — resources that do not carry mandatory tags cannot be created. Implementing this takes a day. The ongoing benefit is that every resource created from that point forward is attributable.
For environments that already exist without proper tagging, a phased cleanup over eight to twelve weeks — starting with production environments and the highest-spend services — is the realistic path.
Component two: budget controls and alerting
Budgets in cloud platforms are not hard limits in most configurations — spending can exceed a budget without being blocked. What budgets provide is the alerting infrastructure that turns a cost anomaly into a notification before it becomes a surprise on a monthly bill.
Every significant workload, team, or project should have an associated budget with alerts configured at 80% and 100% of threshold, sent to the team owner and the person with financial accountability. This configuration takes minutes per environment on any of the major cloud platforms. It is not in place in most South African cloud environments.
The specific numbers matter less than the discipline. A development team that knows its environment has a R12,000 monthly budget and receives an alert when it hits R9,600 has a completely different relationship to cost than a team that receives a consolidated bill after the month closes. The former team adjusts behaviour in time. The latter team explains variance retrospectively.
For organisations running across multiple cloud providers, a cost management layer — AWS Cost Explorer, Azure Cost Management, GCP Billing Reports, or a third-party tool like CloudHealth or Apptio Cloudability — that consolidates spend into a single view is worth the overhead. The alternative is manually reconciling multiple billing portals, which is both time-consuming and error-prone.
Component three: a review cadence
Governance without review is just documentation. Cloud cost governance requires a recurring review at two levels: a weekly operational review and a monthly strategic review.
The weekly operational review is a fifteen-minute check by whoever owns cloud operations. It answers three questions: is any workload trending above its budget before month-end, has any new spend appeared that was not expected, and are there any obvious anomalies in the cost data? The goal is early detection of issues when there is still time to act in the current billing period.
The monthly strategic review is a thirty-minute conversation between engineering leadership and whoever holds financial accountability for the cloud budget. It reviews actual versus budget, identifies the top five cost drivers, reviews any recommendations from the automated cost advisors on each platform, and makes decisions on reserved capacity commitments. This meeting does not need to be long. It does need to happen, on a fixed schedule, with the right people in the room.
South African organisations frequently skip the monthly strategic review because it feels like overhead, particularly in lean teams where the engineering lead and the financial decision-maker are sometimes the same person. The cost of skipping it consistently is that cloud spend grows without strategic direction, and decisions that should be made deliberately — committing to reserved instances, choosing between service tiers, deciding whether to shut down underused environments — are made implicitly by inaction.
Component four: accountability ownership
The most common reason cloud cost governance fails is that no single person owns it.
In most organisations, cloud cost is everyone's responsibility in theory and no one's in practice. Engineering teams make technical decisions that have cost implications but are not accountable for the bill. Finance teams receive the bill but cannot interpret it without technical context. Leadership sees the total but not the detail. No one is connecting all three.
Effective cloud cost governance requires a named owner: a person whose job description includes cloud cost outcomes, who has both the technical context to understand what is driving spend and the organisational standing to change it. In large organisations this is a dedicated FinOps function. In most South African organisations it is a senior engineer or engineering manager who holds this responsibility alongside their other work.
The accountability needs to be explicit — named in the person's objectives, included in team-level reporting, and reviewed in performance conversations. Cloud cost that is everybody's problem is nobody's problem. Cloud cost that is a specific person's accountability becomes a problem that gets solved.
The South African specifics
A few characteristics of the South African cloud environment make cost governance more important here than in some other markets.
Currency exposure is real. Most cloud bills are denominated in USD or EUR. When the rand weakens — as it does regularly — cloud costs in rand terms increase without any change in usage. Organisations that have not planned for this get unpleasant surprises. Budget buffers that account for currency movement, and reserved capacity commitments that lock in pricing for one or three years, reduce this exposure meaningfully.
Development environments are a disproportionate source of waste. In South African organisations with lean operations, development and test environments that were stood up for a specific project frequently run indefinitely after the project ends. No one turned them off because no one was accountable for the cost and the environments are not causing visible problems. A quarterly audit of non-production environments — comparing running resources against active projects — is one of the highest-return activities in cloud cost governance.
Connectivity costs add up. Data egress pricing — the cost of transferring data out of a cloud provider — is often overlooked in South African architecture decisions, particularly where workloads need to connect to on-premises systems, partner networks, or users across the region. Understanding egress cost patterns and designing to minimise unnecessary cross-region or cross-provider data movement can reduce bills meaningfully in data-intensive workloads.
Where to start
If your organisation does not have a cloud cost governance framework in place, the starting point is not a comprehensive programme. It is four concrete actions this week.
Get a full inventory of your cloud spend by service and by team for the last three months. Identify the top ten cost drivers. Check how many of those resources have accurate ownership tags. And name the person who will own cloud cost outcomes going forward.
Those four actions will tell you more about your current governance position than a month of meetings, and they create the foundation for everything that follows.
CloudNala runs cloud cost and governance audits for South African organisations across Azure, AWS and GCP. If you want an independent view of where your cloud spend is going and what to do about it, let's start with a conversation.