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. Wherever production is going, everything goes there — dev, test, the sandbox. One region. Consistent. Tidy.
And expensive. Azure pricing varies between 20 and 40 percent across regions for equivalent services. UK South is a “premium” region. Running a full non-production estate there isn’t a deliberate trade-off; it’s a default locked in before anyone thought to ask if it was necessary.
The Data Residency Myth
The justification is usually data residency: “We need everything in the UK.” This instinct rarely survives scrutiny. Production data handling policies are real and legally mandated. However, these constraints are frequently inherited by development environments without anyone checking if they actually apply.
The Synthetic Data Loophole: I recently pushed back on this with a client. They insisted all environments stay in UK South for “compliance.” When I actually asked the legal team to verify the requirement for anonymised or synthetic test data, they confirmed there was no residency constraint at all. We were paying a 20% premium for “simplicity” that didn’t exist.
“But What About Latency?”
The most common pushback from engineering is latency. The fear is that moving a Dev environment from London to Dublin or Amsterdam will slow down the inner loop.
In reality, latency is simply not a big deal in development. An extra 15ms of round-trip time is imperceptible to a developer running an integration test or checking a UI. If your development process is so fragile that a few milliseconds of cross-border latency breaks it, you have a much bigger architectural problem than regional placement.
The Bicep-Powered Move
If you have invested in Infrastructure as Code, moving regions isn’t a “project”—it’s a task.
The Dan Approach: I use Bicep to handle the move in lower environments. Because the environment is defined in code, we simply point the deployment at the new region and restore the data from a backup. It’s clean, it’s repeatable, and it turns a “scary migration” into a standard deployment pipeline.
My Action Plan for Architects:
- Identify non-prod workloads: Look for anything that doesn’t touch real PII or live customer data.
- Challenge the Residency Assumption: Ask the legal team to sign off on synthetic data moving to cheaper regions.
- Redeploy via IaC: Use your Bicep or Terraform templates to spin up the new environment and restore data from a recent backup.
The most expensive Azure decisions are rarely dramatic scaling mistakes. They are the result of an assumption made once, on the first afternoon, by the engineer who set up the subscription. Assumptions made once and never reviewed do not stay free. They compound.
