There is a decision made on roughly the first afternoon of every Azure engagement that will quietly cost the organisation money for the rest of the platform’s life. It takes about thirty seconds to make, it is almost never revisited, and the justification for it is usually wrong. The decision is: which region do we put this in?
The answer is almost always the same. UK South if you are a UK organisation. West Europe if you are continental. Wherever production is going, everything goes there — the production environment, staging, UAT, dev, test, the sandbox a developer span up eighteen months ago and forgot about. One region. Consistent. Tidy. Nobody argues about it.
And expensive. Azure pricing varies between 20 and 40 percent across regions for equivalent services. UK South is one of the more expensive regions Microsoft operates. Running a full non-production estate there is not a deliberate trade-off. It is the default, locked in before anyone thought to ask whether it needed to be.
The justification, when one is offered at all, is usually data residency. “We need everything in the UK.” Sometimes it is consistency — “it is easier if everything is in the same place.” Both are understandable instincts. Neither survives scrutiny. Data residency requirements for production environments are real, documented, and usually legally mandated. Data residency requirements for a development environment containing synthetic test data and last month’s anonymised fixtures are almost never the same thing. The constraint has been assumed, inherited from production, and applied wholesale without anyone checking whether it actually applies.
I pushed back on this assumption directly with a client whose non-production estate was sitting entirely in UK South alongside production. The stated reason was data residency — the organisation was in a regulated sector and had made a decision early on that everything would stay in-region for simplicity. When I asked to see the documented requirement, what came back was the production data handling policy. Nothing in it said anything about development environments. The legal team, when asked directly, confirmed that synthetic and anonymised test data had no residency constraint at all. The “requirement” was an assumption that had never been tested.
We moved dev, test, and the lower staging tiers to North Europe. The migration took a few days, mostly careful validation that nothing had a hard dependency on the original region. After the move, nothing changed for the teams using those environments. No complaints, no incidents, no developer who noticed that their pull request pipeline was now deploying to a different Azure region. The infrastructure worked exactly as it had before. The bill was measurably lower — a consistent saving that compounds across every month the estate runs.
The question that exposes this in almost every organisation I have worked with is a simple one: “Which of our environments has a documented, verified requirement to run in this specific region?” When you ask it out loud, with the cost data in front of the room, the answer almost always turns out to be: production. Just production. The rest of the estate is there because nobody got around to asking the question.
The most expensive Azure decisions are rarely dramatic. They are not the result of a reckless architecture or a catastrophic scaling mistake. They are the result of a choice made once, on the first afternoon, by the engineer who set up the subscription — and the quiet institutional assumption that it was made correctly and does not need to be looked at again. Assumptions made once and never reviewed do not stay free. They compound.
