Non-production environments tend to mirror the size of production, run twenty-four hours a day, and have no owner. That is the exact combination that produces a slice of the bill nobody defends and almost nobody reviews.
What follows: why they grow unchecked, which measures work, what still requires judgement, and how the saving is sustained.
When an organisation first reviews the detail of its cloud bill, the surprise is rarely in production. It is in the number of development, test, training and demo environments still switched on.
None of them was created by mistake. Each answered a real need at the time, and the need ended before the environment did.
Why they grow unchecked
The first cause is that creating is easy and deleting is frightening. Switching off something someone might be using carries a high perceived cost and a low perceived benefit, so the individually rational decision is to leave it running.
The second is the absence of an owner. An environment built for a project that ended has nobody to ask, and with no identifiable owner nobody takes on the risk of turning it off.
The third is replication by default. Production sizing gets copied because it looks like the safe option for representative testing, even when the environment’s real load is a fraction of it.
Which measures work
Scheduled shutdown. The highest-effect, lowest-friction measure. An environment used during working hours does not need to run overnight or at weekends, and the saving is proportional to the hours it spends switched off.
Mandatory tagging at creation. Project, owner and expiry date as a condition of provisioning. Without a tag there is nobody to attribute the cost to, and what is not attributed is not questioned.
Expiry by default. Giving an environment an expiry date at birth reverses the burden: instead of someone having to justify switching it off, someone has to justify extending it. It is the policy change that brings the most order.
Sizing on its own merits. A test environment rarely needs production capacity. It needs the same behaviour, which is a different thing: same version, same configuration, less capacity.
What requires judgement
Some tests genuinely do require equivalent sizing. A load test against a reduced environment produces results that say nothing useful about production, and trimming there is a false saving.
The usual answer is temporary: stand up the equivalent environment for the test window and release it afterwards. That requires infrastructure described as code, because otherwise rebuilding it costs more than leaving it running.
There is also the question of which data lives in those environments. Copying the production database with real personal data is convenient, and it creates a protection obligation identical to production’s, with fewer controls around it.
What data protection requires
A test environment holding real personal data carries the same obligations as production. Habeas Data (Ley 1581) in Colombia and the LFPDPPP in Mexico do not distinguish by the name of the environment, but by the data it contains.
That makes masking more than good practice: replacing identifiable data with fictitious equivalents that keep the same format allows realistic testing without carrying the obligation across.
It is worth solving inside the copy process rather than as a later clean-up. An unmasked copy that existed for a few hours still existed.
How the saving is sustained
A one-off clean-up works once. What sustains the result is policy that operates on its own: expiry by default, scheduled shutdown active, and tagging mandatory at creation.
Making cost visible per team helps as well. When each area sees what its environments consume, the conversation stops being a central imposition and becomes their own decision.
And it is worth measuring the proportion rather than the amount: what percentage of the bill belongs to non-production environments. That number stays comparable over time even as the business grows.
What has to exist first
An inventory with an owner per environment, and the ability to attribute cost through tags. Without attribution, any discussion about reducing ends in generalities.
And an agreement with the technology team about the goal: reduce the cost of what does not contribute, without taking away the environments the team needs to work well. Framed as a cut it earns justified resistance; framed as hygiene, it does not.
The inventory almost nobody has
Before trimming it is worth knowing what exists, and that inventory is usually the first finding of the exercise: environments from closed projects, copies made for a one-off test, replicas of sales demonstrations already given.
The quick way to build it is to cross two lists: the resources that consume, and the tags that attribute them. Anything in the first and not the second is an immediate candidate for review.
That comparison also reveals the size of the governance problem. If a high share of consumption has no identifiable owner, the saving is the lesser consequence; what matters is that nobody knows what is running.
Which measure has the greatest effect?
Scheduled shutdown outside hours of use. It is simple, reversible, and its saving is proportional to the hours the environment spends doing nothing.
Should test environments match production?
Match in behaviour — same version and configuration — but rarely in capacity. The exception is load testing, where it is worth standing up the equivalent only for the window required.
Can real data be used for testing?
It carries the same protection obligations as production, with fewer controls around it. Mask inside the copy process rather than as a later clean-up.
Which indicator is worth following?
The share of the bill belonging to non-production environments. Unlike the absolute amount, it stays comparable over time even as the business grows.
